Device-to-clinical-system integration for MedTech, designed around the commercial consequence that engineering teams discover late: every customer is a separate project.
Two hospitals running the same EHR product have different builds, different versions, different custom fields, different order catalogues, different workflows and different integration teams with different queues. An interface that works perfectly at the first site requires analysis, configuration, testing and scheduling at the second. The engineering that makes a device speak HL7 or FHIR is the small part. The part that scales badly is everything downstream of it, and it determines how fast you can sell.
When every customer requires its own integration effort, the number of deals the company can deliver in a year is bounded by how many integrations it can complete, not by how many it can sell. That constraint sits in engineering and shows up in the commercial forecast, usually as deals slipping quarters for reasons the sales team cannot influence. Most device companies discover this at the point where integration demand exceeds the small team that has been absorbing it.
Underneath it sits the problem nobody budgets for: connecting a device reading to the right patient, reliably, without a clinician typing anything.
Every customer installation is different
Same product, different build, version, custom fields, order catalogue and workflows.
Integration capacity caps deliverable revenue
The constraint is engineering throughput and it appears in the commercial forecast.
You are competing for the hospital integration team
Who have a queue, their own priorities and no obligation to put a device vendor near the front.
Patient matching is the actual hard problem
A device knows a serial number and the EHR knows a patient, and connecting them without manual entry is non-trivial.
Encounter context is missing even when the patient is right
A result can reach the correct patient record and sit outside the encounter, order or workflow a clinician is working in.
Their upgrade will break your interface
On their schedule, with no notification to you, and you will hear about it from a clinical user.
An HL7 acknowledgment is not proof of clinical completion.
The receiving system confirming a message says nothing about whether the right patient was identified, the correct encounter selected, the order linked, the units preserved, the status set correctly, or whether a clinician can actually see it.
The first integration is always bespoke and should be. The decision that matters is what happens next: whether the second is built by copying the first, which produces ten variants nobody can maintain, or by extracting what is genuinely common into a configurable layer with per-customer settings around it. That extraction is cheap at customer two and expensive at customer ten.
Step 1
Separate what is common from what is per-customer before the second integration, since that split is the whole architecture.
Step 2
Solve patient matching first, because it is the hardest part and everything downstream depends on getting it right.
Step 3
Establish where the clinician will actually look, since data in an unvisited location is an integration nobody uses.
Step 4
Send the least that changes a decision, as a smaller payload is approved faster and used more.
Step 5
Configure per customer rather than coding per customer, so a new site is a configuration exercise.
Step 6
Handle result status properly, since preliminary, final, corrected and amended are distinct states and representing one as another misleads a clinician.
Step 7
Design correction handling explicitly, because a second result can create two conflicting clinical records.
Step 8
Monitor delivery per customer, since their upgrade will break something and you want to know before they do.
Step 9
Plan for their integration queue, as scheduling is frequently the longest part of the timeline and is outside your control.
Step 10
Agree the regulatory position early, since where the boundary falls shapes the architecture.
Step 11
Build the test harness once, because regression testing per customer is otherwise manual forever.
Patient matching is the project, and everything else is plumbing.
The clinical record is identified by a patient. Connecting those reliably, at the bedside, without a clinician typing or scanning something they will sometimes skip, is where device integration projects actually fail. Barcode association, worklist-driven assignment, location inference and manual confirmation all work in some settings and none works everywhere. Choosing the mechanism per clinical workflow rather than per product is the difference between an integration clinicians trust and one they work around.
HL7 v2 and DICOM specifics are covered in depth on our HL7 and DICOM Integration page. These are the capabilities that determine whether a device integration programme scales across customers.
Match and Map
Patient Identity Association
Connecting a device to a patient through barcode, worklist, location or confirmation, chosen per clinical workflow rather than per product.
Clinical Data Mapping
Device output to the receiving system structures, terminology and code sets, with mappings documented and exactness stated.
Order and Context Correlation
Tying a result to the order that requested it, covered further on our HL7 and DICOM page and frequently the missing half.
Correction and Amendment Handling
Because sending a corrected result incorrectly produces two conflicting records rather than one updated one.
Place and Integrate
Destination Design
Where in the chart the data lands and whether a clinician goes there, which determines whether the integration is used at all.
Workflow Fit Assessment
What the clinician is doing when the data arrives, since an integration that interrupts a different task will be disabled.
Interface Engine and API Engineering
HL7 v2, FHIR, direct interfaces and vendor marketplaces, selected by what the customer actually supports.
Bidirectional Integration
Where the device needs orders, demographics or context from the clinical system rather than only sending results.
Repeat and Sustain
Reusable Integration Layer
Common logic extracted once with per-customer configuration, which is what makes the tenth integration cheaper than the first.
Customer Onboarding Tooling
Configuration, validation and test automation so a new site is a workflow rather than a project.
Per-Customer Delivery Monitoring
Because every customer upgrade is a potential break and you want to call them rather than be called.
Regression Test Harness
Built once and run per customer, since manual interface testing does not survive a growing installed base.
The integration pattern follows from the clinical workflow rather than from the device. The third column is how the patient gets associated, which is the decision that determines whether the integration works at the bedside or quietly accumulates unmatched results.
| Integration | What flows | How the patient is matched |
|---|---|---|
| Diagnostic results | A result against an order | The order itself, which is the cleanest mechanism available |
| Continuous monitoring | A stream of measurements | Admission association at the bedside, which must survive patient moves |
| Point-of-care testing | A result produced at the bedside | Barcode scan of patient and operator, which is skipped under pressure |
| Therapy and infusion devices | Delivery events and settings | Order-driven association, with configuration changes needing their own trail |
| Imaging and procedural | Studies and measurements | Modality worklist, covered on our HL7 and DICOM page |
The right result in the wrong encounter is still a failed integration. Patient identity is necessary and not sufficient, since a value attached to the correct person but outside the encounter a clinician is working in sits where nobody will look for it.
The architectural question is which of these you absorb in configuration and which force a code change. Everything in the third column that requires code is a reason the next integration costs as much as the last one.
| What varies | Why it varies | Absorb it in |
|---|---|---|
| Interface version and transport | Upgrade cadence and local IT standards | Configuration, with multiple versions supported concurrently |
| Code sets and terminology | Local catalogues and historical choices | A mapping table per customer, never hard-coded logic |
| Custom fields and extensions | Years of local build decisions | A configurable field map, with unmapped content flagged not dropped |
| Order catalogue and identifiers | Every site names and numbers its own | Configuration, with the catalogue loaded rather than assumed |
| Workflow and destination | Where clinicians work differs by unit and site | Per-customer routing, decided with their clinical informatics team |
| Integration engine and gatekeeper | Different middleware, different team, different queue | An adapter boundary, so the engine is swappable |
Supporting a vendor is not the same as connecting to a customer using it. Stating that a product integrates with a named EHR implies a capability that does not transfer between sites. Each installation has its own version, build, extensions, catalogues and integration team, and the work at the second customer is a meaningful fraction of the work at the first unless the architecture was designed for it. Saying it plainly in a sales conversation costs a little credibility in the room and considerably less than discovering it during an implementation the customer thought was configuration.
An integration that delivers a reading into a clinical record has placed information in front of somebody making a care decision. That changes what a delivery failure means, what a mismatched patient means and what a corrected value means, and it draws the integration closer to the product than to IT. Where that boundary sits is a determination for your quality and regulatory functions, taken before the architecture rather than after the first incident.
Clinical safety
- Patient matching treated as a safety control, since a result on the wrong chart is a clinical event rather than a data error
- Unmatched results owned by a named person with a daily clearance expectation rather than accumulating in a log
- Correction and amendment handling designed so an updated value replaces rather than duplicates
- Delivery confirmed to the point a clinician can see it, not to the point a message was accepted
Security and privacy
- Patient data in transit and at rest handled to the obligations your counsel defines, including HIPAA where applicable
- Minimum necessary applied to what the device sends, since sending more than required expands the exposure
- Customer data segregation enforced, as a multi-tenant integration platform holds several health systems data
- Audit trail of what was sent, when, to which system and whether it was accepted
Regulatory
- Engineering controls capable of supporting the frameworks that apply, which may include FDA regulation, IEC 62304, IEC 81001-5-1 and ISO 13485
- Applicability, classification and validation strategy determined by your quality and regulatory functions rather than by us
- Interface changes assessed against device software scope where the integration participates in device function
- Customer-specific configuration treated as controlled where it affects clinical content
Operations
- Per-customer monitoring, since a break at one site is invisible in an aggregate availability figure
- A named contact at each customer for interface issues, because their upgrade is the commonest cause
- Regression testing per customer configuration rather than once against a reference build
- Decommissioning handled, since an interface left running after a contract ends keeps sending patient data
Your platform reports messages sent. Their system reports messages received. Neither party routinely compares the two, which means a quiet loss of a percentage of results can persist indefinitely with both sides showing healthy interfaces. Periodic reconciliation of counts per customer per day is unglamorous, catches the failure mode that monitoring does not, and is the first thing to build after the interface works.
Sent against received counts
Reconciled on a schedule, since a partial loss shows on neither side alone.
Unmatched result queue depth
And whether it is being cleared, because a growing queue is results that never reached a chart.
Delivery latency against clinical expectation
Since a result arriving after the decision was made is technically delivered and operationally absent.
Rejection and error rates by type
Which identify a configuration drift or a change at their end before a clinician reports it.
Interface version and build at each customer
So an upcoming upgrade is a known risk rather than a surprise outage.
Correction volume
Because a rising rate indicates an upstream problem rather than a clinical one.
Integration programmes are usually reported as interfaces live and messages flowing. The outcomes that matter are whether each new customer is cheaper than the last, whether results reach the right patient, and whether anybody would notice a partial loss.
| Category | What we measure | Why it matters |
|---|---|---|
| Follow one result end to end | Which device produced it, which patient and how identity was established, which encounter, whether an order association is required, what the measurement represents, whether units and timestamp are correct, whether status is right, whether it reached the intended workflow, whether a clinician can review it, and what happens when matching fails | If these cannot be answered the integration is transmitting rather than completing |
| Marginal integration cost | Effort for the next customer against the first | The measure that determines whether integration constrains growth |
| Unmatched rate and queue age | Results without a patient, and how long they wait | Where integrations quietly fail, and rarely on a dashboard |
| Reconciliation variance | Sent against received, per customer per period | Catches partial loss that both sides report as healthy |
| Time to onboard a customer | From contract to live interface, including their queue time | The part of the sales cycle engineering actually controls |
| Break detection source | Breaks found by monitoring against breaks reported by a clinician | Their upgrade will break something, and who notices first matters |
We will compare the marginal cost of your recent integrations, review how patient matching works in each clinical workflow, check whether unmatched results are owned, establish whether counts are reconciled with customers, and identify what belongs in a reusable layer.
CaliberFocus is a MedTech engineering partner delivering EHR and clinical system integration for device companies whose growth depends on connecting to every new customer. From patient matching and clinical data mapping to a reusable integration layer, per-customer configuration and delivery monitoring, we build integrations that put results on the right chart and make each new hospital cheaper to connect than the last.
- Patient matching designed per clinical workflow
- Reusable integration layer with per-customer configuration
- Unmatched results owned and cleared rather than logged
- Sent-against-received reconciliation per customer
Security & Compliance
