Skip to content
QuorlyticTalk to a Data ExpertContact
Menu
Illustration: a hospital campus at dusk, with record, consent, identity and access icons linked by light paths running into the building.

Industry / Healthcare

Operational clarity with privacy intact.

Data and AI for healthcare connects operational and clinical data for planning and capacity decisions while treating consent, access and retention as part of the data model from the start, not added later. Quorlytic keeps clinical judgment with qualified people, using analytics to surface patterns and flag anomalies rather than to automate a clinical decision.

By QuorlyticUpdated

A health organisation knows a great deal about a person and almost never in one place. The same individual is a patient record here, a scheduling entry there, a billing account somewhere else, and the rules about who may read which of those, for what purpose and for how long, are the part that has to survive every join. This page sets out the operational lifecycle that data serves, and what has to hold before analytics is trustworthy on top of it.

Talk to a Data ExpertSee the operational pathway
  • Identity resolved once
  • Purpose travels with the data
  • Access decided at read time
  • Retention is a rule, not a habit
  • One person, one identityDuplicate and merged records reconciled with the link kept, not overwritten
  • Purpose stays attachedWhy data may be used travels with it into every derived view
  • Access at read timePermission evaluated against the caller and the task, not baked into a copy
  • Operational, not clinicalCapacity, flow and administrative decisions — never diagnosis or treatment

Lifecycle

The operational pathway, stage by stage

Nine stages of an operational pathway. Each one produces records the next one depends on, and the recurring failure is not missing data — it is data that arrives without the identity, the purpose or the timing that makes it usable.

  1. Referral and entry

    A person enters the pathway from primary care, an emergency presentation, a transfer or a self-referral. Each route creates a record in a different system with a different identifier.

    Data
    Referral records, source organisation, presenting reason, urgency, demographics as supplied.
    Decision
    Whether this person enters the pathway, and with what priority.

  2. Identity and eligibility

    Work out who this is, and what they are entitled to. FHIR models a patient as carrying many identifiers rather than one, which is a description of reality rather than a shortcoming.

    Data
    Person and patient identifiers from each source, demographics, coverage or scheme eligibility, existing record links.
    Decision
    Which existing record this is, or whether a new one is correct.

  3. Schedule against real capacity

    Offer a slot that actually exists. Capacity is a function of room, staff, equipment and preparation time, and those live in different systems from the appointment book.

    Data
    Slot availability, clinic and resource calendars, staffing rosters, preparation and turnaround rules.
    Decision
    What to offer, to whom, and when.

  4. Encounter

    The appointment, admission or contact happens. This is the event everything else is dated against, and it is often recorded after it ends rather than as it runs.

    Data
    Encounter start and end, location, attending team, arrival and wait events, cancellation and non-attendance.
    Decision
    What actually happened, where, and how long it took.

  5. Documentation

    The encounter is written up. Documentation lags the event by hours or days, so any measure computed on the day is provisional whether or not it says so.

    Data
    Notes, coded observations, procedures performed, authorship and timestamps, amendments and corrections.
    Decision
    What the record of this encounter says — and when it became complete.

  6. Orders and results

    Tests, imaging and prescriptions are ordered, fulfilled and returned, usually across an organisational boundary and on their own clock.

    Data
    Order records, fulfilment status, result availability and acknowledgement, specimen and study identifiers.
    Decision
    What has been requested, what has come back, and what is still outstanding.

  7. Follow-up and transfer

    The person moves on: discharged, referred onward, scheduled again, or handed to another organisation. Continuity depends on identifiers that the receiving system did not issue.

    Data
    Discharge and transfer records, onward referrals, follow-up appointments, correspondence.
    Decision
    Where responsibility sits next, and what travels with the person.

  8. Operational reporting

    Activity, waiting, capacity and cost are reported to management and to external bodies, each with its own definitions and submission windows.

    Data
    Activity and waiting measures, capacity utilisation, coding completeness, submission extracts.
    Decision
    What is reported, against which definition, for which period.

  9. Retention and review

    Records are kept, restricted or disposed of according to rules with long horizons, and the rule has to reach every derived copy, not just the source.

    Data
    Retention schedules, legal holds, consent state and withdrawal, access logs, disposal records.
    Decision
    What is kept, for how long, and who may still read it.

