What Is openEHR? The Complete Guide to Archetypes, Templates, AQL and openEHR Platforms

openEHR (also written open EHR) is an open, vendor-neutral specification for storing and querying electronic health record data, in which the clinical meaning of the data is defined by clinicians in shareable models called archetypes and templates, and the software only has to understand one small, stable reference model. The result is clinical data designed to outlive any single application: a blood pressure recorded in 2026 by one vendor's app can be read, queried and reused years later by a different system that implements the same open models.

That one idea, separating clinical knowledge from software, is why health systems in Wales, Scotland, London, Norway, Slovenia and Catalonia have built shared records on openEHR, and why it keeps coming up in platform strategies from Germany to Australia and India. This guide explains how openEHR works in practice, with a worked example from archetype to query, the API you will actually call, where it is used today, and an honest checklist for deciding whether it fits your project.

Free to share: you can use this image in presentations or docs with a link to this page.

What is openEHR?

What is open EHR, or openEHR as it is officially written? openEHR is a set of open specifications, clinical models and tools for building electronic health records whose data is structured, computable and independent of the application that created it. It is maintained by a not-for-profit organisation, openEHR International, and the specifications are openly published at specifications.openehr.org.

For the full build process beyond the data model, read our EHR software development guide.

Its roots go back to 1992, to the EU research project Good European Health Record (GEHR), and the openEHR Foundation was established in 2003 (openEHR history). The archetype formalism that openEHR created has been adopted by ISO as ISO 13606-2:2019 (openEHR specifications).

In practical terms, openEHR gives you five things:

• A reference model: a small set of generic classes (EHR, COMPOSITION, OBSERVATION, EVALUATION, INSTRUCTION, ACTION, ELEMENT, data types) that every openEHR system implements the same way.
• Archetypes: reusable, clinician-authored definitions of one clinical concept, such as blood pressure, problem/diagnosis or medication order.
• Templates: combinations of archetypes, constrained for one use case, such as an emergency department triage form or a diabetes review.
• AQL (Archetype Query Language): a query language that queries clinical meaning ("all systolic pressures above 140") rather than tables and columns.
• A standard REST API: the same endpoints for creating an EHR, committing a composition and running a query, whichever openEHR platform you use.

If you are planning a build on openEHR, our openEHR integration services team designs the clinical models, the platform and the integrations around them.

Why openEHR exists: the problem with application-owned data

openEHR exists because in most health IT, the data model belongs to the application, so the data is only as durable as the application that wrote it. Every time a hospital replaces a system, adds a new clinical form, or wants to reuse data for research, someone has to understand and translate a proprietary schema.

Three consequences follow in almost every organisation:

1. Every clinical change is a software change. Adding a field to a form means a database migration, a code release and a test cycle, so clinical teams wait months for small changes.
2. Every replacement is a migration. When a system is retired, years of records must be mapped into the next vendor's schema, and meaning is lost along the way. Our guide to migrating a custom EHR schema to openEHR covers what that translation involves.
3. Every reuse is an integration project. Analytics, research and AI teams rebuild the same mappings again and again, because nothing in the data says what a column means clinically.

openEHR moves the definition of clinical meaning out of the code and into governed models that clinicians can read and change. The software implements the reference model once. New clinical content arrives as new templates, not new database tables. That is why openEHR is often described as a platform approach: many applications, from different vendors, read and write the same clinical data store.

openEHR vs a traditional EHR database

openEHR architecture: how the specification is organised

The openEHR architecture is a family of specification components, each covering one layer of an EHR platform: shared base types, the reference model, the archetype model, the query language, services and APIs, and implementation formats. Knowing the map saves time, because most questions about "how openEHR does X" are answered in one specific component (openEHR specifications start page).

For most teams, three documents matter first: the Architecture Overview in BASE, the EHR Information Model in RM, and the REST API in ITS-REST. The rest become relevant as you add modelling tools, decision support or conformance testing to procurement.

The two-level model: reference model, archetypes and templates

openEHR's two-level model splits a health record into a stable technical level, the reference model, and a flexible clinical level, the archetypes and templates that constrain it. Developers build against the first; clinicians define the second.

Level 1: the reference model

The reference model (RM) is the small, generic information model that every openEHR system implements. Its core classes describe the shape of any clinical record: an EHR per patient, holding COMPOSITIONs (document-like units such as an encounter note or a discharge summary), which contain ENTRY types:

