Healthcare and life sciences fundamentals

A patient is a person about whom clinical facts are recorded, and the awkwardness is that the concept is defined by the record rather than by the person. Every organisation that treats someone creates its own patient entity with its own identifier, so one human being routinely exists as a dozen patients across a region and several within a single hospital that has merged with others. Nothing in the data announces that they are the same. The consequence for design is that "patient" is two different things — a local record you own and control, and a person you can only ever approximate through matching — and code that conflates them will eventually attach a result to the wrong human. Keeping the local identity and the resolved identity as separate fields is the cheapest defence.

An encounter is one interaction between a patient and the care system: an outpatient appointment, an inpatient stay, an emergency attendance, a telephone consultation. It matters because it is the hook almost everything else attaches to — the observations taken, the orders placed, the notes written, the diagnoses recorded, the charges generated. Its lifecycle is a small state machine of planned, arrived, in progress, finished and cancelled, and the transitions are what other systems are told about. The design consequence is that an encounter's boundaries decide what a report counts. If an inpatient stay is modelled as one encounter with internal transfers, the ward-level view has to be derived; if each ward is its own encounter, the length of stay has to be assembled.

An episode of care groups the encounters that belong to one clinical problem over time — a pregnancy, a cancer pathway, a course of physiotherapy — so that care delivered across months and departments can be reasoned about as one thing. An encounter is a contact; an episode is a purpose. The distinction is where outcome measurement and pathway analytics live, because a hospital wanting to know whether treatment worked is asking about the episode, not about Tuesday's appointment. It is also the entity most often missing from a schema, since encounters arrive naturally from operational messages while episodes have to be constructed deliberately. Adding them later means inferring groupings from dates and diagnosis codes, which is guesswork with clinical consequences.

A medical record number is an identifier issued by one organisation, unique within that organisation and meaningless outside it. Two hospitals can issue the same digits to different people, and one person carries different numbers at every site they have attended. This is why every identifier in a health message carries an assigning authority alongside the value: the pair is the identity, not the number. Systems that store an MRN as a bare string, or use it as a primary key in a regional aggregation, produce collisions that look like one patient with contradictory history. The correct model is a set of identifiers per patient, each qualified by its issuing system and type, with your own internal key that no external party ever sees.

A master patient index is the service that decides which source records describe the same person. It holds demographic attributes gathered from every contributing system, the links it has asserted between records, a confidence or score for each link, and the history of how those links came to exist. It is deliberately not the clinical record: it resolves identity and points at the systems that hold the data. What makes it a system rather than a table is everything around the matching — a review queue for the ambiguous cases, an audit trail of who confirmed each link, and the ability to reverse a decision. Treating it as a lookup rather than as a workflow is the mistake that leaves an organisation unable to correct its own errors.

Matching is easy to describe and hard to do, and the reason becomes obvious the moment two real records are put side by side.

                 Record A  (site 1, MRN 884120)   Record B  (site 2, MRN 55019)
---------------  ---------------------------      ----------------------------
Surname          O'Brien                          Obrien
Given name       Katherine                        Kate
Date of birth    1981-06-04                       1981-04-06
Sex              F                                F
Postcode         M14 5QT                          M14 5QT
Address line     Flat 2, 14 Elm Road              14 Elm Rd
Phone            07700 900412                     07700 900412
NHS number       (absent)                         999 999 9999

Every difference has an innocent explanation and a sinister one. The apostrophe is a data-entry convention. Kate is a diminutive, not a different name. The birth date is a day-month transposition — or two people born two months apart. The shared postcode and phone could be one person, or a mother and daughter with the same initial. Nothing here is a typo you can safely normalise away.

Deterministic matching applies rules: agree exactly on a trusted identifier, or on surname plus date of birth plus postcode, and link. It is explainable, cheap and auditable, and it fails on exactly the record above, because no rule survives the transposed date. Its failure mode is the false negative — one person split into two charts, each holding half the allergies.

Probabilistic matching scores each field's agreement by how much evidence it carries, using the frequency of the value: agreement on a rare surname is worth far more than agreement on Smith, and agreement on a shared household phone is worth less than it looks. The scores combine into a weight, and two thresholds define auto-link, human review and no-link. Its failure mode is the false positive at the top of the band — two records merged that were never the same person.

The number worth quoting is the width of the review band, because it is a staffing decision rather than an algorithm choice. Narrowing it pushes errors into the record silently; widening it produces a queue that never empties. And the two errors are not symmetrical: a split chart hides history, while a wrong merge actively shows one patient another's results, which is why production systems auto-link only on a narrow, high-confidence path.

Because a national identifier turns identity into a lookup, and its absence turns it into inference over hand-typed demographics. Several countries issue one and mandate its use, so matching is largely solved and the remaining work is validating the check digit and handling the newborn who does not have one yet. In jurisdictions without one — most notably the United States, where an appropriations restriction has long blocked a federal identifier — every organisation runs its own index over names, dates of birth and addresses, all of which change, are misheard and are mistyped. The engineering consequence is that identity becomes a probabilistic subsystem with its own error rates, review staff and safety implications, rather than a foreign key.

You discover that unmerging is not the inverse of merging. Once two records are combined, downstream systems have copied the surviving identifier into orders, results, claims, appointment letters and their own local caches, and each of those copies has to be found and corrected. Clinical documents already contain both patients' data interleaved, so separating them requires clinical judgement about which observation belonged to whom. That is why mature implementations treat a merge as a reversible assertion rather than a destructive update: both source records survive, the link is an entity with an author and a timestamp, and the merged view is computed. Designing for reversal from the start is substantially cheaper than the alternative, which is a manual, clinically supervised data-repair project.

This is the message family that still carries most traffic inside a hospital, and reading one is a hiring filter of its own.

