The Interoperability Layer coordinates checks, transformations, routing, retries, and replay. It is not the patient record or the authority for identity or clinical truth.
Click-and-write workbook · wholly synthetic
A Record Crosses Town
A simple guided tour
Follow linked messages and derived artifacts across separate health information systems. The exhibit deliberately does not pretend that one universal patient record is copied everywhere.
You need
- A phone, tablet, or computer with JavaScript enabled for the interactive exercises
- This guide, plus a pencil or pen if you print it
You will
- 1
Follow the authored journey without treating the exchange as one database
- 2
Inspect the exact evidence shown for a terminology transformation
- 3
Compare what six capabilities may and may not assert
- 4
Inspect one stopped failure, apply one correction, and replay only its failed hop
- 5
Explain what this miniature can and cannot demonstrate
Continue online https://record.suvroghosh.in/guide/
Scan or type this address to open the current guided tour.
Before you begin
What is this exhibit?
A health information exchange, or HIE, helps separately governed systems find and exchange allowed information. Different systems remain authoritative for different facts.
Entity Matching evaluates candidate links and evidence. The Client Registry owns the synthetic enterprise identity and its retained local identifier links.
The Terminology Service supplies authored mapping evidence. A mapping in this toy is not proof that a clinical meaning is medically correct.
The Shared Health Record stores a limited normalized clinical subset. Reporting, stock, product, and payment systems keep separate state.
Write before you look
Before you begin, where do you think shared health information is kept?
Part 1
1. Follow the linked record journey
One system does not do every job. Each capability has a bounded role and authority.
- 1
Open the website and select Follow the record.
- 2
You begin at Chapter 00, The map at rest. The capabilities are separate; they are not one large database.
- 3
If you prefer less movement, select Reduced motion.
- 4
Use the visible right-arrow control, whose accessible name is Next hop, to move one chapter at a time.
- 5
At each chapter, read the main heading and the What could go wrong? note. Continue through the 12 chapters, 00 through 11.
Write what you observed
Which capability links local identifiers to an enterprise identity?
Which capability stores the allowed shared clinical subset?
Did every message invoke every capability?
Check the intended answers
- Client Registry
- Shared Health Record
- No
Part 2 · Chapter 06, A local test order needs portable meaning
2. Inspect the scene 06 evidence
The toy preserves source coding and mapping-version evidence while creating a mapped derivative. This authored example does not establish clinical correctness or standards conformance.
- 1
Stay in Journey and select Next hop until you reach Chapter 06. On the online guide, the Open scene 06 shortcut takes you there directly.
- 2
Select Open packet. The inspector shows this chapter's synthetic artifact and evidence. It is a composite source, mapping, and transformation record, not one transport packet with a single sender and receiver.
- 3
Review Difference first, then Plain meaning, Wire, Lineage, Audit, and Provenance.
- 4
In Difference, find the code row ending in LUM-HB on the source side and 718-7 on the target side. Find the originalCoding row that retains the source coding.
Six evidence views
A short explanation of what the selected artifact does.
The authored computer-shaped data, including sourceSystem clinic-ehr, transformer iol, mapping record SYN-MAP-LUM-HB-001, mapping set SYN-CM-LUMENBANK-LAB, and version 1.2.0.
Changed fields, including https://codes.example.org/lumenbank/lab|LUM-HB to http://loinc.org|718-7, plus retained originalCoding.
How changed fields trace through their source and transformation.
Redacted, ephemeral evidence of the attempted operation and outcome. It is not a durable or tamperproof security control.
Authored evidence about how the derived artifact was created or changed.
Write what you observed
The chapter I opened
Original local code and shared code
The service that governs the mapping
A source artifact or mapping version visible in Lineage or Provenance
Part 3
3. Explore bounded authority
The exchange is a governed set of separate stores and services, not one giant database. Product Catalogue defines products; LMIS owns toy stock state.
- 1
Select Explore mode, or select Explore in the menu.
- 2
Below the map or mobile station spine, use the grid of component-name buttons.
- 3
For each named component, keep Data flow selected and read Payload route contract. Then select Trust and read Authoritative for and Must not assert.
Interoperability Layer
Coordinates, validates, mediates, routes, retries, and replays authored exchanges.
Must not imply
It is not the patient record, clinical truth, identity authority, or a guarantee of exactly-once delivery.
Client Registry
Owns the synthetic enterprise identity and retained local identifier links after evidence is evaluated.
Must not imply
It does not hold clinical results. Entity Matching evaluates candidates; authentication is separate.
Terminology
Provides authored code-system and mapping evidence.
Must not imply
It does not hold patient data, perform structural transformation, or prove medical correctness.
Shared Health Record
Stores the allowed, normalized subset of shared clinical information in this miniature.
Must not imply
It is not a complete EHR and does not own aggregate reports, inventory, product definitions, or claims.
HMIS
Receives a minimized aggregate report in its separate reporting store.
Must not imply
An aggregate is not automatically anonymous, and HMIS cannot mutate the patient-level SHR.
LMIS
Keeps toy supply and stock state in a separate store.
Must not imply
It does not hold patient identity, demographics, laboratory results, or clinical history. This workflow is demonstration-authored because OpenHIE 5.2 marks LMIS and Product Catalogue workflow requirements as yet to be determined.
Write the capability
Which capability owns the synthetic enterprise identity links?
Which capability supplies authored mapping evidence?
Which capability stores the limited shared clinical subset?
Which capability coordinates messages without becoming the patient record?
Part 4 · Scenario 10, The illustrative payload does not satisfy its schema
4. Inspect a failure, then repair it
This preset demonstrates validation before a clinical write, a corrected authored artifact, bounded replay, and retained evidence. It does not prove exactly-once delivery, durable auditing, or production safety.
- 1
Select Failure Theatre and open scenario 10. It opens as an already-stopped, repeatable failure; you do not cause a live-system failure.
- 2
Read Processing stopped here. The Interoperability Layer rejects malformed authored artifact SYN-ART-ORDER-HB-MALFORMED-V1 because required code and codeSystem fields are missing.
- 3
Keep Submit the corrected authored artifact selected.
- 4
Select 1 · Apply selected condition, then 2 · Replay failed hop.
- 5
Confirm The failed hop replayed once and RECOVERED. Confirm that the original failure evidence remains visible.
Write what happened
Where did processing stop?
Which required fields were missing?
Which corrected artifact was submitted?
Did only the failed hop replay?
Did replay create a partial or second clinical write?
Is the original failure evidence still visible?
Part 5
5. Check the limits and explain the exhibit
Open Method. For this short tour, read the opening scope statement and the Contents entries 01 Scope & disclaimer, 02 Architecture doctrine, 11 Glossary, and 12 Sources.
Remember the boundaries
- This is an inspectable, wholly synthetic, OpenHIE-inspired behavioral miniature of selected workflows.
- The illustrative JSON is not validated FHIR, IHE, or OpenHIE conformance. Published OpenHIE workflows use profiles and exchange patterns that this teaching shape simplifies.
- Identity matching, mapping, authorization policy, audit, provenance, retry, and replay are deliberately authored toy behavior.
- Audit and provenance are inspectable evidence here, not access control, durable logging, tamper resistance, or a security guarantee.
- The exhibit proves no claim about clinical safety, privacy, legal compliance, performance, availability, or scale.
- ID-stripped aggregate data is not automatically anonymous.
Explain it in your own words
A clinic authors...
The Interoperability Layer coordinates...
Entity Matching and the Client Registry have different jobs because...
The Terminology Service supplies evidence for...
The Shared Health Record keeps...
When validation fails, this toy...
Quick check
1. The Interoperability Layer is authoritative for every clinical record.
True False Answer: False2. An ambiguous or missing identity match should be held for an explicit decision.
True False Answer: True3. In this authored toy, a mapped derivative retains its source coding and mapping version.
True False Answer: True4. The redacted audit can show an attempted operation and outcome, but is not a durable or tamperproof security control.
True False Answer: True
Your view
Journey Packet inspector Explore Failure Theatre Method
The most useful part was
One real process I would like to see explained
My question or note
Finished
- I followed the linked journey.
- I inspected scene 06 evidence.
- I compared bounded authority.
- I repaired one authored failure.
- I can explain the exhibit's limits to another person.