Free to share: you can use this image in presentations or docs with a link to this page.

Beneath these sit generic structures (ITEM_TREE, CLUSTER, ELEMENT) and a rich set of data types such as DV_QUANTITY, DV_CODED_TEXT and DV_DATE_TIME. Because the reference model does not know what a blood pressure is, it never has to change when medicine does. It also carries the record-keeping features clinical systems need out of the box: versioning of every change, audit of who committed what and when, and support for corrections without losing history (openEHR EHR Information Model).

Versioning and audit inside the reference model

Every composition in openEHR is versioned rather than overwritten. A composition lives inside a VERSIONED_COMPOSITION, each change creates a new version with an identifier of the form object_id::creating_system_id::version, and every commit carries audit details: who committed it, when, and whether it was a creation, a modification or a deletion (openEHR Common Information Model). Several changes committed together form a CONTRIBUTION, so a clinician's whole save, across several documents, is one auditable unit.

For developers this removes a whole class of work. You do not design history tables, soft-delete flags or audit triggers; you read previous versions through the API, and medico-legal questions such as "what did the record say when the decision was made" have a standard answer.

Terminology in openEHR

openEHR separates the structure of data from the terminologies used inside it. Coded values use DV_CODED_TEXT, which carries a code, the terminology it comes from and the text shown to users, so a diagnosis can be stored as a SNOMED CT concept while the archetype defines where it sits and what else is recorded with it. Archetypes carry their own internal codes (the at codes) for structure and value sets, and templates can bind nodes to external terminologies for a specific use case.

That split matters in multi-country products: the same archetype works with SNOMED CT in one market and a national code system in another, and AQL can still find the node by its archetype path.

Privacy by design: the EHR and the person are separate

In openEHR, the EHR does not have to contain the patient's name or identifiers. The EHR_STATUS object links an EHR to its subject through a reference and records whether the EHR is queryable and modifiable (openEHR EHR Information Model). Demographic data can live in a separate demographic service or a master patient index. Research extracts, analytics and AI pipelines can then work on clinical data keyed by ehr_id, with re-identification controlled in one place.

Level 2: archetypes

An archetype is a formal, reusable definition of one clinical concept, expressed as constraints on the reference model. The blood pressure archetype, for example, says: this is an OBSERVATION; it has a systolic and a diastolic value, each a quantity in mm[Hg] within a plausible range; it can record the cuff size, the position of the patient and the location of measurement.

Archetypes are written in the Archetype Definition Language (ADL), identified by names such as openEHR-EHR-OBSERVATION.blood_pressure.v2, and designed to be maximal: they include everything that might be relevant to the concept anywhere in the world, so that different projects reuse the same model instead of inventing their own. Each node carries a code (at0004 is systolic, at0005 is diastolic), and those codes make up the path you later query.

Level 2: templates

A template combines archetypes and narrows them for one real use case. An emergency triage template might take the blood pressure, pulse, temperature and Glasgow Coma Scale archetypes, hide the elements triage staff never use, make systolic and diastolic mandatory, and bind a local terminology subset. Templates are what applications and forms are built from, and what a clinical data repository (CDR) validates data against when it arrives.

For the full developer walkthrough of these concepts, including specialisation, slots and versioning, read openEHR explained for developers and our note on archetype versioning in production.

A worked example: one blood pressure from archetype to query

The fastest way to understand openEHR is to follow one reading through the whole stack: pick the archetype, put it in a template, commit a composition to the CDR, and query it back with AQL. The same four steps apply to any clinical concept.

Step 1: choose the archetype

Search the international Clinical Knowledge Manager for "blood pressure" and you find openEHR-EHR-OBSERVATION.blood_pressure.v2 (archetype source in the CKM mirror), whose node codes include at0004 for systolic, at0005 for diastolic and at1001 for the sitting position. You do not design the data structure; you reuse it.

Step 2: build the template

In a template designer, create a template, say vital_signs_encounter, based on an encounter COMPOSITION archetype (openEHR-EHR-COMPOSITION.encounter.v1). Drop in the blood pressure archetype, keep systolic, diastolic, position and cuff size, and remove what you do not need. Export it as an Operational Template (OPT) and upload it to your CDR through the Definition API.