MSH|^~\&|LAB7|SITE1|EHR|SITE1|20260727134502||ORU^R01|MSG00042|P|2.5.1
PID|1||MRN884120^^^SITE1^MR~9999999999^^^NHS^NI||OBRIEN^KATHERINE^A||19810604|F
PV1|1|I|WARD3^BAY2^BED4||||G1234^HUGHES^SARAH
OBR|1|ORD5581|ACC998|24331-1^Lipid panel^LN|||20260727120000
OBX|1|NM|14647-2^Cholesterol total^LN||6.9|mmol/L|<5.0|H|||F
OBX|2|NM|14927-8^Triglycerides^LN||2.1|mmol/L|<1.7|H|||F
NTE|1||Sample slightly haemolysed

MSH is the envelope: the delimiters it declares in its second field, the sending and receiving application and facility, the timestamp, the trigger event ORU^R01 meaning "unsolicited result", a control identifier for acknowledgement, and the version. Everything routeable is here, which is why an integration engine can move a message without understanding its contents.

PID is the patient. The repeat separator ~ in field three carries two identifiers, each with its assigning authority and type — the local MRN and the national number — which is the standard admitting that no single number identifies a person. PV1 is the visit: patient class I for inpatient, the location as a three-part composite, and the responsible clinician.

OBR is the order the results answer, carrying both the placer's number and the filler's accession number, because matching a result to its order across two systems is the whole problem. Each OBX is one observation: value type, the LOINC code identifying what was measured, the value, units, the reference range, an abnormal flag and a result status. NTE is free text attached to the segment above it.

Three properties are the standard in miniature. Fields are positional, so a missing value still occupies its place and an off-by-one in a parser silently shifts every field after it. The abnormal flag H is the sender's interpretation against the sender's reference range, and a receiver must not recompute it against its own. And most fields are optional, so conformance is partial by design and every interface is a bilateral agreement about which optional fields will actually be populated.

The same cholesterol result, expressed the way a modern API would return it.

{
  "resourceType": "Observation",
  "id": "obs-8841-1",
  "status": "final",
  "category": [{ "coding": [{ "code": "laboratory" }] }],
  "code": {
    "coding": [{
      "system": "http://loinc.org",
      "code": "14647-2",
      "display": "Cholesterol [Moles/volume] in Serum or Plasma"
    }]
  },
  "subject":   { "reference": "Patient/884120" },
  "encounter": { "reference": "Encounter/ward3-2026-07" },
  "effectiveDateTime": "2026-07-27T12:00:00Z",
  "performer": [{ "reference": "Organization/lab7" }],
  "valueQuantity": {
    "value": 6.9, "unit": "mmol/L",
    "system": "http://unitsofmeasure.org", "code": "mmol/L"
  },
  "interpretation": [{ "coding": [{ "code": "H", "display": "High" }] }],
  "referenceRange": [{ "high": { "value": 5.0, "unit": "mmol/L" } }]
}

Every value now carries the code system it came from as a URI, so 14647-2 is unambiguously LOINC rather than "whatever the sender meant". Units are bound to a standard unit code system rather than being a free-text string. The patient and the encounter are references to addressable resources you can fetch, which turns a message into a graph you can traverse.

The tradeoff has three parts, and naming them is what separates someone who has integrated FHIR from someone who has read about it. First, the message became roughly six times larger for the same clinical content, and a busy hospital sends millions of results a day. Second, the event is gone: ORU^R01 said "a result has arrived", while the resource merely describes a state, so notification becomes a separate concern handled by subscriptions or polling. Third, the references only work if both ends agree on identity — Patient/884120 is resolvable in your server and meaningless in mine.

The practical consequence is that the two standards are good at different jobs. HL7 v2 is a compact, event-driven notification format; FHIR is a queryable representation of state. Translating between them is not a syntax exercise, because the intent carried by a v2 trigger event has no direct home in a resource, and a Z-segment's locally agreed meaning has to become an extension somebody documents.

Because there was never a business case for the rewrite. A hospital's v2 interfaces work, carry life-critical traffic, and were paid for years ago; replacing one costs money, consumes scarce integration staff and introduces risk in exchange for no new clinical capability. The installed estate is also not just the EHR — it is the laboratory analyser, the radiology modality worklist, the pharmacy robot and the twenty-year-old departmental system whose vendor no longer exists. So the pattern that actually emerged is layered: v2 for internal event-driven plumbing, FHIR at the boundary where patients, apps and other organisations read. Expect to translate between them for your whole career, and expect the translation to be where the interesting defects live.

A clinical document is a signed, human-readable, self-contained artefact — typically a discharge summary, a referral letter or a care summary — carrying structured entries inside a narrative that a clinician can read without your software. The point is attestation: somebody clinically responsible signed this whole thing at a point in time, and it must travel and be stored as a unit. That is why documents survive alongside resource APIs. When a receiving organisation needs to know what was communicated and who stands behind it, a bundle of independently updatable resources is the wrong shape, because it has no author, no boundary and no version anybody signed. The cost is that documents are duplicative and awkward to query, which is why both models coexist.

Because the base specification makes almost everything optional and permits extension, so two conformant servers can be mutually unusable. An implementation guide constrains that: it profiles resources to say which elements are mandatory, which code systems a field must draw from, which search parameters must be supported and which extensions carry local meaning. National guides do this for a jurisdiction, and a project layers its own on top. The engineering consequence is that the useful question is never "do you support FHIR" but "which version, which guide, and which profiles are you conformant against". Conformance can be tested mechanically against the profiles, which is the main practical advantage over v2's bilateral negotiation by email.

An authorisation and launch model, which is the part the data specification deliberately leaves out. It layers OAuth 2 and OpenID Connect over FHIR with scopes expressed in clinical terms — read this resource type, for this patient, for this user — plus a launch sequence that lets an app be opened from inside an EHR with the current patient and encounter context handed to it. That combination is what makes third-party clinical apps possible without each vendor inventing its own integration. Its significance for design is that it makes the consent and scope decision explicit and machine-readable, so an app receives the minimum necessary rather than a session with the launching clinician's full rights.

