Integrations
What Trisvio connects to
Most integration pages are a wall of logos. This one is a short list of what genuinely works and a longer list of what does not, because the second list is the one that decides whether a product fits — and it is the one you will otherwise discover in month three.
The real integration surface is laboratory instruments. Everything else is either an export or absent, and the page says which.
- Genuine live integration
- Laboratory analysers
- Protocols
- HL7 v2 (MLLP), ASTM E1381/E1394, file-drop
- Everything else
- CSV export, or not built
- Sends messages
- No — nothing, to anyone
Works
What genuinely connects
| What | How |
|---|---|
| Laboratory analysers — HL7 v2 | Results arrive over MLLP on the hospital LAN, parsed by a dependency-free HL7 v2 parser, matched to the specimen on its barcode and written with full provenance. |
| Laboratory analysers — ASTM E1381 / E1394 | The serial protocol, handshake and checksums included, for instruments that speak RS-232 rather than TCP. Linux and macOS; on Windows use file-drop. |
| Analysers that write files | A watched folder, for instruments whose only output is a file. The least elegant option and often the most practical. |
| Accounting, by export | CSV exports of billing, collections and GST summaries, imported into whatever accounting package the hospital already runs. An export, not a live link. |
Analysers sit on the hospital's own network and the platform does not, so the connection runs through a small on-premise gateway. It is the one component that stays inside the hospital, and it is deliberate: it speaks to instruments on the LAN and sends results outbound over authenticated HTTPS.
It queues when the internet drops. Frames spool to disk and replay unattended when the link returns, because a laboratory cannot stop working because a connection did. That behaviour is covered by the gateway's automated tests, which take the platform away mid-delivery and check that the queue drains on its own when it returns, rather than assumed from the design.
Does not
What Trisvio does not integrate with
Published deliberately, and kept current against the product rather than written once. Several of these exist in the data model as enum values, which is why they are easy to claim by accident — an enum value is not a feature:
- ABDM, ABHA, HFR, HPR — No ABDM code exists. No screen even captures a patient identifier today. If ABDM participation matters to you now, this is a gap — ask for a timeline rather than assuming coverage.
- Insurance, TPA, claims, pre-authorisation — No claim submission, no pre-auth workflow, no payer portal connection. Credit patients are billed and their dues aged; the payer's portal stays the payer's portal.
- WhatsApp, SMS and email to patients — Nothing is sent to patients or their families, ever. There is no patient email and no SMS gateway anywhere in the product. Reminders, result notifications and appointment confirmations do not exist.
- Tally or any accounting package — No integration. The connection is a CSV export that someone imports.
- Payment gateways — Payments are RECORDED by mode — cash, UPI, card — after they happen. Nothing collects money, and there is no gateway, link or QR flow.
- Radiology and PACS — No PACS, and no DICOM or modality connection. Ultrasound studies can be ordered, charged and reported in a structured report with the PCPNDT Form F linked, but images are not received from the machine, and there is no X-ray, CT or MRI reporting.
- A mobile app — There is none. The web application is mobile-friendly, which is a different claim and the honest one.
- Hospital ERP, HR and payroll — No general ledger, no payroll, no supplier payments.
Why
Why the second list is longer
If you are still working out what a hospital management system should cover at all, the complete guide for Indian hospitals is the better starting point.
Because the product was built for small and mid-sized Indian hospitals running OPD and inpatient work, and depth in that came before breadth elsewhere. Instrument interfacing earned its place because retyping a result off an analyser screen is where transcription errors enter a clinical record. The rest has not been built yet, and listing it as “coming soon” would be a way of implying otherwise.
Where the software runs is a related question with its own trade-offs — cloud versus traditional hospital software sets them out.
If an item on the second list is a requirement for you, that is a genuine reason to look elsewhere, and we would rather you knew now. A demo is an expensive way to discover a missing integration.
Next
Related
Instrument interfacing without an integration project