Integration is usually discovered after the purchase, when the device is on site and the interface does not behave as expected. By then the price is settled and the leverage is gone. The interface specification, the version and the mapping should be verified before the order, not during commissioning.

Integration Is a Purchase Criterion

Integration is a purchase criterion because a device that cannot exchange the required data may not fit the workflow, even if it works perfectly in isolation. The cost of integration can exceed the discount on a used unit.

The buyer should define what the device must send, receive and display, and which system owns each data element. An order message, a result message, a patient identifier or a worklist entry all depend on the interface, and a missing interface can force a manual workaround.

The purchase decision should include the interface cost, the testing time and the internal resources needed. The buyer should also map the workflow, not only the message. Who enters the order, who matches the patient, who reconciles the result and who handles an exception? An interface that works technically but does not fit the workflow will be bypassed. A device that is cheap but requires a custom interface may be more expensive than a supported alternative. The regulatory context varies by market, from FDA rules and the EU Medical Device Regulation 2017/745 to MHRA, TGA and PMDA requirements, while WHO guidance frames the shared principles; interoperability is a separate question from regulatory status.

Interface Types You Will Meet

Medical device integration typically involves HL7 version 2 messages, FHIR resources, DICOM for imaging, or a proprietary interface. The type determines the specification, the testing and the support model.

HL7 v2 remains common for orders, results and patient administration. FHIR is increasingly used for newer applications and APIs. DICOM governs imaging acquisition, storage and worklists. Proprietary interfaces may be the only option for a specific device, and they create a dependency on the vendor or an integrator.

The Interface Specification to Request

The interface specification should describe the messages, fields, triggers, acknowledgements, encoding and transport. It should be specific to the software version supplied, not a generic product brochure.

For HL7 v2, the specification should identify the message types, the trigger events, the segments and fields used, the required and optional fields, the acknowledgement behavior and the character encoding. It should also state the transport, such as MLLP over TCP, and the expected error handling.

For DICOM, the conformance statement should identify the SOP classes, the transfer syntaxes, the worklist behavior and the storage commitment. For FHIR, the buyer should request the resource profiles, the authentication model and the supported operations. The specification should be attached to the purchase order, not left in a vendor portal. The version tested should be the version delivered. The specification should also state the interface\’s limitations. A device may send results but not receive orders, or support a worklist but not a status update. Those limitations should be known before the purchase, not discovered at go-live.

Version Compatibility and Mapping

Version compatibility and mapping determine whether the messages mean the same thing on both sides. A device may support HL7 v2.5 while the hospital interface engine expects v2.3, and a local code may not match the terminology in the receiving system.

The mapping should cover patient identifiers, order numbers, procedure codes, device identifiers and status values. It should also define what happens when a required field is missing or a code is unknown. A mapping that is assumed rather than documented is a defect waiting for go-live.

The buyer should ask for a sample message from the actual device and version, not a template. The sample should be validated against the receiving system and the interface engine before the purchase is confirmed. The mapping should be versioned. A mapping that works for one software release may not work after an update, and the record should show which mapping was tested with which version. The buyer should ask for the conformance profile, not only the version. Two systems can claim the same HL7 version and still differ in the segments and fields they require.

Testing Before and After Delivery

Testing should happen before delivery where possible and again after installation. The first test proves the specification; the second proves the deployed configuration, the network and the workflow.

The test plan should include the message types, the error cases, the acknowledgement behavior, the retry logic and the end-to-end workflow. It should define who provides the test environment, who validates the output and what counts as a pass. In practice, a test that only sends one successful message is not an integration test. The test should also include the failure path. What happens if the interface engine is down, the network is slow or the message is rejected? A system that handles the happy path but not the failure path will create manual work and data gaps.

The acceptance record should include the message samples, the mapping, the test results and the version tested. If the device is updated later, the interface may need regression testing. The test environment should resemble production: the same interface engine, the same EHR version and the same network rules. A test that bypasses the firewall or uses a different engine proves less than the buyer thinks.

Who Owns the Integration Work

Integration work is usually shared between the device vendor, the interface engine vendor and the hospital IT team. The contract should say who does what, who pays and who is accountable for the end-to-end result.

A device vendor may supply the interface but not configure the hospital\’s engine. An integrator may configure the engine but not validate the clinical workflow. The hospital may own the network but not the device software. The gaps between those roles are where projects fail. The contract should also name the escalation path. If the device vendor and the interface vendor disagree about the cause, the buyer needs a route to resolve it without stopping the project. A single integration owner on the buyer side helps; without one, the vendors will coordinate with each other only when prompted.

The purchase order or contract should name the integration deliverables, the acceptance criteria and the support route. A verbal assurance that \”it will integrate\” is not a deliverable.

Ongoing Support and Change Control

Integration is not finished at go-live. Software updates, network changes and interface engine upgrades can break a working interface, and the support model should include change control.

The buyer should ask how the vendor notifies customers of interface changes, whether updates require re-testing and who supports the interface after the warranty. The interface should be monitored for message failures, queue buildup and latency, with an owner for each alert.

The asset register should record the interface version, the mapping and the test date. When the device or the engine changes, the record shows what was tested and what needs to be repeated. The monitoring should include the interface queue, the error log and the message latency. A queue that is growing slowly can look healthy until it stops.

Fallback if Integration Fails

The contract should provide a fallback if the interface cannot be delivered: a manual workflow, a middleware alternative, a replacement device or a refund. Without a fallback, the buyer is dependent on the vendor\’s schedule.

The fallback should be priced and time-bound. A manual workflow may be acceptable for a short period but not indefinitely, and a middleware alternative may add cost and complexity. The buyer should know the threshold at which the device is rejected. The fallback should also consider the clinical risk of a manual workaround. A duplicate data entry step may be acceptable for a week but not for a year, and the workaround should have an owner.

The PACS and DICOM compatibility guide covers the imaging side, and the Knowledge section has related software and records guides. If you are assessing a used unit and want the interface evidence reviewed, send the specification and sample messages to the HHG team.