Where it breaks

Where health data estates break

Six failures that appear in health data estates repeatedly. Every one of them is an identity, purpose or timing problem before it is an analytics problem.

One person, several records, no maintained link

The same individual exists as separate records created at different entry points, and the duplicates are known but unmerged. FHIR anticipates this: a patient carries many identifiers, and record-to-record links are typed as replaces, replaced-by, refer or seealso rather than assumed away.

What it costsPathway measures count one person as several, follow-up correspondence goes to the wrong record, and any longitudinal view is quietly wrong in a direction nobody can size.

Permission is copied instead of evaluated

Access is decided once, when an extract is built, and then the extract circulates. The rule that justified it does not travel with it, and neither does its expiry.

What it costsWithdrawal of consent, a changed role or an expired purpose has no effect on the copies already in circulation, and the organisation cannot answer who could read what, when.

Purpose is not recorded, so it cannot be enforced

Consent is modelled as a flag rather than as what it is — a permit-or-deny decision, for named recipients, for specific purposes, over a defined period.

What it costsSecondary use cannot be separated from direct care in the data, so either legitimate operational analysis is blocked wholesale or it proceeds without a defensible basis.

Documentation lands after the measure is published

Notes, codes and results are completed days after the encounter, but activity and waiting measures run on a nightly schedule against whatever has arrived.

What it costsYesterday's numbers change under the reader, teams learn not to trust the report, and the shadow spreadsheet becomes the real management information.

Capacity is modelled as slots rather than as constraints

The appointment book knows about slots. Whether a slot can actually be used depends on staffing, room, equipment and turnaround time, which live elsewhere and are reconciled by a person.

What it costsSchedules are built that cannot be delivered, and the resulting cancellations are attributed to demand rather than to a planning assumption.

Corrections overwrite rather than supersede

An amended record replaces the earlier version in place, with no retained history of what was believed at the time a decision was taken.

What it costsAny retrospective review reconstructs the wrong picture, and the difference between a data correction and a genuine operational change becomes impossible to tell.

Functions

What each health function owns

Health organisations divide by function, and each function needs a different slice of the same records under a different justification. The foundation has to serve all six without collapsing them into one undifferentiated copy.

Healthcare functions, the operational question each owns, and what answering it requires
FunctionThe question it ownsData it needsAnalyticsDecision
Access and schedulingWhat can we actually offer, to whom, and when?Slot and resource availability, staffing rosters, preparation rules, referral queue and priorityCapacity modelling against real constraints, queue and wait analysis, non-attendance patternsWhat to offer, and where the bottleneck is worth addressing
Patient administrationIs this the same person, and is this record correct?Identifiers from every source, demographics, record links and merge history, correction logIdentity resolution with confidence retained, duplicate detection, merge-and-link reviewWhich record is authoritative, and which pairs need human review
Operations and flowWhere is the pathway slowing down, and why?Encounter and movement events, wait and turnaround measures, cancellation and transfer recordsFlow and bottleneck analysis, variation by site and team, provisional-versus-final comparisonWhich operational change to make, and where to staff differently
Information governanceWho may read this, for what purpose, and for how long?Consent state and provisions, role and purpose assertions, access logs, retention schedulesAccess review, purpose coverage analysis, retention and disposal trackingWhether a request is permitted, and what has to be withdrawn or disposed of
Finance and coverageWhat was delivered, under which arrangement, and what is outstanding?Activity records, coding and completeness, coverage and scheme eligibility, billing and claimsCoding completeness analysis, activity-to-revenue reconciliation, denial and rework patternsWhat to submit, what to correct, and which process is generating rework
Quality and reportingWhat do we report, against whose definition, for which period?Activity and waiting measures, submission extracts, definition catalogue, amendment historyDefinition reconciliation, completeness and lag measurement, internal-to-external comparisonWhat is published, and what caveat has to travel with it

Decisions

Four operational decisions, traced end to end

Four operational decisions, traced from the question to the measure that says whether the answer worked. None of these is a clinical decision. Nothing on this page supports diagnosis, treatment selection, triage of an individual patient or any other judgement that belongs to a clinician.

