Conformance Statements

The matrix below is generated from the typed sources database. Before reading it, it is worth knowing where the evidence comes from that it rests on: a conformance statement is worth exactly what its confirmation is worth.

Checking behaviour, not code

Unit tests check code against the developer’s idea of the code: the same person writes both, in the same understanding, so a consistent misconception passes through. The platform’s verification apparatus checks behaviour against reference recordings carrying approved annotation: the same recording, the same expected conclusion, the same version. The reference comes from outside the code and outside whoever wrote it.

The publisher of the reference and its consumer are deliberately kept apart: the clinical corpus issues the reference recordings, the verification apparatus runs them. A system that invents the reference it checks itself against is checking its consistency with itself, not its conformance.

Evidence is a file, not a tick

A check answers neither with a line in a console nor with a green tick in an interface, but with a file: an acceptance receipt for the run and evidence for each verified area. The difference is practical — screen output disappears with the session, whereas an evidence file can be quoted, version-checked, and presented to a third party with no privileged access to the developer.

Integrity and adequacy are different claims

A distinction the industry keeps conflating:

  • a signature and a log prove integrity — what exactly is executing and where it came from;
  • adequacy — whether it is right — is proved separately: by reproducible evidence and human review.

A signed artifact can be a signed mistake. A system presenting a signature as proof of correctness is misleading — and the matrix below asserts the former, not the latter.

Conformance Statements

Precise statements of what is implemented in the product, what is partially addressed, and what is explicitly out of scope — per normative standard.

GUIDANCE

Design Considerations and Pre-Market Submission Recommendations for Interoperable Medical Devices
✓ Used as design basis for interface specification, V&V intent and labeling discipline.
✗ No FDA submission filed for HealthOS ICU v0 (pilot program); US market authorisation not in scope.
Source — FDA · Standards & Interoperability → Interoperability planes
Reference only
Clinical Decision Support Software — FDA Guidance
✓ Independent review of basis is supported: each recommendation traces to the term registry / term trace inside the active decision bundle.
✗ Predicate device claim, 510(k) submission and US market authorisation not part of HealthOS ICU v0 (pilot program).
Source — FDA · Safety Kernel and Equipment Control Commands · Glossary → Term registry.
Partial
Software as a Medical Device (SaMD): Application of Quality Management System
✓ Used to align internal QMS readiness vocabulary; no formal IMDRF self-assessment published.
✗ No formal IMDRF self-assessment published for HealthOS ICU v0 (pilot program).
Source — IMDRF · Regulatory & Geography → Quality management system (QMS)
Reference only
Software as a Medical Device (SaMD): Key Definitions
✓ Cited to justify product positioning as software in a medical device / accessory / active control system, not standalone SaMD.
✗ This is a definitional and positioning reference only.
Source — IMDRF · Why Not Artificial Intelligence → Regulatory positioning
Reference only
MDCG 2019-11 — Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745
✓ Used as classification basis for product positioning as accessory / regulated MDSW, not standalone SaMD.
✗ This is a positioning reference, not a conformity statement. CE marking not part of HealthOS ICU v0 (pilot program).
Source — European Commission · Why Not Artificial Intelligence → Regulatory positioning
Reference only

STANDARD

