01
Scoping review
You need to know what you've agreed to before you commit to a date.
1–2 weeksFixed price
HL7 Integration Services
A Hospital Has Asked You for HL7. Now What?
HL7 is how hospitals send out what's happening inside them — admissions, results, appointments, billing. We connect that to your product, get your first hospital live in weeks, and make every hospital after it cheaper than the last.
HL7 v2FHIREpic · Cerner · Meditech · athenahealthAny hospital system, any interface engine. ISO 27001. BAA available.
Which one is your week? pick one
01“We just said yes and aren't sure what we agreed to.”What you've committed to, and what it costs02“Our go-live date is uncomfortably close.”The fastest path that's still honest03“It works once. We've now sold it to twenty.”Why hospital twenty costs what it does04“It's live, fragile, and nobody owns it.”How to get it off your plateEvery one of these is a call we've taken. Pick yours and we'll answer it below.
2–5 wks
To your first hospital sending live data
52
Connections rebuilt without interrupting care
0
Hours of downtime while we did it
47/47
Federal certification tests passed, first submission
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.
2–5 weeks
typical, first connection
What you actually agreed to
The hospital points an existing feed at you and your product starts receiving events. You're not asking them to build anything new — which is why this is usually less frightening than it sounds. 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. Both are findable in days if someone knows to look.
“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
day 1
What data you need, which hospital, and whether your date is realistic.
2
Access requested
day 1–2
Submitted immediately, because their queue is the clock you can't compress.
3
Build & test
weeks 2–4
Against sample data, while their access request moves.
4
Their testing
1–2 weeks
Run with the hospital's team, not around them. We handle the correspondence.
5
Go live
week 5
Monitoring switched on the same day, not added later.
6
Next hospital
ongoing
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.
2–5 weeksFixed price
03
Mapping programme
Thousands of local codes to resolve to LOINC, SNOMED CT and RxNorm.
3–8 weeksFixed 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
2–5 weeks
The fastest useful thing you can ship. Mostly waiting on access, not building.
Data going both ways
6–12 weeks
Writing into a hospital's system needs their sign-off on testing. Budget for their time.
A full site — all four feeds
3–6 months
Each feed has its own testing and its own person at the hospital.
Each hospital after the first
+1–4 weeks
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.
Proof, not promises
Three We've Delivered.
Ageing connections
52 rebuilt, and nobody noticed
Moved onto one shared model in waves, with both paths running during each switchover. No interruption to care and no weekend outage.
52
connections
0
downtime
Many sites
Independent hospitals, kept in step
Facilities sharing no infrastructure and no vendor, with patient data consistent across all of them — reconciled continuously rather than overnight.
Live
not overnight
Multi
vendor
The high bar
Passed what hospitals test against
A server that cleared all 47 federal certification tests — the same bar software must meet to run inside a certified hospital system.
47/47
tests passed
First
submission
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. Nearly every hospital already sends it. That's the good news: connecting usually means asking their IT team to point an existing feed at you, not asking them to build something new.
Do we need HL7 or FHIR?
Usually whichever the hospital already offers, and often both. HL7 is what almost every hospital can switch on quickly, which makes it the fastest route to your first live customer. FHIR is newer and better suited to opening data up to partners and apps. It doesn't change what your product receives.
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?
It stays in your environment. Encrypted in transit and at rest, every access logged, built and tested against synthetic data rather than real records, and handled to your retention policy. We're ISO 27001 certified, go through client security reviews regularly, and will sign a BAA.
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.