They specify how existing standards are combined to accomplish a named real-world task, which is the gap standards themselves leave. A standard tells you what a message may contain; a profile tells you which actors exist, which transactions pass between them, and in what order, for something like publishing a document to a regional registry, finding a patient's documents, or synchronising clocks across devices so that timestamps are comparable. The value is that two vendors can claim conformance to the same profile and actually interoperate, and there is a formal testing process behind it. In an interview, knowing that profiles exist at the level of workflow rather than payload is enough — being able to name a few registry and repository patterns is a bonus.

It is the message broker and transformation layer sitting between clinical systems: channels that listen on a port or a directory, parse a message, transform it, route it to one or more destinations, and record what happened. Every hospital has one, and much integration work is configuring it rather than writing services. What it hides is the fact that a single logical event fans out to a dozen consumers with slightly different requirements, each negotiated separately. That concentration is also the risk: the engine becomes a single point of failure holding undocumented business logic in transformation scripts, and the characteristic incident is a channel that quietly stopped hours ago while every dashboard stayed green because nothing errored.

DICOM is both a file format and a network protocol for medical images, and its defining feature is that the pixel data and the metadata are one object: a study carries the patient, the accession number, the modality, the acquisition parameters and the images together. The workflow is distinctive too, since a modality pulls its worklist from the system rather than being sent an order, and images are stored to an archive that other systems query. What makes imaging different for engineers is scale and latency: a single study is hundreds of megabytes, a radiologist expects it to open immediately, and the archive is retained for years or decades under statutory rules.

Nothing else in a health system produces data at this rate, so the arithmetic changes the architecture rather than just the invoice.

Per-study sizes, uncompressed
  Plain radiograph   2 images  x 2048 x 2500 x 2 bytes   ~ 20 MB
  CT                 500 slices x 512 x 512 x 2 bytes    ~ 256 MB
  MR                 300 images x 256 x 256 x 2 bytes    ~ 38 MB
  Tomosynthesis      4 views, many projections           ~ 1,000 MB

Daily volume for a mid-sized department
  120 radiographs  x  20 MB   =   2,400 MB
   40 CT           x 256 MB   =  10,240 MB
   15 MR           x  38 MB   =     570 MB
   10 tomo         x 1000 MB  =  10,000 MB
                              ------------
  per working day                23,210 MB  ~ 23 GB

  250 working days             ~ 5.8 TB per year
  two copies for resilience    ~ 11.6 TB per year
  8-year retention             ~ 93 TB, growing

Read the tomosynthesis row first. Ten studies a day produce as much data as forty CTs, so a single new modality can double a department's storage growth without changing the patient numbers at all. Capacity planning that extrapolates from study counts rather than from bytes per modality will be wrong by a factor.

The second reading is that retention is not yours to choose. Imaging retention is set by regulation and professional guidance, commonly several years for adults and until well into adulthood for children, so the archive only grows and deletion is a compliance decision rather than a housekeeping one. That is what makes tiering the actual design work: recent studies on fast storage for reporting, older studies on cheap storage with a retrieval delay, and a prefetch triggered by tomorrow's appointment list so a radiologist never waits.

The third point is that compression is a clinical decision, not an engineering one. Lossless compression is uncontroversial and buys perhaps a factor of two or three. Lossy compression buys far more and requires a documented clinical position on diagnostic acceptability per modality, which is a conversation with radiologists rather than a configuration flag.

The reason healthcare integration is hard is visible in one journey: no single system owns it, and each handoff is a different technology negotiated with a different party.

flowchart TD
    G[Referral from primary care<br/>e-referral message] --> R[Registration<br/>MPI match or create]
    R --> A[Admission<br/>HL7 v2 ADT event]
    A --> O[Orders to lab and imaging<br/>order message and DICOM worklist]
    O --> S[Results returned<br/>result message and image store]
    S --> D[Discharge summary<br/>signed clinical document]
    D --> B[Coding and claim<br/>batch file to the payer]
    D --> P[Patient and app access<br/>FHIR API]

The first two boxes carry most of the risk. A referral arrives with demographics typed by somebody else, and registration must decide whether this is a person already known. Every downstream box inherits that decision, so an identity error here becomes a wrong result, a wrong summary and a wrong claim, and each of those looks like a separate defect to whoever receives it.

The handoff from orders to results is where messages are lost, because it is the only place in the diagram where two systems must correlate a reply with a request across an organisational boundary. The order carries the placer's identifier and the result carries both that and the filler's, and an interface that matches on anything else — patient plus test plus approximate time — will eventually file a result to the wrong encounter.

Discharge fans out to two very different consumers. The billing path tolerates batch latency and cares about completeness of coding. The patient-facing path cares about immediacy and about not disclosing something the patient should hear from a clinician first, which is a genuine design constraint rather than paternalism, and one that information-access rules have deliberately narrowed.

The absent box is the one candidates never mention: nothing here tells primary care what happened. Closing that loop — the discharge summary actually reaching and being acknowledged by the referrer — is where continuity of care breaks, and "fire and forget" is not an acceptable delivery model for it.

The orders-and-results loop is the highest-volume clinical workflow in a hospital, and its correctness rests on one identifier.

sequenceDiagram
    participant C as Clinician
    participant E as EHR
    participant I as Integration engine
    participant L as Laboratory system
    C->>E: Place order with indication and priority
    E->>I: Order message carrying placer order number
    I->>L: Order, mapped to the local test code
    L-->>I: Acknowledgement with filler order number
    L->>I: Result with value, units and abnormal flag
    I->>E: Result matched on placer order number
    E-->>C: Result in the inbox, marked unread

The acknowledgement on line four is the line candidates omit, and it is the difference between a reliable interface and a hopeful one. Without it the EHR cannot distinguish "the laboratory has this order" from "the message went into a void", and the failure is silent: no error is raised anywhere while a test is simply never performed. Reconciling outstanding orders without acknowledgements is a standing operational report, not an edge case.

The mapping step hides the second failure mode. The ordering system's test code and the laboratory's are different vocabularies, maintained by different people, and a new test added at the laboratory without a corresponding mapping produces results the EHR cannot file. Those land in an exception queue, which is fine, and are then invisible to the clinician, which is not.