HL7 Version 2 / MLLP
✓ Inbound HL7 v2 / MLLP push is consumed by the device protocol gateway and routed into the stateful rule-based analyzer in the control / telemetry plane.
✗ No outbound HL7 v2 publication back to HIS; no HL7 v2 ORU result push from product side.
Source — HL7 International · Standards & Interoperability → Equipment Plane
Implemented
HL7 FHIR R4
✓ Observation, Device, DeviceMetric, GuidanceResponse, Provenance, AuditEvent emitted via the clinical-data facade as downstream projection of the canonical event log.
✗ Clinical facade is not the source of truth; FHIR Subscriptions push, Bulk Data, SMART on FHIR auth not implemented.
Source — HL7 International · Standards & Interoperability → Record Plane
Implemented
IHE Patient Care Device (PCD) Technical Framework
✓ Architectural slot for an IHE DEV / PCD adapter (PCD-01 / DEC / ACM) in the reference architecture; four-level vendor adapter model accommodates PCD profile mapping.
✗ Concrete profile actor implementations and IHE Integration Statement are roadmap items.
Source — IHE International · Standards & Interoperability → Interoperability planes
Partial
IHE SDPi — Service-oriented Device Point-of-care Interoperability
✓ SDPi-compliant adapter is planned as a roadmap item alongside ISO/IEEE 11073 SDC support.
✗ No SDPi actor shipped in HealthOS ICU v0 (pilot program).
Source — IHE International · Standards & Interoperability → Interoperability planes
Planned
ISO/IEEE 11073-10207 — SDC: Service-oriented Device Connectivity
✓ Read path (bidirectional observation over SDC) is partially implemented: the reference architecture reserves an adapter slot and the vendor adapter model already supports ingesting telemetry from SDC-capable devices.
✗ Write path (governed restricted-write control over SDC) is not part of HealthOS ICU v0 (pilot program): native bedside control remains on the roadmap, gated by phased validation and a vendor-supplied access-and-control package.
Source — ISO · Standards & Interoperability → Interoperability planes · Technical Overview "Safety Kernel & Command Envelopes"
Partial
SHACL — Shapes Constraint Language (W3C Recommendation)
✓ Constraint layer over the medical knowledge graph; the validation digest is part of every release receipt issued by the knowledge compiler.
✗ Not used for inbound runtime data validation in the bedside path (handled by deterministic decoders).
Source — W3C · Glossary → Medical knowledge graph store. · Glossary → Evidence-of-fact receipt
Implemented
PROV-O — The PROV Ontology (W3C Recommendation)
✓ Provenance graph emitted as FHIR Provenance plus an internal release receipt with cryptographically chained digests for graph, validation, projection, mapping spec and bundle.
✗ Direct PROV-O JSON-LD export endpoint not part of HealthOS ICU v0 (pilot program) surface.
Source — W3C · Glossary → Evidence-of-fact receipt
Implemented
DICOM Standard
✓ DICOMweb (WADO-RS / QIDO-RS) used only in auxiliary plane for retrospective episode visualization, augmented by results and audit data.
✗ DICOM is not used as bedside command transport, not as stream-mode ingress, not to carry command intents.
Source — DICOM Standards Committee · Standards & Interoperability → Auxiliary Plane
Partial
ISO 13485:2016 — Medical devices — Quality management systems
✓ Design controls and change-controlled gates for validation, audit and security live in active-draft governance artifacts.
✗ No notified-body certificate issued; QMS certification is a separate productisation track.
Source — ISO · Regulatory & Geography → Quality management system (QMS)
Partial
ISO 14971:2019 — Medical devices — Risk management
✓ Risk management framework outlined in supporting research; formal hazard analysis integration into product RMF is not part of HealthOS ICU v0 (pilot program).
✗ No formal hazard analysis dossier published yet.
Source — ISO · Regulatory & Geography → Risk management
Planned
IEC 62304:2006+AMD1:2015 — Medical device software — Software life cycle processes
✓ Software lifecycle structure (design / spec / runbook gates), change control through the compiled bundle and release receipt, anomaly handling via the audit event log.
✗ SOUP register, formal classification (Class B / C) and full IEC 62304 dossier are not part of HealthOS ICU v0 (pilot program).
Source — ISO · Regulatory & Geography → Software lifecycle
Partial
IEC 82304-1 — Health software — Part 1: General requirements for product safety
✓ Referenced for general health software safety framing; formal assessment is planned alongside the IEC 62304 dossier, not part of HealthOS ICU v0 (pilot program).
✗ No formal IEC 82304-1 dossier or certification for HealthOS ICU v0 (pilot program).
Source — ISO · Regulatory & Geography → Software lifecycle
Planned

REGULATOR

