PerfuseConnectors
Every way in, every way out
A connector is how Perfuse reaches another system: the cable, the folder, the queue or the web address messages travel through. Perfuse has 24 kinds of source and 26 kinds of destination, and the healthcare formats that travel over them.
Healthcare formats
The languages health systems speak
A format is the shape of the message itself. Hospitals use several at once, often for the same patient: the admission in HL7 v2, the record in FHIR, the X-ray in DICOM, the bill in X12. Perfuse reads, checks, writes and converts all of them.
HL7 v2
The workhorse of hospital interfaces since the 1990s: admissions, orders, results, scheduling. Parsed fast, every quirk handled, acknowledgements generated.
FHIR R4, R4B and R5
The modern web standard for health data. A full FHIR server, a validator, and conversion from HL7 v2 to FHIR and US Core.
DICOM
Medical images. All five network services, sending and receiving, with de-identification as a step in the channel.
X12
Insurance transactions: 837 claims, 835 remittances, 270/271 eligibility, 278 prior authorization and 275 attachments.
CDA and C-CDA
Clinical documents, including those hidden inside HL7 v2 messages. Checked, signed, repaired and rendered to PDF.
NCPDP, JSON, XML and delimited
Pharmacy messages, and the general formats partners invent for themselves.
Transports
The classic hospital connections
Most interfaces in a hospital still travel over a few well-worn routes. Perfuse speaks each in both directions, with encryption where the route allows it.
Each is tested against the real thing: SFTP against OpenSSH, databases against PostgreSQL, mutual TLS against OpenSSL, DICOM against the Orthanc archive.
Cloud and message queues
Straight into the cloud, without the cloud's toolkits
Perfuse talks to AWS, Azure and Google Cloud over their own web interfaces, with the signing done inside Perfuse, so nothing extra is installed. A message taken from a queue is confirmed only once it has been handled, so a crash means it is read again, never lost.
| Service | Read from it | Send to it | Tested against |
|---|---|---|---|
| Amazon S3 | Yes | Yes, any storage class, Glacier included | LocalStack, AWS's signature example |
| Amazon SQS | Yes | Yes, FIFO in patient order | LocalStack |
| Amazon SNS | — | Yes | LocalStack |
| Azure Service Bus and Event Hubs (AMQP 1.0) | Yes | Yes | Microsoft's Service Bus emulator |
| Azure Blob Storage | Yes | Yes, Hot to Archive | Azurite |
| Google Cloud Pub/Sub | Yes | Yes, in patient order | Google's Pub/Sub emulator |
| Google Cloud Storage | Yes | Yes, any storage class | fake-gcs-server |
| Kafka | Yes | Yes, keyed by patient | Apache Kafka 3.9 |
| RabbitMQ, ActiveMQ, Artemis (AMQP 1.0, STOMP) | Yes | Yes | RabbitMQ 4, ActiveMQ 6.2 |
| MQTT (Mosquitto, EMQX, HiveMQ, AWS IoT Core) | Yes | Yes | Mosquitto 2.0 |
| IBM MQ | Yes | Yes, persistent | IBM MQ 10 for developers |
"Tested against" means a channel read from one place and delivered to another on that software. Emulators stand in where the service itself needs a paid account; the verification record says exactly what each test did and did not show.
Need a connector that is not here?
Tell us on GitHub. The JavaScript reader and writer cover the rest in the meantime.