Where is operational capacity likely to become constrained?

  1. Question
  2. Data
  3. Analytics
  4. Decision
  5. Measurement

Data required

  • Referral and waiting-list volumes by priority
  • Slot and resource availability, including preparation and turnaround
  • Staffing rosters and planned absence
  • Historical non-attendance and cancellation rates
  • Seasonal and known-event context

Analytics

  • Forecasting of demand by pathway and priority
  • Capacity modelling against the binding constraint rather than slot count
  • Scenario comparison for staffing and session changes

Decision

Where to add, move or reshape sessions, and which waiting cohort to address first.

Measurement

  • Waiting time distribution by priority, not the mean alone
  • Proportion of offered slots that were deliverable
  • Non-attendance and short-notice cancellation rate
  • Forecast error at the planning grain

What this does not settleThis says where a queue is forming, not who should be seen first. Clinical prioritisation of an individual belongs to a clinician, and no model on this page substitutes for it.

Which records may this person or system retrieve for this task?

  1. Question
  2. Data
  3. Analytics
  4. Decision
  5. Measurement

Data required

  • Consent state with its provisions, purposes and effective period
  • Role and relationship of the requester to the person
  • Purpose asserted for this specific request
  • Record links, including unmerged duplicates
  • Access log of what has previously been resolved

Analytics

  • Permission evaluation at read time against caller, purpose and period
  • Identity resolution with a stated confidence threshold
  • Access review across requests, purposes and outcomes

Decision

Permit, refuse, or hold the request pending identity or purpose evidence.

Measurement

  • Proportion of requests decided at read time rather than by a standing extract
  • Purpose coverage: requests whose stated purpose maps to a recorded permission
  • Time to propagate a withdrawal to every derived view
  • Held requests resolved within the review window

What this does not settleA permission model implements the rules the organisation has decided on; it does not determine what those rules should be, and it is not a legal opinion about any jurisdiction's requirements.

Where are identity or record-quality problems interrupting the pathway?

  1. Question
  2. Data
  3. Analytics
  4. Decision
  5. Measurement

Data required

  • Candidate duplicate pairs with match confidence
  • Merge, link and unlink history
  • Correspondence and appointment failures by record
  • Correction and amendment log
  • Source-system identifier coverage

Analytics

  • Duplicate detection with confidence bands and human review queues
  • Failure-mode analysis linking record problems to operational events
  • Coverage analysis by source and entry route

Decision

Which record pairs go to review, and which entry route needs fixing at source.

Measurement

  • Estimated duplicate rate and the trend after intervention
  • Correspondence and appointment failures traced to a record problem
  • Median time from detection to resolution
  • Proportion of new records created with a full identifier set

What this does not settleAutomated matching proposes; it should not merge silently. A wrong merge is materially harder to undo than a missed one, which is why confidence belongs in the output and why linking is preferable to overwriting.

What has to be true before an operational measure is published?

  1. Question
  2. Data
  3. Analytics
  4. Decision
  5. Measurement

Data required

  • Documentation and coding completeness by lag day
  • Amendment and correction history
  • Definition catalogue with owners
  • Submission windows and external definitions
  • Provisional versus final flags on every measure

Analytics

  • Completeness-by-lag curves per measure
  • Provisional-to-final variance analysis
  • Definition reconciliation between internal and external versions

Decision

Whether to publish, with what caveat, and at which lag the measure is considered stable.

Measurement

  • Variance between provisional and final values
  • Proportion of measures with a named definition owner
  • Restatement frequency after publication
  • Submission accepted without correction

What this does not settleCompleteness curves describe how a measure settles; they do not make an incomplete period comparable to a complete one. Publishing a provisional figure without saying so is the failure this decision exists to prevent.

Illustrative interface

Access review — who resolved what, and under which purpose

A fictional screen showing the shape of an access review. No real organisation, person, record or system is represented, and every value here is invented.

