Agree what the receiving system needs
Start with the hospital and integration team. Establish which patient, encounter and report identifiers are needed, how they are supplied and what the destination expects the report to represent.
The contract should also cover report status, timestamps, attachments and how corrected results are handled. Missing context can make a technically valid payload unusable in the intended workflow.
FHIR’s DiagnosticReport resource can represent a diagnostic report and reference associated results or a presented report. That does not mean every hospital uses the same interface or implementation. Confirm the actual destination contract before choosing a message format. HL7 FHIR R4 DiagnosticReport
Separate submission from confirmation
An API response may show that an integration service received a request. It does not necessarily show that the destination accepted it. Neither status proves that a clinician has read the report.
Define these states explicitly. Decide which response advances the workflow, how long the system waits and what the team should do when confirmation never arrives. If the interface requires polling, give that responsibility to a scheduled process rather than assuming the original request will stay open.
In one engagement, we built a submitter and a scheduled confirmer alongside the client’s existing software team. We also added an append-only delivery history so attempts and status changes could be traced. Read the anonymous case study.
Design the failure path before release
Failures are part of the interface, not an exception to the design. Discuss what happens when:
- An upstream step produces no report.
- A patient or encounter identifier is missing.
- Submission times out after the receiver may have accepted it.
- A destination rejects the message.
- A retry would create a duplicate report.
Use stable identifiers and the destination’s supported duplicate-handling behaviour. Keep recovery actions visible to the operational team. A process that silently stops is difficult to support; one that resends indefinitely can create a different problem.
Make the verification boundary visible
Tests against a simulator are useful for checking mappings, orchestration and expected responses. They do not replace acceptance testing with the destination organization.
For our engagement, the complete flow was verified in AWS development against a simulated EHR, with staging prepared for promotion. We describe that milestone precisely because it is different from a production deployment or confirmed delivery into a live patient chart.
Plan the remaining environments, test identities and destination-side checks with the hospital’s integration team. Agree who can confirm that the report appears in the intended place and how the result will be recorded.
Connect the integration to release and support
The integration needs an owner after it starts running. Establish who sees failures, who can retry a delivery and how interface changes are assessed. Keep the release records connected to the verified software version.
ViewCo supports cloud and healthcare integration work as part of product delivery or alongside an existing team. Tell us about the workflow you need to connect.