Step 3: commit a composition

An application now posts data that conforms to the template. Many CDRs accept the simplified FLAT format, a key-value representation generated from the template, which is easy for form builders and integration engines to produce:

{
  "ctx/language": "en",
  "ctx/territory": "GB",
  "ctx/composer_name": "Dr Example",
  "vital_signs_encounter/blood_pressure/any_event:0/time": "2026-09-27T09:30:00Z",
  "vital_signs_encounter/blood_pressure/any_event:0/systolic|magnitude": 148,
  "vital_signs_encounter/blood_pressure/any_event:0/systolic|unit": "mm[Hg]",
  "vital_signs_encounter/blood_pressure/any_event:0/diastolic|magnitude": 92,
  "vital_signs_encounter/blood_pressure/any_event:0/diastolic|unit": "mm[Hg]",
  "vital_signs_encounter/blood_pressure/any_event:0/position|code": "at1001"
}

Inside the CDR the same data is stored in the canonical reference model form, which every openEHR system understands. A trimmed extract of the observation looks like this:

{
  "_type": "OBSERVATION",
  "archetype_node_id": "openEHR-EHR-OBSERVATION.blood_pressure.v2",
  "name": { "_type": "DV_TEXT", "value": "Blood pressure" },
  "data": {
    "_type": "HISTORY",
    "archetype_node_id": "at0001",
    "events": [{
      "_type": "POINT_EVENT",
      "archetype_node_id": "at0006",
      "time": { "_type": "DV_DATE_TIME", "value": "2026-09-27T09:30:00Z" },
      "data": {
        "_type": "ITEM_TREE",
        "archetype_node_id": "at0003",
        "items": [
          { "_type": "ELEMENT", "archetype_node_id": "at0004",
            "name": { "_type": "DV_TEXT", "value": "Systolic" },
            "value": { "_type": "DV_QUANTITY", "magnitude": 148, "units": "mm[Hg]" } },
          { "_type": "ELEMENT", "archetype_node_id": "at0005",
            "name": { "_type": "DV_TEXT", "value": "Diastolic" },
            "value": { "_type": "DV_QUANTITY", "magnitude": 92, "units": "mm[Hg]" } }
        ]
      }
    }]
  }
}

The patient identifiers and demographics do not appear here. openEHR keeps clinical data in the EHR and links it to people through an ehr_id, which simplifies consent, de-identification and research extracts.

Step 4: query it back with AQL

AQL queries the archetype paths, so the query means the same thing on every openEHR system, whichever application wrote the data. This query returns every reading above 140 mmHg systolic for one patient, newest first:

SELECT
  c/context/start_time/value AS recorded_at,
  o/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/magnitude AS systolic,
  o/data[at0001]/events[at0006]/data[at0003]/items[at0005]/value/magnitude AS diastolic
FROM EHR e
  CONTAINS COMPOSITION c
    CONTAINS OBSERVATION o[openEHR-EHR-OBSERVATION.blood_pressure.v2]
WHERE e/ehr_id/value = $ehr_id
  AND o/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/magnitude > 140
ORDER BY c/context/start_time/value DESC

Remove the WHERE e/ehr_id line and the same query runs across the whole population, which is how openEHR platforms serve registries, dashboards and research without a separate data warehouse model. That property is also why openEHR data is well suited to analytics and machine learning, as we cover in why openEHR makes clinical data AI-ready.

The Clinical Knowledge Manager (CKM): where the models live

The Clinical Knowledge Manager is the openEHR community's online library and review system for archetypes and templates, where clinicians and informaticians propose, review, translate and publish models. The international instance is at ckm.openehr.org, described by the community as a collaboration tool to develop, manage, review and publish clinical data models.

Archetypes move through a governed lifecycle, from draft through clinical review to published. Reviewers are clinicians from different specialties and countries, which is what makes a published archetype safe to reuse. National programmes run their own governance for local extensions and translations. In Norway, for example, national archetype governance runs through openEHR Norway, with archetypes published and discussed on arketyper.no.

For a project team, CKM changes the modelling job. Instead of designing tables for "medication order" from scratch, you start from a published archetype, check whether it covers your use case, and only then design a template. When something is genuinely missing, you raise it on CKM or create a local archetype that can be proposed back later.

