Healthcare software is built around a patient record nobody owns end to end, two interoperability standards that both refuse to die, a billing layer that pays for everything, and users who cannot be interrupted.
High demand19 min readHealthcare Integration Engineer, HL7/FHIR Interface Analyst, EHR Application Analyst, Clinical Informaticist, Revenue Cycle Systems Engineer, Computer Systems Validation EngineerUpdated 2026-07-27
Assumes you know: Comfort with REST APIs and JSON, Basic relational data modelling, Some exposure to message-based integration
Overview
What this area actually covers
Four things that only look like one: the clinical record and the systems that
create it, the movement of that record between organisations that do not trust
each other, the coding and claims layer that turns care into money, and the
regulated software lifecycle pharmaceutical and device companies work under.
Someone hired into "healthcare software" may spend a career in exactly one of
them.
Wrongly bundled in: clinical judgement, which is not yours, and consumer
wellness apps. The moment data crosses into a clinician's decision or a payer's
adjudication, everything below applies, and almost none of it applied before.
There is a structural fact worth absorbing before anything else, because it
explains most of what follows. In healthcare, the person receiving the service,
the person choosing it, the organisation delivering it and the organisation
paying for it are frequently four different parties with different interests
and separate systems. Almost every awkward part of the domain — prior
authorisation, eligibility checks, denials, consent, record fragmentation — is
a consequence of that separation rather than of anybody's bad engineering.
The section is divided into seven subsections. They are ordered roughly the way
data flows: the record is created, moved, acted on clinically, coded, billed,
protected, and — in life sciences — evidenced. Knowing which subsection a
question belongs to is most of the battle, because the same word means
different things in two of them. A "claim" in the coding subsection is a
document you assemble; a "claim" in the payer subsection is a case somebody
adjudicates.
Patient Records & Identity is the record model itself and the problem of
knowing who a record is about. It covers how an encounter, a problem list, an
allergy and a medication order relate to one another, and then the harder half:
the master patient index, the algorithms that decide two records describe the
same human, and what happens when a merge turns out to be wrong. It is a
separate area because identity is upstream of everything — a perfect claim
attached to the wrong person is worse than no claim. Open it for matching
strategies, merge and unmerge semantics, and the review queue every real
deployment ends up running.
Interoperability Standards is how records move between organisations. HL7
v2 for event-driven messaging inside and between hospitals, FHIR for modern
resource-oriented APIs, CDA and its constrained forms for documents that must
travel as a whole, and the integration engines that route and transform all of
it. It exists separately because standards conformance is a discipline of its
own: profiles, implementation guides, extensions and the negotiation between
two organisations about what an optional field will mean. Expect message
structures, mapping, and the honest arithmetic of what is lost in translation.
Clinical Workflows is what clinicians actually do with the system: placing
orders and receiving results, prescribing electronically, and the decision
support that fires alongside. Its defining problem is attention. The subsection
exists because a workflow that is technically correct and cognitively
intolerable will be worked around, and the workaround becomes the real system.
Read it for the orders-and-results loop, e-prescribing, and alert fatigue as an
engineering constraint rather than a user-experience complaint.
Coding & Billing turns documented care into billable items: assigning
diagnosis and procedure codes, capturing charges against a chargemaster, and
running the revenue cycle that follows. It is separate from claims because it
happens inside the provider organisation and is about accuracy and completeness
rather than negotiation. Open it for the code systems, charge capture, and why
a hospital employs people whose entire job is reading notes and choosing codes.
Claims & Payers is the negotiation with whoever is paying: checking
eligibility before care, obtaining prior authorisation for expensive things,
submitting claims, receiving adjudication decisions, and working denials. It
warrants its own area because it is genuinely adversarial — two organisations
applying different rules to the same facts — and because denial management is
where a provider's margin lives. Expect transaction formats, adjudication
outcomes, denial reason codes and the appeal loop.
Privacy & Security in Health is the obligation layer over all of the above:
what protected health information is, who may see it and on what basis,
minimum-necessary access, consent, and the audit trail that proves the rules
were kept. It is separate because it constrains design rather than adding
features, and because the constraints are unusually specific — certain
categories of record are separately regulated and must be segmented rather than
stored in one undifferentiated blob. Read it for access models, logging, and
what a breach obligation does to your architecture.
Life Sciences & Trials is the parallel world of pharmaceutical and device
companies: clinical trial data captured to submission standards, systems that
must be validated before use, and the evidence a regulated change requires. It
is here rather than elsewhere because the data is clinical and the regulators
overlap, but the daily work looks nothing like hospital IT. Open it for trial
data standards, validation, electronic records and signature rules, and what a
release pipeline must emit when "the tests passed" is not sufficient.
Subsection
What it is for
Patient Records & Identity
Knowing who this record is about, and modelling the record
Interoperability Standards
Moving records between systems that disagree
Clinical Workflows
Orders, results, prescribing, and not wasting attention
Coding & Billing
Turning documented care into billable, coded items
Claims & Payers
Getting paid, and arguing when you are not
Privacy & Security in Health
Who may see what, and proving it afterwards
Life Sciences & Trials
Regulated evidence for trials, devices and manufacturing
Where it sits in a real business
Follow one encounter. A patient arrives, and the first event is not clinical but
an eligibility check against the payer. The clinician documents the visit in the
electronic health record, in prose. Somebody — increasingly a coder assisted by
software — turns that prose into codes: a diagnosis in ICD-10 or ICD-11, a
procedure in CPT for US professional billing, drugs in RxNorm, lab results in
LOINC, clinical findings in SNOMED CT. Those codes become a claim, sent in the
US as an X12 837 transaction through a clearinghouse. The payer adjudicates and
returns an 835 remittance advice saying what was paid, what was denied and why.
Denials are reworked and resubmitted. For anything expensive the sequence
inverts, because prior authorisation must come before the service, and that
loop is where cost and clinician frustration concentrate.
Loading diagram…
The line to look at is the last one. The patient is billed after everyone
else has finished negotiating, sometimes months later, for an amount nobody
could quote at the time of care — which is why price transparency has been a
regulatory target and why patient-facing estimate tools are hard to build
honestly.
Where the money actually comes from
A provider organisation's revenue is not a price list. It is a set of
negotiated rates with each payer, applied to coded activity, reduced by
contractual adjustments, denials and the portion the patient owes but does not
pay. The same procedure carries a different amount from three payers, and the
list price on the chargemaster is a number almost nobody pays. Engineers arrive
expecting a catalogue and find a matrix of contracts.
For inpatient care in several systems the unit of payment is not the procedure
at all but a case grouping — the diagnosis-related group model, in which a
hospital receives a fixed amount for a category of admission regardless of how
long it took. That inverts the economics: under fee-for-service more activity
means more revenue, under a case rate more activity means less margin. Any
system you build sits inside one of those incentives, and it shows up in what
the business asks you to optimise.
Life sciences runs a parallel track
Life sciences runs at the same regulatory temperature but on a different
object. Trials structure captured data to CDISC standards for submission,
pharmacovigilance reports adverse events on statutory clocks with defined
severity thresholds, and the software controlling a manufacturing batch is part
of the regulated product rather than a tool used alongside it. The unit of work
is a study or a batch rather than a patient encounter, and the customer is
ultimately a regulator reading a submission.
The vocabulary of the first week
Healthcare is dense with acronyms, and people use them without pausing. These
are the ones most likely to appear in your first standup, with the meaning that
matters operationally rather than the expansion of the letters.
Term
What it means in practice
Encounter
One episode of care, and the object most things hang off
MRN
A patient identifier issued by one organisation, unique only there
MPI
The index that decides which records describe the same person
ADT
The message family announcing admission, discharge and transfer
Order and result
A request for a test or drug, and what came back
Chargemaster
The provider's internal price list, rarely what is paid
Eligibility
Whether this payer covers this patient today, checked up front
Prior authorisation
Payer approval required before the service is given
Adjudication
The payer deciding what it will pay and what it refuses
Denial
A refusal with a reason code, appealable within a clock
Remittance
The payer's explanation of what it paid, line by line
PHI
Health information that identifies a person; the regulated object
Break the glass
Emergency access granted now and reviewed afterwards
Terminology binding
Which code system a field's values must come from
Two of these mislead newcomers. Prior authorisation sounds like a
permission check and behaves like a distributed transaction with a party who
can say no, take days to answer, and change its mind. And a denial is not
an error: it is an expected outcome with a defined remedy, and a revenue cycle
team measures its denial rate the way a platform team measures error rate.
The code systems are a second vocabulary, and it helps to know what each is
for rather than memorising them. ICD codes describe what is wrong with the
patient. CPT and HCPCS describe what was done to them, for billing. SNOMED CT
describes clinical meaning richly enough to reason over. LOINC names the
observations a laboratory reports. RxNorm normalises drug names across the
several ways the same medicine can be written. A field bound to the wrong one
of these is a defect that will be found by a coder, not a test.
Who does this work
Integration engineers and interface analysts live in the message layer, between
an EHR and labs, radiology, pharmacy, billing and registries. The day is
operational: a broken interface means results are not reaching clinicians right
now. Much of the work happens inside an integration engine, where a channel
listens for messages, transforms them and forwards them, and where the skill is
diagnosing which of six hops dropped a message rather than writing new code.
EHR application analysts configure the vendor platform, often vendor-certified
because Epic and Oracle Health hold so much of the market. Clinical
informaticists sit between them and the clinicians, frequently being clinicians
part-time, and own whether a workflow is safe. Revenue cycle engineers own
claim generation and denial analytics. In life sciences, validation engineers
produce the evidence that a system does what its specification says.
Role
Where they sit
What ruins their week
Integration engineer
Between systems
A silent interface that stopped hours ago
EHR application analyst
Inside the vendor product
An upgrade that resets local configuration
Clinical informaticist
Between clinicians and IT
A safe workflow nobody will follow
Revenue cycle engineer
Claims and denials
A payer changing an edit without notice
Validation engineer
Regulated change control
Evidence that does not trace to a requirement
The population you must not ignore is clinical staff, who are users in a sense
software people rarely encounter: they cannot pause, cannot retry later, and
are held professionally accountable for decisions your system informed. A
design review that has not been walked through by someone who does the job is
not a design review.
Demand, adoption and how that is changing
Demand is high and unusually insulated from tech cycles, because most of it is
created by regulation rather than discretionary spend. In the US, the 21st
Century Cures Act and the certification and information-blocking rules
implementing it require certified health IT to expose standard patient-facing
APIs, and those APIs are FHIR. A hospital cannot decide interoperability is not
this year's priority.
EHR consolidation moves where the jobs are rather than reducing them: fewer
organisations build a record system, far more build around one. The employer
base is therefore lopsided towards integration, configuration and analytics
rather than green-field product work, and job titles reflect vendor ecosystems
more than in most domains.
Two live shifts are worth tracking. The first is payer-side interoperability:
rules requiring payers to expose FHIR interfaces for coverage, claims history
and eventually prior authorisation are pulling standards work out of hospitals
and into insurers, which historically ran on batch file exchange. The second is
ambient documentation and coding assistance, the clearest place language models
have entered clinical operations. The interesting engineering there is not the
model but the accountability wrapper: attribution of every generated line,
clinician review before anything is signed, and an audit trail that survives a
later dispute about what was documented and by whom.
What makes it hard
Identity is probabilistic. Several countries issue a national health
identifier, so matching is a lookup. The US does not: an appropriations
restriction has long kept the federal government from establishing one, so each
organisation runs its own master patient index and matches on hand-typed names,
dates of birth and addresses. A false negative splits one person into two
charts, and a clinician sees half a history and misses an allergy. A false
positive merges two people, and a clinician sees someone else's result —
irreversibly, once downstream claims have copied the merged identifier. No
threshold makes both errors vanish, so real deployments keep a review queue and
automate merging only on a narrow high-confidence path.
Loading diagram…
The part to look at is the middle band. Everything between the two thresholds
is human work, and the width of that band is a business decision about how many
staff you can afford versus how much risk you will carry. Narrow it and errors
go into the record; widen it and the queue never empties.
Two interoperability standards coexist, permanently. HL7 v2 is a
pipe-and-caret delimited messaging standard, organised into segments and
triggered by events such as an admission or a lab result. It dates from the
late 1980s and is still everywhere. Most of its fields are optional and many
are locally defined, so conformance is partial by design and every interface is
negotiated between two organisations. FHIR is HL7's modern answer: resources
such as Patient, Encounter and Observation as REST endpoints with JSON
payloads, constrained per jurisdiction by implementation guides, secured for
third-party apps by the SMART on FHIR OAuth 2 profiles. It is better for
anything new, and it does not displace v2 inside a hospital, because a working
interface engine has no business case for rewriting. So: v2 for internal
event-driven plumbing, FHIR at the boundary where patients and apps read. You
translate, lossily.
HL7 v2
FHIR R4
Where it gets lossy
PID-3 identifiers
Patient.identifier
v2 type codes rarely map to a system URI
ADT^A01 admit
Encounter status, period
FHIR holds state, v2 holds a transition
OBX-3 / OBX-5
Observation.code / value[x]
Local codes need manual LOINC mapping; v2 is weakly typed
MSH-9 trigger event
No direct equivalent
Intent is in the message type, not the resource
Z-segments
Extensions
Local meaning, agreed bilaterally, undocumented
The last two rows are where interface projects overrun. A Z segment is a
locally defined extension that means whatever two organisations decided it
means, usually in a conversation nobody wrote down, and every hospital has
them.
A v2 message is worth seeing once, because its shape explains the standard's
attitude to structure:
Three things in that fragment are the whole standard in miniature. The fields
are positional, so a missing value still occupies its place. The identifier in
PID-3 carries an assigning authority, because the same number means different
people at different sites. And the H flag on the last line is an
interpretation supplied by the sender, which a receiving system must not
recompute against its own reference range.
Interrupting a clinician has a price. Someone using a record system
mid-consultation has a person in front of them and a queue behind them. A modal
dialog, a slow save, an extra click across a shift, an alert firing on an
interaction that is fine in this context: each has a cost, and alerts that are
usually wrong train people to dismiss alerts including the correct one. Hence
decision support fired where the decision is made rather than as an
interruption, and hence "we will add a warning" often being the wrong answer
rather than the safe one. The useful discipline is to ask, for any proposed
alert, what the clinician is expected to do differently, and what proportion
of firings will be ones where they should. If you cannot answer the second
question, you are building noise.
Getting paid is an adversarial protocol. A claim is not a request that
succeeds or fails; it is an opening position in a process with defined moves.
It can be rejected before adjudication for a format or eligibility problem,
denied after adjudication with a reason code, paid in part, or paid and later
recouped. Each outcome has a different remedy and a different clock.
Loading diagram…
The loop from Rejected back to Assembled is the cheap one, caught by a
scrubber before the claim ever leaves. The loop through Appealed is the
expensive one, involving staff time and often clinical documentation, which is
why every dollar spent on pre-submission edits is worth several spent on
appeals.
Privacy regimes are design inputs. HIPAA's Privacy, Security and Breach
Notification Rules define who may hold protected health information, on what
basis, and how a breach is disclosed; minimum-necessary argues against the wide
internal access most systems drift toward. GDPR treats health data as
special-category data needing a distinct lawful basis, and its erasure rights
collide with records that must be retained. So: every read logged, "break the
glass" access reviewed afterwards, authorisation by relationship to the patient
rather than role alone, and separately-regulated categories such as substance
use disorder treatment segmented rather than left in one blob.
Two practical consequences catch teams out. The first is that vendors and
subcontractors who touch this data are inside the obligation, not outside it,
which is why a contractual data-protection agreement is a prerequisite to
integration rather than a legal formality after go-live. The second is
de-identification: analytics teams routinely want "anonymised" data, but the
recognised routes to it are specific — removing a defined set of identifiers,
or a documented expert assessment that re-identification risk is very small —
and neither is satisfied by dropping the name column.
A change needs evidence. In life sciences, and for software that is itself
a medical device, a change is not done when the tests pass. It is done when
signed evidence exists that the requirement was specified, reviewed,
implemented, tested against that specification and approved, with the audit
trail intact and electronic signature rules satisfied — the expectations behind
GxP, computer system validation, and regulations such as FDA 21 CFR Part 11 and
its EU equivalent. Risk-based iterative approaches are supported and have
gained ground, so effort is meant to concentrate where patient risk is highest
rather than being spread evenly. But this still changes what a pipeline emits:
traceability from requirement to test result, immutable audit trails, and no
route to production that skips the evidence.
Why study it
Study it if you want domain depth that compounds. Healthcare knowledge ages
slowly, transfers between employers, and is hard to acquire accidentally, so an
engineer who understands identity resolution, claims and FHIR is genuinely
scarce. The scarcity is real rather than rhetorical: the standards are public
and free to read, and most engineers still never read them.
There is also a specific technical case. This domain is an unusually good
teacher of two things that are hard to learn elsewhere. One is designing
against a standard you do not control and cannot change, where the correct
answer is often "conform, and handle the ambiguity", not "improve the schema".
The other is building systems where the audit trail is a feature rather than
an afterthought, which transfers to finance, legal technology and anything
touching safety.
Do not study it if you want the fastest route to a high-leverage general
engineering career. Release cycles are slower and the most interesting problem
in the room is often organisational. If you are drawn to greenfield distributed
systems, much of your time goes on other people's twenty-year-old interfaces,
and if audit reads as bureaucracy rather than as what makes a system
trustworthy you will be unhappy.
Your first hour
# Public FHIR R4 test server: fetch a patient, then that patient's observations.
curl -s "https://hapi.fhir.org/baseR4/Patient?name=smith&_count=1" \
-H "Accept: application/fhir+json"
curl -s "https://hapi.fhir.org/baseR4/Observation?subject=Patient/PUT_ID_HERE" \
-H "Accept: application/fhir+json"
Find three things in the response: how many identifiers one patient carries in
identifier, that name is a list rather than a string, and an
Observation.code.coding entry with its system URI. Then find any HL7 v2
ADT^A01 sample message and line its PID fields up against the Patient
elements you just read.
The artefact is a mapping table of your own, shaped like the one above, with a
fourth column you fill in yourself: what a receiving system would get wrong if
this field were missing.
If you have a second hour, do the identity exercise, because it is the one that
changes how people think. Write twenty pairs of patient demographics by hand,
including a married surname change, a transposed birth date, a nickname, a
shared address between two family members with the same first initial, and one
genuine pair of twins. Score each pair however you like — exact match on some
fields, fuzzy on others — then pick your two thresholds and see how many pairs
land in the review band. Write down, in one line each, what happens clinically
if you get each of your errors wrong. That single page is a better answer to a
matching question than any algorithm name.
What this is not
It is not medical knowledge. You acquire a working vocabulary, and should never
mistake that for clinical competence. The correct posture in a room with
clinicians is to be extremely precise about what your system does and
completely deferential about what it means.
It is not HIPAA-as-a-checklist: the privacy rules are constraints on data
model, access control and logging, cheapest to satisfy when they shape the
design. Nor are they the only regime you will meet — a system operating in more
than one country carries more than one set of obligations, and they do not
agree with each other about erasure.
And it is not FHIR alone. Candidates who have read the specification and
nothing else underestimate how much production traffic is still HL7 v2, how
much of the record still moves as documents rather than resources, and how much
engineering headcount sits in coding, claims and prior authorisation rather
than in the clinical record at all.
The two things that will surprise you are that identity is probabilistic and
that the older standard is not going away.