The last line is the safety-critical one. A result that arrives correctly and is never read is clinically identical to a result that never arrived, which is why the requirement is not delivery but acknowledged review by a named clinician, with escalation when an abnormal result stays unread. Designing for that means results have a state machine and an owner, not just a timestamp.

A referral is one clinician asking another service to take on part of a patient's care, and it is a stateful conversation rather than a message: it can be accepted, rejected, returned for more information, redirected to a different service, or booked. Failures are almost always about the loop rather than the transmission. The referrer does not learn that the referral was rejected, so the patient waits for an appointment nobody is arranging. Or it is accepted with insufficient clinical information and triaged wrongly. The engineering consequence is that a referral needs an explicit status visible to both parties and a timer, because the harm here is caused by silence rather than by an error anybody could see.

Because responsibility transfers between organisations at exactly the moment information is least complete. Medications have been changed during the stay, some tests are still pending, follow-up has been requested but not booked, and the receiving clinician was not present for any of it. A discharge summary that arrives days late, omits the medication changes, or lists results without saying who is chasing the outstanding ones creates a gap nobody owns. The engineering requirements that follow are concrete: medication reconciliation as a structured comparison rather than free text, explicit ownership of every pending result, and delivery of the summary that is acknowledged rather than assumed.

A care pathway is the expected sequence of assessments, interventions and decision points for a condition, used both to guide care and to measure whether it happened. It is hard to model because it is a guideline rather than a workflow: clinicians deviate for good reasons, several pathways apply to one patient at once, and the pathway itself is revised as evidence changes. A system that enforces the pathway will be worked around, and the workaround becomes the real record. The pattern that works is to represent the pathway as an expectation against which actual events are compared, surfacing variance for review rather than blocking it, and to version the pathway so an audit can ask what the guidance was at the time.

Not slot availability, which is the part that looks like the problem. The real constraints are that several scarce resources must coincide — a suitably qualified clinician, a room, a device, an interpreter, sometimes a preparatory test whose result must exist first — and that many of them are shared with other services. Layered on top are clinical ordering rules, maximum waiting times with regulatory or contractual force, patient preference and transport, and a no-show rate high enough that overbooking is a deliberate policy. So scheduling is a constraint-satisfaction problem with a fairness dimension, and a design that models it as a calendar with free slots will be rebuilt within a year.

It means the legally significant version of the clinical record lives there, and anything you build is integrating around it rather than replacing part of it. Practically, three things follow. You will rarely own the write path for clinical data, so your system's job is often to compute something and hand it back in a form the record can hold and attribute. Your data is a copy, which raises the questions of staleness and of what happens when the record is corrected after you read it. And the vendor's data model and extension points bound your design, so "we will just add a field" is a configuration negotiation with the platform team. Candidates who assume greenfield ownership of clinical data misjudge most of the work.

It is a clinical terminology designed for meaning rather than counting: a very large set of concepts with defined relationships, so that a concept has parents, children and attributes a machine can reason over. That structure is the point. Recording a finding as a SNOMED concept lets a query for "any diabetes" retrieve every subtype without enumerating them, because the hierarchy already knows. It also supports post-coordination, combining concepts to express something not pre-defined, which is expressive and makes storage and comparison harder. Its cost is size and rate of change: it needs a terminology server rather than a lookup table, and content is released regularly, so your data records concepts whose interpretation is version-dependent.

Each answers a different question, and using one where another belongs is a defect a coder will find rather than a test. ICD classifies diagnoses for statistics and reimbursement, which is why it is a classification with residual "unspecified" categories rather than a rich terminology. LOINC names observations — which test was performed on what specimen, reported in what form — so it labels the question a result answers rather than the answer. RxNorm normalises medicines across brand and generic naming in the United States, and dm+d does the equivalent job for the United Kingdom, distinguishing the virtual product from the actual pack dispensed. The recurring interview point is that a field's meaning is fixed by the code system bound to it.

Mapping is presented as plumbing and is actually where clinical meaning quietly disappears.

Source: SNOMED CT, recorded by the clinician
  concept 24003006   Closed fracture of neck of left femur
  laterality         left
  qualifier          closed
  site               neck of femur

Target: WHO ICD-10, required for the national statistics return
  S72.0              Fracture of neck of femur

What did not survive
  laterality         WHO ICD-10 carries no laterality at all
  open or closed     expressible only through an optional fifth
                     character that most national returns do not collect

Reverse mapping S72.0 back to SNOMED
  candidates         at least 6 concepts, differing in laterality and closure
  correct answer     unknowable from the target code alone

Name the variant before you claim anything is lost, because the variants differ. The block above is WHO ICD-10, the base classification used for statistical returns. ICD-10-CM, the United States clinical modification used for billing, would keep both of the attributes listed: S72.002 encodes the left side, S72.001 the right, and a mandatory seventh character carries the encounter and the open-or-closed distinction, so the full-fidelity code here is S72.002A. Which variant sits on the other end of the map decides how much specificity you actually lose, and it is the first question to ask of any mapping specification.

The asymmetry is the whole lesson. Forward mapping is lossy and deterministic; reverse mapping is one-to-many and therefore a guess. A pipeline that stores only the mapped code has destroyed information the original capture contained, and no later enrichment can recover it. The rule that follows is to persist the source coding alongside the target and treat the mapping as a derived view.

The clinical consequence is not abstract. If the operating list is generated from the mapped code, laterality has been lost from the record that reaches theatre, and wrong-side surgery is a recognised never-event. This is why mappings intended for reimbursement must not be reused for clinical decision support, even though the codes look interchangeable in a schema.

The second detail candidates miss is that maps are versioned and maintained by someone else. Both terminologies release regularly, the map between them lags, and a concept that was mapped last year may map differently or not at all this year. So a map is a dated artefact: record which version produced each mapped value, or an audit cannot reconstruct why a historic claim was coded as it was.