The openEHR REST API: the endpoints you will actually call

The openEHR REST API is a standard HTTP interface for creating EHRs, committing and reading compositions, managing templates and running AQL, so an application written for one openEHR platform can move to another with little change. The current release of the specification is ITS-REST 1.1.0 (openEHR REST API specification).

A first session against an openEHR API

A developer's first hour with any openEHR platform follows the same four requests. The paths are from the ITS-REST specification; the base URL, authentication and the template upload path prefix vary by platform.

# 1. Upload the operational template once
POST /definition/template/adl1.4
Content-Type: application/xml
(body: vital_signs_encounter.opt)

# 2. Create an EHR for the patient; the response returns the ehr_id
POST /ehr
Prefer: return=representation

# 3. Commit a composition that conforms to the template
POST /ehr/{ehr_id}/composition
Content-Type: application/json
(body: canonical JSON composition)

# 4. Query it back by clinical meaning
POST /query/aql
Content-Type: application/json
{ "q": "SELECT c/uid/value FROM EHR e CONTAINS COMPOSITION c WHERE e/ehr_id/value = $ehr_id",
  "query_parameters": { "ehr_id": "..." } }

Two habits help from day one: keep templates in version control alongside the application code that depends on them, and store the returned composition version identifiers, so updates are made against the version you actually read.

A minimal integration flow is three calls: create the EHR, commit a composition against an uploaded template, run AQL. Our openEHR REST API integration guide walks through each call with request and response bodies, error handling and versioning, and the Mirth Connect and openEHR guide shows how to turn HL7 v2 feeds into FLAT compositions with an integration engine.

What is an openEHR platform?

An openEHR platform is the shared clinical data layer of a health system: a clinical data repository (CDR) that implements the openEHR reference model, stores and versions every composition, validates it against templates, and exposes the standard REST API and AQL, together with the modelling, terminology, identity and integration services around it. Applications from different vendors read and write the same openEHR platform instead of each keeping its own copy of the record.

The word "platform" matters. In an open platform approach, the data and the clinical models are owned by the health organisation and governed independently of any one application, so replacing an application does not mean migrating the record.

A production openEHR platform is more than the CDR. The pieces you typically need:

• The CDR, open source or commercial. EHRbase is an open source option, developed by vitagroup with Hannover Medical School and the HiGHmed consortium (About EHRbase). Our openEHR CDR vendor comparison sets out the options side by side.
• A template and archetype workflow: modelling tools, a CKM or Git repository for governance, and a way to deploy templates to each environment.
• Terminology services for SNOMED CT, LOINC and local code sets, bound in templates.
• Identity and demographics: a master patient index or demographic service that maps patients to ehr_ids.
• Integration: an integration engine for HL7 v2, documents and legacy feeds, and usually a FHIR facade for apps that speak FHIR.
• Application layer: form renderers driven by templates, low-code tools and your own clinical applications.

How these pieces are arranged in production, including where FHIR sits, is covered in four architecture patterns for running openEHR and FHIR together.

openEHR platforms in Australia

In Australia, openEHR shows up first in national clinical data standards rather than in a single national platform. The Australian Core Data for Interoperability (AUCDI), published by the CSIRO-led Sparked programme, was built using openEHR archetypes as the vendor-neutral starting point: in the words of its clinical lead, only one AUCDI data group is not directly derived from an equivalent archetype, and the programme funded new archetypes for the international CKM, including service requests for laboratory tests and imaging (openEHR discourse, 2024). Sparked is delivered by CSIRO with the Australian Digital Health Agency, the Department of Health and Aged Care and HL7 Australia (Sparked AUCDI Release 1), and the Agency's Digital Health Implementer Hub lists openEHR's specifications for implementers (Digital Health Implementer Hub).

For Australian teams, that means an openEHR platform can hold data whose models line up with AUCDI from day one, while FHIR remains the exchange layer to national infrastructure.

Designing an openEHR platform? In an architecture call we look at your use cases, existing systems and hosting constraints, and sketch the CDR, template governance and FHIR layer you would need. Book an openEHR architecture call.

openEHR and FHIR: competitors or partners?

openEHR and FHIR solve different problems and most serious platforms use both: openEHR for storing and governing the longitudinal clinical record, FHIR for exchanging data with other systems and apps. FHIR is an exchange standard built from resources that systems send to each other; openEHR is a persistence and modelling standard for the record itself.

