eduKateSG · Why Science?
Separate durable record structure from evolving clinical knowledge—while preserving archetypes, templates, terminology, versions, provenance and governance
Choose the closest route, then return to the full index whenever you need the wider evidence chain.
Science learning becomes powerful when students can tell a measured pattern from a model, a statistical decision from a mechanism, and a useful lead from a finished conclusion. openEHR is an open standards approach for durable, patient-centred electronic health records. Its two-level modelling separates a relatively stable Reference Model from clinical content models: reusable archetypes and implementation templates. Official component listings checked on 12 October 2026 show Archetype Model 2.3.0 from March 2024 and REST API specifications 1.1.0 released on 19 July 2026, while other components have their own releases. Archetypes constrain structures; templates combine and further constrain them for a use case. Conformance does not prove clinical accuracy, safe workflow, privacy, terminology quality or interoperability with an unaligned implementation. This guide supports Primary Science, PSLE Science, Secondary Science, O-Level Science and STEM education as a longform evidence-reading route; it is not medical advice, a laboratory protocol, an admission promise or a career guarantee.
Related eduKate reading: HL7 FHIR and structured health-data exchange; PhenoTips and structured genomic health records; Human Phenotype Ontology and structured clinical phenotypes; preserving ICD, SNOMED CT and LOINC meaning across languages; Science Learning Hub; Education Hub; STEM Education; Careers by Subject Capability.
Primary and official sources checked on 12 October 2026: openEHR official overview of reference model, archetypes and templates, checked 12 October 2026; openEHR official specifications start page, checked 12 October 2026; openEHR official component catalogue, including Archetype Model 2.3.0 and REST 1.1.0, checked 12 October 2026; openEHR official REST API specifications Release 1.1.0 dated 19 July 2026, checked 12 October 2026; 2026 Singapore–Cambridge O-Level Biology syllabus; MOE G2/G3 Lower Secondary Science teaching and learning syllabus; 2026 MOE G2 Computing syllabus. Standards, terminologies, classifications, clinical models and recommendations can change, so preserve dated documentation, exact source data and software versions.
A deeper reading route
Clinical knowledge changes faster than database infrastructure. New observations, guidelines and forms appear while a health record may need to remain readable for decades. openEHR addresses this tension by separating generic record structures from domain models authored as archetypes and templates.
The Reference Model defines stable building blocks such as compositions, entries, data values, identifiers, versioning and audit structures. It does not attempt to hard-code every blood-pressure form or medication workflow. Clinical meaning is added through models that constrain those generic structures.
An archetype is a formal, reusable model of a clinical concept, such as a blood-pressure observation, expressed against a reference model. It defines nodes, occurrences, value constraints and terminology. Archetypes are authored with Archetype Definition Language and represented through the Archetype Object Model.
A template selects, combines and further constrains archetypes for a specific form, document, service or jurisdiction. It can hide unused nodes, tighten occurrences, bind terms and add implementation choices. The template is not merely a screen layout: it defines the content contract behind data capture and exchange.
Operational templates compile the relevant constraints into an implementable artifact. Systems can validate submitted data against that contract. The exact template identifier and version must travel with records or interfaces where reproducibility matters; “openEHR compliant” is too broad to explain one dataset.
Archetype paths provide stable ways to address nodes in structured data, and Archetype Query Language can use paths and pattern matching to query repositories. Queries depend on the deployed models and data, so archive the AQL, template and archetype versions together.
Versioning and contribution structures support a medico-legally useful change history. A corrected composition is not the same as silently mutating an old row. Audit information should identify who committed a change, when and under which contribution, subject to local identity and privacy rules.
openEHR and FHIR solve related but different problems. FHIR focuses strongly on interoperable resources and exchange; openEHR focuses on persistent clinical data architecture and governed models. Mappings can be valuable, but they require explicit semantic decisions rather than assuming every archetype node equals one FHIR element.
For students, two-level modelling resembles a science notebook with a stable grammar and evolving experiment sheets. The notebook guarantees that every observation has a place and audit history; the experiment sheet specifies exactly which quantities, units and conditions this investigation needs.
The optimistic value is durable computability. Clinicians can govern reusable models while software teams implement stable services and repositories. The discipline is to keep model release, terminology bindings, template governance, validation, provenance, security and clinical safety visible at every step.
Clinical Knowledge Manager repositories can support review and reuse of archetypes, but publication status and local adoption matter. A downloaded archetype is not automatically approved for a hospital, language or workflow. Record repository, branch, version, review state and local governance decision.
Terminology bindings connect archetype nodes or values to external systems such as SNOMED CT or LOINC. The archetype’s internal node codes serve local model identity; they should not be mistaken for universal clinical terminology. Preserve both roles and their versions.
Slots allow archetypes to include other archetypes under constraints. This enables composition, but a slot that accepts many candidates can produce variation. Templates should resolve intended choices and validation should check the actual archetype identifiers used.
The REST API specifies service operations and representations, while the clinical models define content. A successful HTTP response does not prove the composition matches the intended template or that the user was authorised. Validate transport, content, identity and policy as separate layers.
AQL results can change after model or data updates even when query text is unchanged. Pin repository snapshot, archetype and template releases, terminology and query engine version. Use small fixtures to confirm path resolution and multiplicity before population-scale analysis.
User-interface labels and forms can evolve independently from stored data when templates and paths are governed well. Still, usability is a clinical-safety issue. Test that required context is visible, defaults are safe and units cannot be misunderstood by the people entering or reviewing data.
Longitudinal records create privacy risk through identity, rare events, dates and narrative. openEHR provides structures; each deployment must implement authentication, authorisation, encryption, consent, retention and audit policy. An open specification is not an open patient record.
Migration should compare model semantics, not only XML or JSON shape. If an archetype changes cardinality, value set or node meaning, transform into a new versioned result, retain the source and record exceptions. A successful parser is only the first layer of evidence preservation.
| Stage | Question | Evidence | Responsible output |
|---|---|---|---|
| Structure | Which durable record building blocks apply? | Reference Model and versioning structures | A stable information foundation |
| Model | What clinical concept is represented? | Archetype, terminology and review state | A reusable clinical definition |
| Implement | Which use-case constraints apply? | Template, operational template and service contract | A validated capture model |
| Verify | What can be trusted and reused? | Data validation, provenance, security and clinical review | A bounded durable record |
Inside this guide
1–12 · Foundations and design
- 1. Start with the durable-record question
- 2. Use two-level modelling
- 3. Read the Reference Model
- 4. Read archetypes
- 5. Read templates
- 6. Read operational templates
- 7. Understand ADL
- 8. Understand the Archetype Object Model
- 9. Use node identifiers carefully
- 10. Bind terminology explicitly
- 11. Use slots deliberately
- 12. Preserve occurrences and cardinality
13–24 · Models and estimation
- 13. Preserve datatypes and units
- 14. Model compositions
- 15. Model entries by purpose
- 16. Preserve version histories
- 17. Use archetype paths
- 18. Query with AQL
- 19. Use the REST API deliberately
- 20. Govern model repositories
- 21. Validate compositions
- 22. Map to FHIR explicitly
- 23. Test longitudinal meaning
- 24. Protect privacy and security
25–36 · Diagnostics and interpretation
- 25. Design for clinical safety
- 26. Separate conformance from interoperability
- 27. Preserve provenance
- 28. Connect to Primary Science
- 29. Connect to Secondary Science
- 30. Connect to mathematics
- 31. Connect to computing
- 32. Connect to pathways
- 33. Did you know?
- 34. Write a reader-ready methods note
- 35. Build a validation ladder
- 36. Finish with a reproducible bundle
Section 1 of 36
1. Start with the durable-record question
Define what clinical information must remain understandable and queryable across software and time.
Working checkpoint — openEHR: Write the use case, retention horizon and accountable model owners. Keep source event, RM, archetype, template and terminology versions, contribution, validation, provenance and access decision together.
For a classroom model, create a stable notebook structure and two versioned experiment templates.
Section 2 of 36
2. Use two-level modelling
openEHR separates a generic Reference Model from domain archetypes and templates.
Working checkpoint — reference model: Keep infrastructure and clinical-model versions distinct. Read every data node beside composition context, path, datatype, unit, author, time and clinical purpose.
For future study, connect health science to software architecture while checking pathways separately.
Section 3 of 36
3. Read the Reference Model
The RM defines generic record, entry, data, identity, version and audit structures shared by implementations.
Working checkpoint — archetype: Cite the exact component release used. Preserve historical versions and rejected migrations; model evolution is not silent mutation.
For writing, cite RM, archetype, template, terminology, API and validation releases.
Section 4 of 36
4. Read archetypes
An archetype formally constrains a reusable clinical concept against a reference model.
Working checkpoint — template: Record archetype identifier, version and publication status. Separate schema conformance from clinical accuracy, workflow safety, privacy and interoperability.
For students, ask which rules belong to the durable notebook and which to today’s experiment sheet.
Section 5 of 36
5. Read templates
A template combines and further constrains archetypes for a specific implementation use.
Working checkpoint — ADL: Name the template and governance scope. Treat artifact identifiers, paths, cardinalities and terminology bindings as scientific inputs: one model shift can change a query.
For parents, ask whether a digital record preserves corrections and access history.
Section 6 of 36
6. Read operational templates
An operational template resolves constraints into an implementable content contract.
Working checkpoint — AQL: Validate submitted compositions against the intended OPT. Keep source event, RM, archetype, template and terminology versions, contribution, validation, provenance and access decision together.
For a classroom model, create a stable notebook structure and two versioned experiment templates.
Section 7 of 36
7. Understand ADL
Archetype Definition Language serialises archetype constraints and terminology in a human-reviewable formal language.
Working checkpoint — openEHR: Use a parser for the matching ADL specification. Read every data node beside composition context, path, datatype, unit, author, time and clinical purpose.
For future study, connect health science to software architecture while checking pathways separately.
Section 8 of 36
8. Understand the Archetype Object Model
AOM defines the machine model behind archetype constraints.
Working checkpoint — reference model: Do not mix artifacts from incompatible AOM generations. Preserve historical versions and rejected migrations; model evolution is not silent mutation.
For writing, cite RM, archetype, template, terminology, API and validation releases.
Section 9 of 36
9. Use node identifiers carefully
Archetype node identifiers support paths and model structure but are not universal clinical terminology codes.
Working checkpoint — archetype: Keep internal node and external terminology identities separate. Separate schema conformance from clinical accuracy, workflow safety, privacy and interoperability.
For students, ask which rules belong to the durable notebook and which to today’s experiment sheet.
Section 10 of 36
10. Bind terminology explicitly
Bindings can associate model nodes or values with SNOMED CT, LOINC or other systems.
Working checkpoint — template: Pin terminology system, release and value-set rule. Treat artifact identifiers, paths, cardinalities and terminology bindings as scientific inputs: one model shift can change a query.
For parents, ask whether a digital record preserves corrections and access history.
Section 11 of 36
11. Use slots deliberately
Slots allow one archetype to include others under constraints.
Working checkpoint — ADL: Resolve expected candidates in implementation templates. Keep source event, RM, archetype, template and terminology versions, contribution, validation, provenance and access decision together.
For a classroom model, create a stable notebook structure and two versioned experiment templates.
Section 12 of 36
12. Preserve occurrences and cardinality
Constraints define whether nodes or values are optional, required or repeatable.
Working checkpoint — AQL: Test missing, repeated and boundary cases. Read every data node beside composition context, path, datatype, unit, author, time and clinical purpose.
For future study, connect health science to software architecture while checking pathways separately.
Section 13 of 36
13. Preserve datatypes and units
Quantities, coded text, dates and identifiers have different semantics and validation rules.
Working checkpoint — openEHR: Reject convenient string coercion. Preserve historical versions and rejected migrations; model evolution is not silent mutation.
For writing, cite RM, archetype, template, terminology, API and validation releases.
Section 14 of 36
14. Model compositions
A Composition provides a coherent clinical-document context for entries and event information.
Working checkpoint — reference model: Keep composer, time, territory, language and category context. Separate schema conformance from clinical accuracy, workflow safety, privacy and interoperability.
For students, ask which rules belong to the durable notebook and which to today’s experiment sheet.
Section 15 of 36
15. Model entries by purpose
Observation, Evaluation, Instruction and Action structures support different clinical intentions.
Working checkpoint — archetype: Do not choose an entry type only for storage convenience. Treat artifact identifiers, paths, cardinalities and terminology bindings as scientific inputs: one model shift can change a query.
For parents, ask whether a digital record preserves corrections and access history.
Section 16 of 36
16. Preserve version histories
Versioned objects and contributions support traceable correction and audit.
Working checkpoint — template: Create a new committed version rather than mutating history silently. Keep source event, RM, archetype, template and terminology versions, contribution, validation, provenance and access decision together.
For a classroom model, create a stable notebook structure and two versioned experiment templates.
Section 17 of 36
17. Use archetype paths
Paths identify nodes through model structure and power queries and extraction.
Working checkpoint — ADL: Test paths against the deployed template. Read every data node beside composition context, path, datatype, unit, author, time and clinical purpose.
For future study, connect health science to software architecture while checking pathways separately.
Section 18 of 36
18. Query with AQL
Archetype Query Language uses model paths and pattern matching; official component status and engine support must be checked.
Working checkpoint — AQL: Archive query, parameters and model releases. Preserve historical versions and rejected migrations; model evolution is not silent mutation.
For writing, cite RM, archetype, template, terminology, API and validation releases.
Section 19 of 36
19. Use the REST API deliberately
Official ITS-REST 1.1.0 was released on 19 July 2026 and defines service interactions; content models remain separate.
Working checkpoint — openEHR: Validate HTTP, service, template and data layers. Separate schema conformance from clinical accuracy, workflow safety, privacy and interoperability.
For students, ask which rules belong to the durable notebook and which to today’s experiment sheet.
Section 20 of 36
20. Govern model repositories
Shared archetypes need ownership, review state, versioning, translation and local adoption decisions.
Working checkpoint — reference model: Record repository and approval evidence. Treat artifact identifiers, paths, cardinalities and terminology bindings as scientific inputs: one model shift can change a query.
For parents, ask whether a digital record preserves corrections and access history.
Section 21 of 36
21. Validate compositions
Check RM schema, archetype and template constraints, terminology, units, references and clinical plausibility.
Working checkpoint — archetype: Retain detailed validator outcomes. Keep source event, RM, archetype, template and terminology versions, contribution, validation, provenance and access decision together.
For a classroom model, create a stable notebook structure and two versioned experiment templates.
Section 22 of 36
22. Map to FHIR explicitly
Mappings can support exchange, but model grain and context differ between openEHR templates and FHIR resources.
Working checkpoint — template: Publish field-level semantics and transformation tests. Read every data node beside composition context, path, datatype, unit, author, time and clinical purpose.
For future study, connect health science to software architecture while checking pathways separately.
Section 23 of 36
23. Test longitudinal meaning
Later model versions must not make historical data unreadable or silently reinterpret old nodes.
Working checkpoint — ADL: Rehearse queries across versioned records. Preserve historical versions and rejected migrations; model evolution is not silent mutation.
For writing, cite RM, archetype, template, terminology, API and validation releases.
Section 24 of 36
24. Protect privacy and security
The standard provides structures, not a complete deployment security policy.
Working checkpoint — AQL: Implement identity, access, encryption, consent, audit and retention controls. Separate schema conformance from clinical accuracy, workflow safety, privacy and interoperability.
For students, ask which rules belong to the durable notebook and which to today’s experiment sheet.
Section 25 of 36
25. Design for clinical safety
Correct schemas can still create unsafe forms, defaults, unit displays or workflow omissions.
Working checkpoint — openEHR: Test with representative users and clinical hazards. Treat artifact identifiers, paths, cardinalities and terminology bindings as scientific inputs: one model shift can change a query.
For parents, ask whether a digital record preserves corrections and access history.
Section 26 of 36
26. Separate conformance from interoperability
Two systems can claim openEHR support while using different templates, terminology or API subsets.
Working checkpoint — reference model: Exchange shared fixtures and compare meaning. Keep source event, RM, archetype, template and terminology versions, contribution, validation, provenance and access decision together.
For a classroom model, create a stable notebook structure and two versioned experiment templates.
Section 27 of 36
27. Preserve provenance
A durable record links source event, model artifacts, author, contribution, system, validation and access decision.
Working checkpoint — archetype: Make every transformation reviewable. Read every data node beside composition context, path, datatype, unit, author, time and clinical purpose.
For future study, connect health science to software architecture while checking pathways separately.
Section 28 of 36
28. Connect to Primary Science
A fictional two-layer health-record model lets younger learners separate the thing observed from the code or model used to record it.
Working checkpoint — template: Use invented, non-personal examples and define every label. Preserve historical versions and rejected migrations; model evolution is not silent mutation.
For writing, cite RM, archetype, template, terminology, API and validation releases.
Section 29 of 36
29. Connect to Secondary Science
openEHR supports lessons about classification, measurement, models, evidence, systems and uncertainty.
Working checkpoint — ADL: Trace one coded statement back to its source observation. Separate schema conformance from clinical accuracy, workflow safety, privacy and interoperability.
For students, ask which rules belong to the durable notebook and which to today’s experiment sheet.
Section 30 of 36
30. Connect to mathematics
Sets, hierarchies, identifiers, units, dates and logical constraints only compare safely when their definitions agree.
Working checkpoint — AQL: Work through one small boundary case by hand. Treat artifact identifiers, paths, cardinalities and terminology bindings as scientific inputs: one model shift can change a query.
For parents, ask whether a digital record preserves corrections and access history.
Section 31 of 36
31. Connect to computing
Formal models, versioned artifacts, REST services, paths, validators and AQL show how software can preserve structured clinical data.
Working checkpoint — openEHR: Break one identifier, version or relationship, then validate and repair it transparently. Keep source event, RM, archetype, template and terminology versions, contribution, validation, provenance and access decision together.
For a classroom model, create a stable notebook structure and two versioned experiment templates.
Section 32 of 36
32. Connect to pathways
openEHR connects medicine, information modelling, software architecture, terminology, databases and clinical safety and can illuminate STEM education and career pathways.
Working checkpoint — reference model: Check current official education and qualification routes separately. Read every data node beside composition context, path, datatype, unit, author, time and clinical purpose.
For future study, connect health science to software architecture while checking pathways separately.
Section 33 of 36
33. Did you know?
openEHR archetypes are models of clinical concepts, while templates combine and further constrain them for a particular implementation.
Working checkpoint — archetype: Explain the fact in plain language, then name what it does not prove. Preserve historical versions and rejected migrations; model evolution is not silent mutation.
For writing, cite RM, archetype, template, terminology, API and validation releases.
Section 34 of 36
34. Write a reader-ready methods note
State the standard and release, source system, mapping, terminology, validation, privacy controls and supported claim.
Working checkpoint — template: Keep the note beside the machine-readable record. Separate schema conformance from clinical accuracy, workflow safety, privacy and interoperability.
For students, ask which rules belong to the durable notebook and which to today’s experiment sheet.
Section 35 of 36
35. Build a validation ladder
Check bytes, identifiers, version, structure, terminology, source fidelity, scientific plausibility, privacy and a known fixture in sequence.
Working checkpoint — ADL: Stop at the earliest unresolved layer. Treat artifact identifiers, paths, cardinalities and terminology bindings as scientific inputs: one model shift can change a query.
For parents, ask whether a digital record preserves corrections and access history.
Section 36 of 36
36. Finish with a reproducible bundle
Deliver source receipts, mappings, releases, software versions, tests, hashes and limitations without exposing governed health records.
Working checkpoint — AQL: Make every published claim traceable. Keep source event, RM, archetype, template and terminology versions, contribution, validation, provenance and access decision together.
For a classroom model, create a stable notebook structure and two versioned experiment templates.
Contents · Previous section · Continue to the Science Learning Hub