A binding declares which code system, and often which subset of it, a field's values must be drawn from, and how strictly. It is the difference between a field that can be validated and a field that accumulates whatever each interface happened to send. The cost of getting it wrong compounds: values from two systems sharing the same short code are indistinguishable, queries silently miss rows, and decision support that keys on a code fires for the wrong concept. The enforcement point matters as much as the declaration, because a binding checked only in the user interface is bypassed by every integration. Validating against a terminology server at ingest, and rejecting rather than storing unmapped codes, is the version that holds.

Structured data is coded into defined fields — a diagnosis as a concept, a result as a number with units — so it can be queried, aggregated and reasoned over. Unstructured data is the narrative: the clinician's account of what happened, why a decision was made and what was uncertain. Most of the clinically important content is in the narrative, because structure is expensive to capture at the point of care and cannot represent nuance. That is the permanent tension: every request for more structured data is a request for more clinician keystrokes during a consultation. Extraction from narrative is therefore attractive and carries its own obligation, since a derived code needs provenance, a confidence and clinician review before it is treated as fact.

It is health information that identifies a person, or could with what else is available, which sweeps in appointment times, ward locations, device identifiers and the fact of an attendance as well as diagnoses. Minimum necessary is the principle that each use discloses no more than the purpose requires, and its code consequence is that role-wide access to a whole record is usually the wrong default. What it pushes towards is purpose-scoped access — this API surface for scheduling sees demographics and appointment times but no diagnoses — plus field-level rather than record-level authorisation, and separate treatment of categories that carry extra statutory protection. Design at that granularity is substantially harder to add later than to build in.

Consent becomes tractable once it is a matrix rather than a flag, and the matrix is the artefact a design review can actually argue about.

                      direct   related    population   commercial   patient's
data category         care     research   statistics   research     own app
--------------------  -------  ---------  -----------  -----------  ---------
Demographics          allow    allow      allow        pseudonym    allow
Encounters, diagnoses allow    consent    pseudonym    deny         allow
Medications           allow    consent    pseudonym    deny         allow
Laboratory results    allow    consent    pseudonym    deny         allow
Imaging               allow    consent    deny         deny         allow
Mental health notes   allow*   consent    deny         deny         allow*
Sexual health         consent  consent    deny         deny         allow
Substance use         consent  consent    deny         deny         allow
Genomic data          allow    consent    deny         consent      allow

allow      permitted on the basis of providing care, still logged
consent    requires a recorded, purpose-specific consent event
pseudonym  permitted only with identifiers removed under a documented process
deny       not permitted by any consent this system can capture
allow*     permitted, but withheld from the default view and released
           on a deliberate action that is recorded

The rows that are not uniform are the point. Several categories are separately regulated — mental health, sexual health, substance use treatment and genomic data recur across jurisdictions — which means they cannot live in one undifferentiated clinical blob if you intend to honour a restriction on them. Retrofitting category-level segmentation onto a schema that stored everything as observations is a migration, not a feature.

The deny column matters as much as the allow column. Deciding in advance that no consent this system captures permits a commercial disclosure means the answer to a later request is a design fact rather than an argument, and it prevents the common drift where an existing consent is stretched to cover a new purpose.

Two details separate a real model from a diagram. Consent is a versioned, append-only event carrying the subject, the purpose, the wording shown and the timestamp, because the obligation is to demonstrate valid consent rather than to know its current value. And withdrawal must propagate to every derived copy — the research extract, the warehouse, the vendor's system — since the copy that keeps processing is the one that becomes the breach.

Opt-in means no sharing until the patient positively agrees, which gives the strongest defensibility and the lowest coverage, so a shared record built on it is often empty when it is most needed. Opt-out means sharing is the default with a right to object, which achieves coverage and depends entirely on the communication being genuine rather than nominal. Granular consent lets the patient permit some categories or some recipients and not others, which is the most respectful and by far the hardest to implement, because every read path must evaluate it and every export must honour it. The engineering trap is offering granularity the downstream systems cannot enforce, which is worse than not offering it.

A legitimate relationship is the requirement that a clinician may only open the records of patients they are actually involved in caring for, evidenced by something the system knows — an admission to their ward, an appointment, a referral, being on the treating team. Role-based access alone answers "may this person read records of this type", which for a hospital-wide clinical role means every patient in the organisation, including their neighbours and colleagues. That is the access model that produces the recurring news story. Implementing relationships means authorisation depends on operational data that changes hourly, which is genuinely harder than a role check and is why an emergency override has to exist alongside it.

The decision is not one check, and the order matters because each branch has a different consequence.

flowchart TD
    R[Request to open a patient record] --> A{Authenticated user<br/>with a clinical role?}
    A -->|no| D[Deny and log the denial]
    A -->|yes| L{Legitimate relationship<br/>to this patient?}
    L -->|no| B[Offer break-glass<br/>reason mandatory]
    L -->|yes| C{Restriction on any<br/>data category?}
    C -->|yes| S[Show permitted items and<br/>state that items are withheld]
    C -->|no| G[Grant, and log the read]
    B --> G

The branch to notice is the one from restriction to a partial view. Silently omitting withheld items is the tempting implementation and is clinically dangerous, because a clinician reading an apparently complete medication list will reason from it. Telling them that something is withheld, without revealing what, preserves both the restriction and their ability to ask the patient.

The denial branch is not a dead end either. Denials are the most informative records in the audit trail, since a pattern of refused attempts is how you detect someone browsing, and a log of successes alone tells you nothing about the person who tried nine times first.

The break-glass edge is deliberately the only route past a missing relationship. Making it the single exception path means every unusual access is attributable, whereas a system with three quiet ways round the relationship check has no meaningful control at all. The cost is that the path must be fast enough to use during a resuscitation, which rules out synchronous human approval.

Emergency access must exist, because a control that obstructs treatment will be defeated by staff sharing logins. The design goal is usable, unattractive and loud.