A common production pattern keeps the clinical record in an openEHR CDR and exposes a FHIR API in front of it, mapping compositions to resources such as Observation, Condition and MedicationRequest. The mapping is real work, and the FHIR to openEHR resource mapping matrix lists the common pairs. For a full side-by-side comparison and a decision guide, read openEHR vs FHIR: which one should you choose. If you run SMART apps, see running SMART on FHIR apps against an openEHR backend.

Where openEHR is used: country by country

openEHR is used in national and regional health records in Europe and is part of national standards and interoperability programmes elsewhere. The list below covers programmes we could confirm from official or peer-reviewed sources.

United Kingdom

Adoption in the UK is regional rather than a single national system, and it is broad.

• Wales: Digital Health and Care Wales selected an openEHR platform for its national clinical data repository in 2021, to standardise clinical data and support services such as the national cancer programme and a shared medicines record (Digital Health, July 2021). The Care Data Repository is the central hub of Wales's National Data Resource (DHCW).
• Scotland: the digital ReSPECT emergency care plan was built on Scotland's National Digital Platform using an openEHR CDR. Deployed in 2020, by July 2025 it had onboarded 8 of 14 health boards and held more than 5,500 patients' plans (BMJ Health & Care Informatics, 2025).
• London: the Universal Care Plan, which lets Londoners' care and support wishes be shared with professionals across the capital, is based on the openEHR standard and delivered with OneLondon (Universal Care Plan).
• England: openEHR UK responded formally to NHS England's Single Patient Record request for information (openehr.org).

Norway

Norway reviews and publishes clinical models nationally through openEHR Norway, and the DIPS Arena hospital system uses openEHR, working with the national editorial committee for archetypes (openEHR Norway).

Slovenia

Slovenia's national eHealth programme stores electronic health records based on openEHR as part of its central eHealth platform (Interoperable Europe), with the central registry of patient data acting as a shared record for providers across the country (Digital Health, 2023).

Catalonia, Spain

The Catalan Health Service (CatSalut) is modelling the region's clinical information with openEHR archetypes as the foundation of its electronic clinical history platform, and says Catalonia will become Europe's most populous region adopting open platforms for health information systems (TIC Salut Social, March 2023). The platform is built on EHRbase and openEHR (HiGHmed) and serves a region of more than 8 million people (vitagroup).

Germany

Germany's openEHR adoption is led by university hospitals and research. HiGHmed, a consortium within the national Medical Informatics Initiative funded by the Federal Ministry of Education and Research, builds its data integration centres on an IHE XDS.b affinity domain together with an openEHR clinical data repository, and runs a German openEHR modelling group (HiGHmed).

Switzerland

openEHR.ch is the Swiss openEHR affiliate, a non-profit association of standardisation organisations and practitioners that organises symposia, supports modelling groups and works with other standards bodies and government partners (openEHR.ch).

Australia

AUCDI, Australia's core clinical data set for interoperability, was derived almost entirely from openEHR archetypes, and the national Implementer Hub lists the openEHR specifications; the detail and sources are in the openEHR platform section above.

India

India's EHR Standards, released by the Ministry of Health and Family Welfare in December 2016, name openEHR as an ISO-harmonised platform for implementation and require openEHR Operational Templates used by an implementation to be public, so other implementers can interoperate (NRCeS, EHR Standards for India). NRCeS at C-DAC Pune supports adoption of these standards.

Advantages and challenges of openEHR: when it is the right choice

openEHR is the right choice when your organisation needs a long-lived, vendor-neutral clinical record that many applications share and that clinicians must be able to evolve; it is the wrong choice when you only need to exchange data between existing systems or ship a narrow app fast. Use the checklist below honestly: two or three strong yes answers usually justify openEHR, a row of no answers usually means FHIR on its own is enough.

Advantages of openEHR

• Data that outlives applications: the record is stored against open models, not a vendor schema.
• Clinician-owned content: forms and data items change through templates, without database migrations.
• Built-in versioning and audit for every composition, defined by the reference model.
• Query by meaning: AQL works on archetype paths, across applications and across the population.
• Vendor neutrality: the REST API and models are open, so applications from different suppliers share one record.
• Reuse of international models published in CKM instead of designing every structure from scratch.

