NATIONAL HEALTHCARE INTELLIGENCE
The Business Problem
Where the record is broken
The client is a healthcare organisation in the United States operating across multiple care settings. A
patient’s history was spread across every organisation that had ever treated them. The hospital holds the
admission, the laboratory holds the results, the imaging centre holds the study, the pharmacy holds what
was dispensed, the insurer holds the claim, and none of them holds all of it. The patient carries the record
between them, usually in a paper folder and usually incompletely.
The clinical cost is repeated tests, missed interactions and decisions taken without the history that would
have changed them. The system level cost is that the health authority is planning capacity, procurement
and disease response using data that is a reporting cycle behind reality
What was happening instead
- The patient is the integration layer. History is reconstructed at every encounter by asking, which works
badly for the unconscious, the elderly and the chronically ill. - Point to point interfaces. Each pair of systems connected separately, so the cost of connectivity grows with the square of the number of participants.
- Registries filled in by hand. Clinicians entering the same data twice, once into the record and once into a
national return. - Research on extracts. De-identified copies shipped to a university, ageing immediately, and creating a governance problem the moment they leave.
Where the cost sits
| Cost | Driver |
|---|---|
| Duplicate investigations | Tests repeated because a prior result cannot be found or trusted. |
| Avoidable admissions | Deterioration in chronic disease that was visible in the data before it became an emergency. |
| Length of stay | Decisions waiting on information that exists elsewhere in the system. |
| Clinician time | Documentation and reporting burden that takes clinicians away from patients. |
| Late diagnosis | Conditions found at a stage where treatment is longer, harder and more expensive. |
| Planning error | Capacity and procurement decided on data that describes last year. |
| Research friction | Months of approvals and extract preparation before a study can begin. |
The Requirement in One Sentence
Bring clinical, imaging, laboratory, pharmacy, claims and genomic data from many independent
organisations onto one governed interoperable platform, resolve each patient to a single identity, enforce
consent and purpose in the data layer itself, and serve clinicians, researchers and the health authority
from that one place without any of them seeing more than they are entitled to see.
Solution Overview
Data arrives in the standards the sector already uses, is normalised against national terminologies, resolved to a single patient identity, and curated into a lakehouse where every access is filtered by consent
and by purpose. Models and copilots read only what the requesting purpose allows, and nothing leaves the platform in identified form.
Layered architecture
Layer 7 Delivery
Command centre, clinical apps and research workspaces
Point of care views, hospital operations, national dashboards and isolated analysis environments.
Layer 6 Agents
Clinical and operational copilots
Summarisation, coding support, cohort building and literature grounded answers, all advisory.
Layer 5 Models
Risk, imaging, deterioration and population models
Registered, validated and monitored, with federated training where data cannot move.
Layer 4 Consent
Purpose binding and access control
Every query carries a purpose, and the consent state at that moment decides what rows and columns return.
Layer 3 Identity
Master patient index and record linkage
Probabilistic matching with clinical review of the uncertain band, and full reversibility.
Layer 2 Semantics
Terminology normalisation
Local codes mapped to national and international vocabularies so the same concept means the same thing everywhere.
Layer 1 Interop
Standards based ingestion
Clinical messaging, resource APIs, imaging transfer and claims files from every participating organisation.
The clinical safety boundary
Everything the platform produces for a clinician is advisory. It surfaces, ranks and explains. The clinical decision, and the accountability for it, stays with the clinician, and the architecture makes that structurally true rather than a line in a disclaimer.
| The platform does | The platform never does |
|---|---|
| Surface the complete history | Make a diagnosis of record |
| Flag a deterioration risk | Order a test or a treatment |
| Highlight an interaction or allergy | Change a prescription |
| Draft a summary for a code | Sign a clinical note |
| Rank a cohort for review | Alter a care pathway on its own |
| Show the evidence and the source | Replace clinical judgement |
why the boundary is drawn here
Anything that acts on a patient is a medical device in most jurisdictions and carries a regulatory pathway
of its own. Keeping the platform advisory means the clinical safety case is about the quality and
provenance of what is shown, which is assessable, rather than about the correctness of an autonomous
action, which is a much longer and more expensive argument.
Interoperability and Ingestion
What arrives and how
| Source | Mechanism and shape |
|---|---|
| Hospital record systems | Clinical messaging for admissions, transfers, orders and results, plus resource APIs where the vendor supports them. |
| Laboratories | Structured result messages with units and reference ranges preserved, because a value without its range is not interpretable. |
| Imaging centres | Standard imaging transfer of studies and structured reports, with pixel data landed in governed storage and metadata indexed. |
| Pharmacy and dispensing | Dispense events and medication lists, which are usually a better record of what the patient actually took than the prescription. |
| Insurers and claims | Batch files carrying diagnosis and procedure coding, useful for coverage and for population denominators. |
| Genomics | Variant call files and interpretation reports, referenced rather than copied, with the raw sequence kept where it was produced. |
| Devices and wearables | Continuous streams landed at low resolution by default, with full resolution retained around clinical events. |
| Registries and public health | Notifications, immunisation and screening records. |
The problems that decide the timeline
Conformance
Standards are implemented, not obeyed
Two hospitals can both claim conformance and still disagree on where the diagnosis sits in the message. Every participating organisation is profiled individually and a conformance test suite is run before its data is trusted.
Local codes
Most systems carry their own vocabularies
A laboratory that uses its own test codes has to be mapped before its results can be compared with anyone else's. That mapping is clinical work, not technical work.
Free text
The most valuable content is unstructured
Discharge summaries and radiology reports hold what actually happened. Extraction runs asynchronously and its output is always marked as derived rather than as source.
Volume
Imaging dominates storage
A single study can be larger than a year of that patient's structured record, so pixel data is tiered and indexed rather than held hot.
Onboarding a hospital is a project with a fixed shape
Profile the source, agree the mapping, run conformance tests, reconcile a month of data against the hospital's own reports, then go live. It takes roughly the same effort at hospital two as at hospital twenty, which means the programme plan must be built around a repeatable onboarding factory rather than around a one time integration.
Terminology and Patient Identity
One meaning per concept
Every clinical code is mapped to a reference vocabulary at the point of curation, and both the original local code and the mapped concept are kept. Keeping both matters, because a clinician needs to see what was actually recorded and an analyst needs to compare across organisations.
| Domain | Reference vocabulary |
|---|---|
| Clinical findings and procedures | A clinical terminology with a concept hierarchy, so a query for a parent concept finds the children. |
| Laboratory tests | A test identification standard, with units normalised and reference ranges retained per laboratory. |
| Diagnoses for reporting | The statistical classification the country reports on. |
| Medicines | A drug vocabulary that resolves brand to ingredient, strength and form. |
| Imaging | Study and body part coding from the imaging standard plus the report terminology. |
mapping in never finished
New tests, new medicines and local additions appear continuously. Treat terminology as a running service
with a clinical owner, a review queue and a versioned release, not as a one time data cleansing exercise.
Unmapped codes are counted and published, because an unmeasured mapping backlog silently distorts
every population number.
Resolving one patient across many organisations
Without a universally used national identifier, the same person appears as a different patient in every system, with names spelled differently, dates transposed and addresses out of date. Getting this wrong in either direction is harmful, so the design is deliberately conservative.
Data quality as an operational signal
Step 1
Deterministic match on strong identifiers
Where a verified national or health identifier exists on both records, the match is accepted.
Step 2
Probabilistic match on the rest
Name, date of birth, sex, address and contact compared with weights fitted to the local population, allowing for transliteration and common name frequency.
Step 3
Three outcomes, not two
Above the upper threshold the records are linked. Below the lower threshold they are kept separate. Between those ranges it goes to a trained human reviewer.
Step 4
Every link is reversible
Links are stored as evidence with their score and their basis, so an incorrect merge can be undone without losing the underlying records.
The two errors are not equal
A false split means a clinician sees an incomplete history, which is the problem the platform exists to solve. A false merge means a clinician sees another person's history, which is a patient safety incident. The thresholds are set with that asymmetry explicit, agreed with clinical governance, and the merge rate and review queue are reported every month.
Consent, Privacy and Purpose
Consent enforced in the data layer
Consent written into a policy document is a promise. Consent implemented as a row filter on the table is a control. Every query carries the identity of the requester and the purpose of the request, and the platform resolves what is visible from the consent state at that moment.
| Control | Implementation |
|---|---|
| Purpose binding | Direct care, operations, public health and research are separate purposes with separate entitlements. The same person gets different results under different purposes. |
| Consent register | Held as versioned records with effective dates, so a query about the past uses the consent that applied then. |
| Row filters | Applied on the table itself, so the rule cannot be bypassed by using a different tool. |
| Column masks | Identifiers masked by default, released only to purposes that genuinely need them. |
| Sensitive categories | Certain record types carry additional restriction by law or by policy and are filtered independently of the rest. |
| Break glass | Emergency access permitted, logged separately, and reviewed by a named person afterwards rather than approved in advance. |
| Withdrawal | Consent withdrawal propagates to derived tables and to future model training, with deletion vectors making removal practical. |
Research access without releasing data
Model 1
De-identified views
Direct identifiers removed, dates shifted consistently per patient, rare values generalised, and small cells suppressed so an individual cannot be isolated by combining fields.
Model 2
Analysis comes to the data
Researchers work inside a controlled workspace with no export path. Results are reviewed for disclosure before they leave, which removes the extract problem entirely.
Model 3
Aggregate query interface
Counts and summaries returned with minimum cell sizes and query budgets, for feasibility work that does not need record level access.
Model 4
Federated computation
Where data may not leave an institution at all, the computation is sent to it and only parameters return.
De-identification is a risk position, not a binary state
No practical de-identification is unbreakable against an adversary with outside data. State the residual re-identification risk explicitly, control it with the access model rather than only with the transformation, and record the decision. A programme that treats de-identification as an absolute guarantee will eventually make a claim it cannot defend.
The Lakehouse Data Model
Three stages, each with a clear job
| Stage | What lives there and why |
|---|---|
| Bronze | The message or file exactly as received, with sending organisation, transport metadata and receipt time. Nothing corrected. This is what an audit or a clinical incident review will need. |
| Silver | Parsed into clinical resources, terminology mapped, units normalised, patient resolved, duplicates collapsed, and every value carrying its provenance back to the sending system. |
| Gold | Patient 360, encounter, longitudinal medication and result series, cohort tables, population denominators and the operational marts each organisation needs. |
Quality enforced at write time
| Expectation class | Example |
|---|---|
| Structural | Mandatory elements present, codes resolve in the declared vocabulary version. |
| Clinical plausibility | Values inside physiologically possible ranges, with implausible entries quarantined rather than published. |
| Temporal | Discharge never precedes admission, results never precede the order. |
| Completeness | Expected message volume per organisation per day, so a hospital that quietly stops sending is detected the same day. |
Why the clinical feature store matters here
Clinical prediction is unusually easy to get wrong in a way that looks excellent in testing. The two common failures are both about time.
- Leakage from the future. A model that uses a laboratory result recorded at eleven o’clock to predict an
event at ten will score beautifully and be useless. Features are joined as of the prediction timestamp,
and that is enforced by the store rather than left to the modeller. - Availability at inference. A feature that exists in the warehouse but arrives four hours late in practice
cannot be used in a model meant to give six hours of warning. Every feature carries a measured arrival
latency and models are restricted to what will actually be there.
missingness is information and it is also a trap
In clinical data the absence of a test usually means the clinician did not think it was needed, which carries
real signal. It also means a model can learn the local ordering habits of one hospital rather than the
physiology, and then fail at the next hospital. Missingness is modelled deliberately and validated across
organisations before deployment.
The Model Estate
What runs, and on what
| Model | Job and shape |
|---|---|
| Deterioration early warning | Continuous risk score on inpatients from vital signs, laboratory trend and treatment, tuned for lead time and for a manageable alert rate. |
| Chronic disease risk | Progression and complication risk in the community, used to prioritise outreach rather than to label patients. |
| Medical imaging | Detection and segmentation as a second reader, with the finding always presented alongside the image region it came from. |
| Clinical language | Extraction of problems, medications and findings from discharge summaries and reports, marked as derived. |
| Precision medicine | Variant interpretation and pharmacogenomic flags combined with the clinical record. |
| Population health | Incidence, prevalence and demand forecasting by geography for capacity and procurement planning. |
| Hospital operations | Admission, discharge and theatre demand forecasting, which is where operational value appears earliest. |
Federated learning where data cannot move
Many organisations will contribute to a model and refuse to contribute their data, and that position is usually correct. Training is therefore sent to the data, with only model updates returning.
Round
Central model distributed to each participant
Local
Trained inside the institution, on the institution's own hardware
Return
Parameter updates only, with noise added where the threat model requires it
Aggregate
Updates combined, weighted by contribution and by validation performance
Validation is the hard part
- External validation before deployment. A model developed at one hospital is tested at another before it
is trusted anywhere, because case mix differs more than most teams expect. - Subgroup performance published. Performance is reported by clinically relevant subgroups and a model
that performs unevenly is treated as a finding rather than as an average. - Alert burden measured. A score with excellent statistics and a high alert rate will be ignored within a
fortnight, which makes the alerting policy as important as the model.
Copilots and the Reasoning Layer
Bounded assistants with a purpose
| Copilot | Scope and limit |
|---|---|
| Clinician summary | Assembles the longitudinal picture for the patient in front of the clinician, with every statement linked to its source document. It never states a conclusion the record does not support. |
| Documentation support | Drafts the discharge summary and suggests coding from the encounter record. The clinician edits and signs. |
| Research cohort | Turns an eligibility description into a query against de-identified data and returns counts, not people. |
| Operations | Explains bed, theatre and staffing pressure and what is driving it. |
| Public health | Answers surveillance questions from population tables with denominators stated. |
| Guideline lookup | Retrieves the applicable guideline and cites the section, without adapting it to the patient. |
The retrieval corpus
National guidelines
Formulary
Care pathways
Local protocols
Medicine information
Published literature Coding standards Consent policy
Published literature Coding standards Consent policy
Grounding contract
| Condition | Required behaviour |
|---|---|
| Supported by the record | State it and link to the document, the encounter and the date. |
| Supported by a guideline | Cite the guideline and the section. Never paraphrase a recommendation without pointing at it. |
| Record is incomplete | Say what is missing and from which organisation, rather than filling the gap. |
| Conflicting entries | Show both with their sources and dates, and let the clinician resolve them. |
| Consent restricts the answer | State that restricted data exists without revealing it, so the clinician knows to ask. |
| Outside scope | Refuse, and record the refusal. |
Links are mandatory
Every clinical statement in a generated summary carries a link back to the source entry, so the clinician can verify it in a second rather than trusting it. That single property is what separates a usable clinical summary from an unusable one, and it is the feature clinicians test first.
Refusals map the gaps
Every question the copilot cannot answer identifies a missing feed, an unmapped vocabulary or a consent design that is blocking legitimate care. Over time that list is the most valuable operational output of the reasoning layer.
Worked Example, End to End
Trigger
A patient admitted through the emergency department two days ago crosses the deterioration threshold on a general ward at 03:40. The score has been climbing for nine hours.
Step 1 Assemble
History resolved across organisations
Two prior admissions at a different hospital and community dispensing records linked to the same patient identity.
Step 2 Score
Trend, not a single reading
Respiratory rate, heart rate and laboratory trend combined, with the rate of change carrying more weight than the absolute value.
Step 3 Explain
Contributing factors listed
The three features driving the score shown with their values and their timestamps.
Step 4 Route
Alert to the outreach team, not the ward alone
Escalation follows the hospital's own protocol rather than a route invented by the platform.
Step 5 Close
Outcome recorded against the alert
What the team found and what they did, which is what allows precision to be measured next month.
Outreach Nurse
"Why is this patient flagged when the observations look borderline?"
Clinical Copilot
"The individual observations are borderline. The rate of change is not. Respiratory rate has risen from 18 to 26 over nine hours, heart rate from 88 to 112, and the most recent laboratory panel at 22:10 shows a fall from the previous panel at 09:15. The score is driven mainly by the trajectory. This patient also had an admission for the same presenting complaint at another hospital in March, linked on 14 February this year, and the discharge summary from that admission is attached."
Outreach Nurse
"Is there anything in the medication history I should know?"
Clinical Copilot
"Community dispensing shows a medicine that was not on the admission list, last dispensed six weeks ago. That is a dispensing record and not a confirmation that it is being taken, so it should be checked with the patient or the family. There is also restricted information on this record that your current access does not cover. I cannot show it, but you should be aware that it exists."
what made ths work
Nothing in this sequence required a new model. It required the card stream, the dispute stream and the
merchant reference data to be in the same governed place, joined on a key both sides agree on, with the
heavy graph work done in advance so the live path only had to read a number.
Security and National Scale Operations
Security posture
| Control | Implementation |
|---|---|
| Network | Private connectivity end to end, no public endpoints on the workspace or the storage account, egress restricted to an approved list. |
| Identity | Single corporate directory, short lived tokens, no shared service accounts, machine identities scoped per pipeline. |
| Encryption | Customer managed keys for storage and for managed services, with rotation and revocation held by the institution rather than the platform. |
| Secrets | Held in the enterprise vault and referenced, never present in notebooks, jobs or repositories. |
| Least privilege | Access granted to a group by role and purpose, reviewed on a recertification cycle, with standing access to production data treated as an exception. |
| Tokenisation | Card numbers and national identifiers replaced at ingest, with detokenisation available only to a small number of controlled paths. |
| Audit immutability | Access logs written once to a separate account under different administration. |
Operating at national scale
Availability
Clinical read paths are life critical
Point of care retrieval runs active in more than one region with independent failure domains. Analytical and research workloads carry a longer recovery objective and are recovered second.
Degradation
A defined degraded mode
If enrichment or scoring is unavailable, the record itself must still be retrievable. The degraded behaviour is designed, tested and understood by clinical staff in advance.
Onboarding
A factory, not a series of projects
Standard profile, standard test suite, standard reconciliation, so the hundredth organisation costs roughly what the tenth did.
Transparency
Published service and quality reporting
Uptime, data freshness by organisation and unmapped code counts published to participants, because voluntary participation depends on visible fairness.
Public trust is a system requirement
A national health data platform fails on consent and confidence long before it fails on engineering. The consent model, the audit visible to the patient and the published transparency reporting are not compliance overhead. They are the mechanism by which the programme keeps its permission to operate.
How We Delivered It
The phases we ran
| Phase | Scope | What it produced |
|---|---|---|
| Phase 0 Foundation |
Legal basis, consent model, identity strategy, terminology ownership, security architecture, participant inventory. | Approved information governance design and a signed consent model. |
| Phase 1 First cohort |
Three to five organisations onboarded end to end, terminology mapped, identity resolution running with human review. | Match quality measured and reconciliation against source reports for a full month. |
| Phase 2 Clinical value |
Longitudinal record available at the point of care in those organisations. | Clinician adoption and measured reduction in repeat investigations. |
| Phase 3 Models |
Deterioration and operational forecasting in shadow mode, externally validated. | Performance and alert burden accepted by clinical governance. |
| Phase 4 Research |
Controlled workspaces and aggregate query interface opened to approved studies. | First studies completed without any data leaving the platform. |
| Phase 5 Scale |
Onboarding industrialised, population analytics available to the health authority. | Repeatable onboarding package and published transparency reporting. |
How it runs now
Terminology service
Clinically owned, versioned, released on a cadence
With an unmapped code backlog that is measured and published rather than allowed to grow quietly.
Identity stewardship
A standing review team
Uncertain matches reviewed daily, merges and unmerges reported monthly to clinical governance.
Model governance
Clinical safety case per model
Reviewed on a schedule and on any material change, with a defined withdrawal path if performance drifts.
Participant support
A named contact per organisation
Because a hospital that has stopped sending data needs a person to call, not a ticket queue.
Deliver clinical value before analytical ambition
Programmes that begin with population dashboards struggle to keep clinical participation, because the people supplying the data see no return. Give clinicians the complete record first. Every later capability depends on their continued willingness to send data, and that willingness is earned once.
Benefits and Measurement
Benefits realised
A complete record at the bedside
History from every participating organisation available at the point of care.
Fewer repeat investigations
Prior results found and trusted rather than reordered.
Earlier intervention
Deterioration and disease progression visible while there is still time to act.
Less documentation burden
Summaries and coding drafted from the record for the clinician to check.
Research without data release
Analysis brought to governed data instead of extracts shipped out.
Current population view
Planning and surveillance on data measured in days rather than reporting cycles.
Consent that is demonstrable
Enforced in the data layer and visible in the audit trail.
Documented data gaps
Unmapped codes and missing feeds counted and published.
KPI framework
| Measure | What it tells you |
|---|---|
| Record completeness at point of care | Share of encounters where the full linked history was available. The measure the clinical case rests on. |
| Identity match rate and review queue | Linkage quality, and whether human review is keeping up. |
| False merge incidents | Tracked separately and reported to clinical governance, because the tolerance is near zero. |
| Duplicate investigation rate | The clearest financial return, measurable from existing order data. |
| Alert precision and burden | Confirmed alerts against total alerts, which decides whether staff keep responding. |
| Prediction lead time | How much warning was actually given before the event. |
| Unmapped code rate | How much clinical content is still not comparable across organisations. |
| Data freshness by organisation | Which participants are lagging, before anyone builds an analysis on stale data. |
Baseline first
Capture the current repeat investigation rate, average time to retrieve external records and existing deterioration outcomes before deployment. Ordering data and admission data usually make this measurable from systems that already exist, and without a baseline the benefit case after go live is a claim rather than a result.
Scale and Performance
Scale the platform was built to carry
| Metric | Enterprise scale |
|---|---|
| Hospitals connected | 200 to 1,000 |
| Patients | 20 to 100 million |
| Clinical records | 1 to 5 billion |
| Medical images | 300 to 800 million |
| Daily streaming events | 100 to 300 million |
| Healthcare professionals served | 50,000 to 250,000 |
| Research datasets | 5 to 30 PB |
Engineering targets
| Measure | Target |
|---|---|
| Clinical data availability | 99.9 percent |
| Patient search response | Under 3 seconds |
| Diagnostic model inference | Under 5 seconds |
| Imaging model processing | Under 30 seconds per study |
| Data refresh | Near real time |
| Data quality compliance | Above 97 percent |
Business improvement ranges
| Measure | Expected improvement |
|---|---|
| Deterioration detection | 20 to 30 percent earlier identification |
| Hospital readmissions | 10 to 18 percent reduction |
| Diagnostic turnaround time | 20 to 35 percent faster |
| Clinical documentation time | 30 to 45 percent reduction |
| Resource utilisation | 12 to 20 percent improvement |
| Research data preparation | 50 to 70 percent faster |
| Patient wait times | 10 to 20 percent reduction |
| Administrative cost | 12 to 18 percent reduction |
How to read these figures
The scale column describes the volumes the platform was engineered to carry. The target column is the service level it is built and operated to, and it is measured continuously. The improvement column is the range this class of platform delivers, and it is confirmed against a client's own baseline during assessment rather than claimed in advance. We capture that baseline before the first pipeline is written, because a benefit without a baseline is an argument rather than a result.
The number that governs the design
Patient search under three seconds is the one clinicians judge the platform on. It is why identity resolution is precomputed rather than run at query time, why the longitudinal record is materialised as a gold table instead of assembled from resources on each request, and why the clinical read path is recovered before anything analytical when a region fails.
Platform Capability Across the Estate
The three platforms are built on the same Databricks foundation and are operated to the same envelope. The figures below describe the capability of that foundation across the estate rather than the load of any single engagement, and they are the numbers we size and design against when a new platform is scoped.
| Platform metric | Typical target |
|---|---|
| Data ingestion | 20 to 150 TB per day |
| Structured streaming throughput | 20,000 to 500,000 events per second |
| Historical lakehouse | 2 to 30 PB |
| Delta tables | 5,000 to 25,000 |
| Models under management | 100 to 500 |
| Feature store features | 10,000 to 100,000 |
| Vector embeddings | 100 million to 2 billion |
Why we publish the envelope rather than one number
Sizing is driven by event rate and retention, not by headcount or revenue. Quoting a single figure invites a
comparison that does not hold. The range is what we design and cost against, and the point inside it is
settled during assessment from the client's own event volumes.
| Platform metric | Typical target |
|---|---|
| Daily inference requests | 10 to 100 million |
| Enterprise users | 5,000 to 50,000 |
| Platform availability | 99.9 to 99.95 percent |
| Automated data quality checks | Above 95 percent of published tables |
| Governance coverage | 100 percent of production datasets |
| Mean time to detect a data issue | Under 15 minutes |
The two that matter most
Governance coverage and mean time to detect are the two we hold hardest. A production dataset outside
the catalogue cannot be audited, and a data issue that is found by a business user rather than by a
monitor has already cost the client the thing the platform was bought to protect.
What We Learned
The hard problems, and what we did about them
| Problem | What we did |
|---|---|
| Identity resolution errors | Conservative thresholds, human review of the uncertain band, reversible links, and false merges reported to clinical governance every month. |
| Terminology mapping backlog | A funded clinical terminology service from Phase 0, with unmapped rates published rather than absorbed. |
| Source conformance variation | Per organisation profiling and a conformance test suite before any feed is trusted, with reconciliation against the organisation's own reports. |
| Consent complexity | Model the consent rules with legal and clinical governance before building, because retrofitting purpose binding onto live data is close to a rebuild. |
| Model generalisation | External validation at a second organisation before deployment anywhere, and subgroup performance published. |
| Alert fatigue | Alert rate treated as a design constraint with clinical staff, and monitored after release as closely as accuracy. |
| Imaging storage cost | Tiered storage with metadata indexed hot and pixel data retrieved on demand. |
| Participation risk | Clinical value delivered to contributing organisations early, because voluntary participation is the real dependency. |
What we settled before writing any code
- The legal basis. What it was, and whether it covered secondary use as well as direct care.
- The patient identifier. Whether a shared identifier existed, and how widely it was actually captured in
practice rather than in theory. - The first cohort. Which organisations would go first, and what interoperability capability their systems
genuinely had. - Terminology ownership. Who owned clinical terminology, and whether there was an existing mapping to
build on. - The consent model. Opt in or opt out, and how consent was captured and withdrawn.
- Residency. Where processing was permitted to happen, and what that meant for the region layout.
- Clinical safety. Who signs the safety case for a model, and under what process.
- Research access. The approval route, and how long it actually took.
What we would tell the next client
An interoperability and identity readiness assessment across three candidate organisations. It costs little, it produces a measured picture of message conformance, code coverage and identifier quality, and it tells you honestly how much of the programme is engineering and how much is clinical mapping. That distinction usually decides the timeline, and it is far better established in eight weeks than discovered in year two.