Recorded at the moment of use
  who              named individual, never a shared emergency account
  which patient    the specific record, not "a patient"
  when             grant, first read, last read, expiry
  why              free-text reason plus a category, entered before entry
  scope            which record, which categories, which system
  duration         time-boxed session, typically minutes to an hour
  what was seen    every item opened within the session, itemised

Reviewed afterwards
  by whom          someone independent of the user and their line manager,
                   commonly a Caldicott or privacy function
  within           a fixed window, typically the next working day
  against          the reason given, the clinical context, and whether a
                   legitimate relationship existed but was not recorded
  outcomes         accepted, query raised with the clinician, or referred
                   as a potential inappropriate access
  informed         the patient, on request and in some regimes proactively

Monitored as a metric
  invocations per month, per user, per ward
  proportion reviewed within the window
  proportion resulting in a query

The itemised record of what was seen is the field teams skip and investigators need. Knowing that someone opened a record does not answer whether they read the mental health notes, and that distinction is the substance of every complaint about inappropriate access.

The review is what makes the control acceptable rather than the pre-approval, because a genuine emergency cannot wait for an approver. Substituting mandatory independent review after the fact for approval before it is an honest design, and the fixed window is the part that has to be enforced, since a review backlog converts the control into logging.

The failure mode to name unprompted is routine use. If break-glass is invoked hundreds of times a month on a particular ward, it is not emergency access, it is the access model, and the fix is to make the missing legitimate relationship visible to the system — bank staff, cross-cover rotas, on-call arrangements — rather than to keep reviewing exceptions. A rising invocation count is therefore a design signal rather than a compliance statistic.

De-identification is claimed far more often than it is achieved, and the gap is visible field by field.

Removed or transformed
  name, initials                      removed
  address below state or region       removed, keep first 3 postcode chars
  all dates except year               year only, and cap ages over 89
  telephone, fax, email               removed
  national and record identifiers     removed
  account, licence, device serials    removed
  vehicle and device identifiers      removed
  URLs, IP addresses                  removed
  biometrics, full-face images        removed
  any other unique identifying code   removed or replaced by a random token

Retained because the analysis needs it
  year of birth                       1981
  region                              North West
  sex                                 F
  diagnosis codes                     rare metabolic disorder
  admission year and length of stay   2026, 14 days
  free-text discharge narrative       retained, unreviewed

The retained block is where the risk lives. A rare diagnosis plus a region plus a year of birth can be unique in a population, so the record is re-identifiable without containing a single removed field — and joining it to any external dataset with those three attributes completes the job. Removing the enumerated identifiers bounds the obvious risk and says nothing about the combination.

The narrative row is the one that invalidates most real attempts. Clinical free text contains names of relatives, employers, the patient's occupation, unusual circumstances and often the patient's own name, and no regular expression finds all of it. Retaining unreviewed narrative in a dataset described as de-identified is the most common way this claim fails an inspection.

Two further residual risks are worth naming. Small cell counts leak: a cross-tabulation with one person in a cell identifies them regardless of what was removed. And repeated releases of overlapping extracts can be differenced, so somebody who obtains two versions learns what changed between them, which is why release management belongs in the process rather than only the transformation.

They are the two recognised routes to treating data as no longer identifiable, and they trade certainty against utility. Safe harbour is a checklist: remove the enumerated set of identifiers, cap ages above ninety, and you are done — cheap, mechanically auditable, and it strips fields analysts often genuinely need, including exact dates. Expert determination has a qualified person assess and document that the risk of re-identification is very small given the data, the recipient and the controls, which allows retaining more detail at the cost of a defensible written analysis and a review when circumstances change. The design implication is that expert determination is a process with an owner and an expiry, not a one-off transformation you can bury in a pipeline.

That clinical data physically remains in permitted jurisdictions, which turns a deployment choice into a design constraint. Storage and backups are region-pinned, a routing layer must know which region owns each patient or tenant, and the peripheral systems are where it breaks: logs, metrics, error traces, search indexes, message queues, support tooling and any third-party component all copy data somewhere. Cross-border transfer needs a lawful mechanism and an assessment rather than a configuration change. The operational consequences are real too — a support engineer in another country may be unable to view a record, and a global reporting view has to be assembled from in-region aggregates rather than raw rows.

Four questions, for a reader who may be adversarial and may arrive years later: who accessed which patient's record, when, and on what basis. That is a stricter requirement than an application log, because reads matter as much as writes — the harm in a privacy incident is usually somebody looking — and because the record must be complete, append-only, retained for years, and unreachable by the people whose actions it captures. The fields that get omitted and are always wanted are the justification for the access, the specific items viewed rather than the record as a whole, and denials alongside successes. It is also the evidence that a break-glass review happened, so it outlives the data it describes.

A structured, documented argument that a system is acceptably safe for a defined clinical use in a defined context, supported by evidence rather than assertion. It names the intended use and the users, identifies the hazards, records the controls that reduce each one, states the residual risk, and is signed by a named clinical safety officer who is accountable for that judgement. In several jurisdictions it is a formal requirement for health IT rather than good practice. Its engineering significance is that it makes safety a deliverable with an owner and a review trigger: a change to the intended use, or a new hazard from an incident, reopens it, so the safety case is a living artefact tied to your release process.

The hazard log is the working heart of the safety case, and one complete entry teaches the vocabulary better than the definitions do.

Hazard ID            HAZ-041
Hazard               A clinician is shown clinical data belonging to a
                     different patient
Clinical context     Inpatient ward round, results review on a shared device
Cause                An incorrect identity merge links two patients, and the
                     merged view combines both histories
Second cause         A result is filed against the wrong encounter after an
                     order acknowledgement is lost and rematched on
                     patient plus test plus approximate time

Harm                 Incorrect treatment decision based on another person's
                     results; a missed abnormal result in the patient's own
                     record
Severity             Major - treatment given or withheld incorrectly
Initial likelihood   Medium - merge review queue runs at volume
Initial risk         High - unacceptable, requires controls

