01
Scoping review
You need to know what you've agreed to before you commit to a date.
Scope-ledFixed price
HL7 Integration Services
Hospital events. Delivered into your workflow.
Connect admissions, orders and results to the product your customers rely on. We scope the hospital interface, build the mapping and make acknowledgements, retries and monitoring part of delivery—not an afterthought.
For healthcare product leaders, engineering teams and health IT teams.
- 01
Hospital or laboratory
An agreed event triggers an HL7 v2 message
- 02
Interface processing
Validate · map fields · route · acknowledge
- 03
Your application
Process the event · track duplicates · monitor failures
A result reaches the right workflow, with failures visible.
Illustrative delivery path · no patient dataClear scope.
Tangible deliverables.
01Interface specification
02Message mapping and test cases
03Go-live and recovery runbook
What determines the scope of an HL7 interface?
Scope depends on the message types, hospital-specific field mappings, transport, acknowledgement behaviour and downstream workflow. Access to the hospital interface team, test messages and a testing environment also affects the delivery plan.
Technical reference: HL7 Version 2 product suite ↗Straight answers
Four Versions of This Conversation.
We've had all of them. Pick the one that sounds like your week — each answers what it costs, how long it takes, and what tends to go wrong.
“We just said yes, and we're not sure what we agreed to.”
Sales committed, the hospital expects something, and nobody internally can say what it involves.
Scope-led
plan after access review
What you actually agreed to
Confirm whether an existing feed can be reused or whether the hospital needs interface configuration or new work. Your side of the line is receiving and handling their data correctly.
Can your team do it?
Technically yes — none of it is exotic. The honest problem is that it's interrupt-driven work with a hard external dependency. Most teams can build it. Fewer can build it and ship their roadmap in the same quarter.
What usually goes wrong
Not the code. It's finding out in week three that the hospital's testing slot is eight weeks out, or that what they send is missing a field your product assumes. Resolve both dependencies before committing to a go-live date.
“We have a go-live date and it's uncomfortably close.”
The date is external, and moving it costs you credibility. So the only question is what gets you there.
Week 1
when you'll know if it's real
The fastest honest path
One feed, one direction, one hospital — admissions first. It's the feed hospitals switch on most readily and it unlocks the most product behaviour. Launching all four at once is the most common reason these dates slip.
What we need from you
- A contact in the hospital's IT or integration team
- Sample data, if they'll share it
- Someone who can answer questions about your data model
- No production access to begin
If the date can't be met
You'll hear it in week one, with the reason — while it's still a conversation with your customer rather than an apology. We'd rather lose the work than have you find out in week five.
“It works at one hospital. We've now sold it to twenty.”
This is where integration stops being an engineering question and becomes a margin question.
4 wks → 1 wk
per site, done right
Why number two costs like number one
Every hospital sends slightly different data. If those differences live in your code, each new customer is a development project. The fix is that they become settings, not code.
When to decide
Before hospital three. It's a normal amount of work to design in, and an expensive one to retrofit once several sites are live and each has its own quiet exceptions.
What it saves
Wire everything directly and connections multiply as you grow; route them through one shared model and they add. At four systems that's 12 versus 7 — and the gap widens with every hospital you sign. There's a picture of this below.
“It's live, it's fragile, and the person who built it left.”
Nobody wants to touch it, it breaks unpredictably, and it's quietly become a risk rather than a feature.
Map first
we change nothing in week one
How you'd know it stopped
Usually you wouldn't — your customer would tell you. A feed that stops raises no error at all; it just goes quiet. Alerting on absence is the cheapest fix with the biggest effect.
Is it safe to touch?
Not until it's mapped, which is why we never start by changing things. You get a written picture of what's running, what still has a consumer, and what's been dead a year. Often the first useful move is deleting something safely.
Can you hand it over entirely?
Yes, including the pager. We watch it and deal with the hospital's IT team directly. The code and documentation stay yours — teams do take it back in-house, and that's a fine outcome.
None of these sound like you? Say so on the call — we'll tell you honestly if it's work we should take.
What you get
Four Kinds of Data. Everything Else Is Detail.
Hospitals can send far more than this, but these four are what products get built on. The grey codes are what your customer's IT team will call them.
Admissions ADT
Who's been admitted, moved or discharged — arriving the moment it happens, not overnight.
CensusEnrolmentFollow-up
Results ORU
Lab, pathology and imaging as they're released — including the corrections that follow, which most integrations miss.
AlertingTrendingDecision support
Appointments SIU
Booked, rescheduled, cancelled and no-showed — so you know who's coming in before they arrive.
RemindersPrepCapacity
Charges DFT
What was done and what gets billed for it — the feed that ties clinical activity to revenue.
Revenue analyticsBilling evidence
The part that decides whether any of it works
Every Hospital Calls the Same Thing Something Different.
One site sends GLUC-F, the next sends FBS, a third sends “Glucose, fasting (serum)”. Same test. Until those become one thing in your product, you have data you can store but can't act on — no alerting, no trending, no analytics that hold up.
A mapping is confirmed by a human once, then applied automatically to every message from that hospital. The AI removes the searching, not the judgement.
Field mapping
Their fields to your model, written down before code is written. You see exactly what maps, what's missing, and what needs a new field on your side.
Terminology mapping
Local codes resolved to the standards the rest of healthcare uses — LOINC for tests, SNOMED CT for problems, RxNorm for medicines, ICD-10 for billing.
AI-assisted, human-confirmed
A model proposes candidates and ranks them; a person confirms. Thousands of local codes stop being a six-week manual slog — without a machine silently deciding clinical meaning.
Kept honest over time
Hospitals add codes without telling anyone. Anything unrecognised is flagged for review rather than dropped, so your coverage doesn't quietly rot.
How it works
One Layer, Five Unglamorous Jobs.
Whether the hospital sends HL7 or offers a newer FHIR connection is their choice — it doesn't change what your product receives.
1
Scoping call
Scope agreed
What data you need, which hospital, and whether your date is realistic.
2
Access requested
Scope agreed
Submitted immediately, because their queue is the clock you can't compress.
3
Build & test
Scope agreed
Against sample data, while their access request moves.
4
Their testing
Scope agreed
Run with the hospital's team, not around them. We handle the correspondence.
5
Go live
Scope agreed
Monitoring switched on the same day, not added later.
6
Next hospital
Scope agreed
A checklist your team can run, not another project.
Where it goes wrong
Six Ways These Projects Fail.
None of them are exotic. All of them are why something that passed testing falls over a month after go-live.
01
The hospital's queue
Access and a testing slot come from their team, on their schedule. Discovered in week three, it costs you the date.
What we doRequest access on day one and build while their queue moves.
02
Unmapped codes
A code nobody mapped arrives, and the record is stored but invisible to your alerting. Nothing errors.
What we doFlag anything unrecognised for review instead of silently accepting it.
03
Corrected results
A result you already showed a clinician gets amended. Most integrations show the first value forever.
What we doTreat amendments as first-class and update what the clinician sees.
04
Two records, one patient
Hospitals merge duplicate patients. If your side ignores it, one person's history splits in two.
What we doHandle merges as a tested event, not an edge case discovered later.
05
Silent stoppage
A connection stops and raises no error. Your customer finds out before you do.
What we doAlert on the absence of data, not only on errors.
06
Site-specific in code
One hospital's quirk hard-coded, then another's. By site eight, nobody will touch the file.
What we doKeep per-site differences as settings from the first hospital.
Adding hospitals
The Decision That Shows Up in Your Margins.
Connect everything to everything and the work multiplies. Route it through one shared model and it adds.
Add one more hospital system and the left goes 12 → 15. The right goes 7 → 8. At twenty customers, that gap is a headcount.
What you can buy
Five Ways to Start.
Fixed scope and fixed price, except the last, which is monthly.
02
Most chosen
First hospital live
A signed customer and a date. One or two feeds, in production, monitored.
Scope-ledFixed price
03
Mapping programme
Thousands of local codes to resolve to LOINC, SNOMED CT and RxNorm.
Scope-ledFixed price
04
Rollout
It works once. Make hospital twenty a checklist rather than a project.
Per hospitalFixed price
05
We hold the pager
It's live. Monitoring, the hospital conversations, and a monthly note.
MonthlyPer connection
Cost & timeline
What It Takes, and What Moves the Date.
Ranges from projects we've delivered. You get a firm number after one scoping call, before committing to anything.
Scope
Typical
What moves the date
One feed at one hospital
Scope-led
The fastest useful thing you can ship. Mostly waiting on access, not building.
Data going both ways
Scope-led
Writing into a hospital's system needs their sign-off on testing. Budget for their time.
A full site — all four feeds
Scope-led
Each feed has its own testing and its own person at the hospital.
Each hospital after the first
Scope-led
Never zero — but this is the number to drive down, and where the shared model pays off.
Keeping it running
ongoing
Hospitals upgrade without telling you. Monitoring, and someone who answers at 2am.
Fixed price agreed before we start, or a dedicated team by the month. Either way the code, the repository and the documentation are yours.
Delivery acceptance
Know what a successful interface looks like.
Agree on these outputs during scoping. Your team should know what it will receive and how to review it.
Message coverage
A versioned mapping specification covering agreed message types, required fields and hospital-specific variations.
Failure-path testing
Evidence for rejected messages, acknowledgements, duplicate handling and recovery—not only the happy path.
Operational handover
Named owners, alert routing, replay procedures and a cutover checklist agreed with the hospital team.
FAQ
The Questions That Actually Get Asked.
If yours isn't here, it's a better use of a call than an email.
What is HL7, in one paragraph?
It's the agreed way hospital systems announce what's happening — a patient admitted, a result released, an appointment cancelled — so other software can react. Ask the hospital which message types and interfaces are available; configuration, access and testing may still require work.
Do we need HL7 or FHIR?
Choose according to the hospital’s supported interfaces and the workflow. HL7 v2 often suits event feeds, while FHIR supports resource-based access. FHIR is newer and better suited to opening data up to partners and apps. Data coverage and workflow behaviour must be validated for the chosen path.
Who owns it when something breaks?
We do, for anything inside the layer we built. When the cause sits at the hospital — a firewall change, an upgrade, an expired certificate — we identify it, explain it in plain terms, and deal with their IT team directly instead of handing you a ticket to chase.
Will this slow down our product roadmap?
That's usually the real reason teams bring us in. The work is interrupt-driven and it eats the engineers you least want interrupted. We either take it off your roadmap entirely or work alongside your team and hand over — your call, and we'll tell you which we'd recommend.
Do we get locked in?
No. It's built in your environment and your repository, and you get the source and the documentation. Ongoing support is something you choose because it's easier, not because you have no alternative. Teams do take it back in-house, and that's a fine outcome.
How do you handle patient data?
We agree the hosting boundary, encryption, access logging and retention requirements with your security team. Development and demonstrations should use synthetic or appropriately de-identified data. Security controls, contractual requirements and any BAA are confirmed during scoping and review.
Tell Us Where You Are.
You'll get a straight answer on whether your date is realistic, roughly what it costs, and what we'd do first — before anyone talks about a contract.
+1 (669) 649 0706
hello@nirmitee.io
USA
Iselin,
NJ 08830
India
Baner, Pune,
Maharashtra 411045
Thanks — we've got it.
You'll hear back within one business day, from someone who has done this before.