Access review — who resolved what, and under which purpose
RequestPurpose assertedIdentity matchDecision
OK: Scheduling team · next-week capacityOperationsNot required — aggregate onlyPermitted
OK: Billing query · single accountPaymentExact on account and person identifierPermitted
Watch: Service review · 12-month extractOperationsTwo candidate records, unmergedHeld for identity review
Risk: Research extract · unconsented cohortSecondary useResolvedRefused — purpose not covered
  • Permitted — purpose covered and identity sufficient for the task
  • Held — the request is legitimate but the identity evidence is not yet good enough
  • Refused — no permission covers this purpose, regardless of identity

Data foundation

The healthcare data foundation

Health data arrives from systems with different identifier schemes, different clocks and different justifications for holding it. The foundation's job is to make them reconcilable while keeping the purpose and permission attached to every derived copy.

  1. Source systems

    Different identifier schemes and different clocks. The ten systems are enumerated in the inventory below.

    • Clinical and administrative records
    • Scheduling and resource systems
    • Diagnostics and orders
    • Billing, coverage and consent

  2. Ingestion

    Event time and record time captured separately

    • Interface and message intake
    • Batch extracts from administrative systems
    • Result and order feeds across organisations
    • Amendments carried as new versions

  3. Cloud platform

    One reconciled operational history

    • Raw landing preserved as received
    • Validated and deduplicated records
    • Pathway and activity models

  4. Identity & purpose

    The layer everything else depends on

    • Person and patient identity with confidence retained
    • Record links, including known duplicates
    • Purpose and consent provisions
    • Role and relationship of the requester

  5. Quality & definitions

    Definitions that survive an external submission

    • Completeness by lag, measured per measure
    • Declared definitions with named owners
    • Provisional and final states made explicit
    • Lineage from measure back to record

  6. Operational models

    Comparable across sites and against the external definition

    • Activity and waiting
    • Capacity against real constraints
    • Flow and bottleneck analysis
    • Coding and submission readiness

  7. Decision surfaces

    Access evaluated per request, not per extract

    • Operational and service reporting
    • Scheduling and capacity planning
    • Identity and record review queues
    • Permission-aware retrieval

  8. Action

    Operational and administrative only — never clinical

    • Session and capacity changes
    • Record merge and correction review
    • Access permitted, held or refused
    • Submission and correction
Reference architecture — a target-state shape, not a description of a client engagement.

Real time is rarely the constraint here. A capacity decision for next week needs a complete and reconciled picture far more than a fresh one, and a measure recomputed continuously changes under the person reading it. The harder requirement is that purpose and permission travel with the data into every derived view, because a model that evaluates access only at extract time cannot honour a withdrawal made afterwards. The ETL versus ELT sensitive-field boundary is useful when deciding whether an identifier may reach raw storage, an error artifact or a replay path. A query-time restriction alone does not settle those storage decisions.

10 source systems, and what to check before trusting each

  • EHR / EMR

    Encounters, documentation, coded observations, orders, amendments

    Check before trustingDocumentation completes days after the event; amendments may overwrite rather than supersede

  • Patient administration

    Person and patient identifiers, demographics, record links and merges

    Check before trustingThe authoritative identity record; duplicates are usually known here and unresolved elsewhere

  • Scheduling

    Slots, bookings, cancellations, non-attendance, resource calendars

    Check before trustingA slot is not capacity; deliverability depends on staffing and room data held in other systems

  • Laboratory and diagnostics

    Orders, specimens, results, acknowledgement status

    Check before trustingResults arrive on their own clock and often cross an organisational boundary

  • Imaging metadata

    Study and series records, modality, timing, report availability

    Check before trustingMetadata only for operational use; the images themselves are a separate governance question

  • Pharmacy and orders

    Medication orders, dispensing and administration records

    Check before trustingOrdered, dispensed and administered are three different events, frequently conflated

  • Billing and claims

    Activity, coding, coverage, submissions, denials and rework

    Check before trustingCoding completes after clinical documentation, so financial and operational views settle at different times

  • Consent and preferences

    Permit and deny provisions, purposes, recipients, effective periods

    Check before trustingWithdrawal has to reach derived copies; a consent flag without scope and period is not consent

  • Access and audit logs

    Who resolved what, when, and under which asserted purpose

    Check before trustingThe evidence base for any access review; frequently retained for less time than the records it describes

  • Reference and definitions

    Code systems, organisational hierarchy, measure definitions and owners

    Check before trustingExternal definitions change on their own schedule and rarely match the internal one exactly