Controls             1  Auto-merge only above the upper score threshold;
                        everything else to human review
                     2  Merge is a reversible assertion; source records
                        retained and unmerge is a supported operation
                     3  Results match on placer order number only; no
                        heuristic rematch, unmatched results to exception queue
                     4  Banner displays patient name, date of birth and
                        identifier persistently, verified against the wristband
                     5  Exception queue depth alerts, with a named owner

Residual likelihood  Low
Residual severity    Major - unchanged; controls reduce likelihood only
Residual risk        Medium - acceptable with monitoring
Owner                Clinical Safety Officer
Evidence             Test cases TC-118 to TC-131; merge review SOP v4;
                     alert configuration record; training material
Review trigger       Any reported wrong-patient event; change to matching
                     thresholds; new source system added to the index
Status               Open, accepted, reviewed 2026-06-18

The line that carries the most weight is that residual severity is unchanged. Preventive controls reduce how often a hazard occurs; only changing what the system does — not merging automatically at all, not showing a combined view — reduces how bad it is when it does. A log claiming that both fell is being filled in rather than reasoned about, and an experienced reviewer reads that column first.

The two causes matter because they are ordinary engineering decisions. A heuristic rematch of unmatched results is exactly the pragmatic fix an engineer would propose to clear an exception queue, and it is control three's job to forbid it. That is what a hazard log is for: it converts "be careful" into a named constraint with test cases behind it.

The review trigger is the field that keeps this from being a document. Changing a matching threshold is a configuration change with no code diff, and here it is tied to reopening a safety judgement — which is why safety and change management have to be the same process rather than two.

A hazard is a potential source of harm arising from the system — the wrong patient's data displayed, a delayed result, an incorrect dose calculation. A cause is the mechanism that leads to it, and one hazard usually has several, which is why controls attach to causes rather than to the hazard itself. A harm is what happens to a patient, expressed clinically: incorrect treatment, delayed diagnosis, unnecessary intervention. Keeping them separate is what makes risk assessable, because severity is a property of the harm while likelihood is a property of the causes and controls. Conflating them produces the common mistake of claiming a control reduced severity, when preventive controls only ever reduce likelihood.

When it has a medical purpose of its own — diagnosis, prevention, monitoring, prediction, prognosis or treatment of a condition — rather than merely storing, transmitting or displaying data for a clinician to interpret. That boundary is where the regulatory obligations start, and it is crossed by features that sound innocuous: a calculator that recommends a dose, a rule that flags a patient as high risk, an algorithm that triages a worklist. Intended use as stated in your own documentation and marketing is what determines it, so claims made by a product team have regulatory effect. The practical consequence is that classification must be assessed before a feature is built, because retrofitting device compliance to a shipped feature is far more expensive.

The class reflects the risk if the software is wrong, and it scales the evidence and the oversight rather than changing the engineering fundamentals. Higher classes require a quality management system, a documented risk management process, clinical evaluation, formal design controls with traceability from requirement through design to verification, post-market surveillance, and assessment by an external body rather than self-declaration. What changes daily is that the artefacts become part of the product: a change needs an impact assessment, releases carry a technical file that must stay current, and significant changes can require reassessment before shipping. That is why device software teams work in small, well-scoped increments rather than large ones — the evidence burden is per change.

GxP is the umbrella for good practice regulations in life sciences — good manufacturing, clinical and laboratory practice — and its recurring theme is that what you did must be evidenced, attributable and reconstructable. Computer system validation is the documented demonstration that a specific system, configured and installed as it actually is, does what its specification says and nothing undesirable, with traceability from user requirement through specification to executed test evidence and approval. Modern risk-based and iterative approaches are accepted, so effort concentrates where patient risk is highest rather than being spread evenly, and automated tests can be the evidence. What does not survive is a production change with no traceable requirement, review and result.

They are the regulatory instruments that turn interoperability from a good idea into an obligation. Certification programmes require health IT to expose defined standards-based APIs — in practice FHIR — for patient and application access, and information blocking rules make it unlawful for a provider or vendor to unreasonably interfere with the access, exchange or use of electronic health information, with a defined list of exceptions such as harm, privacy and infeasibility. The engineering consequences are direct: an API is a compliance surface with availability expectations, a delay deliberately inserted before releasing results to a patient needs to sit within a stated exception, and "commercially sensitive" is not one of them.

The protocol is the study's specification: its objectives, eligibility criteria, interventions, schedule of assessments, endpoints and statistical plan. Nothing may be collected or analysed outside it without an approved amendment, which makes it the requirements document your system implements. The case report form is the structured instrument capturing the data the protocol requires per participant per visit, and the electronic data capture system is the software that presents it, validates it as it is entered, and holds the resulting database. The engineering consequence is that a protocol amendment is a schema migration under change control, with the added requirement that data collected under the previous version remains interpretable and attributable to that version.

Adverse event handling is where trial software meets statutory clocks, and the clocks are short.

Participant          Study ABC-301, site 12, subject 12-0047
Event term           Acute pancreatitis
Onset                2026-07-24 06:30 local
Reported to site     2026-07-24 09:10
Serious?             Yes - required inpatient hospitalisation
Seriousness criteria hospitalisation; not fatal, not life-threatening
Severity             Severe
Causality            Investigator assessment: possibly related to study drug
Expectedness         Not listed in the reference safety information -
                     therefore unexpected
Action taken         Study drug permanently discontinued
Outcome              Recovering
Classification       Serious, unexpected, possibly related - a SUSAR

Clocks that now apply
  Investigator to sponsor        immediately, within 24 hours of awareness
  Sponsor to regulator, fatal
  or life-threatening SUSAR      7 calendar days, follow-up within 8 more
  Sponsor to regulator, other
  serious SUSARs                 15 calendar days
  Clock starts                   sponsor's first awareness, not the site's
  Ethics committee and other
  investigators                  informed per the applicable regime

The classification line is doing all the work. Serious, unexpected and related are three independent judgements, and only when all three hold does the event become a suspected unexpected serious adverse reaction with an external reporting clock. Software that stores a single "serious yes or no" flag cannot compute that, so the data model needs the seriousness criteria, the causality assessment and the comparison against the reference safety information as separate, versioned fields.

