Technical honesty · Method note 01
What this exhibit can—and cannot—show.
An OpenHIE-inspired behavioral miniature of selected HIE workflows, built to make boundaries inspectable without turning a teaching model into a standards claim.
Use the 15-minute guided tour- Architecture
- OpenHIE 5.2
- Published
- August 2024
- Sources accessed
- 10 August 2026
- Demo model
- 1.0.0
Scope
Claims stay smaller than the picture.
The exhibit is deliberately specific about what comes from a source, what the simulator chooses, and what exists only to make a difficult mechanism teachable.
The mechanism is real enough to inspect: separate systems know different things, a routed transaction crosses explicit trust and meaning boundaries, failures stop before the wrong commit, and recovery leaves evidence. The services, people, payloads, credentials, times, policies, and results are not real.
“Accepted” means only that a synthetic artifact passed this toy’s authored checks. It does not mean medically correct, clinically appropriate, secure, lawful, interoperable at scale, or safe for care.
Specified
A claim directly supported by the cited primary specification.
Implementation choice
One bounded way this simulator realizes a capability the source leaves variable.
Pedagogical extension
An authored teaching device, named as such and never attributed to the standard.
Architecture doctrine
A governed journey, not one enormous database.
The map describes responsibilities and contracts. It does not prescribe a server count, product list, or national deployment topology.
Shown
Logical architecture
Capabilities, authority boundaries, dependencies, and the messages that cross between them.
- One logical component can be supplied by many products.
- One product can supply several logical components.
- Only services invoked by the active transaction illuminate.
Not shown
Physical architecture
Hosts, zones, databases, queues, networks, regions, operators, and vendor products.
- No box means “one server.”
- No route demonstrates encryption or availability.
- No layout is a deployment recommendation.
The orientation mnemonic
Different questions, different authorities.
- For whom
- Client Registry
- By whom
- Health Worker Registry
- Where
- Facility Registry
- What care or meaning
- Terminology Service + Shared Health Record
- What product
- Product Catalogue + LMIS
- Who pays
- Finance and Insurance Service
The Interoperability Layer coordinates those answers without becoming authoritative for any of them.
Reference and master data
Client, facility, worker, product, and terminology services govern stable reference facts.
Semantic mapping
A Terminology Service validates codes and supplies a versioned relationship between meanings.
Structural transformation
An IOL mediator creates a new wire shape, preserving and linking the immutable source artifact.
There is no generic canonical OpenHIE component called “the reference and translation service.” A mediator may apply a mapping obtained from a Terminology Service; it may not invent clinical equivalence. When a component is outside the active route, the exhibit says Not invoked in this transaction.
Component/source map
Every service owns less than the whole.
All rows use the architecture exports that drive the exhibit. OpenHIE sources are published 5.2; every source was accessed 10 August 2026.
Point-of-service systems
Systems that own their local workflow and source records.
point of service
Community or mobile application
Captures a small synthetic registration artifact in a field workflow.
Invoked transactions
Field registration
Variation and simplification
- Real-world variation
- May be a mobile app, community-health-worker tool, or offline-capable client.
- This exhibit
- Represented by one committed synthetic fixture; no device or synchronization layer.
point of service
Clinic electronic health record
Owns Lumenbank Clinic local identity, encounter, order, and result workflow context.
Invoked transactions
Find shared history · Laboratory order · Laboratory result receipt
Variation and simplification
- Real-world variation
- A point-of-service system may use different exchange protocols and local data models.
- This exhibit
- One authored encounter and one laboratory workflow.
point of service
Hospital electronic health record
Performs a later permitted cross-town identity query and limited summary retrieval.
Invoked transactions
Cross-town identity query · Permitted limited summary retrieval
Variation and simplification
- Real-world variation
- Hospital systems and disclosure rules vary by deployment.
- This exhibit
- The hospital receives only a deliberately tiny summary.
point of service
Laboratory information system
Receives a normalized order and asserts an immutable synthetic result.
Invoked transactions
Laboratory order · Laboratory result
Variation and simplification
- Real-world variation
- Laboratory exchanges may use HL7 v2, FHIR, profiles, or other governed formats.
- This exhibit
- One plausible synthetic haemoglobin result without interpretation.
point of service
Pharmacy or dispensing system
Creates a minimum dispense or supply event after resolving product identity.
Invoked transactions
Dispense and supply
Variation and simplification
- Real-world variation
- Dispense and logistics boundaries vary between implementations.
- This exhibit
- No prescription, pricing, or clinical chart is sent to logistics.
Interoperability and trust
Coordination, technical trust, relationships, matching, and policy decisions.
interoperability
Health Interoperability Layer / IOL
Authenticates systems, invokes policy, validates, routes, mediates, orchestrates, logs, queues, and replays.
Invoked transactions
Find shared history · Laboratory exchange · Dispense and supply · Eligibility and claim · Aggregate export · Cross-town retrieval
Variation and simplification
- Real-world variation
- Logical capabilities may be centralized, federated, or supplied by multiple products.
- This exhibit
- A deterministic in-memory reducer represents mediation and operations.
trust
Authentication capability
Returns a clearly simulated sending-system credential outcome.
Invoked transactions
Sender check · Cross-town requester check
Variation and simplification
- Real-world variation
- Real identity proofing, key management, and authentication are deployment-specific.
- This exhibit
- No real secrets, tokens, encryption, or identity proofing.
interoperability
Interlinking service / interlinked registry view
Verifies authored practitioner-role, organization, location, and service relationships.
Invoked transactions
Worker–organization–location–service verification
Variation and simplification
- Real-world variation
- May be materialized, computed, or managed through other directory capabilities.
- This exhibit
- One authored relationship is checked synchronously.
interoperability
Entity matching capability
Represents exact, possible, ambiguous, and no-match identity outcomes.
Invoked transactions
Identity resolution · Ambiguous-identity recovery
Variation and simplification
- Real-world variation
- Algorithms, thresholds, governance, and adjudication vary significantly.
- This exhibit
- Fixed outcomes; any score is explicitly a teaching score.
trust
Policy, authorization, purpose, and disclosure accounting
Evaluates an authored requester, role, organization, purpose, category, time, and directive input.
Invoked transactions
Limited history disclosure · Clinical save · Cross-town disclosure
Variation and simplification
- Real-world variation
- There is no single canonical OpenHIE consent component; governance is deployment-specific.
- This exhibit
- A transparent fixed teaching rule set; no real enforcement or compliance claim.
Reference and registry services
Governed identity, directory, terminology, and product reference facts.
reference
Client Registry / CR
Links retained local identifiers to one synthetic enterprise client identity.
Invoked transactions
Identity resolution · Cross-town identity query
Variation and simplification
- Real-world variation
- Registries differ in matching rules, federation, and identifier governance.
- This exhibit
- Two local identifiers are pre-linked in the happy path.
reference
Facility Registry / FR
Returns canonical facility identity, hierarchy, operational status, services, and endpoint.
Invoked transactions
Trust lookup · Cross-town requester lookup
Variation and simplification
- Real-world variation
- Data governance and endpoint directories vary.
- This exhibit
- Three fictional facilities with reserved endpoints.
reference
Health Worker Registry / HWR
Returns canonical synthetic worker identity, role, status, and facility relationship.
Invoked transactions
Trust lookup · Cross-town requester lookup
Variation and simplification
- Real-world variation
- Workforce directories and role models vary by jurisdiction.
- This exhibit
- One active and one inactive fictional worker.
reference
Terminology Service / TS
Validates a tiny code set and governs versioned semantic mappings.
Invoked transactions
Laboratory order normalization · Laboratory result validation
Variation and simplification
- Real-world variation
- Terminology products, licensing, governance, and APIs vary.
- This exhibit
- One sourced LOINC target concept and small authored edge cases.
reference
Product Catalogue / PC
Resolves a fictional local pack to a canonical fictional product identity.
Invoked transactions
Product identity resolution
Variation and simplification
- Real-world variation
- Catalogue standards and product identifiers vary by context.
- This exhibit
- One deliberately non-GS1 fictional product.
Business-domain services
Separate clinical, reporting, supply, and finance truth boundaries.
clinical
Shared Health Record / SHR
Stores a normalized, operational, person-centric subset of shared clinical artifacts and versions.
Invoked transactions
Limited history query · Normalized result save · Cross-town retrieval
Variation and simplification
- Real-world variation
- Shared-record scope, persistence, and access patterns differ widely.
- This exhibit
- A small in-memory versioned artifact list.
population
HMIS / routine health information system
Owns a later periodic aggregate reporting fact without patient drill-through.
Invoked transactions
Periodic aggregate export
Variation and simplification
- Real-world variation
- Indicators, periods, validation, and reporting pipelines vary.
- This exhibit
- One count with a persistent small-cell warning.
supply
Logistics Management Information System / LMIS
Applies an idempotent stock decrement and may issue a replenishment signal.
Invoked transactions
Minimum supply event · Replenishment signal
Variation and simplification
- Real-world variation
- Stock accounting and replenishment rules are implementation-specific.
- This exhibit
- One product/facility balance; no patient identifier or history.
finance
Finance and Insurance Service / FIS
Owns entirely fictional eligibility, claim, and finance states.
Invoked transactions
Eligibility and claim
Variation and simplification
- Real-world variation
- Coverage, claims, and finance architecture are jurisdiction-specific.
- This exhibit
- No real scheme rule, identifier, policy, price, or determination.
Evidence
Redacted system evidence and artifact lineage, kept conceptually separate.
evidence
Audit and provenance evidence
Keeps separate evidence of security/operational events and artifact derivation.
Invoked transactions
Every routed transaction and every derivation activity
Variation and simplification
- Real-world variation
- Retention, integrity controls, formats, and access are policy- and implementation-specific.
- This exhibit
- Ephemeral synthetic arrays with no raw clinical values or credentials in audit.
Claim matrix
Source, implementation, omission.
A source can support a capability without prescribing this exhibit’s exact choreography. The classification names that distance.
| Claim | Primary source | The exhibit implements | The exhibit omits | Class |
|---|---|---|---|---|
| OpenHIE is a logical, notional architecture whose components may be swapped. | OpenHIE architecture specificationOpenHIE architectural principles | A stable authored map of logical capabilities with explicit authority boundaries. | Physical hosts, networks, vendor products, deployment sizing, and procurement guidance. | specified |
| The IOL routes, secures, mediates, orchestrates, audits, and can rerun failed exchange work. | OpenHIE Interoperability Layer | A deterministic in-memory switchyard, error boundary, and replay action. | Real credentials, encryption, durable queues, operational consoles, and retained payload stores. | specified |
| Identity can be linked and uncertain matches can require human adjudication. | OpenHIE Client RegistryIHE PDQmIHE PMIR | Fixed exact, possible, ambiguous, and no-match outcomes with an explicit adjudication event. | A production algorithm, population tuning, identity proofing, and merge governance. | specified |
| Provider, facility, service, and endpoint relationships can be represented in a directory. | IHE mCSDOpenHIE Facility RegistryOpenHIE Health Worker Registry | One versioned PractitionerRole → organization → location → service relationship view. | Federation, directory synchronization, distance queries, and real credentials. | implementation choice |
| Semantic mapping and structural transformation are different operations. | OpenHIE Terminology ServiceOpenHIE Interoperability LayerFHIR R4 terminology module | A TS-owned mapping decision and a separately versioned IOL-created derivative artifact. | A terminology server, mapping governance workflow, and general-purpose transformation engine. | implementation choice |
| The SHR is a normalized operational subset, not a warehouse or copy of everything. | OpenHIE Shared Health RecordSave patient-level clinical data workflowQuery patient-level clinical data workflow | A tiny versioned shared subset, limited query response, and visible missing information. | Document registries, full XDS/MHD exchange, persistence, scale, and broad clinical content. | specified |
| A policy/consent input can constrain disclosure. | FHIR R4 Consent | A transparent authored rule evaluates requester, role, organization, purpose, category, and directive input. | A legal consent service, jurisdictional policy, identity proofing, and real enforcement. | implementation choice |
| AuditEvent and Provenance answer different questions. | FHIR R4 AuditEventFHIR R4 Provenance | Separate redacted security/operation events and artifact derivation records. | FHIR profile validation, durable repositories, signatures, and integrity controls. | specified |
| A replay with the same idempotency key causes one downstream effect. | OpenHIE Interoperability LayerOpenHIM transaction list | Toy duplicate detection plus commit-then-lost-ack reconciliation. | Distributed consensus, transactional messaging, and exactly-once delivery guarantees. | implementation choice |
| Product definition and stock balance belong to different services. | OpenHIE Product CatalogueOpenHIE LMIS | A fictional product mapping followed by a minimum stock event in the LMIS. | Real catalogue standards, inventory accounting, procurement, and resupply integration. | pedagogical extension |
| Eligibility and claims form a separate finance domain. | OpenHIE Finance and Insurance Service | Only fictional states: eligible-for-demo, claim-received, and needs-demo-review. | A real scheme, benefit, price, policy, payer identifier, or determination. | specified |
| Routine reporting exchanges aggregate indicators and their metadata. | OpenHIE HMISOpenHIE aggregate reporting workflowsIHE mADX | A later identifier-stripped count with a persistent small-cell warning. | Measure calculation, mADX validation, statistical disclosure control, and anonymity claims. | implementation choice |
| OpenHIM is one possible IOL technology. | OpenHIM relationship to OpenHIE | A source note and selected interaction ideas only. | OpenHIM code, runtime behavior, configuration, branding, and any mandatory-product claim. | specified |
| The displayed payloads are illustrative demo schemas. | OpenHIE standards and profilesFHIR R4 terminology module | Versioned demo-clinic-v1, demo-exchange-envelope-v1, and demo-canonical-v1 artifacts. | A FHIR validator result, implementation guide, conformance statement, or universal canonical model. | pedagogical extension |
Evidence and policy
Four records, four different questions.
A routing trace, a security event, derivation evidence, and a consent directive overlap—but they are not interchangeable.
01 · route
Transaction trace
Where did the request go?
Envelope references, route hops, attempts, status, response, error boundary, and replay relationship.
Inspired partly by OpenHIM transaction inspection; not an audit standard.02 · security
AuditEvent-like evidence
What did a system do or attempt?
Action, outcome, purpose, actors, source, and affected artifact reference—without raw clinical values or credentials.
FHIR R4 AuditEvent is Trial Use, FMM 3.03 · lineage
Provenance-like evidence
How did this artifact come to be?
Version-specific target, activity, source entity, author or performer, facility, transformer, and mapping version.
FHIR R4 Provenance is Trial Use, FMM 3.04 · directive
Consent and policy input
What choice constrains a governed action?
A directive can express permission or denial for actors, purposes, actions, and periods. A policy engine must still evaluate and enforce it.
FHIR R4 Consent is Trial Use, FMM 2; only privacy is modeled in R4.Transport protection, authentication, authorization, least privilege, policy enforcement, integrity, availability, audit, and provenance remain distinct. A successful technical check does not certify good care or clinical appropriateness.
Standards and profiles
A reference is not a conformance claim.
The OpenHIE release, current IHE profile publications, and permanent FHIR R4 pages have separate versions and maturity states.
Payload honesty
The wire specimens are illustrative demo artifacts.
demo-clinic-v1, demo-exchange-envelope-v1, and demo-canonical-v1 are local teaching schemas. A pretty JSON fragment is not valid
FHIR. The published OpenHIE SHR workflows describe XDS.b/CDA and PIX/CSD, with MHD optional;
real exchanges may also use FHIR, HL7 v2, CDA/XDS, and other governed standards.
| Reference | Version | Status | Use here |
|---|---|---|---|
| Published OpenHIE | 5.2 · August 2024 | Published architecture specification | The governing conceptual architecture for this exhibit. |
| FHIR R4 | 4.0.1 | Permanent R4 publication; individual resource maturity varies | Conceptual vocabulary for audit, provenance, consent, and terminology—not a conformance claim. |
| IHE mCSD | 4.0.0 | Trial Implementation | Directory relationships among workers, organizations, locations, services, and endpoints. |
| IHE PDQm | 3.2.0 | Trial Implementation | Patient-demographics query and match reference. |
| IHE PMIR | 1.6.0 | Trial Implementation | Master identity feed, deprecation, merge, and subscription reference. |
| IHE ATNA | ITI TF revision 20.0 | Final Text · 4 August 2023 | Security audit and node-authentication reference; not the toy policy algorithm. |
| IHE mADX | 3.0.0 | trial-use | Current aggregate-reporting reference; newer than the OpenHIE 5.2 publication. |
One possible technology
OpenHIM is not OpenHIE.
OpenHIM describes itself as one reference implementation of the OpenHIE interoperability-layer role. It is not required, not embedded here, and not the runtime behind this simulation. Its rerun documentation explicitly warns about duplicate downstream data; this toy’s idempotency behavior is its own.
The one sourced concept
LOINC 718-7
The only real terminology concept displayed is 718-7, Hemoglobin [Mass/volume] in Blood. It is active; its fully specified name is Hemoglobin:MCnc:Pt:Bld:Qn: and
its example units include g/dL and g/L. The code does not
establish a unit conversion, reference range, interpretation, or clinical correctness.
The exhibit ships no LOINC distribution.
Synthetic-data manifest
Every name and identifier is invented.
Fixtures are committed, deterministic, ephemeral, and visually marked. Reserved domains and synthetic namespaces make the boundary inspectable.
| Kind | Included fixture | Boundary |
|---|---|---|
| Person | Maya Sen · SYN-PER-00417 | Fictional person; no real address, telephone, national identifier, or contact data. |
| Identity namespaces | SYN-LCC-00417 local clinic ID · SYN-CR-000184 enterprise client ID | Source identifiers remain visible and versioned; no Aadhaar-, NHS-, SSN-, or insurance-like value. |
| Facilities | Lumenbank Community Clinic SYN-FAC-001 · Eastbridge District Hospital SYN-FAC-009 · Rivermark Laboratory SYN-FAC-012 | Invented names and identifiers; no real location, logo, coordinates, or endpoint. |
| Worker | clinician-0148@example.invalid | Reserved non-routable address; no real person or credential. |
| Payer | Rivermark Demonstration Coverage Scheme · SYN-FIS-001 | No real scheme, plan, benefit, policy number, price, or coverage determination. |
| Product | Canonical fictional product SYN-PC-IRON-001 | Deliberately not a valid-looking GS1 identifier; the Product Catalogue stores no stock quantity. |
| Terminology | Local LUM-HB at https://codes.example.org/lumenbank/lab · mapped teaching target LOINC 718-7 | Only one sourced LOINC concept; no terminology distribution and no claim that a matching label alone proves equivalence. |
| Clinical artifacts | Versioned local order, laboratory source result, normalized derivative, and limited shared summary | Plausible unit-bearing values only; no diagnosis, interpretation, decision support, or treatment advice. |
| Exchange identifiers | SYN- prefixed or urn:synthetic: message, trace, correlation, artifact, mapping, and provenance identifiers | Deterministic authored values; never user identifiers and never serialized clinical payloads in URLs. |
| System addresses | Displayed endpoints under example.org and email under .invalid | Presentation-only reserved domains; the application never calls them. |
| Time and scenarios | Fixed demonstration timestamps, named presets, numeric seed, and authored failure slugs | Logical time advances only through discrete events; refresh restores the fixture. |
| Aggregate and operations | Identifier-stripped contribution, one periodic count, retry/dead-letter entries, redacted audit events, and provenance records | Aggregate output has no patient drill-through but is not described as automatically anonymous. |
Accepted input
Only authored buttons, scenario IDs, lens choices, and a numeric seed.
No paste field, upload, camera, microphone, clipboard import, free-form patient field, or external API.
Retention
Simulation state lives in memory and refresh resets it.
Payloads, traces, identifiers, and clinical values are not stored in cookies or browser persistence.
Downloads and URLs
Trace filenames and wrappers say SYNTHETIC-NOT-FOR-CLINICAL-USE.
URLs contain only allow-listed authored IDs, a lens, or a numeric seed—never demographics or payload JSON.
Accessibility and privacy
Readable first; interactive second.
The Method route is complete server-rendered content. Its only interactions are ordinary links and native disclosure controls.
Semantic reading order
One page heading, ordered sections, native tables with captions, descriptive links, lists, and definition lists remain useful without JavaScript.
Keyboard and touch
No custom gestures or pointer-only disclosures. Links and native details controls
use visible focus treatment and generous targets.
Responsive and printable
Tables become labeled row blocks on narrow screens; content does not depend on a shrunken diagram. Print removes chrome and preserves source URLs.
No runtime network
No backend, analytics, tracker, cookie, remote asset, authentication service, service worker, or runtime data request. Source links navigate only when a visitor chooses them.
Population-data caution
Aggregate does not mean anonymous.
Removing direct identifiers is necessary but insufficient. A very small count can reveal information when the population is known or when it can be linked with other data. The HMIS view therefore keeps a visible small-cell warning and makes no anonymity claim.
Assumptions
The choices that hold the toy together.
These assumptions are explicit so a changed source, policy, or implementation goal has a visible place to alter the model.
- A01
The unprefixed OpenHIE documentation root is the published 5.2-en branch; staging and development pages are deliberately excluded.
- A02
Each box represents a logical capability. One product may provide several capabilities, or one capability may be distributed across several products.
- A03
The authored policy evaluator is a transparent teaching device, not a canonical OpenHIE consent component or a jurisdictional rule set.
- A04
The local LUM-HB mapping is curated for this single demonstration context; the display text alone is not treated as proof of equivalence.
- A05
Current IHE profile publications are cited separately from the August 2024 OpenHIE release and do not retroactively change that release.
- A06
The demo schemas are illustrative. Until named validator checks exist and pass, any FHIR-like JSON remains FHIR-shaped rather than valid FHIR.
- A07
Replay safety is supplied by deterministic toy idempotency rules; neither OpenHIM nor the cited specifications provide an exactly-once guarantee.
- A08
Only authored transactions can run. Free-form integration, uploaded records, and arbitrary endpoint calls are outside the model.
Limitations
What cannot be inferred from a successful run.
A deterministic miniature is useful precisely because it leaves most real-world complexity outside the frame.
- L01
This exhibit cannot demonstrate production security, transport encryption, identity proofing, key management, authorization enforcement, or incident response.
- L02
It cannot establish legal consent, privacy compliance, data-sovereignty compliance, clinical safety, clinical correctness, or medical appropriateness.
- L03
Identity matching uses fixed outcomes, not a validated algorithm, population-scale tuning, or a real adjudication operation.
- L04
Terminology is reduced to one sourced LOINC target and a tiny fictional local code set; it does not demonstrate licensing, release management, or terminology-server scale.
- L05
The SHR behavior omits durable persistence, broad clinical content, full document sharing, concurrency, reconciliation, availability, and disaster recovery.
- L06
The IOL behavior omits real network transport, durable queues, message-retention policy, operational staffing, and performance under load.
- L07
LMIS stock behavior and the exact Product Catalogue transaction are pedagogical because OpenHIE 5.2 leaves their detailed workflow requirements undetermined.
- L08
Aggregate data may still disclose information through a small cell or linkage with other data. Removing direct identifiers is not anonymization.
- L09
Audit evidence is ephemeral and redacted; it is not an immutable ledger, a tamperproof repository, or proof that a harmful action was prevented.
- L10
Referencing FHIR and IHE material does not mean the payloads or actors conform to those standards or profiles.
Glossary
The shortest useful definitions.
Terms are described for this exhibit’s scope; they are not substitutes for the cited specifications.
- ADX / mADX
- IHE approaches for exchanging aggregate indicator reports; mADX uses FHIR R4 Measure and MeasureReport.
- AuditEvent
- A security or operational record of what a system did or attempted, including its outcome.
- Client Registry (CR)
- The identity service that links local identifiers and manages an enterprise person identity.
- ConceptMap
- A versioned set of relationships between concepts in different code systems.
- Consent
- A record of a consumer directive within a policy context; enforcement still requires policy and software.
- Entity matching
- The governed process of finding records that may refer to the same entity.
- Facility Registry (FR)
- A governed source for canonical facility and Master Facility List information.
- FHIR
- HL7 Fast Healthcare Interoperability Resources. This exhibit references R4 4.0.1 but does not claim conformance.
- HMIS
- A routine health information system for periodic aggregate indicators and analysis.
- HWR
- A Health Worker Registry for canonical worker identity and workforce facts.
- Idempotency key
- A stable request key used here to recognize a replay and avoid a second toy side effect.
- IOL
- The Health Interoperability Layer that coordinates exchange without becoming the source of clinical truth.
- LMIS
- A logistics information system for commodity visibility, stock, and resupply operations.
- mCSD
- IHE Mobile Care Services Discovery, a FHIR-based profile for directory resources and their relationships.
- OpenHIE
- A community and reusable health-information-exchange architectural framework—not a single software product.
- OpenHIM
- One reference implementation of the OpenHIE IOL role; it is not mandatory and is not OpenHIE itself.
- Provenance
- A record of how an artifact or resource version came to be and who or what contributed to it.
- Shared Health Record (SHR)
- A normalized operational subset of person-centric clinical information, distinct from a warehouse.
- Structural transformation
- Changing a message shape or wire format while retaining and linking the source artifact.
- Terminology Service (TS)
- A governed source for code systems, value sets, concept maps, validation, lookup, and translation.
Primary source register
Published sources, directly linked.
Primary official sources only. Accessed 10 August 2026; source versions are kept separate rather than blended.
OpenHIE 5.2 architecture and workflows
- OpenHIE specification overview
Published 5.2 · August 2024 · accessed 10 August 2026
Reusable, service-oriented architecture; flexible implementation; CC BY 4.0.
- OpenHIE version changelog
Published 5.2 · August 2024 · accessed 10 August 2026
Version anchor; the published root is kept separate from staging and development.
- OpenHIE architecture specification
Published 5.2 · accessed 10 August 2026
A high-level, conceptual, logical, and notional pattern rather than a physical topology.
- OpenHIE architecture overview
Published 5.2 · accessed 10 August 2026
Component landscape and the separation of identity, place, worker, meaning, product, and finance.
- OpenHIE architectural principles
Published 5.2 · accessed 10 August 2026
Standards-based, adaptable, and interchangeable components.
- OpenHIE standards and profiles
Published 5.2 · accessed 10 August 2026
Reference profile inventory; OpenHIE explicitly is not limited to the listed profiles.
- OpenHIE Client Registry
Published 5.2 · accessed 10 August 2026
Identity, linkage, deduplication, configurable matching, and uncertain-match adjudication.
- OpenHIE Facility Registry
Published 5.2 · accessed 10 August 2026
Standardized current facility data and a governed Master Facility List.
- OpenHIE Health Worker Registry
Published 5.2 · accessed 10 August 2026
Canonical health-worker identity and governed workforce data.
- OpenHIE Terminology Service
Published 5.2 · accessed 10 August 2026
Code systems, value sets, concept maps, validation, lookup, and translation.
- OpenHIE Interoperability Layer
Published 5.2 · accessed 10 August 2026
Entry, routing, security, audit, mediation, orchestration, error management, and rerun.
- OpenHIE Shared Health Record
Published 5.2 · accessed 10 August 2026
A normalized operational subset of person-centric clinical data, distinct from a warehouse.
- OpenHIE HMIS
Published 5.2 · accessed 10 August 2026
Periodic routine indicators, aggregation, analysis, and reporting.
- OpenHIE LMIS
Published 5.2 · accessed 10 August 2026
Commodity visibility and resupply; detailed workflow and functional requirements remain undetermined.
- OpenHIE Product Catalogue
Published 5.2 · accessed 10 August 2026
Source of truth for what a product is; detailed workflow requirements remain undetermined.
- OpenHIE Finance and Insurance Service
Published 5.2 · accessed 10 August 2026
Eligibility, claim, and finance administration; 5.2 added FIS functional requirements.
- OpenHIE Point-of-Care Systems
Published 5.2 · accessed 10 August 2026
Point-of-care systems select the workflows relevant to their use cases.
- Save patient-level clinical data workflow
Published 5.2 · accessed 10 August 2026
Identity, provider, and facility validation before save; XDS.b/CDA baseline with optional MHD.
- Query patient-level clinical data workflow
Published 5.2 · accessed 10 August 2026
Authorized retrieval using the published PIX/XDS.b pattern, with MHD optional.
- OpenHIE aggregate reporting workflows
Published 5.2 · accessed 10 August 2026
Aggregate indicator exchange with aligned, exchanged, or translated metadata.
- OpenHIE terminology workflows
Published 5.2 · accessed 10 August 2026
Query, validate, expand, lookup, and translate terminology content.
OpenHIM
- OpenHIM relationship to OpenHIE
OpenHIM documentation 8.0.x · accessed 10 August 2026
OpenHIM is one reference implementation of the IOL component, not OpenHIE itself.
- OpenHIM transaction list
OpenHIM documentation 8.0.x · accessed 10 August 2026
Inspectable requests, responses, routes, orchestrations, statuses, and reruns; rerun can duplicate data.
- OpenHIM auditing
OpenHIM documentation 8.0.x · accessed 10 August 2026
ATNA Audit Repository behavior and RFC3881/DICOM audit-event support.
HL7 FHIR R4
- FHIR R4 Provenance
FHIR 4.0.1 · Trial Use · FMM 3 · accessed 10 August 2026
How a resource version came to be: targets, activities, agents, and source entities.
- FHIR R4 AuditEvent
FHIR 4.0.1 · Trial Use · FMM 3 · accessed 10 August 2026
A security/operational event record, including action, outcome, agents, source, and affected entity.
- FHIR R4 Consent
FHIR 4.0.1 · Trial Use · FMM 2 · accessed 10 August 2026
A consumer directive within a policy context, not an enforcement engine or decision result.
- FHIR R4 terminology module
FHIR 4.0.1 · accessed 10 August 2026
CodeSystem, ValueSet, ConceptMap, and terminology operations.
IHE profiles
- IHE mCSD
4.0.0 · Trial Implementation · 21 May 2025 · accessed 10 August 2026
FHIR R4 care-services directory relationships and endpoint discovery.
- IHE PDQm
3.2.0 · Trial Implementation · 4 November 2025 · accessed 10 August 2026
RESTful patient-demographics query and demographics match.
- IHE PMIR
1.6.0 · Trial Implementation · 4 November 2025 · accessed 10 August 2026
FHIR master-identity create, update, deprecate, merge, and subscription.
- IHE ATNA
ITI TF revision 20.0 · Final Text · 4 August 2023 · accessed 10 August 2026
Node and user authentication, security audit logging, and telecommunications encryption.
- IHE mADX
3.0.0 · trial-use · 19 September 2025 · accessed 10 August 2026
FHIR R4 Measure/MeasureReport aggregate reporting with mCSD and terminology metadata.
Terminology record
- LOINC 718-7
Active concept · concept last updated in LOINC 2.73 (MIN) · accessed 10 August 2026
Hemoglobin [Mass/volume] in Blood; example UCUM units include g/dL and g/L.