Healthcare & Life Sciences

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.

What each of these areas covers

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.

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.

sequenceDiagram
    participant Pt as Patient
    participant Pr as Provider
    participant EHR as EHR and billing
    participant CH as Clearinghouse
    participant Py as Payer
    Pr->>Py: Eligibility enquiry
    Py-->>Pr: Coverage and patient share
    Pt->>Pr: Encounter and documentation
    EHR->>CH: Coded claim
    CH->>Py: Validated claim
    Py-->>CH: Remittance advice
    CH-->>EHR: Payment and denials
    EHR->>Pt: Bill for the remainder

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.

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.

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.

flowchart TD
    A[Incoming demographics] --> B[Block on surname and birth year]
    B --> C[Score candidate pairs]
    C --> D{Score above upper threshold}
    D -->|Yes| E[Auto link]
    D -->|No| F{Score above lower threshold}
    F -->|Yes| G[Manual review queue]
    F -->|No| H[Treat as new person]
    G --> E
    G --> H

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.

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:

MSH|^~\&|LAB|SITE1|EHR|SITE1|202607271345||ORU^R01|MSG00042|P|2.5.1
PID|1||MRN12345^^^SITE1^MR||SMITH^JANE^A||19780412|F
OBR|1||ACC998|24331-1^Lipid panel^LN
OBX|1|NM|2093-3^Cholesterol total^LN||212|mg/dL|<200|H|||F

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.

stateDiagram-v2
    [*] --> Assembled
    Assembled --> Rejected
    Assembled --> Submitted
    Rejected --> Assembled
    Submitted --> Denied
    Submitted --> PartiallyPaid
    Submitted --> Paid
    Denied --> Appealed
    Appealed --> Paid
    Appealed --> WrittenOff

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.