Compendium

Healthcare / Clinical / Medical Informatics DSLs Family Index

15 min read

Healthcare / Clinical / Medical Informatics DSLs Family Index

type: language-family-index family: healthcare-clinical languages_catalogued: 28 tags: [language-reference, family-index, healthcare-clinical, hl7, fhir, dicom, snomed-ct, icd-11, loinc, openehr, omop, cdisc, cql, fhir-shorthand, tefca]

Healthcare / Clinical / Medical Informatics — Family Index

Family overview

Healthcare informatics has the longest and messiest legacy of any DSL family in this library. HL7 v2 — the pipe-delimited, segment-and-field-coded message format that begins with the immortal opening MSH|^~\&|...| — has been the workhorse of hospital messaging since 1989, was last revised as v2.9 in 2019 and most recently as v2.9.1 in 2024, and is still the most-deployed clinical messaging format on Earth. Almost every hospital ADT/orders/results feed in production in 2026 is v2 over MLLP/TCP. HL7 v3 (early 2000s) tried to replace it with a fully XML, RIM-derived alternative; it largely failed except as the parent of CDA / Clinical Document Architecture (R2, 2005), which begat C-CDA / Consolidated CDA (R2.1 the regulatory baseline through Jan 2026, R3 / 5.0.0-ballot in development on top of FHIR), the document standard the US Meaningful Use program ran on.