SAHPRA — South African Health Products Regulatory Authority
✓ South Africa is the first-market regulatory entry target; establishment licensing and clinical evaluation path under active planning.
✗ No SAHPRA registration filed for HealthOS ICU v0 (pilot program).
Source — SAHPRA · Regulatory & Geography → Geographic priority
Planned
BoMRA — Botswana Medicines Regulatory Authority
✓ Botswana is a secondary market target following South Africa entry.
✗ No BoMRA submission planned for HealthOS ICU v0 (pilot program).
Source — BoMRA · Regulatory & Geography → Geographic priority
Planned
ANVISA RDC 657/2022 — Brazil Medical Device Regulation
✓ Cited as a fast-follow market option (Brazil); RDC 657/2022 framework reviewed for compatibility.
✗ No ANVISA submission planned for HealthOS ICU v0 (pilot program).
Source — ANVISA · Regulatory & Geography → Geographic priority
Reference only
NPRA — National Pharmaceutical Regulatory Agency (Malaysia)
✓ Malaysia is a planned market target following South Africa and Botswana entry.
✗ No NPRA registration filed for HealthOS ICU v0 (pilot program).
Source — NPRA · Regulatory & Geography → Geographic priority
Planned
PPB — Guideline on Regulation of Medical Device Software in Kenya (MDSW)
✓ Kenya is a planned market target, fourth in the go-to-market sequence.
✗ No PPB submission filed for HealthOS ICU v0 (pilot program).
Source — PPB Kenya · Regulatory & Geography → Geographic priority
Planned
CDSCO — Central Drugs Standard Control Organisation (India)
✓ India is a planned market target following Malaysia and Kenya entry.
✗ No CDSCO submission filed for HealthOS ICU v0 (pilot program).
Source — CDSCO · Regulatory & Geography → Geographic priority
Planned
Regulation (EU) 2024/1689 — Artificial Intelligence Act
✓ Per-command event log, human confirmation, and technical documentation drawn from release receipts — the evidence a high-risk system would need under the regulation — are produced as a by-product of normal operation.
✗ No conformity statement is made under the regulation; qualification of the recommendation computation path under Article 3(1) is a regulatory assessment specific to each jurisdiction.
Source — EUR-Lex (Official Journal of the EU) · Regulatory & Geography
Reference only
Regulation (EU) 2016/679 — General Data Protection Regulation
✓ Cited to frame the data-protection architecture (audit event log, Provenance, export de-identification) for future EU deployments; no formal GDPR compliance audit conducted.
✗ No Data Protection Impact Assessment or GDPR certification issued for HealthOS ICU v0 (pilot program).
Source — EUR-Lex (Official Journal of the EU) · Conformance Statements
Reference only
HIPAA — Health Insurance Portability and Accountability Act (US)
✓ Cited to frame US health-data handling considerations for a future US-market path; the same architectural properties as GDPR (audit event log, Provenance, export de-identification) apply. No covered-entity or business-associate determination made.
✗ No HIPAA compliance assessment, Business Associate Agreement, or Security Rule audit conducted for HealthOS ICU v0 (pilot program).
Source — U.S. HHS · Conformance Statements
Reference only

VENDOR

Philips IntelliBridge Enterprise / IntelliVue / MDIP / ICCA — Public Documentation
✓ Used as basis for the vendor interoperability matrix; per-vendor write-scope claims pinned to vendor public statements only.
✗ Site does not assert any private capability beyond what Philips publishes; per-site validation packs are separate productisation work.
Source — Philips · Technical Overview "Vendor Interoperability Matrix"
Reference only
Dräger Infinity / SDC / Evita / Atlan / MEDIBUS.X — Public Documentation
✓ Used as basis for the vendor interoperability matrix; per-vendor claims pinned to Dräger public documentation only.
✗ Site does not assert private capability beyond what Dräger publishes.
Source — Dräger · Technical Overview "Vendor Interoperability Matrix"
Reference only
GE Healthcare Aisys CS2 / CARESCAPE — Public Documentation
✓ Used as basis for the vendor interoperability matrix; per-vendor claims pinned to GE Healthcare public documentation only.
✗ Site does not assert private capability beyond what GE Healthcare publishes.
Source — GE Healthcare · Technical Overview "Vendor Interoperability Matrix"
Reference only