openEHR challenges

• Modelling skills: someone must own archetype and template decisions and their governance.
• A new vocabulary for developers: reference model classes, archetype paths and AQL instead of tables and SQL.
• Integration still matters: existing HL7 v2, document and FHIR flows need mapping into and out of compositions.
• Template governance at scale: without versioning rules, templates drift between environments and applications.

The trade-offs are real. openEHR asks for clinical modelling skills your team may not have yet, and a new vocabulary (reference model, archetypes, AQL) for developers used to SQL schemas. In return, you stop paying for the same data model again with every new application and every system replacement.

Scored three or more "yes" answers? Bring the checklist to an openEHR fit call. We will tell you plainly whether openEHR, FHIR alone or both fit your roadmap, and what the first 90 days would look like. Talk to an openEHR engineer.

How to use openEHR in healthcare software development: your first project

To use openEHR in healthcare software development, start with one clinical use case, reuse published archetypes before modelling anything new, and put template governance in place before the second application arrives. The sequence below is the one we recommend to teams building their first openEHR platform.

1. Pick one use case with real users. A care plan, a vital signs chart or a specialty assessment is ideal: small enough to finish, valuable enough to matter.
2. Review CKM before modelling. Map every data item to a published archetype. Note gaps and decide whether to extend, specialise or create a local archetype.
3. Design templates with clinicians in the room. Templates are where clinical safety and usability are decided. Keep them tight: only what the use case needs.
4. Stand up the CDR and environments. Development, test and production, with a repeatable way to deploy templates and a backup and versioning policy.
5. Connect the data you already have. Feed existing HL7 v2, document or database sources into compositions through an integration engine.
6. Ship the first application. Template-driven forms get you to working screens quickly; custom UI comes where the workflow demands it.
7. Add governance, then scale. A model review board, naming and versioning rules, and a change process before the second and third applications arrive.

Skills your team needs

• Clinical modeller: a clinician or clinical informatician who can read and review archetypes.
• openEHR developer: comfortable with the reference model, templates, the REST API and AQL.
• Integration engineer: HL7 v2, FHIR and interface engines, to connect existing systems.
• Platform engineer: security, identity, performance, backup and multi-environment deployment.

Common pitfalls

• Modelling from scratch instead of reusing published archetypes, which quietly recreates the silo problem openEHR is meant to remove.
• One giant template that tries to serve every department. Smaller templates per use case are easier to govern and version.
• Ignoring AQL performance until go-live. Test population queries on realistic data volumes early.
• No template governance, so versions drift between environments and applications break silently. Our write-up on archetype versioning in production covers the controls.
• Treating openEHR and FHIR as either-or instead of planning the FHIR layer from day one.

Emerging applications of openEHR

The fastest-growing uses of openEHR build on the fact that its data is structured, versioned and self-describing: shared care plans, analytics and AI, and clinical workflow. Most of these are already live in the programmes described above.

• Shared care plans across organisations: London's Universal Care Plan and Scotland's digital ReSPECT plan both hold plans in openEHR so every setting sees the same record (sources in the country section above).
• Analytics, registries and AI: because AQL queries clinical meaning, the same data serves care, dashboards and model training. See why openEHR makes clinical data AI-ready.
• Clinical workflow: the Task Planning specification describes work plans and tasks against the record, covered in our openEHR Task Planning guide.
• Research data platforms: Germany's HiGHmed data integration centres combine openEHR CDRs with IHE XDS.b for cross-institution research.

What does "EHR composition type" mean?

"EHR composition type" refers to the kind of document-like unit a piece of health record data was saved in, for example an encounter, a report or a care plan. In openEHR, every clinical entry is stored inside a COMPOSITION, and the composition's archetype tells you what kind of record it is; people often meet the phrase, together with "template entry", when reading their own record online.

For a fuller explanation of compositions, entries and templates, including how they appear to patients and clinicians, see openEHR explained for developers.

openEHR glossary

Building on openEHR, or deciding whether you should? Our healthcare interoperability engineers design openEHR platforms, clinical models and the FHIR and HL7 integrations around them, and our healthcare product engineering team builds the applications on top. Book an openEHR architecture review and we will map your use case to archetypes, templates and a platform design you can take into procurement or build.

Free to share: you can use this image in presentations or docs with a link to this page.