Health data is abundant.Clinical meaning must be engineered.
Digital health platforms connect people, records, devices, services, algorithms and workflows across organizational boundaries. The operating unit is a governed health-data event with verified identity, explicit provenance, semantic meaning, authorized use, clinical ownership and a traceable effect on care.
EVENT
A platform does not become clinical because it stores health-related data.
Digital health platforms may support care navigation, communication, longitudinal records, device connectivity, patient engagement, virtual care, analytics, clinical decision support, population health, research and administration. Their risk changes with intended use, user, autonomy, data type, clinical consequence and whether the software drives or merely supports a decision.
Patient and workforce interfaces
Portals, applications, messaging, accessibility and task design translate system state into action.
Coordinate clinical operations
Orders, results, referrals, tasks, alerts, scheduling and documentation need explicit ownership.
Preserve meaning across systems
Identity, terminology, provenance, version, units and context determine whether exchange is usable.
Constrain risk and change
Authorization, consent, validation, cybersecurity, audit, release and incident response govern operation.
Interoperable does not mean clinically equivalent. Accessible does not mean authorized for every purpose. Structured data is not automatically correct data. A predictive score is not a diagnosis. “AI-powered” does not define regulatory status, evidence quality or accountability. The software function, context of use and consequence determine the control level.
A usable datum must survive every semantic handoff.
Separate the layers so failure does not become invisible coupling.
WORKFLOW
| Layer | Primary responsibility | Required contract | Failure signal | Control owner |
|---|---|---|---|---|
| Experience | Patient, caregiver and workforce interaction | Accessible states, identity context and safe confirmation | Abandonment, misclick, hidden urgency | Product + clinical operations |
| Workflow | Tasks, queues, orders, alerts and handoffs | State model, owner, priority and closure | Orphan task or unresolved result | Clinical service owner |
| Application services | Scheduling, messaging, care plans, rules and APIs | Versioned behavior and failure handling | Silent partial transaction | Engineering + product |
| Interoperability | Exchange and translation | Profile, terminology, cardinality and provenance | Valid syntax with wrong meaning | Integration governance |
| Data platform | Operational and analytical persistence | Canonical model, lineage, retention and quality | Duplicate patient or stale state | Data governance |
| Trust layer | Identity, access, consent, audit and security | Policy decision and enforcement evidence | Unauthorized or untraceable action | Security + privacy |
The patient is not an account, and consent is not one checkbox.
False merge can expose one person’s record to another and contaminate clinical decisions; false split can hide allergies, results or prior treatment. Matching performance, manual review, correction and propagation are patient-safety functions—not back-office cleanup.
Exchange the clinical meaning—not merely a valid payload.
A FHIR resource can be syntactically valid while clinically incomplete, mapped to the wrong code, attached to the wrong encounter or delivered into a queue nobody owns. Interoperability is achieved only when the receiving workflow can interpret and act safely.
Ingestion must preserve the measurement’s context of use.
A recommendation must expose enough basis for the user to challenge it.
| Function | Example | Risk question | Control | Boundary |
|---|---|---|---|---|
| Administrative support | Scheduling or eligibility workflow | Can failure delay necessary care? | Queue monitoring and exception handling | Not risk-free because it is “nonclinical” |
| Reference support | Patient-specific guideline reminder | Can clinician independently review basis? | Source, logic and patient inputs exposed | Regulatory treatment depends on function/jurisdiction |
| Predictive model | Deterioration risk score | Does score drive urgent allocation? | Validation, calibration, drift, subgroup and workflow trial | AUC alone does not show clinical utility |
| Signal analysis | ECG, image or sensor interpretation | What harm follows false output? | Device-quality evidence and regulated lifecycle where applicable | May constitute medical-device software |
| Autonomous action | Therapy adjustment or closed-loop control | Can the user intervene before harm? | High-assurance design, fail-safe and surveillance | Human nominally present may not equal meaningful oversight |
Model performance can decay while the interface still looks perfectly healthy.
Representativeness and leakage
Define cohort, labels, missingness, time, site, intervention effects and protected subgroups.
- Separate training from deployment reality
- Detect proxy variables
- Preserve dataset lineage
Performance in context
Discrimination, calibration, thresholds and clinical utility need external and workflow-specific evidence.
- Average performance can hide harm
- Retrospective accuracy is not impact
- Comparator must reflect actual practice
Human-system interaction
Alert design, automation bias, workload, latency, override and fallback determine real behavior.
- Shadow test before action
- Version every output
- Control silent model updates
Drift and safety signals
Monitor input shift, calibration, subgroup performance, overrides, missed cases and downstream outcomes.
- Define rollback criteria
- Investigate feedback loops
- Retire when benefit no longer holds
Availability, integrity and confidentiality are all clinical safety properties.
| Threat | Clinical consequence | Preventive control | Detection evidence | Recovery objective |
|---|---|---|---|---|
| Account takeover | Unauthorized record access or fraudulent action | Strong authentication, session and privilege controls | Behavioral anomaly and access audit | Contain account, preserve care access, correct actions |
| Ransomware / outage | Orders, records, communication and devices unavailable | Segmentation, hardening, backup and rehearsed downtime | Endpoint/network telemetry | Safe degraded operation and prioritized restoration |
| Data manipulation | Wrong medication, result or identity state | Integrity checks, authorization, provenance and reconciliation | Unexpected change, signature/version mismatch | Identify affected decisions and restore trusted state |
| API abuse | Exfiltration or service disruption at scale | Scoped tokens, rate limits, schema validation and monitoring | Usage anomaly and failed-policy logs | Revoke safely without blocking urgent care |
| Supply-chain compromise | Trusted update introduces exposure or behavior change | Vendor assurance, component inventory and signed releases | SBOM intelligence and runtime monitoring | Isolate, rollback and communicate affected functions |
| Insider misuse | Improper access, disclosure or manipulation | Least privilege, separation of duties and purpose controls | Audit review and break-glass analysis | Stop misuse, notify, remediate and preserve evidence |
Every deployment is a clinical intervention when it changes care behavior.
Define the changed function
UI, terminology, interface, rule, model, permission and infrastructure changes carry different risk.
Test the technical contract
Unit, integration, security, migration, performance and rollback tests establish mechanical behavior.
Test the clinical workflow
Representative users and patient scenarios expose interpretation, workload and downstream effects.
Watch after release
Phased rollout, feature flags, telemetry, incident thresholds and rapid rollback constrain harm.
Terminology updates, API versions, alert thresholds, model weights, vendor dependencies and default settings can materially alter output without changing the visible product name. The deployed version and its clinical configuration must remain reconstructable.
The architecture proves itself at the failure boundary.
Release is not comprehension
- Control
- Abnormal result ownership and non-response escalation.
- Failure
- Mark care complete when result becomes visible online.
One drug, conflicting states
- Control
- Source, time and author retained through merge.
- Failure
- Newest interface value automatically overwrites correct history.
Valid message, wrong meaning
- Control
- Patient, specimen, method and corrected-result handling.
- Failure
- Display numeric value without local reference context.
Duplicate measurements
- Control
- Retain raw provenance and deterministic duplicate rule.
- Failure
- Inflate instability from retransmitted values.
Score without response capacity
- Control
- Staffing, latency, override and downstream outcome.
- Failure
- Deploy high-performing model into an unowned inbox.
Sent is not scheduled
- Control
- Closed-loop state and failed-contact recovery.
- Failure
- Measure referral creation instead of completed care.
Similar demographics, different people
- Control
- High-risk merge threshold and reversible correction.
- Failure
- Auto-merge to improve a duplicate-rate metric.
Stopping future use
- Control
- Separate prospective restriction from lawful prior processing.
- Failure
- Change a UI flag without enforcing it in connected systems.
Draft is not the record
- Control
- Source retention, hallucination checks and attribution.
- Failure
- Auto-file unsupported negatives or diagnoses.
Partial transaction
- Control
- Idempotency, transaction status and clinical fallback.
- Failure
- Repeat an order because the response—not action—failed.
Access changes with relationship
- Control
- Age, capacity, revocation and record segmentation.
- Failure
- Treat shared login credentials as valid delegation.
Continuity beyond the contract
- Control
- Portable data, keys, audit logs, device continuity and deletion evidence.
- Failure
- Discover proprietary dependency during termination.
The platform boundary extends through every dependency that can change care.
| Dependency | Due diligence | Operational evidence | Exit requirement | Hidden risk |
|---|---|---|---|---|
| Cloud / infrastructure | Regions, resilience, access model and shared responsibility | Availability, backup, recovery and incident tests | Data/keys/log migration | Concentration across “different” vendors |
| Integration vendor | Mapping method, testing and support | Interface errors, queue depth and reconciliation | Mappings and specifications | Undocumented semantic transformation |
| Device partner | Intended use, validation, firmware and security | Fleet, versions, failure and recall traceability | Replacement and data continuity | Consumer hardware substituted silently |
| AI/model provider | Data, validation, change policy and regulatory status | Version output, drift, subgroup and incident reporting | Model/data portability and safe disablement | Unannounced upstream model change |
| Communication service | Routing, identity, delivery, consent and retention | Delivery state and failed-message escalation | Template, log and number/domain transfer | Delivered status mistaken for understanding |
Measure whether the platform improves care—not whether users opened it.
Digital health platforms, defined precisely.
What is a digital health platform?
It is a governed technology environment that connects health users, data, services and workflows. A platform can support multiple applications and organizations, but its clinical value depends on identity, semantics, ownership, evidence and safe operational integration.
Does using FHIR guarantee interoperability?
No. FHIR supplies exchange structures and implementation mechanisms. Systems still need aligned profiles, terminology, identifiers, workflow meaning, provenance, authorization and end-to-end clinical validation.
What is Software as a Medical Device?
SaMD generally refers to software intended for one or more medical purposes that performs those purposes without being part of a hardware medical device. Exact classification and obligations depend on intended use and jurisdiction.
Is all clinical decision-support software a medical device?
No. Regulatory treatment depends on the software function, user, inputs, ability to independently review the basis, intended use and risk. Some functions may be excluded or outside active device oversight, while others are regulated.
Why is patient matching a safety issue?
A false merge can expose or combine different people’s data, while a false split can hide important allergies, results or history. Both can alter clinical decisions and require controlled correction across connected systems.
How should health platforms govern AI models?
They should define intended use, data lineage, validation, calibration, subgroup performance, human interaction, version control, drift monitoring, incidents, rollback criteria and retirement.
Can patient-generated data be treated like hospital measurements?
Not automatically. Device validation, patient assignment, technique, acquisition context, units, transmission, quality flags and plausibility determine whether the value is fit for a clinical decision.
Is this page medical, technical or legal advice?
No. It is a digital-health platform system model. Specific deployments require qualified clinical, security, privacy, regulatory, interoperability and jurisdictional review.
Intended use, semantic integrity and measurable clinical value before platform claims.
Primary starting points include the U.S. health-IT interoperability resources, HL7 FHIR specification, FDA Software as a Medical Device framework, FDA Clinical Decision Support Software guidance, NIST Cybersecurity Framework and the WHO digital-health program. Application requires current jurisdiction-specific privacy and medical-device rules, adopted interoperability profiles, validated terminology, documented context of use and clinical safety governance.