Resource schemas
Zod describes the supported structure. TypeScript types are inferred from the same schemas.
Read the resource parserWorkspaceHow it works
Interactive demoA QUICK ORIENTATION
Understand the story behind a record.
You do not need to read code to explore Asclepius. Choose a routine visit or a referral between two teams, open its records, and trace how the information connects. The aim is to understand the record’s role and context—not to make a care decision.
Four questions to guide your exploration
Use the connected records to move from the person to the source of a report.
01 · Patient
Start with the person
Alex Morgan is fictional. The patient record gives the other records a shared person to refer to.
Whose information is this?
02 · Encounter
Find the visit
The visit connects Alex with the care team, clinic, and time. It gives the other records their setting.
Which visit does it belong to?
03 · Observation
Inspect the measurement
The measurement records a value, its units, and when it was taken. This demo does not interpret that value.
What was recorded, and when?
04 · DiagnosticReport
Trace the report to its source
The example report points back to the measurement. Follow that connection to see the source record.
Where did this information come from?
SCENARIO 02 · REFERRAL AND HANDOFF
Who owns the next step?
Maya’s fictional journey connects Willow’s referring team to Cedar’s receiving team. A ServiceRequest records what was requested and who it is for. A Task records who owns the coordination work and its outcome.
The handoff task is completed, the referral remains active, and the receiving visit is still planned. Those statuses describe different records. Moving between stages explores this fixed snapshot; it does not send a referral or change its status.
In the care journey, choose “A referral and handoff” to trace the request, receiving team, and planned visit.
A few useful terms
- FHIR
- Fast Healthcare Interoperability Resources: an HL7 standard for exchanging healthcare information. This demo uses a small teaching subset of version R4.
- Resource
- A structured record about one kind of information, such as a person, a visit, or a measurement. Each record has its own role.
- Reference
- A link from one record to another. For example, a measurement can refer to the person and visit it belongs to.
- Status
- A label describing the state of a particular record. In this scenario, a draft request is a proposal; it is not evidence that medicine was dispensed or taken.
For the full standard, see HL7’s FHIR R4 overview and explanation of references.
What you can learn here
Inspect two journeys with nine linked fictional records each, identify their roles, and follow their connections. Open the validation lab to see how a missing detail can be detected by the kit’s structural checks and teaching rules.
Try the validation labBoth scenarios are fixed and synthetic. It does not exchange live information with a clinic, save a clinical record, interpret results, or recommend treatment.
Passing the lab’s checks does not mean a record is clinically correct, fully FHIR conformant, or safe to use for care. The local drug-interaction knowledge base is intentionally incomplete.
For developers: architecture and source code
The browser and local API share the same domain schemas and validation service. Dependencies point inward: adapters use ports and domain types; services use ports and the domain; domain code does not depend on infrastructure.
Validation service
Structural checks run before three teaching profile rules. The result is an OperationOutcome describing any issues.
Read the validation servicePorts
Contracts describe capabilities such as saving and searching without choosing a database implementation.
Read the repository portAdapters
The separate local API has in-memory and SQLite adapters. Its composition root connects them; this browser demo does not use them.
Read the composition rootNOT_FOR_CLINICAL_USE · Educational subset. Use fictional examples only. This demo does not connect to clinical systems.