Healthcare data interoperability

The technical, syntactic, semantic and organisational levels of interoperability, the standards Anpheros uses (FHIR R4, IPS, SMART on FHIR, HL7 v2) and why provenance makes exchanged data trustworthy.

Healthcare data interoperability is the ability of different systems — apps, clinics, laboratories, hospitals, AI services — to exchange health data and use it without re-interpreting it by hand. Anpheros approaches it by storing every record in the formats other systems already understand (HL7 FHIR R4 with standard code systems), by exchanging it through standard protocols (FHIR REST, SMART on FHIR, the International Patient Summary, HL7 v2 laboratory messages) and by keeping the context that makes exchanged data trustworthy: who wrote it, when, and with whose consent.

Four levels of interoperability

Level	Question it answers	How Anpheros addresses it
Technical	Can the systems connect?	HTTPS APIs, OAuth 2.1, signed webhooks, SDKs in Dart and TypeScript
Syntactic	Can they parse each other's data?	HL7 FHIR R4 (4.0.1) resources and bundles; CSV, HL7 v2 ORU^R01 and JSON accepted for lab results
Semantic	Do they mean the same thing?	LOINC for measurements and results, ICD-10 for conditions, ATC for medications, UCUM for units; original text kept next to every code
Organisational	May they exchange it, and can they trust it?	patient consent per application, provenance on every write, an access log visible to the patient

Most integration projects fail at the semantic and organisational levels, not the technical one. Coding at write time and recording provenance for every value are what make data from one source usable in another.

Standards Anpheros uses

HL7 FHIR R4. Every record is made of FHIR resources — 26 types — searchable and versioned, with a CapabilityStatement at /fhir/R4/metadata. FHIR platform
International Patient Summary (IPS). Patient/{id}/$summary returns an IPS document bundle, validated with the official HL7 validator against hl7.fhir.uv.ips#1.1.0 with 0 errors. The IPS is the summary format intended for cross-border care in Europe.
HL7 Europe laboratory report rules. Lab results are checked on write; gaps are reported in the Anpheros-Conformance response header (advisory today). Observation/$validate?profile=eu-lab runs the check on demand.
SMART on FHIR. Third-party applications reach a record through OAuth 2.1 with PKCE and SMART v2 patient scopes; discovery at /fhir/R4/.well-known/smart-configuration. The standalone launch test group of the Inferno SMART App Launch STU2 suite passes; EHR launch is not supported yet.
HL7 v2. Laboratory results arrive as ORU^R01 messages as well as CSV or JSON, and become FHIR Observations. Lab connector
European Health Data Space. FHIR R4 and the IPS are the formats the EHDS relies on for patient summaries and laboratory results; Anpheros follows them. This is alignment with the formats, not a certification.

Exchange patterns

Consented application access — an application asks the patient for scopes, reads and writes the record through FHIR or REST, and loses access when the patient revokes it.
Document exchange — the record, or its summary, leaves as a FHIR bundle ($everything, $summary).
Inbound results — laboratories and clinics write into the record on behalf of their organisation; the patient sees who wrote what.
Events — subscribers are told that something changed (ids only, never clinical content) and read what they are allowed to.

Provenance: interoperability you can trust

Data that travels between systems loses its context unless the context travels with it. In Anpheros every version of every resource records:

the author type — patient, practitioner, device, import or AI;
the organisation on whose behalf it was written and, when named, the practitioner;
the source system and the record's id there (X-Anpheros-Source-System, X-Anpheros-Origin-Id).

Values produced by AI are labelled as such and are kept apart from clinical facts when a context is built for a model.

Identity across applications

Each application sees its own identifier for the same person (pairwise ids), so records cannot be correlated between applications behind the patient's back. References to people outside an application's scope are masked. Interoperability happens through consent, not through shared identifiers.