The clock detail candidates miss is that it starts at the sponsor's awareness. A system that lets a site's report sit in a queue for four days has consumed most of a fifteen-day window before anybody assessed it, so the engineering requirements are timestamped receipt, escalation on unactioned reports, and an audit trail showing exactly when each party became aware.

The other consequence is that expectedness is a comparison against a document that changes. When the reference safety information is updated, events previously unexpected become expected, and the system must record which version was in force at assessment — otherwise a later inspection cannot reconstruct why an event was or was not reported.

ALCOA is the shorthand for the properties regulated data must have: attributable, legible, contemporaneous, original and accurate, commonly extended with complete, consistent, enduring and available. It reads as a quality slogan and is really a list of system requirements — every value traceable to a person and a time, no overwriting without an audit trail, no retrospective entry disguised as contemporaneous. Source data verification is the check that what the trial database holds matches the original record, historically by a monitor comparing against the medical notes on site. Risk-based monitoring has reduced how much is verified, which raises rather than lowers the demands on the system, because statistical detection of anomalies replaces exhaustive checking.

They standardise how trial data is structured so that a regulator can review submissions from different sponsors without learning a new schema each time. The family separates concerns: a model for how data is collected, a tabulation standard for the observed data as submitted, and an analysis standard for the derived datasets the statistical results were produced from. The value to a sponsor is that the pipeline from capture to submission has defined shapes at each stage; the cost is that mapping into them is real work, usually done by programmers who specialise in it. The transferable lesson is that a standard imposed by whoever consumes your data eventually reaches back into how you capture it.

Randomisation demands that allocation be unpredictable, reproducible from a recorded seed and list, auditable after the fact, and available immediately at the point of enrolment including out of hours. Blinding demands that the system does not reveal allocation to people who must not know it, which is an access-control problem that extends into places engineers forget: logs, error messages, database backups, analytics dashboards, support tooling and anything showing a drug kit number. There must also be a controlled emergency unblinding path that records who unblinded whom, when and why. And an unblinding through a stack trace is a protocol deviation, which is a reportable event rather than a bug.

Database lock is the point at which trial data is declared final so the planned analysis can run against a fixed dataset. Before it, data flows in and queries are raised and resolved; after it, no change is permitted without a documented, approved unlock with a reason. It changes the software because it makes immutability and reproducibility functional requirements rather than good practice: the exact dataset used for the analysis must be reconstructable years later, every change before the lock must be attributable, and derived datasets must be regenerable from the locked data with the same code. Analysts who query a live mutable database cannot answer an inspector's question about what the numbers were on lock day.

No, and reaching for it reflexively is a recognisable signal that a candidate has read the specification and not worked in a hospital. FHIR is the right answer for new external interfaces, patient and application access, and anywhere query matters. It is the wrong answer for replacing a working v2 interface with no clinical benefit, for high-volume internal event notification where the payload size and the missing event semantics both hurt, and for anything that needs a signed attested document rather than a bundle of independently mutable resources. The stronger answer names the layering — v2 or documents internally, FHIR at the boundary — and identifies the translation as the place defects will actually appear.

No, and the belief that it does is how identifiable data ends up in analytics environments with weak controls. Identification comes from combinations, so a year of birth, a region and a rare diagnosis can single out one person without a name anywhere in the row, and any external dataset sharing those attributes completes the link. Free-text clinical narrative is worse, since it contains relatives, employers, occupations and often the patient's own name in prose no pattern match reliably finds. The defensible positions are the enumerated-removal route or a documented expert assessment of residual risk, both accompanied by controls on who receives the data and what they may join it to.

Usually not, and treating it as the default is one of the clearest signals that someone has not worked with clinicians. An alert consumes attention from a person who has a patient in front of them and a queue behind them, and alerts that are mostly wrong train people to dismiss all alerts, including the correct one. The two questions to ask about any proposed alert are what the clinician is expected to do differently, and what proportion of firings will be ones where they should. If the second answer is low, the alert makes the system less safe while making the project look diligent. Better answers place the information where the decision is made rather than interrupting it.

It treats identity as data cleaning when it is a safety-critical decision with asymmetric errors and no threshold that eliminates both. A false negative leaves one person as two charts, so a clinician sees half a history and can miss an allergy. A false positive merges two people, so a clinician is shown someone else's results, and by the time it is discovered the merged identifier has been copied into orders, claims and other organisations' systems. Batch deduplication run once against a scoring function is therefore the wrong shape entirely. The credible answer is a narrow auto-link band, a review queue with staff, reversible merges, and a measured rate for both error directions.

Because optionality in a standard is where interoperability is actually decided, and it pushes the decision onto you rather than removing it. If a field may be absent, your system needs a defined behaviour for its absence, and that behaviour is a clinical judgement: rejecting the message, storing a null, or defaulting are three different safety positions. Optional fields are also where local meaning accumulates, since two organisations agree bilaterally what an optional field or a local extension will carry, usually in a conversation nobody documented. So the useful answer names the profile or implementation guide that makes the field mandatory for your context, and the exception handling for when it arrives empty anyway.

Whether you can design for a failure mode whose cost is patient harm rather than error rate. A strong answer names the hazard and its causes before the feature: identity merged incorrectly, a result matched by heuristic instead of by order identifier, a session bound to the wrong patient on a shared device. It attaches a control to each cause — auto-link only above a high threshold, reversible merges, matching on the placer order number with unmatched results queued, a persistent patient banner verified against the wristband — and says which reduce likelihood while admitting severity is unchanged. It names the detection: not an error rate, because nothing errors, but exception queue depth, unmerge frequency and wrong-patient events reported by clinicians.

A weak answer substitutes reassurance for design. It promises careful testing, offers a confirmation dialogue as the control, treats the problem as data quality, or escalates it to compliance. The distinguishing signal is whether the candidate reasons backwards from the harm to the mechanism, and can say what the system does once the control has already failed and a clinician is looking at the wrong history right now.