Analytics & AI

From operational visibility to assistance, in dependency order

The progression below is a dependency chain rather than a maturity badge, and it has a hard ceiling: everything here supports operational and administrative decisions. Clinical decision support is a regulated activity with its own evidence requirements and is outside this scope.

  1. Operational visibility

    Activity, waiting, cancellations and capacity available to the teams running the service, on a stated schedule, with provisional periods marked as provisional.

    RequiresOne authoritative identity record, an agreed encounter definition, and a published refresh time

  2. Comparable measures

    The same measure means the same thing across sites and against the external definition it will be submitted under, with the differences documented rather than argued.

    RequiresA definition catalogue with named owners, and reconciliation between internal and external versions

  3. Diagnosis of flow

    Explaining where a pathway slows: which step, which site, which cohort, and how much of the movement is documentation lag rather than operational change.

    RequiresEvent timestamps that distinguish when something happened from when it was recorded

  4. Forecasting demand and capacity

    Projecting referral volume, attendance and resource requirement at the grain a scheduling decision is actually made in.

    RequiresStable historical definitions, non-attendance history, and a constraint model rather than a slot count

  5. Permission-aware retrieval

    Letting staff ask an operational question in language and get an answer grounded in records they are permitted to see, with the source shown and refusal as a valid outcome.

    RequiresAccess evaluated at read time, a curated corpus with owners, and an evaluation set that tests refusal as well as answers

  6. Bounded operational automation

    Narrow, reversible actions — flagging a duplicate pair for review, raising a capacity exception, drafting an administrative task — with a person accountable for each.

    RequiresEverything above, explicit action limits, a complete log, and formal exclusion of anything clinical

Maturity

A maturity progression, with readiness tests

Progress here is usually blocked by an unresolved identity or an unrecorded permission rather than by a missing capability. Each readiness test is deliberately concrete.

  1. Service visibility

    Each service can see its own activity, in its own definitions, mostly after the period has closed.

    Ready for the next stage whenOne identity record is authoritative, and the encounter definition is agreed and written down.

  2. Comparable services

    Activity, waiting and capacity mean the same thing across sites, and differences from the external definition are documented.

    Ready for the next stage whenEvery published measure has a named owner and a reconciliation against the definition it is submitted under.

  3. Explained variation

    Flow analysis separates genuine operational change from documentation lag and coding completeness.

    Ready for the next stage whenEvent time and record time are captured separately, and completeness-by-lag is measured per measure.

  4. Supported operational decisions

    Capacity, scheduling and identity decisions arrive with a recommendation, the evidence behind it, and a recorded override path.

    Ready for the next stage whenConstraints are modelled rather than assumed, and every recommendation has a named decision owner.

  5. Governed assistance

    Retrieval and bounded automation support administrative work, with permission evaluated per request and clinical decisions formally out of scope.

    Ready for the next stage whenAccess is decided at read time, withdrawal propagates to derived views, and refusal is tested as an outcome.

Measurement

What a health organisation should measure operationally

A measurement framework for the decisions above. Definitions vary more in healthcare than in most sectors, and the external definition a measure is submitted under is frequently not the internal one.

Healthcare operational measures, what each one captures, and the decision it informs
MeasureWhat it capturesDecision it informs
Waiting time distributionHow long people wait by priority, read as a distribution rather than a meanWhere to add capacity and which cohort to address first
Referral-to-first-contact timeElapsed time from referral receipt to the first delivered contactWhere the pathway entry process is losing time
Slot deliverabilityProportion of offered slots that could actually be delivered as offeredWhether the planning constraint model matches reality
Non-attendance rateAppointments not attended, by cohort, route and notice periodReminder policy, overbooking policy and access route design
Cancellation rate by originCancellations separated into organisation-initiated and person-initiatedWhich of the two problems is actually being managed
Documentation completeness by lagShare of encounters fully documented at each day after the eventThe lag at which a measure becomes stable enough to publish
Coding completenessProportion of activity coded and available for submission within the windowWhere coding capacity or process is the constraint
Estimated duplicate rateShare of person records with a probable duplicate awaiting reviewIdentity remediation priority and entry-route fixes
Access requests decided at read timeShare of retrievals authorised per request rather than by standing extractWhether permission is enforced or merely recorded
Withdrawal propagation timeElapsed time from a consent withdrawal to its effect in every derived viewWhether the governance model works in practice or only on paper