HL7 FHIR (Fast Healthcare Interoperability Resources, 2014+) is the modern answer: REST + JSON/XML + Turtle, resource-based (Patient, Observation, Encounter, etc.), with SMART on FHIR providing OAuth 2.0 / OIDC layered identity. R4 (2019) is the first normative core and remains the production target everywhere outside cutting-edge implementations; R5 (2023) added subscriptions, MeasureReport revisions, and matured the workflow resources; R6 is in active ballot as of May 2026 (hl7.fhir.core#6.0.0-ballot4, generated 2026-05-06) — this is the first fully Normative ANSI ballot of FHIR, with thousands of changes and immature resources moving out to “incubator IGs”. CMS-0057-F (the CMS Interoperability and Prior Authorization Final Rule) requires impacted payers to implement HL7 FHIR Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization APIs by Jan 1 2027 (operational provisions began Jan 1 2026), and a “FHIR-only” prior-auth implementation path exempts payers from HIPAA X12 278 enforcement. TEFCA / QHINs went live December 2023 and now has 11 designated QHINs (2026); from Jan 1 2026 all data sent through TEFCA must conform to USCDI v3.

DICOM lives in a parallel imaging universe — tag-based (group,element) binary format plus DIMSE network protocol, first released 1993, currently in the 2026b edition (released March 27 2026, NEMA publishes multiple times per year); DICOMweb (QIDO-RS, WADO-RS, STOW-RS) is its REST/JSON face and is the convergence point with FHIR ImagingStudy. DICOM SR (Structured Report) is the structured-data alternative to free-text radiology reports, used heavily in cardiology, mammography, and some oncology workflows.

The terminology layer is the third axis. SNOMED CT (~360,000 active concepts) is the comprehensive clinical terminology used worldwide for clinical care; the January 2026 International Edition (released 2026-01-06) deprecated Concept Non Current (CNC) indicators and SNOMED is now on a monthly release cadence (Jan/Feb/Mar/Apr 2026 editions all already shipped). ICD-11 is the WHO disease classification: officially in effect for member states since Jan 1 2022, the 8th update (9th stable release) of ICD-11 MMS shipped Feb 16 2026, but in 2026 only ~14 countries are actually collecting/reporting health data with ICD-11, the US has no finalized implementation date (the NCVHS ICD-11 Workgroup was formed 2023; 2025–2027 timing speculative), and the NHS in England has not committed to a transition date. So in practice: ICD-10 / ICD-10-CM still rules reimbursement, ICD-11 is the future. LOINC owns lab tests and observations; RxNorm owns US drug normalisation; NDC owns US drug packaging codes; CPT / HCPCS own US procedures. OpenEHR is the European EHR alternative — a two-level model where archetypes (in ADL 2, currently STABLE) define the clinical content separately from the underlying reference model. OMOP CDM v5.4 (OHDSI) is the unifying observational-research data layer (CDM v6.0 exists but is not OHDSI-tool-supported, so v5.4 remains the recommended target through 2026). CDISC standards (SDTM v1.4 / SDTMIG v3.2, ADaM v2.1 / ADaMIG v1.1, ODM-XML 1.3.2, Define-XML 2.1.10) own clinical-trial submissions to FDA and PMDA; SDTM v3.0 / ADaM v3.0 are 2026+ targets.

Finally, the modern authoring layer: CQL (Clinical Quality Language) v1.5.3 — ANSI-Normative HL7 standard, FHIR-R4-aware — is the query/expression language used for eCQMs (electronic clinical quality measures) and CDS Hooks; CQL 2.0 ballot is in continuous build. FHIR Shorthand (FSH) v3.0.0 with the SUSHI 3.18.1 reference compiler (March 2026) is now the dominant text-DSL for authoring FHIR profiles and Implementation Guides, supporting R4, R4B, and R5 outputs. NCPDP SCRIPT v2023011 is the next ePrescribing standard (CMS-mandated effective Jan 1 2028; v2017071 still required through early 2026).

In our deep library

None catalogued. Healthcare-clinical DSLs are extremely application-specific and do not have standalone deep-library notes; profile-authoring sits on top of JSON / XML / Turtle / OAuth, all of which are catalogued elsewhere or implicit.

Cross-reference:

  • bio-fileformats — sibling family covering sequence/structure/chemistry formats (FASTA, FASTQ, SBML, etc.); zero overlap with clinical informatics in practice — different file formats, different communities, different regulators.
  • bio-workflow — sibling family covering bioinformatics pipeline DSLs (Nextflow, Snakemake, CWL, WDL); occasionally crosses into clinical via genomics-in-EHR projects (FHIR Genomics) but otherwise disjoint.
  • api-description — FHIR REST surfaces are normally documented with OpenAPI / Swagger, and FHIR’s own CapabilityStatement resource is effectively a domain-specific OpenAPI variant.
  • identity-auth-policy — SMART on FHIR is the OAuth 2.0 / OIDC profile for FHIR; the EHR launch context is essentially an OIDC ID-token extension. UDAP is the related PKI/JWT trust framework used in TEFCA Facilitated FHIR.
  • citation-formats — clinical literature workflows (MEDLINE/PubMed XML, NLM’s NCBI bibliographic feeds) sit adjacent.
  • notation-spec — formal terminology grammars (the SNOMED CT Compositional Grammar, the Expression Constraint Language ECL) live closer to formal-notation territory than to ordinary DSLs.
  • i18n-locale — clinical content is multi-language by mandate (ICD-11 has 50+ official translations; SNOMED CT national extensions); code-system designations are locale-tagged.
  • query — CQL and the FHIR Search syntax are query languages, but tightly bound to FHIR resource model rather than generic data.

Tier 3 family table — Messaging / interchange (HL7 family)

FormatFirst appearedOriginTypeStatus (2026)URL
HL7 v21989Health Level Seven InternationalPipe-delimited segment/field message format over MLLP/TCPDominant: v2.9 (2019), v2.9.1 (2024) is current; still the most-deployed clinical messaging standard on Earth — every US hospital ADT/orders/results runs ithttps://www.hl7.org/implement/standards/product_brief.cfm?product_id=649
HL7 FHIR R42019 (first normative)HL7 International (Grahame Grieve et al.)RESTful resource API, JSON/XML/Turtle; FHIRPath query languageDominant production target in 2026; US Core IG is built on R4; CMS-0057-F APIs target R4https://hl7.org/fhir/R4/
HL7 FHIR R52023HL7 InternationalREST + resources; matured Subscription, MedicationRequest, workflow resourcesActive, growing adoption; basis for FHIR Shorthand authoringhttps://hl7.org/fhir/R5/
HL7 FHIR R62026 (ballot)HL7 InternationalFirst fully Normative ANSI ballot; thousands of changes vs R5; immature resources moved to incubator IGsIn ballot: 6.0.0-ballot4 generated 2026-05-06; Normative publication targeted late 2026 / 2027https://build.fhir.org/
SMART on FHIR2014Boston Children’s / Harvard (Mandl, Kohane)OAuth 2.0 / OIDC profile + FHIR launch-context extensionDe facto standard for app-to-EHR auth (Epic, Cerner/Oracle, Athena, etc.); SMART App Launch v2.2.0 currenthttps://hl7.org/fhir/smart-app-launch/
FHIR Bulk Data Access (“Flat FHIR”)2018HL7 International / ArgonautAsync bulk export protocol; NDJSON over HTTPS; group-level exportActive, v2.0.0; basis for CMS payer-to-payer and Provider Access bulk exporthttps://hl7.org/fhir/uv/bulkdata/
HL7 v2-to-FHIR2020+HL7 v2-to-FHIR projectMapping IG translating v2 segments/fields/triggers to FHIR resourcesActive, mapping coverage growing; key migration enablerhttps://build.fhir.org/ig/HL7/v2-to-fhir/
HL7 v3 / RIM~2003HL7 InternationalXML messages derived from the Reference Information ModelLegacy / abandoned as a messaging standard; survives only through CDA derivationhttps://www.hl7.org/implement/standards/product_brief.cfm?product_id=186
CDA (Clinical Document Architecture)2000 (R1), 2005 (R2)HL7 InternationalXML clinical document standard built on RIM; structured + narrativeLegacy but still in production; backbone of US Meaningful Use exchange; EU MyHealth@EU patient summarieshttps://www.hl7.org/implement/standards/product_brief.cfm?product_id=7
C-CDA / Consolidated CDA2012 (R1.1), 2015 (R2.1)HL7 + ONC (US)Bundled CDA templates for clinical notesR2.1 is current regulatory baseline (adoption period expired Jan 1 2026); C-CDA 5.0.0 ballot on FHIR underwayhttps://www.hl7.org/implement/standards/product_brief.cfm?product_id=492
CCD (Continuity of Care Document)2007HL7 + ASTMCDA template — patient summaryLegacy template, subsumed by C-CDA Continuity of Care Document sectionhttps://www.hl7.org/implement/standards/product_brief.cfm?product_id=6
TEFCA / QHIN technical framework2023 (live)ONC + Sequoia Project (RCE)Common Agreement + QTF (QHIN Technical Framework); Facilitated FHIR profile + IHE XCA over IHE-XDSOperational: 11 QHINs designated as of 2026; USCDI v3 mandatory from Jan 1 2026https://rce.sequoiaproject.org/tefca/
NCPDP SCRIPT1995+NCPDPEDI-style ePrescribing / pharmacy transactions (XML/JSON variants)v2017071 mandated through early 2026; v2023011 required from Jan 1 2028 (Surescripts migrating now)https://www.ncpdp.org/Standards-Development/Standards-Information

Tier 3 family table — Imaging

FormatFirst appearedOriginTypeStatus (2026)URL
DICOM1993 (DICOM 3.0)NEMA / ACRTag-based binary (group, element) format + DIMSE protocol; the only universally-deployed medical-imaging standardUniversal in radiology / cardiology / pathology; 2026b edition released 2026-03-27 (multiple releases per year)https://www.dicomstandard.org/current
DICOMweb2014+DICOM Standards CommitteeREST + JSON wrappers: QIDO-RS (query), WADO-RS (retrieve), STOW-RS (store)Active, the modern face of DICOM; convergence point with FHIR ImagingStudyhttps://www.dicomstandard.org/dicomweb
DICOM SR (Structured Report)2000DICOM Standards CommitteeStructured-data alternative to free-text radiology reports; SR templates from TID libraryActive, dominant in cardiology measurements, mammography (BI-RADS), some oncologyhttps://dicom.nema.org/medical/dicom/current/output/html/part16.html

Tier 3 family table — Terminology / classification

FormatFirst appearedOriginTypeStatus (2026)URL
SNOMED CT2002 (CT) — descended from SNOMED 1965SNOMED International (formerly IHTSDO); originally CAPComprehensive clinical terminology, ~360,000 active concepts; description logic (EL++) backboneDominant for clinical care; January 2026 International Edition released 2026-01-06; now on monthly release cadencehttps://www.snomed.org/
ICD-10 / ICD-10-CM1990 (ICD-10), 1999 (ICD-10-CM US)WHO / NCHS (US clinical mod)Hierarchical disease and procedure classificationProduction reimbursement standard in US/UK and most of the world in 2026; ICD-10-CM FY2026 update activehttps://icd.who.int/browse10/2019/en
ICD-112022-01-01 (in effect)WHOFoundation Component + MMS (Mortality and Morbidity Statistics)Slowly adopting: ~14 countries reporting with it; US no finalized date; UK NHS no commitment; 8th update / 9th stable release 2026-02-16https://icd.who.int/en/
LOINC1994Regenstrief Institute (Indianapolis)Codes for lab tests, clinical observations, document types, survey itemsUniversal for lab interfacing globally; semi-annual releaseshttps://loinc.org/
RxNorm2004US National Library of MedicineNormalised US drug naming; concepts at ingredient / strength / dose-form / brand levelsUniversal in US pharmacy / e-prescribing; weekly + monthly releaseshttps://www.nlm.nih.gov/research/umls/rxnorm/
CPT / HCPCS1966 (CPT) / 1983 (HCPCS)AMA (CPT) / CMS (HCPCS)Procedure billing codes used across US healthcareUniversal in US billing; CPT 2026 in effecthttps://www.ama-assn.org/practice-management/cpt
NDC (National Drug Code)1972FDA10-digit drug product identifier (labeler-product-package)Universal in US pharmacy supply chainhttps://www.fda.gov/drugs/drug-approvals-and-databases/national-drug-code-directory
SNOMED CT Compositional Grammar / ECL2014+SNOMED InternationalPostcoordination grammar + Expression Constraint Language for refset queriesActive, used by SNOMED CT browsers and FHIR ValueSet expansionhttps://confluence.ihtsdotools.org/display/DOCSCG

Tier 3 family table — EHR / archetype models

FormatFirst appearedOriginTypeStatus (2026)URL
openEHR ADL 2 (Archetype Definition Language)2007 (ADL 1.4), 2014+ (ADL 2)openEHR Foundation (Beale, Heard)Two-level: archetypes/templates over a stable Reference Model; ADL is YAML-like with embedded constraintsSTABLE; ADL 2 is current; openEHR adopted as national standard in Norway, Slovenia, Brazil, India (parts), several UK trustshttps://specifications.openehr.org/releases/AM/latest/ADL2.html
openEHR Templates (OPT / WT)2010+openEHR FoundationOperational Templates compiled from archetype + reference model + terminology bindingsActive, the runtime form clinicians and engines actually consumehttps://specifications.openehr.org/releases/AM/latest/OperationalTemplate.html
AQL (Archetype Query Language)2013openEHR FoundationSQL-like query language over openEHR dataActive, the openEHR equivalent of FHIR Search / CQLhttps://specifications.openehr.org/releases/QUERY/latest/AQL.html
ISO 136062008 (Part 1)ISO TC 215 / CENEHR reference architecture and archetype model derived from openEHRStable / niche; primarily used in EU public-sector EHR architecturehttps://www.iso.org/standard/40784.html

Tier 3 family table — Research / quality / clinical trials

FormatFirst appearedOriginTypeStatus (2026)URL
OMOP CDM2008 (OMOP), 2014+ (OHDSI takes over)FDA OMOP project → OHDSI consortiumRelational schema for observational health data, vocabulary-driven (SNOMED CT + RxNorm + LOINC + ICD)v5.4 is current (recommended in 2026); v6.0 exists but unsupported by OHDSI tools; 2026 next-version planning underwayhttps://ohdsi.github.io/CommonDataModel/cdm54.html
Sentinel CDM2009+FDA Sentinel InitiativeDistributed CDM for post-market drug safety surveillance across US health systemsActive, FDA-operationalhttps://www.sentinelinitiative.org/
PCORnet CDM2014+PCORI / PCORnetPatient-centered outcomes research CDMActive (v6.x in 2026)https://pcornet.org/data/
i2b2 / TranSMART2007 / 2008Partners HealthCare (i2b2) / J&J + tranSMART FoundationStar-schema research data warehouse modelsLegacy / niche; many sites have migrated to OMOPhttps://www.i2b2.org/
CDISC SDTM2004CDISCTabulation model for FDA / PMDA clinical-trial submissionsv1.4 + SDTMIG v3.2 current; v3.0 / IG v4.0 expected 2026+https://www.cdisc.org/standards/foundational/sdtm
CDISC ADaM2009CDISCAnalysis-ready dataset standard for trial efficacy / safety analysesv2.1 + ADaMIG v1.1 current; v3.0 in developmenthttps://www.cdisc.org/standards/foundational/adam
CDISC ODM-XML2002CDISCXML-based clinical-trial data exchange (eCRFs, casebooks, audit trail)v1.3.2 currenthttps://www.cdisc.org/standards/data-exchange/odm
CDISC Define-XML2005CDISCMetadata document accompanying SDTM / ADaM submissionsv2.1.10 (October 2025) currenthttps://www.cdisc.org/standards/data-exchange/define-xml
CQL (Clinical Quality Language)2014HL7 CDS WG + CQI WGHigh-level expression / query language over FHIR for eCQMs and CDSv1.5.3 ANSI Normative; 2.0.0-ballot in continuous buildhttps://cql.hl7.org/
FHIR Shorthand (FSH)2019HL7 + MITREText DSL for authoring FHIR profiles, extensions, value sets, IGsv3.0.0 current; reference compiler SUSHI 3.18.1 (March 2026); emits R4, R4B, R5https://hl7.org/fhir/uv/shorthand/

Notable threads

  • HL7 v2 vs FHIR migration reality. Almost every US hospital in 2026 runs both v2 and FHIR simultaneously: v2 still drives the internal lab → EMR → billing pipes (because it works, every interface engine speaks it, and switching is risky), while FHIR is the outward-facing layer for patient-access apps, payer interfaces, and CMS-mandated APIs. The HL7 v2-to-FHIR mapping IG is the practical Rosetta Stone — a single ADT^A04 admit message becomes a Patient + Encounter + Coverage + (sometimes) ServiceRequest bundle. The message volume gap is enormous: a typical 500-bed hospital generates millions of v2 messages/day vs thousands of FHIR API calls/day. Any prediction of “v2 is dead” should be tempered by the fact that v2.9.1 was published in 2024.

  • FHIR R5 → R6 and the CMS regulatory pressure. CMS-0057-F (Interoperability and Prior Authorization Final Rule) is the single biggest forcing function on FHIR adoption in 2026 — impacted payers (Medicare Advantage, Medicaid managed care, CHIP, QHP issuers) must implement Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization FHIR APIs by Jan 1 2027. The “FHIR-only Prior Auth” path lets payers skip X12 278 enforcement. R6 is in active ballot (6.0.0-ballot4, 2026-05-06) as the first fully Normative ANSI ballot of FHIR — a major upgrade in maturity status for the spec — but production deployments will continue to target R4 through 2027 because the US Core IG is R4-anchored and Argonaut’s R4→R6 transition strategy is still in design.

  • DICOM’s 30+ year reign in imaging is an outlier. Unlike messaging (where v2 → FHIR is at least underway), imaging has had no successor candidate to DICOM in 30 years. The 2026b edition (March 2026) keeps the same tag-based binary format introduced in DICOM 3.0 (1993). DICOMweb is REST/JSON over the same data model — not a replacement, just a new transport. Why? Because PACS vendors, modalities (CT, MRI, US, PET, mammography), and AI image-analysis tools all interop natively, the raw pixel data is enormous and tag-based encoding is efficient, and there is no regulatory pressure to change. FHIR ImagingStudy is a pointer resource, not a replacement — it links to DICOMweb endpoints rather than carrying pixel data.

  • SNOMED CT vs ICD-11: clinical care vs reimbursement. These are not competitors; they are two different jobs. SNOMED CT (~360,000 concepts, full description-logic graph, postcoordination via Compositional Grammar/ECL) is the clinical care terminology — the level of detail clinicians need to record findings, observations, and procedures meaningfully. ICD-10 / ICD-11 (~17,000 / ~85,000 codes, hierarchical, no DL backbone) are statistical/billing classifications — coarse categories sufficient for mortality reporting, reimbursement, and epidemiology. Mapping SNOMED → ICD is one-way and lossy; the SNOMED CT to ICD-10-CM map is maintained as a baseline reference set. ICD-11 adoption is glacial — only 14 countries are reporting health data with it as of 2024–2026, and the US has no implementation target date — because ICD-10-CM is so deeply baked into US billing infrastructure that switching costs are enormous.

  • OpenEHR’s European traction vs FHIR’s US/global lead. OpenEHR is the clinical-information-modeling-first approach — separate “what is a blood pressure” (the archetype, in ADL 2) from “how do I encode it on the wire” (FHIR Observation, HL7 v2 OBX, openEHR Composition). Norway, Slovenia, parts of the UK NHS, parts of India, Brazil, and several research-led EU sites have made openEHR their national-level EHR persistence standard. The FHIR community in contrast has no equivalent shared content model — FHIR profiles (US Core, IPS, AU Core) are point-in-time adaptations of resources without a global archetype library. The two communities have explored openEHR-to-FHIR converters (e.g. the EHRbase project) but the cultural split persists: openEHR is for the persistence layer, FHIR is for the API layer — and increasingly, sophisticated EU implementations run both.

  • OMOP CDM as the unifying research-data layer. OHDSI’s OMOP CDM v5.4 is the de facto observational-health-data standard for cross-site federated analytics: convert your EHR data to OMOP once, then any of the 100+ OHDSI methods packages (cohort builders, propensity-score adjusters, self-controlled case series) just work. The vocabulary layer is the unifier — every concept in OMOP resolves to a vocabulary_id (SNOMED, RxNorm, LOINC, ICD, ATC, etc.) so federated network studies (LEGEND, CHARYBDIS) can run identical SQL across institutions. CDM v6.0 was an attempt to support hierarchies and metadata more flexibly but was never adopted by OHDSI tools, so v5.4 has held the production crown since 2020 and 2026 next-version planning is just beginning.

  • FHIR Shorthand (FSH) as the modern profile-authoring language. Pre-2020, authoring a FHIR profile meant editing XML or JSON StructureDefinitions by hand or wrestling with Forge / Trifolia (visual editors). FSH (announced 2019, v3.0.0 in 2026) made profile-authoring a text DSL — Profile: USCorePatient, Parent: Patient, * identifier 1..* MS — that compiles via SUSHI 3.18.1 to the underlying StructureDefinition and IG-publisher inputs. Every major FHIR Implementation Guide published since ~2022 is authored in FSH, including US Core, IPS, mCODE, CARIN BB, and Da Vinci PDex. The mental model is “Sass for FHIR” — a much terser surface compiles to the verbose canonical form. SUSHI in 2026 supports R4, R4B, and R5 profile outputs, with R6 support tracking the ballot.

Citations

Graph View