These are common operational measures and their usual reading, not results Quorlytic has produced for a client. None is a clinical or quality-of-care measure. Definitions differ between organisations and between internal and external reporting, which is why each one needs an owner before it is compared.

Principles

Principles we work to

The 6 principles this work is built on
  1. 01

    Treat consent as part of the data

    Permissions and consent are not metadata to add later. Carry purpose, access and retention context through ingestion, models and derived views. A de-identified extract is still governed by the rules that created it.

  2. 02

    Reconcile operational measures

    Bed use, wait times, throughput and cost each have local definitions. Agree what counts and who owns the process before aggregating. Reconcile source totals with the teams responsible for the operational result.

  3. 03

    Keep clinical judgement human

    Analytics can surface patterns, flag anomalies and support planning. Clinical decisions remain with qualified people. Separate decision support from any automated action, and define an escalation path.

    • Operational and capacity visibility
    • Consent-aware, purpose-specific views
    • Anomaly and quality signals for review
  4. 04

    Prove the path with one service line

    Choose a single operational question with accessible, permitted data. Establish the access boundary and acceptance test before extending the model to other services.

  5. 05

    Integration under purpose and consent constraints

    Healthcare integration is not only a technical exercise: each source carries consent, purpose and retention context that has to survive into every derived view. Design the minimum dataset for the question, keep the access boundary explicit, and make the audit trail answer who accessed which record for which purpose.

  6. 06

    Knowledge retrieval belongs behind the permission boundary

    Operational and clinical-adjacent documents can support planning, but retrieval has to enforce permissions before any content reaches a model, and a person has to remain responsible for clinical judgement. Start with read-only search over a bounded, owned collection, and evaluate refusals and citation accuracy as seriously as answers.

Engagement

How an engagement can progress

A typical engagement can progress through these stages. It is a sequence rather than a proprietary method, and in healthcare the identity and permission stages routinely take longer than expected because they are the ones that have to be right.

  1. Discover

    OutputAn inventory of the operational decisions in scope, who makes them, and what they currently use

  2. Map identity

    OutputA documented picture of how one person is represented across systems, including known duplicates and merge history

  3. Map purpose and permission

    OutputThe purposes data is held under, the permissions that exist, and where each is enforced today

  4. Audit the data

    OutputA source and quality map: what each system carries, how late it arrives, and where definitions differ

  5. Design the architecture

    OutputA target-state design with read-time access evaluation and event-versus-record time made explicit

  6. Build the foundation

    OutputPipelines, identity resolution with confidence retained, quality gates and the definition catalogue

  7. Build the decision layer

    OutputThe capacity, flow or access analysis the decision requires, validated against how the service measures itself

  8. Operationalise

    OutputMonitoring, named ownership, an access review process and a withdrawal propagation path

  9. Measure and improve

    OutputA decision-level measurement framework and the next pathway prioritised against it

Where this connects

Capabilities that support these decisions

  • Data Engineering

    Identity resolution, event-versus-record time and the quality gates every decision above depends on

  • Managed Data & AI

    Ownership, monitoring and the access-review process that keeps permission enforced rather than recorded

  • Enterprise AI Search

    Permission-aware retrieval over operational and administrative content, with refusal as a valid answer

  • Business Intelligence

    One definition of activity, waiting and capacity, owned and reconciled against external reporting

  • Data Science & Advanced Analytics

    Demand and capacity forecasting scoped to operational decisions, never clinical ones

  • Customer 360

    The identity-resolution pattern behind a single person view, with match confidence kept visible

Further reading, chosen for this pathway

Technical references

Questions

Questions worth asking.

Can sensitive records be used in the first project?

Begin with the minimum data needed and the strongest access boundary. Sensitive or identifiable records should be introduced only when the task requires them and the controls are agreed.

Your next data decision

Start with a clear problem.
Build what comes next.

Talk to a Data Expert

Bring the business question.
We'll help shape the engineering brief.