Hl7wiki - Benutzerbeiträge [de]

Ballotbox MI-I

2022-02-24T18:45:34Z

Dammon:

{{BallotboxBegin| Kerndatensatz-Module Medizininformatik Initiative | Profile, Extensions und Value Sets für FHIR (MII) }}

{{BallotboxItem
|status = vote
|type = Informativ
|version = Broad Consent 1.0.0
|date = 15.02.2022
|from = 01.03.2021
|to = 12.04.2021
|ballotannouncement = [https://www.medizininformatik-initiative.de/de/kommentierung-mii-kerndatensatzmodul-consent-einwilligung]
|ballotstart =
|pdf = https://simplifier.net/MedizininformatikInitiative-ModulConsent/~introduction
|wiki =
|artdecor = https://art-decor.org/art-decor/decor-datasets--mide-?id=2.16.840.1.113883.3.1937.777.24.1.1&effectiveDate=2018-06-05T12%3A44%3A12&conceptId=2.16.840.1.113883.3.1937.777.24.2.184&conceptEffectiveDate=2018-06-29T16%3A26%3A50&language=de-DE
}}

{{BallotboxItem
|status = vote
|type = Informativ
|version = Intensivmedizin 1.0.0
|date = 11.02.2022
|from = 25.02.2021
|to = 08.04.2021
|ballotannouncement = [https://www.medizininformatik-initiative.de/de/kommentierung-mii-kerndatensatzmodul-intensivmedizin-pdms-daten-und-hochaufloesende-biosignaldaten]
|ballotstart =
|pdf = https://simplifier.net/MedizininformatikInitiative-Modul-Intensivmedizin/~introduction
|wiki =
|artdecor = https://art-decor.org/art-decor/decor-datasets--mide-?id=2.16.840.1.113883.3.1937.777.24.1.1&effectiveDate=2018-06-05T12%3A44%3A12&conceptId=2.16.840.1.113883.3.1937.777.24.2.9&conceptEffectiveDate=2018-06-05T16%3A14%3A53&language=de-DE
}}

{{BallotboxItem
|status = vote
|type = Informativ
|version = Biobank 1.0.0
|date = 23.06.2021
|from = 07.07.2021
|to = 18.08.2021
|ballotannouncement = Ankuendigung_MII_Biobank
|ballotstart =
|pdf = https://simplifier.net/MedizininformatikInitiative-ModulBiobank/~introduction
|wiki =
|artdecor = https://art-decor.org/art-decor/decor-datasets--mide-?id=2.16.840.1.113883.3.1937.777.24.1.1&effectiveDate=2018-06-05T12%3A44%3A12&conceptId=2.16.840.1.113883.3.1937.777.24.2.72&conceptEffectiveDate=2018-06-06T06%3A26%3A44&language=de-DE
}}

{{BallotboxItem
|status = reconc
|type = Informativ
|version = Fall, Diagnose, Prozedur 1.0.0
|date = 01.07.2020
|from = 11.05.2020
|to = 21.06.2020
|ballotannouncement = https://www.medizininformatik-initiative.de/de/kerndatensatzmodule-fall-diagnose-und-prozedur-der-medizininformatik-initiative
|ballotstart =
|pdf = https://simplifier.net/organization/koordinationsstellemii/~projects
|wiki =
|artdecor = https://github.com/medizininformatik-initiative
}}

{{BallotboxItem
|status = reconc
|type = Informativ
|version = Medikation, Laborbefund 1.0.0
|date = 01.04.2020
|from = 10.02.2020
|to = 23.03.2020
|ballotannouncement = https://www.medizininformatik-initiative.de/de/kommentierung-der-kerndatensatzmodule-person-medikation-und-laborbefund-der-medizininformatik
|ballotstart =
|pdf = https://simplifier.net/organization/koordinationsstellemii/~projects
|wiki =
|artdecor = https://github.com/medizininformatik-initiative
}}

{{BallotboxEnd}}

[[Kategorie:Ballotbox]]

FHIR-Marktübersicht

2021-02-08T13:25:03Z

Dammon:

{{Underconstruction}}

Diese Seite dient der Orientierung und soll eine grobe Einschätzung der Verbreitung von FHIR in Deutschland erlauben.

=FHIR-Produkte auf dem Deutschen Markt=

Diese Liste ist alphabetisch nach Hersteller sortiert:

{| class="hl7table"
!Hersteller!!Produkt/ Modul!!Beschreibung!!Rolle!!Ressourcen (Profile)!!FHIR-Version!!Status!!IHE-Profile!!Capability-Statement

|-
|[http://dmi.de DMI]||Archivar 4.0||Dokumentenmanagement in der Langzeitarchivierung||FHIR-Server||Patient Encounter DocumentReference Binary||STU3/R4||produktiv/in (Weiter-)Entwicklung||MHD||

|-
|[https://www.corpuls.world GS Elektromedizinische Geräte G. Stemple GmbH]||corpuls.web LIVE||Telemedizinsoftware zur Liveübertragung von EKGs, Vitalwerten und Patientendaten in der präklinischen Notfallmedizin. Als eigenständiges Medizinprodukt ist es zur Diagnose und Einholung eines Telekonsils im Rettungsdienst und Klinikumfeld zugelassen.||Webanwendung für Telekonsil, Schnittstelle zwischen corpuls Geräten und Drittsoftware||Bundle CapabilityStatement (Device) Encounter Patient (Procedure) Observation||R4||produktiv||-||

|-
|[https://www.ibm.com/de-de/ IBM]||eGA (elektronische Gesundheitsakte)||Elektronische Gesundheitsakte für Versicherte der Techniker Krankenkasse ||App||Claim DocumentReference Encounter Immunization Medication MedicationDispense MedicationRequest Organization Practitioner||STU3||in Entwicklung||-||

|-
|[http://www.icw.de ICW]||ICW eHealth Suite||Master Patient Index, Provider Directory, Document and Image Exchange, Clinical Data Repository, Integrated Forms, Appointments||FHIR-Server||Patient Encounter DocumentReference Binary Procedure ProcedureRequest Observation Condition Medication MedicationStatement MedicationDispense MedicationAdministration Questionnaire QuestionnaireResponse Appointment Practitioner PractitionerRole Organization Device ||STU3||produktiv||PIXm, PDQm, MHD, mCSD, QEDm||

|-
|[http://nursit-institute.de/de/startseite/ NursIT Institute]||CareIT Pro||Pflegedokumentationssystem, Pflegeplanung, Bettenbelegung, Questionnaire-Designer||Smart-App Client + SmileCDR Server||Encounter Patient Questionnaire QuestionnaireResponse Procedure ProcedureRequest CarePlan Observation ||STU3||produktiv||-||

|-
|[https://www.sap.com/industries/healthcare.html SAP SE]||SAP Health for Waiting Time Management||Verwaltung und Vorhersage von individuellen Wartezeiten von Patienten in der Notaufnahme und ambulanten Versorgung (siehe Disclaimer und Product Roadmap [https://www.sap.com/products/roadmaps.industry.html#pdf-asset=9435cfc6-c37c-0010-82c7-eda71af511fa&page=1 hier]) ||Cloud Anwendung für Krankenhäuser und Ambulanzen für den Patienten als Konsumenten||Bundle MessageHeader Patient Encounter Organization Observation Location ||STU3||produktiv||-||
|-
|[https://www.sap.com/industries/healthcare.html SAP SE]||SAP S/4HANA Healthcare for Patient Accounting||Patientenabrechnung für Leistungserbringer im Gesundheitswesen (siehe Disclaimer und Product Roadmap [https://www.sap.com/products/roadmaps.industry.html#pdf-asset=9435cfc6-c37c-0010-82c7-eda71af511fa&page=1 hier]) || Cloud-Anwendung für Patientenabrechner|| Patient EpisodeOfCare Encounter Coverage ChargeItem Invoice ||STU3 und R4||in Entwicklung||-||

|-
|[https://www.synedra.com synedra IT GmbH] || synedra AIM / FHIRServer || Anbindung von Laborsystemen direkt über FHIR oder HL7 V2 zu FHIR Konnektor, revisionssichere Archivierung von strukturierten Daten, Multiformat-Viewer inkl. Labor-Viewer, Bereitstellung von Daten für klinische Systeme, Anbindung von mobilen Apps und Webapplikationen von Drittherstellern, Health Content Management, PACS || FHIR-Server || Observation, DiagnosticReport, MedicationAdministration, AuditEvent (read-only), Patient (read-only), Encounter (read-only), Organization (read-only), Practitioner (read-only) || R4 || produktiv und in (Weiter-)Entwicklung || ATNA/ARR/Option RETRIEVE_AUDIT_MSG || [https://aimcloud-integration.synedra.net:8449/fhir/r4/metadata.json]
|-

|}

{{fmbox
| image = [[Bild:Attention_icon.svg|50px]]
| text = Die hier aufgeführten Informationen bestehen aus der Selbstauskunft der Hersteller. Diese Liste stellt keine Empfehlung von HL7 Deutschland e.V. dar. Auch wird die tatsächliche Kompatibilität der Produkte zum FHIR-Standard zum jetzigen Zeitpunkt nicht vom [[TC_FHIR|Technischen Komitee für FHIR]] überprüft.
}}

==Herstellerübergreifende FHIR-Projekte und Leitfäden in Deutschland==

{| class="hl7table"
!Beteiligte Organisationen!!Projekt!!Beschreibung!!Akteure/Rollen!!Resourcen (Profile)!!FHIR-Version!!Status!!IHE-Profile!!verwendete Produkte/Tools
|-
|Hochschule Niederrhein http://hsnr.de||[http://medikationsplan-plus.de MedikationsplanPlus]||FHIR dient neben CDA als strukturierte Darstellungsform für den Medikationsplan. Zudem erhält der auf dem papiergebundenen Medikationsplan aufgedruckte Barcode ein Ultrakurzformat, aus dem die Inhalte der FHIR-Resourcen wiederhergestellt werden können||Erzeuger des Medikationsplans Konsumenten des Medikationsplans||Patient Composition List MedicationStatement Medication||STU3||in Entwicklung||-||Simplifier/Forge
|-
|Hochschule Niederrhein http://hsnr.de||[http://www.genealyse.de Genealyse]||FHIR dient neben CDA als strukturierte Darstellungsform für den Genetic Testing Report.||Erzeuger des GTR Konsumenten des GTR||Patient Composition List MedicationStatement Medication||STU3||in Entwicklung||-||Simplifier/Forge
|-
|[http://dmi.de DMI] [https://dvmd.de/ DVMD]||[https://www.dmi.de/wissen/kdl/ Konsoliderte Dokumentenliste]||Publikation der KDL (einheitliche Terminologie für die Benennung von Dokumenttypen) sowie der Mappings auf IHE-DE Type- und Classcodes als FHIR-Terminologie-Ressourcen||-||ValueSet CodeSystem ConceptMap||STU3/R4||Publikation in Vorbereitung||-||Simplifier
|-
|UKs Aachen, Bonn, Düsseldorf, Essen, Halle, Hamburg-Eppendorf, Jena, Leipzig, Rostock, HL7 Deutschland u.a.||[http://www.smith.care Smart Medical Information Technology for Healthcare (SMITH)]||neben IHE-XDS-Infrastrukturen werden in den [https://www.medizininformatik-initiative.de/de/start Datenintegrationszentren] von SMITH FHIR-Server die zentrale Vorhaltung von / Zugriffsmöglichkeit auf Daten der Krankenversorgung bilden, die für spezifische Forschungsprojekte zur Nutzung bereitgestellt werden||Krankenversorger Forscher||Patient Encounter Condition Procedure Observation Medication DiagnosticReport Specimen Provenance Consent Questionnaire ResearchStudy Group Organization etc.||R4||in Entwicklung||-||ART-DECOR Simplifier
|-
|[https://www.uniklinikum-jena.de/gbit/Projekte.html Universitätsklinikum Jena]||ESSENZ||Beschreibung und Umsetzung essenzieller Bestandteile universitätsmedizinischer Dokumentation am UK Jena inkl. notwendiger Mappings, die perspektivisch von allen IT-Subsystemen auf Basis von FHIR kommuniziert und synchronisiert werden sollen (Anbindung von FHIR an ein VNA als Plattformstrategie)||Erzeuger klinischer Dokumentation Konsumenten klinischer Dokumentation||Patient Encounter Condition Procedure Observation Practitioner Organization etc.||R4||in Entwicklung||-||Simplifier (geplant)
|-
|[https://www.hs-osnabrueck.de/forschungsgruppe-informatik-im-gesundheitswesen/ Hochschule Osnabrück]||[https://simplifier.net/ePflegebericht/ ePflegebericht]||Darstellung des ePflegeberichts in HL7-FHIR||primär Pflegekräfte, als Empfänger auch Ärzte, Patienten und Angehörige möglich||Bundle Coding Composition Condition Device DeviceRequest Goal Observation Patient Procedure RelatedPerson||R4||in Entwicklung||-||Simplifier, Forge
|-
|[https://www.hs-osnabrueck.de/forschungsgruppe-informatik-im-gesundheitswesen/ Hochschule Osnabrück]||[https://simplifier.net/ewundbericht eWundbericht]||Darstellung des eWundberichts in HL7-FHIR||alle an der Wundversorgung beteiligten Professionen (z.B. Pflegekräfte, Ärzte, Wundmanager), als Empfänger auch Patienten und Angehörige möglich||AllergyIntolerance BodyStructure Bundle Composition Condition DeviceDefinition DocumentReference Goal Observation Procedure RiskAssessment||R4||in Entwicklung||-||Simplifier, Forge
|}
{{fmbox
| image = [[Bild:Attention_icon.svg|50px]]
| text = Die hier aufgeführten Informationen bestehen aus der Selbstauskunft der Organisationen. Die Nennung der Projekte impliziert keine Beteiligung von HL7 Deutschland e.V., es sei denn in der Spalte "Beteiligte Organisationen" explizit genannt.
}}

==FHIR-Projekte International==
siehe http://wiki.hl7.org/index.php?title=National_FHIR_Projects

Medizininformatik-Initiative

2020-01-31T13:43:46Z

Dammon:

Dies ist die Startseite der Medizininformatik-Initiative (MI-Initiative, MII) im Wiki des Interoperabilitätsforums. Die MII ist ein mehrphasiges Förderprogramm des BMBF, in dem an den deutschen Universitätskliniken und Partnereinrichtungen Datenintegrationszentren aufgebaut und vernetzt werden, um Forschungs- und Versorgungsdaten standortübergreifend verknüpfen zu können. Für konkrete medizinische Anwendungen werden auf dieser Basis innovative IT-Lösungen entwickelt, die die Möglichkeiten moderner digitaler Dienstleistungen und Infrastrukturen im Gesundheitsbereich zeigen sollen.
* [https://www.medizininformatik-initiative.de Link zur Website der Medizininformatik-Initiative]

== Kümmerer im Interoperabilitätsforum ==

* [https://www.uniklinikum-jena.de/datenintegrationszentrum Danny Ammon]
* [https://www.uniklinikum-jena.de/gbit/Ansprechpartner/Applikationen+f%C3%BCr+Forschung+und+Lehre/Anwendungsforschung.html Kutaiba Saleh]

== Kerndatensatz ==

Um Dateninhalte, -strukturen und -kodierungen in den Datenintegrationszentren der an der Medizininformatik-Initiative beteiligten Universitätsklinika auf Basis von Interoperabilitätsstandards zugreif- oder austauschbar zu gestalten, wird bis 2021 ein übergreifender MII-Kerndatensatz entwickelt, der in technischen Spezifikationen münden soll.
Der Kerndatensatz wird fortgeschrieben in ART-DECOR und Simplifier.net
* [https://www.medizininformatik-initiative.de/sites/default/files/inline-files/MII_04_Kerndatensatz_1-0.pdf Beschreibung des MII-Kerndatensatzes in der früheren Version 1.0 vom 10.3.2017 (PDF)]
* [https://art-decor.org/art-decor/decor-project--mide- Datensatzmodellierung des weiterentwickelten MII-Kerndatensatzes in ART-DECOR]
* [https://simplifier.net/organization/koordinationsstellemii/~projects FHIR-Profilierungsprojekte der weiterentwickelten Kerndatensatzmodule auf Simplifier.net]

== Konsortien ==

=== SMITH ===

Die universitätsmedizinischen Standorte Leipzig, Jena, Aachen, Halle(Saale), Bonn, Hamburg-Eppendorf, Essen, Düsseldorf und Rostock verbinden in ihrem Konzept medizininformatische, klinische, systemmedizinische, computerlinguistische und epidemiologische Kompetenzen. In enger Kooperation mit externen Partnern wird eine Architektur für die interoperable Nutzung von Daten aus der Krankenversorgung und der patientenorientierten Forschung über die Grenzen von Institutionen und Standorten aufgebaut. Dies ermöglicht über die SMITH-Service-Plattform die Nutzung der Ergebnisse durch Vernetzungspartner.
* [http://www.smith.care Link zur SMITH-Website]

==== Use Case ASIC ====

Im Use Case ASIC soll auf Intensivstationen mittels kontinuierlicher Auswertungen u.a. aus dem Patientendatenmanagementsystem eine algorithmisch basierte Überwachung des Zustandes kritisch kranker Patienten erfolgen. Damit wird die Voraussetzung für eine frühe Alarmierung geschaffen, die ein schnelles diagnostisches und therapeutisches Eingreifen ermöglichen soll. Diese Daten werden durch High-Performance-Computing analysiert und für die klinische Entscheidung annotiert.
* [https://art-decor.org/art-decor/decor-project--asic- Projekt ASIC in ART-DECOR]

==== Use Case HELP ====
Im Use Case HELP entwickeln wir ein krankenhausweites computergestütztes Entscheidungsunterstützungssystem zur Verbesserung der Ergebnisse von Patienten mit Blutstrominfektionen. Dabei geht es um den zielgerichteten, leitliniengerechten Einsatz von Antibiotika zur Bekämpfung bakterieller Infektionen – insbesondere vor dem Hintergrund einer zu geringen Zahl an ausgebildeten Infektiologen in Deutschland. Der Use Case wird auf Normal- und Intensivstationen an den SMITH-Standorten Jena, Leipzig und Aachen sowie Halle und Essen implementiert und evaluiert.
* [https://art-decor.org/art-decor/decor-project--help- Projekt HELP in ART-DECOR]

=== HiGHmed ===

Das Konsortium HiGHmed verbindet drei international führende und komplementär aufgestellte Medizinische Fakultäten und Universitätsklinika: Heidelberg, Göttingen und Hannover. Ergänzt wird der Verbund durch das Deutsche Krebsforschungszentrum (DKFZ) in Heidelberg. HiGHmed verfolgt das Ziel durch neue medizininformatische Lösungen und einen übergreifenden Datenaustausch die Effizienz klinischer Forschung zu steigern und die Versorgung der Patienten zu verbessern. Dabei profitieren die Partner von ihrer langjährigen Erfahrung auf dem Gebiet der klinischen Informationstechnologie im Bereich Entwicklung, Anwendung und Ausbildung. Neben den Kernpartnern wird HiGHmed von akademischen und privaten Partnern unterstützt.

* [http://www.highmed.org Link zur HiGHmed-Website]

==== Datenintegrationszentren ====

Um übergreifenden Datenaustausch und Datenintegration zu erreichen, wird an jedem Universitätsklinikum ein medizinisches Datenintegrationszentrum aufgebaut. Ein zusätzliches Datenintegrationszentrum mit Fokus auf Genomdaten und radiologischen Bilddaten am DKFZ wird mit den klinischen Zentren eng verknüpft. Der Aufbau der Datenintegrationszentren mit flexibler institutionsübergreifender Rahmenarchitektur basiert auf offenen Standards, um die Übertragung auf weitere Standorte inklusive der Einbindung neuer Datenbestände sicherzustellen. Planungsgrundlage für die Datenintegrationszentren und die Integrationsplattform sind drei medizinische Use Cases aus den Bereichen Onkologie, Kardiologie und Infektiologie.

==== Use Cases ====

Im '''Use Case Onkologie''' widmet sich der Verbund der Herausforderung enorme Datenmengen aus der Genomsequenzierung (omics-Daten) und Radiologie in die klinische Praxis zu integrieren. Ein virtuelles Onkologiezentrum wird den Behandlungsverlauf von Krebspatienten veranschaulichen und den Kliniken, Forschungseinrichtungen, Ärzten und Patienten als Austauschplattform dienen. Das virtuelle Onkologiezentrum wird maßgeblich dazu beitragen ähnliche Krebsfälle zu erkennen und eine individuelle patientenorientierte Behandlung zu ermöglichen. Das wird am Beispiel von Tumoren des Pankreas, der Leber und der Gallengänge demonstriert.

Im '''Use Case Kardiologie''' werden Daten von tragbaren, implantierten oder vernetzten Geräten in die IT-Architektur der Datenzentren integriert. Neue mobile diagnostische Geräte werden die derzeitige medizinische Praxis und Forschung erheblich beeinflussen. Diese liefern Datensätze aus Langzeitüberwachungen und -messungen und generieren dadurch spezifische und umfassende Datensätze. Risikopatienten können so frühzeitig erkannt und Krankenhausaufenthalte sowie die Sterbewahrscheinlichkeit verringert werden.

Im '''Use Case Infektionskontrolle''' wird ein automatisiertes Frühwarn- und Clustersystem entwickelt, welches die algorithmische Erkennung von Erregerclustern in Krankenhäusern ermöglicht. Dies beinhaltet auch die Identifikation von multiresistenten Keimen und deren Transmissionswege innerhalb und zwischen den Kliniken, die Prüfung ob es sich bei den Erregerclustern um Ausbrüche handelt und das Erkennen von möglichen Gründen für Übertragungen und Ausbrüche.

=== MIRACUM ===

MIRACUM vereint zehn Universitätsklinika, zwei Hochschulen und einen Industriepartner aus sieben deutschen Bundesländern. Ziel ist es, klinische Daten, Bilddaten und Daten aus molekularen/genomischen Untersuchungen sowohl standortbezogen als auch standortübergreifend über modular aufgebaute, skalierbare und föderierte Datenintegrationszentren für innovative Forschungsprojekte nutzbar zu machen. Neben der, mit solchen Datenintegrationszentren grundsätzlichen, Möglichkeit der Durchführung von Machbarkeitsstudien, Beobachtungsstudien und der Untersuchung von „Real World Pathways“ in großem Maßstab, wird MIRACUM die Rekrutierung von Patienten für klinische Studien, die Entwicklung von Prädiktionsmodellen und die Präzisionsmedizin unterstützen. Um die Biomedizinische Informatik und Medical Data Science zu stärken, wurden an den MIRACUM Standorten bereits zehn neue Professuren ausgeschrieben und weitere werden folgen. Zudem soll ein gemeinsames, standortübergreifendes Masterstudium zu „Biomedical Informatics und Medical Data Science“ aufgebaut werden.

* [https://www.miracum.org Link zur MIRACUM-Website]

==== Use Cases ====

'''Alerting in Care – IT Support for Patient Recruitment:''' Klinische Studien scheitern häufig bereits an der zu geringen Rekrutierung passender Studienteilnehmer/innen. Um die Rekrutierungsprozesse durch IT-Verfahren und vorhandene Routinedaten zu unterstützen, werden wir an jedem unserer Universitätsklinika entsprechende Rekrutierungsplattformen in die KIS-Umgebungen integrieren und die Dokumentationsqualität und Vollständigkeit der für die Rekrutierung herangezogenen Datenelemente kontinuierlich mittels regelmäßiger Evaluationen und Feedbackschleifen verbessern.

'''From Data to Knowledge – Clinico-molecular predictive knowledge tool:''' Mit dem schrittweisen inhaltlichen Ausbau der Datenintegrationszentren wird eine Basis gelegt, um Patientenkohorten anhand von klinischen Parametern, Biomarkern und molekularen/genomischen Untersuchungen zu identifizieren und in Subgruppen zu stratifizieren, so dass auf diese jeweils zugeschnittene Prädiktionsmodelle entwickelt werden können. Mittels FHIR-basierter, in die jeweiligen KIS-Umgebungen eingebetteter Smart-Apps werden die Prädiktionsmodelle in den Klinikalltag zurück gespielt und Ärzte in ihren diagnostischen und therapeutischen Entscheidungen unterstützt. Der klinische Fokus wird hierbei zunächst auf Lungenerkrankungen und Patienten mit Hirntumoren gelegt.

'''From Knowledge to Action – Support for Molecular Tumor Boards:''' Die Präzisionsmedizin ist im Kontext der Versorgung von Tumorpatienten bereits sehr weit fortgeschritten. Für viele Tumore kann man heute sogenannte “Driver Mutations” mittels tiefer genetischer Charakterisierung identifizieren und diese sehr gezielt therapieren. In Molekularen Tumorboards (MTB) laufen letztendlich alle klinischen Informationen und Bilder, sowie molekulare/genetische Untersuchungsergebnisse zur interdisziplinären Entscheidungsfindung zusammen. In diesem Kontext hat es sich MIRACUM zur Aufgabe gestellt, die komplexen Prozesse der Qualitätssicherung, Datenaufbereitung, Datenintegration und Informationsrecherche zwischen den genetischen Hochdurchsatzanalysen und der medizinischen Therapieentscheidung, mit innovativen IT-Lösungen zu optimieren und den Klinikern durch effiziente Datenvisualisierungen eine Entscheidungsunterstützung zu bieten.

=== DIFUTURE ===

Für die Medizin der Zukunft sind die Integration von Daten und ihre standortübergreifende Nutzung essentiell. DIFUTURE stellt den in der Krankenversorgung Tätigen und für die Forschung Daten und Wissen in innovativer Breite und Tiefe bereit, um die Prozesse der Krankenversorgung zu verbessern, Innovation zu beschleunigen und konkrete Fortschritte für die Patientinnen und Patienten zu erzielen.

In DIFUTURE haben sich drei Exzellenzuniversitäten mit ihren Universitätsklinika und weiteren, auch klinischen Partnern zusammengeschlossen. Es resultiert eine einmalige Synthese des Wissens aus Medizin, Informatik, Biostatistik und Bioinformatik. Die internationale Vernetzung ist eine weitere Stärke.

* [https://difuture.de Link zur DIFUTURE-Website]

==== Datenintegrationszentren ====

Die Datenintegrationszentren von DIFUTURE sind modular, erweiterbar und auf Standards basierend. Der Prozess der Datenintegration umfasst die Harmonisierung von Daten und von Prozessen. Dabei fokussiert er auf hohe Datenqualität. Um die notwendige Interoperabilität zu gewährleisten, werden kommerzielle Komponenten mit frei verfügbarer (Open-Source-) Software kombiniert. Datenschutz und Datensicherheit spielen eine zentrale Rolle, u.a. im Hinblick auf Sicherheit bereits im Entwurf, Datensparsamkeit und Schalenmodelle. Die Analysen und Studien von DIFUTURE werden verteilte Ansätze verwenden und so dem Methodentransfer gegenüber einem Datentransfer den Vorrang geben.

==== Use Cases ====

'''Anwendungsfall 1: Multiple Sklerose (MS)'''

Die Kliniker und Wissenschaftler des Konsortiums sind zentral in die Erforschung der MS involviert, in der Grundlagenforschung und in nationalen und internationalen Verbünden. Eine Datenintegration wurde bereits vorgenommen, um verteilte Analysen zu ermöglichen. Insbesondere die Entdeckung von Markern und Algorithmen zur Vorhersage des Krankheitsverlaufs und für eine früh einsetzende zielgerichtete und personalisierte Therapie stehen im Fokus. Das Spektrum der integrierten Daten ist breit und reicht von klinischen und Labordaten über multidimensionale Bilddaten zu genetischen Daten. Hier kann auf sehr große, bereits in wesentlichen Teilen standardisierte Datensammlungen zugegriffen werden.

'''Anwendungsfall 2: Parkinson-Krankheit'''

Alle Anwendungsfälle von DIFUTURE sind darauf ausgerichtet, verallgemeinerbare Ansätze zu etablieren. So werden die Integrations- und Analysemethoden des MS-Anwendungsfalles in analoger Weise auf die Parkinson-Krankheit übertragen. Auch hier werden Daten verschiedenster Art harmonisiert, in qualitätskontrollierter Weise integriert, und dann für Analysen im Konsortium und darüber hinaus nutzbar gemacht. Für alle Anwendungsfälle – vorgesehen sind auch seltene Erkrankungen, Krebs, Schlaganfall und Herz-Kreislauf-Erkrankungen – soll eine Präzisionsmedizin ermöglicht werden. Die Therapie, aber auch die (Früh-) Diagnose, die Vorbeugung und die Nachsorge sollen deutlich verbessert werden.

== Übergreifende Use Cases ==

* Polypharmazie – Arzneimittelwechselwirkungen – Risiken (POLAR): ''in Beantragung''
* Collaboration On Rare Diseases (CORD): ''in Beantragung''

== Wichtige Dokumente und Links ==

* [https://www.medizininformatik-initiative.de/de/ueber-die-inititative/ergebnisse Ergebnisdokumente der Medizinformatik-Initiative]
* [[MI-Initiative:_Modellierung_in_ART-DECOR|MII-Leitfaden zur Modellierung in ART-DECOR]]
* [https://www.hl7.org/fhir/resourcelist.html Aktuelle FHIR-Spezifikation (engl.)]
* [[HL7_CDA_Core_Principles|Basisprinzipien für die Spezifikation von CDA-Templates (engl.)]]

Medizininformatik-Initiative

2020-01-31T13:40:43Z

Dammon:

Dies ist die Startseite der Medizininformatik-Initiative (MI-Initiative, MII) im Wiki des Interoperabilitätsforums. Die MII ist ein mehrphasiges Förderprogramm des BMBF, in dem an den deutschen Universitätskliniken und Partnereinrichtungen Datenintegrationszentren aufgebaut und vernetzt werden, um Forschungs- und Versorgungsdaten standortübergreifend verknüpfen zu können. Für konkrete medizinische Anwendungen werden auf dieser Basis innovative IT-Lösungen entwickelt, die die Möglichkeiten moderner digitaler Dienstleistungen und Infrastrukturen im Gesundheitsbereich zeigen sollen.
* [https://www.medizininformatik-initiative.de Link zur Website der Medizininformatik-Initiative]

==Kümmerer im Interoperabilitätsforum==

* [https://www.uniklinikum-jena.de/datenintegrationszentrum Danny Ammon]
* [https://www.uniklinikum-jena.de/gbit/Ansprechpartner/Applikationen+f%C3%BCr+Forschung+und+Lehre/Anwendungsforschung.html Kutaiba Saleh]

==Kerndatensatz==

Um Dateninhalte, -strukturen und -kodierungen in den Datenintegrationszentren der an der Medizininformatik-Initiative beteiligten Universitätsklinika auf Basis von Interoperabilitätsstandards zugreif- oder austauschbar zu gestalten, wird bis 2021 ein übergreifender MII-Kerndatensatz entwickelt, der in technischen Spezifikationen münden soll.
Der Kerndatensatz wird fortgeschrieben in ART-DECOR und Simplifier.net
* [https://www.medizininformatik-initiative.de/sites/default/files/inline-files/MII_04_Kerndatensatz_1-0.pdf Beschreibung des MII-Kerndatensatzes in der Version 1.0 vom 10.3.2017 (PDF)]
* [https://art-decor.org/art-decor/decor-project--mide- Weiterentwicklung des MII-Kerndatensatzes in ART-DECOR]

==Konsortien==

===SMITH===

Die universitätsmedizinischen Standorte Leipzig, Jena, Aachen, Halle(Saale), Bonn, Hamburg-Eppendorf, Essen, Düsseldorf und Rostock verbinden in ihrem Konzept medizininformatische, klinische, systemmedizinische, computerlinguistische und epidemiologische Kompetenzen. In enger Kooperation mit externen Partnern wird eine Architektur für die interoperable Nutzung von Daten aus der Krankenversorgung und der patientenorientierten Forschung über die Grenzen von Institutionen und Standorten aufgebaut. Dies ermöglicht über die SMITH-Service-Plattform die Nutzung der Ergebnisse durch Vernetzungspartner.
* [http://www.smith.care Link zur SMITH-Website]

====Use Case ASIC====

Im Use Case ASIC soll auf Intensivstationen mittels kontinuierlicher Auswertungen u.a. aus dem Patientendatenmanagementsystem eine algorithmisch basierte Überwachung des Zustandes kritisch kranker Patienten erfolgen. Damit wird die Voraussetzung für eine frühe Alarmierung geschaffen, die ein schnelles diagnostisches und therapeutisches Eingreifen ermöglichen soll. Diese Daten werden durch High-Performance-Computing analysiert und für die klinische Entscheidung annotiert.
* [https://art-decor.org/art-decor/decor-project--asic- Projekt ASIC in ART-DECOR]

====Use Case HELP====
Im Use Case HELP entwickeln wir ein krankenhausweites computergestütztes Entscheidungsunterstützungssystem zur Verbesserung der Ergebnisse von Patienten mit Blutstrominfektionen. Dabei geht es um den zielgerichteten, leitliniengerechten Einsatz von Antibiotika zur Bekämpfung bakterieller Infektionen – insbesondere vor dem Hintergrund einer zu geringen Zahl an ausgebildeten Infektiologen in Deutschland. Der Use Case wird auf Normal- und Intensivstationen an den SMITH-Standorten Jena, Leipzig und Aachen sowie Halle und Essen implementiert und evaluiert.
* [https://art-decor.org/art-decor/decor-project--help- Projekt HELP in ART-DECOR]

===HiGHmed===

Das Konsortium HiGHmed verbindet drei international führende und komplementär aufgestellte Medizinische Fakultäten und Universitätsklinika: Heidelberg, Göttingen und Hannover. Ergänzt wird der Verbund durch das Deutsche Krebsforschungszentrum (DKFZ) in Heidelberg. HiGHmed verfolgt das Ziel durch neue medizininformatische Lösungen und einen übergreifenden Datenaustausch die Effizienz klinischer Forschung zu steigern und die Versorgung der Patienten zu verbessern. Dabei profitieren die Partner von ihrer langjährigen Erfahrung auf dem Gebiet der klinischen Informationstechnologie im Bereich Entwicklung, Anwendung und Ausbildung. Neben den Kernpartnern wird HiGHmed von akademischen und privaten Partnern unterstützt.

* [http://www.highmed.org Link zur HiGHmed-Website]

====Datenintegrationszentren====

Um übergreifenden Datenaustausch und Datenintegration zu erreichen, wird an jedem Universitätsklinikum ein medizinisches Datenintegrationszentrum aufgebaut. Ein zusätzliches Datenintegrationszentrum mit Fokus auf Genomdaten und radiologischen Bilddaten am DKFZ wird mit den klinischen Zentren eng verknüpft. Der Aufbau der Datenintegrationszentren mit flexibler institutionsübergreifender Rahmenarchitektur basiert auf offenen Standards, um die Übertragung auf weitere Standorte inklusive der Einbindung neuer Datenbestände sicherzustellen. Planungsgrundlage für die Datenintegrationszentren und die Integrationsplattform sind drei medizinische Use Cases aus den Bereichen Onkologie, Kardiologie und Infektiologie.

====Use Cases====

Im '''Use Case Onkologie''' widmet sich der Verbund der Herausforderung enorme Datenmengen aus der Genomsequenzierung (omics-Daten) und Radiologie in die klinische Praxis zu integrieren. Ein virtuelles Onkologiezentrum wird den Behandlungsverlauf von Krebspatienten veranschaulichen und den Kliniken, Forschungseinrichtungen, Ärzten und Patienten als Austauschplattform dienen. Das virtuelle Onkologiezentrum wird maßgeblich dazu beitragen ähnliche Krebsfälle zu erkennen und eine individuelle patientenorientierte Behandlung zu ermöglichen. Das wird am Beispiel von Tumoren des Pankreas, der Leber und der Gallengänge demonstriert.

Im '''Use Case Kardiologie''' werden Daten von tragbaren, implantierten oder vernetzten Geräten in die IT-Architektur der Datenzentren integriert. Neue mobile diagnostische Geräte werden die derzeitige medizinische Praxis und Forschung erheblich beeinflussen. Diese liefern Datensätze aus Langzeitüberwachungen und -messungen und generieren dadurch spezifische und umfassende Datensätze. Risikopatienten können so frühzeitig erkannt und Krankenhausaufenthalte sowie die Sterbewahrscheinlichkeit verringert werden.

Im '''Use Case Infektionskontrolle''' wird ein automatisiertes Frühwarn- und Clustersystem entwickelt, welches die algorithmische Erkennung von Erregerclustern in Krankenhäusern ermöglicht. Dies beinhaltet auch die Identifikation von multiresistenten Keimen und deren Transmissionswege innerhalb und zwischen den Kliniken, die Prüfung ob es sich bei den Erregerclustern um Ausbrüche handelt und das Erkennen von möglichen Gründen für Übertragungen und Ausbrüche.

===MIRACUM===

MIRACUM vereint zehn Universitätsklinika, zwei Hochschulen und einen Industriepartner aus sieben deutschen Bundesländern. Ziel ist es, klinische Daten, Bilddaten und Daten aus molekularen/genomischen Untersuchungen sowohl standortbezogen als auch standortübergreifend über modular aufgebaute, skalierbare und föderierte Datenintegrationszentren für innovative Forschungsprojekte nutzbar zu machen. Neben der, mit solchen Datenintegrationszentren grundsätzlichen, Möglichkeit der Durchführung von Machbarkeitsstudien, Beobachtungsstudien und der Untersuchung von „Real World Pathways“ in großem Maßstab, wird MIRACUM die Rekrutierung von Patienten für klinische Studien, die Entwicklung von Prädiktionsmodellen und die Präzisionsmedizin unterstützen. Um die Biomedizinische Informatik und Medical Data Science zu stärken, wurden an den MIRACUM Standorten bereits zehn neue Professuren ausgeschrieben und weitere werden folgen. Zudem soll ein gemeinsames, standortübergreifendes Masterstudium zu „Biomedical Informatics und Medical Data Science“ aufgebaut werden.

* [https://www.miracum.org Link zur MIRACUM-Website]

====Use Cases====

'''Alerting in Care – IT Support for Patient Recruitment:''' Klinische Studien scheitern häufig bereits an der zu geringen Rekrutierung passender Studienteilnehmer/innen. Um die Rekrutierungsprozesse durch IT-Verfahren und vorhandene Routinedaten zu unterstützen, werden wir an jedem unserer Universitätsklinika entsprechende Rekrutierungsplattformen in die KIS-Umgebungen integrieren und die Dokumentationsqualität und Vollständigkeit der für die Rekrutierung herangezogenen Datenelemente kontinuierlich mittels regelmäßiger Evaluationen und Feedbackschleifen verbessern.

'''From Data to Knowledge – Clinico-molecular predictive knowledge tool:''' Mit dem schrittweisen inhaltlichen Ausbau der Datenintegrationszentren wird eine Basis gelegt, um Patientenkohorten anhand von klinischen Parametern, Biomarkern und molekularen/genomischen Untersuchungen zu identifizieren und in Subgruppen zu stratifizieren, so dass auf diese jeweils zugeschnittene Prädiktionsmodelle entwickelt werden können. Mittels FHIR-basierter, in die jeweiligen KIS-Umgebungen eingebetteter Smart-Apps werden die Prädiktionsmodelle in den Klinikalltag zurück gespielt und Ärzte in ihren diagnostischen und therapeutischen Entscheidungen unterstützt. Der klinische Fokus wird hierbei zunächst auf Lungenerkrankungen und Patienten mit Hirntumoren gelegt.

'''From Knowledge to Action – Support for Molecular Tumor Boards:''' Die Präzisionsmedizin ist im Kontext der Versorgung von Tumorpatienten bereits sehr weit fortgeschritten. Für viele Tumore kann man heute sogenannte “Driver Mutations” mittels tiefer genetischer Charakterisierung identifizieren und diese sehr gezielt therapieren. In Molekularen Tumorboards (MTB) laufen letztendlich alle klinischen Informationen und Bilder, sowie molekulare/genetische Untersuchungsergebnisse zur interdisziplinären Entscheidungsfindung zusammen. In diesem Kontext hat es sich MIRACUM zur Aufgabe gestellt, die komplexen Prozesse der Qualitätssicherung, Datenaufbereitung, Datenintegration und Informationsrecherche zwischen den genetischen Hochdurchsatzanalysen und der medizinischen Therapieentscheidung, mit innovativen IT-Lösungen zu optimieren und den Klinikern durch effiziente Datenvisualisierungen eine Entscheidungsunterstützung zu bieten.

===DIFUTURE===

Für die Medizin der Zukunft sind die Integration von Daten und ihre standortübergreifende Nutzung essentiell. DIFUTURE stellt den in der Krankenversorgung Tätigen und für die Forschung Daten und Wissen in innovativer Breite und Tiefe bereit, um die Prozesse der Krankenversorgung zu verbessern, Innovation zu beschleunigen und konkrete Fortschritte für die Patientinnen und Patienten zu erzielen.

In DIFUTURE haben sich drei Exzellenzuniversitäten mit ihren Universitätsklinika und weiteren, auch klinischen Partnern zusammengeschlossen. Es resultiert eine einmalige Synthese des Wissens aus Medizin, Informatik, Biostatistik und Bioinformatik. Die internationale Vernetzung ist eine weitere Stärke.

* [https://difuture.de Link zur DIFUTURE-Website]

====Datenintegrationszentren====

Die Datenintegrationszentren von DIFUTURE sind modular, erweiterbar und auf Standards basierend. Der Prozess der Datenintegration umfasst die Harmonisierung von Daten und von Prozessen. Dabei fokussiert er auf hohe Datenqualität. Um die notwendige Interoperabilität zu gewährleisten, werden kommerzielle Komponenten mit frei verfügbarer (Open-Source-) Software kombiniert. Datenschutz und Datensicherheit spielen eine zentrale Rolle, u.a. im Hinblick auf Sicherheit bereits im Entwurf, Datensparsamkeit und Schalenmodelle. Die Analysen und Studien von DIFUTURE werden verteilte Ansätze verwenden und so dem Methodentransfer gegenüber einem Datentransfer den Vorrang geben.

====Use Cases====

'''Anwendungsfall 1: Multiple Sklerose (MS)'''

Die Kliniker und Wissenschaftler des Konsortiums sind zentral in die Erforschung der MS involviert, in der Grundlagenforschung und in nationalen und internationalen Verbünden. Eine Datenintegration wurde bereits vorgenommen, um verteilte Analysen zu ermöglichen. Insbesondere die Entdeckung von Markern und Algorithmen zur Vorhersage des Krankheitsverlaufs und für eine früh einsetzende zielgerichtete und personalisierte Therapie stehen im Fokus. Das Spektrum der integrierten Daten ist breit und reicht von klinischen und Labordaten über multidimensionale Bilddaten zu genetischen Daten. Hier kann auf sehr große, bereits in wesentlichen Teilen standardisierte Datensammlungen zugegriffen werden.

'''Anwendungsfall 2: Parkinson-Krankheit'''

Alle Anwendungsfälle von DIFUTURE sind darauf ausgerichtet, verallgemeinerbare Ansätze zu etablieren. So werden die Integrations- und Analysemethoden des MS-Anwendungsfalles in analoger Weise auf die Parkinson-Krankheit übertragen. Auch hier werden Daten verschiedenster Art harmonisiert, in qualitätskontrollierter Weise integriert, und dann für Analysen im Konsortium und darüber hinaus nutzbar gemacht. Für alle Anwendungsfälle – vorgesehen sind auch seltene Erkrankungen, Krebs, Schlaganfall und Herz-Kreislauf-Erkrankungen – soll eine Präzisionsmedizin ermöglicht werden. Die Therapie, aber auch die (Früh-) Diagnose, die Vorbeugung und die Nachsorge sollen deutlich verbessert werden.

== Übergreifende Use Cases ==

* Polypharmazie – Arzneimittelwechselwirkungen – Risiken (POLAR): ''in Beantragung''
* Collaboration On Rare Diseases (CORD): ''in Beantragung''

==Wichtige Dokumente und Links==

* [https://www.medizininformatik-initiative.de/de/ueber-die-inititative/ergebnisse Ergebnisdokumente der Medizinformatik-Initiative]
* [[MI-Initiative:_Modellierung_in_ART-DECOR|MII-Leitfaden zur Modellierung in ART-DECOR]]
* [https://www.hl7.org/fhir/resourcelist.html Aktuelle FHIR-Spezifikation (engl.)]
* [[HL7_CDA_Core_Principles|Basisprinzipien für die Spezifikation von CDA-Templates (engl.)]]

Medizininformatik-Initiative

2019-08-03T09:46:50Z

Dammon:

Dies ist die Startseite der Medizininformatik-Initiative (MI-Initiative, MII) im Wiki des Interoperabilitätsforums. Die MII ist ein mehrphasiges Förderprogramm des BMBF, in dem an den deutschen Universitätskliniken und Partnereinrichtungen Datenintegrationszentren aufgebaut und vernetzt werden, um Forschungs- und Versorgungsdaten standortübergreifend verknüpfen zu können. Für konkrete medizinische Anwendungen werden auf dieser Basis innovative IT-Lösungen entwickelt, die die Möglichkeiten moderner digitaler Dienstleistungen und Infrastrukturen im Gesundheitsbereich zeigen sollen.
* [https://www.medizininformatik-initiative.de Link zur Website der Medizininformatik-Initiative]

==Kümmerer im Interoperabilitätsforum==

* [https://www.uniklinikum-jena.de/datenintegrationszentrum Danny Ammon]
* [https://www.uniklinikum-jena.de/gbit/Ansprechpartner/Applikationen+f%C3%BCr+Forschung+und+Lehre/Anwendungsforschung.html Kutaiba Saleh]

==Wichtige Dokumente und Links==

* [https://www.medizininformatik-initiative.de/de/ueber-die-inititative/ergebnisse Ergebnisdokumente der Medizinformatik-Initiative]
* [[MI-Initiative:_Modellierung_in_ART-DECOR|MII-Leitfaden zur Modellierung in ART-DECOR]]
* [https://www.hl7.org/fhir/resourcelist.html Aktuelle FHIR-Spezifikation (engl.)]
* [[HL7_CDA_Core_Principles|Basisprinzipien für die Spezifikation von CDA-Templates (engl.)]]

==Kerndatensatz==

Um Dateninhalte, -strukturen und -kodierungen in den Datenintegrationszentren der an der Medizininformatik-Initiative beteiligten Universitätsklinika auf Basis von Interoperabilitätsstandards zugreif- oder austauschbar zu gestalten, wird bis 2021 ein übergreifender MII-Kerndatensatz entwickelt, der in technischen Spezifikationen münden soll.
Der Kerndatensatz wird fortgeschrieben in ART-DECOR und Simplifier.net
* [https://www.medizininformatik-initiative.de/sites/default/files/inline-files/MII_04_Kerndatensatz_1-0.pdf Beschreibung des MII-Kerndatensatzes in der Version 1.0 vom 10.3.2017 (PDF)]
* [https://art-decor.org/art-decor/decor-project--mide- Weiterentwicklung des MII-Kerndatensatzes in ART-DECOR]

==Konsortien==

===SMITH===

Die universitätsmedizinischen Standorte Leipzig, Jena, Aachen, Halle(Saale), Bonn, Hamburg-Eppendorf, Essen, Düsseldorf und Rostock verbinden in ihrem Konzept medizininformatische, klinische, systemmedizinische, computerlinguistische und epidemiologische Kompetenzen. In enger Kooperation mit externen Partnern wird eine Architektur für die interoperable Nutzung von Daten aus der Krankenversorgung und der patientenorientierten Forschung über die Grenzen von Institutionen und Standorten aufgebaut. Dies ermöglicht über die SMITH-Service-Plattform die Nutzung der Ergebnisse durch Vernetzungspartner.
* [http://www.smith.care Link zur SMITH-Website]

====Use Case ASIC====

Im Use Case ASIC soll auf Intensivstationen mittels kontinuierlicher Auswertungen u.a. aus dem Patientendatenmanagementsystem eine algorithmisch basierte Überwachung des Zustandes kritisch kranker Patienten erfolgen. Damit wird die Voraussetzung für eine frühe Alarmierung geschaffen, die ein schnelles diagnostisches und therapeutisches Eingreifen ermöglichen soll. Diese Daten werden durch High-Performance-Computing analysiert und für die klinische Entscheidung annotiert.
* [https://art-decor.org/art-decor/decor-project--asic- Projekt ASIC in ART-DECOR]

====Use Case HELP====
Im Use Case HELP entwickeln wir ein krankenhausweites computergestütztes Entscheidungsunterstützungssystem zur Verbesserung der Ergebnisse von Patienten mit Blutstrominfektionen. Dabei geht es um den zielgerichteten, leitliniengerechten Einsatz von Antibiotika zur Bekämpfung bakterieller Infektionen – insbesondere vor dem Hintergrund einer zu geringen Zahl an ausgebildeten Infektiologen in Deutschland. Der Use Case wird auf Normal- und Intensivstationen an den SMITH-Standorten Jena, Leipzig und Aachen sowie Halle und Essen implementiert und evaluiert.
* [https://art-decor.org/art-decor/decor-project--help- Projekt HELP in ART-DECOR]

===HiGHmed===

Das Konsortium HiGHmed verbindet drei international führende und komplementär aufgestellte Medizinische Fakultäten und Universitätsklinika: Heidelberg, Göttingen und Hannover. Ergänzt wird der Verbund durch das Deutsche Krebsforschungszentrum (DKFZ) in Heidelberg. HiGHmed verfolgt das Ziel durch neue medizininformatische Lösungen und einen übergreifenden Datenaustausch die Effizienz klinischer Forschung zu steigern und die Versorgung der Patienten zu verbessern. Dabei profitieren die Partner von ihrer langjährigen Erfahrung auf dem Gebiet der klinischen Informationstechnologie im Bereich Entwicklung, Anwendung und Ausbildung. Neben den Kernpartnern wird HiGHmed von akademischen und privaten Partnern unterstützt.

* [http://www.highmed.org Link zur HiGHmed-Website]

====Datenintegrationszentren====

Um übergreifenden Datenaustausch und Datenintegration zu erreichen, wird an jedem Universitätsklinikum ein medizinisches Datenintegrationszentrum aufgebaut. Ein zusätzliches Datenintegrationszentrum mit Fokus auf Genomdaten und radiologischen Bilddaten am DKFZ wird mit den klinischen Zentren eng verknüpft. Der Aufbau der Datenintegrationszentren mit flexibler institutionsübergreifender Rahmenarchitektur basiert auf offenen Standards, um die Übertragung auf weitere Standorte inklusive der Einbindung neuer Datenbestände sicherzustellen. Planungsgrundlage für die Datenintegrationszentren und die Integrationsplattform sind drei medizinische Use Cases aus den Bereichen Onkologie, Kardiologie und Infektiologie.

====Use Cases====

Im '''Use Case Onkologie''' widmet sich der Verbund der Herausforderung enorme Datenmengen aus der Genomsequenzierung (omics-Daten) und Radiologie in die klinische Praxis zu integrieren. Ein virtuelles Onkologiezentrum wird den Behandlungsverlauf von Krebspatienten veranschaulichen und den Kliniken, Forschungseinrichtungen, Ärzten und Patienten als Austauschplattform dienen. Das virtuelle Onkologiezentrum wird maßgeblich dazu beitragen ähnliche Krebsfälle zu erkennen und eine individuelle patientenorientierte Behandlung zu ermöglichen. Das wird am Beispiel von Tumoren des Pankreas, der Leber und der Gallengänge demonstriert.

Im '''Use Case Kardiologie''' werden Daten von tragbaren, implantierten oder vernetzten Geräten in die IT-Architektur der Datenzentren integriert. Neue mobile diagnostische Geräte werden die derzeitige medizinische Praxis und Forschung erheblich beeinflussen. Diese liefern Datensätze aus Langzeitüberwachungen und -messungen und generieren dadurch spezifische und umfassende Datensätze. Risikopatienten können so frühzeitig erkannt und Krankenhausaufenthalte sowie die Sterbewahrscheinlichkeit verringert werden.

Im '''Use Case Infektionskontrolle''' wird ein automatisiertes Frühwarn- und Clustersystem entwickelt, welches die algorithmische Erkennung von Erregerclustern in Krankenhäusern ermöglicht. Dies beinhaltet auch die Identifikation von multiresistenten Keimen und deren Transmissionswege innerhalb und zwischen den Kliniken, die Prüfung ob es sich bei den Erregerclustern um Ausbrüche handelt und das Erkennen von möglichen Gründen für Übertragungen und Ausbrüche.

===MIRACUM===

MIRACUM vereint zehn Universitätsklinika, zwei Hochschulen und einen Industriepartner aus sieben deutschen Bundesländern. Ziel ist es, klinische Daten, Bilddaten und Daten aus molekularen/genomischen Untersuchungen sowohl standortbezogen als auch standortübergreifend über modular aufgebaute, skalierbare und föderierte Datenintegrationszentren für innovative Forschungsprojekte nutzbar zu machen. Neben der, mit solchen Datenintegrationszentren grundsätzlichen, Möglichkeit der Durchführung von Machbarkeitsstudien, Beobachtungsstudien und der Untersuchung von „Real World Pathways“ in großem Maßstab, wird MIRACUM die Rekrutierung von Patienten für klinische Studien, die Entwicklung von Prädiktionsmodellen und die Präzisionsmedizin unterstützen. Um die Biomedizinische Informatik und Medical Data Science zu stärken, wurden an den MIRACUM Standorten bereits zehn neue Professuren ausgeschrieben und weitere werden folgen. Zudem soll ein gemeinsames, standortübergreifendes Masterstudium zu „Biomedical Informatics und Medical Data Science“ aufgebaut werden.

* [https://www.miracum.org Link zur MIRACUM-Website]

====Use Cases====

'''Alerting in Care – IT Support for Patient Recruitment:''' Klinische Studien scheitern häufig bereits an der zu geringen Rekrutierung passender Studienteilnehmer/innen. Um die Rekrutierungsprozesse durch IT-Verfahren und vorhandene Routinedaten zu unterstützen, werden wir an jedem unserer Universitätsklinika entsprechende Rekrutierungsplattformen in die KIS-Umgebungen integrieren und die Dokumentationsqualität und Vollständigkeit der für die Rekrutierung herangezogenen Datenelemente kontinuierlich mittels regelmäßiger Evaluationen und Feedbackschleifen verbessern.

'''From Data to Knowledge – Clinico-molecular predictive knowledge tool:''' Mit dem schrittweisen inhaltlichen Ausbau der Datenintegrationszentren wird eine Basis gelegt, um Patientenkohorten anhand von klinischen Parametern, Biomarkern und molekularen/genomischen Untersuchungen zu identifizieren und in Subgruppen zu stratifizieren, so dass auf diese jeweils zugeschnittene Prädiktionsmodelle entwickelt werden können. Mittels FHIR-basierter, in die jeweiligen KIS-Umgebungen eingebetteter Smart-Apps werden die Prädiktionsmodelle in den Klinikalltag zurück gespielt und Ärzte in ihren diagnostischen und therapeutischen Entscheidungen unterstützt. Der klinische Fokus wird hierbei zunächst auf Lungenerkrankungen und Patienten mit Hirntumoren gelegt.

'''From Knowledge to Action – Support for Molecular Tumor Boards:''' Die Präzisionsmedizin ist im Kontext der Versorgung von Tumorpatienten bereits sehr weit fortgeschritten. Für viele Tumore kann man heute sogenannte “Driver Mutations” mittels tiefer genetischer Charakterisierung identifizieren und diese sehr gezielt therapieren. In Molekularen Tumorboards (MTB) laufen letztendlich alle klinischen Informationen und Bilder, sowie molekulare/genetische Untersuchungsergebnisse zur interdisziplinären Entscheidungsfindung zusammen. In diesem Kontext hat es sich MIRACUM zur Aufgabe gestellt, die komplexen Prozesse der Qualitätssicherung, Datenaufbereitung, Datenintegration und Informationsrecherche zwischen den genetischen Hochdurchsatzanalysen und der medizinischen Therapieentscheidung, mit innovativen IT-Lösungen zu optimieren und den Klinikern durch effiziente Datenvisualisierungen eine Entscheidungsunterstützung zu bieten.

===DIFUTURE===

Für die Medizin der Zukunft sind die Integration von Daten und ihre standortübergreifende Nutzung essentiell. DIFUTURE stellt den in der Krankenversorgung Tätigen und für die Forschung Daten und Wissen in innovativer Breite und Tiefe bereit, um die Prozesse der Krankenversorgung zu verbessern, Innovation zu beschleunigen und konkrete Fortschritte für die Patientinnen und Patienten zu erzielen.

In DIFUTURE haben sich drei Exzellenzuniversitäten mit ihren Universitätsklinika und weiteren, auch klinischen Partnern zusammengeschlossen. Es resultiert eine einmalige Synthese des Wissens aus Medizin, Informatik, Biostatistik und Bioinformatik. Die internationale Vernetzung ist eine weitere Stärke.

* [https://difuture.de Link zur DIFUTURE-Website]

====Datenintegrationszentren====

Die Datenintegrationszentren von DIFUTURE sind modular, erweiterbar und auf Standards basierend. Der Prozess der Datenintegration umfasst die Harmonisierung von Daten und von Prozessen. Dabei fokussiert er auf hohe Datenqualität. Um die notwendige Interoperabilität zu gewährleisten, werden kommerzielle Komponenten mit frei verfügbarer (Open-Source-) Software kombiniert. Datenschutz und Datensicherheit spielen eine zentrale Rolle, u.a. im Hinblick auf Sicherheit bereits im Entwurf, Datensparsamkeit und Schalenmodelle. Die Analysen und Studien von DIFUTURE werden verteilte Ansätze verwenden und so dem Methodentransfer gegenüber einem Datentransfer den Vorrang geben.

====Use Cases====

'''Anwendungsfall 1: Multiple Sklerose (MS)'''

Die Kliniker und Wissenschaftler des Konsortiums sind zentral in die Erforschung der MS involviert, in der Grundlagenforschung und in nationalen und internationalen Verbünden. Eine Datenintegration wurde bereits vorgenommen, um verteilte Analysen zu ermöglichen. Insbesondere die Entdeckung von Markern und Algorithmen zur Vorhersage des Krankheitsverlaufs und für eine früh einsetzende zielgerichtete und personalisierte Therapie stehen im Fokus. Das Spektrum der integrierten Daten ist breit und reicht von klinischen und Labordaten über multidimensionale Bilddaten zu genetischen Daten. Hier kann auf sehr große, bereits in wesentlichen Teilen standardisierte Datensammlungen zugegriffen werden.

'''Anwendungsfall 2: Parkinson-Krankheit'''

Alle Anwendungsfälle von DIFUTURE sind darauf ausgerichtet, verallgemeinerbare Ansätze zu etablieren. So werden die Integrations- und Analysemethoden des MS-Anwendungsfalles in analoger Weise auf die Parkinson-Krankheit übertragen. Auch hier werden Daten verschiedenster Art harmonisiert, in qualitätskontrollierter Weise integriert, und dann für Analysen im Konsortium und darüber hinaus nutzbar gemacht. Für alle Anwendungsfälle – vorgesehen sind auch seltene Erkrankungen, Krebs, Schlaganfall und Herz-Kreislauf-Erkrankungen – soll eine Präzisionsmedizin ermöglicht werden. Die Therapie, aber auch die (Früh-) Diagnose, die Vorbeugung und die Nachsorge sollen deutlich verbessert werden.

== Übergreifende Use Cases ==

* Polypharmazie – Arzneimittelwechselwirkungen – Risiken (POLAR): ''in Beantragung''
* Collaboration On Rare Diseases (CORD): ''in Beantragung''

IF 2019-06-27

2019-06-28T14:46:49Z

Dammon: /* Medizininformatik-Initiative (28.06.2019) */

{{#CustomTitle:Interoperabilitätsforum / TC-Arbeit 27. und 28. Juni 2019 in Heidelberg}}
{{Infobox Dokument
|Title = Interoperabilitätsforum / TC-Arbeit 27. und 28. Juni 2019 in Heidelberg
|Short = Interoperabilitätsforum 2019-06-27
|Type = Agenda
|Version = 1.0
|Copyright = 2019
|Namespace = iopfp
|Status =
|Period =
|OID =
|Realm = Deutschland
}}

= Veranstaltungsort und -zeiten =
27. und 28. Juni 2019 in Heidelberg

Tagungsort: Seminarraum 108, Im Neuenheimer Feld 346, 69120 Heidelberg.

Tag 1
*ab 11 Uhr bis ca. 17:30 Uhr
*Abendveranstaltung (gemeinsames Essen) wird noch angekündigt
Tag 2
*9 Uhr bis ca. 15 Uhr

Siehe auch Abschnitt [[#Hinweise|Hinweise]].

Das [[Interoperabilitätsforum]] diskutiert und bearbeitet Themen zur Standardisierung der Technischen Komitees der HL7-Benutzergruppe, IHE Deutschland und anderer Standardisierungsaktivitäten im Gesundheitswesen.

=vorgesehene Agenda=

= Agenda Do. vormittag =

== FHIR ==
* FHIR-Slam: Questionnaires (Simone/Patrick)

* Überblick: weitere Entwicklung deutsche Basisprofile (Simone/Stefan)
** Migration STU3->R4
** Basis vs. Core
** Merge von Observations mit IPS
** Timeline und Partizipation
** Encounter CRs
* Strategie International: IPS als Inhaltsprofile für AppleHealth (außerhalb von US) und Argonaut SMART-Profil als int. Profil für Patientenzugriff? (Simone)
* Bericht DevDays Redmont (Simone)
* Patient Reported Outcomes und Formulare on FHIR: Electronic Questionnaires (Patrick)
* Umgang mit Versichertennummern im PKV-Bereich: Erfordernis von Namensräumen/NamingSystems für PKV-Versicherte (??)

=Agenda Do. nachmittag=

== FHIR (Fortsetzung) ==
* Onkologische Basisprofile: Scope und Status (Alexander)
* FHIR Store für CQL-Queries (Alexander Kiel)

==IHE==
* Anregung an IHE Deutschland, ein einheitliches Prozessmodell zu definieren (Diskussion 10-20min)

==abgeschlossene Ballotierungsverfahren: Ergebnisse de Kommentierung==
* eRezept (F. Oemig)
* eMDAF (T.Eggers)

== parallel am Do. nachmittag: BREAKOUT-Session: AG Einwilligungsmanagement ==
*Präsenzmeeting am 27.06. nachmittags. Fortsetzung der Detailarbeit an FHIR-Profilen und Workflows.

= Agenda Fr. vormittag=

==neue Leitfäden==
* eImpfpass (R. Franke)
* Hilfsmittel (R. Franke)
* weitere Musterformulare (T.Eggers, 27.6.)
** eAU die Zweite - wie kann‘s mit den Mustern 1b,1c und weiteren Mustern weitergehen
** Muster 20 (Wiedereingliederungsplan)
** Muster 21 (Ärztliche Bescheinigung zur Erkrankung des Kindes)
** Muster 53 (Anfrage im Zusammenhang mit AU-Zeiten)

==Patient Summary und eRezept (cross-border)==
* Kurzbericht

== Medizininformatik-Initiative (28.06.2019) ==
* Fortschritte ART-DECOR und FHIR-Profilierung (Danny Ammon, Alexander Zautke)
**siehe [[Media:20190628_MI-Initiative.pdf|Präsentation]]

* Rest FHIR

== FHIR ==
* Koordination/Abstimmung zwischen TC und MI-Initiative (alle)
* FHIR Community Process (??)
* IG Best Practice (Alexander)
* KDL on FHIR - Dokumententypisierung mit Mapping auf IHE-Type-/Classcodes (Simone)
* Wundbericht - Profilierung (Mareike, Alexander Zautke)

=Agenda Fr nachmittag=

== vesta (S. Hennecke)==
* Aktuelle Zahlen, Daten, Fakten
* Prozessanpassungen vesta
* Weiterentwicklungen vesta

==Sonstiges==
* Wie vertragen sich Arztbrief Plus und HL7 Entlassmanagementbrief

=Hinweise=
'''Teilnahme:''' An den Sitzungen können alle Interessierten teilnehmen, egal ob Mitglied bei HL7, IHE oder einer der kooperierenden Organisationen oder nicht! Um eine vorherige Anmeldung über https://doodle.com/poll/6np3k9b286exr2cs und an [mailto:info@interoperabilitaetsforum.de info@interoperabilitaetsforum.de] wird allerdings gebeten.

'''Zeiten:'''
Das Treffen beginnt traditionell am ersten Tag um 10:30 mit Kaffee/Tee, um 11 Uhr beginnt die Besprechung. Am zweiten Tag beginnt das Treffen um 9 Uhr und dauert bis zu Nachmittag (meist ca. 15-16 Uhr)

'''Agendapunkte:'''
Die o.g. Agenda ist vorläufig und wird ständig aktualisiert. Weitere Agendapunkte bitte an [mailto:info@interoperabilitaetsforum.de info@interoperabilitaetsforum.de] schicken.

'''Unterkunft:'''
Für ein Zimmer in einem der umliegenden Hotels sorgen die Teilnehmer selbst.

'''Gemeinsames Abendessen:'''
tbd, ab 19 Uhr

=Medienpartner=

Unsere Medienpartner sind:

{| width="100%"
|-
| [[file:Logo_kma.png|200px|kma]]
| [[file:Logo_EHEALTHCOM.jpg|300px|eHealthcom]]
| [[file:Logo_kh-it.PNG|300px|KH-IT]]
|}


[[Kategorie:IF Treffen]]
[[Kategorie:Interoperabilitätsforum 2019]]

IF 2019-06-27

2019-06-28T10:15:13Z

Dammon: /* Medizininformatik-Initiative (28.06.2019) */

{{#CustomTitle:Interoperabilitätsforum / TC-Arbeit 27. und 28. Juni 2019 in Heidelberg}}
{{Infobox Dokument
|Title = Interoperabilitätsforum / TC-Arbeit 27. und 28. Juni 2019 in Heidelberg
|Short = Interoperabilitätsforum 2019-06-27
|Type = Agenda
|Version = 1.0
|Copyright = 2019
|Namespace = iopfp
|Status =
|Period =
|OID =
|Realm = Deutschland
}}

= Veranstaltungsort und -zeiten =
27. und 28. Juni 2019 in Heidelberg

Tagungsort: Seminarraum 108, Im Neuenheimer Feld 346, 69120 Heidelberg.

Tag 1
*ab 11 Uhr bis ca. 17:30 Uhr
*Abendveranstaltung (gemeinsames Essen) wird noch angekündigt
Tag 2
*9 Uhr bis ca. 15 Uhr

Siehe auch Abschnitt [[#Hinweise|Hinweise]].

Das [[Interoperabilitätsforum]] diskutiert und bearbeitet Themen zur Standardisierung der Technischen Komitees der HL7-Benutzergruppe, IHE Deutschland und anderer Standardisierungsaktivitäten im Gesundheitswesen.

=vorgesehene Agenda=

= Agenda Do. vormittag =

== FHIR ==
* FHIR-Slam: Questionnaires (Simone/Patrick)

* Überblick: weitere Entwicklung deutsche Basisprofile (Simone/Stefan)
** Migration STU3->R4
** Basis vs. Core
** Merge von Observations mit IPS
** Timeline und Partizipation
** Encounter CRs
* Strategie International: IPS als Inhaltsprofile für AppleHealth (außerhalb von US) und Argonaut SMART-Profil als int. Profil für Patientenzugriff? (Simone)
* Bericht DevDays Redmont (Simone)
* Patient Reported Outcomes und Formulare on FHIR: Electronic Questionnaires (Patrick)
* Umgang mit Versichertennummern im PKV-Bereich: Erfordernis von Namensräumen/NamingSystems für PKV-Versicherte (??)

=Agenda Do. nachmittag=

== FHIR (Fortsetzung) ==
* Onkologische Basisprofile: Scope und Status (Alexander)
* FHIR Store für CQL-Queries (Alexander Kiel)

==IHE==
* Anregung an IHE Deutschland, ein einheitliches Prozessmodell zu definieren (Diskussion 10-20min)

==abgeschlossene Ballotierungsverfahren: Ergebnisse de Kommentierung==
* eRezept (F. Oemig)
* eMDAF (T.Eggers)

== parallel am Do. nachmittag: BREAKOUT-Session: AG Einwilligungsmanagement ==
*Präsenzmeeting am 27.06. nachmittags. Fortsetzung der Detailarbeit an FHIR-Profilen und Workflows.

= Agenda Fr. vormittag=

==neue Leitfäden==
* eImpfpass (R. Franke)
* Hilfsmittel (R. Franke)
* weitere Musterformulare (T.Eggers, 27.6.)
** eAU die Zweite - wie kann‘s mit den Mustern 1b,1c und weiteren Mustern weitergehen
** Muster 20 (Wiedereingliederungsplan)
** Muster 21 (Ärztliche Bescheinigung zur Erkrankung des Kindes)
** Muster 53 (Anfrage im Zusammenhang mit AU-Zeiten)

==Patient Summary und eRezept (cross-border)==
* Kurzbericht

== Medizininformatik-Initiative (28.06.2019) ==
* Fortschritte ART-DECOR und FHIR-Profilierung (Danny Ammon)
**siehe [[Media:20190628_MI-Initiative.pdf|Präsentation]]

* Rest FHIR

== FHIR ==
* Koordination/Abstimmung zwischen TC und MI-Initiative (alle)
* FHIR Community Process (??)
* IG Best Practice (Alexander)
* KDL on FHIR - Dokumententypisierung mit Mapping auf IHE-Type-/Classcodes (Simone)
* Wundbericht - Profilierung (Mareike, Alexander Zautke)

=Agenda Fr nachmittag=

== vesta (S. Hennecke)==
* Aktuelle Zahlen, Daten, Fakten
* Prozessanpassungen vesta
* Weiterentwicklungen vesta

==Sonstiges==
* Wie vertragen sich Arztbrief Plus und HL7 Entlassmanagementbrief

=Hinweise=
'''Teilnahme:''' An den Sitzungen können alle Interessierten teilnehmen, egal ob Mitglied bei HL7, IHE oder einer der kooperierenden Organisationen oder nicht! Um eine vorherige Anmeldung über https://doodle.com/poll/6np3k9b286exr2cs und an [mailto:info@interoperabilitaetsforum.de info@interoperabilitaetsforum.de] wird allerdings gebeten.

'''Zeiten:'''
Das Treffen beginnt traditionell am ersten Tag um 10:30 mit Kaffee/Tee, um 11 Uhr beginnt die Besprechung. Am zweiten Tag beginnt das Treffen um 9 Uhr und dauert bis zu Nachmittag (meist ca. 15-16 Uhr)

'''Agendapunkte:'''
Die o.g. Agenda ist vorläufig und wird ständig aktualisiert. Weitere Agendapunkte bitte an [mailto:info@interoperabilitaetsforum.de info@interoperabilitaetsforum.de] schicken.

'''Unterkunft:'''
Für ein Zimmer in einem der umliegenden Hotels sorgen die Teilnehmer selbst.

'''Gemeinsames Abendessen:'''
tbd, ab 19 Uhr

=Medienpartner=

Unsere Medienpartner sind:

{| width="100%"
|-
| [[file:Logo_kma.png|200px|kma]]
| [[file:Logo_EHEALTHCOM.jpg|300px|eHealthcom]]
| [[file:Logo_kh-it.PNG|300px|KH-IT]]
|}


[[Kategorie:IF Treffen]]
[[Kategorie:Interoperabilitätsforum 2019]]

Datei:20190628 MI-Initiative.pdf

2019-06-28T10:13:45Z

Dammon:

Medizininformatik-Initiative

2019-06-16T12:38:08Z

Dammon:

Medizininformatik-Initiative

2019-06-16T12:37:05Z

Dammon: /* Wichtige Dokumente */

HL7 CDA Core Principles

2019-06-16T11:49:00Z

Dammon: /* Use of XML */

== Introduction ==

This implementation guide specifies the ''Core Principles'' of using the ''Clinical Document Architecture'' <ref>Clinical Document Architecture Release 2: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=7</ref>.

=== Scope ===

This guide focuses on ''Data Types Release 1'' <ref>HL7 Data Types Release 1: http://www.hl7.org</ref>. Meanwhile an ISO specification ISO 21090 is out, also known as Data Type Release 2. The latter is subject to another implementation guide that will be published when ISO data types are used.

=== Focus of this document: HL7 Version 3 Data Types for CDA ===

The following chapters of this document will focus on the description of the data types and associated material. It will highlight the essentials in four chapters, all focusing on the Norwegian situation.
* '''Common aspects:''' explains common aspects of use of CDA and XML
* '''Data types:''' gives an overview and detailed specification of all data types used in CDA
* '''Identification schemes:''' explains major aspects of identification and the use in CDA
* '''Use of vocabulary:''' explains major aspects of vocabulary use in CDA.

=== Background ===

In many (European) countries, implementation guides for the use of data types in HL7 V3 are published. They take into account country specific constraints on the data types.

=== Legend of symbols ===

In this document several symbols are used.

{| class="hl7table" style="width:50%"
| [[File:Pfeil_rechts.png|50px]] || This is an important item
|-
| [[File:Issue.svg|50px]] || This is a known open issue
|-
| [[File:Faq.svg|50px]] || This is a frequently asked question (FAQ) with answer
|-
| [[File:Conformance.svg|50px]] || This is a constraint; in some situations also the rule identification is specified, e.g. dtr1-1-ANY, which links to the corresponding validation rule.
|}

=== Version history ===

{| class="hl7table" style="width:50%"
|+
! Version !! Date !! Description !! Author
|-
| 1.1 || 2019-04-24 || Refurbished guide based on earlier work || Kai U. Heitmann
|}

== Common aspects ==

=== Use of XML ===

HL7 Version 3 CDA uses the Extensible Markup Language (XML) as the exchange format. It is assumed that the reader is familiar with common XML aspects <ref>World Wide Web Consortium. Extensible Markup Language, 1.0, 2nd Edition: http://www.w3.org/TR/REC-xml</ref><ref>World Wide Web Consortium. XML Schema: http://www.w3.org/TR/xmlschema-0/,   http://www.w3.org/TR/xmlschema-1/,   http://www.w3.org/TR/xmlschema-2/</ref>. However, some constraints are made regarding the use of CDA.

==== Character Set ====

{{ConstraintBox|
The character encoding of any CDA document shall be “UTF-8”.}}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="utf-8"?>
</syntaxhighlight>

=== CDA document structure ===

The XML namespace for CDA Release 2 documents is ''<nowiki>urn:hl7-org:v3</nowiki>''. This must be correctly mentioned in every XML instance.

CDA XML documents starts with the root element ''ClinicalDocument''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">


...

<component>
<structuredBody>
...
</structuredBody>
</component>

</ClinicalDocument>
</syntaxhighlight>

== Data types ==

=== Introduction ===

The following chapter describes the typical data types used in CDA implementation guides. For further information please refer to the HL7 V3 standard and its two parts concerning data types:
* Abstract Data type definition <ref>HL7 Version 3 Abstract Data type definition: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=264</ref>
* XML ITS for data types <ref>XML ITS for data types: https://www.hl7.org/documentcenter/public_temp_682D4D16-1C23-BA17-0C789BA52BEDB68E/wg/inm/datatypes-its-xml20050714.htm</ref>
Data types are properties of model class attributes and the basic building blocks of information in a CDA XML instance. For example, a model attribute named “time” has as its data type a time stamp “TS” (see Figure 1).

[[File:CDA_Core_Principles_Figure_1_CDA_Structure_Data_Types.png|700px]]

<ref group="Figure">CDA structure (left) and the data type specification (right)</ref> ''CDA structure (left) and the data type specification (right)''

=== XML representation of data types ===

Actual data is mostly carried in HL7 Version 3 by populating XML attributes and not as element content. Exceptions are names of persons and organizations as well as addresses.

The XML elements have names like the model attributes. For example, a model attribute “id” has a corresponding XML element named <id…>. The model determines the sequence of elements and their hierarchy. The data type itself determines the XML attributes within the start tag. The notation here is as follows:

{| class="hl7table"
|+
! Attribute !! DT !! Conf !! Description
|-
| (name of the model attribute or XML element) || Data type || Conformance, i.e. O, R, M || Textual description
|}

XML attributes (data type properties) are denoted as ''@attribute'' in order to distinguish their names from XML elements.

Example: in the example model above, the data type of the ''id'' attribute's is ''II'' (Instance Identifier). The corresponding XML attributes for that data type include ''@root'' and ''@extension''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id root="..." extension="..." />
</syntaxhighlight>

A description of the data types and their corresponding XML representation is contained in subsequent paragraphs of this guide.

==== Exceptions using XML element content ====

For most data types, the actual data is conveyed in XML attributes. However, there are some exceptions. For the data types binary (BIN), Encapsulated Data (ED), Entity Name (EN), Person Name (PN), Organization Name (ON), Trivial Name (TN), Address (AD) and character string data (ST), information is carried as element content.

Example: the components of an address <addr> are represented by sub elements with the data as element content (in the example shown in black).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr>
<streetAddressLine>Thormøhlens gate 12</streetAddressLine>
<postalCode>5006</postalCode>
<city>Bergen</city>
</addr>
</syntaxhighlight>

==== Combined data types ====

There are a number of so-called combined data types. For example, an interval with a lower and upper limit and a ratio that has a nominator and a denominator value.

In combined data types the substructure (e.g. <low> <high> in an interval) are represented as child elements of the relevant data type element.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110701"/>
<high value="20110729"/>
</effectiveTime>
</syntaxhighlight>

==== Conformance information ====

The conformance indicators distinguish kinds of conformance information described shortly here.

* '''O''': An optional item may be omitted if no data is present, i.e. no corresponding XML attribute or element is sent (marked as “O”)
* '''R''': For required items, lower cardinality is always zero or 1.
** Elements must be present and populated with data if present in the sending system. If no data is available (yet), a null flavor (see below) indicates and possibly classifies the missing information (marked as R).
** Attribute flagged as required must be present in the instance and populated.
* '''M''': For mandatory elements data must be sent and no missing values are allowed, i.e. if the sending system does not have information for mandatory elements the XML instance cannot be created and sent (marked as M).
* '''NP''': no data may be present at all (not permitted)
* '''C''': conditional conformance; typically a conformance table shows the circumstances (conditions) derived from information in the instance and the corresponding cardinalities and conformance statements.

=== Missing values (null flavor) ===

For every data type it is possible to specify a missing value including a kind of reason why data is missing. Instead of specifying any attribute of the corresponding element, a ''@nullFlavor'' attribute expresses the omission of data. Note that missing data is not allowed for mandatory elements (see above).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value nullFlavor="OTH"/>

<code nullFlavor="UNK"/>

<booleanInd nullFlavor="NI"/>

</syntaxhighlight>

The codes for the ''@nullFlavor'' attribute are drawn from the following hierarchical code system. It is a Coded Simple (CS), which means it has no code system (attribute ''@codeSystem'') specified.

{| class="hl7table"
|+<ref group="Table">NullFlavor</ref> ''NullFlavor''
! Code
! width=15% | Print Name
! Definition / Description
|-
| NI || No Information || No information whatsoever can be inferred from this exceptional value. This is the most general exceptional value. It is also the default exceptional value.
|-
|   OTH || other || The actual value is not an element in the value domain of a variable. (e.g., concept not provided by required code system).
|-
|     NINF || negative infinity || Negative infinity of numbers.
|-
|     PINF || positive infinity || Positive infinity of numbers.
|-
|   UNK || unknown || A proper value is applicable, but not known.
|-
|     ASKU || asked but unknown || Information was sought but not found (e.g., patient was asked but didn't know)
|-
|       NAV || temporarily unavailable || Information is not available at this time but it is expected that it will be available later.
|-
|       NASK || not asked || This information has not been sought (e.g., patient was not asked)
|-
|       TRC || trace || The content is greater than zero, but too small to be quantified.
|-
|   MSK || masked || There is information on this item available but it has not been provided by the sender due to security, privacy or other reasons. There may be an alternate mechanism for gaining access to this information.
Note: using this null flavour does provide information that may be a breach of confidentiality, even though no detail data is provided. Its primary purpose is for those circumstances where it is necessary to inform the receiver that the information does exist without providing any detail.
|-
|   NA || not applicable || No proper value is applicable in this context (e.g., last menstrual period for a male).
|-
| NP || not present || Value is not present in a message. This is only defined in messages, never in application data! All values not present in the message must be replaced by the applicable default, or no-information (NI) as the default of all defaults.
|}

=== ANY as the generic data type ===

This abstract data type is the basis for all other data types. Not a single value within a CDA document has the effective data type ANY, but any data type within HL7v3 is a specialization of ANY. This also means that any other data type inherits all properties of ANY (see [[#Missing_values_.28null_flavor.29|“Missing values (null flavor)”]]).

The ANY type is occasionally found in HL7 models when it comes to clinical finding etc. where – at model time – the actual data type of the value is not known. At instantiation time however, the actual data type ''is'' known and ANY is always replaced by a particular data type in an instance.

One example is the observation value (child element value in an observation), where in the model the data type of value cannot be anticipated. When instantiation is taking place, the data type is specified by the XML instance attribute ''@xsi:type''. This information can be used by the receiver to validate and process the value.

Attributes of an element with this data type are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@nullFlavor''' || <center>CS</center> || <center>–</center> || Classification of the missing value, see [[#Missing_values_.28null_flavor.29|3.3 Missing values (null flavor)]].
|}

{| class="hl7table" style="width:100%"
| width=8% | <center>[[File:Conformance.svg|50px]] dtr1-1-ANY</center> || If there is a ''nullFlavor'', there shall be no other attribute or element, unless it's ''nullFlavor="OTH"''.

In that case ''@codeSystem'' or ''originalText'' (see “code” data types) may have a value.
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">

<value xsi:type="CE" code="N11.9" codeSystem="2.16.840.1.113883.6.3"/>


<value xsi:type="PQ" value="12" unit="mL"/>


<value xsi:type="ED">this is text</value>
</syntaxhighlight>

=== Boolean (BL) ===

Elements of this data type refer to Boolean logic and have an attribute ''@value''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>BL</center> || <center>–</center> || Valued as “true” or “false”
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<negationInd value="false"/>

<deceasedInd value="true"/>

</syntaxhighlight>

In some situations, the BL data does not apply to an XML element, but an attribute. In that case, the attribute carries the Boolean value directly.
<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<support contextConductionInd ="false">
...
</support>
</syntaxhighlight>

=== Instance Identifier (II) ===

This data type identifies instances of classes like observations or entities (persons, organizations). Attributes are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@extension''' || <center>ST</center> || <center>O</center> || Identification
|-
| '''@root''' || <center>OID</center> || <center>R</center> || Source of identification
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id extension="13234453645" root="2.16.840.1.113883.2.6.15.3.427.1"/>
</syntaxhighlight>

The ''@root'' attribute is of type OID (object identifier), a unique identifier of the issuing authority or system. For example, a patient with a patient number 13234453645 created by a specific healthcare provider organization is uniquely identified by the number itself in ''@extension'' and the OID of the organization or the sending system, in the example 2.16.840.1.113883.2.6.15.3.427.1 in ''@root''.

In some cases, a single OID identifies an object uniquely. In that situation, only ''@root'' is populated and ''@extension'' is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Encapsulated Data (ED) ===

Elements of this data type carry multimedia content. The actual multimedia content is represented as element content. There are two situations for the use of ED:

* Inline: The full data is transmitted in the type. This form is mainly used for text.
* By reference: a thumbnail is provided which links to the full data by reference.

In an instance, the data type is normally determined by an ''xsi:type'' specification and some attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@mediaType''' || <center>CS</center> || <center>O</center> || MIME media type classification. At time of writing this specification, the following MIME types are allowed:
* text/plain (plain text)
* text/html (text with html markup)
* image/jpeg (JPEG image)
* application/pdf (a PDF, portable document format)
* application/hl7-sda+xml (CDA documents).
|-
| '''@representation''' || <center>CS</center> || <center>O</center> || Representation of the multimedia content. At time of writing this specification, the following representations are allowed:
* TXT (text, this is the default)
* B64 base 64 encoded data, for example for embedded CDA documents).
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<text xsi:type="ED" mediaType="text/plain">
Patient treated sucessfully
</text>

<text mediaType="application/hl7-sda+xml" representation="B64">PD94bWw..etc..==</text>

</syntaxhighlight>

To include referenced data the two sub elements ''thumbnail'' and ''reference'' are used.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''reference''' || <center>TEL</center> || <center>0..*</center> || <center>O</center> || Link (URI) to full data
|-
| '''thumbnail''' || <center>ED</center> || <center>0..*</center> || <center>O</center> || Thumbnail of referenced data
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value xsi:type="ED" mediaType="image/png" representation="B64">
<reference value="http://radiology.bergen.no/xrays/128s.png"/>
<thumbnail mediaType="image/jpeg" representation="B64"> MNY...83== </thumbnail>
</value>
</syntaxhighlight>

=== Strings (ST) ===

This data type is a specialization of the ED type where ''@mediaType'' is fixed “text/plain” and ''@representation'' is fixed “TXT”. It allows conveying a character string as '''element content'''. This data type is used in other data types it like the ''@extension'' in instance identifiers, or address and person name data type components.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<lotNumber> 143GT6DT </lotNumber>
</syntaxhighlight>

=== Concept Descriptor (CD) ===

This data type specifies a concept by means of a code and its code system (except for situations where no code is available).

A couple of specializations of data type CD exist, which differ in the main characteristics (properties) of the data type that may or may not be supported.

{| class="hl7table" style="width:50%"
|+<ref group="Table">Properties of data types used for codes</ref> ''Properties of data types used for codes''
! <div style="text-align: right">DataType</div> !! CD !! CE !! CV !! CO !! CS
|-
! <div style="text-align: left">Property</div> !! !! !! !! !!
|-
| '''@code''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||<center>X</center>
|-
| '''@codeSystem''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''@codeSystemVersion''' || <center>X</center> || <center>X</center> || <center>X</center>|| <center>X</center> ||
|-
| '''@displayName''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''originalText''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''translation''' || <center>X</center> || <center>X</center> || || ||
|-
| '''qualifier''' || <center>X</center> || || || ||
|}

Because the CE variant is most used in practice, the general explanation of the properties will be given with de description of CE (see below).

The only attribute that is unique to CD is briefly explained here.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@qualifier''' || <center>CR</center> || <center>O</center> || An additional qualifier for the code.
|}

Complex terminologies like SNOMED CT can be used only using data type CD.

=== Coded with Equivalents (CE) ===

With elements of this data type, a concept by means of a code and its coding system (except for situations where no code is available) can be specified. It optionally contains one or more equivalents using other code systems.

It may contain the following attributes:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@code''' || <center>ST</center> || <center>R</center> || The actual code
|-
| '''@codeSystem''' || <center>OID</center> || <center>R</center> || required to identify the code system were the code is drawn from. This is an OID (object identifier, see [[#Object_Identifiers_.28OIDs.29|Object Identifiers at 4.1]])
|-
| '''@displayName''' || <center>ST</center> || <center>O</center> || Optional textual representation of code. A display name may be specified representing the plain text of the code. The information of this attribute may not be used by the receiving system for interpretation, but only for display purposes. The display name may never be transmitted without a code and must have the same meaning as the code.
|-
| '''@codeSystemName''' || <center>ST</center> || <center>O</center> || A textual representation of the name of the code system
|-
| '''@codeSystemVersion''' || <center>ST</center> || <center>O</center> || A textual representation of the version of the code system
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"/>

<code code="AU" codeSystem="2.16.840.1.113883.5.33"/>

<storageCode code="AC" codeSystem="2.16.840.1.113883.5.34" displayName="active"/>

<code code="A45.0" displayName="Somatisierungsstörung" codeSystem="1.2.276.0.76.5.409" codeSystemName="ICD-10 GM 2012"/>
</syntaxhighlight>

There are some child elements of codes that can be used to express what the “original text” was that was used for the coding or to indicate that there are “translations” to other code systems than the primary code.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''originalText''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Textual representation of the concept, actually a description which was used to create the actual code
|}

No semantics may be assumed other than showing the ''@displayName'' to a user to clarify the code. A display name cannot occur without its code and must carry the same meaning.

In case no code is known, it is allowed to specify a ''@nullFlavor'' for the code element and to give information about the (not yet coded) concept in original text. However, this should be an exception.

If other codes than the primary code need to be conveyed adding a translation child element can be used.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<originalText>minor aphthous stomatitis</originalText>
</code>
</syntaxhighlight>

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''translation''' || <center>CD</center> || <center>0..*</center> || <center>O</center> || Alternative code(s)
|}

A ''translation'' element is also of type CD and shall have a code and a code system identified. It shall point to the same concept as the primary code. It is allowed that a translation conveys less conceptual details than the original code.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<translation code="528.2" codeSystem="2.16.840.1.113883.6.2" codeSystemName="ICD9" displayName="Oral aphthae"/>
</code>
</syntaxhighlight>

=== Coded Value (CV) ===

This is actually a specialization of CE (see above), with the exception that neither ''originalText'' nor ''translation'' child element are allowed.

=== Coded Simple Value (CS) ===

This is actually a specialization of CE (see above), with no code system attribute and no original text or translation child element allowed. It specifies a concept by means of a code from a ''predefined'' code system (table) where the code is drawn from. This data type is usually applied in the context of fixed predefined HL7 tables.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<statusCode code="completed"/>
</syntaxhighlight>

In this example ''statusCode'' is bound in the underlying model to the specific code system ''ActStatus''. Because it is predefined by means of the vocabulary binding, ''@codeSystem'' is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Telecommunication Address (TEL) ===

Elements of this type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>ST</center> || <center>R</center> || carries strings that represent telecommunication contact information
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

The actual data is preceded by the scheme (refer to Internet Standard “RFC 1738 Uniform Resource Locators (URL)” <ref>RFC 1738 Uniform Resource Locators (URL): http://www.ietf.org/rfc/rfc1738.txt</ref>.

Examples:
* telephone (tel:),
* fax (fax:),
* email (mailto:).

It must follow the rules defined in Internet “RFC 2806 URLs for Telephone Calls” <ref>RFC 2806 URLs for Telephone Calls: http://www.ietf.org/rfc/rfc2806.txt</ref>.

The following codes will be used in the “use” attribute:
* H – Home
* WP – Work
* MC can be used (in addition to H or WP) to denote that this is a mobile phone.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257" />

<telecom use="H" value="tel:55354257" />

<telecom use="H" value="fax:56542558" />

<telecom value="tel:+41.34.21.4765342"/>

<telecom value="mailto:opr@opr-sem.no"/>

<telecom use="WP MC" value="tel:97555786" />
</syntaxhighlight>

It is possible to express the useable period of a telecommunication contact. A child element ''useablePeriod'' is used as a time interval to indicate this period.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''useablePeriod''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257">
<useablePeriod>
<high value="20111201"/>
</useablePeriod>
</telecom>
</syntaxhighlight>

=== Postal Address (AD) ===

Elements of this data type have a substructure in order to represent a structured address specification. In this implementation guide only a selection of all possible child elements is allowed, the original HL7 specification is richer.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''streetAddressLine''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Street address, includes street name and house number
|-
| '''city''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || City
|-
| '''postalCode''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Postal code
|-
| '''country''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Country
|-
|}

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that the sequence of the sub elements is country specific, i.e. it has to follow “common” rules how to write an address. For example, an UK address and a German address have different sequences of address representation.
|}

A ''@use'' attribute can also be specified.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="WP">
<streetAddressLine>Anna-Louisa-Karsch-Str. 2</streetAddressLine>
<postalCode>10178</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="H WP">
<streetAddressLine>Tatungasse 34</streetAddressLine>
<postalCode>10825</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

Also, a country may be specified using the element ''country''.

=== Person Name (PN) ===

Elements of this data type do also have a substructure to represent the parts of a person name, like family or given name and prefixes.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>
<given>Franz</given>
<given>Ingrun</given>
<family>Nordmann</family>
</name>
</syntaxhighlight>

Previous or birth or maiden names are supported using the ''validTime'' element. ''validTime'' (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]]) specifies the validity range of the name.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">

<name>
<given>Jan</given>
<given>Olaf</given>
<family>Hendrikson</family>
<validTime>
<high value="20000101"/>
</validTime>
</name>
</syntaxhighlight>

Note that the name attribute is repeating, i.e. multiple (types of) names could be sent. It is up to the receiver (based on the value of the ''@use'' attribute, and ''validTime'') to decide what name it wants to use or import in its database.

=== Organisation Name (ON) ===

Elements of this data type represent a name of an organization.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name> Charité Berlin </name>
</syntaxhighlight>

The optional ''validTime'' element (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]] may be used to specify the validity range of the name of the organization.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name of the organization
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>The old hospital
<validTime>
<high value="20111231235959"/>
</validTime>
</name>
</syntaxhighlight>

Please note that the use of ''validTime'' yields XML mixed content which should be avoided if possible.

=== Integer Number (INT) ===

Elements of this data type are used to specify integer numbers and have one attribute.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>int</center> || <center>R</center> || Integer value
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<sequenceNumber value="24"/>
</syntaxhighlight>

=== Physical Quantities (PQ) ===

Elements of this data type are physical quantities, i.e. a measurable quantity (or countable) value from the physical world. This is different from just a “number”, because there is a (natural) unit specified in which the measurable quantity is expressed.
Examples:
* an amount of blood 20 ml (sample volume)
* a cut with a length of 10 cm (result observation)
* a dose of 200 milligrams per administration (dosing)
* delivery of 60 pieces of a tablet (amount supplied).
Elements of this data type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>real</center> || <center>R</center> || value of the measurement
|-
| '''@unit''' || <center>CS</center> || <center>R</center> || unit of measurement
|}

In the unit of measurement unit is expressed following the ''Unified Code for Units of Measure'' (UCUM) specification. This specification is a collection of atomic units, prefixes and a corresponding grammar for valid combinations to build all-natural units of measurement. For a complete description of possible units, see the ''Unified Code for Units of Measure'' <ref>Unified Code for Units of Measure: http://unitsofmeasure.org/</ref> specification.

If a value is not countable or if measurable, for example expressed in milligrams or liters, then this unit is a valid UCUM unit like “mg” or “L”. If a value is countable, for example the number of tablets, then this attribute contains “1”.

In HL7 it is required that all PQ data type units are valid UCUM units.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<value value="165" unit="cm"/>

<value value="81.1" unit="kg"/>

<value value="120" unit="mm[Hg]"/>

<value value="5" unit="1"/>
</syntaxhighlight>

=== Point in Time (TS) ===

Elements of this data type have the attribute

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>TS</center> || <center>R</center> || Point in time
|}

and specify points in time in the format YYYYMMDDhhmmss±ZZZZ, where
* YYYY is the four-digit year,
* MM the two-digit month,
* DD the two-digit day,
* hh the two-digit hour,
* mm the two-digits minute and
* ss the two-digit second.
Optional a time zone ZZZZ, the four-digit time alignment with a preceding “-” or a “+” can be specified. If time zone is omitted, local time is assumed.

The point in time may be right truncated in respect to the precision of the information.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<effectiveTime value="20140412"/>

<effectiveTime value="201409091245"/>

<effectiveTime value="1996"/>

<birthTime value="19540714"/>

<effectiveTime value="20140412+0100"/>
</syntaxhighlight>

=== Intervals (IVL) ===

Intervals are defined only for data types with an ordinal or interval scale type. There are several possibilities to determine an interval (see Figure 2), for example to specify

* a lower <low> and an upper boundary <high> (a),
* a lower <low> boundary and width <width> (b)
* an upper boundary and width <width> (c) or
* the middle of the interval <nowiki><center></nowiki> and a width <width> (d).

[[File:CDA_Core_Principles_Figure_2_Determining_Intervals.png|700px]]

<ref group="Figure">Several possibilities to determine closed intervals</ref> ''Several possibilities to determine closed intervals''

In addition, there is sometimes the need to specify incomplete intervals (open intervals). For example, an interval with only an upper limit to indicate a maximum dose or a start date and time only to express “since…”.

{{ConstraintBox|
To indicate an interval, only the following combinations are permitted.
(1) A lower and an upper boundary may not be identical, and their accuracy has to be equal.

Correct examples:

{{BeginGreenBox|}}
Interval from 5 to 6
Interval from 20110607 until 20110612
{{EndGreenBox}}

Incorrect examples:

{{BeginRedBox|}}
Interval from 5 to 6.0
Interval from 20110101 to 2011
{{EndRedBox|}}

(2) A lower boundary and a width

(3) A lower limit boundary

(4) A upper limit boundary

(5) Only the middle of the interval

(6) Only the width of an interval}}

Accordingly, four child elements are available.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Lower boundary
|-
| '''high''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Upper boundary
|-
| '''center''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Where ''(T)'' is defined in this specification as one of the data types “TS” or “PQ”.

=== Interval of time (IVL_TS) ===

Elements of this data type represent time intervals. There are four possible child elements.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Lower boundary (start date/time)
|-
| '''high''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Upper boundary (end date/time)
|-
| '''center''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Normally, a lower and an upper boundary is given, both are points in time. Also, it is possible to specify open intervals like “since June 14, 1999” (left boundary given only) or “until September 24, 2006” (right boundary given).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110507"/>
<high value="20110909"/>
</effectiveTime>

<effectiveTime>
<low value="20110507"/>
</effectiveTime>

<value>
<low value="20110101"/>
<width value="120" unit="d"/>
</value>

<value>
<center value="20110101"/>
</value>
</syntaxhighlight>

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|It must be noted that intervals of time stamps in HL7 are equally treated as other interval types (e.g. integers). The statement, one may take 1–3 tablets (interval of integers), for example, says that you are allowed to take no more than three tablets, not 3½ or 3.5 tablets. On the other hand, when treat the words “until 12 June 2011” regarding the upper interval limit differently, particularly we assume that the entire day 12 June is still included in this time interval.

Thus, in human perception time intervals are handled differently compared to such as number intervals. This is a situation may lead to inconsistencies in standardized communication. As a conclusion, an upper limit “12 June 2011” means that only the very first moment of the 12 June is included in the interval, but not, for example, the 12 June 13:00 hours.

Interpretation does not depend on the accuracy of the time:
* “after 2004” means “from January 1, 2005 00:00:00.000”,
* “after 20041201” means “from 2 December 2004 00:00:00.000 hours”,
* and “after 200412011200” means “from 1 December 2004 12:01:00.000”.

As a result, you have to carefully consider the specification and implemen-tation of time intervals upper boundaries. In order to prevent mis-understandings intervals are always specified with the date and time for an upper limit that would cover the whole day. Accordingly, “201106122359” means 12 June 2011 throughout the day.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="201106122359"/>
</effectiveTime>
</syntaxhighlight>

Because of the equal treatment of time intervals this is applied also to the lower limit boundaries of time intervals as “0000”. This means for example that “since 9 June 2011” is expressed as “201106090000”.
|}

The <width> element is of data type PQ (physical quantity). The value obviously shall relate to a period of time and it is required to include a “time” unit. These are the units “us” (microseconds), “ms” (milliseconds), “s” (seconds), “min” (minute), “h” (hours), “d” (day), “wk” (week), “mo” (month) and “a” (year).

{{ConstraintBox|
For interval of time stamps the @unit of a ''low'' or ''high'' child element shall use units
* us (microseconds),
* ms (milliseconds),
* s (seconds),
* min (minute),
* h (hours),
* d (day),
* wk (week),
* mo (month) or
* a (year).
}}

=== Interval of physical quantities (IVL_PQ) ===

Elements of this data type are used to indicate intervals of physical quantities (see also [[#Physical Quantities (PQ)|3.18 Physical Quantities (PQ)]]). In general, an upper and a lower boundary is specified. It is also possible to use ''center'' instead of ''low'' and ''high''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low || <center>TS</center> || <center>0..1</center> || <center>C</center> || the lower limit of the interval (i.e. the minimum amount).
|-
| '''high || <center>TS</center> || <center>0..1</center> || <center>C</center> || the upper limit of the interval (i.e. the maximum amount).
|-
| '''center || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of the interval
|}

The ''center'' child element is used when there is no interval, but an exact value. Alternative would be to demote IVL_PQ to data type PQ and populate the element’s ''@value'' attribute, but this is more difficult to process in XML. That is why the use of the ''center'' child element is deprecated.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<referenceRange>
<low value="7.5" unit="mmol/l"/>
<high value="10" unit="mmol/l"/>
</referenceRange>

<doseQuantity>
<center value="9" unit="1"/>
</doseQuantity>
</syntaxhighlight>

=== Ratio of quantities (RTO_QTY_QTY) ===

Elements of this data type specify ratios and have two child elements, a numerator and a denominator. The underlying QTY (Quantity) data type is an abstract data type and in a XML instance it has to be replaced by a specific data type using the ''@xsi:type'' instruction (see below).

In this specification only “PQ” or “INT” are allowed for the demotion of both ''numerator'' and ''denominator''. The relevant child elements are:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''numerator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the numerator of the ratio
|-
| '''denominator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the denominator of the ratio
|}

If a model attribute already is a RTO_QTY_QTY, you need to specify (demote) the OTY abstract data type for both ''numerator'' and ''denominator'' by using an ''@xsi:type'' instruction.
In some cases where the model attribute is of type “ANY”, also the root element shall carry an ''@xsi:type'' RTO_QTY_QTY instruction.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<maxDoseQuantity>
<numerator xsi:type="PQ" value="6"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="400" unit="mg"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="5"/>
<denominator xsi:type="PQ" value="1" unit="h"/>
</maxDoseQuantity>

<value xsi:type="RTO_QTY_QTY">
<numerator xsi:type="INT" value="1"/>
<denominator xsi:type="INT" value="10000"/>
</value>
</syntaxhighlight>

== Identification mechanisms ==

=== Object Identifiers (OIDs) ===

Standardized exchange of information using messages or documents also deals with unique identifications of objects and concepts, especially in environments where sender and receiver do not “know” each other necessarily.

It is important to understand the difference between identification of instances (ids) and code concepts (classifications). Within the context of HL7 interactions OIDs are quite often used.

An id points to a specific instance of an object or identification scheme (a particular methodology for the identification of a class of objects), for example a specific person as the patient or a physician, a specific lab observation or an X-ray photo.

In contrast to instance identifiers, a classification identifies a specific concept. The type of patient (inpatient, outpatient), the type of doctor (an anesthesiologist), the codes for gender or a lab observation (blood cell count) may serve as examples.

OIDs (object identifiers) are worldwide unique identifiers for objects. They are used in HL7 to specify identifications and classifications. An object in this sense is persistent, well-defined information, definitions or specifications and is represented with ids or codes.

Commonly used OIDs (i.e. used for a purpose that is wider in scope than the regional healthcare organization; used in communications between healthcare regions) can be found in OIDs registries such as

* [http://www.oid-info.com www.oid-info.com],
* [http://www.hl7.org www.hl7.org],
* [http://www.hl7.org.uk/version3group/oids.asp HL7 OID registry in the UK],
* [https://www.dimdi.de/dynamic/de/klassifikationen/weitere-klassifikationen-und-standards/oid/ OID registry Germany].

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|All OIDs with an element of 999 or 9999 are for documentation purposes only. They will be replaced by permanent OIDs once these have been assigned/found/applied for.
|}

OID (Object Identifiers) are unique identifiers for any kind of objects. They are defined in Rec. ITU-T X.660 | ISO/IEC 9834-1. This identification system for objects and concepts makes reliable electronic information exchange possible. Administration and Registration is regulated by a set of rules, described in the corresponding chapter of this document.

Every artefact in ART-DECOR has an Object Identifier (OID). There are recommendations for the management and the exchange of Object Identifiers, partially defined in ISO TS 13582 <ref>ISO TS 13582: https://www.iso.org/standard/69652.html</ref>.

''HL7 International'' has created a type ontology for the OIDs in the HL7 registry to make it easier for the user community to search for OIDs they may be looking for and can be found at hl7.org.

From a policy perspective it is common practice in several healthcare related OID registries (HL7 International at http://www.hl7.org, OID Registry Germany at http://www.dimdi.de, OID registry Switzerland at http://oid.refdata.ch, and OID registry Austria at https://www.gesundheit.gv.at/OID_Frontend) to distinguish at least between the following types of OIDs:

{| class="hl7table" style="width:50%"
|+<ref group="Table">Recommended OID sub-branches for different artefacts</ref> ''Recommended OID sub-branches for different artefacts''
! Arc !! Description
|-
| .3 || organizational bodies and groups
|-
| .4 || identifier systems and namespaces
|-
| .5 || code systems
|-
| .7 || document artefacts
|-
| .9 || conformance profiles
|-
| .10 || templates
|-
| .11 || value sets
|-
| .19 || examples
|-
| .99 || experimental
|}

''Example: given that “your” root OID is 1.2.3.4.5, the first value set of your governance group is then to be 1.2.3.4.5.11.1, with .11 as the value set “branch” and the last .1 as the first artefact of that kind.''

In ART-DECOR a project typically is set into the .77 branch of a governance group. When setting up the project, the OID for that project also determines the artefact OIDs using throughout the ART-DECOR project. The following additional branches are used to distinguish between different OID types:

{| class="hl7table" style="width:50%"
|+<ref group="Table">Recommended OID sub-branches for ART-DECOR projects</ref> ''Recommended OID sub-branches for ART-DECOR projects''
! Artefact code !! Description !! Recommended OID suffix
|-
| DS || dataset || .77.1
|-
| DE || dataset concept || .77.2
|-
| SC || scenario || .77.3
|-
| TR || transaction in scenario || .77.4
|-
| CS || code system || .77.5
|-
| IS || issue || .77.6
|-
| AC || actor in scenario || .77.7
|-
| CL || concept list in dataset || .77.8
|-
| EL || element in template || .77.9
|-
| TM || template || .77.10
|-
| VS || value set || .77.11
|-
| RL || rule for instances || .77.12
|-
| SX || test/example scenario || .77.18
|-
| EX || test/example instance || .77.19
|-
| QX || qualification test/example || .77.20
|-
| TX || test/example data element || .77.21
|-
| CM || community || .77.22
|-
| MP || concept map || .77.24
|}

In ART-DECOR a newly created project uses these OID branches automatically.

=== Instance identification ===

Instance identification is done with the id element of a class. Its type is II (instance identifier) and described in the data type section above. For example, a patient number can be represented as
* 2.16.578.1.34.1.5432.1, the root-OID of the issuing authority, for example a system/application in a hospital, and
* 67543242 as the ''@extension'', representing the patient number within the system defined by the ''@root'' attribute.

=== Coding scheme identification ===

Coding schemes have to be uniquely identified using OIDs as well. All coding tables used in this implementation guide show the corresponding OID that has to be specified in the ''@codeSystem'' attribute of coded elements. Both attributes ''@code'' and ''@codeSystem'' together allows a correct interpretation of concept and code.

=== List of identification schemes ===

The following are OIDs for commonly used identification schemes.

{| class="hl7table"
|+<ref group="Table">Commonly used identification scheme OIDs</ref> ''Commonly used identification scheme OIDs''
! OID !! Identification System Name !! Description !! Issuer
|-
| 1.2.276.0.76.4.8 || KV-Nummer || Krankenversichertennummer ||
|-
| 1.2.276.0.76.4.17 || BSNR || Betriebsstättennummer ||
|-
| 1.2.276.0.76.4.16 || LANR || lebenslange Arztnummer ||
|}

=== List of code systems ===

The following are OIDs for code systems.

{| class="hl7table"
|+<ref group="Table">Commonly used code system OIDs</ref> ''Commonly used code system OIDs''
! OID !! Code System Name !! Description !! Issuer
|-
| 2.16.840.1.113883.6.1 || LOINC || Logical Observation Identifiers Names and Codes (LOINC) || Regenstrief Institute
|-
| 2.16.840.1.113883.6.96 || SNOMED CT || Systemized Nomenclature in Medicine Reference Terminology (SNOMED CT) || SNOMED International
|-
| 1.0.3166.1.2 || ISO 3166-1 (second edition) || Country codes as per ISO 3166-1:2007 || ISO
|}

== Vocabulary ==

=== Code Systems ===

Within HL7, a ''Code System'' is defined as a collection of codes with associated designations and meanings. Examples of code systems include ICD-10, SNOMED CT, and LOINC.

To meet the requirements of a code system as defined by HL7, a given code must resolve to one and only one meaning within the code system. Given this definition, each code table in the HL7 Version 3 standard represents a different code system since codes are sometimes used in different tables to have different meanings.

For example, “M” in the administrative gender table (''AdministrativeGender'', OID 2.16.840.1.113883.5.1) means “male”, while “M” in the marital status table (''MaritalStatus'', OID 2.16.840.1.113883.5.2) means “married”.

In this specification, code system tables are not presented in detail.

=== Value Sets ===

A ''Value Set'' represents a uniquely identifiable set of valid concept representations, where any concept representation can be tested to determine whether or not it is a member of the value set.

Value set complexity may range from a simple flat list of concept codes drawn from a single code system, to an unbounded hierarchical set of possibly post-coordinated expressions drawn from multiple code systems.

Value sets exist to constrain the content for a coded element in an HL7 static model or data type property. Value sets cannot have null content and must contain at least one concept representation where any given concept is generally (but not required to be) represented by only a single code within the Value Set.

[[File:CDA_Core_Principles_Figure_3_ValueSet_Example.png|800px]]

<ref group="Figure">Example presentation of the value set “MaritalStatus”</ref> ''Example presentation of the value set “MaritalStatus”''

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that value set OIDs never appear in a CDA Release 2 document. They are used for constraint expressions, for example in implementation guides.

In order to send a specific code drawn from a value set, the corresponding code system has to be conveyed.

An example, in the implementation specification the constraint on the model element ''maritalStatusCode'' is expressed as “to be drawn from value set 2.16.840.1.113883.5.2 ''MaritalStatus''”.

To actually send a marital status of “M” (married) that is shown in the value set figure above, the corresponding HL7 CDA instance would say:

<syntaxhighlight lang="xml">
<maritalStatusCode code="M" codeSystem="2.16.840.1.113883.5.2"/>
</syntaxhighlight>
|}

In this specification, value set tables are not presented in detail.

==== Binding strength ====

There is an optional vocabulary strength for data types that support that feature (coded concepts). Examples include CD, CE, CV and CO. Values are required, extensible, preferred and example. Default is required.

Please note: the formerly supported values CNE (Coded No Extensibility) and CWE (Coded With Extensibility) in ART-DECOR are deprecated as of December 2017. Specification CNE is handled as required and CWE is handled as extensible.

{| class="hl7table" style="width:50%"
|+<ref group="Table">Binding Strengths</ref> ''Binding Strengths''
! Strength !! Description
|-
|required||Required/CNE. Coded with no exceptions; this element SHALL be from the specified value set
|-
|extensible||Extensible/CWE. Coded with Exceptions; this element SHALL be from the specified value set if any of the codes within the value set can apply to the concept being communicated. If the value set does not cover the concept (based on human review), alternate codings (or, data type allowing, text) may be included instead.
|-
|preferred||Preferred. Instances are encouraged to draw from the specified codes for interoperability purposes but are not required to do so to be considered conformant.
|-
|example||Example. Instances are not expected or even encouraged to draw from the specified value set. The value set merely provides examples of the types of concepts intended to be included.
|}

Mismatches with required lead to validation errors (SHALL logic). Mismatches with extensible lead to validation warnings (SHOULD logic). Mismatches with preferred lead to validation information messages (MAY logic). Mismatches with example don't have any validation consequences.

== Appendix ==

=== References ===

<references/>

=== List of figures ===

<references group="Figure" />

=== List of tables ===

<references group="Table" />

HL7 CDA Core Principles

2019-06-16T11:47:20Z

Dammon: /* Common aspects */

== Introduction ==

This implementation guide specifies the ''Core Principles'' of using the ''Clinical Document Architecture'' <ref>Clinical Document Architecture Release 2: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=7</ref>.

=== Scope ===

This guide focuses on ''Data Types Release 1'' <ref>HL7 Data Types Release 1: http://www.hl7.org</ref>. Meanwhile an ISO specification ISO 21090 is out, also known as Data Type Release 2. The latter is subject to another implementation guide that will be published when ISO data types are used.

=== Focus of this document: HL7 Version 3 Data Types for CDA ===

The following chapters of this document will focus on the description of the data types and associated material. It will highlight the essentials in four chapters, all focusing on the Norwegian situation.
* '''Common aspects:''' explains common aspects of use of CDA and XML
* '''Data types:''' gives an overview and detailed specification of all data types used in CDA
* '''Identification schemes:''' explains major aspects of identification and the use in CDA
* '''Use of vocabulary:''' explains major aspects of vocabulary use in CDA.

=== Background ===

In many (European) countries, implementation guides for the use of data types in HL7 V3 are published. They take into account country specific constraints on the data types.

=== Legend of symbols ===

In this document several symbols are used.

{| class="hl7table" style="width:50%"
| [[File:Pfeil_rechts.png|50px]] || This is an important item
|-
| [[File:Issue.svg|50px]] || This is a known open issue
|-
| [[File:Faq.svg|50px]] || This is a frequently asked question (FAQ) with answer
|-
| [[File:Conformance.svg|50px]] || This is a constraint; in some situations also the rule identification is specified, e.g. dtr1-1-ANY, which links to the corresponding validation rule.
|}

=== Version history ===

{| class="hl7table" style="width:50%"
|+
! Version !! Date !! Description !! Author
|-
| 1.1 || 2019-04-24 || Refurbished guide based on earlier work || Kai U. Heitmann
|}

== Common aspects ==

=== Use of XML ===

HL7 Version 3 CDA uses the Extensible Markup Language (XML) as the exchange format. It is assumed that the reader is familiar with common XML aspects <ref>World Wide Web Consortium. Extensible Markup Language, 1.0, 2nd Edition: http://www.w3.org/TR/REC-xml</ref><ref>World Wide Web Consortium. XML Schema: http://www.w3.org/TR/xmlschema-0/ http://www.w3.org/TR/xmlschema-1/ http://www.w3.org/TR/xmlschema-2/</ref>. However, some constraints are made regarding the use of CDA.

==== Character Set ====

{{ConstraintBox|
The character encoding of any CDA document shall be “UTF-8”.}}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="utf-8"?>
</syntaxhighlight>

=== CDA document structure ===

The XML namespace for CDA Release 2 documents is ''<nowiki>urn:hl7-org:v3</nowiki>''. This must be correctly mentioned in every XML instance.

CDA XML documents starts with the root element ''ClinicalDocument''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">


...

<component>
<structuredBody>
...
</structuredBody>
</component>

</ClinicalDocument>
</syntaxhighlight>

== Data types ==

=== Introduction ===

The following chapter describes the typical data types used in CDA implementation guides. For further information please refer to the HL7 V3 standard and its two parts concerning data types:
* Abstract Data type definition <ref>HL7 Version 3 Abstract Data type definition: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=264</ref>
* XML ITS for data types <ref>XML ITS for data types: https://www.hl7.org/documentcenter/public_temp_682D4D16-1C23-BA17-0C789BA52BEDB68E/wg/inm/datatypes-its-xml20050714.htm</ref>
Data types are properties of model class attributes and the basic building blocks of information in a CDA XML instance. For example, a model attribute named “time” has as its data type a time stamp “TS” (see Figure 1).

[[File:CDA_Core_Principles_Figure_1_CDA_Structure_Data_Types.png|700px]]

<ref group="Figure">CDA structure (left) and the data type specification (right)</ref> ''CDA structure (left) and the data type specification (right)''

=== XML representation of data types ===

Actual data is mostly carried in HL7 Version 3 by populating XML attributes and not as element content. Exceptions are names of persons and organizations as well as addresses.

The XML elements have names like the model attributes. For example, a model attribute “id” has a corresponding XML element named <id…>. The model determines the sequence of elements and their hierarchy. The data type itself determines the XML attributes within the start tag. The notation here is as follows:

{| class="hl7table"
|+
! Attribute !! DT !! Conf !! Description
|-
| (name of the model attribute or XML element) || Data type || Conformance, i.e. O, R, M || Textual description
|}

XML attributes (data type properties) are denoted as ''@attribute'' in order to distinguish their names from XML elements.

Example: in the example model above, the data type of the ''id'' attribute's is ''II'' (Instance Identifier). The corresponding XML attributes for that data type include ''@root'' and ''@extension''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id root="..." extension="..." />
</syntaxhighlight>

A description of the data types and their corresponding XML representation is contained in subsequent paragraphs of this guide.

==== Exceptions using XML element content ====

For most data types, the actual data is conveyed in XML attributes. However, there are some exceptions. For the data types binary (BIN), Encapsulated Data (ED), Entity Name (EN), Person Name (PN), Organization Name (ON), Trivial Name (TN), Address (AD) and character string data (ST), information is carried as element content.

Example: the components of an address <addr> are represented by sub elements with the data as element content (in the example shown in black).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr>
<streetAddressLine>Thormøhlens gate 12</streetAddressLine>
<postalCode>5006</postalCode>
<city>Bergen</city>
</addr>
</syntaxhighlight>

==== Combined data types ====

There are a number of so-called combined data types. For example, an interval with a lower and upper limit and a ratio that has a nominator and a denominator value.

In combined data types the substructure (e.g. <low> <high> in an interval) are represented as child elements of the relevant data type element.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110701"/>
<high value="20110729"/>
</effectiveTime>
</syntaxhighlight>

==== Conformance information ====

The conformance indicators distinguish kinds of conformance information described shortly here.

* '''O''': An optional item may be omitted if no data is present, i.e. no corresponding XML attribute or element is sent (marked as “O”)
* '''R''': For required items, lower cardinality is always zero or 1.
** Elements must be present and populated with data if present in the sending system. If no data is available (yet), a null flavor (see below) indicates and possibly classifies the missing information (marked as R).
** Attribute flagged as required must be present in the instance and populated.
* '''M''': For mandatory elements data must be sent and no missing values are allowed, i.e. if the sending system does not have information for mandatory elements the XML instance cannot be created and sent (marked as M).
* '''NP''': no data may be present at all (not permitted)
* '''C''': conditional conformance; typically a conformance table shows the circumstances (conditions) derived from information in the instance and the corresponding cardinalities and conformance statements.

=== Missing values (null flavor) ===

For every data type it is possible to specify a missing value including a kind of reason why data is missing. Instead of specifying any attribute of the corresponding element, a ''@nullFlavor'' attribute expresses the omission of data. Note that missing data is not allowed for mandatory elements (see above).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value nullFlavor="OTH"/>

<code nullFlavor="UNK"/>

<booleanInd nullFlavor="NI"/>

</syntaxhighlight>

The codes for the ''@nullFlavor'' attribute are drawn from the following hierarchical code system. It is a Coded Simple (CS), which means it has no code system (attribute ''@codeSystem'') specified.

{| class="hl7table"
|+<ref group="Table">NullFlavor</ref> ''NullFlavor''
! Code
! width=15% | Print Name
! Definition / Description
|-
| NI || No Information || No information whatsoever can be inferred from this exceptional value. This is the most general exceptional value. It is also the default exceptional value.
|-
|   OTH || other || The actual value is not an element in the value domain of a variable. (e.g., concept not provided by required code system).
|-
|     NINF || negative infinity || Negative infinity of numbers.
|-
|     PINF || positive infinity || Positive infinity of numbers.
|-
|   UNK || unknown || A proper value is applicable, but not known.
|-
|     ASKU || asked but unknown || Information was sought but not found (e.g., patient was asked but didn't know)
|-
|       NAV || temporarily unavailable || Information is not available at this time but it is expected that it will be available later.
|-
|       NASK || not asked || This information has not been sought (e.g., patient was not asked)
|-
|       TRC || trace || The content is greater than zero, but too small to be quantified.
|-
|   MSK || masked || There is information on this item available but it has not been provided by the sender due to security, privacy or other reasons. There may be an alternate mechanism for gaining access to this information.
Note: using this null flavour does provide information that may be a breach of confidentiality, even though no detail data is provided. Its primary purpose is for those circumstances where it is necessary to inform the receiver that the information does exist without providing any detail.
|-
|   NA || not applicable || No proper value is applicable in this context (e.g., last menstrual period for a male).
|-
| NP || not present || Value is not present in a message. This is only defined in messages, never in application data! All values not present in the message must be replaced by the applicable default, or no-information (NI) as the default of all defaults.
|}

=== ANY as the generic data type ===

This abstract data type is the basis for all other data types. Not a single value within a CDA document has the effective data type ANY, but any data type within HL7v3 is a specialization of ANY. This also means that any other data type inherits all properties of ANY (see [[#Missing_values_.28null_flavor.29|“Missing values (null flavor)”]]).

The ANY type is occasionally found in HL7 models when it comes to clinical finding etc. where – at model time – the actual data type of the value is not known. At instantiation time however, the actual data type ''is'' known and ANY is always replaced by a particular data type in an instance.

One example is the observation value (child element value in an observation), where in the model the data type of value cannot be anticipated. When instantiation is taking place, the data type is specified by the XML instance attribute ''@xsi:type''. This information can be used by the receiver to validate and process the value.

Attributes of an element with this data type are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@nullFlavor''' || <center>CS</center> || <center>–</center> || Classification of the missing value, see [[#Missing_values_.28null_flavor.29|3.3 Missing values (null flavor)]].
|}

{| class="hl7table" style="width:100%"
| width=8% | <center>[[File:Conformance.svg|50px]] dtr1-1-ANY</center> || If there is a ''nullFlavor'', there shall be no other attribute or element, unless it's ''nullFlavor="OTH"''.

In that case ''@codeSystem'' or ''originalText'' (see “code” data types) may have a value.
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">

<value xsi:type="CE" code="N11.9" codeSystem="2.16.840.1.113883.6.3"/>


<value xsi:type="PQ" value="12" unit="mL"/>


<value xsi:type="ED">this is text</value>
</syntaxhighlight>

=== Boolean (BL) ===

Elements of this data type refer to Boolean logic and have an attribute ''@value''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>BL</center> || <center>–</center> || Valued as “true” or “false”
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<negationInd value="false"/>

<deceasedInd value="true"/>

</syntaxhighlight>

In some situations, the BL data does not apply to an XML element, but an attribute. In that case, the attribute carries the Boolean value directly.
<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<support contextConductionInd ="false">
...
</support>
</syntaxhighlight>

=== Instance Identifier (II) ===

This data type identifies instances of classes like observations or entities (persons, organizations). Attributes are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@extension''' || <center>ST</center> || <center>O</center> || Identification
|-
| '''@root''' || <center>OID</center> || <center>R</center> || Source of identification
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id extension="13234453645" root="2.16.840.1.113883.2.6.15.3.427.1"/>
</syntaxhighlight>

The ''@root'' attribute is of type OID (object identifier), a unique identifier of the issuing authority or system. For example, a patient with a patient number 13234453645 created by a specific healthcare provider organization is uniquely identified by the number itself in ''@extension'' and the OID of the organization or the sending system, in the example 2.16.840.1.113883.2.6.15.3.427.1 in ''@root''.

In some cases, a single OID identifies an object uniquely. In that situation, only ''@root'' is populated and ''@extension'' is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Encapsulated Data (ED) ===

Elements of this data type carry multimedia content. The actual multimedia content is represented as element content. There are two situations for the use of ED:

* Inline: The full data is transmitted in the type. This form is mainly used for text.
* By reference: a thumbnail is provided which links to the full data by reference.

In an instance, the data type is normally determined by an ''xsi:type'' specification and some attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@mediaType''' || <center>CS</center> || <center>O</center> || MIME media type classification. At time of writing this specification, the following MIME types are allowed:
* text/plain (plain text)
* text/html (text with html markup)
* image/jpeg (JPEG image)
* application/pdf (a PDF, portable document format)
* application/hl7-sda+xml (CDA documents).
|-
| '''@representation''' || <center>CS</center> || <center>O</center> || Representation of the multimedia content. At time of writing this specification, the following representations are allowed:
* TXT (text, this is the default)
* B64 base 64 encoded data, for example for embedded CDA documents).
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<text xsi:type="ED" mediaType="text/plain">
Patient treated sucessfully
</text>

<text mediaType="application/hl7-sda+xml" representation="B64">PD94bWw..etc..==</text>

</syntaxhighlight>

To include referenced data the two sub elements ''thumbnail'' and ''reference'' are used.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''reference''' || <center>TEL</center> || <center>0..*</center> || <center>O</center> || Link (URI) to full data
|-
| '''thumbnail''' || <center>ED</center> || <center>0..*</center> || <center>O</center> || Thumbnail of referenced data
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value xsi:type="ED" mediaType="image/png" representation="B64">
<reference value="http://radiology.bergen.no/xrays/128s.png"/>
<thumbnail mediaType="image/jpeg" representation="B64"> MNY...83== </thumbnail>
</value>
</syntaxhighlight>

=== Strings (ST) ===

This data type is a specialization of the ED type where ''@mediaType'' is fixed “text/plain” and ''@representation'' is fixed “TXT”. It allows conveying a character string as '''element content'''. This data type is used in other data types it like the ''@extension'' in instance identifiers, or address and person name data type components.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<lotNumber> 143GT6DT </lotNumber>
</syntaxhighlight>

=== Concept Descriptor (CD) ===

This data type specifies a concept by means of a code and its code system (except for situations where no code is available).

A couple of specializations of data type CD exist, which differ in the main characteristics (properties) of the data type that may or may not be supported.

{| class="hl7table" style="width:50%"
|+<ref group="Table">Properties of data types used for codes</ref> ''Properties of data types used for codes''
! <div style="text-align: right">DataType</div> !! CD !! CE !! CV !! CO !! CS
|-
! <div style="text-align: left">Property</div> !! !! !! !! !!
|-
| '''@code''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||<center>X</center>
|-
| '''@codeSystem''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''@codeSystemVersion''' || <center>X</center> || <center>X</center> || <center>X</center>|| <center>X</center> ||
|-
| '''@displayName''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''originalText''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''translation''' || <center>X</center> || <center>X</center> || || ||
|-
| '''qualifier''' || <center>X</center> || || || ||
|}

Because the CE variant is most used in practice, the general explanation of the properties will be given with de description of CE (see below).

The only attribute that is unique to CD is briefly explained here.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@qualifier''' || <center>CR</center> || <center>O</center> || An additional qualifier for the code.
|}

Complex terminologies like SNOMED CT can be used only using data type CD.

=== Coded with Equivalents (CE) ===

With elements of this data type, a concept by means of a code and its coding system (except for situations where no code is available) can be specified. It optionally contains one or more equivalents using other code systems.

It may contain the following attributes:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@code''' || <center>ST</center> || <center>R</center> || The actual code
|-
| '''@codeSystem''' || <center>OID</center> || <center>R</center> || required to identify the code system were the code is drawn from. This is an OID (object identifier, see [[#Object_Identifiers_.28OIDs.29|Object Identifiers at 4.1]])
|-
| '''@displayName''' || <center>ST</center> || <center>O</center> || Optional textual representation of code. A display name may be specified representing the plain text of the code. The information of this attribute may not be used by the receiving system for interpretation, but only for display purposes. The display name may never be transmitted without a code and must have the same meaning as the code.
|-
| '''@codeSystemName''' || <center>ST</center> || <center>O</center> || A textual representation of the name of the code system
|-
| '''@codeSystemVersion''' || <center>ST</center> || <center>O</center> || A textual representation of the version of the code system
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"/>

<code code="AU" codeSystem="2.16.840.1.113883.5.33"/>

<storageCode code="AC" codeSystem="2.16.840.1.113883.5.34" displayName="active"/>

<code code="A45.0" displayName="Somatisierungsstörung" codeSystem="1.2.276.0.76.5.409" codeSystemName="ICD-10 GM 2012"/>
</syntaxhighlight>

There are some child elements of codes that can be used to express what the “original text” was that was used for the coding or to indicate that there are “translations” to other code systems than the primary code.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''originalText''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Textual representation of the concept, actually a description which was used to create the actual code
|}

No semantics may be assumed other than showing the ''@displayName'' to a user to clarify the code. A display name cannot occur without its code and must carry the same meaning.

In case no code is known, it is allowed to specify a ''@nullFlavor'' for the code element and to give information about the (not yet coded) concept in original text. However, this should be an exception.

If other codes than the primary code need to be conveyed adding a translation child element can be used.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<originalText>minor aphthous stomatitis</originalText>
</code>
</syntaxhighlight>

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''translation''' || <center>CD</center> || <center>0..*</center> || <center>O</center> || Alternative code(s)
|}

A ''translation'' element is also of type CD and shall have a code and a code system identified. It shall point to the same concept as the primary code. It is allowed that a translation conveys less conceptual details than the original code.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<translation code="528.2" codeSystem="2.16.840.1.113883.6.2" codeSystemName="ICD9" displayName="Oral aphthae"/>
</code>
</syntaxhighlight>

=== Coded Value (CV) ===

This is actually a specialization of CE (see above), with the exception that neither ''originalText'' nor ''translation'' child element are allowed.

=== Coded Simple Value (CS) ===

This is actually a specialization of CE (see above), with no code system attribute and no original text or translation child element allowed. It specifies a concept by means of a code from a ''predefined'' code system (table) where the code is drawn from. This data type is usually applied in the context of fixed predefined HL7 tables.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<statusCode code="completed"/>
</syntaxhighlight>

In this example ''statusCode'' is bound in the underlying model to the specific code system ''ActStatus''. Because it is predefined by means of the vocabulary binding, ''@codeSystem'' is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Telecommunication Address (TEL) ===

Elements of this type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>ST</center> || <center>R</center> || carries strings that represent telecommunication contact information
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

The actual data is preceded by the scheme (refer to Internet Standard “RFC 1738 Uniform Resource Locators (URL)” <ref>RFC 1738 Uniform Resource Locators (URL): http://www.ietf.org/rfc/rfc1738.txt</ref>.

Examples:
* telephone (tel:),
* fax (fax:),
* email (mailto:).

It must follow the rules defined in Internet “RFC 2806 URLs for Telephone Calls” <ref>RFC 2806 URLs for Telephone Calls: http://www.ietf.org/rfc/rfc2806.txt</ref>.

The following codes will be used in the “use” attribute:
* H – Home
* WP – Work
* MC can be used (in addition to H or WP) to denote that this is a mobile phone.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257" />

<telecom use="H" value="tel:55354257" />

<telecom use="H" value="fax:56542558" />

<telecom value="tel:+41.34.21.4765342"/>

<telecom value="mailto:opr@opr-sem.no"/>

<telecom use="WP MC" value="tel:97555786" />
</syntaxhighlight>

It is possible to express the useable period of a telecommunication contact. A child element ''useablePeriod'' is used as a time interval to indicate this period.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''useablePeriod''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257">
<useablePeriod>
<high value="20111201"/>
</useablePeriod>
</telecom>
</syntaxhighlight>

=== Postal Address (AD) ===

Elements of this data type have a substructure in order to represent a structured address specification. In this implementation guide only a selection of all possible child elements is allowed, the original HL7 specification is richer.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''streetAddressLine''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Street address, includes street name and house number
|-
| '''city''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || City
|-
| '''postalCode''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Postal code
|-
| '''country''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Country
|-
|}

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that the sequence of the sub elements is country specific, i.e. it has to follow “common” rules how to write an address. For example, an UK address and a German address have different sequences of address representation.
|}

A ''@use'' attribute can also be specified.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="WP">
<streetAddressLine>Anna-Louisa-Karsch-Str. 2</streetAddressLine>
<postalCode>10178</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="H WP">
<streetAddressLine>Tatungasse 34</streetAddressLine>
<postalCode>10825</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

Also, a country may be specified using the element ''country''.

=== Person Name (PN) ===

Elements of this data type do also have a substructure to represent the parts of a person name, like family or given name and prefixes.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>
<given>Franz</given>
<given>Ingrun</given>
<family>Nordmann</family>
</name>
</syntaxhighlight>

Previous or birth or maiden names are supported using the ''validTime'' element. ''validTime'' (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]]) specifies the validity range of the name.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">

<name>
<given>Jan</given>
<given>Olaf</given>
<family>Hendrikson</family>
<validTime>
<high value="20000101"/>
</validTime>
</name>
</syntaxhighlight>

Note that the name attribute is repeating, i.e. multiple (types of) names could be sent. It is up to the receiver (based on the value of the ''@use'' attribute, and ''validTime'') to decide what name it wants to use or import in its database.

=== Organisation Name (ON) ===

Elements of this data type represent a name of an organization.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name> Charité Berlin </name>
</syntaxhighlight>

The optional ''validTime'' element (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]] may be used to specify the validity range of the name of the organization.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name of the organization
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>The old hospital
<validTime>
<high value="20111231235959"/>
</validTime>
</name>
</syntaxhighlight>

Please note that the use of ''validTime'' yields XML mixed content which should be avoided if possible.

=== Integer Number (INT) ===

Elements of this data type are used to specify integer numbers and have one attribute.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>int</center> || <center>R</center> || Integer value
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<sequenceNumber value="24"/>
</syntaxhighlight>

=== Physical Quantities (PQ) ===

Elements of this data type are physical quantities, i.e. a measurable quantity (or countable) value from the physical world. This is different from just a “number”, because there is a (natural) unit specified in which the measurable quantity is expressed.
Examples:
* an amount of blood 20 ml (sample volume)
* a cut with a length of 10 cm (result observation)
* a dose of 200 milligrams per administration (dosing)
* delivery of 60 pieces of a tablet (amount supplied).
Elements of this data type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>real</center> || <center>R</center> || value of the measurement
|-
| '''@unit''' || <center>CS</center> || <center>R</center> || unit of measurement
|}

In the unit of measurement unit is expressed following the ''Unified Code for Units of Measure'' (UCUM) specification. This specification is a collection of atomic units, prefixes and a corresponding grammar for valid combinations to build all-natural units of measurement. For a complete description of possible units, see the ''Unified Code for Units of Measure'' <ref>Unified Code for Units of Measure: http://unitsofmeasure.org/</ref> specification.

If a value is not countable or if measurable, for example expressed in milligrams or liters, then this unit is a valid UCUM unit like “mg” or “L”. If a value is countable, for example the number of tablets, then this attribute contains “1”.

In HL7 it is required that all PQ data type units are valid UCUM units.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<value value="165" unit="cm"/>

<value value="81.1" unit="kg"/>

<value value="120" unit="mm[Hg]"/>

<value value="5" unit="1"/>
</syntaxhighlight>

=== Point in Time (TS) ===

Elements of this data type have the attribute

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>TS</center> || <center>R</center> || Point in time
|}

and specify points in time in the format YYYYMMDDhhmmss±ZZZZ, where
* YYYY is the four-digit year,
* MM the two-digit month,
* DD the two-digit day,
* hh the two-digit hour,
* mm the two-digits minute and
* ss the two-digit second.
Optional a time zone ZZZZ, the four-digit time alignment with a preceding “-” or a “+” can be specified. If time zone is omitted, local time is assumed.

The point in time may be right truncated in respect to the precision of the information.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<effectiveTime value="20140412"/>

<effectiveTime value="201409091245"/>

<effectiveTime value="1996"/>

<birthTime value="19540714"/>

<effectiveTime value="20140412+0100"/>
</syntaxhighlight>

=== Intervals (IVL) ===

Intervals are defined only for data types with an ordinal or interval scale type. There are several possibilities to determine an interval (see Figure 2), for example to specify

* a lower <low> and an upper boundary <high> (a),
* a lower <low> boundary and width <width> (b)
* an upper boundary and width <width> (c) or
* the middle of the interval <nowiki><center></nowiki> and a width <width> (d).

[[File:CDA_Core_Principles_Figure_2_Determining_Intervals.png|700px]]

<ref group="Figure">Several possibilities to determine closed intervals</ref> ''Several possibilities to determine closed intervals''

In addition, there is sometimes the need to specify incomplete intervals (open intervals). For example, an interval with only an upper limit to indicate a maximum dose or a start date and time only to express “since…”.

{{ConstraintBox|
To indicate an interval, only the following combinations are permitted.
(1) A lower and an upper boundary may not be identical, and their accuracy has to be equal.

Correct examples:

{{BeginGreenBox|}}
Interval from 5 to 6
Interval from 20110607 until 20110612
{{EndGreenBox}}

Incorrect examples:

{{BeginRedBox|}}
Interval from 5 to 6.0
Interval from 20110101 to 2011
{{EndRedBox|}}

(2) A lower boundary and a width

(3) A lower limit boundary

(4) A upper limit boundary

(5) Only the middle of the interval

(6) Only the width of an interval}}

Accordingly, four child elements are available.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Lower boundary
|-
| '''high''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Upper boundary
|-
| '''center''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Where ''(T)'' is defined in this specification as one of the data types “TS” or “PQ”.

=== Interval of time (IVL_TS) ===

Elements of this data type represent time intervals. There are four possible child elements.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Lower boundary (start date/time)
|-
| '''high''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Upper boundary (end date/time)
|-
| '''center''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Normally, a lower and an upper boundary is given, both are points in time. Also, it is possible to specify open intervals like “since June 14, 1999” (left boundary given only) or “until September 24, 2006” (right boundary given).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110507"/>
<high value="20110909"/>
</effectiveTime>

<effectiveTime>
<low value="20110507"/>
</effectiveTime>

<value>
<low value="20110101"/>
<width value="120" unit="d"/>
</value>

<value>
<center value="20110101"/>
</value>
</syntaxhighlight>

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|It must be noted that intervals of time stamps in HL7 are equally treated as other interval types (e.g. integers). The statement, one may take 1–3 tablets (interval of integers), for example, says that you are allowed to take no more than three tablets, not 3½ or 3.5 tablets. On the other hand, when treat the words “until 12 June 2011” regarding the upper interval limit differently, particularly we assume that the entire day 12 June is still included in this time interval.

Thus, in human perception time intervals are handled differently compared to such as number intervals. This is a situation may lead to inconsistencies in standardized communication. As a conclusion, an upper limit “12 June 2011” means that only the very first moment of the 12 June is included in the interval, but not, for example, the 12 June 13:00 hours.

Interpretation does not depend on the accuracy of the time:
* “after 2004” means “from January 1, 2005 00:00:00.000”,
* “after 20041201” means “from 2 December 2004 00:00:00.000 hours”,
* and “after 200412011200” means “from 1 December 2004 12:01:00.000”.

As a result, you have to carefully consider the specification and implemen-tation of time intervals upper boundaries. In order to prevent mis-understandings intervals are always specified with the date and time for an upper limit that would cover the whole day. Accordingly, “201106122359” means 12 June 2011 throughout the day.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="201106122359"/>
</effectiveTime>
</syntaxhighlight>

Because of the equal treatment of time intervals this is applied also to the lower limit boundaries of time intervals as “0000”. This means for example that “since 9 June 2011” is expressed as “201106090000”.
|}

The <width> element is of data type PQ (physical quantity). The value obviously shall relate to a period of time and it is required to include a “time” unit. These are the units “us” (microseconds), “ms” (milliseconds), “s” (seconds), “min” (minute), “h” (hours), “d” (day), “wk” (week), “mo” (month) and “a” (year).

{{ConstraintBox|
For interval of time stamps the @unit of a ''low'' or ''high'' child element shall use units
* us (microseconds),
* ms (milliseconds),
* s (seconds),
* min (minute),
* h (hours),
* d (day),
* wk (week),
* mo (month) or
* a (year).
}}

=== Interval of physical quantities (IVL_PQ) ===

Elements of this data type are used to indicate intervals of physical quantities (see also [[#Physical Quantities (PQ)|3.18 Physical Quantities (PQ)]]). In general, an upper and a lower boundary is specified. It is also possible to use ''center'' instead of ''low'' and ''high''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low || <center>TS</center> || <center>0..1</center> || <center>C</center> || the lower limit of the interval (i.e. the minimum amount).
|-
| '''high || <center>TS</center> || <center>0..1</center> || <center>C</center> || the upper limit of the interval (i.e. the maximum amount).
|-
| '''center || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of the interval
|}

The ''center'' child element is used when there is no interval, but an exact value. Alternative would be to demote IVL_PQ to data type PQ and populate the element’s ''@value'' attribute, but this is more difficult to process in XML. That is why the use of the ''center'' child element is deprecated.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<referenceRange>
<low value="7.5" unit="mmol/l"/>
<high value="10" unit="mmol/l"/>
</referenceRange>

<doseQuantity>
<center value="9" unit="1"/>
</doseQuantity>
</syntaxhighlight>

=== Ratio of quantities (RTO_QTY_QTY) ===

Elements of this data type specify ratios and have two child elements, a numerator and a denominator. The underlying QTY (Quantity) data type is an abstract data type and in a XML instance it has to be replaced by a specific data type using the ''@xsi:type'' instruction (see below).

In this specification only “PQ” or “INT” are allowed for the demotion of both ''numerator'' and ''denominator''. The relevant child elements are:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''numerator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the numerator of the ratio
|-
| '''denominator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the denominator of the ratio
|}

If a model attribute already is a RTO_QTY_QTY, you need to specify (demote) the OTY abstract data type for both ''numerator'' and ''denominator'' by using an ''@xsi:type'' instruction.
In some cases where the model attribute is of type “ANY”, also the root element shall carry an ''@xsi:type'' RTO_QTY_QTY instruction.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<maxDoseQuantity>
<numerator xsi:type="PQ" value="6"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="400" unit="mg"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="5"/>
<denominator xsi:type="PQ" value="1" unit="h"/>
</maxDoseQuantity>

<value xsi:type="RTO_QTY_QTY">
<numerator xsi:type="INT" value="1"/>
<denominator xsi:type="INT" value="10000"/>
</value>
</syntaxhighlight>

== Identification mechanisms ==

=== Object Identifiers (OIDs) ===

Standardized exchange of information using messages or documents also deals with unique identifications of objects and concepts, especially in environments where sender and receiver do not “know” each other necessarily.

It is important to understand the difference between identification of instances (ids) and code concepts (classifications). Within the context of HL7 interactions OIDs are quite often used.

An id points to a specific instance of an object or identification scheme (a particular methodology for the identification of a class of objects), for example a specific person as the patient or a physician, a specific lab observation or an X-ray photo.

In contrast to instance identifiers, a classification identifies a specific concept. The type of patient (inpatient, outpatient), the type of doctor (an anesthesiologist), the codes for gender or a lab observation (blood cell count) may serve as examples.

OIDs (object identifiers) are worldwide unique identifiers for objects. They are used in HL7 to specify identifications and classifications. An object in this sense is persistent, well-defined information, definitions or specifications and is represented with ids or codes.

Commonly used OIDs (i.e. used for a purpose that is wider in scope than the regional healthcare organization; used in communications between healthcare regions) can be found in OIDs registries such as

* [http://www.oid-info.com www.oid-info.com],
* [http://www.hl7.org www.hl7.org],
* [http://www.hl7.org.uk/version3group/oids.asp HL7 OID registry in the UK],
* [https://www.dimdi.de/dynamic/de/klassifikationen/weitere-klassifikationen-und-standards/oid/ OID registry Germany].

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|All OIDs with an element of 999 or 9999 are for documentation purposes only. They will be replaced by permanent OIDs once these have been assigned/found/applied for.
|}

OID (Object Identifiers) are unique identifiers for any kind of objects. They are defined in Rec. ITU-T X.660 | ISO/IEC 9834-1. This identification system for objects and concepts makes reliable electronic information exchange possible. Administration and Registration is regulated by a set of rules, described in the corresponding chapter of this document.

Every artefact in ART-DECOR has an Object Identifier (OID). There are recommendations for the management and the exchange of Object Identifiers, partially defined in ISO TS 13582 <ref>ISO TS 13582: https://www.iso.org/standard/69652.html</ref>.

''HL7 International'' has created a type ontology for the OIDs in the HL7 registry to make it easier for the user community to search for OIDs they may be looking for and can be found at hl7.org.

From a policy perspective it is common practice in several healthcare related OID registries (HL7 International at http://www.hl7.org, OID Registry Germany at http://www.dimdi.de, OID registry Switzerland at http://oid.refdata.ch, and OID registry Austria at https://www.gesundheit.gv.at/OID_Frontend) to distinguish at least between the following types of OIDs:

{| class="hl7table" style="width:50%"
|+<ref group="Table">Recommended OID sub-branches for different artefacts</ref> ''Recommended OID sub-branches for different artefacts''
! Arc !! Description
|-
| .3 || organizational bodies and groups
|-
| .4 || identifier systems and namespaces
|-
| .5 || code systems
|-
| .7 || document artefacts
|-
| .9 || conformance profiles
|-
| .10 || templates
|-
| .11 || value sets
|-
| .19 || examples
|-
| .99 || experimental
|}

''Example: given that “your” root OID is 1.2.3.4.5, the first value set of your governance group is then to be 1.2.3.4.5.11.1, with .11 as the value set “branch” and the last .1 as the first artefact of that kind.''

In ART-DECOR a project typically is set into the .77 branch of a governance group. When setting up the project, the OID for that project also determines the artefact OIDs using throughout the ART-DECOR project. The following additional branches are used to distinguish between different OID types:

{| class="hl7table" style="width:50%"
|+<ref group="Table">Recommended OID sub-branches for ART-DECOR projects</ref> ''Recommended OID sub-branches for ART-DECOR projects''
! Artefact code !! Description !! Recommended OID suffix
|-
| DS || dataset || .77.1
|-
| DE || dataset concept || .77.2
|-
| SC || scenario || .77.3
|-
| TR || transaction in scenario || .77.4
|-
| CS || code system || .77.5
|-
| IS || issue || .77.6
|-
| AC || actor in scenario || .77.7
|-
| CL || concept list in dataset || .77.8
|-
| EL || element in template || .77.9
|-
| TM || template || .77.10
|-
| VS || value set || .77.11
|-
| RL || rule for instances || .77.12
|-
| SX || test/example scenario || .77.18
|-
| EX || test/example instance || .77.19
|-
| QX || qualification test/example || .77.20
|-
| TX || test/example data element || .77.21
|-
| CM || community || .77.22
|-
| MP || concept map || .77.24
|}

In ART-DECOR a newly created project uses these OID branches automatically.

=== Instance identification ===

Instance identification is done with the id element of a class. Its type is II (instance identifier) and described in the data type section above. For example, a patient number can be represented as
* 2.16.578.1.34.1.5432.1, the root-OID of the issuing authority, for example a system/application in a hospital, and
* 67543242 as the ''@extension'', representing the patient number within the system defined by the ''@root'' attribute.

=== Coding scheme identification ===

Coding schemes have to be uniquely identified using OIDs as well. All coding tables used in this implementation guide show the corresponding OID that has to be specified in the ''@codeSystem'' attribute of coded elements. Both attributes ''@code'' and ''@codeSystem'' together allows a correct interpretation of concept and code.

=== List of identification schemes ===

The following are OIDs for commonly used identification schemes.

{| class="hl7table"
|+<ref group="Table">Commonly used identification scheme OIDs</ref> ''Commonly used identification scheme OIDs''
! OID !! Identification System Name !! Description !! Issuer
|-
| 1.2.276.0.76.4.8 || KV-Nummer || Krankenversichertennummer ||
|-
| 1.2.276.0.76.4.17 || BSNR || Betriebsstättennummer ||
|-
| 1.2.276.0.76.4.16 || LANR || lebenslange Arztnummer ||
|}

=== List of code systems ===

The following are OIDs for code systems.

{| class="hl7table"
|+<ref group="Table">Commonly used code system OIDs</ref> ''Commonly used code system OIDs''
! OID !! Code System Name !! Description !! Issuer
|-
| 2.16.840.1.113883.6.1 || LOINC || Logical Observation Identifiers Names and Codes (LOINC) || Regenstrief Institute
|-
| 2.16.840.1.113883.6.96 || SNOMED CT || Systemized Nomenclature in Medicine Reference Terminology (SNOMED CT) || SNOMED International
|-
| 1.0.3166.1.2 || ISO 3166-1 (second edition) || Country codes as per ISO 3166-1:2007 || ISO
|}

== Vocabulary ==

=== Code Systems ===

Within HL7, a ''Code System'' is defined as a collection of codes with associated designations and meanings. Examples of code systems include ICD-10, SNOMED CT, and LOINC.

To meet the requirements of a code system as defined by HL7, a given code must resolve to one and only one meaning within the code system. Given this definition, each code table in the HL7 Version 3 standard represents a different code system since codes are sometimes used in different tables to have different meanings.

For example, “M” in the administrative gender table (''AdministrativeGender'', OID 2.16.840.1.113883.5.1) means “male”, while “M” in the marital status table (''MaritalStatus'', OID 2.16.840.1.113883.5.2) means “married”.

In this specification, code system tables are not presented in detail.

=== Value Sets ===

A ''Value Set'' represents a uniquely identifiable set of valid concept representations, where any concept representation can be tested to determine whether or not it is a member of the value set.

Value set complexity may range from a simple flat list of concept codes drawn from a single code system, to an unbounded hierarchical set of possibly post-coordinated expressions drawn from multiple code systems.

Value sets exist to constrain the content for a coded element in an HL7 static model or data type property. Value sets cannot have null content and must contain at least one concept representation where any given concept is generally (but not required to be) represented by only a single code within the Value Set.

[[File:CDA_Core_Principles_Figure_3_ValueSet_Example.png|800px]]

<ref group="Figure">Example presentation of the value set “MaritalStatus”</ref> ''Example presentation of the value set “MaritalStatus”''

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that value set OIDs never appear in a CDA Release 2 document. They are used for constraint expressions, for example in implementation guides.

In order to send a specific code drawn from a value set, the corresponding code system has to be conveyed.

An example, in the implementation specification the constraint on the model element ''maritalStatusCode'' is expressed as “to be drawn from value set 2.16.840.1.113883.5.2 ''MaritalStatus''”.

To actually send a marital status of “M” (married) that is shown in the value set figure above, the corresponding HL7 CDA instance would say:

<syntaxhighlight lang="xml">
<maritalStatusCode code="M" codeSystem="2.16.840.1.113883.5.2"/>
</syntaxhighlight>
|}

In this specification, value set tables are not presented in detail.

==== Binding strength ====

There is an optional vocabulary strength for data types that support that feature (coded concepts). Examples include CD, CE, CV and CO. Values are required, extensible, preferred and example. Default is required.

Please note: the formerly supported values CNE (Coded No Extensibility) and CWE (Coded With Extensibility) in ART-DECOR are deprecated as of December 2017. Specification CNE is handled as required and CWE is handled as extensible.

{| class="hl7table" style="width:50%"
|+<ref group="Table">Binding Strengths</ref> ''Binding Strengths''
! Strength !! Description
|-
|required||Required/CNE. Coded with no exceptions; this element SHALL be from the specified value set
|-
|extensible||Extensible/CWE. Coded with Exceptions; this element SHALL be from the specified value set if any of the codes within the value set can apply to the concept being communicated. If the value set does not cover the concept (based on human review), alternate codings (or, data type allowing, text) may be included instead.
|-
|preferred||Preferred. Instances are encouraged to draw from the specified codes for interoperability purposes but are not required to do so to be considered conformant.
|-
|example||Example. Instances are not expected or even encouraged to draw from the specified value set. The value set merely provides examples of the types of concepts intended to be included.
|}

Mismatches with required lead to validation errors (SHALL logic). Mismatches with extensible lead to validation warnings (SHOULD logic). Mismatches with preferred lead to validation information messages (MAY logic). Mismatches with example don't have any validation consequences.

== Appendix ==

=== References ===

<references/>

=== List of figures ===

<references group="Figure" />

=== List of tables ===

<references group="Table" />

HL7 CDA Core Principles

2019-06-16T11:36:33Z

Dammon: /* Value Sets */

== Introduction ==

This implementation guide specifies the ''Core Principles'' of using the ''Clinical Document Architecture'' <ref>Clinical Document Architecture Release 2: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=7</ref>.

=== Scope ===

This guide focuses on ''Data Types Release 1'' <ref>HL7 Data Types Release 1: http://www.hl7.org</ref>. Meanwhile an ISO specification ISO 21090 is out, also known as Data Type Release 2. The latter is subject to another implementation guide that will be published when ISO data types are used.

=== Focus of this document: HL7 Version 3 Data Types for CDA ===

The following chapters of this document will focus on the description of the data types and associated material. It will highlight the essentials in four chapters, all focusing on the Norwegian situation.
* '''Common aspects:''' explains common aspects of use of CDA and XML
* '''Data types:''' gives an overview and detailed specification of all data types used in CDA
* '''Identification schemes:''' explains major aspects of identification and the use in CDA
* '''Use of vocabulary:''' explains major aspects of vocabulary use in CDA.

=== Background ===

In many (European) countries, implementation guides for the use of data types in HL7 V3 are published. They take into account country specific constraints on the data types.

=== Legend of symbols ===

In this document several symbols are used.

{| class="hl7table" style="width:50%"
| [[File:Pfeil_rechts.png|50px]] || This is an important item
|-
| [[File:Issue.svg|50px]] || This is a known open issue
|-
| [[File:Faq.svg|50px]] || This is a frequently asked question (FAQ) with answer
|-
| [[File:Conformance.svg|50px]] || This is a constraint; in some situations also the rule identification is specified, e.g. dtr1-1-ANY, which links to the corresponding validation rule.
|}

=== Version history ===

{| class="hl7table" style="width:50%"
|+
! Version !! Date !! Description !! Author
|-
| 1.1 || 2019-04-24 || Refurbished guide based on earlier work || Kai U. Heitmann
|}

== Common aspects ==

=== Use of XML ===

HL7 Version 3 CDA uses the Extensible Markup Language (XML) as the exchange format. It is assumed that the reader is familiar with common XML aspects. However, some constraints are made regarding the use of CDA.

==== Character Set ====

{{ConstraintBox|
The character encoding of any CDA document shall be “UTF-8”.}}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="utf-8"?>
</syntaxhighlight>

=== CDA document structure ===

The XML namespace for CDA Release 2 documents is ''<nowiki>urn:hl7-org:v3</nowiki>''. This must be correctly mentioned in every XML instance.

CDA XML documents starts with the root element ''ClinicalDocument''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">


...

<component>
<structuredBody>
...
</structuredBody>
</component>

</ClinicalDocument>
</syntaxhighlight>

== Data types ==

=== Introduction ===

The following chapter describes the typical data types used in CDA implementation guides. For further information please refer to the HL7 V3 standard and its two parts concerning data types:
* Abstract Data type definition <ref>HL7 Version 3 Abstract Data type definition: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=264</ref>
* XML ITS for data types <ref>XML ITS for data types: https://www.hl7.org/documentcenter/public_temp_682D4D16-1C23-BA17-0C789BA52BEDB68E/wg/inm/datatypes-its-xml20050714.htm</ref>
Data types are properties of model class attributes and the basic building blocks of information in a CDA XML instance. For example, a model attribute named “time” has as its data type a time stamp “TS” (see Figure 1).

[[File:CDA_Core_Principles_Figure_1_CDA_Structure_Data_Types.png|700px]]

<ref group="Figure">CDA structure (left) and the data type specification (right)</ref> ''CDA structure (left) and the data type specification (right)''

=== XML representation of data types ===

Actual data is mostly carried in HL7 Version 3 by populating XML attributes and not as element content. Exceptions are names of persons and organizations as well as addresses.

The XML elements have names like the model attributes. For example, a model attribute “id” has a corresponding XML element named <id…>. The model determines the sequence of elements and their hierarchy. The data type itself determines the XML attributes within the start tag. The notation here is as follows:

{| class="hl7table"
|+
! Attribute !! DT !! Conf !! Description
|-
| (name of the model attribute or XML element) || Data type || Conformance, i.e. O, R, M || Textual description
|}

XML attributes (data type properties) are denoted as ''@attribute'' in order to distinguish their names from XML elements.

Example: in the example model above, the data type of the ''id'' attribute's is ''II'' (Instance Identifier). The corresponding XML attributes for that data type include ''@root'' and ''@extension''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id root="..." extension="..." />
</syntaxhighlight>

A description of the data types and their corresponding XML representation is contained in subsequent paragraphs of this guide.

==== Exceptions using XML element content ====

For most data types, the actual data is conveyed in XML attributes. However, there are some exceptions. For the data types binary (BIN), Encapsulated Data (ED), Entity Name (EN), Person Name (PN), Organization Name (ON), Trivial Name (TN), Address (AD) and character string data (ST), information is carried as element content.

Example: the components of an address <addr> are represented by sub elements with the data as element content (in the example shown in black).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr>
<streetAddressLine>Thormøhlens gate 12</streetAddressLine>
<postalCode>5006</postalCode>
<city>Bergen</city>
</addr>
</syntaxhighlight>

==== Combined data types ====

There are a number of so-called combined data types. For example, an interval with a lower and upper limit and a ratio that has a nominator and a denominator value.

In combined data types the substructure (e.g. <low> <high> in an interval) are represented as child elements of the relevant data type element.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110701"/>
<high value="20110729"/>
</effectiveTime>
</syntaxhighlight>

==== Conformance information ====

The conformance indicators distinguish kinds of conformance information described shortly here.

* '''O''': An optional item may be omitted if no data is present, i.e. no corresponding XML attribute or element is sent (marked as “O”)
* '''R''': For required items, lower cardinality is always zero or 1.
** Elements must be present and populated with data if present in the sending system. If no data is available (yet), a null flavor (see below) indicates and possibly classifies the missing information (marked as R).
** Attribute flagged as required must be present in the instance and populated.
* '''M''': For mandatory elements data must be sent and no missing values are allowed, i.e. if the sending system does not have information for mandatory elements the XML instance cannot be created and sent (marked as M).
* '''NP''': no data may be present at all (not permitted)
* '''C''': conditional conformance; typically a conformance table shows the circumstances (conditions) derived from information in the instance and the corresponding cardinalities and conformance statements.

=== Missing values (null flavor) ===

For every data type it is possible to specify a missing value including a kind of reason why data is missing. Instead of specifying any attribute of the corresponding element, a ''@nullFlavor'' attribute expresses the omission of data. Note that missing data is not allowed for mandatory elements (see above).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value nullFlavor="OTH"/>

<code nullFlavor="UNK"/>

<booleanInd nullFlavor="NI"/>

</syntaxhighlight>

The codes for the ''@nullFlavor'' attribute are drawn from the following hierarchical code system. It is a Coded Simple (CS), which means it has no code system (attribute ''@codeSystem'') specified.

{| class="hl7table"
|+<ref group="Table">NullFlavor</ref> ''NullFlavor''
! Code
! width=15% | Print Name
! Definition / Description
|-
| NI || No Information || No information whatsoever can be inferred from this exceptional value. This is the most general exceptional value. It is also the default exceptional value.
|-
|   OTH || other || The actual value is not an element in the value domain of a variable. (e.g., concept not provided by required code system).
|-
|     NINF || negative infinity || Negative infinity of numbers.
|-
|     PINF || positive infinity || Positive infinity of numbers.
|-
|   UNK || unknown || A proper value is applicable, but not known.
|-
|     ASKU || asked but unknown || Information was sought but not found (e.g., patient was asked but didn't know)
|-
|       NAV || temporarily unavailable || Information is not available at this time but it is expected that it will be available later.
|-
|       NASK || not asked || This information has not been sought (e.g., patient was not asked)
|-
|       TRC || trace || The content is greater than zero, but too small to be quantified.
|-
|   MSK || masked || There is information on this item available but it has not been provided by the sender due to security, privacy or other reasons. There may be an alternate mechanism for gaining access to this information.
Note: using this null flavour does provide information that may be a breach of confidentiality, even though no detail data is provided. Its primary purpose is for those circumstances where it is necessary to inform the receiver that the information does exist without providing any detail.
|-
|   NA || not applicable || No proper value is applicable in this context (e.g., last menstrual period for a male).
|-
| NP || not present || Value is not present in a message. This is only defined in messages, never in application data! All values not present in the message must be replaced by the applicable default, or no-information (NI) as the default of all defaults.
|}

=== ANY as the generic data type ===

This abstract data type is the basis for all other data types. Not a single value within a CDA document has the effective data type ANY, but any data type within HL7v3 is a specialization of ANY. This also means that any other data type inherits all properties of ANY (see [[#Missing_values_.28null_flavor.29|“Missing values (null flavor)”]]).

The ANY type is occasionally found in HL7 models when it comes to clinical finding etc. where – at model time – the actual data type of the value is not known. At instantiation time however, the actual data type ''is'' known and ANY is always replaced by a particular data type in an instance.

One example is the observation value (child element value in an observation), where in the model the data type of value cannot be anticipated. When instantiation is taking place, the data type is specified by the XML instance attribute ''@xsi:type''. This information can be used by the receiver to validate and process the value.

Attributes of an element with this data type are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@nullFlavor''' || <center>CS</center> || <center>–</center> || Classification of the missing value, see [[#Missing_values_.28null_flavor.29|3.3 Missing values (null flavor)]].
|}

{| class="hl7table" style="width:100%"
| width=8% | <center>[[File:Conformance.svg|50px]] dtr1-1-ANY</center> || If there is a ''nullFlavor'', there shall be no other attribute or element, unless it's ''nullFlavor="OTH"''.

In that case ''@codeSystem'' or ''originalText'' (see “code” data types) may have a value.
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">

<value xsi:type="CE" code="N11.9" codeSystem="2.16.840.1.113883.6.3"/>


<value xsi:type="PQ" value="12" unit="mL"/>


<value xsi:type="ED">this is text</value>
</syntaxhighlight>

=== Boolean (BL) ===

Elements of this data type refer to Boolean logic and have an attribute ''@value''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>BL</center> || <center>–</center> || Valued as “true” or “false”
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<negationInd value="false"/>

<deceasedInd value="true"/>

</syntaxhighlight>

In some situations, the BL data does not apply to an XML element, but an attribute. In that case, the attribute carries the Boolean value directly.
<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<support contextConductionInd ="false">
...
</support>
</syntaxhighlight>

=== Instance Identifier (II) ===

This data type identifies instances of classes like observations or entities (persons, organizations). Attributes are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@extension''' || <center>ST</center> || <center>O</center> || Identification
|-
| '''@root''' || <center>OID</center> || <center>R</center> || Source of identification
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id extension="13234453645" root="2.16.840.1.113883.2.6.15.3.427.1"/>
</syntaxhighlight>

The ''@root'' attribute is of type OID (object identifier), a unique identifier of the issuing authority or system. For example, a patient with a patient number 13234453645 created by a specific healthcare provider organization is uniquely identified by the number itself in ''@extension'' and the OID of the organization or the sending system, in the example 2.16.840.1.113883.2.6.15.3.427.1 in ''@root''.

In some cases, a single OID identifies an object uniquely. In that situation, only ''@root'' is populated and ''@extension'' is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Encapsulated Data (ED) ===

Elements of this data type carry multimedia content. The actual multimedia content is represented as element content. There are two situations for the use of ED:

* Inline: The full data is transmitted in the type. This form is mainly used for text.
* By reference: a thumbnail is provided which links to the full data by reference.

In an instance, the data type is normally determined by an ''xsi:type'' specification and some attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@mediaType''' || <center>CS</center> || <center>O</center> || MIME media type classification. At time of writing this specification, the following MIME types are allowed:
* text/plain (plain text)
* text/html (text with html markup)
* image/jpeg (JPEG image)
* application/pdf (a PDF, portable document format)
* application/hl7-sda+xml (CDA documents).
|-
| '''@representation''' || <center>CS</center> || <center>O</center> || Representation of the multimedia content. At time of writing this specification, the following representations are allowed:
* TXT (text, this is the default)
* B64 base 64 encoded data, for example for embedded CDA documents).
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<text xsi:type="ED" mediaType="text/plain">
Patient treated sucessfully
</text>

<text mediaType="application/hl7-sda+xml" representation="B64">PD94bWw..etc..==</text>

</syntaxhighlight>

To include referenced data the two sub elements ''thumbnail'' and ''reference'' are used.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''reference''' || <center>TEL</center> || <center>0..*</center> || <center>O</center> || Link (URI) to full data
|-
| '''thumbnail''' || <center>ED</center> || <center>0..*</center> || <center>O</center> || Thumbnail of referenced data
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value xsi:type="ED" mediaType="image/png" representation="B64">
<reference value="http://radiology.bergen.no/xrays/128s.png"/>
<thumbnail mediaType="image/jpeg" representation="B64"> MNY...83== </thumbnail>
</value>
</syntaxhighlight>

=== Strings (ST) ===

This data type is a specialization of the ED type where ''@mediaType'' is fixed “text/plain” and ''@representation'' is fixed “TXT”. It allows conveying a character string as '''element content'''. This data type is used in other data types it like the ''@extension'' in instance identifiers, or address and person name data type components.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<lotNumber> 143GT6DT </lotNumber>
</syntaxhighlight>

=== Concept Descriptor (CD) ===

This data type specifies a concept by means of a code and its code system (except for situations where no code is available).

A couple of specializations of data type CD exist, which differ in the main characteristics (properties) of the data type that may or may not be supported.

{| class="hl7table" style="width:50%"
|+<ref group="Table">Properties of data types used for codes</ref> ''Properties of data types used for codes''
! <div style="text-align: right">DataType</div> !! CD !! CE !! CV !! CO !! CS
|-
! <div style="text-align: left">Property</div> !! !! !! !! !!
|-
| '''@code''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||<center>X</center>
|-
| '''@codeSystem''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''@codeSystemVersion''' || <center>X</center> || <center>X</center> || <center>X</center>|| <center>X</center> ||
|-
| '''@displayName''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''originalText''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''translation''' || <center>X</center> || <center>X</center> || || ||
|-
| '''qualifier''' || <center>X</center> || || || ||
|}

Because the CE variant is most used in practice, the general explanation of the properties will be given with de description of CE (see below).

The only attribute that is unique to CD is briefly explained here.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@qualifier''' || <center>CR</center> || <center>O</center> || An additional qualifier for the code.
|}

Complex terminologies like SNOMED CT can be used only using data type CD.

=== Coded with Equivalents (CE) ===

With elements of this data type, a concept by means of a code and its coding system (except for situations where no code is available) can be specified. It optionally contains one or more equivalents using other code systems.

It may contain the following attributes:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@code''' || <center>ST</center> || <center>R</center> || The actual code
|-
| '''@codeSystem''' || <center>OID</center> || <center>R</center> || required to identify the code system were the code is drawn from. This is an OID (object identifier, see [[#Object_Identifiers_.28OIDs.29|Object Identifiers at 4.1]])
|-
| '''@displayName''' || <center>ST</center> || <center>O</center> || Optional textual representation of code. A display name may be specified representing the plain text of the code. The information of this attribute may not be used by the receiving system for interpretation, but only for display purposes. The display name may never be transmitted without a code and must have the same meaning as the code.
|-
| '''@codeSystemName''' || <center>ST</center> || <center>O</center> || A textual representation of the name of the code system
|-
| '''@codeSystemVersion''' || <center>ST</center> || <center>O</center> || A textual representation of the version of the code system
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"/>

<code code="AU" codeSystem="2.16.840.1.113883.5.33"/>

<storageCode code="AC" codeSystem="2.16.840.1.113883.5.34" displayName="active"/>

<code code="A45.0" displayName="Somatisierungsstörung" codeSystem="1.2.276.0.76.5.409" codeSystemName="ICD-10 GM 2012"/>
</syntaxhighlight>

There are some child elements of codes that can be used to express what the “original text” was that was used for the coding or to indicate that there are “translations” to other code systems than the primary code.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''originalText''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Textual representation of the concept, actually a description which was used to create the actual code
|}

No semantics may be assumed other than showing the ''@displayName'' to a user to clarify the code. A display name cannot occur without its code and must carry the same meaning.

In case no code is known, it is allowed to specify a ''@nullFlavor'' for the code element and to give information about the (not yet coded) concept in original text. However, this should be an exception.

If other codes than the primary code need to be conveyed adding a translation child element can be used.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<originalText>minor aphthous stomatitis</originalText>
</code>
</syntaxhighlight>

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''translation''' || <center>CD</center> || <center>0..*</center> || <center>O</center> || Alternative code(s)
|}

A ''translation'' element is also of type CD and shall have a code and a code system identified. It shall point to the same concept as the primary code. It is allowed that a translation conveys less conceptual details than the original code.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<translation code="528.2" codeSystem="2.16.840.1.113883.6.2" codeSystemName="ICD9" displayName="Oral aphthae"/>
</code>
</syntaxhighlight>

=== Coded Value (CV) ===

This is actually a specialization of CE (see above), with the exception that neither ''originalText'' nor ''translation'' child element are allowed.

=== Coded Simple Value (CS) ===

This is actually a specialization of CE (see above), with no code system attribute and no original text or translation child element allowed. It specifies a concept by means of a code from a ''predefined'' code system (table) where the code is drawn from. This data type is usually applied in the context of fixed predefined HL7 tables.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<statusCode code="completed"/>
</syntaxhighlight>

In this example ''statusCode'' is bound in the underlying model to the specific code system ''ActStatus''. Because it is predefined by means of the vocabulary binding, ''@codeSystem'' is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Telecommunication Address (TEL) ===

Elements of this type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>ST</center> || <center>R</center> || carries strings that represent telecommunication contact information
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

The actual data is preceded by the scheme (refer to Internet Standard “RFC 1738 Uniform Resource Locators (URL)” <ref>RFC 1738 Uniform Resource Locators (URL): http://www.ietf.org/rfc/rfc1738.txt</ref>.

Examples:
* telephone (tel:),
* fax (fax:),
* email (mailto:).

It must follow the rules defined in Internet “RFC 2806 URLs for Telephone Calls” <ref>RFC 2806 URLs for Telephone Calls: http://www.ietf.org/rfc/rfc2806.txt</ref>.

The following codes will be used in the “use” attribute:
* H – Home
* WP – Work
* MC can be used (in addition to H or WP) to denote that this is a mobile phone.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257" />

<telecom use="H" value="tel:55354257" />

<telecom use="H" value="fax:56542558" />

<telecom value="tel:+41.34.21.4765342"/>

<telecom value="mailto:opr@opr-sem.no"/>

<telecom use="WP MC" value="tel:97555786" />
</syntaxhighlight>

It is possible to express the useable period of a telecommunication contact. A child element ''useablePeriod'' is used as a time interval to indicate this period.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''useablePeriod''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257">
<useablePeriod>
<high value="20111201"/>
</useablePeriod>
</telecom>
</syntaxhighlight>

=== Postal Address (AD) ===

Elements of this data type have a substructure in order to represent a structured address specification. In this implementation guide only a selection of all possible child elements is allowed, the original HL7 specification is richer.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''streetAddressLine''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Street address, includes street name and house number
|-
| '''city''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || City
|-
| '''postalCode''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Postal code
|-
| '''country''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Country
|-
|}

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that the sequence of the sub elements is country specific, i.e. it has to follow “common” rules how to write an address. For example, an UK address and a German address have different sequences of address representation.
|}

A ''@use'' attribute can also be specified.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="WP">
<streetAddressLine>Anna-Louisa-Karsch-Str. 2</streetAddressLine>
<postalCode>10178</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="H WP">
<streetAddressLine>Tatungasse 34</streetAddressLine>
<postalCode>10825</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

Also, a country may be specified using the element ''country''.

=== Person Name (PN) ===

Elements of this data type do also have a substructure to represent the parts of a person name, like family or given name and prefixes.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>
<given>Franz</given>
<given>Ingrun</given>
<family>Nordmann</family>
</name>
</syntaxhighlight>

Previous or birth or maiden names are supported using the ''validTime'' element. ''validTime'' (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]]) specifies the validity range of the name.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">

<name>
<given>Jan</given>
<given>Olaf</given>
<family>Hendrikson</family>
<validTime>
<high value="20000101"/>
</validTime>
</name>
</syntaxhighlight>

Note that the name attribute is repeating, i.e. multiple (types of) names could be sent. It is up to the receiver (based on the value of the ''@use'' attribute, and ''validTime'') to decide what name it wants to use or import in its database.

=== Organisation Name (ON) ===

Elements of this data type represent a name of an organization.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name> Charité Berlin </name>
</syntaxhighlight>

The optional ''validTime'' element (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]] may be used to specify the validity range of the name of the organization.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name of the organization
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>The old hospital
<validTime>
<high value="20111231235959"/>
</validTime>
</name>
</syntaxhighlight>

Please note that the use of ''validTime'' yields XML mixed content which should be avoided if possible.

=== Integer Number (INT) ===

Elements of this data type are used to specify integer numbers and have one attribute.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>int</center> || <center>R</center> || Integer value
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<sequenceNumber value="24"/>
</syntaxhighlight>

=== Physical Quantities (PQ) ===

Elements of this data type are physical quantities, i.e. a measurable quantity (or countable) value from the physical world. This is different from just a “number”, because there is a (natural) unit specified in which the measurable quantity is expressed.
Examples:
* an amount of blood 20 ml (sample volume)
* a cut with a length of 10 cm (result observation)
* a dose of 200 milligrams per administration (dosing)
* delivery of 60 pieces of a tablet (amount supplied).
Elements of this data type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>real</center> || <center>R</center> || value of the measurement
|-
| '''@unit''' || <center>CS</center> || <center>R</center> || unit of measurement
|}

In the unit of measurement unit is expressed following the ''Unified Code for Units of Measure'' (UCUM) specification. This specification is a collection of atomic units, prefixes and a corresponding grammar for valid combinations to build all-natural units of measurement. For a complete description of possible units, see the ''Unified Code for Units of Measure'' <ref>Unified Code for Units of Measure: http://unitsofmeasure.org/</ref> specification.

If a value is not countable or if measurable, for example expressed in milligrams or liters, then this unit is a valid UCUM unit like “mg” or “L”. If a value is countable, for example the number of tablets, then this attribute contains “1”.

In HL7 it is required that all PQ data type units are valid UCUM units.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<value value="165" unit="cm"/>

<value value="81.1" unit="kg"/>

<value value="120" unit="mm[Hg]"/>

<value value="5" unit="1"/>
</syntaxhighlight>

=== Point in Time (TS) ===

Elements of this data type have the attribute

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>TS</center> || <center>R</center> || Point in time
|}

and specify points in time in the format YYYYMMDDhhmmss±ZZZZ, where
* YYYY is the four-digit year,
* MM the two-digit month,
* DD the two-digit day,
* hh the two-digit hour,
* mm the two-digits minute and
* ss the two-digit second.
Optional a time zone ZZZZ, the four-digit time alignment with a preceding “-” or a “+” can be specified. If time zone is omitted, local time is assumed.

The point in time may be right truncated in respect to the precision of the information.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<effectiveTime value="20140412"/>

<effectiveTime value="201409091245"/>

<effectiveTime value="1996"/>

<birthTime value="19540714"/>

<effectiveTime value="20140412+0100"/>
</syntaxhighlight>

=== Intervals (IVL) ===

Intervals are defined only for data types with an ordinal or interval scale type. There are several possibilities to determine an interval (see Figure 2), for example to specify

* a lower <low> and an upper boundary <high> (a),
* a lower <low> boundary and width <width> (b)
* an upper boundary and width <width> (c) or
* the middle of the interval <nowiki><center></nowiki> and a width <width> (d).

[[File:CDA_Core_Principles_Figure_2_Determining_Intervals.png|700px]]

<ref group="Figure">Several possibilities to determine closed intervals</ref> ''Several possibilities to determine closed intervals''

In addition, there is sometimes the need to specify incomplete intervals (open intervals). For example, an interval with only an upper limit to indicate a maximum dose or a start date and time only to express “since…”.

{{ConstraintBox|
To indicate an interval, only the following combinations are permitted.
(1) A lower and an upper boundary may not be identical, and their accuracy has to be equal.

Correct examples:

{{BeginGreenBox|}}
Interval from 5 to 6
Interval from 20110607 until 20110612
{{EndGreenBox}}

Incorrect examples:

{{BeginRedBox|}}
Interval from 5 to 6.0
Interval from 20110101 to 2011
{{EndRedBox|}}

(2) A lower boundary and a width

(3) A lower limit boundary

(4) A upper limit boundary

(5) Only the middle of the interval

(6) Only the width of an interval}}

Accordingly, four child elements are available.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Lower boundary
|-
| '''high''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Upper boundary
|-
| '''center''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Where ''(T)'' is defined in this specification as one of the data types “TS” or “PQ”.

=== Interval of time (IVL_TS) ===

Elements of this data type represent time intervals. There are four possible child elements.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Lower boundary (start date/time)
|-
| '''high''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Upper boundary (end date/time)
|-
| '''center''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Normally, a lower and an upper boundary is given, both are points in time. Also, it is possible to specify open intervals like “since June 14, 1999” (left boundary given only) or “until September 24, 2006” (right boundary given).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110507"/>
<high value="20110909"/>
</effectiveTime>

<effectiveTime>
<low value="20110507"/>
</effectiveTime>

<value>
<low value="20110101"/>
<width value="120" unit="d"/>
</value>

<value>
<center value="20110101"/>
</value>
</syntaxhighlight>

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|It must be noted that intervals of time stamps in HL7 are equally treated as other interval types (e.g. integers). The statement, one may take 1–3 tablets (interval of integers), for example, says that you are allowed to take no more than three tablets, not 3½ or 3.5 tablets. On the other hand, when treat the words “until 12 June 2011” regarding the upper interval limit differently, particularly we assume that the entire day 12 June is still included in this time interval.

Thus, in human perception time intervals are handled differently compared to such as number intervals. This is a situation may lead to inconsistencies in standardized communication. As a conclusion, an upper limit “12 June 2011” means that only the very first moment of the 12 June is included in the interval, but not, for example, the 12 June 13:00 hours.

Interpretation does not depend on the accuracy of the time:
* “after 2004” means “from January 1, 2005 00:00:00.000”,
* “after 20041201” means “from 2 December 2004 00:00:00.000 hours”,
* and “after 200412011200” means “from 1 December 2004 12:01:00.000”.

As a result, you have to carefully consider the specification and implemen-tation of time intervals upper boundaries. In order to prevent mis-understandings intervals are always specified with the date and time for an upper limit that would cover the whole day. Accordingly, “201106122359” means 12 June 2011 throughout the day.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="201106122359"/>
</effectiveTime>
</syntaxhighlight>

Because of the equal treatment of time intervals this is applied also to the lower limit boundaries of time intervals as “0000”. This means for example that “since 9 June 2011” is expressed as “201106090000”.
|}

The <width> element is of data type PQ (physical quantity). The value obviously shall relate to a period of time and it is required to include a “time” unit. These are the units “us” (microseconds), “ms” (milliseconds), “s” (seconds), “min” (minute), “h” (hours), “d” (day), “wk” (week), “mo” (month) and “a” (year).

{{ConstraintBox|
For interval of time stamps the @unit of a ''low'' or ''high'' child element shall use units
* us (microseconds),
* ms (milliseconds),
* s (seconds),
* min (minute),
* h (hours),
* d (day),
* wk (week),
* mo (month) or
* a (year).
}}

=== Interval of physical quantities (IVL_PQ) ===

Elements of this data type are used to indicate intervals of physical quantities (see also [[#Physical Quantities (PQ)|3.18 Physical Quantities (PQ)]]). In general, an upper and a lower boundary is specified. It is also possible to use ''center'' instead of ''low'' and ''high''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low || <center>TS</center> || <center>0..1</center> || <center>C</center> || the lower limit of the interval (i.e. the minimum amount).
|-
| '''high || <center>TS</center> || <center>0..1</center> || <center>C</center> || the upper limit of the interval (i.e. the maximum amount).
|-
| '''center || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of the interval
|}

The ''center'' child element is used when there is no interval, but an exact value. Alternative would be to demote IVL_PQ to data type PQ and populate the element’s ''@value'' attribute, but this is more difficult to process in XML. That is why the use of the ''center'' child element is deprecated.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<referenceRange>
<low value="7.5" unit="mmol/l"/>
<high value="10" unit="mmol/l"/>
</referenceRange>

<doseQuantity>
<center value="9" unit="1"/>
</doseQuantity>
</syntaxhighlight>

=== Ratio of quantities (RTO_QTY_QTY) ===

Elements of this data type specify ratios and have two child elements, a numerator and a denominator. The underlying QTY (Quantity) data type is an abstract data type and in a XML instance it has to be replaced by a specific data type using the ''@xsi:type'' instruction (see below).

In this specification only “PQ” or “INT” are allowed for the demotion of both ''numerator'' and ''denominator''. The relevant child elements are:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''numerator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the numerator of the ratio
|-
| '''denominator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the denominator of the ratio
|}

If a model attribute already is a RTO_QTY_QTY, you need to specify (demote) the OTY abstract data type for both ''numerator'' and ''denominator'' by using an ''@xsi:type'' instruction.
In some cases where the model attribute is of type “ANY”, also the root element shall carry an ''@xsi:type'' RTO_QTY_QTY instruction.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<maxDoseQuantity>
<numerator xsi:type="PQ" value="6"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="400" unit="mg"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="5"/>
<denominator xsi:type="PQ" value="1" unit="h"/>
</maxDoseQuantity>

<value xsi:type="RTO_QTY_QTY">
<numerator xsi:type="INT" value="1"/>
<denominator xsi:type="INT" value="10000"/>
</value>
</syntaxhighlight>

== Identification mechanisms ==

=== Object Identifiers (OIDs) ===

Standardized exchange of information using messages or documents also deals with unique identifications of objects and concepts, especially in environments where sender and receiver do not “know” each other necessarily.

It is important to understand the difference between identification of instances (ids) and code concepts (classifications). Within the context of HL7 interactions OIDs are quite often used.

An id points to a specific instance of an object or identification scheme (a particular methodology for the identification of a class of objects), for example a specific person as the patient or a physician, a specific lab observation or an X-ray photo.

In contrast to instance identifiers, a classification identifies a specific concept. The type of patient (inpatient, outpatient), the type of doctor (an anesthesiologist), the codes for gender or a lab observation (blood cell count) may serve as examples.

OIDs (object identifiers) are worldwide unique identifiers for objects. They are used in HL7 to specify identifications and classifications. An object in this sense is persistent, well-defined information, definitions or specifications and is represented with ids or codes.

Commonly used OIDs (i.e. used for a purpose that is wider in scope than the regional healthcare organization; used in communications between healthcare regions) can be found in OIDs registries such as

* [http://www.oid-info.com www.oid-info.com],
* [http://www.hl7.org www.hl7.org],
* [http://www.hl7.org.uk/version3group/oids.asp HL7 OID registry in the UK],
* [https://www.dimdi.de/dynamic/de/klassifikationen/weitere-klassifikationen-und-standards/oid/ OID registry Germany].

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|All OIDs with an element of 999 or 9999 are for documentation purposes only. They will be replaced by permanent OIDs once these have been assigned/found/applied for.
|}

OID (Object Identifiers) are unique identifiers for any kind of objects. They are defined in Rec. ITU-T X.660 | ISO/IEC 9834-1. This identification system for objects and concepts makes reliable electronic information exchange possible. Administration and Registration is regulated by a set of rules, described in the corresponding chapter of this document.

Every artefact in ART-DECOR has an Object Identifier (OID). There are recommendations for the management and the exchange of Object Identifiers, partially defined in ISO TS 13582 <ref>ISO TS 13582: https://www.iso.org/standard/69652.html</ref>.

''HL7 International'' has created a type ontology for the OIDs in the HL7 registry to make it easier for the user community to search for OIDs they may be looking for and can be found at hl7.org.

From a policy perspective it is common practice in several healthcare related OID registries (HL7 International at http://www.hl7.org, OID Registry Germany at http://www.dimdi.de, OID registry Switzerland at http://oid.refdata.ch, and OID registry Austria at https://www.gesundheit.gv.at/OID_Frontend) to distinguish at least between the following types of OIDs:

{| class="hl7table" style="width:50%"
|+<ref group="Table">Recommended OID sub-branches for different artefacts</ref> ''Recommended OID sub-branches for different artefacts''
! Arc !! Description
|-
| .3 || organizational bodies and groups
|-
| .4 || identifier systems and namespaces
|-
| .5 || code systems
|-
| .7 || document artefacts
|-
| .9 || conformance profiles
|-
| .10 || templates
|-
| .11 || value sets
|-
| .19 || examples
|-
| .99 || experimental
|}

''Example: given that “your” root OID is 1.2.3.4.5, the first value set of your governance group is then to be 1.2.3.4.5.11.1, with .11 as the value set “branch” and the last .1 as the first artefact of that kind.''

In ART-DECOR a project typically is set into the .77 branch of a governance group. When setting up the project, the OID for that project also determines the artefact OIDs using throughout the ART-DECOR project. The following additional branches are used to distinguish between different OID types:

{| class="hl7table" style="width:50%"
|+<ref group="Table">Recommended OID sub-branches for ART-DECOR projects</ref> ''Recommended OID sub-branches for ART-DECOR projects''
! Artefact code !! Description !! Recommended OID suffix
|-
| DS || dataset || .77.1
|-
| DE || dataset concept || .77.2
|-
| SC || scenario || .77.3
|-
| TR || transaction in scenario || .77.4
|-
| CS || code system || .77.5
|-
| IS || issue || .77.6
|-
| AC || actor in scenario || .77.7
|-
| CL || concept list in dataset || .77.8
|-
| EL || element in template || .77.9
|-
| TM || template || .77.10
|-
| VS || value set || .77.11
|-
| RL || rule for instances || .77.12
|-
| SX || test/example scenario || .77.18
|-
| EX || test/example instance || .77.19
|-
| QX || qualification test/example || .77.20
|-
| TX || test/example data element || .77.21
|-
| CM || community || .77.22
|-
| MP || concept map || .77.24
|}

In ART-DECOR a newly created project uses these OID branches automatically.

=== Instance identification ===

Instance identification is done with the id element of a class. Its type is II (instance identifier) and described in the data type section above. For example, a patient number can be represented as
* 2.16.578.1.34.1.5432.1, the root-OID of the issuing authority, for example a system/application in a hospital, and
* 67543242 as the ''@extension'', representing the patient number within the system defined by the ''@root'' attribute.

=== Coding scheme identification ===

Coding schemes have to be uniquely identified using OIDs as well. All coding tables used in this implementation guide show the corresponding OID that has to be specified in the ''@codeSystem'' attribute of coded elements. Both attributes ''@code'' and ''@codeSystem'' together allows a correct interpretation of concept and code.

=== List of identification schemes ===

The following are OIDs for commonly used identification schemes.

{| class="hl7table"
|+<ref group="Table">Commonly used identification scheme OIDs</ref> ''Commonly used identification scheme OIDs''
! OID !! Identification System Name !! Description !! Issuer
|-
| 1.2.276.0.76.4.8 || KV-Nummer || Krankenversichertennummer ||
|-
| 1.2.276.0.76.4.17 || BSNR || Betriebsstättennummer ||
|-
| 1.2.276.0.76.4.16 || LANR || lebenslange Arztnummer ||
|}

=== List of code systems ===

The following are OIDs for code systems.

{| class="hl7table"
|+<ref group="Table">Commonly used code system OIDs</ref> ''Commonly used code system OIDs''
! OID !! Code System Name !! Description !! Issuer
|-
| 2.16.840.1.113883.6.1 || LOINC || Logical Observation Identifiers Names and Codes (LOINC) || Regenstrief Institute
|-
| 2.16.840.1.113883.6.96 || SNOMED CT || Systemized Nomenclature in Medicine Reference Terminology (SNOMED CT) || SNOMED International
|-
| 1.0.3166.1.2 || ISO 3166-1 (second edition) || Country codes as per ISO 3166-1:2007 || ISO
|}

== Vocabulary ==

=== Code Systems ===

Within HL7, a ''Code System'' is defined as a collection of codes with associated designations and meanings. Examples of code systems include ICD-10, SNOMED CT, and LOINC.

To meet the requirements of a code system as defined by HL7, a given code must resolve to one and only one meaning within the code system. Given this definition, each code table in the HL7 Version 3 standard represents a different code system since codes are sometimes used in different tables to have different meanings.

For example, “M” in the administrative gender table (''AdministrativeGender'', OID 2.16.840.1.113883.5.1) means “male”, while “M” in the marital status table (''MaritalStatus'', OID 2.16.840.1.113883.5.2) means “married”.

In this specification, code system tables are not presented in detail.

=== Value Sets ===

A ''Value Set'' represents a uniquely identifiable set of valid concept representations, where any concept representation can be tested to determine whether or not it is a member of the value set.

Value set complexity may range from a simple flat list of concept codes drawn from a single code system, to an unbounded hierarchical set of possibly post-coordinated expressions drawn from multiple code systems.

Value sets exist to constrain the content for a coded element in an HL7 static model or data type property. Value sets cannot have null content and must contain at least one concept representation where any given concept is generally (but not required to be) represented by only a single code within the Value Set.

[[File:CDA_Core_Principles_Figure_3_ValueSet_Example.png|800px]]

<ref group="Figure">Example presentation of the value set “MaritalStatus”</ref> ''Example presentation of the value set “MaritalStatus”''

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that value set OIDs never appear in a CDA Release 2 document. They are used for constraint expressions, for example in implementation guides.

In order to send a specific code drawn from a value set, the corresponding code system has to be conveyed.

An example, in the implementation specification the constraint on the model element ''maritalStatusCode'' is expressed as “to be drawn from value set 2.16.840.1.113883.5.2 ''MaritalStatus''”.

To actually send a marital status of “M” (married) that is shown in the value set figure above, the corresponding HL7 CDA instance would say:

<syntaxhighlight lang="xml">
<maritalStatusCode code="M" codeSystem="2.16.840.1.113883.5.2"/>
</syntaxhighlight>
|}

In this specification, value set tables are not presented in detail.

==== Binding strength ====

There is an optional vocabulary strength for data types that support that feature (coded concepts). Examples include CD, CE, CV and CO. Values are required, extensible, preferred and example. Default is required.

Please note: the formerly supported values CNE (Coded No Extensibility) and CWE (Coded With Extensibility) in ART-DECOR are deprecated as of December 2017. Specification CNE is handled as required and CWE is handled as extensible.

{| class="hl7table" style="width:50%"
|+<ref group="Table">Binding Strengths</ref> ''Binding Strengths''
! Strength !! Description
|-
|required||Required/CNE. Coded with no exceptions; this element SHALL be from the specified value set
|-
|extensible||Extensible/CWE. Coded with Exceptions; this element SHALL be from the specified value set if any of the codes within the value set can apply to the concept being communicated. If the value set does not cover the concept (based on human review), alternate codings (or, data type allowing, text) may be included instead.
|-
|preferred||Preferred. Instances are encouraged to draw from the specified codes for interoperability purposes but are not required to do so to be considered conformant.
|-
|example||Example. Instances are not expected or even encouraged to draw from the specified value set. The value set merely provides examples of the types of concepts intended to be included.
|}

Mismatches with required lead to validation errors (SHALL logic). Mismatches with extensible lead to validation warnings (SHOULD logic). Mismatches with preferred lead to validation information messages (MAY logic). Mismatches with example don't have any validation consequences.

== Appendix ==

=== References ===

<references/>

=== List of figures ===

<references group="Figure" />

=== List of tables ===

<references group="Table" />

HL7 CDA Core Principles

2019-06-16T11:32:43Z

Dammon: /* Code Systems */

== Introduction ==

This implementation guide specifies the ''Core Principles'' of using the ''Clinical Document Architecture'' <ref>Clinical Document Architecture Release 2: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=7</ref>.

=== Scope ===

This guide focuses on ''Data Types Release 1'' <ref>HL7 Data Types Release 1: http://www.hl7.org</ref>. Meanwhile an ISO specification ISO 21090 is out, also known as Data Type Release 2. The latter is subject to another implementation guide that will be published when ISO data types are used.

=== Focus of this document: HL7 Version 3 Data Types for CDA ===

The following chapters of this document will focus on the description of the data types and associated material. It will highlight the essentials in four chapters, all focusing on the Norwegian situation.
* '''Common aspects:''' explains common aspects of use of CDA and XML
* '''Data types:''' gives an overview and detailed specification of all data types used in CDA
* '''Identification schemes:''' explains major aspects of identification and the use in CDA
* '''Use of vocabulary:''' explains major aspects of vocabulary use in CDA.

=== Background ===

In many (European) countries, implementation guides for the use of data types in HL7 V3 are published. They take into account country specific constraints on the data types.

=== Legend of symbols ===

In this document several symbols are used.

{| class="hl7table" style="width:50%"
| [[File:Pfeil_rechts.png|50px]] || This is an important item
|-
| [[File:Issue.svg|50px]] || This is a known open issue
|-
| [[File:Faq.svg|50px]] || This is a frequently asked question (FAQ) with answer
|-
| [[File:Conformance.svg|50px]] || This is a constraint; in some situations also the rule identification is specified, e.g. dtr1-1-ANY, which links to the corresponding validation rule.
|}

=== Version history ===

{| class="hl7table" style="width:50%"
|+
! Version !! Date !! Description !! Author
|-
| 1.1 || 2019-04-24 || Refurbished guide based on earlier work || Kai U. Heitmann
|}

== Common aspects ==

=== Use of XML ===

HL7 Version 3 CDA uses the Extensible Markup Language (XML) as the exchange format. It is assumed that the reader is familiar with common XML aspects. However, some constraints are made regarding the use of CDA.

==== Character Set ====

{{ConstraintBox|
The character encoding of any CDA document shall be “UTF-8”.}}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="utf-8"?>
</syntaxhighlight>

=== CDA document structure ===

The XML namespace for CDA Release 2 documents is ''<nowiki>urn:hl7-org:v3</nowiki>''. This must be correctly mentioned in every XML instance.

CDA XML documents starts with the root element ''ClinicalDocument''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">


...

<component>
<structuredBody>
...
</structuredBody>
</component>

</ClinicalDocument>
</syntaxhighlight>

== Data types ==

=== Introduction ===

The following chapter describes the typical data types used in CDA implementation guides. For further information please refer to the HL7 V3 standard and its two parts concerning data types:
* Abstract Data type definition <ref>HL7 Version 3 Abstract Data type definition: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=264</ref>
* XML ITS for data types <ref>XML ITS for data types: https://www.hl7.org/documentcenter/public_temp_682D4D16-1C23-BA17-0C789BA52BEDB68E/wg/inm/datatypes-its-xml20050714.htm</ref>
Data types are properties of model class attributes and the basic building blocks of information in a CDA XML instance. For example, a model attribute named “time” has as its data type a time stamp “TS” (see Figure 1).

[[File:CDA_Core_Principles_Figure_1_CDA_Structure_Data_Types.png|700px]]

<ref group="Figure">CDA structure (left) and the data type specification (right)</ref> ''CDA structure (left) and the data type specification (right)''

=== XML representation of data types ===

Actual data is mostly carried in HL7 Version 3 by populating XML attributes and not as element content. Exceptions are names of persons and organizations as well as addresses.

The XML elements have names like the model attributes. For example, a model attribute “id” has a corresponding XML element named <id…>. The model determines the sequence of elements and their hierarchy. The data type itself determines the XML attributes within the start tag. The notation here is as follows:

{| class="hl7table"
|+
! Attribute !! DT !! Conf !! Description
|-
| (name of the model attribute or XML element) || Data type || Conformance, i.e. O, R, M || Textual description
|}

XML attributes (data type properties) are denoted as ''@attribute'' in order to distinguish their names from XML elements.

Example: in the example model above, the data type of the ''id'' attribute's is ''II'' (Instance Identifier). The corresponding XML attributes for that data type include ''@root'' and ''@extension''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id root="..." extension="..." />
</syntaxhighlight>

A description of the data types and their corresponding XML representation is contained in subsequent paragraphs of this guide.

==== Exceptions using XML element content ====

For most data types, the actual data is conveyed in XML attributes. However, there are some exceptions. For the data types binary (BIN), Encapsulated Data (ED), Entity Name (EN), Person Name (PN), Organization Name (ON), Trivial Name (TN), Address (AD) and character string data (ST), information is carried as element content.

Example: the components of an address <addr> are represented by sub elements with the data as element content (in the example shown in black).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr>
<streetAddressLine>Thormøhlens gate 12</streetAddressLine>
<postalCode>5006</postalCode>
<city>Bergen</city>
</addr>
</syntaxhighlight>

==== Combined data types ====

There are a number of so-called combined data types. For example, an interval with a lower and upper limit and a ratio that has a nominator and a denominator value.

In combined data types the substructure (e.g. <low> <high> in an interval) are represented as child elements of the relevant data type element.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110701"/>
<high value="20110729"/>
</effectiveTime>
</syntaxhighlight>

==== Conformance information ====

The conformance indicators distinguish kinds of conformance information described shortly here.

* '''O''': An optional item may be omitted if no data is present, i.e. no corresponding XML attribute or element is sent (marked as “O”)
* '''R''': For required items, lower cardinality is always zero or 1.
** Elements must be present and populated with data if present in the sending system. If no data is available (yet), a null flavor (see below) indicates and possibly classifies the missing information (marked as R).
** Attribute flagged as required must be present in the instance and populated.
* '''M''': For mandatory elements data must be sent and no missing values are allowed, i.e. if the sending system does not have information for mandatory elements the XML instance cannot be created and sent (marked as M).
* '''NP''': no data may be present at all (not permitted)
* '''C''': conditional conformance; typically a conformance table shows the circumstances (conditions) derived from information in the instance and the corresponding cardinalities and conformance statements.

=== Missing values (null flavor) ===

For every data type it is possible to specify a missing value including a kind of reason why data is missing. Instead of specifying any attribute of the corresponding element, a ''@nullFlavor'' attribute expresses the omission of data. Note that missing data is not allowed for mandatory elements (see above).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value nullFlavor="OTH"/>

<code nullFlavor="UNK"/>

<booleanInd nullFlavor="NI"/>

</syntaxhighlight>

The codes for the ''@nullFlavor'' attribute are drawn from the following hierarchical code system. It is a Coded Simple (CS), which means it has no code system (attribute ''@codeSystem'') specified.

{| class="hl7table"
|+<ref group="Table">NullFlavor</ref> ''NullFlavor''
! Code
! width=15% | Print Name
! Definition / Description
|-
| NI || No Information || No information whatsoever can be inferred from this exceptional value. This is the most general exceptional value. It is also the default exceptional value.
|-
|   OTH || other || The actual value is not an element in the value domain of a variable. (e.g., concept not provided by required code system).
|-
|     NINF || negative infinity || Negative infinity of numbers.
|-
|     PINF || positive infinity || Positive infinity of numbers.
|-
|   UNK || unknown || A proper value is applicable, but not known.
|-
|     ASKU || asked but unknown || Information was sought but not found (e.g., patient was asked but didn't know)
|-
|       NAV || temporarily unavailable || Information is not available at this time but it is expected that it will be available later.
|-
|       NASK || not asked || This information has not been sought (e.g., patient was not asked)
|-
|       TRC || trace || The content is greater than zero, but too small to be quantified.
|-
|   MSK || masked || There is information on this item available but it has not been provided by the sender due to security, privacy or other reasons. There may be an alternate mechanism for gaining access to this information.
Note: using this null flavour does provide information that may be a breach of confidentiality, even though no detail data is provided. Its primary purpose is for those circumstances where it is necessary to inform the receiver that the information does exist without providing any detail.
|-
|   NA || not applicable || No proper value is applicable in this context (e.g., last menstrual period for a male).
|-
| NP || not present || Value is not present in a message. This is only defined in messages, never in application data! All values not present in the message must be replaced by the applicable default, or no-information (NI) as the default of all defaults.
|}

=== ANY as the generic data type ===

This abstract data type is the basis for all other data types. Not a single value within a CDA document has the effective data type ANY, but any data type within HL7v3 is a specialization of ANY. This also means that any other data type inherits all properties of ANY (see [[#Missing_values_.28null_flavor.29|“Missing values (null flavor)”]]).

The ANY type is occasionally found in HL7 models when it comes to clinical finding etc. where – at model time – the actual data type of the value is not known. At instantiation time however, the actual data type ''is'' known and ANY is always replaced by a particular data type in an instance.

One example is the observation value (child element value in an observation), where in the model the data type of value cannot be anticipated. When instantiation is taking place, the data type is specified by the XML instance attribute ''@xsi:type''. This information can be used by the receiver to validate and process the value.

Attributes of an element with this data type are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@nullFlavor''' || <center>CS</center> || <center>–</center> || Classification of the missing value, see [[#Missing_values_.28null_flavor.29|3.3 Missing values (null flavor)]].
|}

{| class="hl7table" style="width:100%"
| width=8% | <center>[[File:Conformance.svg|50px]] dtr1-1-ANY</center> || If there is a ''nullFlavor'', there shall be no other attribute or element, unless it's ''nullFlavor="OTH"''.

In that case ''@codeSystem'' or ''originalText'' (see “code” data types) may have a value.
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">

<value xsi:type="CE" code="N11.9" codeSystem="2.16.840.1.113883.6.3"/>


<value xsi:type="PQ" value="12" unit="mL"/>


<value xsi:type="ED">this is text</value>
</syntaxhighlight>

=== Boolean (BL) ===

Elements of this data type refer to Boolean logic and have an attribute ''@value''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>BL</center> || <center>–</center> || Valued as “true” or “false”
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<negationInd value="false"/>

<deceasedInd value="true"/>

</syntaxhighlight>

In some situations, the BL data does not apply to an XML element, but an attribute. In that case, the attribute carries the Boolean value directly.
<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<support contextConductionInd ="false">
...
</support>
</syntaxhighlight>

=== Instance Identifier (II) ===

This data type identifies instances of classes like observations or entities (persons, organizations). Attributes are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@extension''' || <center>ST</center> || <center>O</center> || Identification
|-
| '''@root''' || <center>OID</center> || <center>R</center> || Source of identification
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id extension="13234453645" root="2.16.840.1.113883.2.6.15.3.427.1"/>
</syntaxhighlight>

The ''@root'' attribute is of type OID (object identifier), a unique identifier of the issuing authority or system. For example, a patient with a patient number 13234453645 created by a specific healthcare provider organization is uniquely identified by the number itself in ''@extension'' and the OID of the organization or the sending system, in the example 2.16.840.1.113883.2.6.15.3.427.1 in ''@root''.

In some cases, a single OID identifies an object uniquely. In that situation, only ''@root'' is populated and ''@extension'' is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Encapsulated Data (ED) ===

Elements of this data type carry multimedia content. The actual multimedia content is represented as element content. There are two situations for the use of ED:

* Inline: The full data is transmitted in the type. This form is mainly used for text.
* By reference: a thumbnail is provided which links to the full data by reference.

In an instance, the data type is normally determined by an ''xsi:type'' specification and some attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@mediaType''' || <center>CS</center> || <center>O</center> || MIME media type classification. At time of writing this specification, the following MIME types are allowed:
* text/plain (plain text)
* text/html (text with html markup)
* image/jpeg (JPEG image)
* application/pdf (a PDF, portable document format)
* application/hl7-sda+xml (CDA documents).
|-
| '''@representation''' || <center>CS</center> || <center>O</center> || Representation of the multimedia content. At time of writing this specification, the following representations are allowed:
* TXT (text, this is the default)
* B64 base 64 encoded data, for example for embedded CDA documents).
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<text xsi:type="ED" mediaType="text/plain">
Patient treated sucessfully
</text>

<text mediaType="application/hl7-sda+xml" representation="B64">PD94bWw..etc..==</text>

</syntaxhighlight>

To include referenced data the two sub elements ''thumbnail'' and ''reference'' are used.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''reference''' || <center>TEL</center> || <center>0..*</center> || <center>O</center> || Link (URI) to full data
|-
| '''thumbnail''' || <center>ED</center> || <center>0..*</center> || <center>O</center> || Thumbnail of referenced data
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value xsi:type="ED" mediaType="image/png" representation="B64">
<reference value="http://radiology.bergen.no/xrays/128s.png"/>
<thumbnail mediaType="image/jpeg" representation="B64"> MNY...83== </thumbnail>
</value>
</syntaxhighlight>

=== Strings (ST) ===

This data type is a specialization of the ED type where ''@mediaType'' is fixed “text/plain” and ''@representation'' is fixed “TXT”. It allows conveying a character string as '''element content'''. This data type is used in other data types it like the ''@extension'' in instance identifiers, or address and person name data type components.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<lotNumber> 143GT6DT </lotNumber>
</syntaxhighlight>

=== Concept Descriptor (CD) ===

This data type specifies a concept by means of a code and its code system (except for situations where no code is available).

A couple of specializations of data type CD exist, which differ in the main characteristics (properties) of the data type that may or may not be supported.

{| class="hl7table" style="width:50%"
|+<ref group="Table">Properties of data types used for codes</ref> ''Properties of data types used for codes''
! <div style="text-align: right">DataType</div> !! CD !! CE !! CV !! CO !! CS
|-
! <div style="text-align: left">Property</div> !! !! !! !! !!
|-
| '''@code''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||<center>X</center>
|-
| '''@codeSystem''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''@codeSystemVersion''' || <center>X</center> || <center>X</center> || <center>X</center>|| <center>X</center> ||
|-
| '''@displayName''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''originalText''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''translation''' || <center>X</center> || <center>X</center> || || ||
|-
| '''qualifier''' || <center>X</center> || || || ||
|}

Because the CE variant is most used in practice, the general explanation of the properties will be given with de description of CE (see below).

The only attribute that is unique to CD is briefly explained here.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@qualifier''' || <center>CR</center> || <center>O</center> || An additional qualifier for the code.
|}

Complex terminologies like SNOMED CT can be used only using data type CD.

=== Coded with Equivalents (CE) ===

With elements of this data type, a concept by means of a code and its coding system (except for situations where no code is available) can be specified. It optionally contains one or more equivalents using other code systems.

It may contain the following attributes:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@code''' || <center>ST</center> || <center>R</center> || The actual code
|-
| '''@codeSystem''' || <center>OID</center> || <center>R</center> || required to identify the code system were the code is drawn from. This is an OID (object identifier, see [[#Object_Identifiers_.28OIDs.29|Object Identifiers at 4.1]])
|-
| '''@displayName''' || <center>ST</center> || <center>O</center> || Optional textual representation of code. A display name may be specified representing the plain text of the code. The information of this attribute may not be used by the receiving system for interpretation, but only for display purposes. The display name may never be transmitted without a code and must have the same meaning as the code.
|-
| '''@codeSystemName''' || <center>ST</center> || <center>O</center> || A textual representation of the name of the code system
|-
| '''@codeSystemVersion''' || <center>ST</center> || <center>O</center> || A textual representation of the version of the code system
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"/>

<code code="AU" codeSystem="2.16.840.1.113883.5.33"/>

<storageCode code="AC" codeSystem="2.16.840.1.113883.5.34" displayName="active"/>

<code code="A45.0" displayName="Somatisierungsstörung" codeSystem="1.2.276.0.76.5.409" codeSystemName="ICD-10 GM 2012"/>
</syntaxhighlight>

There are some child elements of codes that can be used to express what the “original text” was that was used for the coding or to indicate that there are “translations” to other code systems than the primary code.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''originalText''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Textual representation of the concept, actually a description which was used to create the actual code
|}

No semantics may be assumed other than showing the ''@displayName'' to a user to clarify the code. A display name cannot occur without its code and must carry the same meaning.

In case no code is known, it is allowed to specify a ''@nullFlavor'' for the code element and to give information about the (not yet coded) concept in original text. However, this should be an exception.

If other codes than the primary code need to be conveyed adding a translation child element can be used.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<originalText>minor aphthous stomatitis</originalText>
</code>
</syntaxhighlight>

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''translation''' || <center>CD</center> || <center>0..*</center> || <center>O</center> || Alternative code(s)
|}

A ''translation'' element is also of type CD and shall have a code and a code system identified. It shall point to the same concept as the primary code. It is allowed that a translation conveys less conceptual details than the original code.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<translation code="528.2" codeSystem="2.16.840.1.113883.6.2" codeSystemName="ICD9" displayName="Oral aphthae"/>
</code>
</syntaxhighlight>

=== Coded Value (CV) ===

This is actually a specialization of CE (see above), with the exception that neither ''originalText'' nor ''translation'' child element are allowed.

=== Coded Simple Value (CS) ===

This is actually a specialization of CE (see above), with no code system attribute and no original text or translation child element allowed. It specifies a concept by means of a code from a ''predefined'' code system (table) where the code is drawn from. This data type is usually applied in the context of fixed predefined HL7 tables.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<statusCode code="completed"/>
</syntaxhighlight>

In this example ''statusCode'' is bound in the underlying model to the specific code system ''ActStatus''. Because it is predefined by means of the vocabulary binding, ''@codeSystem'' is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Telecommunication Address (TEL) ===

Elements of this type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>ST</center> || <center>R</center> || carries strings that represent telecommunication contact information
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

The actual data is preceded by the scheme (refer to Internet Standard “RFC 1738 Uniform Resource Locators (URL)” <ref>RFC 1738 Uniform Resource Locators (URL): http://www.ietf.org/rfc/rfc1738.txt</ref>.

Examples:
* telephone (tel:),
* fax (fax:),
* email (mailto:).

It must follow the rules defined in Internet “RFC 2806 URLs for Telephone Calls” <ref>RFC 2806 URLs for Telephone Calls: http://www.ietf.org/rfc/rfc2806.txt</ref>.

The following codes will be used in the “use” attribute:
* H – Home
* WP – Work
* MC can be used (in addition to H or WP) to denote that this is a mobile phone.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257" />

<telecom use="H" value="tel:55354257" />

<telecom use="H" value="fax:56542558" />

<telecom value="tel:+41.34.21.4765342"/>

<telecom value="mailto:opr@opr-sem.no"/>

<telecom use="WP MC" value="tel:97555786" />
</syntaxhighlight>

It is possible to express the useable period of a telecommunication contact. A child element ''useablePeriod'' is used as a time interval to indicate this period.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''useablePeriod''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257">
<useablePeriod>
<high value="20111201"/>
</useablePeriod>
</telecom>
</syntaxhighlight>

=== Postal Address (AD) ===

Elements of this data type have a substructure in order to represent a structured address specification. In this implementation guide only a selection of all possible child elements is allowed, the original HL7 specification is richer.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''streetAddressLine''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Street address, includes street name and house number
|-
| '''city''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || City
|-
| '''postalCode''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Postal code
|-
| '''country''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Country
|-
|}

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that the sequence of the sub elements is country specific, i.e. it has to follow “common” rules how to write an address. For example, an UK address and a German address have different sequences of address representation.
|}

A ''@use'' attribute can also be specified.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="WP">
<streetAddressLine>Anna-Louisa-Karsch-Str. 2</streetAddressLine>
<postalCode>10178</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="H WP">
<streetAddressLine>Tatungasse 34</streetAddressLine>
<postalCode>10825</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

Also, a country may be specified using the element ''country''.

=== Person Name (PN) ===

Elements of this data type do also have a substructure to represent the parts of a person name, like family or given name and prefixes.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>
<given>Franz</given>
<given>Ingrun</given>
<family>Nordmann</family>
</name>
</syntaxhighlight>

Previous or birth or maiden names are supported using the ''validTime'' element. ''validTime'' (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]]) specifies the validity range of the name.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">

<name>
<given>Jan</given>
<given>Olaf</given>
<family>Hendrikson</family>
<validTime>
<high value="20000101"/>
</validTime>
</name>
</syntaxhighlight>

Note that the name attribute is repeating, i.e. multiple (types of) names could be sent. It is up to the receiver (based on the value of the ''@use'' attribute, and ''validTime'') to decide what name it wants to use or import in its database.

=== Organisation Name (ON) ===

Elements of this data type represent a name of an organization.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name> Charité Berlin </name>
</syntaxhighlight>

The optional ''validTime'' element (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]] may be used to specify the validity range of the name of the organization.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name of the organization
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>The old hospital
<validTime>
<high value="20111231235959"/>
</validTime>
</name>
</syntaxhighlight>

Please note that the use of ''validTime'' yields XML mixed content which should be avoided if possible.

=== Integer Number (INT) ===

Elements of this data type are used to specify integer numbers and have one attribute.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>int</center> || <center>R</center> || Integer value
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<sequenceNumber value="24"/>
</syntaxhighlight>

=== Physical Quantities (PQ) ===

Elements of this data type are physical quantities, i.e. a measurable quantity (or countable) value from the physical world. This is different from just a “number”, because there is a (natural) unit specified in which the measurable quantity is expressed.
Examples:
* an amount of blood 20 ml (sample volume)
* a cut with a length of 10 cm (result observation)
* a dose of 200 milligrams per administration (dosing)
* delivery of 60 pieces of a tablet (amount supplied).
Elements of this data type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>real</center> || <center>R</center> || value of the measurement
|-
| '''@unit''' || <center>CS</center> || <center>R</center> || unit of measurement
|}

In the unit of measurement unit is expressed following the ''Unified Code for Units of Measure'' (UCUM) specification. This specification is a collection of atomic units, prefixes and a corresponding grammar for valid combinations to build all-natural units of measurement. For a complete description of possible units, see the ''Unified Code for Units of Measure'' <ref>Unified Code for Units of Measure: http://unitsofmeasure.org/</ref> specification.

If a value is not countable or if measurable, for example expressed in milligrams or liters, then this unit is a valid UCUM unit like “mg” or “L”. If a value is countable, for example the number of tablets, then this attribute contains “1”.

In HL7 it is required that all PQ data type units are valid UCUM units.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<value value="165" unit="cm"/>

<value value="81.1" unit="kg"/>

<value value="120" unit="mm[Hg]"/>

<value value="5" unit="1"/>
</syntaxhighlight>

=== Point in Time (TS) ===

Elements of this data type have the attribute

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>TS</center> || <center>R</center> || Point in time
|}

and specify points in time in the format YYYYMMDDhhmmss±ZZZZ, where
* YYYY is the four-digit year,
* MM the two-digit month,
* DD the two-digit day,
* hh the two-digit hour,
* mm the two-digits minute and
* ss the two-digit second.
Optional a time zone ZZZZ, the four-digit time alignment with a preceding “-” or a “+” can be specified. If time zone is omitted, local time is assumed.

The point in time may be right truncated in respect to the precision of the information.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<effectiveTime value="20140412"/>

<effectiveTime value="201409091245"/>

<effectiveTime value="1996"/>

<birthTime value="19540714"/>

<effectiveTime value="20140412+0100"/>
</syntaxhighlight>

=== Intervals (IVL) ===

Intervals are defined only for data types with an ordinal or interval scale type. There are several possibilities to determine an interval (see Figure 2), for example to specify

* a lower <low> and an upper boundary <high> (a),
* a lower <low> boundary and width <width> (b)
* an upper boundary and width <width> (c) or
* the middle of the interval <nowiki><center></nowiki> and a width <width> (d).

[[File:CDA_Core_Principles_Figure_2_Determining_Intervals.png|700px]]

<ref group="Figure">Several possibilities to determine closed intervals</ref> ''Several possibilities to determine closed intervals''

In addition, there is sometimes the need to specify incomplete intervals (open intervals). For example, an interval with only an upper limit to indicate a maximum dose or a start date and time only to express “since…”.

{{ConstraintBox|
To indicate an interval, only the following combinations are permitted.
(1) A lower and an upper boundary may not be identical, and their accuracy has to be equal.

Correct examples:

{{BeginGreenBox|}}
Interval from 5 to 6
Interval from 20110607 until 20110612
{{EndGreenBox}}

Incorrect examples:

{{BeginRedBox|}}
Interval from 5 to 6.0
Interval from 20110101 to 2011
{{EndRedBox|}}

(2) A lower boundary and a width

(3) A lower limit boundary

(4) A upper limit boundary

(5) Only the middle of the interval

(6) Only the width of an interval}}

Accordingly, four child elements are available.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Lower boundary
|-
| '''high''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Upper boundary
|-
| '''center''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Where ''(T)'' is defined in this specification as one of the data types “TS” or “PQ”.

=== Interval of time (IVL_TS) ===

Elements of this data type represent time intervals. There are four possible child elements.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Lower boundary (start date/time)
|-
| '''high''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Upper boundary (end date/time)
|-
| '''center''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Normally, a lower and an upper boundary is given, both are points in time. Also, it is possible to specify open intervals like “since June 14, 1999” (left boundary given only) or “until September 24, 2006” (right boundary given).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110507"/>
<high value="20110909"/>
</effectiveTime>

<effectiveTime>
<low value="20110507"/>
</effectiveTime>

<value>
<low value="20110101"/>
<width value="120" unit="d"/>
</value>

<value>
<center value="20110101"/>
</value>
</syntaxhighlight>

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|It must be noted that intervals of time stamps in HL7 are equally treated as other interval types (e.g. integers). The statement, one may take 1–3 tablets (interval of integers), for example, says that you are allowed to take no more than three tablets, not 3½ or 3.5 tablets. On the other hand, when treat the words “until 12 June 2011” regarding the upper interval limit differently, particularly we assume that the entire day 12 June is still included in this time interval.

Thus, in human perception time intervals are handled differently compared to such as number intervals. This is a situation may lead to inconsistencies in standardized communication. As a conclusion, an upper limit “12 June 2011” means that only the very first moment of the 12 June is included in the interval, but not, for example, the 12 June 13:00 hours.

Interpretation does not depend on the accuracy of the time:
* “after 2004” means “from January 1, 2005 00:00:00.000”,
* “after 20041201” means “from 2 December 2004 00:00:00.000 hours”,
* and “after 200412011200” means “from 1 December 2004 12:01:00.000”.

As a result, you have to carefully consider the specification and implemen-tation of time intervals upper boundaries. In order to prevent mis-understandings intervals are always specified with the date and time for an upper limit that would cover the whole day. Accordingly, “201106122359” means 12 June 2011 throughout the day.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="201106122359"/>
</effectiveTime>
</syntaxhighlight>

Because of the equal treatment of time intervals this is applied also to the lower limit boundaries of time intervals as “0000”. This means for example that “since 9 June 2011” is expressed as “201106090000”.
|}

The <width> element is of data type PQ (physical quantity). The value obviously shall relate to a period of time and it is required to include a “time” unit. These are the units “us” (microseconds), “ms” (milliseconds), “s” (seconds), “min” (minute), “h” (hours), “d” (day), “wk” (week), “mo” (month) and “a” (year).

{{ConstraintBox|
For interval of time stamps the @unit of a ''low'' or ''high'' child element shall use units
* us (microseconds),
* ms (milliseconds),
* s (seconds),
* min (minute),
* h (hours),
* d (day),
* wk (week),
* mo (month) or
* a (year).
}}

=== Interval of physical quantities (IVL_PQ) ===

Elements of this data type are used to indicate intervals of physical quantities (see also [[#Physical Quantities (PQ)|3.18 Physical Quantities (PQ)]]). In general, an upper and a lower boundary is specified. It is also possible to use ''center'' instead of ''low'' and ''high''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low || <center>TS</center> || <center>0..1</center> || <center>C</center> || the lower limit of the interval (i.e. the minimum amount).
|-
| '''high || <center>TS</center> || <center>0..1</center> || <center>C</center> || the upper limit of the interval (i.e. the maximum amount).
|-
| '''center || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of the interval
|}

The ''center'' child element is used when there is no interval, but an exact value. Alternative would be to demote IVL_PQ to data type PQ and populate the element’s ''@value'' attribute, but this is more difficult to process in XML. That is why the use of the ''center'' child element is deprecated.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<referenceRange>
<low value="7.5" unit="mmol/l"/>
<high value="10" unit="mmol/l"/>
</referenceRange>

<doseQuantity>
<center value="9" unit="1"/>
</doseQuantity>
</syntaxhighlight>

=== Ratio of quantities (RTO_QTY_QTY) ===

Elements of this data type specify ratios and have two child elements, a numerator and a denominator. The underlying QTY (Quantity) data type is an abstract data type and in a XML instance it has to be replaced by a specific data type using the ''@xsi:type'' instruction (see below).

In this specification only “PQ” or “INT” are allowed for the demotion of both ''numerator'' and ''denominator''. The relevant child elements are:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''numerator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the numerator of the ratio
|-
| '''denominator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the denominator of the ratio
|}

If a model attribute already is a RTO_QTY_QTY, you need to specify (demote) the OTY abstract data type for both ''numerator'' and ''denominator'' by using an ''@xsi:type'' instruction.
In some cases where the model attribute is of type “ANY”, also the root element shall carry an ''@xsi:type'' RTO_QTY_QTY instruction.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<maxDoseQuantity>
<numerator xsi:type="PQ" value="6"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="400" unit="mg"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="5"/>
<denominator xsi:type="PQ" value="1" unit="h"/>
</maxDoseQuantity>

<value xsi:type="RTO_QTY_QTY">
<numerator xsi:type="INT" value="1"/>
<denominator xsi:type="INT" value="10000"/>
</value>
</syntaxhighlight>

== Identification mechanisms ==

=== Object Identifiers (OIDs) ===

Standardized exchange of information using messages or documents also deals with unique identifications of objects and concepts, especially in environments where sender and receiver do not “know” each other necessarily.

It is important to understand the difference between identification of instances (ids) and code concepts (classifications). Within the context of HL7 interactions OIDs are quite often used.

An id points to a specific instance of an object or identification scheme (a particular methodology for the identification of a class of objects), for example a specific person as the patient or a physician, a specific lab observation or an X-ray photo.

In contrast to instance identifiers, a classification identifies a specific concept. The type of patient (inpatient, outpatient), the type of doctor (an anesthesiologist), the codes for gender or a lab observation (blood cell count) may serve as examples.

OIDs (object identifiers) are worldwide unique identifiers for objects. They are used in HL7 to specify identifications and classifications. An object in this sense is persistent, well-defined information, definitions or specifications and is represented with ids or codes.

Commonly used OIDs (i.e. used for a purpose that is wider in scope than the regional healthcare organization; used in communications between healthcare regions) can be found in OIDs registries such as

* [http://www.oid-info.com www.oid-info.com],
* [http://www.hl7.org www.hl7.org],
* [http://www.hl7.org.uk/version3group/oids.asp HL7 OID registry in the UK],
* [https://www.dimdi.de/dynamic/de/klassifikationen/weitere-klassifikationen-und-standards/oid/ OID registry Germany].

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|All OIDs with an element of 999 or 9999 are for documentation purposes only. They will be replaced by permanent OIDs once these have been assigned/found/applied for.
|}

OID (Object Identifiers) are unique identifiers for any kind of objects. They are defined in Rec. ITU-T X.660 | ISO/IEC 9834-1. This identification system for objects and concepts makes reliable electronic information exchange possible. Administration and Registration is regulated by a set of rules, described in the corresponding chapter of this document.

Every artefact in ART-DECOR has an Object Identifier (OID). There are recommendations for the management and the exchange of Object Identifiers, partially defined in ISO TS 13582 <ref>ISO TS 13582: https://www.iso.org/standard/69652.html</ref>.

''HL7 International'' has created a type ontology for the OIDs in the HL7 registry to make it easier for the user community to search for OIDs they may be looking for and can be found at hl7.org.

From a policy perspective it is common practice in several healthcare related OID registries (HL7 International at http://www.hl7.org, OID Registry Germany at http://www.dimdi.de, OID registry Switzerland at http://oid.refdata.ch, and OID registry Austria at https://www.gesundheit.gv.at/OID_Frontend) to distinguish at least between the following types of OIDs:

{| class="hl7table" style="width:50%"
|+<ref group="Table">Recommended OID sub-branches for different artefacts</ref> ''Recommended OID sub-branches for different artefacts''
! Arc !! Description
|-
| .3 || organizational bodies and groups
|-
| .4 || identifier systems and namespaces
|-
| .5 || code systems
|-
| .7 || document artefacts
|-
| .9 || conformance profiles
|-
| .10 || templates
|-
| .11 || value sets
|-
| .19 || examples
|-
| .99 || experimental
|}

''Example: given that “your” root OID is 1.2.3.4.5, the first value set of your governance group is then to be 1.2.3.4.5.11.1, with .11 as the value set “branch” and the last .1 as the first artefact of that kind.''

In ART-DECOR a project typically is set into the .77 branch of a governance group. When setting up the project, the OID for that project also determines the artefact OIDs using throughout the ART-DECOR project. The following additional branches are used to distinguish between different OID types:

{| class="hl7table" style="width:50%"
|+<ref group="Table">Recommended OID sub-branches for ART-DECOR projects</ref> ''Recommended OID sub-branches for ART-DECOR projects''
! Artefact code !! Description !! Recommended OID suffix
|-
| DS || dataset || .77.1
|-
| DE || dataset concept || .77.2
|-
| SC || scenario || .77.3
|-
| TR || transaction in scenario || .77.4
|-
| CS || code system || .77.5
|-
| IS || issue || .77.6
|-
| AC || actor in scenario || .77.7
|-
| CL || concept list in dataset || .77.8
|-
| EL || element in template || .77.9
|-
| TM || template || .77.10
|-
| VS || value set || .77.11
|-
| RL || rule for instances || .77.12
|-
| SX || test/example scenario || .77.18
|-
| EX || test/example instance || .77.19
|-
| QX || qualification test/example || .77.20
|-
| TX || test/example data element || .77.21
|-
| CM || community || .77.22
|-
| MP || concept map || .77.24
|}

In ART-DECOR a newly created project uses these OID branches automatically.

=== Instance identification ===

Instance identification is done with the id element of a class. Its type is II (instance identifier) and described in the data type section above. For example, a patient number can be represented as
* 2.16.578.1.34.1.5432.1, the root-OID of the issuing authority, for example a system/application in a hospital, and
* 67543242 as the ''@extension'', representing the patient number within the system defined by the ''@root'' attribute.

=== Coding scheme identification ===

Coding schemes have to be uniquely identified using OIDs as well. All coding tables used in this implementation guide show the corresponding OID that has to be specified in the ''@codeSystem'' attribute of coded elements. Both attributes ''@code'' and ''@codeSystem'' together allows a correct interpretation of concept and code.

=== List of identification schemes ===

The following are OIDs for commonly used identification schemes.

{| class="hl7table"
|+<ref group="Table">Commonly used identification scheme OIDs</ref> ''Commonly used identification scheme OIDs''
! OID !! Identification System Name !! Description !! Issuer
|-
| 1.2.276.0.76.4.8 || KV-Nummer || Krankenversichertennummer ||
|-
| 1.2.276.0.76.4.17 || BSNR || Betriebsstättennummer ||
|-
| 1.2.276.0.76.4.16 || LANR || lebenslange Arztnummer ||
|}

=== List of code systems ===

The following are OIDs for code systems.

{| class="hl7table"
|+<ref group="Table">Commonly used code system OIDs</ref> ''Commonly used code system OIDs''
! OID !! Code System Name !! Description !! Issuer
|-
| 2.16.840.1.113883.6.1 || LOINC || Logical Observation Identifiers Names and Codes (LOINC) || Regenstrief Institute
|-
| 2.16.840.1.113883.6.96 || SNOMED CT || Systemized Nomenclature in Medicine Reference Terminology (SNOMED CT) || SNOMED International
|-
| 1.0.3166.1.2 || ISO 3166-1 (second edition) || Country codes as per ISO 3166-1:2007 || ISO
|}

== Vocabulary ==

=== Code Systems ===

Within HL7, a ''Code System'' is defined as a collection of codes with associated designations and meanings. Examples of code systems include ICD-10, SNOMED CT, and LOINC.

To meet the requirements of a code system as defined by HL7, a given code must resolve to one and only one meaning within the code system. Given this definition, each code table in the HL7 Version 3 standard represents a different code system since codes are sometimes used in different tables to have different meanings.

For example, “M” in the administrative gender table (''AdministrativeGender'', OID 2.16.840.1.113883.5.1) means “male”, while “M” in the marital status table (''MaritalStatus'', OID 2.16.840.1.113883.5.2) means “married”.

In this specification, code system tables are not presented in detail.

=== Value Sets ===

A ''Value Set'' represents a uniquely identifiable set of valid concept representations, where any concept representation can be tested to determine whether or not it is a member of the value set.
Value set complexity may range from a simple flat list of concept codes drawn from a single code system, to an unbounded hierarchical set of possibly post-coordinated expressions drawn from multiple code systems.
Value sets exist to constrain the content for a coded element in an HL7 static model or data type property. Value sets cannot have null content and must contain at least one concept representation where any given concept is generally (but not required to be) represented by only a single code within the Value Set.

[[File:CDA_Core_Principles_Figure_3_ValueSet_Example.png|800px]]

<ref group="Figure">Example presentation of the value set “MaritalStatus”</ref> ''Example presentation of the value set “MaritalStatus”''

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that value set OIDs never appear in a CDA Release 2 document. They are used for constraint expressions, for example in implementation guides.
In order to send a specific code drawn from a value set, the corresponding code system has to be conveyed.
An example, in the implementation specification the constraint on the model element ''maritalStatusCode'' is expressed as “to be drawn from value set 2.16.840.1.113883.5.2 ''MaritalStatus''”.
To actually send a marital status of “M” (married) that is shown in the value set figure above, the corresponding HL7 CDA instance would say:
<syntaxhighlight lang="xml">
<maritalStatusCode code="M" codeSystem="2.16.840.1.113883.5.2"/>
</syntaxhighlight>
|}

In this specification, value set tables are not presented in detail.

==== Binding strength ====

There is an optional vocabulary strength for data types that support that feature (coded concepts). Examples include CD, CE, CV and CO. Values are required, extensible, preferred and example. Default is required.

Please note: the formerly supported values CNE (Coded No Extensibility) and CWE (Coded With Extensibility) in ART-DECOR are deprecated as of December 2017. Specification CNE is handled as required and CWE is handled as extensible.

{| class="hl7table"
|+<ref group="Table">Binding Strengths</ref> ''Binding Strengths''
! Strength !! Description
|-
|required||Required/CNE. Coded with no exceptions; this element SHALL be from the specified value set
|-
|extensible||Extensible/CWE. Coded with Exceptions; this element SHALL be from the specified value set if any of the codes within the value set can apply to the concept being communicated. If the value set does not cover the concept (based on human review), alternate codings (or, data type allowing, text) may be included instead.
|-
|preferred||Preferred. Instances are encouraged to draw from the specified codes for interoperability purposes but are not required to do so to be considered conformant.
|-
|example||Example. Instances are not expected or even encouraged to draw from the specified value set. The value set merely provides examples of the types of concepts intended to be included.
|}

Mismatches with required lead to validation errors (SHALL logic). Mismatches with extensible lead to validation warnings (SHOULD logic). Mismatches with preferred lead to validation information messages (MAY logic). Mismatches with example don't have any validation consequences.

== Appendix ==

=== References ===

<references/>

=== List of figures ===

<references group="Figure" />

=== List of tables ===

<references group="Table" />

HL7 CDA Core Principles

2019-06-16T11:25:24Z

Dammon: /* Object Identifiers (OIDs) */

== Introduction ==

This implementation guide specifies the ''Core Principles'' of using the ''Clinical Document Architecture'' <ref>Clinical Document Architecture Release 2: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=7</ref>.

=== Scope ===

This guide focuses on ''Data Types Release 1'' <ref>HL7 Data Types Release 1: http://www.hl7.org</ref>. Meanwhile an ISO specification ISO 21090 is out, also known as Data Type Release 2. The latter is subject to another implementation guide that will be published when ISO data types are used.

=== Focus of this document: HL7 Version 3 Data Types for CDA ===

The following chapters of this document will focus on the description of the data types and associated material. It will highlight the essentials in four chapters, all focusing on the Norwegian situation.
* '''Common aspects:''' explains common aspects of use of CDA and XML
* '''Data types:''' gives an overview and detailed specification of all data types used in CDA
* '''Identification schemes:''' explains major aspects of identification and the use in CDA
* '''Use of vocabulary:''' explains major aspects of vocabulary use in CDA.

=== Background ===

In many (European) countries, implementation guides for the use of data types in HL7 V3 are published. They take into account country specific constraints on the data types.

=== Legend of symbols ===

In this document several symbols are used.

{| class="hl7table" style="width:50%"
| [[File:Pfeil_rechts.png|50px]] || This is an important item
|-
| [[File:Issue.svg|50px]] || This is a known open issue
|-
| [[File:Faq.svg|50px]] || This is a frequently asked question (FAQ) with answer
|-
| [[File:Conformance.svg|50px]] || This is a constraint; in some situations also the rule identification is specified, e.g. dtr1-1-ANY, which links to the corresponding validation rule.
|}

=== Version history ===

{| class="hl7table" style="width:50%"
|+
! Version !! Date !! Description !! Author
|-
| 1.1 || 2019-04-24 || Refurbished guide based on earlier work || Kai U. Heitmann
|}

== Common aspects ==

=== Use of XML ===

HL7 Version 3 CDA uses the Extensible Markup Language (XML) as the exchange format. It is assumed that the reader is familiar with common XML aspects. However, some constraints are made regarding the use of CDA.

==== Character Set ====

{{ConstraintBox|
The character encoding of any CDA document shall be “UTF-8”.}}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="utf-8"?>
</syntaxhighlight>

=== CDA document structure ===

The XML namespace for CDA Release 2 documents is ''<nowiki>urn:hl7-org:v3</nowiki>''. This must be correctly mentioned in every XML instance.

CDA XML documents starts with the root element ''ClinicalDocument''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">


...

<component>
<structuredBody>
...
</structuredBody>
</component>

</ClinicalDocument>
</syntaxhighlight>

== Data types ==

=== Introduction ===

The following chapter describes the typical data types used in CDA implementation guides. For further information please refer to the HL7 V3 standard and its two parts concerning data types:
* Abstract Data type definition <ref>HL7 Version 3 Abstract Data type definition: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=264</ref>
* XML ITS for data types <ref>XML ITS for data types: https://www.hl7.org/documentcenter/public_temp_682D4D16-1C23-BA17-0C789BA52BEDB68E/wg/inm/datatypes-its-xml20050714.htm</ref>
Data types are properties of model class attributes and the basic building blocks of information in a CDA XML instance. For example, a model attribute named “time” has as its data type a time stamp “TS” (see Figure 1).

[[File:CDA_Core_Principles_Figure_1_CDA_Structure_Data_Types.png|700px]]

<ref group="Figure">CDA structure (left) and the data type specification (right)</ref> ''CDA structure (left) and the data type specification (right)''

=== XML representation of data types ===

Actual data is mostly carried in HL7 Version 3 by populating XML attributes and not as element content. Exceptions are names of persons and organizations as well as addresses.

The XML elements have names like the model attributes. For example, a model attribute “id” has a corresponding XML element named <id…>. The model determines the sequence of elements and their hierarchy. The data type itself determines the XML attributes within the start tag. The notation here is as follows:

{| class="hl7table"
|+
! Attribute !! DT !! Conf !! Description
|-
| (name of the model attribute or XML element) || Data type || Conformance, i.e. O, R, M || Textual description
|}

XML attributes (data type properties) are denoted as ''@attribute'' in order to distinguish their names from XML elements.

Example: in the example model above, the data type of the ''id'' attribute's is ''II'' (Instance Identifier). The corresponding XML attributes for that data type include ''@root'' and ''@extension''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id root="..." extension="..." />
</syntaxhighlight>

A description of the data types and their corresponding XML representation is contained in subsequent paragraphs of this guide.

==== Exceptions using XML element content ====

For most data types, the actual data is conveyed in XML attributes. However, there are some exceptions. For the data types binary (BIN), Encapsulated Data (ED), Entity Name (EN), Person Name (PN), Organization Name (ON), Trivial Name (TN), Address (AD) and character string data (ST), information is carried as element content.

Example: the components of an address <addr> are represented by sub elements with the data as element content (in the example shown in black).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr>
<streetAddressLine>Thormøhlens gate 12</streetAddressLine>
<postalCode>5006</postalCode>
<city>Bergen</city>
</addr>
</syntaxhighlight>

==== Combined data types ====

There are a number of so-called combined data types. For example, an interval with a lower and upper limit and a ratio that has a nominator and a denominator value.

In combined data types the substructure (e.g. <low> <high> in an interval) are represented as child elements of the relevant data type element.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110701"/>
<high value="20110729"/>
</effectiveTime>
</syntaxhighlight>

==== Conformance information ====

The conformance indicators distinguish kinds of conformance information described shortly here.

* '''O''': An optional item may be omitted if no data is present, i.e. no corresponding XML attribute or element is sent (marked as “O”)
* '''R''': For required items, lower cardinality is always zero or 1.
** Elements must be present and populated with data if present in the sending system. If no data is available (yet), a null flavor (see below) indicates and possibly classifies the missing information (marked as R).
** Attribute flagged as required must be present in the instance and populated.
* '''M''': For mandatory elements data must be sent and no missing values are allowed, i.e. if the sending system does not have information for mandatory elements the XML instance cannot be created and sent (marked as M).
* '''NP''': no data may be present at all (not permitted)
* '''C''': conditional conformance; typically a conformance table shows the circumstances (conditions) derived from information in the instance and the corresponding cardinalities and conformance statements.

=== Missing values (null flavor) ===

For every data type it is possible to specify a missing value including a kind of reason why data is missing. Instead of specifying any attribute of the corresponding element, a ''@nullFlavor'' attribute expresses the omission of data. Note that missing data is not allowed for mandatory elements (see above).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value nullFlavor="OTH"/>

<code nullFlavor="UNK"/>

<booleanInd nullFlavor="NI"/>

</syntaxhighlight>

The codes for the ''@nullFlavor'' attribute are drawn from the following hierarchical code system. It is a Coded Simple (CS), which means it has no code system (attribute ''@codeSystem'') specified.

{| class="hl7table"
|+<ref group="Table">NullFlavor</ref> ''NullFlavor''
! Code
! width=15% | Print Name
! Definition / Description
|-
| NI || No Information || No information whatsoever can be inferred from this exceptional value. This is the most general exceptional value. It is also the default exceptional value.
|-
|   OTH || other || The actual value is not an element in the value domain of a variable. (e.g., concept not provided by required code system).
|-
|     NINF || negative infinity || Negative infinity of numbers.
|-
|     PINF || positive infinity || Positive infinity of numbers.
|-
|   UNK || unknown || A proper value is applicable, but not known.
|-
|     ASKU || asked but unknown || Information was sought but not found (e.g., patient was asked but didn't know)
|-
|       NAV || temporarily unavailable || Information is not available at this time but it is expected that it will be available later.
|-
|       NASK || not asked || This information has not been sought (e.g., patient was not asked)
|-
|       TRC || trace || The content is greater than zero, but too small to be quantified.
|-
|   MSK || masked || There is information on this item available but it has not been provided by the sender due to security, privacy or other reasons. There may be an alternate mechanism for gaining access to this information.
Note: using this null flavour does provide information that may be a breach of confidentiality, even though no detail data is provided. Its primary purpose is for those circumstances where it is necessary to inform the receiver that the information does exist without providing any detail.
|-
|   NA || not applicable || No proper value is applicable in this context (e.g., last menstrual period for a male).
|-
| NP || not present || Value is not present in a message. This is only defined in messages, never in application data! All values not present in the message must be replaced by the applicable default, or no-information (NI) as the default of all defaults.
|}

=== ANY as the generic data type ===

This abstract data type is the basis for all other data types. Not a single value within a CDA document has the effective data type ANY, but any data type within HL7v3 is a specialization of ANY. This also means that any other data type inherits all properties of ANY (see [[#Missing_values_.28null_flavor.29|“Missing values (null flavor)”]]).

The ANY type is occasionally found in HL7 models when it comes to clinical finding etc. where – at model time – the actual data type of the value is not known. At instantiation time however, the actual data type ''is'' known and ANY is always replaced by a particular data type in an instance.

One example is the observation value (child element value in an observation), where in the model the data type of value cannot be anticipated. When instantiation is taking place, the data type is specified by the XML instance attribute ''@xsi:type''. This information can be used by the receiver to validate and process the value.

Attributes of an element with this data type are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@nullFlavor''' || <center>CS</center> || <center>–</center> || Classification of the missing value, see [[#Missing_values_.28null_flavor.29|3.3 Missing values (null flavor)]].
|}

{| class="hl7table" style="width:100%"
| width=8% | <center>[[File:Conformance.svg|50px]] dtr1-1-ANY</center> || If there is a ''nullFlavor'', there shall be no other attribute or element, unless it's ''nullFlavor="OTH"''.

In that case ''@codeSystem'' or ''originalText'' (see “code” data types) may have a value.
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">

<value xsi:type="CE" code="N11.9" codeSystem="2.16.840.1.113883.6.3"/>


<value xsi:type="PQ" value="12" unit="mL"/>


<value xsi:type="ED">this is text</value>
</syntaxhighlight>

=== Boolean (BL) ===

Elements of this data type refer to Boolean logic and have an attribute ''@value''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>BL</center> || <center>–</center> || Valued as “true” or “false”
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<negationInd value="false"/>

<deceasedInd value="true"/>

</syntaxhighlight>

In some situations, the BL data does not apply to an XML element, but an attribute. In that case, the attribute carries the Boolean value directly.
<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<support contextConductionInd ="false">
...
</support>
</syntaxhighlight>

=== Instance Identifier (II) ===

This data type identifies instances of classes like observations or entities (persons, organizations). Attributes are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@extension''' || <center>ST</center> || <center>O</center> || Identification
|-
| '''@root''' || <center>OID</center> || <center>R</center> || Source of identification
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id extension="13234453645" root="2.16.840.1.113883.2.6.15.3.427.1"/>
</syntaxhighlight>

The ''@root'' attribute is of type OID (object identifier), a unique identifier of the issuing authority or system. For example, a patient with a patient number 13234453645 created by a specific healthcare provider organization is uniquely identified by the number itself in ''@extension'' and the OID of the organization or the sending system, in the example 2.16.840.1.113883.2.6.15.3.427.1 in ''@root''.

In some cases, a single OID identifies an object uniquely. In that situation, only ''@root'' is populated and ''@extension'' is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Encapsulated Data (ED) ===

Elements of this data type carry multimedia content. The actual multimedia content is represented as element content. There are two situations for the use of ED:

* Inline: The full data is transmitted in the type. This form is mainly used for text.
* By reference: a thumbnail is provided which links to the full data by reference.

In an instance, the data type is normally determined by an ''xsi:type'' specification and some attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@mediaType''' || <center>CS</center> || <center>O</center> || MIME media type classification. At time of writing this specification, the following MIME types are allowed:
* text/plain (plain text)
* text/html (text with html markup)
* image/jpeg (JPEG image)
* application/pdf (a PDF, portable document format)
* application/hl7-sda+xml (CDA documents).
|-
| '''@representation''' || <center>CS</center> || <center>O</center> || Representation of the multimedia content. At time of writing this specification, the following representations are allowed:
* TXT (text, this is the default)
* B64 base 64 encoded data, for example for embedded CDA documents).
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<text xsi:type="ED" mediaType="text/plain">
Patient treated sucessfully
</text>

<text mediaType="application/hl7-sda+xml" representation="B64">PD94bWw..etc..==</text>

</syntaxhighlight>

To include referenced data the two sub elements ''thumbnail'' and ''reference'' are used.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''reference''' || <center>TEL</center> || <center>0..*</center> || <center>O</center> || Link (URI) to full data
|-
| '''thumbnail''' || <center>ED</center> || <center>0..*</center> || <center>O</center> || Thumbnail of referenced data
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value xsi:type="ED" mediaType="image/png" representation="B64">
<reference value="http://radiology.bergen.no/xrays/128s.png"/>
<thumbnail mediaType="image/jpeg" representation="B64"> MNY...83== </thumbnail>
</value>
</syntaxhighlight>

=== Strings (ST) ===

This data type is a specialization of the ED type where ''@mediaType'' is fixed “text/plain” and ''@representation'' is fixed “TXT”. It allows conveying a character string as '''element content'''. This data type is used in other data types it like the ''@extension'' in instance identifiers, or address and person name data type components.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<lotNumber> 143GT6DT </lotNumber>
</syntaxhighlight>

=== Concept Descriptor (CD) ===

This data type specifies a concept by means of a code and its code system (except for situations where no code is available).

A couple of specializations of data type CD exist, which differ in the main characteristics (properties) of the data type that may or may not be supported.

{| class="hl7table" style="width:50%"
|+<ref group="Table">Properties of data types used for codes</ref> ''Properties of data types used for codes''
! <div style="text-align: right">DataType</div> !! CD !! CE !! CV !! CO !! CS
|-
! <div style="text-align: left">Property</div> !! !! !! !! !!
|-
| '''@code''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||<center>X</center>
|-
| '''@codeSystem''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''@codeSystemVersion''' || <center>X</center> || <center>X</center> || <center>X</center>|| <center>X</center> ||
|-
| '''@displayName''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''originalText''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''translation''' || <center>X</center> || <center>X</center> || || ||
|-
| '''qualifier''' || <center>X</center> || || || ||
|}

Because the CE variant is most used in practice, the general explanation of the properties will be given with de description of CE (see below).

The only attribute that is unique to CD is briefly explained here.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@qualifier''' || <center>CR</center> || <center>O</center> || An additional qualifier for the code.
|}

Complex terminologies like SNOMED CT can be used only using data type CD.

=== Coded with Equivalents (CE) ===

With elements of this data type, a concept by means of a code and its coding system (except for situations where no code is available) can be specified. It optionally contains one or more equivalents using other code systems.

It may contain the following attributes:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@code''' || <center>ST</center> || <center>R</center> || The actual code
|-
| '''@codeSystem''' || <center>OID</center> || <center>R</center> || required to identify the code system were the code is drawn from. This is an OID (object identifier, see [[#Object_Identifiers_.28OIDs.29|Object Identifiers at 4.1]])
|-
| '''@displayName''' || <center>ST</center> || <center>O</center> || Optional textual representation of code. A display name may be specified representing the plain text of the code. The information of this attribute may not be used by the receiving system for interpretation, but only for display purposes. The display name may never be transmitted without a code and must have the same meaning as the code.
|-
| '''@codeSystemName''' || <center>ST</center> || <center>O</center> || A textual representation of the name of the code system
|-
| '''@codeSystemVersion''' || <center>ST</center> || <center>O</center> || A textual representation of the version of the code system
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"/>

<code code="AU" codeSystem="2.16.840.1.113883.5.33"/>

<storageCode code="AC" codeSystem="2.16.840.1.113883.5.34" displayName="active"/>

<code code="A45.0" displayName="Somatisierungsstörung" codeSystem="1.2.276.0.76.5.409" codeSystemName="ICD-10 GM 2012"/>
</syntaxhighlight>

There are some child elements of codes that can be used to express what the “original text” was that was used for the coding or to indicate that there are “translations” to other code systems than the primary code.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''originalText''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Textual representation of the concept, actually a description which was used to create the actual code
|}

No semantics may be assumed other than showing the ''@displayName'' to a user to clarify the code. A display name cannot occur without its code and must carry the same meaning.

In case no code is known, it is allowed to specify a ''@nullFlavor'' for the code element and to give information about the (not yet coded) concept in original text. However, this should be an exception.

If other codes than the primary code need to be conveyed adding a translation child element can be used.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<originalText>minor aphthous stomatitis</originalText>
</code>
</syntaxhighlight>

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''translation''' || <center>CD</center> || <center>0..*</center> || <center>O</center> || Alternative code(s)
|}

A ''translation'' element is also of type CD and shall have a code and a code system identified. It shall point to the same concept as the primary code. It is allowed that a translation conveys less conceptual details than the original code.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<translation code="528.2" codeSystem="2.16.840.1.113883.6.2" codeSystemName="ICD9" displayName="Oral aphthae"/>
</code>
</syntaxhighlight>

=== Coded Value (CV) ===

This is actually a specialization of CE (see above), with the exception that neither ''originalText'' nor ''translation'' child element are allowed.

=== Coded Simple Value (CS) ===

This is actually a specialization of CE (see above), with no code system attribute and no original text or translation child element allowed. It specifies a concept by means of a code from a ''predefined'' code system (table) where the code is drawn from. This data type is usually applied in the context of fixed predefined HL7 tables.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<statusCode code="completed"/>
</syntaxhighlight>

In this example ''statusCode'' is bound in the underlying model to the specific code system ''ActStatus''. Because it is predefined by means of the vocabulary binding, ''@codeSystem'' is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Telecommunication Address (TEL) ===

Elements of this type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>ST</center> || <center>R</center> || carries strings that represent telecommunication contact information
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

The actual data is preceded by the scheme (refer to Internet Standard “RFC 1738 Uniform Resource Locators (URL)” <ref>RFC 1738 Uniform Resource Locators (URL): http://www.ietf.org/rfc/rfc1738.txt</ref>.

Examples:
* telephone (tel:),
* fax (fax:),
* email (mailto:).

It must follow the rules defined in Internet “RFC 2806 URLs for Telephone Calls” <ref>RFC 2806 URLs for Telephone Calls: http://www.ietf.org/rfc/rfc2806.txt</ref>.

The following codes will be used in the “use” attribute:
* H – Home
* WP – Work
* MC can be used (in addition to H or WP) to denote that this is a mobile phone.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257" />

<telecom use="H" value="tel:55354257" />

<telecom use="H" value="fax:56542558" />

<telecom value="tel:+41.34.21.4765342"/>

<telecom value="mailto:opr@opr-sem.no"/>

<telecom use="WP MC" value="tel:97555786" />
</syntaxhighlight>

It is possible to express the useable period of a telecommunication contact. A child element ''useablePeriod'' is used as a time interval to indicate this period.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''useablePeriod''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257">
<useablePeriod>
<high value="20111201"/>
</useablePeriod>
</telecom>
</syntaxhighlight>

=== Postal Address (AD) ===

Elements of this data type have a substructure in order to represent a structured address specification. In this implementation guide only a selection of all possible child elements is allowed, the original HL7 specification is richer.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''streetAddressLine''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Street address, includes street name and house number
|-
| '''city''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || City
|-
| '''postalCode''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Postal code
|-
| '''country''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Country
|-
|}

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that the sequence of the sub elements is country specific, i.e. it has to follow “common” rules how to write an address. For example, an UK address and a German address have different sequences of address representation.
|}

A ''@use'' attribute can also be specified.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="WP">
<streetAddressLine>Anna-Louisa-Karsch-Str. 2</streetAddressLine>
<postalCode>10178</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="H WP">
<streetAddressLine>Tatungasse 34</streetAddressLine>
<postalCode>10825</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

Also, a country may be specified using the element ''country''.

=== Person Name (PN) ===

Elements of this data type do also have a substructure to represent the parts of a person name, like family or given name and prefixes.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>
<given>Franz</given>
<given>Ingrun</given>
<family>Nordmann</family>
</name>
</syntaxhighlight>

Previous or birth or maiden names are supported using the ''validTime'' element. ''validTime'' (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]]) specifies the validity range of the name.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">

<name>
<given>Jan</given>
<given>Olaf</given>
<family>Hendrikson</family>
<validTime>
<high value="20000101"/>
</validTime>
</name>
</syntaxhighlight>

Note that the name attribute is repeating, i.e. multiple (types of) names could be sent. It is up to the receiver (based on the value of the ''@use'' attribute, and ''validTime'') to decide what name it wants to use or import in its database.

=== Organisation Name (ON) ===

Elements of this data type represent a name of an organization.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name> Charité Berlin </name>
</syntaxhighlight>

The optional ''validTime'' element (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]] may be used to specify the validity range of the name of the organization.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name of the organization
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>The old hospital
<validTime>
<high value="20111231235959"/>
</validTime>
</name>
</syntaxhighlight>

Please note that the use of ''validTime'' yields XML mixed content which should be avoided if possible.

=== Integer Number (INT) ===

Elements of this data type are used to specify integer numbers and have one attribute.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>int</center> || <center>R</center> || Integer value
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<sequenceNumber value="24"/>
</syntaxhighlight>

=== Physical Quantities (PQ) ===

Elements of this data type are physical quantities, i.e. a measurable quantity (or countable) value from the physical world. This is different from just a “number”, because there is a (natural) unit specified in which the measurable quantity is expressed.
Examples:
* an amount of blood 20 ml (sample volume)
* a cut with a length of 10 cm (result observation)
* a dose of 200 milligrams per administration (dosing)
* delivery of 60 pieces of a tablet (amount supplied).
Elements of this data type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>real</center> || <center>R</center> || value of the measurement
|-
| '''@unit''' || <center>CS</center> || <center>R</center> || unit of measurement
|}

In the unit of measurement unit is expressed following the ''Unified Code for Units of Measure'' (UCUM) specification. This specification is a collection of atomic units, prefixes and a corresponding grammar for valid combinations to build all-natural units of measurement. For a complete description of possible units, see the ''Unified Code for Units of Measure'' <ref>Unified Code for Units of Measure: http://unitsofmeasure.org/</ref> specification.

If a value is not countable or if measurable, for example expressed in milligrams or liters, then this unit is a valid UCUM unit like “mg” or “L”. If a value is countable, for example the number of tablets, then this attribute contains “1”.

In HL7 it is required that all PQ data type units are valid UCUM units.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<value value="165" unit="cm"/>

<value value="81.1" unit="kg"/>

<value value="120" unit="mm[Hg]"/>

<value value="5" unit="1"/>
</syntaxhighlight>

=== Point in Time (TS) ===

Elements of this data type have the attribute

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>TS</center> || <center>R</center> || Point in time
|}

and specify points in time in the format YYYYMMDDhhmmss±ZZZZ, where
* YYYY is the four-digit year,
* MM the two-digit month,
* DD the two-digit day,
* hh the two-digit hour,
* mm the two-digits minute and
* ss the two-digit second.
Optional a time zone ZZZZ, the four-digit time alignment with a preceding “-” or a “+” can be specified. If time zone is omitted, local time is assumed.

The point in time may be right truncated in respect to the precision of the information.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<effectiveTime value="20140412"/>

<effectiveTime value="201409091245"/>

<effectiveTime value="1996"/>

<birthTime value="19540714"/>

<effectiveTime value="20140412+0100"/>
</syntaxhighlight>

=== Intervals (IVL) ===

Intervals are defined only for data types with an ordinal or interval scale type. There are several possibilities to determine an interval (see Figure 2), for example to specify

* a lower <low> and an upper boundary <high> (a),
* a lower <low> boundary and width <width> (b)
* an upper boundary and width <width> (c) or
* the middle of the interval <nowiki><center></nowiki> and a width <width> (d).

[[File:CDA_Core_Principles_Figure_2_Determining_Intervals.png|700px]]

<ref group="Figure">Several possibilities to determine closed intervals</ref> ''Several possibilities to determine closed intervals''

In addition, there is sometimes the need to specify incomplete intervals (open intervals). For example, an interval with only an upper limit to indicate a maximum dose or a start date and time only to express “since…”.

{{ConstraintBox|
To indicate an interval, only the following combinations are permitted.
(1) A lower and an upper boundary may not be identical, and their accuracy has to be equal.

Correct examples:

{{BeginGreenBox|}}
Interval from 5 to 6
Interval from 20110607 until 20110612
{{EndGreenBox}}

Incorrect examples:

{{BeginRedBox|}}
Interval from 5 to 6.0
Interval from 20110101 to 2011
{{EndRedBox|}}

(2) A lower boundary and a width

(3) A lower limit boundary

(4) A upper limit boundary

(5) Only the middle of the interval

(6) Only the width of an interval}}

Accordingly, four child elements are available.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Lower boundary
|-
| '''high''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Upper boundary
|-
| '''center''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Where ''(T)'' is defined in this specification as one of the data types “TS” or “PQ”.

=== Interval of time (IVL_TS) ===

Elements of this data type represent time intervals. There are four possible child elements.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Lower boundary (start date/time)
|-
| '''high''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Upper boundary (end date/time)
|-
| '''center''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Normally, a lower and an upper boundary is given, both are points in time. Also, it is possible to specify open intervals like “since June 14, 1999” (left boundary given only) or “until September 24, 2006” (right boundary given).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110507"/>
<high value="20110909"/>
</effectiveTime>

<effectiveTime>
<low value="20110507"/>
</effectiveTime>

<value>
<low value="20110101"/>
<width value="120" unit="d"/>
</value>

<value>
<center value="20110101"/>
</value>
</syntaxhighlight>

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|It must be noted that intervals of time stamps in HL7 are equally treated as other interval types (e.g. integers). The statement, one may take 1–3 tablets (interval of integers), for example, says that you are allowed to take no more than three tablets, not 3½ or 3.5 tablets. On the other hand, when treat the words “until 12 June 2011” regarding the upper interval limit differently, particularly we assume that the entire day 12 June is still included in this time interval.

Thus, in human perception time intervals are handled differently compared to such as number intervals. This is a situation may lead to inconsistencies in standardized communication. As a conclusion, an upper limit “12 June 2011” means that only the very first moment of the 12 June is included in the interval, but not, for example, the 12 June 13:00 hours.

Interpretation does not depend on the accuracy of the time:
* “after 2004” means “from January 1, 2005 00:00:00.000”,
* “after 20041201” means “from 2 December 2004 00:00:00.000 hours”,
* and “after 200412011200” means “from 1 December 2004 12:01:00.000”.

As a result, you have to carefully consider the specification and implemen-tation of time intervals upper boundaries. In order to prevent mis-understandings intervals are always specified with the date and time for an upper limit that would cover the whole day. Accordingly, “201106122359” means 12 June 2011 throughout the day.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="201106122359"/>
</effectiveTime>
</syntaxhighlight>

Because of the equal treatment of time intervals this is applied also to the lower limit boundaries of time intervals as “0000”. This means for example that “since 9 June 2011” is expressed as “201106090000”.
|}

The <width> element is of data type PQ (physical quantity). The value obviously shall relate to a period of time and it is required to include a “time” unit. These are the units “us” (microseconds), “ms” (milliseconds), “s” (seconds), “min” (minute), “h” (hours), “d” (day), “wk” (week), “mo” (month) and “a” (year).

{{ConstraintBox|
For interval of time stamps the @unit of a ''low'' or ''high'' child element shall use units
* us (microseconds),
* ms (milliseconds),
* s (seconds),
* min (minute),
* h (hours),
* d (day),
* wk (week),
* mo (month) or
* a (year).
}}

=== Interval of physical quantities (IVL_PQ) ===

Elements of this data type are used to indicate intervals of physical quantities (see also [[#Physical Quantities (PQ)|3.18 Physical Quantities (PQ)]]). In general, an upper and a lower boundary is specified. It is also possible to use ''center'' instead of ''low'' and ''high''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low || <center>TS</center> || <center>0..1</center> || <center>C</center> || the lower limit of the interval (i.e. the minimum amount).
|-
| '''high || <center>TS</center> || <center>0..1</center> || <center>C</center> || the upper limit of the interval (i.e. the maximum amount).
|-
| '''center || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of the interval
|}

The ''center'' child element is used when there is no interval, but an exact value. Alternative would be to demote IVL_PQ to data type PQ and populate the element’s ''@value'' attribute, but this is more difficult to process in XML. That is why the use of the ''center'' child element is deprecated.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<referenceRange>
<low value="7.5" unit="mmol/l"/>
<high value="10" unit="mmol/l"/>
</referenceRange>

<doseQuantity>
<center value="9" unit="1"/>
</doseQuantity>
</syntaxhighlight>

=== Ratio of quantities (RTO_QTY_QTY) ===

Elements of this data type specify ratios and have two child elements, a numerator and a denominator. The underlying QTY (Quantity) data type is an abstract data type and in a XML instance it has to be replaced by a specific data type using the ''@xsi:type'' instruction (see below).

In this specification only “PQ” or “INT” are allowed for the demotion of both ''numerator'' and ''denominator''. The relevant child elements are:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''numerator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the numerator of the ratio
|-
| '''denominator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the denominator of the ratio
|}

If a model attribute already is a RTO_QTY_QTY, you need to specify (demote) the OTY abstract data type for both ''numerator'' and ''denominator'' by using an ''@xsi:type'' instruction.
In some cases where the model attribute is of type “ANY”, also the root element shall carry an ''@xsi:type'' RTO_QTY_QTY instruction.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<maxDoseQuantity>
<numerator xsi:type="PQ" value="6"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="400" unit="mg"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="5"/>
<denominator xsi:type="PQ" value="1" unit="h"/>
</maxDoseQuantity>

<value xsi:type="RTO_QTY_QTY">
<numerator xsi:type="INT" value="1"/>
<denominator xsi:type="INT" value="10000"/>
</value>
</syntaxhighlight>

== Identification mechanisms ==

=== Object Identifiers (OIDs) ===

Standardized exchange of information using messages or documents also deals with unique identifications of objects and concepts, especially in environments where sender and receiver do not “know” each other necessarily.

It is important to understand the difference between identification of instances (ids) and code concepts (classifications). Within the context of HL7 interactions OIDs are quite often used.

An id points to a specific instance of an object or identification scheme (a particular methodology for the identification of a class of objects), for example a specific person as the patient or a physician, a specific lab observation or an X-ray photo.

In contrast to instance identifiers, a classification identifies a specific concept. The type of patient (inpatient, outpatient), the type of doctor (an anesthesiologist), the codes for gender or a lab observation (blood cell count) may serve as examples.

OIDs (object identifiers) are worldwide unique identifiers for objects. They are used in HL7 to specify identifications and classifications. An object in this sense is persistent, well-defined information, definitions or specifications and is represented with ids or codes.

Commonly used OIDs (i.e. used for a purpose that is wider in scope than the regional healthcare organization; used in communications between healthcare regions) can be found in OIDs registries such as

* [http://www.oid-info.com www.oid-info.com],
* [http://www.hl7.org www.hl7.org],
* [http://www.hl7.org.uk/version3group/oids.asp HL7 OID registry in the UK],
* [https://www.dimdi.de/dynamic/de/klassifikationen/weitere-klassifikationen-und-standards/oid/ OID registry Germany].

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|All OIDs with an element of 999 or 9999 are for documentation purposes only. They will be replaced by permanent OIDs once these have been assigned/found/applied for.
|}

OID (Object Identifiers) are unique identifiers for any kind of objects. They are defined in Rec. ITU-T X.660 | ISO/IEC 9834-1. This identification system for objects and concepts makes reliable electronic information exchange possible. Administration and Registration is regulated by a set of rules, described in the corresponding chapter of this document.

Every artefact in ART-DECOR has an Object Identifier (OID). There are recommendations for the management and the exchange of Object Identifiers, partially defined in ISO TS 13582 <ref>ISO TS 13582: https://www.iso.org/standard/69652.html</ref>.

''HL7 International'' has created a type ontology for the OIDs in the HL7 registry to make it easier for the user community to search for OIDs they may be looking for and can be found at hl7.org.

From a policy perspective it is common practice in several healthcare related OID registries (HL7 International at http://www.hl7.org, OID Registry Germany at http://www.dimdi.de, OID registry Switzerland at http://oid.refdata.ch, and OID registry Austria at https://www.gesundheit.gv.at/OID_Frontend) to distinguish at least between the following types of OIDs:

{| class="hl7table" style="width:50%"
|+<ref group="Table">Recommended OID sub-branches for different artefacts</ref> ''Recommended OID sub-branches for different artefacts''
! Arc !! Description
|-
| .3 || organizational bodies and groups
|-
| .4 || identifier systems and namespaces
|-
| .5 || code systems
|-
| .7 || document artefacts
|-
| .9 || conformance profiles
|-
| .10 || templates
|-
| .11 || value sets
|-
| .19 || examples
|-
| .99 || experimental
|}

''Example: given that “your” root OID is 1.2.3.4.5, the first value set of your governance group is then to be 1.2.3.4.5.11.1, with .11 as the value set “branch” and the last .1 as the first artefact of that kind.''

In ART-DECOR a project typically is set into the .77 branch of a governance group. When setting up the project, the OID for that project also determines the artefact OIDs using throughout the ART-DECOR project. The following additional branches are used to distinguish between different OID types:

{| class="hl7table" style="width:50%"
|+<ref group="Table">Recommended OID sub-branches for ART-DECOR projects</ref> ''Recommended OID sub-branches for ART-DECOR projects''
! Artefact code !! Description !! Recommended OID suffix
|-
| DS || dataset || .77.1
|-
| DE || dataset concept || .77.2
|-
| SC || scenario || .77.3
|-
| TR || transaction in scenario || .77.4
|-
| CS || code system || .77.5
|-
| IS || issue || .77.6
|-
| AC || actor in scenario || .77.7
|-
| CL || concept list in dataset || .77.8
|-
| EL || element in template || .77.9
|-
| TM || template || .77.10
|-
| VS || value set || .77.11
|-
| RL || rule for instances || .77.12
|-
| SX || test/example scenario || .77.18
|-
| EX || test/example instance || .77.19
|-
| QX || qualification test/example || .77.20
|-
| TX || test/example data element || .77.21
|-
| CM || community || .77.22
|-
| MP || concept map || .77.24
|}

In ART-DECOR a newly created project uses these OID branches automatically.

=== Instance identification ===

Instance identification is done with the id element of a class. Its type is II (instance identifier) and described in the data type section above. For example, a patient number can be represented as
* 2.16.578.1.34.1.5432.1, the root-OID of the issuing authority, for example a system/application in a hospital, and
* 67543242 as the ''@extension'', representing the patient number within the system defined by the ''@root'' attribute.

=== Coding scheme identification ===

Coding schemes have to be uniquely identified using OIDs as well. All coding tables used in this implementation guide show the corresponding OID that has to be specified in the ''@codeSystem'' attribute of coded elements. Both attributes ''@code'' and ''@codeSystem'' together allows a correct interpretation of concept and code.

=== List of identification schemes ===

The following are OIDs for commonly used identification schemes.

{| class="hl7table"
|+<ref group="Table">Commonly used identification scheme OIDs</ref> ''Commonly used identification scheme OIDs''
! OID !! Identification System Name !! Description !! Issuer
|-
| 1.2.276.0.76.4.8 || KV-Nummer || Krankenversichertennummer ||
|-
| 1.2.276.0.76.4.17 || BSNR || Betriebsstättennummer ||
|-
| 1.2.276.0.76.4.16 || LANR || lebenslange Arztnummer ||
|}

=== List of code systems ===

The following are OIDs for code systems.

{| class="hl7table"
|+<ref group="Table">Commonly used code system OIDs</ref> ''Commonly used code system OIDs''
! OID !! Code System Name !! Description !! Issuer
|-
| 2.16.840.1.113883.6.1 || LOINC || Logical Observation Identifiers Names and Codes (LOINC) || Regenstrief Institute
|-
| 2.16.840.1.113883.6.96 || SNOMED CT || Systemized Nomenclature in Medicine Reference Terminology (SNOMED CT) || SNOMED International
|-
| 1.0.3166.1.2 || ISO 3166-1 (second edition) || Country codes as per ISO 3166-1:2007 || ISO
|}

== Vocabulary ==

=== Code Systems ===

Within HL7, a ''Code System'' is defined as a collection of codes with associated designations and meanings. Examples of code systems include ICD-10, SNOMED CT, and LOINC.
To meet the requirements of a code system as defined by HL7, a given code must resolve to one and only one meaning within the code system. Given this definition, each code table in the HL7 Version 3 standard represents a different code system since codes are sometimes used in different tables to have different meanings.
For example, “M” in the administrative gender table (''AdministrativeGender'', OID 2.16.840.1.113883.5.1) means “male”, while “M” in the marital status table (''MaritalStatus'', OID 2.16.840.1.113883.5.2) means “married”.
In this specification, code system tables are not presented in detail.

=== Value Sets ===

A ''Value Set'' represents a uniquely identifiable set of valid concept representations, where any concept representation can be tested to determine whether or not it is a member of the value set.
Value set complexity may range from a simple flat list of concept codes drawn from a single code system, to an unbounded hierarchical set of possibly post-coordinated expressions drawn from multiple code systems.
Value sets exist to constrain the content for a coded element in an HL7 static model or data type property. Value sets cannot have null content and must contain at least one concept representation where any given concept is generally (but not required to be) represented by only a single code within the Value Set.

[[File:CDA_Core_Principles_Figure_3_ValueSet_Example.png|800px]]

<ref group="Figure">Example presentation of the value set “MaritalStatus”</ref> ''Example presentation of the value set “MaritalStatus”''

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that value set OIDs never appear in a CDA Release 2 document. They are used for constraint expressions, for example in implementation guides.
In order to send a specific code drawn from a value set, the corresponding code system has to be conveyed.
An example, in the implementation specification the constraint on the model element ''maritalStatusCode'' is expressed as “to be drawn from value set 2.16.840.1.113883.5.2 ''MaritalStatus''”.
To actually send a marital status of “M” (married) that is shown in the value set figure above, the corresponding HL7 CDA instance would say:
<syntaxhighlight lang="xml">
<maritalStatusCode code="M" codeSystem="2.16.840.1.113883.5.2"/>
</syntaxhighlight>
|}

In this specification, value set tables are not presented in detail.

==== Binding strength ====

There is an optional vocabulary strength for data types that support that feature (coded concepts). Examples include CD, CE, CV and CO. Values are required, extensible, preferred and example. Default is required.

Please note: the formerly supported values CNE (Coded No Extensibility) and CWE (Coded With Extensibility) in ART-DECOR are deprecated as of December 2017. Specification CNE is handled as required and CWE is handled as extensible.

{| class="hl7table"
|+<ref group="Table">Binding Strengths</ref> ''Binding Strengths''
! Strength !! Description
|-
|required||Required/CNE. Coded with no exceptions; this element SHALL be from the specified value set
|-
|extensible||Extensible/CWE. Coded with Exceptions; this element SHALL be from the specified value set if any of the codes within the value set can apply to the concept being communicated. If the value set does not cover the concept (based on human review), alternate codings (or, data type allowing, text) may be included instead.
|-
|preferred||Preferred. Instances are encouraged to draw from the specified codes for interoperability purposes but are not required to do so to be considered conformant.
|-
|example||Example. Instances are not expected or even encouraged to draw from the specified value set. The value set merely provides examples of the types of concepts intended to be included.
|}

Mismatches with required lead to validation errors (SHALL logic). Mismatches with extensible lead to validation warnings (SHOULD logic). Mismatches with preferred lead to validation information messages (MAY logic). Mismatches with example don't have any validation consequences.

== Appendix ==

=== References ===

<references/>

=== List of figures ===

<references group="Figure" />

=== List of tables ===

<references group="Table" />

HL7 CDA Core Principles

2019-06-16T11:19:17Z

Dammon: /* Interval of time (IVL_TS) */

== Introduction ==

This implementation guide specifies the ''Core Principles'' of using the ''Clinical Document Architecture'' <ref>Clinical Document Architecture Release 2: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=7</ref>.

=== Scope ===

This guide focuses on ''Data Types Release 1'' <ref>HL7 Data Types Release 1: http://www.hl7.org</ref>. Meanwhile an ISO specification ISO 21090 is out, also known as Data Type Release 2. The latter is subject to another implementation guide that will be published when ISO data types are used.

=== Focus of this document: HL7 Version 3 Data Types for CDA ===

The following chapters of this document will focus on the description of the data types and associated material. It will highlight the essentials in four chapters, all focusing on the Norwegian situation.
* '''Common aspects:''' explains common aspects of use of CDA and XML
* '''Data types:''' gives an overview and detailed specification of all data types used in CDA
* '''Identification schemes:''' explains major aspects of identification and the use in CDA
* '''Use of vocabulary:''' explains major aspects of vocabulary use in CDA.

=== Background ===

In many (European) countries, implementation guides for the use of data types in HL7 V3 are published. They take into account country specific constraints on the data types.

=== Legend of symbols ===

In this document several symbols are used.

{| class="hl7table" style="width:50%"
| [[File:Pfeil_rechts.png|50px]] || This is an important item
|-
| [[File:Issue.svg|50px]] || This is a known open issue
|-
| [[File:Faq.svg|50px]] || This is a frequently asked question (FAQ) with answer
|-
| [[File:Conformance.svg|50px]] || This is a constraint; in some situations also the rule identification is specified, e.g. dtr1-1-ANY, which links to the corresponding validation rule.
|}

=== Version history ===

{| class="hl7table" style="width:50%"
|+
! Version !! Date !! Description !! Author
|-
| 1.1 || 2019-04-24 || Refurbished guide based on earlier work || Kai U. Heitmann
|}

== Common aspects ==

=== Use of XML ===

HL7 Version 3 CDA uses the Extensible Markup Language (XML) as the exchange format. It is assumed that the reader is familiar with common XML aspects. However, some constraints are made regarding the use of CDA.

==== Character Set ====

{{ConstraintBox|
The character encoding of any CDA document shall be “UTF-8”.}}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="utf-8"?>
</syntaxhighlight>

=== CDA document structure ===

The XML namespace for CDA Release 2 documents is ''<nowiki>urn:hl7-org:v3</nowiki>''. This must be correctly mentioned in every XML instance.

CDA XML documents starts with the root element ''ClinicalDocument''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">


...

<component>
<structuredBody>
...
</structuredBody>
</component>

</ClinicalDocument>
</syntaxhighlight>

== Data types ==

=== Introduction ===

The following chapter describes the typical data types used in CDA implementation guides. For further information please refer to the HL7 V3 standard and its two parts concerning data types:
* Abstract Data type definition <ref>HL7 Version 3 Abstract Data type definition: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=264</ref>
* XML ITS for data types <ref>XML ITS for data types: https://www.hl7.org/documentcenter/public_temp_682D4D16-1C23-BA17-0C789BA52BEDB68E/wg/inm/datatypes-its-xml20050714.htm</ref>
Data types are properties of model class attributes and the basic building blocks of information in a CDA XML instance. For example, a model attribute named “time” has as its data type a time stamp “TS” (see Figure 1).

[[File:CDA_Core_Principles_Figure_1_CDA_Structure_Data_Types.png|700px]]

<ref group="Figure">CDA structure (left) and the data type specification (right)</ref> ''CDA structure (left) and the data type specification (right)''

=== XML representation of data types ===

Actual data is mostly carried in HL7 Version 3 by populating XML attributes and not as element content. Exceptions are names of persons and organizations as well as addresses.

The XML elements have names like the model attributes. For example, a model attribute “id” has a corresponding XML element named <id…>. The model determines the sequence of elements and their hierarchy. The data type itself determines the XML attributes within the start tag. The notation here is as follows:

{| class="hl7table"
|+
! Attribute !! DT !! Conf !! Description
|-
| (name of the model attribute or XML element) || Data type || Conformance, i.e. O, R, M || Textual description
|}

XML attributes (data type properties) are denoted as ''@attribute'' in order to distinguish their names from XML elements.

Example: in the example model above, the data type of the ''id'' attribute's is ''II'' (Instance Identifier). The corresponding XML attributes for that data type include ''@root'' and ''@extension''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id root="..." extension="..." />
</syntaxhighlight>

A description of the data types and their corresponding XML representation is contained in subsequent paragraphs of this guide.

==== Exceptions using XML element content ====

For most data types, the actual data is conveyed in XML attributes. However, there are some exceptions. For the data types binary (BIN), Encapsulated Data (ED), Entity Name (EN), Person Name (PN), Organization Name (ON), Trivial Name (TN), Address (AD) and character string data (ST), information is carried as element content.

Example: the components of an address <addr> are represented by sub elements with the data as element content (in the example shown in black).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr>
<streetAddressLine>Thormøhlens gate 12</streetAddressLine>
<postalCode>5006</postalCode>
<city>Bergen</city>
</addr>
</syntaxhighlight>

==== Combined data types ====

There are a number of so-called combined data types. For example, an interval with a lower and upper limit and a ratio that has a nominator and a denominator value.

In combined data types the substructure (e.g. <low> <high> in an interval) are represented as child elements of the relevant data type element.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110701"/>
<high value="20110729"/>
</effectiveTime>
</syntaxhighlight>

==== Conformance information ====

The conformance indicators distinguish kinds of conformance information described shortly here.

* '''O''': An optional item may be omitted if no data is present, i.e. no corresponding XML attribute or element is sent (marked as “O”)
* '''R''': For required items, lower cardinality is always zero or 1.
** Elements must be present and populated with data if present in the sending system. If no data is available (yet), a null flavor (see below) indicates and possibly classifies the missing information (marked as R).
** Attribute flagged as required must be present in the instance and populated.
* '''M''': For mandatory elements data must be sent and no missing values are allowed, i.e. if the sending system does not have information for mandatory elements the XML instance cannot be created and sent (marked as M).
* '''NP''': no data may be present at all (not permitted)
* '''C''': conditional conformance; typically a conformance table shows the circumstances (conditions) derived from information in the instance and the corresponding cardinalities and conformance statements.

=== Missing values (null flavor) ===

For every data type it is possible to specify a missing value including a kind of reason why data is missing. Instead of specifying any attribute of the corresponding element, a ''@nullFlavor'' attribute expresses the omission of data. Note that missing data is not allowed for mandatory elements (see above).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value nullFlavor="OTH"/>

<code nullFlavor="UNK"/>

<booleanInd nullFlavor="NI"/>

</syntaxhighlight>

The codes for the ''@nullFlavor'' attribute are drawn from the following hierarchical code system. It is a Coded Simple (CS), which means it has no code system (attribute ''@codeSystem'') specified.

{| class="hl7table"
|+<ref group="Table">NullFlavor</ref> ''NullFlavor''
! Code
! width=15% | Print Name
! Definition / Description
|-
| NI || No Information || No information whatsoever can be inferred from this exceptional value. This is the most general exceptional value. It is also the default exceptional value.
|-
|   OTH || other || The actual value is not an element in the value domain of a variable. (e.g., concept not provided by required code system).
|-
|     NINF || negative infinity || Negative infinity of numbers.
|-
|     PINF || positive infinity || Positive infinity of numbers.
|-
|   UNK || unknown || A proper value is applicable, but not known.
|-
|     ASKU || asked but unknown || Information was sought but not found (e.g., patient was asked but didn't know)
|-
|       NAV || temporarily unavailable || Information is not available at this time but it is expected that it will be available later.
|-
|       NASK || not asked || This information has not been sought (e.g., patient was not asked)
|-
|       TRC || trace || The content is greater than zero, but too small to be quantified.
|-
|   MSK || masked || There is information on this item available but it has not been provided by the sender due to security, privacy or other reasons. There may be an alternate mechanism for gaining access to this information.
Note: using this null flavour does provide information that may be a breach of confidentiality, even though no detail data is provided. Its primary purpose is for those circumstances where it is necessary to inform the receiver that the information does exist without providing any detail.
|-
|   NA || not applicable || No proper value is applicable in this context (e.g., last menstrual period for a male).
|-
| NP || not present || Value is not present in a message. This is only defined in messages, never in application data! All values not present in the message must be replaced by the applicable default, or no-information (NI) as the default of all defaults.
|}

=== ANY as the generic data type ===

This abstract data type is the basis for all other data types. Not a single value within a CDA document has the effective data type ANY, but any data type within HL7v3 is a specialization of ANY. This also means that any other data type inherits all properties of ANY (see [[#Missing_values_.28null_flavor.29|“Missing values (null flavor)”]]).

The ANY type is occasionally found in HL7 models when it comes to clinical finding etc. where – at model time – the actual data type of the value is not known. At instantiation time however, the actual data type ''is'' known and ANY is always replaced by a particular data type in an instance.

One example is the observation value (child element value in an observation), where in the model the data type of value cannot be anticipated. When instantiation is taking place, the data type is specified by the XML instance attribute ''@xsi:type''. This information can be used by the receiver to validate and process the value.

Attributes of an element with this data type are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@nullFlavor''' || <center>CS</center> || <center>–</center> || Classification of the missing value, see [[#Missing_values_.28null_flavor.29|3.3 Missing values (null flavor)]].
|}

{| class="hl7table" style="width:100%"
| width=8% | <center>[[File:Conformance.svg|50px]] dtr1-1-ANY</center> || If there is a ''nullFlavor'', there shall be no other attribute or element, unless it's ''nullFlavor="OTH"''.

In that case ''@codeSystem'' or ''originalText'' (see “code” data types) may have a value.
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">

<value xsi:type="CE" code="N11.9" codeSystem="2.16.840.1.113883.6.3"/>


<value xsi:type="PQ" value="12" unit="mL"/>


<value xsi:type="ED">this is text</value>
</syntaxhighlight>

=== Boolean (BL) ===

Elements of this data type refer to Boolean logic and have an attribute ''@value''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>BL</center> || <center>–</center> || Valued as “true” or “false”
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<negationInd value="false"/>

<deceasedInd value="true"/>

</syntaxhighlight>

In some situations, the BL data does not apply to an XML element, but an attribute. In that case, the attribute carries the Boolean value directly.
<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<support contextConductionInd ="false">
...
</support>
</syntaxhighlight>

=== Instance Identifier (II) ===

This data type identifies instances of classes like observations or entities (persons, organizations). Attributes are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@extension''' || <center>ST</center> || <center>O</center> || Identification
|-
| '''@root''' || <center>OID</center> || <center>R</center> || Source of identification
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id extension="13234453645" root="2.16.840.1.113883.2.6.15.3.427.1"/>
</syntaxhighlight>

The ''@root'' attribute is of type OID (object identifier), a unique identifier of the issuing authority or system. For example, a patient with a patient number 13234453645 created by a specific healthcare provider organization is uniquely identified by the number itself in ''@extension'' and the OID of the organization or the sending system, in the example 2.16.840.1.113883.2.6.15.3.427.1 in ''@root''.

In some cases, a single OID identifies an object uniquely. In that situation, only ''@root'' is populated and ''@extension'' is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Encapsulated Data (ED) ===

Elements of this data type carry multimedia content. The actual multimedia content is represented as element content. There are two situations for the use of ED:

* Inline: The full data is transmitted in the type. This form is mainly used for text.
* By reference: a thumbnail is provided which links to the full data by reference.

In an instance, the data type is normally determined by an ''xsi:type'' specification and some attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@mediaType''' || <center>CS</center> || <center>O</center> || MIME media type classification. At time of writing this specification, the following MIME types are allowed:
* text/plain (plain text)
* text/html (text with html markup)
* image/jpeg (JPEG image)
* application/pdf (a PDF, portable document format)
* application/hl7-sda+xml (CDA documents).
|-
| '''@representation''' || <center>CS</center> || <center>O</center> || Representation of the multimedia content. At time of writing this specification, the following representations are allowed:
* TXT (text, this is the default)
* B64 base 64 encoded data, for example for embedded CDA documents).
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<text xsi:type="ED" mediaType="text/plain">
Patient treated sucessfully
</text>

<text mediaType="application/hl7-sda+xml" representation="B64">PD94bWw..etc..==</text>

</syntaxhighlight>

To include referenced data the two sub elements ''thumbnail'' and ''reference'' are used.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''reference''' || <center>TEL</center> || <center>0..*</center> || <center>O</center> || Link (URI) to full data
|-
| '''thumbnail''' || <center>ED</center> || <center>0..*</center> || <center>O</center> || Thumbnail of referenced data
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value xsi:type="ED" mediaType="image/png" representation="B64">
<reference value="http://radiology.bergen.no/xrays/128s.png"/>
<thumbnail mediaType="image/jpeg" representation="B64"> MNY...83== </thumbnail>
</value>
</syntaxhighlight>

=== Strings (ST) ===

This data type is a specialization of the ED type where ''@mediaType'' is fixed “text/plain” and ''@representation'' is fixed “TXT”. It allows conveying a character string as '''element content'''. This data type is used in other data types it like the ''@extension'' in instance identifiers, or address and person name data type components.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<lotNumber> 143GT6DT </lotNumber>
</syntaxhighlight>

=== Concept Descriptor (CD) ===

This data type specifies a concept by means of a code and its code system (except for situations where no code is available).

A couple of specializations of data type CD exist, which differ in the main characteristics (properties) of the data type that may or may not be supported.

{| class="hl7table" style="width:50%"
|+<ref group="Table">Properties of data types used for codes</ref> ''Properties of data types used for codes''
! <div style="text-align: right">DataType</div> !! CD !! CE !! CV !! CO !! CS
|-
! <div style="text-align: left">Property</div> !! !! !! !! !!
|-
| '''@code''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||<center>X</center>
|-
| '''@codeSystem''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''@codeSystemVersion''' || <center>X</center> || <center>X</center> || <center>X</center>|| <center>X</center> ||
|-
| '''@displayName''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''originalText''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''translation''' || <center>X</center> || <center>X</center> || || ||
|-
| '''qualifier''' || <center>X</center> || || || ||
|}

Because the CE variant is most used in practice, the general explanation of the properties will be given with de description of CE (see below).

The only attribute that is unique to CD is briefly explained here.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@qualifier''' || <center>CR</center> || <center>O</center> || An additional qualifier for the code.
|}

Complex terminologies like SNOMED CT can be used only using data type CD.

=== Coded with Equivalents (CE) ===

With elements of this data type, a concept by means of a code and its coding system (except for situations where no code is available) can be specified. It optionally contains one or more equivalents using other code systems.

It may contain the following attributes:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@code''' || <center>ST</center> || <center>R</center> || The actual code
|-
| '''@codeSystem''' || <center>OID</center> || <center>R</center> || required to identify the code system were the code is drawn from. This is an OID (object identifier, see [[#Object_Identifiers_.28OIDs.29|Object Identifiers at 4.1]])
|-
| '''@displayName''' || <center>ST</center> || <center>O</center> || Optional textual representation of code. A display name may be specified representing the plain text of the code. The information of this attribute may not be used by the receiving system for interpretation, but only for display purposes. The display name may never be transmitted without a code and must have the same meaning as the code.
|-
| '''@codeSystemName''' || <center>ST</center> || <center>O</center> || A textual representation of the name of the code system
|-
| '''@codeSystemVersion''' || <center>ST</center> || <center>O</center> || A textual representation of the version of the code system
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"/>

<code code="AU" codeSystem="2.16.840.1.113883.5.33"/>

<storageCode code="AC" codeSystem="2.16.840.1.113883.5.34" displayName="active"/>

<code code="A45.0" displayName="Somatisierungsstörung" codeSystem="1.2.276.0.76.5.409" codeSystemName="ICD-10 GM 2012"/>
</syntaxhighlight>

There are some child elements of codes that can be used to express what the “original text” was that was used for the coding or to indicate that there are “translations” to other code systems than the primary code.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''originalText''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Textual representation of the concept, actually a description which was used to create the actual code
|}

No semantics may be assumed other than showing the ''@displayName'' to a user to clarify the code. A display name cannot occur without its code and must carry the same meaning.

In case no code is known, it is allowed to specify a ''@nullFlavor'' for the code element and to give information about the (not yet coded) concept in original text. However, this should be an exception.

If other codes than the primary code need to be conveyed adding a translation child element can be used.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<originalText>minor aphthous stomatitis</originalText>
</code>
</syntaxhighlight>

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''translation''' || <center>CD</center> || <center>0..*</center> || <center>O</center> || Alternative code(s)
|}

A ''translation'' element is also of type CD and shall have a code and a code system identified. It shall point to the same concept as the primary code. It is allowed that a translation conveys less conceptual details than the original code.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<translation code="528.2" codeSystem="2.16.840.1.113883.6.2" codeSystemName="ICD9" displayName="Oral aphthae"/>
</code>
</syntaxhighlight>

=== Coded Value (CV) ===

This is actually a specialization of CE (see above), with the exception that neither ''originalText'' nor ''translation'' child element are allowed.

=== Coded Simple Value (CS) ===

This is actually a specialization of CE (see above), with no code system attribute and no original text or translation child element allowed. It specifies a concept by means of a code from a ''predefined'' code system (table) where the code is drawn from. This data type is usually applied in the context of fixed predefined HL7 tables.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<statusCode code="completed"/>
</syntaxhighlight>

In this example ''statusCode'' is bound in the underlying model to the specific code system ''ActStatus''. Because it is predefined by means of the vocabulary binding, ''@codeSystem'' is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Telecommunication Address (TEL) ===

Elements of this type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>ST</center> || <center>R</center> || carries strings that represent telecommunication contact information
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

The actual data is preceded by the scheme (refer to Internet Standard “RFC 1738 Uniform Resource Locators (URL)” <ref>RFC 1738 Uniform Resource Locators (URL): http://www.ietf.org/rfc/rfc1738.txt</ref>.

Examples:
* telephone (tel:),
* fax (fax:),
* email (mailto:).

It must follow the rules defined in Internet “RFC 2806 URLs for Telephone Calls” <ref>RFC 2806 URLs for Telephone Calls: http://www.ietf.org/rfc/rfc2806.txt</ref>.

The following codes will be used in the “use” attribute:
* H – Home
* WP – Work
* MC can be used (in addition to H or WP) to denote that this is a mobile phone.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257" />

<telecom use="H" value="tel:55354257" />

<telecom use="H" value="fax:56542558" />

<telecom value="tel:+41.34.21.4765342"/>

<telecom value="mailto:opr@opr-sem.no"/>

<telecom use="WP MC" value="tel:97555786" />
</syntaxhighlight>

It is possible to express the useable period of a telecommunication contact. A child element ''useablePeriod'' is used as a time interval to indicate this period.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''useablePeriod''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257">
<useablePeriod>
<high value="20111201"/>
</useablePeriod>
</telecom>
</syntaxhighlight>

=== Postal Address (AD) ===

Elements of this data type have a substructure in order to represent a structured address specification. In this implementation guide only a selection of all possible child elements is allowed, the original HL7 specification is richer.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''streetAddressLine''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Street address, includes street name and house number
|-
| '''city''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || City
|-
| '''postalCode''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Postal code
|-
| '''country''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Country
|-
|}

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that the sequence of the sub elements is country specific, i.e. it has to follow “common” rules how to write an address. For example, an UK address and a German address have different sequences of address representation.
|}

A ''@use'' attribute can also be specified.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="WP">
<streetAddressLine>Anna-Louisa-Karsch-Str. 2</streetAddressLine>
<postalCode>10178</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="H WP">
<streetAddressLine>Tatungasse 34</streetAddressLine>
<postalCode>10825</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

Also, a country may be specified using the element ''country''.

=== Person Name (PN) ===

Elements of this data type do also have a substructure to represent the parts of a person name, like family or given name and prefixes.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>
<given>Franz</given>
<given>Ingrun</given>
<family>Nordmann</family>
</name>
</syntaxhighlight>

Previous or birth or maiden names are supported using the ''validTime'' element. ''validTime'' (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]]) specifies the validity range of the name.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">

<name>
<given>Jan</given>
<given>Olaf</given>
<family>Hendrikson</family>
<validTime>
<high value="20000101"/>
</validTime>
</name>
</syntaxhighlight>

Note that the name attribute is repeating, i.e. multiple (types of) names could be sent. It is up to the receiver (based on the value of the ''@use'' attribute, and ''validTime'') to decide what name it wants to use or import in its database.

=== Organisation Name (ON) ===

Elements of this data type represent a name of an organization.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name> Charité Berlin </name>
</syntaxhighlight>

The optional ''validTime'' element (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]] may be used to specify the validity range of the name of the organization.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name of the organization
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>The old hospital
<validTime>
<high value="20111231235959"/>
</validTime>
</name>
</syntaxhighlight>

Please note that the use of ''validTime'' yields XML mixed content which should be avoided if possible.

=== Integer Number (INT) ===

Elements of this data type are used to specify integer numbers and have one attribute.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>int</center> || <center>R</center> || Integer value
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<sequenceNumber value="24"/>
</syntaxhighlight>

=== Physical Quantities (PQ) ===

Elements of this data type are physical quantities, i.e. a measurable quantity (or countable) value from the physical world. This is different from just a “number”, because there is a (natural) unit specified in which the measurable quantity is expressed.
Examples:
* an amount of blood 20 ml (sample volume)
* a cut with a length of 10 cm (result observation)
* a dose of 200 milligrams per administration (dosing)
* delivery of 60 pieces of a tablet (amount supplied).
Elements of this data type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>real</center> || <center>R</center> || value of the measurement
|-
| '''@unit''' || <center>CS</center> || <center>R</center> || unit of measurement
|}

In the unit of measurement unit is expressed following the ''Unified Code for Units of Measure'' (UCUM) specification. This specification is a collection of atomic units, prefixes and a corresponding grammar for valid combinations to build all-natural units of measurement. For a complete description of possible units, see the ''Unified Code for Units of Measure'' <ref>Unified Code for Units of Measure: http://unitsofmeasure.org/</ref> specification.

If a value is not countable or if measurable, for example expressed in milligrams or liters, then this unit is a valid UCUM unit like “mg” or “L”. If a value is countable, for example the number of tablets, then this attribute contains “1”.

In HL7 it is required that all PQ data type units are valid UCUM units.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<value value="165" unit="cm"/>

<value value="81.1" unit="kg"/>

<value value="120" unit="mm[Hg]"/>

<value value="5" unit="1"/>
</syntaxhighlight>

=== Point in Time (TS) ===

Elements of this data type have the attribute

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>TS</center> || <center>R</center> || Point in time
|}

and specify points in time in the format YYYYMMDDhhmmss±ZZZZ, where
* YYYY is the four-digit year,
* MM the two-digit month,
* DD the two-digit day,
* hh the two-digit hour,
* mm the two-digits minute and
* ss the two-digit second.
Optional a time zone ZZZZ, the four-digit time alignment with a preceding “-” or a “+” can be specified. If time zone is omitted, local time is assumed.

The point in time may be right truncated in respect to the precision of the information.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<effectiveTime value="20140412"/>

<effectiveTime value="201409091245"/>

<effectiveTime value="1996"/>

<birthTime value="19540714"/>

<effectiveTime value="20140412+0100"/>
</syntaxhighlight>

=== Intervals (IVL) ===

Intervals are defined only for data types with an ordinal or interval scale type. There are several possibilities to determine an interval (see Figure 2), for example to specify

* a lower <low> and an upper boundary <high> (a),
* a lower <low> boundary and width <width> (b)
* an upper boundary and width <width> (c) or
* the middle of the interval <nowiki><center></nowiki> and a width <width> (d).

[[File:CDA_Core_Principles_Figure_2_Determining_Intervals.png|700px]]

<ref group="Figure">Several possibilities to determine closed intervals</ref> ''Several possibilities to determine closed intervals''

In addition, there is sometimes the need to specify incomplete intervals (open intervals). For example, an interval with only an upper limit to indicate a maximum dose or a start date and time only to express “since…”.

{{ConstraintBox|
To indicate an interval, only the following combinations are permitted.
(1) A lower and an upper boundary may not be identical, and their accuracy has to be equal.

Correct examples:

{{BeginGreenBox|}}
Interval from 5 to 6
Interval from 20110607 until 20110612
{{EndGreenBox}}

Incorrect examples:

{{BeginRedBox|}}
Interval from 5 to 6.0
Interval from 20110101 to 2011
{{EndRedBox|}}

(2) A lower boundary and a width

(3) A lower limit boundary

(4) A upper limit boundary

(5) Only the middle of the interval

(6) Only the width of an interval}}

Accordingly, four child elements are available.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Lower boundary
|-
| '''high''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Upper boundary
|-
| '''center''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Where ''(T)'' is defined in this specification as one of the data types “TS” or “PQ”.

=== Interval of time (IVL_TS) ===

Elements of this data type represent time intervals. There are four possible child elements.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Lower boundary (start date/time)
|-
| '''high''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Upper boundary (end date/time)
|-
| '''center''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Normally, a lower and an upper boundary is given, both are points in time. Also, it is possible to specify open intervals like “since June 14, 1999” (left boundary given only) or “until September 24, 2006” (right boundary given).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110507"/>
<high value="20110909"/>
</effectiveTime>

<effectiveTime>
<low value="20110507"/>
</effectiveTime>

<value>
<low value="20110101"/>
<width value="120" unit="d"/>
</value>

<value>
<center value="20110101"/>
</value>
</syntaxhighlight>

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|It must be noted that intervals of time stamps in HL7 are equally treated as other interval types (e.g. integers). The statement, one may take 1–3 tablets (interval of integers), for example, says that you are allowed to take no more than three tablets, not 3½ or 3.5 tablets. On the other hand, when treat the words “until 12 June 2011” regarding the upper interval limit differently, particularly we assume that the entire day 12 June is still included in this time interval.

Thus, in human perception time intervals are handled differently compared to such as number intervals. This is a situation may lead to inconsistencies in standardized communication. As a conclusion, an upper limit “12 June 2011” means that only the very first moment of the 12 June is included in the interval, but not, for example, the 12 June 13:00 hours.

Interpretation does not depend on the accuracy of the time:
* “after 2004” means “from January 1, 2005 00:00:00.000”,
* “after 20041201” means “from 2 December 2004 00:00:00.000 hours”,
* and “after 200412011200” means “from 1 December 2004 12:01:00.000”.

As a result, you have to carefully consider the specification and implemen-tation of time intervals upper boundaries. In order to prevent mis-understandings intervals are always specified with the date and time for an upper limit that would cover the whole day. Accordingly, “201106122359” means 12 June 2011 throughout the day.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="201106122359"/>
</effectiveTime>
</syntaxhighlight>

Because of the equal treatment of time intervals this is applied also to the lower limit boundaries of time intervals as “0000”. This means for example that “since 9 June 2011” is expressed as “201106090000”.
|}

The <width> element is of data type PQ (physical quantity). The value obviously shall relate to a period of time and it is required to include a “time” unit. These are the units “us” (microseconds), “ms” (milliseconds), “s” (seconds), “min” (minute), “h” (hours), “d” (day), “wk” (week), “mo” (month) and “a” (year).

{{ConstraintBox|
For interval of time stamps the @unit of a ''low'' or ''high'' child element shall use units
* us (microseconds),
* ms (milliseconds),
* s (seconds),
* min (minute),
* h (hours),
* d (day),
* wk (week),
* mo (month) or
* a (year).
}}

=== Interval of physical quantities (IVL_PQ) ===

Elements of this data type are used to indicate intervals of physical quantities (see also [[#Physical Quantities (PQ)|3.18 Physical Quantities (PQ)]]). In general, an upper and a lower boundary is specified. It is also possible to use ''center'' instead of ''low'' and ''high''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low || <center>TS</center> || <center>0..1</center> || <center>C</center> || the lower limit of the interval (i.e. the minimum amount).
|-
| '''high || <center>TS</center> || <center>0..1</center> || <center>C</center> || the upper limit of the interval (i.e. the maximum amount).
|-
| '''center || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of the interval
|}

The ''center'' child element is used when there is no interval, but an exact value. Alternative would be to demote IVL_PQ to data type PQ and populate the element’s ''@value'' attribute, but this is more difficult to process in XML. That is why the use of the ''center'' child element is deprecated.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<referenceRange>
<low value="7.5" unit="mmol/l"/>
<high value="10" unit="mmol/l"/>
</referenceRange>

<doseQuantity>
<center value="9" unit="1"/>
</doseQuantity>
</syntaxhighlight>

=== Ratio of quantities (RTO_QTY_QTY) ===

Elements of this data type specify ratios and have two child elements, a numerator and a denominator. The underlying QTY (Quantity) data type is an abstract data type and in a XML instance it has to be replaced by a specific data type using the ''@xsi:type'' instruction (see below).

In this specification only “PQ” or “INT” are allowed for the demotion of both ''numerator'' and ''denominator''. The relevant child elements are:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''numerator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the numerator of the ratio
|-
| '''denominator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the denominator of the ratio
|}

If a model attribute already is a RTO_QTY_QTY, you need to specify (demote) the OTY abstract data type for both ''numerator'' and ''denominator'' by using an ''@xsi:type'' instruction.
In some cases where the model attribute is of type “ANY”, also the root element shall carry an ''@xsi:type'' RTO_QTY_QTY instruction.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<maxDoseQuantity>
<numerator xsi:type="PQ" value="6"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="400" unit="mg"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="5"/>
<denominator xsi:type="PQ" value="1" unit="h"/>
</maxDoseQuantity>

<value xsi:type="RTO_QTY_QTY">
<numerator xsi:type="INT" value="1"/>
<denominator xsi:type="INT" value="10000"/>
</value>
</syntaxhighlight>

== Identification mechanisms ==

=== Object Identifiers (OIDs) ===

Standardized exchange of information using messages or documents also deals with unique identifications of objects and concepts, especially in environments where sender and receiver do not “know” each other necessarily.

It is important to understand the difference between identification of instances (ids) and code concepts (classifications). Within the context of HL7 interactions OIDs are quite often used.
An id points to a specific instance of an object or identification scheme (a particular methodology for the identification of a class of objects), for example a specific person as the patient or a physician, a specific lab observation or an X-ray photo.

In contrast to instance identifiers, a classification identifies a specific concept. The type of patient (inpatient, outpatient), the type of doctor (an anesthesiologist), the codes for gender or a lab observation (blood cell count) may serve as examples.

OIDs (object identifiers) are worldwide unique identifiers for objects. They are used in HL7 to specify identifications and classifications. An object in this sense is persistent, well-defined information, definitions or specifications and is represented with ids or codes.

Commonly used OIDs (i.e. used for a purpose that is wider in scope than the regional healthcare organization; used in communications between healthcare regions) can be found in OIDs registries such as

* [http://www.oid-info.com www.oid-info.com],
* [http://www.hl7.org www.hl7.org],
* [http://www.hl7.org.uk/version3group/oids.asp HL7 OID registry in the UK],
* [https://www.dimdi.de/dynamic/de/klassifikationen/weitere-klassifikationen-und-standards/oid/ OID registry Germany].

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|All OIDs with an element of 999 or 9999 are for documentation purposes only. They will be replaced by permanent OIDs once these have been as-signed/found/applied for.
|}

OID (Object Identifiers) are unique identifiers for any kind of objects. They are defined in Rec. ITU-T X.660 | ISO/IEC 9834-1. This identification system for objects and concepts makes reliable electronic information exchange possible. Administration and Registration is regulated by a set of rules, described in the corresponding chapter of this document.

Every artefact in ART-DECOR has an Object Identifier (OID). There are recommendations for the management and the exchange of Object Identifiers, partially defined in ISO TS 13582 <ref>ISO TS 13582: https://www.iso.org/standard/69652.html</ref>.

''HL7 International'' has created a type ontology for the OIDs in the HL7 registry to make it easier for the user community to search for OIDs they may be looking for and can be found at hl7.org.

From a policy perspective it is common practice in several healthcare related OID registries (HL7 International at http://www.hl7.org, OID Registry Germany at http://www.dimdi.de, OID registry Switzerland at http://oid.refdata.ch, and OID registry Austria at https://www.gesundheit.gv.at/OID_Frontend) to distinguish at least between the following types of OIDs:

{| class="hl7table" style="width:60%"
|+<ref group="Table">Recommended OID sub-branches for different artefacts</ref> ''Recommended OID sub-branches for different artefacts''
! Arc !! Description
|-
| .3 || organizational bodies and groups
|-
| .4 || identifier systems and namespaces
|-
| .5 || code systems
|-
| .7 || document artefacts
|-
| .9 || conformance profiles
|-
| .10 || templates
|-
| .11 || value sets
|-
| .19 || examples
|-
| .99 || experimental
|}

''Example: given that “your” root OID is 1.2.3.4.5, the first value set of your governance group is then to be 1.2.3.4.5.11.1, with .11 as the value set “branch” and the last .1 as the first artefact of that kind.''

In ART-DECOR a project typically is set into the .77 branch of a governance group. When setting up the project, the OID for that project also determines the artefact OIDs using throughout the ART-DECOR project. The following additional branches are used to distinguish between different OID types:

{| class="hl7table"
|+<ref group="Table">Recommended OID sub-branches for ART-DECOR projects</ref> ''Recommended OID sub-branches for different artefacts''
! Artefact code Description !! Recommended !! OID suffix
|-
| DS || dataset || .77.1
|-
| DE || dataset concept || .77.2
|-
| SC || scenario || .77.3
|-
| TR || transaction in scenario || .77.4
|-
| CS || code system || .77.5
|-
| IS || issue || .77.6
|-
| AC || actor in scenario || .77.7
|-
| CL || concept list in dataset || .77.8
|-
| EL || element in template || .77.9
|-
| TM || template || .77.10
|-
| VS || value set || .77.11
|-
| RL || rule for instances || .77.12
|-
| SX || test/example scenario || .77.18
|-
| EX || test/example instance || .77.19
|-
| QX || qualification test/example || .77.20
|-
| TX || test/example data element || .77.21
|-
| CM || community || .77.22
|-
| MP || concept map || .77.24
|}

In ART-DECOR a newly created project uses these OID branches automatically.

=== Instance identification ===

Instance identification is done with the id element of a class. Its type is II (instance identifier) and described in the data type section above. For example, a patient number can be represented as
* 2.16.578.1.34.1.5432.1, the root-OID of the issuing authority, for example a system/application in a hospital, and
* 67543242 as the ''@extension'', representing the patient number within the system defined by the ''@root'' attribute.

=== Coding scheme identification ===

Coding schemes have to be uniquely identified using OIDs as well. All coding tables used in this implementation guide show the corresponding OID that has to be specified in the ''@codeSystem'' attribute of coded elements. Both attributes ''@code'' and ''@codeSystem'' together allows a correct interpretation of concept and code.

=== List of identification schemes ===

The following are OIDs for commonly used identification schemes.

{| class="hl7table"
|+<ref group="Table">Commonly used identification scheme OIDs</ref> ''Commonly used identification scheme OIDs''
! OID !! Identification System Name !! Description !! Issuer
|-
| 1.2.276.0.76.4.8 || KV-Nummer || Krankenversichertennummer ||
|-
| 1.2.276.0.76.4.17 || BSNR || Betriebsstättennummer ||
|-
| 1.2.276.0.76.4.16 || LANR || lebenslange Arztnummer ||
|}

=== List of code systems ===

The following are OIDs for code systems.

{| class="hl7table"
|+<ref group="Table">Commonly used code system OIDs</ref> ''Commonly used code system OIDs''
! OID !! Code System Name !! Description !! Issuer
|-
| 2.16.840.1.113883.6.1 || LOINC || Logical Observation Identifiers Names and Codes (LOINC) || Regenstrief Institute
|-
| 2.16.840.1.113883.6.96 || SNOMED CT || Systemized Nomenclature in Medicine Reference Terminology (SNOMED CT) || SNOMED International
|-
| 1.0.3166.1.2 || ISO 3166-1 (second edition) || Country codes as per ISO 3166-1:2007 || ISO
|}

== Vocabulary ==

=== Code Systems ===

Within HL7, a ''Code System'' is defined as a collection of codes with associated designations and meanings. Examples of code systems include ICD-10, SNOMED CT, and LOINC.
To meet the requirements of a code system as defined by HL7, a given code must resolve to one and only one meaning within the code system. Given this definition, each code table in the HL7 Version 3 standard represents a different code system since codes are sometimes used in different tables to have different meanings.
For example, “M” in the administrative gender table (''AdministrativeGender'', OID 2.16.840.1.113883.5.1) means “male”, while “M” in the marital status table (''MaritalStatus'', OID 2.16.840.1.113883.5.2) means “married”.
In this specification, code system tables are not presented in detail.

=== Value Sets ===

A ''Value Set'' represents a uniquely identifiable set of valid concept representations, where any concept representation can be tested to determine whether or not it is a member of the value set.
Value set complexity may range from a simple flat list of concept codes drawn from a single code system, to an unbounded hierarchical set of possibly post-coordinated expressions drawn from multiple code systems.
Value sets exist to constrain the content for a coded element in an HL7 static model or data type property. Value sets cannot have null content and must contain at least one concept representation where any given concept is generally (but not required to be) represented by only a single code within the Value Set.

[[File:CDA_Core_Principles_Figure_3_ValueSet_Example.png|800px]]

<ref group="Figure">Example presentation of the value set “MaritalStatus”</ref> ''Example presentation of the value set “MaritalStatus”''

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that value set OIDs never appear in a CDA Release 2 document. They are used for constraint expressions, for example in implementation guides.
In order to send a specific code drawn from a value set, the corresponding code system has to be conveyed.
An example, in the implementation specification the constraint on the model element ''maritalStatusCode'' is expressed as “to be drawn from value set 2.16.840.1.113883.5.2 ''MaritalStatus''”.
To actually send a marital status of “M” (married) that is shown in the value set figure above, the corresponding HL7 CDA instance would say:
<syntaxhighlight lang="xml">
<maritalStatusCode code="M" codeSystem="2.16.840.1.113883.5.2"/>
</syntaxhighlight>
|}

In this specification, value set tables are not presented in detail.

==== Binding strength ====

There is an optional vocabulary strength for data types that support that feature (coded concepts). Examples include CD, CE, CV and CO. Values are required, extensible, preferred and example. Default is required.

Please note: the formerly supported values CNE (Coded No Extensibility) and CWE (Coded With Extensibility) in ART-DECOR are deprecated as of December 2017. Specification CNE is handled as required and CWE is handled as extensible.

{| class="hl7table"
|+<ref group="Table">Binding Strengths</ref> ''Binding Strengths''
! Strength !! Description
|-
|required||Required/CNE. Coded with no exceptions; this element SHALL be from the specified value set
|-
|extensible||Extensible/CWE. Coded with Exceptions; this element SHALL be from the specified value set if any of the codes within the value set can apply to the concept being communicated. If the value set does not cover the concept (based on human review), alternate codings (or, data type allowing, text) may be included instead.
|-
|preferred||Preferred. Instances are encouraged to draw from the specified codes for interoperability purposes but are not required to do so to be considered conformant.
|-
|example||Example. Instances are not expected or even encouraged to draw from the specified value set. The value set merely provides examples of the types of concepts intended to be included.
|}

Mismatches with required lead to validation errors (SHALL logic). Mismatches with extensible lead to validation warnings (SHOULD logic). Mismatches with preferred lead to validation information messages (MAY logic). Mismatches with example don't have any validation consequences.

== Appendix ==

=== References ===

<references/>

=== List of figures ===

<references group="Figure" />

=== List of tables ===

<references group="Table" />

HL7 CDA Core Principles

2019-06-16T11:17:39Z

Dammon: /* Intervals (IVL) */

== Introduction ==

This implementation guide specifies the ''Core Principles'' of using the ''Clinical Document Architecture'' <ref>Clinical Document Architecture Release 2: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=7</ref>.

=== Scope ===

This guide focuses on ''Data Types Release 1'' <ref>HL7 Data Types Release 1: http://www.hl7.org</ref>. Meanwhile an ISO specification ISO 21090 is out, also known as Data Type Release 2. The latter is subject to another implementation guide that will be published when ISO data types are used.

=== Focus of this document: HL7 Version 3 Data Types for CDA ===

The following chapters of this document will focus on the description of the data types and associated material. It will highlight the essentials in four chapters, all focusing on the Norwegian situation.
* '''Common aspects:''' explains common aspects of use of CDA and XML
* '''Data types:''' gives an overview and detailed specification of all data types used in CDA
* '''Identification schemes:''' explains major aspects of identification and the use in CDA
* '''Use of vocabulary:''' explains major aspects of vocabulary use in CDA.

=== Background ===

In many (European) countries, implementation guides for the use of data types in HL7 V3 are published. They take into account country specific constraints on the data types.

=== Legend of symbols ===

In this document several symbols are used.

{| class="hl7table" style="width:50%"
| [[File:Pfeil_rechts.png|50px]] || This is an important item
|-
| [[File:Issue.svg|50px]] || This is a known open issue
|-
| [[File:Faq.svg|50px]] || This is a frequently asked question (FAQ) with answer
|-
| [[File:Conformance.svg|50px]] || This is a constraint; in some situations also the rule identification is specified, e.g. dtr1-1-ANY, which links to the corresponding validation rule.
|}

=== Version history ===

{| class="hl7table" style="width:50%"
|+
! Version !! Date !! Description !! Author
|-
| 1.1 || 2019-04-24 || Refurbished guide based on earlier work || Kai U. Heitmann
|}

== Common aspects ==

=== Use of XML ===

HL7 Version 3 CDA uses the Extensible Markup Language (XML) as the exchange format. It is assumed that the reader is familiar with common XML aspects. However, some constraints are made regarding the use of CDA.

==== Character Set ====

{{ConstraintBox|
The character encoding of any CDA document shall be “UTF-8”.}}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="utf-8"?>
</syntaxhighlight>

=== CDA document structure ===

The XML namespace for CDA Release 2 documents is ''<nowiki>urn:hl7-org:v3</nowiki>''. This must be correctly mentioned in every XML instance.

CDA XML documents starts with the root element ''ClinicalDocument''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">


...

<component>
<structuredBody>
...
</structuredBody>
</component>

</ClinicalDocument>
</syntaxhighlight>

== Data types ==

=== Introduction ===

The following chapter describes the typical data types used in CDA implementation guides. For further information please refer to the HL7 V3 standard and its two parts concerning data types:
* Abstract Data type definition <ref>HL7 Version 3 Abstract Data type definition: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=264</ref>
* XML ITS for data types <ref>XML ITS for data types: https://www.hl7.org/documentcenter/public_temp_682D4D16-1C23-BA17-0C789BA52BEDB68E/wg/inm/datatypes-its-xml20050714.htm</ref>
Data types are properties of model class attributes and the basic building blocks of information in a CDA XML instance. For example, a model attribute named “time” has as its data type a time stamp “TS” (see Figure 1).

[[File:CDA_Core_Principles_Figure_1_CDA_Structure_Data_Types.png|700px]]

<ref group="Figure">CDA structure (left) and the data type specification (right)</ref> ''CDA structure (left) and the data type specification (right)''

=== XML representation of data types ===

Actual data is mostly carried in HL7 Version 3 by populating XML attributes and not as element content. Exceptions are names of persons and organizations as well as addresses.

The XML elements have names like the model attributes. For example, a model attribute “id” has a corresponding XML element named <id…>. The model determines the sequence of elements and their hierarchy. The data type itself determines the XML attributes within the start tag. The notation here is as follows:

{| class="hl7table"
|+
! Attribute !! DT !! Conf !! Description
|-
| (name of the model attribute or XML element) || Data type || Conformance, i.e. O, R, M || Textual description
|}

XML attributes (data type properties) are denoted as ''@attribute'' in order to distinguish their names from XML elements.

Example: in the example model above, the data type of the ''id'' attribute's is ''II'' (Instance Identifier). The corresponding XML attributes for that data type include ''@root'' and ''@extension''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id root="..." extension="..." />
</syntaxhighlight>

A description of the data types and their corresponding XML representation is contained in subsequent paragraphs of this guide.

==== Exceptions using XML element content ====

For most data types, the actual data is conveyed in XML attributes. However, there are some exceptions. For the data types binary (BIN), Encapsulated Data (ED), Entity Name (EN), Person Name (PN), Organization Name (ON), Trivial Name (TN), Address (AD) and character string data (ST), information is carried as element content.

Example: the components of an address <addr> are represented by sub elements with the data as element content (in the example shown in black).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr>
<streetAddressLine>Thormøhlens gate 12</streetAddressLine>
<postalCode>5006</postalCode>
<city>Bergen</city>
</addr>
</syntaxhighlight>

==== Combined data types ====

There are a number of so-called combined data types. For example, an interval with a lower and upper limit and a ratio that has a nominator and a denominator value.

In combined data types the substructure (e.g. <low> <high> in an interval) are represented as child elements of the relevant data type element.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110701"/>
<high value="20110729"/>
</effectiveTime>
</syntaxhighlight>

==== Conformance information ====

The conformance indicators distinguish kinds of conformance information described shortly here.

* '''O''': An optional item may be omitted if no data is present, i.e. no corresponding XML attribute or element is sent (marked as “O”)
* '''R''': For required items, lower cardinality is always zero or 1.
** Elements must be present and populated with data if present in the sending system. If no data is available (yet), a null flavor (see below) indicates and possibly classifies the missing information (marked as R).
** Attribute flagged as required must be present in the instance and populated.
* '''M''': For mandatory elements data must be sent and no missing values are allowed, i.e. if the sending system does not have information for mandatory elements the XML instance cannot be created and sent (marked as M).
* '''NP''': no data may be present at all (not permitted)
* '''C''': conditional conformance; typically a conformance table shows the circumstances (conditions) derived from information in the instance and the corresponding cardinalities and conformance statements.

=== Missing values (null flavor) ===

For every data type it is possible to specify a missing value including a kind of reason why data is missing. Instead of specifying any attribute of the corresponding element, a ''@nullFlavor'' attribute expresses the omission of data. Note that missing data is not allowed for mandatory elements (see above).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value nullFlavor="OTH"/>

<code nullFlavor="UNK"/>

<booleanInd nullFlavor="NI"/>

</syntaxhighlight>

The codes for the ''@nullFlavor'' attribute are drawn from the following hierarchical code system. It is a Coded Simple (CS), which means it has no code system (attribute ''@codeSystem'') specified.

{| class="hl7table"
|+<ref group="Table">NullFlavor</ref> ''NullFlavor''
! Code
! width=15% | Print Name
! Definition / Description
|-
| NI || No Information || No information whatsoever can be inferred from this exceptional value. This is the most general exceptional value. It is also the default exceptional value.
|-
|   OTH || other || The actual value is not an element in the value domain of a variable. (e.g., concept not provided by required code system).
|-
|     NINF || negative infinity || Negative infinity of numbers.
|-
|     PINF || positive infinity || Positive infinity of numbers.
|-
|   UNK || unknown || A proper value is applicable, but not known.
|-
|     ASKU || asked but unknown || Information was sought but not found (e.g., patient was asked but didn't know)
|-
|       NAV || temporarily unavailable || Information is not available at this time but it is expected that it will be available later.
|-
|       NASK || not asked || This information has not been sought (e.g., patient was not asked)
|-
|       TRC || trace || The content is greater than zero, but too small to be quantified.
|-
|   MSK || masked || There is information on this item available but it has not been provided by the sender due to security, privacy or other reasons. There may be an alternate mechanism for gaining access to this information.
Note: using this null flavour does provide information that may be a breach of confidentiality, even though no detail data is provided. Its primary purpose is for those circumstances where it is necessary to inform the receiver that the information does exist without providing any detail.
|-
|   NA || not applicable || No proper value is applicable in this context (e.g., last menstrual period for a male).
|-
| NP || not present || Value is not present in a message. This is only defined in messages, never in application data! All values not present in the message must be replaced by the applicable default, or no-information (NI) as the default of all defaults.
|}

=== ANY as the generic data type ===

This abstract data type is the basis for all other data types. Not a single value within a CDA document has the effective data type ANY, but any data type within HL7v3 is a specialization of ANY. This also means that any other data type inherits all properties of ANY (see [[#Missing_values_.28null_flavor.29|“Missing values (null flavor)”]]).

The ANY type is occasionally found in HL7 models when it comes to clinical finding etc. where – at model time – the actual data type of the value is not known. At instantiation time however, the actual data type ''is'' known and ANY is always replaced by a particular data type in an instance.

One example is the observation value (child element value in an observation), where in the model the data type of value cannot be anticipated. When instantiation is taking place, the data type is specified by the XML instance attribute ''@xsi:type''. This information can be used by the receiver to validate and process the value.

Attributes of an element with this data type are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@nullFlavor''' || <center>CS</center> || <center>–</center> || Classification of the missing value, see [[#Missing_values_.28null_flavor.29|3.3 Missing values (null flavor)]].
|}

{| class="hl7table" style="width:100%"
| width=8% | <center>[[File:Conformance.svg|50px]] dtr1-1-ANY</center> || If there is a ''nullFlavor'', there shall be no other attribute or element, unless it's ''nullFlavor="OTH"''.

In that case ''@codeSystem'' or ''originalText'' (see “code” data types) may have a value.
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">

<value xsi:type="CE" code="N11.9" codeSystem="2.16.840.1.113883.6.3"/>


<value xsi:type="PQ" value="12" unit="mL"/>


<value xsi:type="ED">this is text</value>
</syntaxhighlight>

=== Boolean (BL) ===

Elements of this data type refer to Boolean logic and have an attribute ''@value''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>BL</center> || <center>–</center> || Valued as “true” or “false”
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<negationInd value="false"/>

<deceasedInd value="true"/>

</syntaxhighlight>

In some situations, the BL data does not apply to an XML element, but an attribute. In that case, the attribute carries the Boolean value directly.
<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<support contextConductionInd ="false">
...
</support>
</syntaxhighlight>

=== Instance Identifier (II) ===

This data type identifies instances of classes like observations or entities (persons, organizations). Attributes are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@extension''' || <center>ST</center> || <center>O</center> || Identification
|-
| '''@root''' || <center>OID</center> || <center>R</center> || Source of identification
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id extension="13234453645" root="2.16.840.1.113883.2.6.15.3.427.1"/>
</syntaxhighlight>

The ''@root'' attribute is of type OID (object identifier), a unique identifier of the issuing authority or system. For example, a patient with a patient number 13234453645 created by a specific healthcare provider organization is uniquely identified by the number itself in ''@extension'' and the OID of the organization or the sending system, in the example 2.16.840.1.113883.2.6.15.3.427.1 in ''@root''.

In some cases, a single OID identifies an object uniquely. In that situation, only ''@root'' is populated and ''@extension'' is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Encapsulated Data (ED) ===

Elements of this data type carry multimedia content. The actual multimedia content is represented as element content. There are two situations for the use of ED:

* Inline: The full data is transmitted in the type. This form is mainly used for text.
* By reference: a thumbnail is provided which links to the full data by reference.

In an instance, the data type is normally determined by an ''xsi:type'' specification and some attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@mediaType''' || <center>CS</center> || <center>O</center> || MIME media type classification. At time of writing this specification, the following MIME types are allowed:
* text/plain (plain text)
* text/html (text with html markup)
* image/jpeg (JPEG image)
* application/pdf (a PDF, portable document format)
* application/hl7-sda+xml (CDA documents).
|-
| '''@representation''' || <center>CS</center> || <center>O</center> || Representation of the multimedia content. At time of writing this specification, the following representations are allowed:
* TXT (text, this is the default)
* B64 base 64 encoded data, for example for embedded CDA documents).
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<text xsi:type="ED" mediaType="text/plain">
Patient treated sucessfully
</text>

<text mediaType="application/hl7-sda+xml" representation="B64">PD94bWw..etc..==</text>

</syntaxhighlight>

To include referenced data the two sub elements ''thumbnail'' and ''reference'' are used.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''reference''' || <center>TEL</center> || <center>0..*</center> || <center>O</center> || Link (URI) to full data
|-
| '''thumbnail''' || <center>ED</center> || <center>0..*</center> || <center>O</center> || Thumbnail of referenced data
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value xsi:type="ED" mediaType="image/png" representation="B64">
<reference value="http://radiology.bergen.no/xrays/128s.png"/>
<thumbnail mediaType="image/jpeg" representation="B64"> MNY...83== </thumbnail>
</value>
</syntaxhighlight>

=== Strings (ST) ===

This data type is a specialization of the ED type where ''@mediaType'' is fixed “text/plain” and ''@representation'' is fixed “TXT”. It allows conveying a character string as '''element content'''. This data type is used in other data types it like the ''@extension'' in instance identifiers, or address and person name data type components.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<lotNumber> 143GT6DT </lotNumber>
</syntaxhighlight>

=== Concept Descriptor (CD) ===

This data type specifies a concept by means of a code and its code system (except for situations where no code is available).

A couple of specializations of data type CD exist, which differ in the main characteristics (properties) of the data type that may or may not be supported.

{| class="hl7table" style="width:50%"
|+<ref group="Table">Properties of data types used for codes</ref> ''Properties of data types used for codes''
! <div style="text-align: right">DataType</div> !! CD !! CE !! CV !! CO !! CS
|-
! <div style="text-align: left">Property</div> !! !! !! !! !!
|-
| '''@code''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||<center>X</center>
|-
| '''@codeSystem''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''@codeSystemVersion''' || <center>X</center> || <center>X</center> || <center>X</center>|| <center>X</center> ||
|-
| '''@displayName''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''originalText''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''translation''' || <center>X</center> || <center>X</center> || || ||
|-
| '''qualifier''' || <center>X</center> || || || ||
|}

Because the CE variant is most used in practice, the general explanation of the properties will be given with de description of CE (see below).

The only attribute that is unique to CD is briefly explained here.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@qualifier''' || <center>CR</center> || <center>O</center> || An additional qualifier for the code.
|}

Complex terminologies like SNOMED CT can be used only using data type CD.

=== Coded with Equivalents (CE) ===

With elements of this data type, a concept by means of a code and its coding system (except for situations where no code is available) can be specified. It optionally contains one or more equivalents using other code systems.

It may contain the following attributes:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@code''' || <center>ST</center> || <center>R</center> || The actual code
|-
| '''@codeSystem''' || <center>OID</center> || <center>R</center> || required to identify the code system were the code is drawn from. This is an OID (object identifier, see [[#Object_Identifiers_.28OIDs.29|Object Identifiers at 4.1]])
|-
| '''@displayName''' || <center>ST</center> || <center>O</center> || Optional textual representation of code. A display name may be specified representing the plain text of the code. The information of this attribute may not be used by the receiving system for interpretation, but only for display purposes. The display name may never be transmitted without a code and must have the same meaning as the code.
|-
| '''@codeSystemName''' || <center>ST</center> || <center>O</center> || A textual representation of the name of the code system
|-
| '''@codeSystemVersion''' || <center>ST</center> || <center>O</center> || A textual representation of the version of the code system
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"/>

<code code="AU" codeSystem="2.16.840.1.113883.5.33"/>

<storageCode code="AC" codeSystem="2.16.840.1.113883.5.34" displayName="active"/>

<code code="A45.0" displayName="Somatisierungsstörung" codeSystem="1.2.276.0.76.5.409" codeSystemName="ICD-10 GM 2012"/>
</syntaxhighlight>

There are some child elements of codes that can be used to express what the “original text” was that was used for the coding or to indicate that there are “translations” to other code systems than the primary code.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''originalText''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Textual representation of the concept, actually a description which was used to create the actual code
|}

No semantics may be assumed other than showing the ''@displayName'' to a user to clarify the code. A display name cannot occur without its code and must carry the same meaning.

In case no code is known, it is allowed to specify a ''@nullFlavor'' for the code element and to give information about the (not yet coded) concept in original text. However, this should be an exception.

If other codes than the primary code need to be conveyed adding a translation child element can be used.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<originalText>minor aphthous stomatitis</originalText>
</code>
</syntaxhighlight>

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''translation''' || <center>CD</center> || <center>0..*</center> || <center>O</center> || Alternative code(s)
|}

A ''translation'' element is also of type CD and shall have a code and a code system identified. It shall point to the same concept as the primary code. It is allowed that a translation conveys less conceptual details than the original code.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<translation code="528.2" codeSystem="2.16.840.1.113883.6.2" codeSystemName="ICD9" displayName="Oral aphthae"/>
</code>
</syntaxhighlight>

=== Coded Value (CV) ===

This is actually a specialization of CE (see above), with the exception that neither ''originalText'' nor ''translation'' child element are allowed.

=== Coded Simple Value (CS) ===

This is actually a specialization of CE (see above), with no code system attribute and no original text or translation child element allowed. It specifies a concept by means of a code from a ''predefined'' code system (table) where the code is drawn from. This data type is usually applied in the context of fixed predefined HL7 tables.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<statusCode code="completed"/>
</syntaxhighlight>

In this example ''statusCode'' is bound in the underlying model to the specific code system ''ActStatus''. Because it is predefined by means of the vocabulary binding, ''@codeSystem'' is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Telecommunication Address (TEL) ===

Elements of this type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>ST</center> || <center>R</center> || carries strings that represent telecommunication contact information
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

The actual data is preceded by the scheme (refer to Internet Standard “RFC 1738 Uniform Resource Locators (URL)” <ref>RFC 1738 Uniform Resource Locators (URL): http://www.ietf.org/rfc/rfc1738.txt</ref>.

Examples:
* telephone (tel:),
* fax (fax:),
* email (mailto:).

It must follow the rules defined in Internet “RFC 2806 URLs for Telephone Calls” <ref>RFC 2806 URLs for Telephone Calls: http://www.ietf.org/rfc/rfc2806.txt</ref>.

The following codes will be used in the “use” attribute:
* H – Home
* WP – Work
* MC can be used (in addition to H or WP) to denote that this is a mobile phone.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257" />

<telecom use="H" value="tel:55354257" />

<telecom use="H" value="fax:56542558" />

<telecom value="tel:+41.34.21.4765342"/>

<telecom value="mailto:opr@opr-sem.no"/>

<telecom use="WP MC" value="tel:97555786" />
</syntaxhighlight>

It is possible to express the useable period of a telecommunication contact. A child element ''useablePeriod'' is used as a time interval to indicate this period.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''useablePeriod''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257">
<useablePeriod>
<high value="20111201"/>
</useablePeriod>
</telecom>
</syntaxhighlight>

=== Postal Address (AD) ===

Elements of this data type have a substructure in order to represent a structured address specification. In this implementation guide only a selection of all possible child elements is allowed, the original HL7 specification is richer.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''streetAddressLine''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Street address, includes street name and house number
|-
| '''city''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || City
|-
| '''postalCode''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Postal code
|-
| '''country''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Country
|-
|}

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that the sequence of the sub elements is country specific, i.e. it has to follow “common” rules how to write an address. For example, an UK address and a German address have different sequences of address representation.
|}

A ''@use'' attribute can also be specified.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="WP">
<streetAddressLine>Anna-Louisa-Karsch-Str. 2</streetAddressLine>
<postalCode>10178</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="H WP">
<streetAddressLine>Tatungasse 34</streetAddressLine>
<postalCode>10825</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

Also, a country may be specified using the element ''country''.

=== Person Name (PN) ===

Elements of this data type do also have a substructure to represent the parts of a person name, like family or given name and prefixes.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>
<given>Franz</given>
<given>Ingrun</given>
<family>Nordmann</family>
</name>
</syntaxhighlight>

Previous or birth or maiden names are supported using the ''validTime'' element. ''validTime'' (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]]) specifies the validity range of the name.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">

<name>
<given>Jan</given>
<given>Olaf</given>
<family>Hendrikson</family>
<validTime>
<high value="20000101"/>
</validTime>
</name>
</syntaxhighlight>

Note that the name attribute is repeating, i.e. multiple (types of) names could be sent. It is up to the receiver (based on the value of the ''@use'' attribute, and ''validTime'') to decide what name it wants to use or import in its database.

=== Organisation Name (ON) ===

Elements of this data type represent a name of an organization.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name> Charité Berlin </name>
</syntaxhighlight>

The optional ''validTime'' element (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]] may be used to specify the validity range of the name of the organization.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name of the organization
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>The old hospital
<validTime>
<high value="20111231235959"/>
</validTime>
</name>
</syntaxhighlight>

Please note that the use of ''validTime'' yields XML mixed content which should be avoided if possible.

=== Integer Number (INT) ===

Elements of this data type are used to specify integer numbers and have one attribute.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>int</center> || <center>R</center> || Integer value
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<sequenceNumber value="24"/>
</syntaxhighlight>

=== Physical Quantities (PQ) ===

Elements of this data type are physical quantities, i.e. a measurable quantity (or countable) value from the physical world. This is different from just a “number”, because there is a (natural) unit specified in which the measurable quantity is expressed.
Examples:
* an amount of blood 20 ml (sample volume)
* a cut with a length of 10 cm (result observation)
* a dose of 200 milligrams per administration (dosing)
* delivery of 60 pieces of a tablet (amount supplied).
Elements of this data type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>real</center> || <center>R</center> || value of the measurement
|-
| '''@unit''' || <center>CS</center> || <center>R</center> || unit of measurement
|}

In the unit of measurement unit is expressed following the ''Unified Code for Units of Measure'' (UCUM) specification. This specification is a collection of atomic units, prefixes and a corresponding grammar for valid combinations to build all-natural units of measurement. For a complete description of possible units, see the ''Unified Code for Units of Measure'' <ref>Unified Code for Units of Measure: http://unitsofmeasure.org/</ref> specification.

If a value is not countable or if measurable, for example expressed in milligrams or liters, then this unit is a valid UCUM unit like “mg” or “L”. If a value is countable, for example the number of tablets, then this attribute contains “1”.

In HL7 it is required that all PQ data type units are valid UCUM units.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<value value="165" unit="cm"/>

<value value="81.1" unit="kg"/>

<value value="120" unit="mm[Hg]"/>

<value value="5" unit="1"/>
</syntaxhighlight>

=== Point in Time (TS) ===

Elements of this data type have the attribute

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>TS</center> || <center>R</center> || Point in time
|}

and specify points in time in the format YYYYMMDDhhmmss±ZZZZ, where
* YYYY is the four-digit year,
* MM the two-digit month,
* DD the two-digit day,
* hh the two-digit hour,
* mm the two-digits minute and
* ss the two-digit second.
Optional a time zone ZZZZ, the four-digit time alignment with a preceding “-” or a “+” can be specified. If time zone is omitted, local time is assumed.

The point in time may be right truncated in respect to the precision of the information.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<effectiveTime value="20140412"/>

<effectiveTime value="201409091245"/>

<effectiveTime value="1996"/>

<birthTime value="19540714"/>

<effectiveTime value="20140412+0100"/>
</syntaxhighlight>

=== Intervals (IVL) ===

Intervals are defined only for data types with an ordinal or interval scale type. There are several possibilities to determine an interval (see Figure 2), for example to specify

* a lower <low> and an upper boundary <high> (a),
* a lower <low> boundary and width <width> (b)
* an upper boundary and width <width> (c) or
* the middle of the interval <nowiki><center></nowiki> and a width <width> (d).

[[File:CDA_Core_Principles_Figure_2_Determining_Intervals.png|700px]]

<ref group="Figure">Several possibilities to determine closed intervals</ref> ''Several possibilities to determine closed intervals''

In addition, there is sometimes the need to specify incomplete intervals (open intervals). For example, an interval with only an upper limit to indicate a maximum dose or a start date and time only to express “since…”.

{{ConstraintBox|
To indicate an interval, only the following combinations are permitted.
(1) A lower and an upper boundary may not be identical, and their accuracy has to be equal.

Correct examples:

{{BeginGreenBox|}}
Interval from 5 to 6
Interval from 20110607 until 20110612
{{EndGreenBox}}

Incorrect examples:

{{BeginRedBox|}}
Interval from 5 to 6.0
Interval from 20110101 to 2011
{{EndRedBox|}}

(2) A lower boundary and a width

(3) A lower limit boundary

(4) A upper limit boundary

(5) Only the middle of the interval

(6) Only the width of an interval}}

Accordingly, four child elements are available.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Lower boundary
|-
| '''high''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Upper boundary
|-
| '''center''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Where ''(T)'' is defined in this specification as one of the data types “TS” or “PQ”.

=== Interval of time (IVL_TS) ===

Elements of this data type represent time intervals. There are four possible child elements.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Lower boundary (start date/time)
|-
| '''high''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Upper boundary (end date/time)
|-
| '''center''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Normally, a lower and an upper boundary is given, both are points in time. Also, it is possible to specify open intervals like “since June 14, 1999” (left boundary given only) or “until September 24, 2006” (right boundary given).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110507"/>
<high value="20110909"/>
</effectiveTime>

<effectiveTime>
<low value="20110507"/>
</effectiveTime>

<value>
<low value="20110101"/>
<width value="120" unit="d"/>
</value>

<value>
<center value="20110101"/>
</value>
</syntaxhighlight>

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|It must be noted that intervals of time stamps in HL7 are equally treated as other interval types (e.g. integers). The statement, one may take 1–3 tablets (interval of integers), for example, says that you are allowed to take no more than three tablets, not 3½ or 3.5 tablets. On the other hand, when treat the words “until 12 June 2011” regarding the upper interval limit differently, particularly we assume that the entire day 12 June is still in-cluded in this time interval.
Thus, in human perception time intervals are handled differently com-pared to such as number intervals. This is a situation may lead to inconsist-encies in standardized communication. As a conclusion, an upper limit “12 June 2011” means that only the very first moment of the 12 June is included in the interval, but not, for example, the 12 June 13:00 hours.
Interpretation does not depend on the accuracy of the time:
* “after 2004” means “from January 1, 2005 00:00:00.000”,
* “after 20041201” means “from 2 December 2004 00:00:00.000 hours”,
* and “after 200412011200” means “from 1 December 2004 12:01:00.000”.

As a result, you have to carefully consider the specification and implemen-tation of time intervals upper boundaries. In order to prevent mis-understandings intervals are always specified with the date and time for an upper limit that would cover the whole day. Accordingly, “201106122359” means 12 June 2011 throughout the day.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="201106122359"/>
</effectiveTime>
</syntaxhighlight>

Because of the equal treatment of time intervals this is applied also to the lower limit boundaries of time intervals as “0000”. This means for example that “since 9 June 2011” is expressed as “201106090000”.
|}

The <width> element is of data type PQ (physical quantity). The value obviously shall relate to a period of time and it is required to include a “time” unit. These are the units “us” (microseconds), “ms” (milliseconds), “s” (seconds), “min” (minute), “h” (hours), “d” (day), “wk” (week), “mo” (month) and “a” (year).

{{ConstraintBox|
For interval of time stamps the @unit of a ''low'' or ''high'' child element shall use units
* us (microseconds),
* ms (milliseconds),
* s (seconds),
* min (minute),
* h (hours),
* d (day),
* wk (week),
* mo (month) or
* a (year).
}}

=== Interval of physical quantities (IVL_PQ) ===

Elements of this data type are used to indicate intervals of physical quantities (see also [[#Physical Quantities (PQ)|3.18 Physical Quantities (PQ)]]). In general, an upper and a lower boundary is specified. It is also possible to use ''center'' instead of ''low'' and ''high''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low || <center>TS</center> || <center>0..1</center> || <center>C</center> || the lower limit of the interval (i.e. the minimum amount).
|-
| '''high || <center>TS</center> || <center>0..1</center> || <center>C</center> || the upper limit of the interval (i.e. the maximum amount).
|-
| '''center || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of the interval
|}

The ''center'' child element is used when there is no interval, but an exact value. Alternative would be to demote IVL_PQ to data type PQ and populate the element’s ''@value'' attribute, but this is more difficult to process in XML. That is why the use of the ''center'' child element is deprecated.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<referenceRange>
<low value="7.5" unit="mmol/l"/>
<high value="10" unit="mmol/l"/>
</referenceRange>

<doseQuantity>
<center value="9" unit="1"/>
</doseQuantity>
</syntaxhighlight>

=== Ratio of quantities (RTO_QTY_QTY) ===

Elements of this data type specify ratios and have two child elements, a numerator and a denominator. The underlying QTY (Quantity) data type is an abstract data type and in a XML instance it has to be replaced by a specific data type using the ''@xsi:type'' instruction (see below).

In this specification only “PQ” or “INT” are allowed for the demotion of both ''numerator'' and ''denominator''. The relevant child elements are:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''numerator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the numerator of the ratio
|-
| '''denominator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the denominator of the ratio
|}

If a model attribute already is a RTO_QTY_QTY, you need to specify (demote) the OTY abstract data type for both ''numerator'' and ''denominator'' by using an ''@xsi:type'' instruction.
In some cases where the model attribute is of type “ANY”, also the root element shall carry an ''@xsi:type'' RTO_QTY_QTY instruction.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<maxDoseQuantity>
<numerator xsi:type="PQ" value="6"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="400" unit="mg"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="5"/>
<denominator xsi:type="PQ" value="1" unit="h"/>
</maxDoseQuantity>

<value xsi:type="RTO_QTY_QTY">
<numerator xsi:type="INT" value="1"/>
<denominator xsi:type="INT" value="10000"/>
</value>
</syntaxhighlight>

== Identification mechanisms ==

=== Object Identifiers (OIDs) ===

Standardized exchange of information using messages or documents also deals with unique identifications of objects and concepts, especially in environments where sender and receiver do not “know” each other necessarily.

It is important to understand the difference between identification of instances (ids) and code concepts (classifications). Within the context of HL7 interactions OIDs are quite often used.
An id points to a specific instance of an object or identification scheme (a particular methodology for the identification of a class of objects), for example a specific person as the patient or a physician, a specific lab observation or an X-ray photo.

In contrast to instance identifiers, a classification identifies a specific concept. The type of patient (inpatient, outpatient), the type of doctor (an anesthesiologist), the codes for gender or a lab observation (blood cell count) may serve as examples.

OIDs (object identifiers) are worldwide unique identifiers for objects. They are used in HL7 to specify identifications and classifications. An object in this sense is persistent, well-defined information, definitions or specifications and is represented with ids or codes.

Commonly used OIDs (i.e. used for a purpose that is wider in scope than the regional healthcare organization; used in communications between healthcare regions) can be found in OIDs registries such as

* [http://www.oid-info.com www.oid-info.com],
* [http://www.hl7.org www.hl7.org],
* [http://www.hl7.org.uk/version3group/oids.asp HL7 OID registry in the UK],
* [https://www.dimdi.de/dynamic/de/klassifikationen/weitere-klassifikationen-und-standards/oid/ OID registry Germany].

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|All OIDs with an element of 999 or 9999 are for documentation purposes only. They will be replaced by permanent OIDs once these have been as-signed/found/applied for.
|}

OID (Object Identifiers) are unique identifiers for any kind of objects. They are defined in Rec. ITU-T X.660 | ISO/IEC 9834-1. This identification system for objects and concepts makes reliable electronic information exchange possible. Administration and Registration is regulated by a set of rules, described in the corresponding chapter of this document.

Every artefact in ART-DECOR has an Object Identifier (OID). There are recommendations for the management and the exchange of Object Identifiers, partially defined in ISO TS 13582 <ref>ISO TS 13582: https://www.iso.org/standard/69652.html</ref>.

''HL7 International'' has created a type ontology for the OIDs in the HL7 registry to make it easier for the user community to search for OIDs they may be looking for and can be found at hl7.org.

From a policy perspective it is common practice in several healthcare related OID registries (HL7 International at http://www.hl7.org, OID Registry Germany at http://www.dimdi.de, OID registry Switzerland at http://oid.refdata.ch, and OID registry Austria at https://www.gesundheit.gv.at/OID_Frontend) to distinguish at least between the following types of OIDs:

{| class="hl7table" style="width:60%"
|+<ref group="Table">Recommended OID sub-branches for different artefacts</ref> ''Recommended OID sub-branches for different artefacts''
! Arc !! Description
|-
| .3 || organizational bodies and groups
|-
| .4 || identifier systems and namespaces
|-
| .5 || code systems
|-
| .7 || document artefacts
|-
| .9 || conformance profiles
|-
| .10 || templates
|-
| .11 || value sets
|-
| .19 || examples
|-
| .99 || experimental
|}

''Example: given that “your” root OID is 1.2.3.4.5, the first value set of your governance group is then to be 1.2.3.4.5.11.1, with .11 as the value set “branch” and the last .1 as the first artefact of that kind.''

In ART-DECOR a project typically is set into the .77 branch of a governance group. When setting up the project, the OID for that project also determines the artefact OIDs using throughout the ART-DECOR project. The following additional branches are used to distinguish between different OID types:

{| class="hl7table"
|+<ref group="Table">Recommended OID sub-branches for ART-DECOR projects</ref> ''Recommended OID sub-branches for different artefacts''
! Artefact code Description !! Recommended !! OID suffix
|-
| DS || dataset || .77.1
|-
| DE || dataset concept || .77.2
|-
| SC || scenario || .77.3
|-
| TR || transaction in scenario || .77.4
|-
| CS || code system || .77.5
|-
| IS || issue || .77.6
|-
| AC || actor in scenario || .77.7
|-
| CL || concept list in dataset || .77.8
|-
| EL || element in template || .77.9
|-
| TM || template || .77.10
|-
| VS || value set || .77.11
|-
| RL || rule for instances || .77.12
|-
| SX || test/example scenario || .77.18
|-
| EX || test/example instance || .77.19
|-
| QX || qualification test/example || .77.20
|-
| TX || test/example data element || .77.21
|-
| CM || community || .77.22
|-
| MP || concept map || .77.24
|}

In ART-DECOR a newly created project uses these OID branches automatically.

=== Instance identification ===

Instance identification is done with the id element of a class. Its type is II (instance identifier) and described in the data type section above. For example, a patient number can be represented as
* 2.16.578.1.34.1.5432.1, the root-OID of the issuing authority, for example a system/application in a hospital, and
* 67543242 as the ''@extension'', representing the patient number within the system defined by the ''@root'' attribute.

=== Coding scheme identification ===

Coding schemes have to be uniquely identified using OIDs as well. All coding tables used in this implementation guide show the corresponding OID that has to be specified in the ''@codeSystem'' attribute of coded elements. Both attributes ''@code'' and ''@codeSystem'' together allows a correct interpretation of concept and code.

=== List of identification schemes ===

The following are OIDs for commonly used identification schemes.

{| class="hl7table"
|+<ref group="Table">Commonly used identification scheme OIDs</ref> ''Commonly used identification scheme OIDs''
! OID !! Identification System Name !! Description !! Issuer
|-
| 1.2.276.0.76.4.8 || KV-Nummer || Krankenversichertennummer ||
|-
| 1.2.276.0.76.4.17 || BSNR || Betriebsstättennummer ||
|-
| 1.2.276.0.76.4.16 || LANR || lebenslange Arztnummer ||
|}

=== List of code systems ===

The following are OIDs for code systems.

{| class="hl7table"
|+<ref group="Table">Commonly used code system OIDs</ref> ''Commonly used code system OIDs''
! OID !! Code System Name !! Description !! Issuer
|-
| 2.16.840.1.113883.6.1 || LOINC || Logical Observation Identifiers Names and Codes (LOINC) || Regenstrief Institute
|-
| 2.16.840.1.113883.6.96 || SNOMED CT || Systemized Nomenclature in Medicine Reference Terminology (SNOMED CT) || SNOMED International
|-
| 1.0.3166.1.2 || ISO 3166-1 (second edition) || Country codes as per ISO 3166-1:2007 || ISO
|}

== Vocabulary ==

=== Code Systems ===

Within HL7, a ''Code System'' is defined as a collection of codes with associated designations and meanings. Examples of code systems include ICD-10, SNOMED CT, and LOINC.
To meet the requirements of a code system as defined by HL7, a given code must resolve to one and only one meaning within the code system. Given this definition, each code table in the HL7 Version 3 standard represents a different code system since codes are sometimes used in different tables to have different meanings.
For example, “M” in the administrative gender table (''AdministrativeGender'', OID 2.16.840.1.113883.5.1) means “male”, while “M” in the marital status table (''MaritalStatus'', OID 2.16.840.1.113883.5.2) means “married”.
In this specification, code system tables are not presented in detail.

=== Value Sets ===

A ''Value Set'' represents a uniquely identifiable set of valid concept representations, where any concept representation can be tested to determine whether or not it is a member of the value set.
Value set complexity may range from a simple flat list of concept codes drawn from a single code system, to an unbounded hierarchical set of possibly post-coordinated expressions drawn from multiple code systems.
Value sets exist to constrain the content for a coded element in an HL7 static model or data type property. Value sets cannot have null content and must contain at least one concept representation where any given concept is generally (but not required to be) represented by only a single code within the Value Set.

[[File:CDA_Core_Principles_Figure_3_ValueSet_Example.png|800px]]

<ref group="Figure">Example presentation of the value set “MaritalStatus”</ref> ''Example presentation of the value set “MaritalStatus”''

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that value set OIDs never appear in a CDA Release 2 document. They are used for constraint expressions, for example in implementation guides.
In order to send a specific code drawn from a value set, the corresponding code system has to be conveyed.
An example, in the implementation specification the constraint on the model element ''maritalStatusCode'' is expressed as “to be drawn from value set 2.16.840.1.113883.5.2 ''MaritalStatus''”.
To actually send a marital status of “M” (married) that is shown in the value set figure above, the corresponding HL7 CDA instance would say:
<syntaxhighlight lang="xml">
<maritalStatusCode code="M" codeSystem="2.16.840.1.113883.5.2"/>
</syntaxhighlight>
|}

In this specification, value set tables are not presented in detail.

==== Binding strength ====

There is an optional vocabulary strength for data types that support that feature (coded concepts). Examples include CD, CE, CV and CO. Values are required, extensible, preferred and example. Default is required.

Please note: the formerly supported values CNE (Coded No Extensibility) and CWE (Coded With Extensibility) in ART-DECOR are deprecated as of December 2017. Specification CNE is handled as required and CWE is handled as extensible.

{| class="hl7table"
|+<ref group="Table">Binding Strengths</ref> ''Binding Strengths''
! Strength !! Description
|-
|required||Required/CNE. Coded with no exceptions; this element SHALL be from the specified value set
|-
|extensible||Extensible/CWE. Coded with Exceptions; this element SHALL be from the specified value set if any of the codes within the value set can apply to the concept being communicated. If the value set does not cover the concept (based on human review), alternate codings (or, data type allowing, text) may be included instead.
|-
|preferred||Preferred. Instances are encouraged to draw from the specified codes for interoperability purposes but are not required to do so to be considered conformant.
|-
|example||Example. Instances are not expected or even encouraged to draw from the specified value set. The value set merely provides examples of the types of concepts intended to be included.
|}

Mismatches with required lead to validation errors (SHALL logic). Mismatches with extensible lead to validation warnings (SHOULD logic). Mismatches with preferred lead to validation information messages (MAY logic). Mismatches with example don't have any validation consequences.

== Appendix ==

=== References ===

<references/>

=== List of figures ===

<references group="Figure" />

=== List of tables ===

<references group="Table" />

HL7 CDA Core Principles

2019-06-16T11:15:52Z

Dammon: /* Point in Time (TS) */

== Introduction ==

This implementation guide specifies the ''Core Principles'' of using the ''Clinical Document Architecture'' <ref>Clinical Document Architecture Release 2: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=7</ref>.

=== Scope ===

This guide focuses on ''Data Types Release 1'' <ref>HL7 Data Types Release 1: http://www.hl7.org</ref>. Meanwhile an ISO specification ISO 21090 is out, also known as Data Type Release 2. The latter is subject to another implementation guide that will be published when ISO data types are used.

=== Focus of this document: HL7 Version 3 Data Types for CDA ===

The following chapters of this document will focus on the description of the data types and associated material. It will highlight the essentials in four chapters, all focusing on the Norwegian situation.
* '''Common aspects:''' explains common aspects of use of CDA and XML
* '''Data types:''' gives an overview and detailed specification of all data types used in CDA
* '''Identification schemes:''' explains major aspects of identification and the use in CDA
* '''Use of vocabulary:''' explains major aspects of vocabulary use in CDA.

=== Background ===

In many (European) countries, implementation guides for the use of data types in HL7 V3 are published. They take into account country specific constraints on the data types.

=== Legend of symbols ===

In this document several symbols are used.

{| class="hl7table" style="width:50%"
| [[File:Pfeil_rechts.png|50px]] || This is an important item
|-
| [[File:Issue.svg|50px]] || This is a known open issue
|-
| [[File:Faq.svg|50px]] || This is a frequently asked question (FAQ) with answer
|-
| [[File:Conformance.svg|50px]] || This is a constraint; in some situations also the rule identification is specified, e.g. dtr1-1-ANY, which links to the corresponding validation rule.
|}

=== Version history ===

{| class="hl7table" style="width:50%"
|+
! Version !! Date !! Description !! Author
|-
| 1.1 || 2019-04-24 || Refurbished guide based on earlier work || Kai U. Heitmann
|}

== Common aspects ==

=== Use of XML ===

HL7 Version 3 CDA uses the Extensible Markup Language (XML) as the exchange format. It is assumed that the reader is familiar with common XML aspects. However, some constraints are made regarding the use of CDA.

==== Character Set ====

{{ConstraintBox|
The character encoding of any CDA document shall be “UTF-8”.}}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="utf-8"?>
</syntaxhighlight>

=== CDA document structure ===

The XML namespace for CDA Release 2 documents is ''<nowiki>urn:hl7-org:v3</nowiki>''. This must be correctly mentioned in every XML instance.

CDA XML documents starts with the root element ''ClinicalDocument''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">


...

<component>
<structuredBody>
...
</structuredBody>
</component>

</ClinicalDocument>
</syntaxhighlight>

== Data types ==

=== Introduction ===

The following chapter describes the typical data types used in CDA implementation guides. For further information please refer to the HL7 V3 standard and its two parts concerning data types:
* Abstract Data type definition <ref>HL7 Version 3 Abstract Data type definition: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=264</ref>
* XML ITS for data types <ref>XML ITS for data types: https://www.hl7.org/documentcenter/public_temp_682D4D16-1C23-BA17-0C789BA52BEDB68E/wg/inm/datatypes-its-xml20050714.htm</ref>
Data types are properties of model class attributes and the basic building blocks of information in a CDA XML instance. For example, a model attribute named “time” has as its data type a time stamp “TS” (see Figure 1).

[[File:CDA_Core_Principles_Figure_1_CDA_Structure_Data_Types.png|700px]]

<ref group="Figure">CDA structure (left) and the data type specification (right)</ref> ''CDA structure (left) and the data type specification (right)''

=== XML representation of data types ===

Actual data is mostly carried in HL7 Version 3 by populating XML attributes and not as element content. Exceptions are names of persons and organizations as well as addresses.

The XML elements have names like the model attributes. For example, a model attribute “id” has a corresponding XML element named <id…>. The model determines the sequence of elements and their hierarchy. The data type itself determines the XML attributes within the start tag. The notation here is as follows:

{| class="hl7table"
|+
! Attribute !! DT !! Conf !! Description
|-
| (name of the model attribute or XML element) || Data type || Conformance, i.e. O, R, M || Textual description
|}

XML attributes (data type properties) are denoted as ''@attribute'' in order to distinguish their names from XML elements.

Example: in the example model above, the data type of the ''id'' attribute's is ''II'' (Instance Identifier). The corresponding XML attributes for that data type include ''@root'' and ''@extension''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id root="..." extension="..." />
</syntaxhighlight>

A description of the data types and their corresponding XML representation is contained in subsequent paragraphs of this guide.

==== Exceptions using XML element content ====

For most data types, the actual data is conveyed in XML attributes. However, there are some exceptions. For the data types binary (BIN), Encapsulated Data (ED), Entity Name (EN), Person Name (PN), Organization Name (ON), Trivial Name (TN), Address (AD) and character string data (ST), information is carried as element content.

Example: the components of an address <addr> are represented by sub elements with the data as element content (in the example shown in black).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr>
<streetAddressLine>Thormøhlens gate 12</streetAddressLine>
<postalCode>5006</postalCode>
<city>Bergen</city>
</addr>
</syntaxhighlight>

==== Combined data types ====

There are a number of so-called combined data types. For example, an interval with a lower and upper limit and a ratio that has a nominator and a denominator value.

In combined data types the substructure (e.g. <low> <high> in an interval) are represented as child elements of the relevant data type element.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110701"/>
<high value="20110729"/>
</effectiveTime>
</syntaxhighlight>

==== Conformance information ====

The conformance indicators distinguish kinds of conformance information described shortly here.

* '''O''': An optional item may be omitted if no data is present, i.e. no corresponding XML attribute or element is sent (marked as “O”)
* '''R''': For required items, lower cardinality is always zero or 1.
** Elements must be present and populated with data if present in the sending system. If no data is available (yet), a null flavor (see below) indicates and possibly classifies the missing information (marked as R).
** Attribute flagged as required must be present in the instance and populated.
* '''M''': For mandatory elements data must be sent and no missing values are allowed, i.e. if the sending system does not have information for mandatory elements the XML instance cannot be created and sent (marked as M).
* '''NP''': no data may be present at all (not permitted)
* '''C''': conditional conformance; typically a conformance table shows the circumstances (conditions) derived from information in the instance and the corresponding cardinalities and conformance statements.

=== Missing values (null flavor) ===

For every data type it is possible to specify a missing value including a kind of reason why data is missing. Instead of specifying any attribute of the corresponding element, a ''@nullFlavor'' attribute expresses the omission of data. Note that missing data is not allowed for mandatory elements (see above).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value nullFlavor="OTH"/>

<code nullFlavor="UNK"/>

<booleanInd nullFlavor="NI"/>

</syntaxhighlight>

The codes for the ''@nullFlavor'' attribute are drawn from the following hierarchical code system. It is a Coded Simple (CS), which means it has no code system (attribute ''@codeSystem'') specified.

{| class="hl7table"
|+<ref group="Table">NullFlavor</ref> ''NullFlavor''
! Code
! width=15% | Print Name
! Definition / Description
|-
| NI || No Information || No information whatsoever can be inferred from this exceptional value. This is the most general exceptional value. It is also the default exceptional value.
|-
|   OTH || other || The actual value is not an element in the value domain of a variable. (e.g., concept not provided by required code system).
|-
|     NINF || negative infinity || Negative infinity of numbers.
|-
|     PINF || positive infinity || Positive infinity of numbers.
|-
|   UNK || unknown || A proper value is applicable, but not known.
|-
|     ASKU || asked but unknown || Information was sought but not found (e.g., patient was asked but didn't know)
|-
|       NAV || temporarily unavailable || Information is not available at this time but it is expected that it will be available later.
|-
|       NASK || not asked || This information has not been sought (e.g., patient was not asked)
|-
|       TRC || trace || The content is greater than zero, but too small to be quantified.
|-
|   MSK || masked || There is information on this item available but it has not been provided by the sender due to security, privacy or other reasons. There may be an alternate mechanism for gaining access to this information.
Note: using this null flavour does provide information that may be a breach of confidentiality, even though no detail data is provided. Its primary purpose is for those circumstances where it is necessary to inform the receiver that the information does exist without providing any detail.
|-
|   NA || not applicable || No proper value is applicable in this context (e.g., last menstrual period for a male).
|-
| NP || not present || Value is not present in a message. This is only defined in messages, never in application data! All values not present in the message must be replaced by the applicable default, or no-information (NI) as the default of all defaults.
|}

=== ANY as the generic data type ===

This abstract data type is the basis for all other data types. Not a single value within a CDA document has the effective data type ANY, but any data type within HL7v3 is a specialization of ANY. This also means that any other data type inherits all properties of ANY (see [[#Missing_values_.28null_flavor.29|“Missing values (null flavor)”]]).

The ANY type is occasionally found in HL7 models when it comes to clinical finding etc. where – at model time – the actual data type of the value is not known. At instantiation time however, the actual data type ''is'' known and ANY is always replaced by a particular data type in an instance.

One example is the observation value (child element value in an observation), where in the model the data type of value cannot be anticipated. When instantiation is taking place, the data type is specified by the XML instance attribute ''@xsi:type''. This information can be used by the receiver to validate and process the value.

Attributes of an element with this data type are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@nullFlavor''' || <center>CS</center> || <center>–</center> || Classification of the missing value, see [[#Missing_values_.28null_flavor.29|3.3 Missing values (null flavor)]].
|}

{| class="hl7table" style="width:100%"
| width=8% | <center>[[File:Conformance.svg|50px]] dtr1-1-ANY</center> || If there is a ''nullFlavor'', there shall be no other attribute or element, unless it's ''nullFlavor="OTH"''.

In that case ''@codeSystem'' or ''originalText'' (see “code” data types) may have a value.
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">

<value xsi:type="CE" code="N11.9" codeSystem="2.16.840.1.113883.6.3"/>


<value xsi:type="PQ" value="12" unit="mL"/>


<value xsi:type="ED">this is text</value>
</syntaxhighlight>

=== Boolean (BL) ===

Elements of this data type refer to Boolean logic and have an attribute ''@value''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>BL</center> || <center>–</center> || Valued as “true” or “false”
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<negationInd value="false"/>

<deceasedInd value="true"/>

</syntaxhighlight>

In some situations, the BL data does not apply to an XML element, but an attribute. In that case, the attribute carries the Boolean value directly.
<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<support contextConductionInd ="false">
...
</support>
</syntaxhighlight>

=== Instance Identifier (II) ===

This data type identifies instances of classes like observations or entities (persons, organizations). Attributes are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@extension''' || <center>ST</center> || <center>O</center> || Identification
|-
| '''@root''' || <center>OID</center> || <center>R</center> || Source of identification
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id extension="13234453645" root="2.16.840.1.113883.2.6.15.3.427.1"/>
</syntaxhighlight>

The ''@root'' attribute is of type OID (object identifier), a unique identifier of the issuing authority or system. For example, a patient with a patient number 13234453645 created by a specific healthcare provider organization is uniquely identified by the number itself in ''@extension'' and the OID of the organization or the sending system, in the example 2.16.840.1.113883.2.6.15.3.427.1 in ''@root''.

In some cases, a single OID identifies an object uniquely. In that situation, only ''@root'' is populated and ''@extension'' is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Encapsulated Data (ED) ===

Elements of this data type carry multimedia content. The actual multimedia content is represented as element content. There are two situations for the use of ED:

* Inline: The full data is transmitted in the type. This form is mainly used for text.
* By reference: a thumbnail is provided which links to the full data by reference.

In an instance, the data type is normally determined by an ''xsi:type'' specification and some attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@mediaType''' || <center>CS</center> || <center>O</center> || MIME media type classification. At time of writing this specification, the following MIME types are allowed:
* text/plain (plain text)
* text/html (text with html markup)
* image/jpeg (JPEG image)
* application/pdf (a PDF, portable document format)
* application/hl7-sda+xml (CDA documents).
|-
| '''@representation''' || <center>CS</center> || <center>O</center> || Representation of the multimedia content. At time of writing this specification, the following representations are allowed:
* TXT (text, this is the default)
* B64 base 64 encoded data, for example for embedded CDA documents).
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<text xsi:type="ED" mediaType="text/plain">
Patient treated sucessfully
</text>

<text mediaType="application/hl7-sda+xml" representation="B64">PD94bWw..etc..==</text>

</syntaxhighlight>

To include referenced data the two sub elements ''thumbnail'' and ''reference'' are used.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''reference''' || <center>TEL</center> || <center>0..*</center> || <center>O</center> || Link (URI) to full data
|-
| '''thumbnail''' || <center>ED</center> || <center>0..*</center> || <center>O</center> || Thumbnail of referenced data
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value xsi:type="ED" mediaType="image/png" representation="B64">
<reference value="http://radiology.bergen.no/xrays/128s.png"/>
<thumbnail mediaType="image/jpeg" representation="B64"> MNY...83== </thumbnail>
</value>
</syntaxhighlight>

=== Strings (ST) ===

This data type is a specialization of the ED type where ''@mediaType'' is fixed “text/plain” and ''@representation'' is fixed “TXT”. It allows conveying a character string as '''element content'''. This data type is used in other data types it like the ''@extension'' in instance identifiers, or address and person name data type components.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<lotNumber> 143GT6DT </lotNumber>
</syntaxhighlight>

=== Concept Descriptor (CD) ===

This data type specifies a concept by means of a code and its code system (except for situations where no code is available).

A couple of specializations of data type CD exist, which differ in the main characteristics (properties) of the data type that may or may not be supported.

{| class="hl7table" style="width:50%"
|+<ref group="Table">Properties of data types used for codes</ref> ''Properties of data types used for codes''
! <div style="text-align: right">DataType</div> !! CD !! CE !! CV !! CO !! CS
|-
! <div style="text-align: left">Property</div> !! !! !! !! !!
|-
| '''@code''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||<center>X</center>
|-
| '''@codeSystem''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''@codeSystemVersion''' || <center>X</center> || <center>X</center> || <center>X</center>|| <center>X</center> ||
|-
| '''@displayName''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''originalText''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''translation''' || <center>X</center> || <center>X</center> || || ||
|-
| '''qualifier''' || <center>X</center> || || || ||
|}

Because the CE variant is most used in practice, the general explanation of the properties will be given with de description of CE (see below).

The only attribute that is unique to CD is briefly explained here.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@qualifier''' || <center>CR</center> || <center>O</center> || An additional qualifier for the code.
|}

Complex terminologies like SNOMED CT can be used only using data type CD.

=== Coded with Equivalents (CE) ===

With elements of this data type, a concept by means of a code and its coding system (except for situations where no code is available) can be specified. It optionally contains one or more equivalents using other code systems.

It may contain the following attributes:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@code''' || <center>ST</center> || <center>R</center> || The actual code
|-
| '''@codeSystem''' || <center>OID</center> || <center>R</center> || required to identify the code system were the code is drawn from. This is an OID (object identifier, see [[#Object_Identifiers_.28OIDs.29|Object Identifiers at 4.1]])
|-
| '''@displayName''' || <center>ST</center> || <center>O</center> || Optional textual representation of code. A display name may be specified representing the plain text of the code. The information of this attribute may not be used by the receiving system for interpretation, but only for display purposes. The display name may never be transmitted without a code and must have the same meaning as the code.
|-
| '''@codeSystemName''' || <center>ST</center> || <center>O</center> || A textual representation of the name of the code system
|-
| '''@codeSystemVersion''' || <center>ST</center> || <center>O</center> || A textual representation of the version of the code system
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"/>

<code code="AU" codeSystem="2.16.840.1.113883.5.33"/>

<storageCode code="AC" codeSystem="2.16.840.1.113883.5.34" displayName="active"/>

<code code="A45.0" displayName="Somatisierungsstörung" codeSystem="1.2.276.0.76.5.409" codeSystemName="ICD-10 GM 2012"/>
</syntaxhighlight>

There are some child elements of codes that can be used to express what the “original text” was that was used for the coding or to indicate that there are “translations” to other code systems than the primary code.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''originalText''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Textual representation of the concept, actually a description which was used to create the actual code
|}

No semantics may be assumed other than showing the ''@displayName'' to a user to clarify the code. A display name cannot occur without its code and must carry the same meaning.

In case no code is known, it is allowed to specify a ''@nullFlavor'' for the code element and to give information about the (not yet coded) concept in original text. However, this should be an exception.

If other codes than the primary code need to be conveyed adding a translation child element can be used.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<originalText>minor aphthous stomatitis</originalText>
</code>
</syntaxhighlight>

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''translation''' || <center>CD</center> || <center>0..*</center> || <center>O</center> || Alternative code(s)
|}

A ''translation'' element is also of type CD and shall have a code and a code system identified. It shall point to the same concept as the primary code. It is allowed that a translation conveys less conceptual details than the original code.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<translation code="528.2" codeSystem="2.16.840.1.113883.6.2" codeSystemName="ICD9" displayName="Oral aphthae"/>
</code>
</syntaxhighlight>

=== Coded Value (CV) ===

This is actually a specialization of CE (see above), with the exception that neither ''originalText'' nor ''translation'' child element are allowed.

=== Coded Simple Value (CS) ===

This is actually a specialization of CE (see above), with no code system attribute and no original text or translation child element allowed. It specifies a concept by means of a code from a ''predefined'' code system (table) where the code is drawn from. This data type is usually applied in the context of fixed predefined HL7 tables.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<statusCode code="completed"/>
</syntaxhighlight>

In this example ''statusCode'' is bound in the underlying model to the specific code system ''ActStatus''. Because it is predefined by means of the vocabulary binding, ''@codeSystem'' is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Telecommunication Address (TEL) ===

Elements of this type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>ST</center> || <center>R</center> || carries strings that represent telecommunication contact information
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

The actual data is preceded by the scheme (refer to Internet Standard “RFC 1738 Uniform Resource Locators (URL)” <ref>RFC 1738 Uniform Resource Locators (URL): http://www.ietf.org/rfc/rfc1738.txt</ref>.

Examples:
* telephone (tel:),
* fax (fax:),
* email (mailto:).

It must follow the rules defined in Internet “RFC 2806 URLs for Telephone Calls” <ref>RFC 2806 URLs for Telephone Calls: http://www.ietf.org/rfc/rfc2806.txt</ref>.

The following codes will be used in the “use” attribute:
* H – Home
* WP – Work
* MC can be used (in addition to H or WP) to denote that this is a mobile phone.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257" />

<telecom use="H" value="tel:55354257" />

<telecom use="H" value="fax:56542558" />

<telecom value="tel:+41.34.21.4765342"/>

<telecom value="mailto:opr@opr-sem.no"/>

<telecom use="WP MC" value="tel:97555786" />
</syntaxhighlight>

It is possible to express the useable period of a telecommunication contact. A child element ''useablePeriod'' is used as a time interval to indicate this period.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''useablePeriod''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257">
<useablePeriod>
<high value="20111201"/>
</useablePeriod>
</telecom>
</syntaxhighlight>

=== Postal Address (AD) ===

Elements of this data type have a substructure in order to represent a structured address specification. In this implementation guide only a selection of all possible child elements is allowed, the original HL7 specification is richer.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''streetAddressLine''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Street address, includes street name and house number
|-
| '''city''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || City
|-
| '''postalCode''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Postal code
|-
| '''country''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Country
|-
|}

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that the sequence of the sub elements is country specific, i.e. it has to follow “common” rules how to write an address. For example, an UK address and a German address have different sequences of address representation.
|}

A ''@use'' attribute can also be specified.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="WP">
<streetAddressLine>Anna-Louisa-Karsch-Str. 2</streetAddressLine>
<postalCode>10178</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="H WP">
<streetAddressLine>Tatungasse 34</streetAddressLine>
<postalCode>10825</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

Also, a country may be specified using the element ''country''.

=== Person Name (PN) ===

Elements of this data type do also have a substructure to represent the parts of a person name, like family or given name and prefixes.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>
<given>Franz</given>
<given>Ingrun</given>
<family>Nordmann</family>
</name>
</syntaxhighlight>

Previous or birth or maiden names are supported using the ''validTime'' element. ''validTime'' (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]]) specifies the validity range of the name.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">

<name>
<given>Jan</given>
<given>Olaf</given>
<family>Hendrikson</family>
<validTime>
<high value="20000101"/>
</validTime>
</name>
</syntaxhighlight>

Note that the name attribute is repeating, i.e. multiple (types of) names could be sent. It is up to the receiver (based on the value of the ''@use'' attribute, and ''validTime'') to decide what name it wants to use or import in its database.

=== Organisation Name (ON) ===

Elements of this data type represent a name of an organization.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name> Charité Berlin </name>
</syntaxhighlight>

The optional ''validTime'' element (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]] may be used to specify the validity range of the name of the organization.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name of the organization
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>The old hospital
<validTime>
<high value="20111231235959"/>
</validTime>
</name>
</syntaxhighlight>

Please note that the use of ''validTime'' yields XML mixed content which should be avoided if possible.

=== Integer Number (INT) ===

Elements of this data type are used to specify integer numbers and have one attribute.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>int</center> || <center>R</center> || Integer value
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<sequenceNumber value="24"/>
</syntaxhighlight>

=== Physical Quantities (PQ) ===

Elements of this data type are physical quantities, i.e. a measurable quantity (or countable) value from the physical world. This is different from just a “number”, because there is a (natural) unit specified in which the measurable quantity is expressed.
Examples:
* an amount of blood 20 ml (sample volume)
* a cut with a length of 10 cm (result observation)
* a dose of 200 milligrams per administration (dosing)
* delivery of 60 pieces of a tablet (amount supplied).
Elements of this data type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>real</center> || <center>R</center> || value of the measurement
|-
| '''@unit''' || <center>CS</center> || <center>R</center> || unit of measurement
|}

In the unit of measurement unit is expressed following the ''Unified Code for Units of Measure'' (UCUM) specification. This specification is a collection of atomic units, prefixes and a corresponding grammar for valid combinations to build all-natural units of measurement. For a complete description of possible units, see the ''Unified Code for Units of Measure'' <ref>Unified Code for Units of Measure: http://unitsofmeasure.org/</ref> specification.

If a value is not countable or if measurable, for example expressed in milligrams or liters, then this unit is a valid UCUM unit like “mg” or “L”. If a value is countable, for example the number of tablets, then this attribute contains “1”.

In HL7 it is required that all PQ data type units are valid UCUM units.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<value value="165" unit="cm"/>

<value value="81.1" unit="kg"/>

<value value="120" unit="mm[Hg]"/>

<value value="5" unit="1"/>
</syntaxhighlight>

=== Point in Time (TS) ===

Elements of this data type have the attribute

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>TS</center> || <center>R</center> || Point in time
|}

and specify points in time in the format YYYYMMDDhhmmss±ZZZZ, where
* YYYY is the four-digit year,
* MM the two-digit month,
* DD the two-digit day,
* hh the two-digit hour,
* mm the two-digits minute and
* ss the two-digit second.
Optional a time zone ZZZZ, the four-digit time alignment with a preceding “-” or a “+” can be specified. If time zone is omitted, local time is assumed.

The point in time may be right truncated in respect to the precision of the information.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<effectiveTime value="20140412"/>

<effectiveTime value="201409091245"/>

<effectiveTime value="1996"/>

<birthTime value="19540714"/>

<effectiveTime value="20140412+0100"/>
</syntaxhighlight>

=== Intervals (IVL) ===

Intervals are defined only for data types with an ordinal or interval scale type. There are several possibilities to determine an interval (see Figure 2), for example to specify

* a lower <low> and an upper boundary <high> (a),
* a lower <low> boundary and width <width> (b)
* an upper boundary and width <width> (c) or
* the middle of the interval <nowiki><center></nowiki> and a width <width> (d).

[[File:CDA_Core_Principles_Figure_2_Determining_Intervals.png|700px]]

<ref group="Figure">Several possibilities to determine closed intervals</ref> ''Several possibilities to determine closed intervals''

{{ConstraintBox|
To indicate an interval, only the following combinations are permitted.
(1) A lower and an upper boundary may not be identical, and their accuracy has to be equal.

Correct examples:

{{BeginGreenBox|}}
Interval from 5 to 6
Interval from 20110607 until 20110612
{{EndGreenBox}}

Incorrect examples:

{{BeginRedBox|}}
Interval from 5 to 6.0
Interval from 20110101 to 2011
{{EndRedBox|}}

(2) A lower boundary and a width

(3) A lower limit boundary

(4) A upper limit boundary

(5) Only the middle of the interval

(6) Only the width of an interval}}

Accordingly, four child elements are available.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Lower boundary
|-
| '''high''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Upper boundary
|-
| '''center''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Where ''(T)'' is defined in this specification as one of the data types “TS” or “PQ”.

=== Interval of time (IVL_TS) ===

Elements of this data type represent time intervals. There are four possible child elements.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Lower boundary (start date/time)
|-
| '''high''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Upper boundary (end date/time)
|-
| '''center''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Normally, a lower and an upper boundary is given, both are points in time. Also, it is possible to specify open intervals like “since June 14, 1999” (left boundary given only) or “until September 24, 2006” (right boundary given).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110507"/>
<high value="20110909"/>
</effectiveTime>

<effectiveTime>
<low value="20110507"/>
</effectiveTime>

<value>
<low value="20110101"/>
<width value="120" unit="d"/>
</value>

<value>
<center value="20110101"/>
</value>
</syntaxhighlight>

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|It must be noted that intervals of time stamps in HL7 are equally treated as other interval types (e.g. integers). The statement, one may take 1–3 tablets (interval of integers), for example, says that you are allowed to take no more than three tablets, not 3½ or 3.5 tablets. On the other hand, when treat the words “until 12 June 2011” regarding the upper interval limit differently, particularly we assume that the entire day 12 June is still in-cluded in this time interval.
Thus, in human perception time intervals are handled differently com-pared to such as number intervals. This is a situation may lead to inconsist-encies in standardized communication. As a conclusion, an upper limit “12 June 2011” means that only the very first moment of the 12 June is included in the interval, but not, for example, the 12 June 13:00 hours.
Interpretation does not depend on the accuracy of the time:
* “after 2004” means “from January 1, 2005 00:00:00.000”,
* “after 20041201” means “from 2 December 2004 00:00:00.000 hours”,
* and “after 200412011200” means “from 1 December 2004 12:01:00.000”.

As a result, you have to carefully consider the specification and implemen-tation of time intervals upper boundaries. In order to prevent mis-understandings intervals are always specified with the date and time for an upper limit that would cover the whole day. Accordingly, “201106122359” means 12 June 2011 throughout the day.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="201106122359"/>
</effectiveTime>
</syntaxhighlight>

Because of the equal treatment of time intervals this is applied also to the lower limit boundaries of time intervals as “0000”. This means for example that “since 9 June 2011” is expressed as “201106090000”.
|}

The <width> element is of data type PQ (physical quantity). The value obviously shall relate to a period of time and it is required to include a “time” unit. These are the units “us” (microseconds), “ms” (milliseconds), “s” (seconds), “min” (minute), “h” (hours), “d” (day), “wk” (week), “mo” (month) and “a” (year).

{{ConstraintBox|
For interval of time stamps the @unit of a ''low'' or ''high'' child element shall use units
* us (microseconds),
* ms (milliseconds),
* s (seconds),
* min (minute),
* h (hours),
* d (day),
* wk (week),
* mo (month) or
* a (year).
}}

=== Interval of physical quantities (IVL_PQ) ===

Elements of this data type are used to indicate intervals of physical quantities (see also [[#Physical Quantities (PQ)|3.18 Physical Quantities (PQ)]]). In general, an upper and a lower boundary is specified. It is also possible to use ''center'' instead of ''low'' and ''high''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low || <center>TS</center> || <center>0..1</center> || <center>C</center> || the lower limit of the interval (i.e. the minimum amount).
|-
| '''high || <center>TS</center> || <center>0..1</center> || <center>C</center> || the upper limit of the interval (i.e. the maximum amount).
|-
| '''center || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of the interval
|}

The ''center'' child element is used when there is no interval, but an exact value. Alternative would be to demote IVL_PQ to data type PQ and populate the element’s ''@value'' attribute, but this is more difficult to process in XML. That is why the use of the ''center'' child element is deprecated.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<referenceRange>
<low value="7.5" unit="mmol/l"/>
<high value="10" unit="mmol/l"/>
</referenceRange>

<doseQuantity>
<center value="9" unit="1"/>
</doseQuantity>
</syntaxhighlight>

=== Ratio of quantities (RTO_QTY_QTY) ===

Elements of this data type specify ratios and have two child elements, a numerator and a denominator. The underlying QTY (Quantity) data type is an abstract data type and in a XML instance it has to be replaced by a specific data type using the ''@xsi:type'' instruction (see below).

In this specification only “PQ” or “INT” are allowed for the demotion of both ''numerator'' and ''denominator''. The relevant child elements are:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''numerator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the numerator of the ratio
|-
| '''denominator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the denominator of the ratio
|}

If a model attribute already is a RTO_QTY_QTY, you need to specify (demote) the OTY abstract data type for both ''numerator'' and ''denominator'' by using an ''@xsi:type'' instruction.
In some cases where the model attribute is of type “ANY”, also the root element shall carry an ''@xsi:type'' RTO_QTY_QTY instruction.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<maxDoseQuantity>
<numerator xsi:type="PQ" value="6"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="400" unit="mg"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="5"/>
<denominator xsi:type="PQ" value="1" unit="h"/>
</maxDoseQuantity>

<value xsi:type="RTO_QTY_QTY">
<numerator xsi:type="INT" value="1"/>
<denominator xsi:type="INT" value="10000"/>
</value>
</syntaxhighlight>

== Identification mechanisms ==

=== Object Identifiers (OIDs) ===

Standardized exchange of information using messages or documents also deals with unique identifications of objects and concepts, especially in environments where sender and receiver do not “know” each other necessarily.

It is important to understand the difference between identification of instances (ids) and code concepts (classifications). Within the context of HL7 interactions OIDs are quite often used.
An id points to a specific instance of an object or identification scheme (a particular methodology for the identification of a class of objects), for example a specific person as the patient or a physician, a specific lab observation or an X-ray photo.

In contrast to instance identifiers, a classification identifies a specific concept. The type of patient (inpatient, outpatient), the type of doctor (an anesthesiologist), the codes for gender or a lab observation (blood cell count) may serve as examples.

OIDs (object identifiers) are worldwide unique identifiers for objects. They are used in HL7 to specify identifications and classifications. An object in this sense is persistent, well-defined information, definitions or specifications and is represented with ids or codes.

Commonly used OIDs (i.e. used for a purpose that is wider in scope than the regional healthcare organization; used in communications between healthcare regions) can be found in OIDs registries such as

* [http://www.oid-info.com www.oid-info.com],
* [http://www.hl7.org www.hl7.org],
* [http://www.hl7.org.uk/version3group/oids.asp HL7 OID registry in the UK],
* [https://www.dimdi.de/dynamic/de/klassifikationen/weitere-klassifikationen-und-standards/oid/ OID registry Germany].

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|All OIDs with an element of 999 or 9999 are for documentation purposes only. They will be replaced by permanent OIDs once these have been as-signed/found/applied for.
|}

OID (Object Identifiers) are unique identifiers for any kind of objects. They are defined in Rec. ITU-T X.660 | ISO/IEC 9834-1. This identification system for objects and concepts makes reliable electronic information exchange possible. Administration and Registration is regulated by a set of rules, described in the corresponding chapter of this document.

Every artefact in ART-DECOR has an Object Identifier (OID). There are recommendations for the management and the exchange of Object Identifiers, partially defined in ISO TS 13582 <ref>ISO TS 13582: https://www.iso.org/standard/69652.html</ref>.

''HL7 International'' has created a type ontology for the OIDs in the HL7 registry to make it easier for the user community to search for OIDs they may be looking for and can be found at hl7.org.

From a policy perspective it is common practice in several healthcare related OID registries (HL7 International at http://www.hl7.org, OID Registry Germany at http://www.dimdi.de, OID registry Switzerland at http://oid.refdata.ch, and OID registry Austria at https://www.gesundheit.gv.at/OID_Frontend) to distinguish at least between the following types of OIDs:

{| class="hl7table" style="width:60%"
|+<ref group="Table">Recommended OID sub-branches for different artefacts</ref> ''Recommended OID sub-branches for different artefacts''
! Arc !! Description
|-
| .3 || organizational bodies and groups
|-
| .4 || identifier systems and namespaces
|-
| .5 || code systems
|-
| .7 || document artefacts
|-
| .9 || conformance profiles
|-
| .10 || templates
|-
| .11 || value sets
|-
| .19 || examples
|-
| .99 || experimental
|}

''Example: given that “your” root OID is 1.2.3.4.5, the first value set of your governance group is then to be 1.2.3.4.5.11.1, with .11 as the value set “branch” and the last .1 as the first artefact of that kind.''

In ART-DECOR a project typically is set into the .77 branch of a governance group. When setting up the project, the OID for that project also determines the artefact OIDs using throughout the ART-DECOR project. The following additional branches are used to distinguish between different OID types:

{| class="hl7table"
|+<ref group="Table">Recommended OID sub-branches for ART-DECOR projects</ref> ''Recommended OID sub-branches for different artefacts''
! Artefact code Description !! Recommended !! OID suffix
|-
| DS || dataset || .77.1
|-
| DE || dataset concept || .77.2
|-
| SC || scenario || .77.3
|-
| TR || transaction in scenario || .77.4
|-
| CS || code system || .77.5
|-
| IS || issue || .77.6
|-
| AC || actor in scenario || .77.7
|-
| CL || concept list in dataset || .77.8
|-
| EL || element in template || .77.9
|-
| TM || template || .77.10
|-
| VS || value set || .77.11
|-
| RL || rule for instances || .77.12
|-
| SX || test/example scenario || .77.18
|-
| EX || test/example instance || .77.19
|-
| QX || qualification test/example || .77.20
|-
| TX || test/example data element || .77.21
|-
| CM || community || .77.22
|-
| MP || concept map || .77.24
|}

In ART-DECOR a newly created project uses these OID branches automatically.

=== Instance identification ===

Instance identification is done with the id element of a class. Its type is II (instance identifier) and described in the data type section above. For example, a patient number can be represented as
* 2.16.578.1.34.1.5432.1, the root-OID of the issuing authority, for example a system/application in a hospital, and
* 67543242 as the ''@extension'', representing the patient number within the system defined by the ''@root'' attribute.

=== Coding scheme identification ===

Coding schemes have to be uniquely identified using OIDs as well. All coding tables used in this implementation guide show the corresponding OID that has to be specified in the ''@codeSystem'' attribute of coded elements. Both attributes ''@code'' and ''@codeSystem'' together allows a correct interpretation of concept and code.

=== List of identification schemes ===

The following are OIDs for commonly used identification schemes.

{| class="hl7table"
|+<ref group="Table">Commonly used identification scheme OIDs</ref> ''Commonly used identification scheme OIDs''
! OID !! Identification System Name !! Description !! Issuer
|-
| 1.2.276.0.76.4.8 || KV-Nummer || Krankenversichertennummer ||
|-
| 1.2.276.0.76.4.17 || BSNR || Betriebsstättennummer ||
|-
| 1.2.276.0.76.4.16 || LANR || lebenslange Arztnummer ||
|}

=== List of code systems ===

The following are OIDs for code systems.

{| class="hl7table"
|+<ref group="Table">Commonly used code system OIDs</ref> ''Commonly used code system OIDs''
! OID !! Code System Name !! Description !! Issuer
|-
| 2.16.840.1.113883.6.1 || LOINC || Logical Observation Identifiers Names and Codes (LOINC) || Regenstrief Institute
|-
| 2.16.840.1.113883.6.96 || SNOMED CT || Systemized Nomenclature in Medicine Reference Terminology (SNOMED CT) || SNOMED International
|-
| 1.0.3166.1.2 || ISO 3166-1 (second edition) || Country codes as per ISO 3166-1:2007 || ISO
|}

== Vocabulary ==

=== Code Systems ===

Within HL7, a ''Code System'' is defined as a collection of codes with associated designations and meanings. Examples of code systems include ICD-10, SNOMED CT, and LOINC.
To meet the requirements of a code system as defined by HL7, a given code must resolve to one and only one meaning within the code system. Given this definition, each code table in the HL7 Version 3 standard represents a different code system since codes are sometimes used in different tables to have different meanings.
For example, “M” in the administrative gender table (''AdministrativeGender'', OID 2.16.840.1.113883.5.1) means “male”, while “M” in the marital status table (''MaritalStatus'', OID 2.16.840.1.113883.5.2) means “married”.
In this specification, code system tables are not presented in detail.

=== Value Sets ===

A ''Value Set'' represents a uniquely identifiable set of valid concept representations, where any concept representation can be tested to determine whether or not it is a member of the value set.
Value set complexity may range from a simple flat list of concept codes drawn from a single code system, to an unbounded hierarchical set of possibly post-coordinated expressions drawn from multiple code systems.
Value sets exist to constrain the content for a coded element in an HL7 static model or data type property. Value sets cannot have null content and must contain at least one concept representation where any given concept is generally (but not required to be) represented by only a single code within the Value Set.

[[File:CDA_Core_Principles_Figure_3_ValueSet_Example.png|800px]]

<ref group="Figure">Example presentation of the value set “MaritalStatus”</ref> ''Example presentation of the value set “MaritalStatus”''

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that value set OIDs never appear in a CDA Release 2 document. They are used for constraint expressions, for example in implementation guides.
In order to send a specific code drawn from a value set, the corresponding code system has to be conveyed.
An example, in the implementation specification the constraint on the model element ''maritalStatusCode'' is expressed as “to be drawn from value set 2.16.840.1.113883.5.2 ''MaritalStatus''”.
To actually send a marital status of “M” (married) that is shown in the value set figure above, the corresponding HL7 CDA instance would say:
<syntaxhighlight lang="xml">
<maritalStatusCode code="M" codeSystem="2.16.840.1.113883.5.2"/>
</syntaxhighlight>
|}

In this specification, value set tables are not presented in detail.

==== Binding strength ====

There is an optional vocabulary strength for data types that support that feature (coded concepts). Examples include CD, CE, CV and CO. Values are required, extensible, preferred and example. Default is required.

Please note: the formerly supported values CNE (Coded No Extensibility) and CWE (Coded With Extensibility) in ART-DECOR are deprecated as of December 2017. Specification CNE is handled as required and CWE is handled as extensible.

{| class="hl7table"
|+<ref group="Table">Binding Strengths</ref> ''Binding Strengths''
! Strength !! Description
|-
|required||Required/CNE. Coded with no exceptions; this element SHALL be from the specified value set
|-
|extensible||Extensible/CWE. Coded with Exceptions; this element SHALL be from the specified value set if any of the codes within the value set can apply to the concept being communicated. If the value set does not cover the concept (based on human review), alternate codings (or, data type allowing, text) may be included instead.
|-
|preferred||Preferred. Instances are encouraged to draw from the specified codes for interoperability purposes but are not required to do so to be considered conformant.
|-
|example||Example. Instances are not expected or even encouraged to draw from the specified value set. The value set merely provides examples of the types of concepts intended to be included.
|}

Mismatches with required lead to validation errors (SHALL logic). Mismatches with extensible lead to validation warnings (SHOULD logic). Mismatches with preferred lead to validation information messages (MAY logic). Mismatches with example don't have any validation consequences.

== Appendix ==

=== References ===

<references/>

=== List of figures ===

<references group="Figure" />

=== List of tables ===

<references group="Table" />

HL7 CDA Core Principles

2019-06-16T11:15:07Z

Dammon: /* Physical Quantities (PQ) */

== Introduction ==

This implementation guide specifies the ''Core Principles'' of using the ''Clinical Document Architecture'' <ref>Clinical Document Architecture Release 2: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=7</ref>.

=== Scope ===

This guide focuses on ''Data Types Release 1'' <ref>HL7 Data Types Release 1: http://www.hl7.org</ref>. Meanwhile an ISO specification ISO 21090 is out, also known as Data Type Release 2. The latter is subject to another implementation guide that will be published when ISO data types are used.

=== Focus of this document: HL7 Version 3 Data Types for CDA ===

The following chapters of this document will focus on the description of the data types and associated material. It will highlight the essentials in four chapters, all focusing on the Norwegian situation.
* '''Common aspects:''' explains common aspects of use of CDA and XML
* '''Data types:''' gives an overview and detailed specification of all data types used in CDA
* '''Identification schemes:''' explains major aspects of identification and the use in CDA
* '''Use of vocabulary:''' explains major aspects of vocabulary use in CDA.

=== Background ===

In many (European) countries, implementation guides for the use of data types in HL7 V3 are published. They take into account country specific constraints on the data types.

=== Legend of symbols ===

In this document several symbols are used.

{| class="hl7table" style="width:50%"
| [[File:Pfeil_rechts.png|50px]] || This is an important item
|-
| [[File:Issue.svg|50px]] || This is a known open issue
|-
| [[File:Faq.svg|50px]] || This is a frequently asked question (FAQ) with answer
|-
| [[File:Conformance.svg|50px]] || This is a constraint; in some situations also the rule identification is specified, e.g. dtr1-1-ANY, which links to the corresponding validation rule.
|}

=== Version history ===

{| class="hl7table" style="width:50%"
|+
! Version !! Date !! Description !! Author
|-
| 1.1 || 2019-04-24 || Refurbished guide based on earlier work || Kai U. Heitmann
|}

== Common aspects ==

=== Use of XML ===

HL7 Version 3 CDA uses the Extensible Markup Language (XML) as the exchange format. It is assumed that the reader is familiar with common XML aspects. However, some constraints are made regarding the use of CDA.

==== Character Set ====

{{ConstraintBox|
The character encoding of any CDA document shall be “UTF-8”.}}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="utf-8"?>
</syntaxhighlight>

=== CDA document structure ===

The XML namespace for CDA Release 2 documents is ''<nowiki>urn:hl7-org:v3</nowiki>''. This must be correctly mentioned in every XML instance.

CDA XML documents starts with the root element ''ClinicalDocument''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">


...

<component>
<structuredBody>
...
</structuredBody>
</component>

</ClinicalDocument>
</syntaxhighlight>

== Data types ==

=== Introduction ===

The following chapter describes the typical data types used in CDA implementation guides. For further information please refer to the HL7 V3 standard and its two parts concerning data types:
* Abstract Data type definition <ref>HL7 Version 3 Abstract Data type definition: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=264</ref>
* XML ITS for data types <ref>XML ITS for data types: https://www.hl7.org/documentcenter/public_temp_682D4D16-1C23-BA17-0C789BA52BEDB68E/wg/inm/datatypes-its-xml20050714.htm</ref>
Data types are properties of model class attributes and the basic building blocks of information in a CDA XML instance. For example, a model attribute named “time” has as its data type a time stamp “TS” (see Figure 1).

[[File:CDA_Core_Principles_Figure_1_CDA_Structure_Data_Types.png|700px]]

<ref group="Figure">CDA structure (left) and the data type specification (right)</ref> ''CDA structure (left) and the data type specification (right)''

=== XML representation of data types ===

Actual data is mostly carried in HL7 Version 3 by populating XML attributes and not as element content. Exceptions are names of persons and organizations as well as addresses.

The XML elements have names like the model attributes. For example, a model attribute “id” has a corresponding XML element named <id…>. The model determines the sequence of elements and their hierarchy. The data type itself determines the XML attributes within the start tag. The notation here is as follows:

{| class="hl7table"
|+
! Attribute !! DT !! Conf !! Description
|-
| (name of the model attribute or XML element) || Data type || Conformance, i.e. O, R, M || Textual description
|}

XML attributes (data type properties) are denoted as ''@attribute'' in order to distinguish their names from XML elements.

Example: in the example model above, the data type of the ''id'' attribute's is ''II'' (Instance Identifier). The corresponding XML attributes for that data type include ''@root'' and ''@extension''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id root="..." extension="..." />
</syntaxhighlight>

A description of the data types and their corresponding XML representation is contained in subsequent paragraphs of this guide.

==== Exceptions using XML element content ====

For most data types, the actual data is conveyed in XML attributes. However, there are some exceptions. For the data types binary (BIN), Encapsulated Data (ED), Entity Name (EN), Person Name (PN), Organization Name (ON), Trivial Name (TN), Address (AD) and character string data (ST), information is carried as element content.

Example: the components of an address <addr> are represented by sub elements with the data as element content (in the example shown in black).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr>
<streetAddressLine>Thormøhlens gate 12</streetAddressLine>
<postalCode>5006</postalCode>
<city>Bergen</city>
</addr>
</syntaxhighlight>

==== Combined data types ====

There are a number of so-called combined data types. For example, an interval with a lower and upper limit and a ratio that has a nominator and a denominator value.

In combined data types the substructure (e.g. <low> <high> in an interval) are represented as child elements of the relevant data type element.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110701"/>
<high value="20110729"/>
</effectiveTime>
</syntaxhighlight>

==== Conformance information ====

The conformance indicators distinguish kinds of conformance information described shortly here.

* '''O''': An optional item may be omitted if no data is present, i.e. no corresponding XML attribute or element is sent (marked as “O”)
* '''R''': For required items, lower cardinality is always zero or 1.
** Elements must be present and populated with data if present in the sending system. If no data is available (yet), a null flavor (see below) indicates and possibly classifies the missing information (marked as R).
** Attribute flagged as required must be present in the instance and populated.
* '''M''': For mandatory elements data must be sent and no missing values are allowed, i.e. if the sending system does not have information for mandatory elements the XML instance cannot be created and sent (marked as M).
* '''NP''': no data may be present at all (not permitted)
* '''C''': conditional conformance; typically a conformance table shows the circumstances (conditions) derived from information in the instance and the corresponding cardinalities and conformance statements.

=== Missing values (null flavor) ===

For every data type it is possible to specify a missing value including a kind of reason why data is missing. Instead of specifying any attribute of the corresponding element, a ''@nullFlavor'' attribute expresses the omission of data. Note that missing data is not allowed for mandatory elements (see above).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value nullFlavor="OTH"/>

<code nullFlavor="UNK"/>

<booleanInd nullFlavor="NI"/>

</syntaxhighlight>

The codes for the ''@nullFlavor'' attribute are drawn from the following hierarchical code system. It is a Coded Simple (CS), which means it has no code system (attribute ''@codeSystem'') specified.

{| class="hl7table"
|+<ref group="Table">NullFlavor</ref> ''NullFlavor''
! Code
! width=15% | Print Name
! Definition / Description
|-
| NI || No Information || No information whatsoever can be inferred from this exceptional value. This is the most general exceptional value. It is also the default exceptional value.
|-
|   OTH || other || The actual value is not an element in the value domain of a variable. (e.g., concept not provided by required code system).
|-
|     NINF || negative infinity || Negative infinity of numbers.
|-
|     PINF || positive infinity || Positive infinity of numbers.
|-
|   UNK || unknown || A proper value is applicable, but not known.
|-
|     ASKU || asked but unknown || Information was sought but not found (e.g., patient was asked but didn't know)
|-
|       NAV || temporarily unavailable || Information is not available at this time but it is expected that it will be available later.
|-
|       NASK || not asked || This information has not been sought (e.g., patient was not asked)
|-
|       TRC || trace || The content is greater than zero, but too small to be quantified.
|-
|   MSK || masked || There is information on this item available but it has not been provided by the sender due to security, privacy or other reasons. There may be an alternate mechanism for gaining access to this information.
Note: using this null flavour does provide information that may be a breach of confidentiality, even though no detail data is provided. Its primary purpose is for those circumstances where it is necessary to inform the receiver that the information does exist without providing any detail.
|-
|   NA || not applicable || No proper value is applicable in this context (e.g., last menstrual period for a male).
|-
| NP || not present || Value is not present in a message. This is only defined in messages, never in application data! All values not present in the message must be replaced by the applicable default, or no-information (NI) as the default of all defaults.
|}

=== ANY as the generic data type ===

This abstract data type is the basis for all other data types. Not a single value within a CDA document has the effective data type ANY, but any data type within HL7v3 is a specialization of ANY. This also means that any other data type inherits all properties of ANY (see [[#Missing_values_.28null_flavor.29|“Missing values (null flavor)”]]).

The ANY type is occasionally found in HL7 models when it comes to clinical finding etc. where – at model time – the actual data type of the value is not known. At instantiation time however, the actual data type ''is'' known and ANY is always replaced by a particular data type in an instance.

One example is the observation value (child element value in an observation), where in the model the data type of value cannot be anticipated. When instantiation is taking place, the data type is specified by the XML instance attribute ''@xsi:type''. This information can be used by the receiver to validate and process the value.

Attributes of an element with this data type are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@nullFlavor''' || <center>CS</center> || <center>–</center> || Classification of the missing value, see [[#Missing_values_.28null_flavor.29|3.3 Missing values (null flavor)]].
|}

{| class="hl7table" style="width:100%"
| width=8% | <center>[[File:Conformance.svg|50px]] dtr1-1-ANY</center> || If there is a ''nullFlavor'', there shall be no other attribute or element, unless it's ''nullFlavor="OTH"''.

In that case ''@codeSystem'' or ''originalText'' (see “code” data types) may have a value.
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">

<value xsi:type="CE" code="N11.9" codeSystem="2.16.840.1.113883.6.3"/>


<value xsi:type="PQ" value="12" unit="mL"/>


<value xsi:type="ED">this is text</value>
</syntaxhighlight>

=== Boolean (BL) ===

Elements of this data type refer to Boolean logic and have an attribute ''@value''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>BL</center> || <center>–</center> || Valued as “true” or “false”
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<negationInd value="false"/>

<deceasedInd value="true"/>

</syntaxhighlight>

In some situations, the BL data does not apply to an XML element, but an attribute. In that case, the attribute carries the Boolean value directly.
<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<support contextConductionInd ="false">
...
</support>
</syntaxhighlight>

=== Instance Identifier (II) ===

This data type identifies instances of classes like observations or entities (persons, organizations). Attributes are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@extension''' || <center>ST</center> || <center>O</center> || Identification
|-
| '''@root''' || <center>OID</center> || <center>R</center> || Source of identification
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id extension="13234453645" root="2.16.840.1.113883.2.6.15.3.427.1"/>
</syntaxhighlight>

The ''@root'' attribute is of type OID (object identifier), a unique identifier of the issuing authority or system. For example, a patient with a patient number 13234453645 created by a specific healthcare provider organization is uniquely identified by the number itself in ''@extension'' and the OID of the organization or the sending system, in the example 2.16.840.1.113883.2.6.15.3.427.1 in ''@root''.

In some cases, a single OID identifies an object uniquely. In that situation, only ''@root'' is populated and ''@extension'' is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Encapsulated Data (ED) ===

Elements of this data type carry multimedia content. The actual multimedia content is represented as element content. There are two situations for the use of ED:

* Inline: The full data is transmitted in the type. This form is mainly used for text.
* By reference: a thumbnail is provided which links to the full data by reference.

In an instance, the data type is normally determined by an ''xsi:type'' specification and some attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@mediaType''' || <center>CS</center> || <center>O</center> || MIME media type classification. At time of writing this specification, the following MIME types are allowed:
* text/plain (plain text)
* text/html (text with html markup)
* image/jpeg (JPEG image)
* application/pdf (a PDF, portable document format)
* application/hl7-sda+xml (CDA documents).
|-
| '''@representation''' || <center>CS</center> || <center>O</center> || Representation of the multimedia content. At time of writing this specification, the following representations are allowed:
* TXT (text, this is the default)
* B64 base 64 encoded data, for example for embedded CDA documents).
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<text xsi:type="ED" mediaType="text/plain">
Patient treated sucessfully
</text>

<text mediaType="application/hl7-sda+xml" representation="B64">PD94bWw..etc..==</text>

</syntaxhighlight>

To include referenced data the two sub elements ''thumbnail'' and ''reference'' are used.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''reference''' || <center>TEL</center> || <center>0..*</center> || <center>O</center> || Link (URI) to full data
|-
| '''thumbnail''' || <center>ED</center> || <center>0..*</center> || <center>O</center> || Thumbnail of referenced data
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value xsi:type="ED" mediaType="image/png" representation="B64">
<reference value="http://radiology.bergen.no/xrays/128s.png"/>
<thumbnail mediaType="image/jpeg" representation="B64"> MNY...83== </thumbnail>
</value>
</syntaxhighlight>

=== Strings (ST) ===

This data type is a specialization of the ED type where ''@mediaType'' is fixed “text/plain” and ''@representation'' is fixed “TXT”. It allows conveying a character string as '''element content'''. This data type is used in other data types it like the ''@extension'' in instance identifiers, or address and person name data type components.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<lotNumber> 143GT6DT </lotNumber>
</syntaxhighlight>

=== Concept Descriptor (CD) ===

This data type specifies a concept by means of a code and its code system (except for situations where no code is available).

A couple of specializations of data type CD exist, which differ in the main characteristics (properties) of the data type that may or may not be supported.

{| class="hl7table" style="width:50%"
|+<ref group="Table">Properties of data types used for codes</ref> ''Properties of data types used for codes''
! <div style="text-align: right">DataType</div> !! CD !! CE !! CV !! CO !! CS
|-
! <div style="text-align: left">Property</div> !! !! !! !! !!
|-
| '''@code''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||<center>X</center>
|-
| '''@codeSystem''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''@codeSystemVersion''' || <center>X</center> || <center>X</center> || <center>X</center>|| <center>X</center> ||
|-
| '''@displayName''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''originalText''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''translation''' || <center>X</center> || <center>X</center> || || ||
|-
| '''qualifier''' || <center>X</center> || || || ||
|}

Because the CE variant is most used in practice, the general explanation of the properties will be given with de description of CE (see below).

The only attribute that is unique to CD is briefly explained here.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@qualifier''' || <center>CR</center> || <center>O</center> || An additional qualifier for the code.
|}

Complex terminologies like SNOMED CT can be used only using data type CD.

=== Coded with Equivalents (CE) ===

With elements of this data type, a concept by means of a code and its coding system (except for situations where no code is available) can be specified. It optionally contains one or more equivalents using other code systems.

It may contain the following attributes:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@code''' || <center>ST</center> || <center>R</center> || The actual code
|-
| '''@codeSystem''' || <center>OID</center> || <center>R</center> || required to identify the code system were the code is drawn from. This is an OID (object identifier, see [[#Object_Identifiers_.28OIDs.29|Object Identifiers at 4.1]])
|-
| '''@displayName''' || <center>ST</center> || <center>O</center> || Optional textual representation of code. A display name may be specified representing the plain text of the code. The information of this attribute may not be used by the receiving system for interpretation, but only for display purposes. The display name may never be transmitted without a code and must have the same meaning as the code.
|-
| '''@codeSystemName''' || <center>ST</center> || <center>O</center> || A textual representation of the name of the code system
|-
| '''@codeSystemVersion''' || <center>ST</center> || <center>O</center> || A textual representation of the version of the code system
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"/>

<code code="AU" codeSystem="2.16.840.1.113883.5.33"/>

<storageCode code="AC" codeSystem="2.16.840.1.113883.5.34" displayName="active"/>

<code code="A45.0" displayName="Somatisierungsstörung" codeSystem="1.2.276.0.76.5.409" codeSystemName="ICD-10 GM 2012"/>
</syntaxhighlight>

There are some child elements of codes that can be used to express what the “original text” was that was used for the coding or to indicate that there are “translations” to other code systems than the primary code.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''originalText''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Textual representation of the concept, actually a description which was used to create the actual code
|}

No semantics may be assumed other than showing the ''@displayName'' to a user to clarify the code. A display name cannot occur without its code and must carry the same meaning.

In case no code is known, it is allowed to specify a ''@nullFlavor'' for the code element and to give information about the (not yet coded) concept in original text. However, this should be an exception.

If other codes than the primary code need to be conveyed adding a translation child element can be used.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<originalText>minor aphthous stomatitis</originalText>
</code>
</syntaxhighlight>

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''translation''' || <center>CD</center> || <center>0..*</center> || <center>O</center> || Alternative code(s)
|}

A ''translation'' element is also of type CD and shall have a code and a code system identified. It shall point to the same concept as the primary code. It is allowed that a translation conveys less conceptual details than the original code.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<translation code="528.2" codeSystem="2.16.840.1.113883.6.2" codeSystemName="ICD9" displayName="Oral aphthae"/>
</code>
</syntaxhighlight>

=== Coded Value (CV) ===

This is actually a specialization of CE (see above), with the exception that neither ''originalText'' nor ''translation'' child element are allowed.

=== Coded Simple Value (CS) ===

This is actually a specialization of CE (see above), with no code system attribute and no original text or translation child element allowed. It specifies a concept by means of a code from a ''predefined'' code system (table) where the code is drawn from. This data type is usually applied in the context of fixed predefined HL7 tables.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<statusCode code="completed"/>
</syntaxhighlight>

In this example ''statusCode'' is bound in the underlying model to the specific code system ''ActStatus''. Because it is predefined by means of the vocabulary binding, ''@codeSystem'' is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Telecommunication Address (TEL) ===

Elements of this type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>ST</center> || <center>R</center> || carries strings that represent telecommunication contact information
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

The actual data is preceded by the scheme (refer to Internet Standard “RFC 1738 Uniform Resource Locators (URL)” <ref>RFC 1738 Uniform Resource Locators (URL): http://www.ietf.org/rfc/rfc1738.txt</ref>.

Examples:
* telephone (tel:),
* fax (fax:),
* email (mailto:).

It must follow the rules defined in Internet “RFC 2806 URLs for Telephone Calls” <ref>RFC 2806 URLs for Telephone Calls: http://www.ietf.org/rfc/rfc2806.txt</ref>.

The following codes will be used in the “use” attribute:
* H – Home
* WP – Work
* MC can be used (in addition to H or WP) to denote that this is a mobile phone.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257" />

<telecom use="H" value="tel:55354257" />

<telecom use="H" value="fax:56542558" />

<telecom value="tel:+41.34.21.4765342"/>

<telecom value="mailto:opr@opr-sem.no"/>

<telecom use="WP MC" value="tel:97555786" />
</syntaxhighlight>

It is possible to express the useable period of a telecommunication contact. A child element ''useablePeriod'' is used as a time interval to indicate this period.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''useablePeriod''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257">
<useablePeriod>
<high value="20111201"/>
</useablePeriod>
</telecom>
</syntaxhighlight>

=== Postal Address (AD) ===

Elements of this data type have a substructure in order to represent a structured address specification. In this implementation guide only a selection of all possible child elements is allowed, the original HL7 specification is richer.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''streetAddressLine''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Street address, includes street name and house number
|-
| '''city''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || City
|-
| '''postalCode''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Postal code
|-
| '''country''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Country
|-
|}

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that the sequence of the sub elements is country specific, i.e. it has to follow “common” rules how to write an address. For example, an UK address and a German address have different sequences of address representation.
|}

A ''@use'' attribute can also be specified.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="WP">
<streetAddressLine>Anna-Louisa-Karsch-Str. 2</streetAddressLine>
<postalCode>10178</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="H WP">
<streetAddressLine>Tatungasse 34</streetAddressLine>
<postalCode>10825</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

Also, a country may be specified using the element ''country''.

=== Person Name (PN) ===

Elements of this data type do also have a substructure to represent the parts of a person name, like family or given name and prefixes.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>
<given>Franz</given>
<given>Ingrun</given>
<family>Nordmann</family>
</name>
</syntaxhighlight>

Previous or birth or maiden names are supported using the ''validTime'' element. ''validTime'' (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]]) specifies the validity range of the name.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">

<name>
<given>Jan</given>
<given>Olaf</given>
<family>Hendrikson</family>
<validTime>
<high value="20000101"/>
</validTime>
</name>
</syntaxhighlight>

Note that the name attribute is repeating, i.e. multiple (types of) names could be sent. It is up to the receiver (based on the value of the ''@use'' attribute, and ''validTime'') to decide what name it wants to use or import in its database.

=== Organisation Name (ON) ===

Elements of this data type represent a name of an organization.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name> Charité Berlin </name>
</syntaxhighlight>

The optional ''validTime'' element (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]] may be used to specify the validity range of the name of the organization.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name of the organization
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>The old hospital
<validTime>
<high value="20111231235959"/>
</validTime>
</name>
</syntaxhighlight>

Please note that the use of ''validTime'' yields XML mixed content which should be avoided if possible.

=== Integer Number (INT) ===

Elements of this data type are used to specify integer numbers and have one attribute.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>int</center> || <center>R</center> || Integer value
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<sequenceNumber value="24"/>
</syntaxhighlight>

=== Physical Quantities (PQ) ===

Elements of this data type are physical quantities, i.e. a measurable quantity (or countable) value from the physical world. This is different from just a “number”, because there is a (natural) unit specified in which the measurable quantity is expressed.
Examples:
* an amount of blood 20 ml (sample volume)
* a cut with a length of 10 cm (result observation)
* a dose of 200 milligrams per administration (dosing)
* delivery of 60 pieces of a tablet (amount supplied).
Elements of this data type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>real</center> || <center>R</center> || value of the measurement
|-
| '''@unit''' || <center>CS</center> || <center>R</center> || unit of measurement
|}

In the unit of measurement unit is expressed following the ''Unified Code for Units of Measure'' (UCUM) specification. This specification is a collection of atomic units, prefixes and a corresponding grammar for valid combinations to build all-natural units of measurement. For a complete description of possible units, see the ''Unified Code for Units of Measure'' <ref>Unified Code for Units of Measure: http://unitsofmeasure.org/</ref> specification.

If a value is not countable or if measurable, for example expressed in milligrams or liters, then this unit is a valid UCUM unit like “mg” or “L”. If a value is countable, for example the number of tablets, then this attribute contains “1”.

In HL7 it is required that all PQ data type units are valid UCUM units.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<value value="165" unit="cm"/>

<value value="81.1" unit="kg"/>

<value value="120" unit="mm[Hg]"/>

<value value="5" unit="1"/>
</syntaxhighlight>

=== Point in Time (TS) ===

Elements of this data type have the attribute

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>TS</center> || <center>R</center> || Point in time
|}

and specify points in time in the format YYYYMMDDhhmmss±ZZZZ, where
* YYYY is the four-digit year,
* MM the two-digit month,
* DD the two-digit day,
* hh the two-digit hour,
* mm the two-digits minute and
* ss the two-digit second.
Optional a time zone ZZZZ, the four-digit time alignment with a preceding “-” or a “+” can be specified. If time zone is omitted, local time is assumed.
The point in time may be right truncated in respect to the precision of the information.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<effectiveTime value="20140412"/>

<effectiveTime value="201409091245"/>

<effectiveTime value="1996"/>

<birthTime value="19540714"/>

<effectiveTime value="20140412+0100"/>
</syntaxhighlight>

=== Intervals (IVL) ===

Intervals are defined only for data types with an ordinal or interval scale type. There are several possibilities to determine an interval (see Figure 2), for example to specify

* a lower <low> and an upper boundary <high> (a),
* a lower <low> boundary and width <width> (b)
* an upper boundary and width <width> (c) or
* the middle of the interval <nowiki><center></nowiki> and a width <width> (d).

[[File:CDA_Core_Principles_Figure_2_Determining_Intervals.png|700px]]

<ref group="Figure">Several possibilities to determine closed intervals</ref> ''Several possibilities to determine closed intervals''

{{ConstraintBox|
To indicate an interval, only the following combinations are permitted.
(1) A lower and an upper boundary may not be identical, and their accuracy has to be equal.

Correct examples:

{{BeginGreenBox|}}
Interval from 5 to 6
Interval from 20110607 until 20110612
{{EndGreenBox}}

Incorrect examples:

{{BeginRedBox|}}
Interval from 5 to 6.0
Interval from 20110101 to 2011
{{EndRedBox|}}

(2) A lower boundary and a width

(3) A lower limit boundary

(4) A upper limit boundary

(5) Only the middle of the interval

(6) Only the width of an interval}}

Accordingly, four child elements are available.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Lower boundary
|-
| '''high''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Upper boundary
|-
| '''center''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Where ''(T)'' is defined in this specification as one of the data types “TS” or “PQ”.

=== Interval of time (IVL_TS) ===

Elements of this data type represent time intervals. There are four possible child elements.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Lower boundary (start date/time)
|-
| '''high''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Upper boundary (end date/time)
|-
| '''center''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Normally, a lower and an upper boundary is given, both are points in time. Also, it is possible to specify open intervals like “since June 14, 1999” (left boundary given only) or “until September 24, 2006” (right boundary given).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110507"/>
<high value="20110909"/>
</effectiveTime>

<effectiveTime>
<low value="20110507"/>
</effectiveTime>

<value>
<low value="20110101"/>
<width value="120" unit="d"/>
</value>

<value>
<center value="20110101"/>
</value>
</syntaxhighlight>

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|It must be noted that intervals of time stamps in HL7 are equally treated as other interval types (e.g. integers). The statement, one may take 1–3 tablets (interval of integers), for example, says that you are allowed to take no more than three tablets, not 3½ or 3.5 tablets. On the other hand, when treat the words “until 12 June 2011” regarding the upper interval limit differently, particularly we assume that the entire day 12 June is still in-cluded in this time interval.
Thus, in human perception time intervals are handled differently com-pared to such as number intervals. This is a situation may lead to inconsist-encies in standardized communication. As a conclusion, an upper limit “12 June 2011” means that only the very first moment of the 12 June is included in the interval, but not, for example, the 12 June 13:00 hours.
Interpretation does not depend on the accuracy of the time:
* “after 2004” means “from January 1, 2005 00:00:00.000”,
* “after 20041201” means “from 2 December 2004 00:00:00.000 hours”,
* and “after 200412011200” means “from 1 December 2004 12:01:00.000”.

As a result, you have to carefully consider the specification and implemen-tation of time intervals upper boundaries. In order to prevent mis-understandings intervals are always specified with the date and time for an upper limit that would cover the whole day. Accordingly, “201106122359” means 12 June 2011 throughout the day.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="201106122359"/>
</effectiveTime>
</syntaxhighlight>

Because of the equal treatment of time intervals this is applied also to the lower limit boundaries of time intervals as “0000”. This means for example that “since 9 June 2011” is expressed as “201106090000”.
|}

The <width> element is of data type PQ (physical quantity). The value obviously shall relate to a period of time and it is required to include a “time” unit. These are the units “us” (microseconds), “ms” (milliseconds), “s” (seconds), “min” (minute), “h” (hours), “d” (day), “wk” (week), “mo” (month) and “a” (year).

{{ConstraintBox|
For interval of time stamps the @unit of a ''low'' or ''high'' child element shall use units
* us (microseconds),
* ms (milliseconds),
* s (seconds),
* min (minute),
* h (hours),
* d (day),
* wk (week),
* mo (month) or
* a (year).
}}

=== Interval of physical quantities (IVL_PQ) ===

Elements of this data type are used to indicate intervals of physical quantities (see also [[#Physical Quantities (PQ)|3.18 Physical Quantities (PQ)]]). In general, an upper and a lower boundary is specified. It is also possible to use ''center'' instead of ''low'' and ''high''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low || <center>TS</center> || <center>0..1</center> || <center>C</center> || the lower limit of the interval (i.e. the minimum amount).
|-
| '''high || <center>TS</center> || <center>0..1</center> || <center>C</center> || the upper limit of the interval (i.e. the maximum amount).
|-
| '''center || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of the interval
|}

The ''center'' child element is used when there is no interval, but an exact value. Alternative would be to demote IVL_PQ to data type PQ and populate the element’s ''@value'' attribute, but this is more difficult to process in XML. That is why the use of the ''center'' child element is deprecated.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<referenceRange>
<low value="7.5" unit="mmol/l"/>
<high value="10" unit="mmol/l"/>
</referenceRange>

<doseQuantity>
<center value="9" unit="1"/>
</doseQuantity>
</syntaxhighlight>

=== Ratio of quantities (RTO_QTY_QTY) ===

Elements of this data type specify ratios and have two child elements, a numerator and a denominator. The underlying QTY (Quantity) data type is an abstract data type and in a XML instance it has to be replaced by a specific data type using the ''@xsi:type'' instruction (see below).

In this specification only “PQ” or “INT” are allowed for the demotion of both ''numerator'' and ''denominator''. The relevant child elements are:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''numerator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the numerator of the ratio
|-
| '''denominator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the denominator of the ratio
|}

If a model attribute already is a RTO_QTY_QTY, you need to specify (demote) the OTY abstract data type for both ''numerator'' and ''denominator'' by using an ''@xsi:type'' instruction.
In some cases where the model attribute is of type “ANY”, also the root element shall carry an ''@xsi:type'' RTO_QTY_QTY instruction.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<maxDoseQuantity>
<numerator xsi:type="PQ" value="6"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="400" unit="mg"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="5"/>
<denominator xsi:type="PQ" value="1" unit="h"/>
</maxDoseQuantity>

<value xsi:type="RTO_QTY_QTY">
<numerator xsi:type="INT" value="1"/>
<denominator xsi:type="INT" value="10000"/>
</value>
</syntaxhighlight>

== Identification mechanisms ==

=== Object Identifiers (OIDs) ===

Standardized exchange of information using messages or documents also deals with unique identifications of objects and concepts, especially in environments where sender and receiver do not “know” each other necessarily.

It is important to understand the difference between identification of instances (ids) and code concepts (classifications). Within the context of HL7 interactions OIDs are quite often used.
An id points to a specific instance of an object or identification scheme (a particular methodology for the identification of a class of objects), for example a specific person as the patient or a physician, a specific lab observation or an X-ray photo.

In contrast to instance identifiers, a classification identifies a specific concept. The type of patient (inpatient, outpatient), the type of doctor (an anesthesiologist), the codes for gender or a lab observation (blood cell count) may serve as examples.

OIDs (object identifiers) are worldwide unique identifiers for objects. They are used in HL7 to specify identifications and classifications. An object in this sense is persistent, well-defined information, definitions or specifications and is represented with ids or codes.

Commonly used OIDs (i.e. used for a purpose that is wider in scope than the regional healthcare organization; used in communications between healthcare regions) can be found in OIDs registries such as

* [http://www.oid-info.com www.oid-info.com],
* [http://www.hl7.org www.hl7.org],
* [http://www.hl7.org.uk/version3group/oids.asp HL7 OID registry in the UK],
* [https://www.dimdi.de/dynamic/de/klassifikationen/weitere-klassifikationen-und-standards/oid/ OID registry Germany].

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|All OIDs with an element of 999 or 9999 are for documentation purposes only. They will be replaced by permanent OIDs once these have been as-signed/found/applied for.
|}

OID (Object Identifiers) are unique identifiers for any kind of objects. They are defined in Rec. ITU-T X.660 | ISO/IEC 9834-1. This identification system for objects and concepts makes reliable electronic information exchange possible. Administration and Registration is regulated by a set of rules, described in the corresponding chapter of this document.

Every artefact in ART-DECOR has an Object Identifier (OID). There are recommendations for the management and the exchange of Object Identifiers, partially defined in ISO TS 13582 <ref>ISO TS 13582: https://www.iso.org/standard/69652.html</ref>.

''HL7 International'' has created a type ontology for the OIDs in the HL7 registry to make it easier for the user community to search for OIDs they may be looking for and can be found at hl7.org.

From a policy perspective it is common practice in several healthcare related OID registries (HL7 International at http://www.hl7.org, OID Registry Germany at http://www.dimdi.de, OID registry Switzerland at http://oid.refdata.ch, and OID registry Austria at https://www.gesundheit.gv.at/OID_Frontend) to distinguish at least between the following types of OIDs:

{| class="hl7table" style="width:60%"
|+<ref group="Table">Recommended OID sub-branches for different artefacts</ref> ''Recommended OID sub-branches for different artefacts''
! Arc !! Description
|-
| .3 || organizational bodies and groups
|-
| .4 || identifier systems and namespaces
|-
| .5 || code systems
|-
| .7 || document artefacts
|-
| .9 || conformance profiles
|-
| .10 || templates
|-
| .11 || value sets
|-
| .19 || examples
|-
| .99 || experimental
|}

''Example: given that “your” root OID is 1.2.3.4.5, the first value set of your governance group is then to be 1.2.3.4.5.11.1, with .11 as the value set “branch” and the last .1 as the first artefact of that kind.''

In ART-DECOR a project typically is set into the .77 branch of a governance group. When setting up the project, the OID for that project also determines the artefact OIDs using throughout the ART-DECOR project. The following additional branches are used to distinguish between different OID types:

{| class="hl7table"
|+<ref group="Table">Recommended OID sub-branches for ART-DECOR projects</ref> ''Recommended OID sub-branches for different artefacts''
! Artefact code Description !! Recommended !! OID suffix
|-
| DS || dataset || .77.1
|-
| DE || dataset concept || .77.2
|-
| SC || scenario || .77.3
|-
| TR || transaction in scenario || .77.4
|-
| CS || code system || .77.5
|-
| IS || issue || .77.6
|-
| AC || actor in scenario || .77.7
|-
| CL || concept list in dataset || .77.8
|-
| EL || element in template || .77.9
|-
| TM || template || .77.10
|-
| VS || value set || .77.11
|-
| RL || rule for instances || .77.12
|-
| SX || test/example scenario || .77.18
|-
| EX || test/example instance || .77.19
|-
| QX || qualification test/example || .77.20
|-
| TX || test/example data element || .77.21
|-
| CM || community || .77.22
|-
| MP || concept map || .77.24
|}

In ART-DECOR a newly created project uses these OID branches automatically.

=== Instance identification ===

Instance identification is done with the id element of a class. Its type is II (instance identifier) and described in the data type section above. For example, a patient number can be represented as
* 2.16.578.1.34.1.5432.1, the root-OID of the issuing authority, for example a system/application in a hospital, and
* 67543242 as the ''@extension'', representing the patient number within the system defined by the ''@root'' attribute.

=== Coding scheme identification ===

Coding schemes have to be uniquely identified using OIDs as well. All coding tables used in this implementation guide show the corresponding OID that has to be specified in the ''@codeSystem'' attribute of coded elements. Both attributes ''@code'' and ''@codeSystem'' together allows a correct interpretation of concept and code.

=== List of identification schemes ===

The following are OIDs for commonly used identification schemes.

{| class="hl7table"
|+<ref group="Table">Commonly used identification scheme OIDs</ref> ''Commonly used identification scheme OIDs''
! OID !! Identification System Name !! Description !! Issuer
|-
| 1.2.276.0.76.4.8 || KV-Nummer || Krankenversichertennummer ||
|-
| 1.2.276.0.76.4.17 || BSNR || Betriebsstättennummer ||
|-
| 1.2.276.0.76.4.16 || LANR || lebenslange Arztnummer ||
|}

=== List of code systems ===

The following are OIDs for code systems.

{| class="hl7table"
|+<ref group="Table">Commonly used code system OIDs</ref> ''Commonly used code system OIDs''
! OID !! Code System Name !! Description !! Issuer
|-
| 2.16.840.1.113883.6.1 || LOINC || Logical Observation Identifiers Names and Codes (LOINC) || Regenstrief Institute
|-
| 2.16.840.1.113883.6.96 || SNOMED CT || Systemized Nomenclature in Medicine Reference Terminology (SNOMED CT) || SNOMED International
|-
| 1.0.3166.1.2 || ISO 3166-1 (second edition) || Country codes as per ISO 3166-1:2007 || ISO
|}

== Vocabulary ==

=== Code Systems ===

Within HL7, a ''Code System'' is defined as a collection of codes with associated designations and meanings. Examples of code systems include ICD-10, SNOMED CT, and LOINC.
To meet the requirements of a code system as defined by HL7, a given code must resolve to one and only one meaning within the code system. Given this definition, each code table in the HL7 Version 3 standard represents a different code system since codes are sometimes used in different tables to have different meanings.
For example, “M” in the administrative gender table (''AdministrativeGender'', OID 2.16.840.1.113883.5.1) means “male”, while “M” in the marital status table (''MaritalStatus'', OID 2.16.840.1.113883.5.2) means “married”.
In this specification, code system tables are not presented in detail.

=== Value Sets ===

A ''Value Set'' represents a uniquely identifiable set of valid concept representations, where any concept representation can be tested to determine whether or not it is a member of the value set.
Value set complexity may range from a simple flat list of concept codes drawn from a single code system, to an unbounded hierarchical set of possibly post-coordinated expressions drawn from multiple code systems.
Value sets exist to constrain the content for a coded element in an HL7 static model or data type property. Value sets cannot have null content and must contain at least one concept representation where any given concept is generally (but not required to be) represented by only a single code within the Value Set.

[[File:CDA_Core_Principles_Figure_3_ValueSet_Example.png|800px]]

<ref group="Figure">Example presentation of the value set “MaritalStatus”</ref> ''Example presentation of the value set “MaritalStatus”''

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that value set OIDs never appear in a CDA Release 2 document. They are used for constraint expressions, for example in implementation guides.
In order to send a specific code drawn from a value set, the corresponding code system has to be conveyed.
An example, in the implementation specification the constraint on the model element ''maritalStatusCode'' is expressed as “to be drawn from value set 2.16.840.1.113883.5.2 ''MaritalStatus''”.
To actually send a marital status of “M” (married) that is shown in the value set figure above, the corresponding HL7 CDA instance would say:
<syntaxhighlight lang="xml">
<maritalStatusCode code="M" codeSystem="2.16.840.1.113883.5.2"/>
</syntaxhighlight>
|}

In this specification, value set tables are not presented in detail.

==== Binding strength ====

There is an optional vocabulary strength for data types that support that feature (coded concepts). Examples include CD, CE, CV and CO. Values are required, extensible, preferred and example. Default is required.

Please note: the formerly supported values CNE (Coded No Extensibility) and CWE (Coded With Extensibility) in ART-DECOR are deprecated as of December 2017. Specification CNE is handled as required and CWE is handled as extensible.

{| class="hl7table"
|+<ref group="Table">Binding Strengths</ref> ''Binding Strengths''
! Strength !! Description
|-
|required||Required/CNE. Coded with no exceptions; this element SHALL be from the specified value set
|-
|extensible||Extensible/CWE. Coded with Exceptions; this element SHALL be from the specified value set if any of the codes within the value set can apply to the concept being communicated. If the value set does not cover the concept (based on human review), alternate codings (or, data type allowing, text) may be included instead.
|-
|preferred||Preferred. Instances are encouraged to draw from the specified codes for interoperability purposes but are not required to do so to be considered conformant.
|-
|example||Example. Instances are not expected or even encouraged to draw from the specified value set. The value set merely provides examples of the types of concepts intended to be included.
|}

Mismatches with required lead to validation errors (SHALL logic). Mismatches with extensible lead to validation warnings (SHOULD logic). Mismatches with preferred lead to validation information messages (MAY logic). Mismatches with example don't have any validation consequences.

== Appendix ==

=== References ===

<references/>

=== List of figures ===

<references group="Figure" />

=== List of tables ===

<references group="Table" />

HL7 CDA Core Principles

2019-06-16T11:14:02Z

Dammon: /* Organisation Name (ON) */

== Introduction ==

This implementation guide specifies the ''Core Principles'' of using the ''Clinical Document Architecture'' <ref>Clinical Document Architecture Release 2: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=7</ref>.

=== Scope ===

This guide focuses on ''Data Types Release 1'' <ref>HL7 Data Types Release 1: http://www.hl7.org</ref>. Meanwhile an ISO specification ISO 21090 is out, also known as Data Type Release 2. The latter is subject to another implementation guide that will be published when ISO data types are used.

=== Focus of this document: HL7 Version 3 Data Types for CDA ===

The following chapters of this document will focus on the description of the data types and associated material. It will highlight the essentials in four chapters, all focusing on the Norwegian situation.
* '''Common aspects:''' explains common aspects of use of CDA and XML
* '''Data types:''' gives an overview and detailed specification of all data types used in CDA
* '''Identification schemes:''' explains major aspects of identification and the use in CDA
* '''Use of vocabulary:''' explains major aspects of vocabulary use in CDA.

=== Background ===

In many (European) countries, implementation guides for the use of data types in HL7 V3 are published. They take into account country specific constraints on the data types.

=== Legend of symbols ===

In this document several symbols are used.

{| class="hl7table" style="width:50%"
| [[File:Pfeil_rechts.png|50px]] || This is an important item
|-
| [[File:Issue.svg|50px]] || This is a known open issue
|-
| [[File:Faq.svg|50px]] || This is a frequently asked question (FAQ) with answer
|-
| [[File:Conformance.svg|50px]] || This is a constraint; in some situations also the rule identification is specified, e.g. dtr1-1-ANY, which links to the corresponding validation rule.
|}

=== Version history ===

{| class="hl7table" style="width:50%"
|+
! Version !! Date !! Description !! Author
|-
| 1.1 || 2019-04-24 || Refurbished guide based on earlier work || Kai U. Heitmann
|}

== Common aspects ==

=== Use of XML ===

HL7 Version 3 CDA uses the Extensible Markup Language (XML) as the exchange format. It is assumed that the reader is familiar with common XML aspects. However, some constraints are made regarding the use of CDA.

==== Character Set ====

{{ConstraintBox|
The character encoding of any CDA document shall be “UTF-8”.}}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="utf-8"?>
</syntaxhighlight>

=== CDA document structure ===

The XML namespace for CDA Release 2 documents is ''<nowiki>urn:hl7-org:v3</nowiki>''. This must be correctly mentioned in every XML instance.

CDA XML documents starts with the root element ''ClinicalDocument''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">


...

<component>
<structuredBody>
...
</structuredBody>
</component>

</ClinicalDocument>
</syntaxhighlight>

== Data types ==

=== Introduction ===

The following chapter describes the typical data types used in CDA implementation guides. For further information please refer to the HL7 V3 standard and its two parts concerning data types:
* Abstract Data type definition <ref>HL7 Version 3 Abstract Data type definition: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=264</ref>
* XML ITS for data types <ref>XML ITS for data types: https://www.hl7.org/documentcenter/public_temp_682D4D16-1C23-BA17-0C789BA52BEDB68E/wg/inm/datatypes-its-xml20050714.htm</ref>
Data types are properties of model class attributes and the basic building blocks of information in a CDA XML instance. For example, a model attribute named “time” has as its data type a time stamp “TS” (see Figure 1).

[[File:CDA_Core_Principles_Figure_1_CDA_Structure_Data_Types.png|700px]]

<ref group="Figure">CDA structure (left) and the data type specification (right)</ref> ''CDA structure (left) and the data type specification (right)''

=== XML representation of data types ===

Actual data is mostly carried in HL7 Version 3 by populating XML attributes and not as element content. Exceptions are names of persons and organizations as well as addresses.

The XML elements have names like the model attributes. For example, a model attribute “id” has a corresponding XML element named <id…>. The model determines the sequence of elements and their hierarchy. The data type itself determines the XML attributes within the start tag. The notation here is as follows:

{| class="hl7table"
|+
! Attribute !! DT !! Conf !! Description
|-
| (name of the model attribute or XML element) || Data type || Conformance, i.e. O, R, M || Textual description
|}

XML attributes (data type properties) are denoted as ''@attribute'' in order to distinguish their names from XML elements.

Example: in the example model above, the data type of the ''id'' attribute's is ''II'' (Instance Identifier). The corresponding XML attributes for that data type include ''@root'' and ''@extension''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id root="..." extension="..." />
</syntaxhighlight>

A description of the data types and their corresponding XML representation is contained in subsequent paragraphs of this guide.

==== Exceptions using XML element content ====

For most data types, the actual data is conveyed in XML attributes. However, there are some exceptions. For the data types binary (BIN), Encapsulated Data (ED), Entity Name (EN), Person Name (PN), Organization Name (ON), Trivial Name (TN), Address (AD) and character string data (ST), information is carried as element content.

Example: the components of an address <addr> are represented by sub elements with the data as element content (in the example shown in black).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr>
<streetAddressLine>Thormøhlens gate 12</streetAddressLine>
<postalCode>5006</postalCode>
<city>Bergen</city>
</addr>
</syntaxhighlight>

==== Combined data types ====

There are a number of so-called combined data types. For example, an interval with a lower and upper limit and a ratio that has a nominator and a denominator value.

In combined data types the substructure (e.g. <low> <high> in an interval) are represented as child elements of the relevant data type element.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110701"/>
<high value="20110729"/>
</effectiveTime>
</syntaxhighlight>

==== Conformance information ====

The conformance indicators distinguish kinds of conformance information described shortly here.

* '''O''': An optional item may be omitted if no data is present, i.e. no corresponding XML attribute or element is sent (marked as “O”)
* '''R''': For required items, lower cardinality is always zero or 1.
** Elements must be present and populated with data if present in the sending system. If no data is available (yet), a null flavor (see below) indicates and possibly classifies the missing information (marked as R).
** Attribute flagged as required must be present in the instance and populated.
* '''M''': For mandatory elements data must be sent and no missing values are allowed, i.e. if the sending system does not have information for mandatory elements the XML instance cannot be created and sent (marked as M).
* '''NP''': no data may be present at all (not permitted)
* '''C''': conditional conformance; typically a conformance table shows the circumstances (conditions) derived from information in the instance and the corresponding cardinalities and conformance statements.

=== Missing values (null flavor) ===

For every data type it is possible to specify a missing value including a kind of reason why data is missing. Instead of specifying any attribute of the corresponding element, a ''@nullFlavor'' attribute expresses the omission of data. Note that missing data is not allowed for mandatory elements (see above).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value nullFlavor="OTH"/>

<code nullFlavor="UNK"/>

<booleanInd nullFlavor="NI"/>

</syntaxhighlight>

The codes for the ''@nullFlavor'' attribute are drawn from the following hierarchical code system. It is a Coded Simple (CS), which means it has no code system (attribute ''@codeSystem'') specified.

{| class="hl7table"
|+<ref group="Table">NullFlavor</ref> ''NullFlavor''
! Code
! width=15% | Print Name
! Definition / Description
|-
| NI || No Information || No information whatsoever can be inferred from this exceptional value. This is the most general exceptional value. It is also the default exceptional value.
|-
|   OTH || other || The actual value is not an element in the value domain of a variable. (e.g., concept not provided by required code system).
|-
|     NINF || negative infinity || Negative infinity of numbers.
|-
|     PINF || positive infinity || Positive infinity of numbers.
|-
|   UNK || unknown || A proper value is applicable, but not known.
|-
|     ASKU || asked but unknown || Information was sought but not found (e.g., patient was asked but didn't know)
|-
|       NAV || temporarily unavailable || Information is not available at this time but it is expected that it will be available later.
|-
|       NASK || not asked || This information has not been sought (e.g., patient was not asked)
|-
|       TRC || trace || The content is greater than zero, but too small to be quantified.
|-
|   MSK || masked || There is information on this item available but it has not been provided by the sender due to security, privacy or other reasons. There may be an alternate mechanism for gaining access to this information.
Note: using this null flavour does provide information that may be a breach of confidentiality, even though no detail data is provided. Its primary purpose is for those circumstances where it is necessary to inform the receiver that the information does exist without providing any detail.
|-
|   NA || not applicable || No proper value is applicable in this context (e.g., last menstrual period for a male).
|-
| NP || not present || Value is not present in a message. This is only defined in messages, never in application data! All values not present in the message must be replaced by the applicable default, or no-information (NI) as the default of all defaults.
|}

=== ANY as the generic data type ===

This abstract data type is the basis for all other data types. Not a single value within a CDA document has the effective data type ANY, but any data type within HL7v3 is a specialization of ANY. This also means that any other data type inherits all properties of ANY (see [[#Missing_values_.28null_flavor.29|“Missing values (null flavor)”]]).

The ANY type is occasionally found in HL7 models when it comes to clinical finding etc. where – at model time – the actual data type of the value is not known. At instantiation time however, the actual data type ''is'' known and ANY is always replaced by a particular data type in an instance.

One example is the observation value (child element value in an observation), where in the model the data type of value cannot be anticipated. When instantiation is taking place, the data type is specified by the XML instance attribute ''@xsi:type''. This information can be used by the receiver to validate and process the value.

Attributes of an element with this data type are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@nullFlavor''' || <center>CS</center> || <center>–</center> || Classification of the missing value, see [[#Missing_values_.28null_flavor.29|3.3 Missing values (null flavor)]].
|}

{| class="hl7table" style="width:100%"
| width=8% | <center>[[File:Conformance.svg|50px]] dtr1-1-ANY</center> || If there is a ''nullFlavor'', there shall be no other attribute or element, unless it's ''nullFlavor="OTH"''.

In that case ''@codeSystem'' or ''originalText'' (see “code” data types) may have a value.
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">

<value xsi:type="CE" code="N11.9" codeSystem="2.16.840.1.113883.6.3"/>


<value xsi:type="PQ" value="12" unit="mL"/>


<value xsi:type="ED">this is text</value>
</syntaxhighlight>

=== Boolean (BL) ===

Elements of this data type refer to Boolean logic and have an attribute ''@value''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>BL</center> || <center>–</center> || Valued as “true” or “false”
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<negationInd value="false"/>

<deceasedInd value="true"/>

</syntaxhighlight>

In some situations, the BL data does not apply to an XML element, but an attribute. In that case, the attribute carries the Boolean value directly.
<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<support contextConductionInd ="false">
...
</support>
</syntaxhighlight>

=== Instance Identifier (II) ===

This data type identifies instances of classes like observations or entities (persons, organizations). Attributes are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@extension''' || <center>ST</center> || <center>O</center> || Identification
|-
| '''@root''' || <center>OID</center> || <center>R</center> || Source of identification
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id extension="13234453645" root="2.16.840.1.113883.2.6.15.3.427.1"/>
</syntaxhighlight>

The ''@root'' attribute is of type OID (object identifier), a unique identifier of the issuing authority or system. For example, a patient with a patient number 13234453645 created by a specific healthcare provider organization is uniquely identified by the number itself in ''@extension'' and the OID of the organization or the sending system, in the example 2.16.840.1.113883.2.6.15.3.427.1 in ''@root''.

In some cases, a single OID identifies an object uniquely. In that situation, only ''@root'' is populated and ''@extension'' is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Encapsulated Data (ED) ===

Elements of this data type carry multimedia content. The actual multimedia content is represented as element content. There are two situations for the use of ED:

* Inline: The full data is transmitted in the type. This form is mainly used for text.
* By reference: a thumbnail is provided which links to the full data by reference.

In an instance, the data type is normally determined by an ''xsi:type'' specification and some attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@mediaType''' || <center>CS</center> || <center>O</center> || MIME media type classification. At time of writing this specification, the following MIME types are allowed:
* text/plain (plain text)
* text/html (text with html markup)
* image/jpeg (JPEG image)
* application/pdf (a PDF, portable document format)
* application/hl7-sda+xml (CDA documents).
|-
| '''@representation''' || <center>CS</center> || <center>O</center> || Representation of the multimedia content. At time of writing this specification, the following representations are allowed:
* TXT (text, this is the default)
* B64 base 64 encoded data, for example for embedded CDA documents).
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<text xsi:type="ED" mediaType="text/plain">
Patient treated sucessfully
</text>

<text mediaType="application/hl7-sda+xml" representation="B64">PD94bWw..etc..==</text>

</syntaxhighlight>

To include referenced data the two sub elements ''thumbnail'' and ''reference'' are used.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''reference''' || <center>TEL</center> || <center>0..*</center> || <center>O</center> || Link (URI) to full data
|-
| '''thumbnail''' || <center>ED</center> || <center>0..*</center> || <center>O</center> || Thumbnail of referenced data
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value xsi:type="ED" mediaType="image/png" representation="B64">
<reference value="http://radiology.bergen.no/xrays/128s.png"/>
<thumbnail mediaType="image/jpeg" representation="B64"> MNY...83== </thumbnail>
</value>
</syntaxhighlight>

=== Strings (ST) ===

This data type is a specialization of the ED type where ''@mediaType'' is fixed “text/plain” and ''@representation'' is fixed “TXT”. It allows conveying a character string as '''element content'''. This data type is used in other data types it like the ''@extension'' in instance identifiers, or address and person name data type components.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<lotNumber> 143GT6DT </lotNumber>
</syntaxhighlight>

=== Concept Descriptor (CD) ===

This data type specifies a concept by means of a code and its code system (except for situations where no code is available).

A couple of specializations of data type CD exist, which differ in the main characteristics (properties) of the data type that may or may not be supported.

{| class="hl7table" style="width:50%"
|+<ref group="Table">Properties of data types used for codes</ref> ''Properties of data types used for codes''
! <div style="text-align: right">DataType</div> !! CD !! CE !! CV !! CO !! CS
|-
! <div style="text-align: left">Property</div> !! !! !! !! !!
|-
| '''@code''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||<center>X</center>
|-
| '''@codeSystem''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''@codeSystemVersion''' || <center>X</center> || <center>X</center> || <center>X</center>|| <center>X</center> ||
|-
| '''@displayName''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''originalText''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''translation''' || <center>X</center> || <center>X</center> || || ||
|-
| '''qualifier''' || <center>X</center> || || || ||
|}

Because the CE variant is most used in practice, the general explanation of the properties will be given with de description of CE (see below).

The only attribute that is unique to CD is briefly explained here.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@qualifier''' || <center>CR</center> || <center>O</center> || An additional qualifier for the code.
|}

Complex terminologies like SNOMED CT can be used only using data type CD.

=== Coded with Equivalents (CE) ===

With elements of this data type, a concept by means of a code and its coding system (except for situations where no code is available) can be specified. It optionally contains one or more equivalents using other code systems.

It may contain the following attributes:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@code''' || <center>ST</center> || <center>R</center> || The actual code
|-
| '''@codeSystem''' || <center>OID</center> || <center>R</center> || required to identify the code system were the code is drawn from. This is an OID (object identifier, see [[#Object_Identifiers_.28OIDs.29|Object Identifiers at 4.1]])
|-
| '''@displayName''' || <center>ST</center> || <center>O</center> || Optional textual representation of code. A display name may be specified representing the plain text of the code. The information of this attribute may not be used by the receiving system for interpretation, but only for display purposes. The display name may never be transmitted without a code and must have the same meaning as the code.
|-
| '''@codeSystemName''' || <center>ST</center> || <center>O</center> || A textual representation of the name of the code system
|-
| '''@codeSystemVersion''' || <center>ST</center> || <center>O</center> || A textual representation of the version of the code system
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"/>

<code code="AU" codeSystem="2.16.840.1.113883.5.33"/>

<storageCode code="AC" codeSystem="2.16.840.1.113883.5.34" displayName="active"/>

<code code="A45.0" displayName="Somatisierungsstörung" codeSystem="1.2.276.0.76.5.409" codeSystemName="ICD-10 GM 2012"/>
</syntaxhighlight>

There are some child elements of codes that can be used to express what the “original text” was that was used for the coding or to indicate that there are “translations” to other code systems than the primary code.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''originalText''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Textual representation of the concept, actually a description which was used to create the actual code
|}

No semantics may be assumed other than showing the ''@displayName'' to a user to clarify the code. A display name cannot occur without its code and must carry the same meaning.

In case no code is known, it is allowed to specify a ''@nullFlavor'' for the code element and to give information about the (not yet coded) concept in original text. However, this should be an exception.

If other codes than the primary code need to be conveyed adding a translation child element can be used.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<originalText>minor aphthous stomatitis</originalText>
</code>
</syntaxhighlight>

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''translation''' || <center>CD</center> || <center>0..*</center> || <center>O</center> || Alternative code(s)
|}

A ''translation'' element is also of type CD and shall have a code and a code system identified. It shall point to the same concept as the primary code. It is allowed that a translation conveys less conceptual details than the original code.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<translation code="528.2" codeSystem="2.16.840.1.113883.6.2" codeSystemName="ICD9" displayName="Oral aphthae"/>
</code>
</syntaxhighlight>

=== Coded Value (CV) ===

This is actually a specialization of CE (see above), with the exception that neither ''originalText'' nor ''translation'' child element are allowed.

=== Coded Simple Value (CS) ===

This is actually a specialization of CE (see above), with no code system attribute and no original text or translation child element allowed. It specifies a concept by means of a code from a ''predefined'' code system (table) where the code is drawn from. This data type is usually applied in the context of fixed predefined HL7 tables.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<statusCode code="completed"/>
</syntaxhighlight>

In this example ''statusCode'' is bound in the underlying model to the specific code system ''ActStatus''. Because it is predefined by means of the vocabulary binding, ''@codeSystem'' is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Telecommunication Address (TEL) ===

Elements of this type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>ST</center> || <center>R</center> || carries strings that represent telecommunication contact information
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

The actual data is preceded by the scheme (refer to Internet Standard “RFC 1738 Uniform Resource Locators (URL)” <ref>RFC 1738 Uniform Resource Locators (URL): http://www.ietf.org/rfc/rfc1738.txt</ref>.

Examples:
* telephone (tel:),
* fax (fax:),
* email (mailto:).

It must follow the rules defined in Internet “RFC 2806 URLs for Telephone Calls” <ref>RFC 2806 URLs for Telephone Calls: http://www.ietf.org/rfc/rfc2806.txt</ref>.

The following codes will be used in the “use” attribute:
* H – Home
* WP – Work
* MC can be used (in addition to H or WP) to denote that this is a mobile phone.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257" />

<telecom use="H" value="tel:55354257" />

<telecom use="H" value="fax:56542558" />

<telecom value="tel:+41.34.21.4765342"/>

<telecom value="mailto:opr@opr-sem.no"/>

<telecom use="WP MC" value="tel:97555786" />
</syntaxhighlight>

It is possible to express the useable period of a telecommunication contact. A child element ''useablePeriod'' is used as a time interval to indicate this period.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''useablePeriod''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257">
<useablePeriod>
<high value="20111201"/>
</useablePeriod>
</telecom>
</syntaxhighlight>

=== Postal Address (AD) ===

Elements of this data type have a substructure in order to represent a structured address specification. In this implementation guide only a selection of all possible child elements is allowed, the original HL7 specification is richer.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''streetAddressLine''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Street address, includes street name and house number
|-
| '''city''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || City
|-
| '''postalCode''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Postal code
|-
| '''country''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Country
|-
|}

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that the sequence of the sub elements is country specific, i.e. it has to follow “common” rules how to write an address. For example, an UK address and a German address have different sequences of address representation.
|}

A ''@use'' attribute can also be specified.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="WP">
<streetAddressLine>Anna-Louisa-Karsch-Str. 2</streetAddressLine>
<postalCode>10178</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="H WP">
<streetAddressLine>Tatungasse 34</streetAddressLine>
<postalCode>10825</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

Also, a country may be specified using the element ''country''.

=== Person Name (PN) ===

Elements of this data type do also have a substructure to represent the parts of a person name, like family or given name and prefixes.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>
<given>Franz</given>
<given>Ingrun</given>
<family>Nordmann</family>
</name>
</syntaxhighlight>

Previous or birth or maiden names are supported using the ''validTime'' element. ''validTime'' (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]]) specifies the validity range of the name.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">

<name>
<given>Jan</given>
<given>Olaf</given>
<family>Hendrikson</family>
<validTime>
<high value="20000101"/>
</validTime>
</name>
</syntaxhighlight>

Note that the name attribute is repeating, i.e. multiple (types of) names could be sent. It is up to the receiver (based on the value of the ''@use'' attribute, and ''validTime'') to decide what name it wants to use or import in its database.

=== Organisation Name (ON) ===

Elements of this data type represent a name of an organization.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name> Charité Berlin </name>
</syntaxhighlight>

The optional ''validTime'' element (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]] may be used to specify the validity range of the name of the organization.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name of the organization
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>The old hospital
<validTime>
<high value="20111231235959"/>
</validTime>
</name>
</syntaxhighlight>

Please note that the use of ''validTime'' yields XML mixed content which should be avoided if possible.

=== Integer Number (INT) ===

Elements of this data type are used to specify integer numbers and have one attribute.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>int</center> || <center>R</center> || Integer value
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<sequenceNumber value="24"/>
</syntaxhighlight>

=== Physical Quantities (PQ) ===

Elements of this data type are physical quantities, i.e. a measurable quantity (or countable) value from the physical world. This is different from just a “number”, because there is a (natural) unit specified in which the measurable quantity is expressed.
Examples:
* an amount of blood 20 ml (sample volume)
* a cut with a length of 10 cm (result observation)
* a dose of 200 milligrams per administration (dosing)
* delivery of 60 pieces of a tablet (amount supplied).
Elements of this data type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>real</center> || <center>R</center> || value of the measurement
|-
| '''@unit''' || <center>CS</center> || <center>R</center> || unit of measurement
|}

In the unit of measurement unit is expressed following the ''Unified Code for Units of Measure'' (UCUM) specification. This specification is a collection of atomic units, prefixes and a corresponding grammar for valid combinations to build all-natural units of measurement. For a complete description of possible units, see the ''Unified Code for Units of Measure'' <ref>Unified Code for Units of Measure: http://unitsofmeasure.org/</ref> specification.
If a value is not countable or if measurable, for example expressed in milligrams or liters, then this unit is a valid UCUM unit like “mg” or “L”. If a value is countable, for example the number of tablets, then this attribute contains “1”.
In HL7 it is required that all PQ data type units are valid UCUM units.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<value value="165" unit="cm"/>

<value value="81.1" unit="kg"/>

<value value="120" unit="mm[Hg]"/>

<value value="5" unit="1"/>
</syntaxhighlight>

=== Point in Time (TS) ===

Elements of this data type have the attribute

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>TS</center> || <center>R</center> || Point in time
|}

and specify points in time in the format YYYYMMDDhhmmss±ZZZZ, where
* YYYY is the four-digit year,
* MM the two-digit month,
* DD the two-digit day,
* hh the two-digit hour,
* mm the two-digits minute and
* ss the two-digit second.
Optional a time zone ZZZZ, the four-digit time alignment with a preceding “-” or a “+” can be specified. If time zone is omitted, local time is assumed.
The point in time may be right truncated in respect to the precision of the information.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<effectiveTime value="20140412"/>

<effectiveTime value="201409091245"/>

<effectiveTime value="1996"/>

<birthTime value="19540714"/>

<effectiveTime value="20140412+0100"/>
</syntaxhighlight>

=== Intervals (IVL) ===

Intervals are defined only for data types with an ordinal or interval scale type. There are several possibilities to determine an interval (see Figure 2), for example to specify

* a lower <low> and an upper boundary <high> (a),
* a lower <low> boundary and width <width> (b)
* an upper boundary and width <width> (c) or
* the middle of the interval <nowiki><center></nowiki> and a width <width> (d).

[[File:CDA_Core_Principles_Figure_2_Determining_Intervals.png|700px]]

<ref group="Figure">Several possibilities to determine closed intervals</ref> ''Several possibilities to determine closed intervals''

{{ConstraintBox|
To indicate an interval, only the following combinations are permitted.
(1) A lower and an upper boundary may not be identical, and their accuracy has to be equal.

Correct examples:

{{BeginGreenBox|}}
Interval from 5 to 6
Interval from 20110607 until 20110612
{{EndGreenBox}}

Incorrect examples:

{{BeginRedBox|}}
Interval from 5 to 6.0
Interval from 20110101 to 2011
{{EndRedBox|}}

(2) A lower boundary and a width

(3) A lower limit boundary

(4) A upper limit boundary

(5) Only the middle of the interval

(6) Only the width of an interval}}

Accordingly, four child elements are available.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Lower boundary
|-
| '''high''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Upper boundary
|-
| '''center''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Where ''(T)'' is defined in this specification as one of the data types “TS” or “PQ”.

=== Interval of time (IVL_TS) ===

Elements of this data type represent time intervals. There are four possible child elements.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Lower boundary (start date/time)
|-
| '''high''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Upper boundary (end date/time)
|-
| '''center''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Normally, a lower and an upper boundary is given, both are points in time. Also, it is possible to specify open intervals like “since June 14, 1999” (left boundary given only) or “until September 24, 2006” (right boundary given).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110507"/>
<high value="20110909"/>
</effectiveTime>

<effectiveTime>
<low value="20110507"/>
</effectiveTime>

<value>
<low value="20110101"/>
<width value="120" unit="d"/>
</value>

<value>
<center value="20110101"/>
</value>
</syntaxhighlight>

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|It must be noted that intervals of time stamps in HL7 are equally treated as other interval types (e.g. integers). The statement, one may take 1–3 tablets (interval of integers), for example, says that you are allowed to take no more than three tablets, not 3½ or 3.5 tablets. On the other hand, when treat the words “until 12 June 2011” regarding the upper interval limit differently, particularly we assume that the entire day 12 June is still in-cluded in this time interval.
Thus, in human perception time intervals are handled differently com-pared to such as number intervals. This is a situation may lead to inconsist-encies in standardized communication. As a conclusion, an upper limit “12 June 2011” means that only the very first moment of the 12 June is included in the interval, but not, for example, the 12 June 13:00 hours.
Interpretation does not depend on the accuracy of the time:
* “after 2004” means “from January 1, 2005 00:00:00.000”,
* “after 20041201” means “from 2 December 2004 00:00:00.000 hours”,
* and “after 200412011200” means “from 1 December 2004 12:01:00.000”.

As a result, you have to carefully consider the specification and implemen-tation of time intervals upper boundaries. In order to prevent mis-understandings intervals are always specified with the date and time for an upper limit that would cover the whole day. Accordingly, “201106122359” means 12 June 2011 throughout the day.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="201106122359"/>
</effectiveTime>
</syntaxhighlight>

Because of the equal treatment of time intervals this is applied also to the lower limit boundaries of time intervals as “0000”. This means for example that “since 9 June 2011” is expressed as “201106090000”.
|}

The <width> element is of data type PQ (physical quantity). The value obviously shall relate to a period of time and it is required to include a “time” unit. These are the units “us” (microseconds), “ms” (milliseconds), “s” (seconds), “min” (minute), “h” (hours), “d” (day), “wk” (week), “mo” (month) and “a” (year).

{{ConstraintBox|
For interval of time stamps the @unit of a ''low'' or ''high'' child element shall use units
* us (microseconds),
* ms (milliseconds),
* s (seconds),
* min (minute),
* h (hours),
* d (day),
* wk (week),
* mo (month) or
* a (year).
}}

=== Interval of physical quantities (IVL_PQ) ===

Elements of this data type are used to indicate intervals of physical quantities (see also [[#Physical Quantities (PQ)|3.18 Physical Quantities (PQ)]]). In general, an upper and a lower boundary is specified. It is also possible to use ''center'' instead of ''low'' and ''high''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low || <center>TS</center> || <center>0..1</center> || <center>C</center> || the lower limit of the interval (i.e. the minimum amount).
|-
| '''high || <center>TS</center> || <center>0..1</center> || <center>C</center> || the upper limit of the interval (i.e. the maximum amount).
|-
| '''center || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of the interval
|}

The ''center'' child element is used when there is no interval, but an exact value. Alternative would be to demote IVL_PQ to data type PQ and populate the element’s ''@value'' attribute, but this is more difficult to process in XML. That is why the use of the ''center'' child element is deprecated.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<referenceRange>
<low value="7.5" unit="mmol/l"/>
<high value="10" unit="mmol/l"/>
</referenceRange>

<doseQuantity>
<center value="9" unit="1"/>
</doseQuantity>
</syntaxhighlight>

=== Ratio of quantities (RTO_QTY_QTY) ===

Elements of this data type specify ratios and have two child elements, a numerator and a denominator. The underlying QTY (Quantity) data type is an abstract data type and in a XML instance it has to be replaced by a specific data type using the ''@xsi:type'' instruction (see below).

In this specification only “PQ” or “INT” are allowed for the demotion of both ''numerator'' and ''denominator''. The relevant child elements are:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''numerator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the numerator of the ratio
|-
| '''denominator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the denominator of the ratio
|}

If a model attribute already is a RTO_QTY_QTY, you need to specify (demote) the OTY abstract data type for both ''numerator'' and ''denominator'' by using an ''@xsi:type'' instruction.
In some cases where the model attribute is of type “ANY”, also the root element shall carry an ''@xsi:type'' RTO_QTY_QTY instruction.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<maxDoseQuantity>
<numerator xsi:type="PQ" value="6"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="400" unit="mg"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="5"/>
<denominator xsi:type="PQ" value="1" unit="h"/>
</maxDoseQuantity>

<value xsi:type="RTO_QTY_QTY">
<numerator xsi:type="INT" value="1"/>
<denominator xsi:type="INT" value="10000"/>
</value>
</syntaxhighlight>

== Identification mechanisms ==

=== Object Identifiers (OIDs) ===

Standardized exchange of information using messages or documents also deals with unique identifications of objects and concepts, especially in environments where sender and receiver do not “know” each other necessarily.

It is important to understand the difference between identification of instances (ids) and code concepts (classifications). Within the context of HL7 interactions OIDs are quite often used.
An id points to a specific instance of an object or identification scheme (a particular methodology for the identification of a class of objects), for example a specific person as the patient or a physician, a specific lab observation or an X-ray photo.

In contrast to instance identifiers, a classification identifies a specific concept. The type of patient (inpatient, outpatient), the type of doctor (an anesthesiologist), the codes for gender or a lab observation (blood cell count) may serve as examples.

OIDs (object identifiers) are worldwide unique identifiers for objects. They are used in HL7 to specify identifications and classifications. An object in this sense is persistent, well-defined information, definitions or specifications and is represented with ids or codes.

Commonly used OIDs (i.e. used for a purpose that is wider in scope than the regional healthcare organization; used in communications between healthcare regions) can be found in OIDs registries such as

* [http://www.oid-info.com www.oid-info.com],
* [http://www.hl7.org www.hl7.org],
* [http://www.hl7.org.uk/version3group/oids.asp HL7 OID registry in the UK],
* [https://www.dimdi.de/dynamic/de/klassifikationen/weitere-klassifikationen-und-standards/oid/ OID registry Germany].

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|All OIDs with an element of 999 or 9999 are for documentation purposes only. They will be replaced by permanent OIDs once these have been as-signed/found/applied for.
|}

OID (Object Identifiers) are unique identifiers for any kind of objects. They are defined in Rec. ITU-T X.660 | ISO/IEC 9834-1. This identification system for objects and concepts makes reliable electronic information exchange possible. Administration and Registration is regulated by a set of rules, described in the corresponding chapter of this document.

Every artefact in ART-DECOR has an Object Identifier (OID). There are recommendations for the management and the exchange of Object Identifiers, partially defined in ISO TS 13582 <ref>ISO TS 13582: https://www.iso.org/standard/69652.html</ref>.

''HL7 International'' has created a type ontology for the OIDs in the HL7 registry to make it easier for the user community to search for OIDs they may be looking for and can be found at hl7.org.

From a policy perspective it is common practice in several healthcare related OID registries (HL7 International at http://www.hl7.org, OID Registry Germany at http://www.dimdi.de, OID registry Switzerland at http://oid.refdata.ch, and OID registry Austria at https://www.gesundheit.gv.at/OID_Frontend) to distinguish at least between the following types of OIDs:

{| class="hl7table" style="width:60%"
|+<ref group="Table">Recommended OID sub-branches for different artefacts</ref> ''Recommended OID sub-branches for different artefacts''
! Arc !! Description
|-
| .3 || organizational bodies and groups
|-
| .4 || identifier systems and namespaces
|-
| .5 || code systems
|-
| .7 || document artefacts
|-
| .9 || conformance profiles
|-
| .10 || templates
|-
| .11 || value sets
|-
| .19 || examples
|-
| .99 || experimental
|}

''Example: given that “your” root OID is 1.2.3.4.5, the first value set of your governance group is then to be 1.2.3.4.5.11.1, with .11 as the value set “branch” and the last .1 as the first artefact of that kind.''

In ART-DECOR a project typically is set into the .77 branch of a governance group. When setting up the project, the OID for that project also determines the artefact OIDs using throughout the ART-DECOR project. The following additional branches are used to distinguish between different OID types:

{| class="hl7table"
|+<ref group="Table">Recommended OID sub-branches for ART-DECOR projects</ref> ''Recommended OID sub-branches for different artefacts''
! Artefact code Description !! Recommended !! OID suffix
|-
| DS || dataset || .77.1
|-
| DE || dataset concept || .77.2
|-
| SC || scenario || .77.3
|-
| TR || transaction in scenario || .77.4
|-
| CS || code system || .77.5
|-
| IS || issue || .77.6
|-
| AC || actor in scenario || .77.7
|-
| CL || concept list in dataset || .77.8
|-
| EL || element in template || .77.9
|-
| TM || template || .77.10
|-
| VS || value set || .77.11
|-
| RL || rule for instances || .77.12
|-
| SX || test/example scenario || .77.18
|-
| EX || test/example instance || .77.19
|-
| QX || qualification test/example || .77.20
|-
| TX || test/example data element || .77.21
|-
| CM || community || .77.22
|-
| MP || concept map || .77.24
|}

In ART-DECOR a newly created project uses these OID branches automatically.

=== Instance identification ===

Instance identification is done with the id element of a class. Its type is II (instance identifier) and described in the data type section above. For example, a patient number can be represented as
* 2.16.578.1.34.1.5432.1, the root-OID of the issuing authority, for example a system/application in a hospital, and
* 67543242 as the ''@extension'', representing the patient number within the system defined by the ''@root'' attribute.

=== Coding scheme identification ===

Coding schemes have to be uniquely identified using OIDs as well. All coding tables used in this implementation guide show the corresponding OID that has to be specified in the ''@codeSystem'' attribute of coded elements. Both attributes ''@code'' and ''@codeSystem'' together allows a correct interpretation of concept and code.

=== List of identification schemes ===

The following are OIDs for commonly used identification schemes.

{| class="hl7table"
|+<ref group="Table">Commonly used identification scheme OIDs</ref> ''Commonly used identification scheme OIDs''
! OID !! Identification System Name !! Description !! Issuer
|-
| 1.2.276.0.76.4.8 || KV-Nummer || Krankenversichertennummer ||
|-
| 1.2.276.0.76.4.17 || BSNR || Betriebsstättennummer ||
|-
| 1.2.276.0.76.4.16 || LANR || lebenslange Arztnummer ||
|}

=== List of code systems ===

The following are OIDs for code systems.

{| class="hl7table"
|+<ref group="Table">Commonly used code system OIDs</ref> ''Commonly used code system OIDs''
! OID !! Code System Name !! Description !! Issuer
|-
| 2.16.840.1.113883.6.1 || LOINC || Logical Observation Identifiers Names and Codes (LOINC) || Regenstrief Institute
|-
| 2.16.840.1.113883.6.96 || SNOMED CT || Systemized Nomenclature in Medicine Reference Terminology (SNOMED CT) || SNOMED International
|-
| 1.0.3166.1.2 || ISO 3166-1 (second edition) || Country codes as per ISO 3166-1:2007 || ISO
|}

== Vocabulary ==

=== Code Systems ===

Within HL7, a ''Code System'' is defined as a collection of codes with associated designations and meanings. Examples of code systems include ICD-10, SNOMED CT, and LOINC.
To meet the requirements of a code system as defined by HL7, a given code must resolve to one and only one meaning within the code system. Given this definition, each code table in the HL7 Version 3 standard represents a different code system since codes are sometimes used in different tables to have different meanings.
For example, “M” in the administrative gender table (''AdministrativeGender'', OID 2.16.840.1.113883.5.1) means “male”, while “M” in the marital status table (''MaritalStatus'', OID 2.16.840.1.113883.5.2) means “married”.
In this specification, code system tables are not presented in detail.

=== Value Sets ===

A ''Value Set'' represents a uniquely identifiable set of valid concept representations, where any concept representation can be tested to determine whether or not it is a member of the value set.
Value set complexity may range from a simple flat list of concept codes drawn from a single code system, to an unbounded hierarchical set of possibly post-coordinated expressions drawn from multiple code systems.
Value sets exist to constrain the content for a coded element in an HL7 static model or data type property. Value sets cannot have null content and must contain at least one concept representation where any given concept is generally (but not required to be) represented by only a single code within the Value Set.

[[File:CDA_Core_Principles_Figure_3_ValueSet_Example.png|800px]]

<ref group="Figure">Example presentation of the value set “MaritalStatus”</ref> ''Example presentation of the value set “MaritalStatus”''

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that value set OIDs never appear in a CDA Release 2 document. They are used for constraint expressions, for example in implementation guides.
In order to send a specific code drawn from a value set, the corresponding code system has to be conveyed.
An example, in the implementation specification the constraint on the model element ''maritalStatusCode'' is expressed as “to be drawn from value set 2.16.840.1.113883.5.2 ''MaritalStatus''”.
To actually send a marital status of “M” (married) that is shown in the value set figure above, the corresponding HL7 CDA instance would say:
<syntaxhighlight lang="xml">
<maritalStatusCode code="M" codeSystem="2.16.840.1.113883.5.2"/>
</syntaxhighlight>
|}

In this specification, value set tables are not presented in detail.

==== Binding strength ====

There is an optional vocabulary strength for data types that support that feature (coded concepts). Examples include CD, CE, CV and CO. Values are required, extensible, preferred and example. Default is required.

Please note: the formerly supported values CNE (Coded No Extensibility) and CWE (Coded With Extensibility) in ART-DECOR are deprecated as of December 2017. Specification CNE is handled as required and CWE is handled as extensible.

{| class="hl7table"
|+<ref group="Table">Binding Strengths</ref> ''Binding Strengths''
! Strength !! Description
|-
|required||Required/CNE. Coded with no exceptions; this element SHALL be from the specified value set
|-
|extensible||Extensible/CWE. Coded with Exceptions; this element SHALL be from the specified value set if any of the codes within the value set can apply to the concept being communicated. If the value set does not cover the concept (based on human review), alternate codings (or, data type allowing, text) may be included instead.
|-
|preferred||Preferred. Instances are encouraged to draw from the specified codes for interoperability purposes but are not required to do so to be considered conformant.
|-
|example||Example. Instances are not expected or even encouraged to draw from the specified value set. The value set merely provides examples of the types of concepts intended to be included.
|}

Mismatches with required lead to validation errors (SHALL logic). Mismatches with extensible lead to validation warnings (SHOULD logic). Mismatches with preferred lead to validation information messages (MAY logic). Mismatches with example don't have any validation consequences.

== Appendix ==

=== References ===

<references/>

=== List of figures ===

<references group="Figure" />

=== List of tables ===

<references group="Table" />

HL7 CDA Core Principles

2019-06-16T11:10:55Z

Dammon: /* Coded with Equivalents (CE) */

== Introduction ==

This implementation guide specifies the ''Core Principles'' of using the ''Clinical Document Architecture'' <ref>Clinical Document Architecture Release 2: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=7</ref>.

=== Scope ===

This guide focuses on ''Data Types Release 1'' <ref>HL7 Data Types Release 1: http://www.hl7.org</ref>. Meanwhile an ISO specification ISO 21090 is out, also known as Data Type Release 2. The latter is subject to another implementation guide that will be published when ISO data types are used.

=== Focus of this document: HL7 Version 3 Data Types for CDA ===

The following chapters of this document will focus on the description of the data types and associated material. It will highlight the essentials in four chapters, all focusing on the Norwegian situation.
* '''Common aspects:''' explains common aspects of use of CDA and XML
* '''Data types:''' gives an overview and detailed specification of all data types used in CDA
* '''Identification schemes:''' explains major aspects of identification and the use in CDA
* '''Use of vocabulary:''' explains major aspects of vocabulary use in CDA.

=== Background ===

In many (European) countries, implementation guides for the use of data types in HL7 V3 are published. They take into account country specific constraints on the data types.

=== Legend of symbols ===

In this document several symbols are used.

{| class="hl7table" style="width:50%"
| [[File:Pfeil_rechts.png|50px]] || This is an important item
|-
| [[File:Issue.svg|50px]] || This is a known open issue
|-
| [[File:Faq.svg|50px]] || This is a frequently asked question (FAQ) with answer
|-
| [[File:Conformance.svg|50px]] || This is a constraint; in some situations also the rule identification is specified, e.g. dtr1-1-ANY, which links to the corresponding validation rule.
|}

=== Version history ===

{| class="hl7table" style="width:50%"
|+
! Version !! Date !! Description !! Author
|-
| 1.1 || 2019-04-24 || Refurbished guide based on earlier work || Kai U. Heitmann
|}

== Common aspects ==

=== Use of XML ===

HL7 Version 3 CDA uses the Extensible Markup Language (XML) as the exchange format. It is assumed that the reader is familiar with common XML aspects. However, some constraints are made regarding the use of CDA.

==== Character Set ====

{{ConstraintBox|
The character encoding of any CDA document shall be “UTF-8”.}}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="utf-8"?>
</syntaxhighlight>

=== CDA document structure ===

The XML namespace for CDA Release 2 documents is ''<nowiki>urn:hl7-org:v3</nowiki>''. This must be correctly mentioned in every XML instance.

CDA XML documents starts with the root element ''ClinicalDocument''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">


...

<component>
<structuredBody>
...
</structuredBody>
</component>

</ClinicalDocument>
</syntaxhighlight>

== Data types ==

=== Introduction ===

The following chapter describes the typical data types used in CDA implementation guides. For further information please refer to the HL7 V3 standard and its two parts concerning data types:
* Abstract Data type definition <ref>HL7 Version 3 Abstract Data type definition: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=264</ref>
* XML ITS for data types <ref>XML ITS for data types: https://www.hl7.org/documentcenter/public_temp_682D4D16-1C23-BA17-0C789BA52BEDB68E/wg/inm/datatypes-its-xml20050714.htm</ref>
Data types are properties of model class attributes and the basic building blocks of information in a CDA XML instance. For example, a model attribute named “time” has as its data type a time stamp “TS” (see Figure 1).

[[File:CDA_Core_Principles_Figure_1_CDA_Structure_Data_Types.png|700px]]

<ref group="Figure">CDA structure (left) and the data type specification (right)</ref> ''CDA structure (left) and the data type specification (right)''

=== XML representation of data types ===

Actual data is mostly carried in HL7 Version 3 by populating XML attributes and not as element content. Exceptions are names of persons and organizations as well as addresses.

The XML elements have names like the model attributes. For example, a model attribute “id” has a corresponding XML element named <id…>. The model determines the sequence of elements and their hierarchy. The data type itself determines the XML attributes within the start tag. The notation here is as follows:

{| class="hl7table"
|+
! Attribute !! DT !! Conf !! Description
|-
| (name of the model attribute or XML element) || Data type || Conformance, i.e. O, R, M || Textual description
|}

XML attributes (data type properties) are denoted as ''@attribute'' in order to distinguish their names from XML elements.

Example: in the example model above, the data type of the ''id'' attribute's is ''II'' (Instance Identifier). The corresponding XML attributes for that data type include ''@root'' and ''@extension''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id root="..." extension="..." />
</syntaxhighlight>

A description of the data types and their corresponding XML representation is contained in subsequent paragraphs of this guide.

==== Exceptions using XML element content ====

For most data types, the actual data is conveyed in XML attributes. However, there are some exceptions. For the data types binary (BIN), Encapsulated Data (ED), Entity Name (EN), Person Name (PN), Organization Name (ON), Trivial Name (TN), Address (AD) and character string data (ST), information is carried as element content.

Example: the components of an address <addr> are represented by sub elements with the data as element content (in the example shown in black).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr>
<streetAddressLine>Thormøhlens gate 12</streetAddressLine>
<postalCode>5006</postalCode>
<city>Bergen</city>
</addr>
</syntaxhighlight>

==== Combined data types ====

There are a number of so-called combined data types. For example, an interval with a lower and upper limit and a ratio that has a nominator and a denominator value.

In combined data types the substructure (e.g. <low> <high> in an interval) are represented as child elements of the relevant data type element.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110701"/>
<high value="20110729"/>
</effectiveTime>
</syntaxhighlight>

==== Conformance information ====

The conformance indicators distinguish kinds of conformance information described shortly here.

* '''O''': An optional item may be omitted if no data is present, i.e. no corresponding XML attribute or element is sent (marked as “O”)
* '''R''': For required items, lower cardinality is always zero or 1.
** Elements must be present and populated with data if present in the sending system. If no data is available (yet), a null flavor (see below) indicates and possibly classifies the missing information (marked as R).
** Attribute flagged as required must be present in the instance and populated.
* '''M''': For mandatory elements data must be sent and no missing values are allowed, i.e. if the sending system does not have information for mandatory elements the XML instance cannot be created and sent (marked as M).
* '''NP''': no data may be present at all (not permitted)
* '''C''': conditional conformance; typically a conformance table shows the circumstances (conditions) derived from information in the instance and the corresponding cardinalities and conformance statements.

=== Missing values (null flavor) ===

For every data type it is possible to specify a missing value including a kind of reason why data is missing. Instead of specifying any attribute of the corresponding element, a ''@nullFlavor'' attribute expresses the omission of data. Note that missing data is not allowed for mandatory elements (see above).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value nullFlavor="OTH"/>

<code nullFlavor="UNK"/>

<booleanInd nullFlavor="NI"/>

</syntaxhighlight>

The codes for the ''@nullFlavor'' attribute are drawn from the following hierarchical code system. It is a Coded Simple (CS), which means it has no code system (attribute ''@codeSystem'') specified.

{| class="hl7table"
|+<ref group="Table">NullFlavor</ref> ''NullFlavor''
! Code
! width=15% | Print Name
! Definition / Description
|-
| NI || No Information || No information whatsoever can be inferred from this exceptional value. This is the most general exceptional value. It is also the default exceptional value.
|-
|   OTH || other || The actual value is not an element in the value domain of a variable. (e.g., concept not provided by required code system).
|-
|     NINF || negative infinity || Negative infinity of numbers.
|-
|     PINF || positive infinity || Positive infinity of numbers.
|-
|   UNK || unknown || A proper value is applicable, but not known.
|-
|     ASKU || asked but unknown || Information was sought but not found (e.g., patient was asked but didn't know)
|-
|       NAV || temporarily unavailable || Information is not available at this time but it is expected that it will be available later.
|-
|       NASK || not asked || This information has not been sought (e.g., patient was not asked)
|-
|       TRC || trace || The content is greater than zero, but too small to be quantified.
|-
|   MSK || masked || There is information on this item available but it has not been provided by the sender due to security, privacy or other reasons. There may be an alternate mechanism for gaining access to this information.
Note: using this null flavour does provide information that may be a breach of confidentiality, even though no detail data is provided. Its primary purpose is for those circumstances where it is necessary to inform the receiver that the information does exist without providing any detail.
|-
|   NA || not applicable || No proper value is applicable in this context (e.g., last menstrual period for a male).
|-
| NP || not present || Value is not present in a message. This is only defined in messages, never in application data! All values not present in the message must be replaced by the applicable default, or no-information (NI) as the default of all defaults.
|}

=== ANY as the generic data type ===

This abstract data type is the basis for all other data types. Not a single value within a CDA document has the effective data type ANY, but any data type within HL7v3 is a specialization of ANY. This also means that any other data type inherits all properties of ANY (see [[#Missing_values_.28null_flavor.29|“Missing values (null flavor)”]]).

The ANY type is occasionally found in HL7 models when it comes to clinical finding etc. where – at model time – the actual data type of the value is not known. At instantiation time however, the actual data type ''is'' known and ANY is always replaced by a particular data type in an instance.

One example is the observation value (child element value in an observation), where in the model the data type of value cannot be anticipated. When instantiation is taking place, the data type is specified by the XML instance attribute ''@xsi:type''. This information can be used by the receiver to validate and process the value.

Attributes of an element with this data type are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@nullFlavor''' || <center>CS</center> || <center>–</center> || Classification of the missing value, see [[#Missing_values_.28null_flavor.29|3.3 Missing values (null flavor)]].
|}

{| class="hl7table" style="width:100%"
| width=8% | <center>[[File:Conformance.svg|50px]] dtr1-1-ANY</center> || If there is a ''nullFlavor'', there shall be no other attribute or element, unless it's ''nullFlavor="OTH"''.

In that case ''@codeSystem'' or ''originalText'' (see “code” data types) may have a value.
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">

<value xsi:type="CE" code="N11.9" codeSystem="2.16.840.1.113883.6.3"/>


<value xsi:type="PQ" value="12" unit="mL"/>


<value xsi:type="ED">this is text</value>
</syntaxhighlight>

=== Boolean (BL) ===

Elements of this data type refer to Boolean logic and have an attribute ''@value''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>BL</center> || <center>–</center> || Valued as “true” or “false”
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<negationInd value="false"/>

<deceasedInd value="true"/>

</syntaxhighlight>

In some situations, the BL data does not apply to an XML element, but an attribute. In that case, the attribute carries the Boolean value directly.
<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<support contextConductionInd ="false">
...
</support>
</syntaxhighlight>

=== Instance Identifier (II) ===

This data type identifies instances of classes like observations or entities (persons, organizations). Attributes are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@extension''' || <center>ST</center> || <center>O</center> || Identification
|-
| '''@root''' || <center>OID</center> || <center>R</center> || Source of identification
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id extension="13234453645" root="2.16.840.1.113883.2.6.15.3.427.1"/>
</syntaxhighlight>

The ''@root'' attribute is of type OID (object identifier), a unique identifier of the issuing authority or system. For example, a patient with a patient number 13234453645 created by a specific healthcare provider organization is uniquely identified by the number itself in ''@extension'' and the OID of the organization or the sending system, in the example 2.16.840.1.113883.2.6.15.3.427.1 in ''@root''.

In some cases, a single OID identifies an object uniquely. In that situation, only ''@root'' is populated and ''@extension'' is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Encapsulated Data (ED) ===

Elements of this data type carry multimedia content. The actual multimedia content is represented as element content. There are two situations for the use of ED:

* Inline: The full data is transmitted in the type. This form is mainly used for text.
* By reference: a thumbnail is provided which links to the full data by reference.

In an instance, the data type is normally determined by an ''xsi:type'' specification and some attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@mediaType''' || <center>CS</center> || <center>O</center> || MIME media type classification. At time of writing this specification, the following MIME types are allowed:
* text/plain (plain text)
* text/html (text with html markup)
* image/jpeg (JPEG image)
* application/pdf (a PDF, portable document format)
* application/hl7-sda+xml (CDA documents).
|-
| '''@representation''' || <center>CS</center> || <center>O</center> || Representation of the multimedia content. At time of writing this specification, the following representations are allowed:
* TXT (text, this is the default)
* B64 base 64 encoded data, for example for embedded CDA documents).
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<text xsi:type="ED" mediaType="text/plain">
Patient treated sucessfully
</text>

<text mediaType="application/hl7-sda+xml" representation="B64">PD94bWw..etc..==</text>

</syntaxhighlight>

To include referenced data the two sub elements ''thumbnail'' and ''reference'' are used.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''reference''' || <center>TEL</center> || <center>0..*</center> || <center>O</center> || Link (URI) to full data
|-
| '''thumbnail''' || <center>ED</center> || <center>0..*</center> || <center>O</center> || Thumbnail of referenced data
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value xsi:type="ED" mediaType="image/png" representation="B64">
<reference value="http://radiology.bergen.no/xrays/128s.png"/>
<thumbnail mediaType="image/jpeg" representation="B64"> MNY...83== </thumbnail>
</value>
</syntaxhighlight>

=== Strings (ST) ===

This data type is a specialization of the ED type where ''@mediaType'' is fixed “text/plain” and ''@representation'' is fixed “TXT”. It allows conveying a character string as '''element content'''. This data type is used in other data types it like the ''@extension'' in instance identifiers, or address and person name data type components.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<lotNumber> 143GT6DT </lotNumber>
</syntaxhighlight>

=== Concept Descriptor (CD) ===

This data type specifies a concept by means of a code and its code system (except for situations where no code is available).

A couple of specializations of data type CD exist, which differ in the main characteristics (properties) of the data type that may or may not be supported.

{| class="hl7table" style="width:50%"
|+<ref group="Table">Properties of data types used for codes</ref> ''Properties of data types used for codes''
! <div style="text-align: right">DataType</div> !! CD !! CE !! CV !! CO !! CS
|-
! <div style="text-align: left">Property</div> !! !! !! !! !!
|-
| '''@code''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||<center>X</center>
|-
| '''@codeSystem''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''@codeSystemVersion''' || <center>X</center> || <center>X</center> || <center>X</center>|| <center>X</center> ||
|-
| '''@displayName''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''originalText''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''translation''' || <center>X</center> || <center>X</center> || || ||
|-
| '''qualifier''' || <center>X</center> || || || ||
|}

Because the CE variant is most used in practice, the general explanation of the properties will be given with de description of CE (see below).

The only attribute that is unique to CD is briefly explained here.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@qualifier''' || <center>CR</center> || <center>O</center> || An additional qualifier for the code.
|}

Complex terminologies like SNOMED CT can be used only using data type CD.

=== Coded with Equivalents (CE) ===

With elements of this data type, a concept by means of a code and its coding system (except for situations where no code is available) can be specified. It optionally contains one or more equivalents using other code systems.

It may contain the following attributes:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@code''' || <center>ST</center> || <center>R</center> || The actual code
|-
| '''@codeSystem''' || <center>OID</center> || <center>R</center> || required to identify the code system were the code is drawn from. This is an OID (object identifier, see [[#Object_Identifiers_.28OIDs.29|Object Identifiers at 4.1]])
|-
| '''@displayName''' || <center>ST</center> || <center>O</center> || Optional textual representation of code. A display name may be specified representing the plain text of the code. The information of this attribute may not be used by the receiving system for interpretation, but only for display purposes. The display name may never be transmitted without a code and must have the same meaning as the code.
|-
| '''@codeSystemName''' || <center>ST</center> || <center>O</center> || A textual representation of the name of the code system
|-
| '''@codeSystemVersion''' || <center>ST</center> || <center>O</center> || A textual representation of the version of the code system
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"/>

<code code="AU" codeSystem="2.16.840.1.113883.5.33"/>

<storageCode code="AC" codeSystem="2.16.840.1.113883.5.34" displayName="active"/>

<code code="A45.0" displayName="Somatisierungsstörung" codeSystem="1.2.276.0.76.5.409" codeSystemName="ICD-10 GM 2012"/>
</syntaxhighlight>

There are some child elements of codes that can be used to express what the “original text” was that was used for the coding or to indicate that there are “translations” to other code systems than the primary code.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''originalText''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Textual representation of the concept, actually a description which was used to create the actual code
|}

No semantics may be assumed other than showing the ''@displayName'' to a user to clarify the code. A display name cannot occur without its code and must carry the same meaning.

In case no code is known, it is allowed to specify a ''@nullFlavor'' for the code element and to give information about the (not yet coded) concept in original text. However, this should be an exception.

If other codes than the primary code need to be conveyed adding a translation child element can be used.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<originalText>minor aphthous stomatitis</originalText>
</code>
</syntaxhighlight>

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''translation''' || <center>CD</center> || <center>0..*</center> || <center>O</center> || Alternative code(s)
|}

A ''translation'' element is also of type CD and shall have a code and a code system identified. It shall point to the same concept as the primary code. It is allowed that a translation conveys less conceptual details than the original code.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<translation code="528.2" codeSystem="2.16.840.1.113883.6.2" codeSystemName="ICD9" displayName="Oral aphthae"/>
</code>
</syntaxhighlight>

=== Coded Value (CV) ===

This is actually a specialization of CE (see above), with the exception that neither ''originalText'' nor ''translation'' child element are allowed.

=== Coded Simple Value (CS) ===

This is actually a specialization of CE (see above), with no code system attribute and no original text or translation child element allowed. It specifies a concept by means of a code from a ''predefined'' code system (table) where the code is drawn from. This data type is usually applied in the context of fixed predefined HL7 tables.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<statusCode code="completed"/>
</syntaxhighlight>

In this example ''statusCode'' is bound in the underlying model to the specific code system ''ActStatus''. Because it is predefined by means of the vocabulary binding, ''@codeSystem'' is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Telecommunication Address (TEL) ===

Elements of this type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>ST</center> || <center>R</center> || carries strings that represent telecommunication contact information
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

The actual data is preceded by the scheme (refer to Internet Standard “RFC 1738 Uniform Resource Locators (URL)” <ref>RFC 1738 Uniform Resource Locators (URL): http://www.ietf.org/rfc/rfc1738.txt</ref>.

Examples:
* telephone (tel:),
* fax (fax:),
* email (mailto:).

It must follow the rules defined in Internet “RFC 2806 URLs for Telephone Calls” <ref>RFC 2806 URLs for Telephone Calls: http://www.ietf.org/rfc/rfc2806.txt</ref>.

The following codes will be used in the “use” attribute:
* H – Home
* WP – Work
* MC can be used (in addition to H or WP) to denote that this is a mobile phone.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257" />

<telecom use="H" value="tel:55354257" />

<telecom use="H" value="fax:56542558" />

<telecom value="tel:+41.34.21.4765342"/>

<telecom value="mailto:opr@opr-sem.no"/>

<telecom use="WP MC" value="tel:97555786" />
</syntaxhighlight>

It is possible to express the useable period of a telecommunication contact. A child element ''useablePeriod'' is used as a time interval to indicate this period.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''useablePeriod''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257">
<useablePeriod>
<high value="20111201"/>
</useablePeriod>
</telecom>
</syntaxhighlight>

=== Postal Address (AD) ===

Elements of this data type have a substructure in order to represent a structured address specification. In this implementation guide only a selection of all possible child elements is allowed, the original HL7 specification is richer.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''streetAddressLine''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Street address, includes street name and house number
|-
| '''city''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || City
|-
| '''postalCode''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Postal code
|-
| '''country''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Country
|-
|}

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that the sequence of the sub elements is country specific, i.e. it has to follow “common” rules how to write an address. For example, an UK address and a German address have different sequences of address representation.
|}

A ''@use'' attribute can also be specified.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="WP">
<streetAddressLine>Anna-Louisa-Karsch-Str. 2</streetAddressLine>
<postalCode>10178</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="H WP">
<streetAddressLine>Tatungasse 34</streetAddressLine>
<postalCode>10825</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

Also, a country may be specified using the element ''country''.

=== Person Name (PN) ===

Elements of this data type do also have a substructure to represent the parts of a person name, like family or given name and prefixes.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>
<given>Franz</given>
<given>Ingrun</given>
<family>Nordmann</family>
</name>
</syntaxhighlight>

Previous or birth or maiden names are supported using the ''validTime'' element. ''validTime'' (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]]) specifies the validity range of the name.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">

<name>
<given>Jan</given>
<given>Olaf</given>
<family>Hendrikson</family>
<validTime>
<high value="20000101"/>
</validTime>
</name>
</syntaxhighlight>

Note that the name attribute is repeating, i.e. multiple (types of) names could be sent. It is up to the receiver (based on the value of the ''@use'' attribute, and ''validTime'') to decide what name it wants to use or import in its database.

=== Organisation Name (ON) ===

Elements of this data type represent a name of an organization.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name> Charité Berlin </name>
</syntaxhighlight>

The optional ''validTime'' element (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]] may be used to specify the validity range of the name of the organization.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name of the organization
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>The old hospital
<validTime>
<high value="20111231235959"/>
</validTime>
</name>
</syntaxhighlight>

Please note that the use of ''validTime'' yields XML mixed content which should be avoid-ed if possible.

=== Integer Number (INT) ===

Elements of this data type are used to specify integer numbers and have one attribute.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>int</center> || <center>R</center> || Integer value
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<sequenceNumber value="24"/>
</syntaxhighlight>

=== Physical Quantities (PQ) ===

Elements of this data type are physical quantities, i.e. a measurable quantity (or countable) value from the physical world. This is different from just a “number”, because there is a (natural) unit specified in which the measurable quantity is expressed.
Examples:
* an amount of blood 20 ml (sample volume)
* a cut with a length of 10 cm (result observation)
* a dose of 200 milligrams per administration (dosing)
* delivery of 60 pieces of a tablet (amount supplied).
Elements of this data type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>real</center> || <center>R</center> || value of the measurement
|-
| '''@unit''' || <center>CS</center> || <center>R</center> || unit of measurement
|}

In the unit of measurement unit is expressed following the ''Unified Code for Units of Measure'' (UCUM) specification. This specification is a collection of atomic units, prefixes and a corresponding grammar for valid combinations to build all-natural units of measurement. For a complete description of possible units, see the ''Unified Code for Units of Measure'' <ref>Unified Code for Units of Measure: http://unitsofmeasure.org/</ref> specification.
If a value is not countable or if measurable, for example expressed in milligrams or liters, then this unit is a valid UCUM unit like “mg” or “L”. If a value is countable, for example the number of tablets, then this attribute contains “1”.
In HL7 it is required that all PQ data type units are valid UCUM units.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<value value="165" unit="cm"/>

<value value="81.1" unit="kg"/>

<value value="120" unit="mm[Hg]"/>

<value value="5" unit="1"/>
</syntaxhighlight>

=== Point in Time (TS) ===

Elements of this data type have the attribute

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>TS</center> || <center>R</center> || Point in time
|}

and specify points in time in the format YYYYMMDDhhmmss±ZZZZ, where
* YYYY is the four-digit year,
* MM the two-digit month,
* DD the two-digit day,
* hh the two-digit hour,
* mm the two-digits minute and
* ss the two-digit second.
Optional a time zone ZZZZ, the four-digit time alignment with a preceding “-” or a “+” can be specified. If time zone is omitted, local time is assumed.
The point in time may be right truncated in respect to the precision of the information.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<effectiveTime value="20140412"/>

<effectiveTime value="201409091245"/>

<effectiveTime value="1996"/>

<birthTime value="19540714"/>

<effectiveTime value="20140412+0100"/>
</syntaxhighlight>

=== Intervals (IVL) ===

Intervals are defined only for data types with an ordinal or interval scale type. There are several possibilities to determine an interval (see Figure 2), for example to specify

* a lower <low> and an upper boundary <high> (a),
* a lower <low> boundary and width <width> (b)
* an upper boundary and width <width> (c) or
* the middle of the interval <nowiki><center></nowiki> and a width <width> (d).

[[File:CDA_Core_Principles_Figure_2_Determining_Intervals.png|700px]]

<ref group="Figure">Several possibilities to determine closed intervals</ref> ''Several possibilities to determine closed intervals''

{{ConstraintBox|
To indicate an interval, only the following combinations are permitted.
(1) A lower and an upper boundary may not be identical, and their accuracy has to be equal.

Correct examples:

{{BeginGreenBox|}}
Interval from 5 to 6
Interval from 20110607 until 20110612
{{EndGreenBox}}

Incorrect examples:

{{BeginRedBox|}}
Interval from 5 to 6.0
Interval from 20110101 to 2011
{{EndRedBox|}}

(2) A lower boundary and a width

(3) A lower limit boundary

(4) A upper limit boundary

(5) Only the middle of the interval

(6) Only the width of an interval}}

Accordingly, four child elements are available.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Lower boundary
|-
| '''high''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Upper boundary
|-
| '''center''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Where ''(T)'' is defined in this specification as one of the data types “TS” or “PQ”.

=== Interval of time (IVL_TS) ===

Elements of this data type represent time intervals. There are four possible child elements.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Lower boundary (start date/time)
|-
| '''high''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Upper boundary (end date/time)
|-
| '''center''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Normally, a lower and an upper boundary is given, both are points in time. Also, it is possible to specify open intervals like “since June 14, 1999” (left boundary given only) or “until September 24, 2006” (right boundary given).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110507"/>
<high value="20110909"/>
</effectiveTime>

<effectiveTime>
<low value="20110507"/>
</effectiveTime>

<value>
<low value="20110101"/>
<width value="120" unit="d"/>
</value>

<value>
<center value="20110101"/>
</value>
</syntaxhighlight>

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|It must be noted that intervals of time stamps in HL7 are equally treated as other interval types (e.g. integers). The statement, one may take 1–3 tablets (interval of integers), for example, says that you are allowed to take no more than three tablets, not 3½ or 3.5 tablets. On the other hand, when treat the words “until 12 June 2011” regarding the upper interval limit differently, particularly we assume that the entire day 12 June is still in-cluded in this time interval.
Thus, in human perception time intervals are handled differently com-pared to such as number intervals. This is a situation may lead to inconsist-encies in standardized communication. As a conclusion, an upper limit “12 June 2011” means that only the very first moment of the 12 June is included in the interval, but not, for example, the 12 June 13:00 hours.
Interpretation does not depend on the accuracy of the time:
* “after 2004” means “from January 1, 2005 00:00:00.000”,
* “after 20041201” means “from 2 December 2004 00:00:00.000 hours”,
* and “after 200412011200” means “from 1 December 2004 12:01:00.000”.

As a result, you have to carefully consider the specification and implemen-tation of time intervals upper boundaries. In order to prevent mis-understandings intervals are always specified with the date and time for an upper limit that would cover the whole day. Accordingly, “201106122359” means 12 June 2011 throughout the day.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="201106122359"/>
</effectiveTime>
</syntaxhighlight>

Because of the equal treatment of time intervals this is applied also to the lower limit boundaries of time intervals as “0000”. This means for example that “since 9 June 2011” is expressed as “201106090000”.
|}

The <width> element is of data type PQ (physical quantity). The value obviously shall relate to a period of time and it is required to include a “time” unit. These are the units “us” (microseconds), “ms” (milliseconds), “s” (seconds), “min” (minute), “h” (hours), “d” (day), “wk” (week), “mo” (month) and “a” (year).

{{ConstraintBox|
For interval of time stamps the @unit of a ''low'' or ''high'' child element shall use units
* us (microseconds),
* ms (milliseconds),
* s (seconds),
* min (minute),
* h (hours),
* d (day),
* wk (week),
* mo (month) or
* a (year).
}}

=== Interval of physical quantities (IVL_PQ) ===

Elements of this data type are used to indicate intervals of physical quantities (see also [[#Physical Quantities (PQ)|3.18 Physical Quantities (PQ)]]). In general, an upper and a lower boundary is specified. It is also possible to use ''center'' instead of ''low'' and ''high''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low || <center>TS</center> || <center>0..1</center> || <center>C</center> || the lower limit of the interval (i.e. the minimum amount).
|-
| '''high || <center>TS</center> || <center>0..1</center> || <center>C</center> || the upper limit of the interval (i.e. the maximum amount).
|-
| '''center || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of the interval
|}

The ''center'' child element is used when there is no interval, but an exact value. Alternative would be to demote IVL_PQ to data type PQ and populate the element’s ''@value'' attribute, but this is more difficult to process in XML. That is why the use of the ''center'' child element is deprecated.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<referenceRange>
<low value="7.5" unit="mmol/l"/>
<high value="10" unit="mmol/l"/>
</referenceRange>

<doseQuantity>
<center value="9" unit="1"/>
</doseQuantity>
</syntaxhighlight>

=== Ratio of quantities (RTO_QTY_QTY) ===

Elements of this data type specify ratios and have two child elements, a numerator and a denominator. The underlying QTY (Quantity) data type is an abstract data type and in a XML instance it has to be replaced by a specific data type using the ''@xsi:type'' instruction (see below).

In this specification only “PQ” or “INT” are allowed for the demotion of both ''numerator'' and ''denominator''. The relevant child elements are:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''numerator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the numerator of the ratio
|-
| '''denominator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the denominator of the ratio
|}

If a model attribute already is a RTO_QTY_QTY, you need to specify (demote) the OTY abstract data type for both ''numerator'' and ''denominator'' by using an ''@xsi:type'' instruction.
In some cases where the model attribute is of type “ANY”, also the root element shall carry an ''@xsi:type'' RTO_QTY_QTY instruction.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<maxDoseQuantity>
<numerator xsi:type="PQ" value="6"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="400" unit="mg"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="5"/>
<denominator xsi:type="PQ" value="1" unit="h"/>
</maxDoseQuantity>

<value xsi:type="RTO_QTY_QTY">
<numerator xsi:type="INT" value="1"/>
<denominator xsi:type="INT" value="10000"/>
</value>
</syntaxhighlight>

== Identification mechanisms ==

=== Object Identifiers (OIDs) ===

Standardized exchange of information using messages or documents also deals with unique identifications of objects and concepts, especially in environments where sender and receiver do not “know” each other necessarily.

It is important to understand the difference between identification of instances (ids) and code concepts (classifications). Within the context of HL7 interactions OIDs are quite often used.
An id points to a specific instance of an object or identification scheme (a particular methodology for the identification of a class of objects), for example a specific person as the patient or a physician, a specific lab observation or an X-ray photo.

In contrast to instance identifiers, a classification identifies a specific concept. The type of patient (inpatient, outpatient), the type of doctor (an anesthesiologist), the codes for gender or a lab observation (blood cell count) may serve as examples.

OIDs (object identifiers) are worldwide unique identifiers for objects. They are used in HL7 to specify identifications and classifications. An object in this sense is persistent, well-defined information, definitions or specifications and is represented with ids or codes.

Commonly used OIDs (i.e. used for a purpose that is wider in scope than the regional healthcare organization; used in communications between healthcare regions) can be found in OIDs registries such as

* [http://www.oid-info.com www.oid-info.com],
* [http://www.hl7.org www.hl7.org],
* [http://www.hl7.org.uk/version3group/oids.asp HL7 OID registry in the UK],
* [https://www.dimdi.de/dynamic/de/klassifikationen/weitere-klassifikationen-und-standards/oid/ OID registry Germany].

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|All OIDs with an element of 999 or 9999 are for documentation purposes only. They will be replaced by permanent OIDs once these have been as-signed/found/applied for.
|}

OID (Object Identifiers) are unique identifiers for any kind of objects. They are defined in Rec. ITU-T X.660 | ISO/IEC 9834-1. This identification system for objects and concepts makes reliable electronic information exchange possible. Administration and Registration is regulated by a set of rules, described in the corresponding chapter of this document.

Every artefact in ART-DECOR has an Object Identifier (OID). There are recommendations for the management and the exchange of Object Identifiers, partially defined in ISO TS 13582 <ref>ISO TS 13582: https://www.iso.org/standard/69652.html</ref>.

''HL7 International'' has created a type ontology for the OIDs in the HL7 registry to make it easier for the user community to search for OIDs they may be looking for and can be found at hl7.org.

From a policy perspective it is common practice in several healthcare related OID registries (HL7 International at http://www.hl7.org, OID Registry Germany at http://www.dimdi.de, OID registry Switzerland at http://oid.refdata.ch, and OID registry Austria at https://www.gesundheit.gv.at/OID_Frontend) to distinguish at least between the following types of OIDs:

{| class="hl7table" style="width:60%"
|+<ref group="Table">Recommended OID sub-branches for different artefacts</ref> ''Recommended OID sub-branches for different artefacts''
! Arc !! Description
|-
| .3 || organizational bodies and groups
|-
| .4 || identifier systems and namespaces
|-
| .5 || code systems
|-
| .7 || document artefacts
|-
| .9 || conformance profiles
|-
| .10 || templates
|-
| .11 || value sets
|-
| .19 || examples
|-
| .99 || experimental
|}

''Example: given that “your” root OID is 1.2.3.4.5, the first value set of your governance group is then to be 1.2.3.4.5.11.1, with .11 as the value set “branch” and the last .1 as the first artefact of that kind.''

In ART-DECOR a project typically is set into the .77 branch of a governance group. When setting up the project, the OID for that project also determines the artefact OIDs using throughout the ART-DECOR project. The following additional branches are used to distinguish between different OID types:

{| class="hl7table"
|+<ref group="Table">Recommended OID sub-branches for ART-DECOR projects</ref> ''Recommended OID sub-branches for different artefacts''
! Artefact code Description !! Recommended !! OID suffix
|-
| DS || dataset || .77.1
|-
| DE || dataset concept || .77.2
|-
| SC || scenario || .77.3
|-
| TR || transaction in scenario || .77.4
|-
| CS || code system || .77.5
|-
| IS || issue || .77.6
|-
| AC || actor in scenario || .77.7
|-
| CL || concept list in dataset || .77.8
|-
| EL || element in template || .77.9
|-
| TM || template || .77.10
|-
| VS || value set || .77.11
|-
| RL || rule for instances || .77.12
|-
| SX || test/example scenario || .77.18
|-
| EX || test/example instance || .77.19
|-
| QX || qualification test/example || .77.20
|-
| TX || test/example data element || .77.21
|-
| CM || community || .77.22
|-
| MP || concept map || .77.24
|}

In ART-DECOR a newly created project uses these OID branches automatically.

=== Instance identification ===

Instance identification is done with the id element of a class. Its type is II (instance identifier) and described in the data type section above. For example, a patient number can be represented as
* 2.16.578.1.34.1.5432.1, the root-OID of the issuing authority, for example a system/application in a hospital, and
* 67543242 as the ''@extension'', representing the patient number within the system defined by the ''@root'' attribute.

=== Coding scheme identification ===

Coding schemes have to be uniquely identified using OIDs as well. All coding tables used in this implementation guide show the corresponding OID that has to be specified in the ''@codeSystem'' attribute of coded elements. Both attributes ''@code'' and ''@codeSystem'' together allows a correct interpretation of concept and code.

=== List of identification schemes ===

The following are OIDs for commonly used identification schemes.

{| class="hl7table"
|+<ref group="Table">Commonly used identification scheme OIDs</ref> ''Commonly used identification scheme OIDs''
! OID !! Identification System Name !! Description !! Issuer
|-
| 1.2.276.0.76.4.8 || KV-Nummer || Krankenversichertennummer ||
|-
| 1.2.276.0.76.4.17 || BSNR || Betriebsstättennummer ||
|-
| 1.2.276.0.76.4.16 || LANR || lebenslange Arztnummer ||
|}

=== List of code systems ===

The following are OIDs for code systems.

{| class="hl7table"
|+<ref group="Table">Commonly used code system OIDs</ref> ''Commonly used code system OIDs''
! OID !! Code System Name !! Description !! Issuer
|-
| 2.16.840.1.113883.6.1 || LOINC || Logical Observation Identifiers Names and Codes (LOINC) || Regenstrief Institute
|-
| 2.16.840.1.113883.6.96 || SNOMED CT || Systemized Nomenclature in Medicine Reference Terminology (SNOMED CT) || SNOMED International
|-
| 1.0.3166.1.2 || ISO 3166-1 (second edition) || Country codes as per ISO 3166-1:2007 || ISO
|}

== Vocabulary ==

=== Code Systems ===

Within HL7, a ''Code System'' is defined as a collection of codes with associated designations and meanings. Examples of code systems include ICD-10, SNOMED CT, and LOINC.
To meet the requirements of a code system as defined by HL7, a given code must resolve to one and only one meaning within the code system. Given this definition, each code table in the HL7 Version 3 standard represents a different code system since codes are sometimes used in different tables to have different meanings.
For example, “M” in the administrative gender table (''AdministrativeGender'', OID 2.16.840.1.113883.5.1) means “male”, while “M” in the marital status table (''MaritalStatus'', OID 2.16.840.1.113883.5.2) means “married”.
In this specification, code system tables are not presented in detail.

=== Value Sets ===

A ''Value Set'' represents a uniquely identifiable set of valid concept representations, where any concept representation can be tested to determine whether or not it is a member of the value set.
Value set complexity may range from a simple flat list of concept codes drawn from a single code system, to an unbounded hierarchical set of possibly post-coordinated expressions drawn from multiple code systems.
Value sets exist to constrain the content for a coded element in an HL7 static model or data type property. Value sets cannot have null content and must contain at least one concept representation where any given concept is generally (but not required to be) represented by only a single code within the Value Set.

[[File:CDA_Core_Principles_Figure_3_ValueSet_Example.png|800px]]

<ref group="Figure">Example presentation of the value set “MaritalStatus”</ref> ''Example presentation of the value set “MaritalStatus”''

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that value set OIDs never appear in a CDA Release 2 document. They are used for constraint expressions, for example in implementation guides.
In order to send a specific code drawn from a value set, the corresponding code system has to be conveyed.
An example, in the implementation specification the constraint on the model element ''maritalStatusCode'' is expressed as “to be drawn from value set 2.16.840.1.113883.5.2 ''MaritalStatus''”.
To actually send a marital status of “M” (married) that is shown in the value set figure above, the corresponding HL7 CDA instance would say:
<syntaxhighlight lang="xml">
<maritalStatusCode code="M" codeSystem="2.16.840.1.113883.5.2"/>
</syntaxhighlight>
|}

In this specification, value set tables are not presented in detail.

==== Binding strength ====

There is an optional vocabulary strength for data types that support that feature (coded concepts). Examples include CD, CE, CV and CO. Values are required, extensible, preferred and example. Default is required.

Please note: the formerly supported values CNE (Coded No Extensibility) and CWE (Coded With Extensibility) in ART-DECOR are deprecated as of December 2017. Specification CNE is handled as required and CWE is handled as extensible.

{| class="hl7table"
|+<ref group="Table">Binding Strengths</ref> ''Binding Strengths''
! Strength !! Description
|-
|required||Required/CNE. Coded with no exceptions; this element SHALL be from the specified value set
|-
|extensible||Extensible/CWE. Coded with Exceptions; this element SHALL be from the specified value set if any of the codes within the value set can apply to the concept being communicated. If the value set does not cover the concept (based on human review), alternate codings (or, data type allowing, text) may be included instead.
|-
|preferred||Preferred. Instances are encouraged to draw from the specified codes for interoperability purposes but are not required to do so to be considered conformant.
|-
|example||Example. Instances are not expected or even encouraged to draw from the specified value set. The value set merely provides examples of the types of concepts intended to be included.
|}

Mismatches with required lead to validation errors (SHALL logic). Mismatches with extensible lead to validation warnings (SHOULD logic). Mismatches with preferred lead to validation information messages (MAY logic). Mismatches with example don't have any validation consequences.

== Appendix ==

=== References ===

<references/>

=== List of figures ===

<references group="Figure" />

=== List of tables ===

<references group="Table" />

HL7 CDA Core Principles

2019-06-16T11:10:22Z

Dammon: /* Concept Descriptor (CD) */

== Introduction ==

This implementation guide specifies the ''Core Principles'' of using the ''Clinical Document Architecture'' <ref>Clinical Document Architecture Release 2: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=7</ref>.

=== Scope ===

This guide focuses on ''Data Types Release 1'' <ref>HL7 Data Types Release 1: http://www.hl7.org</ref>. Meanwhile an ISO specification ISO 21090 is out, also known as Data Type Release 2. The latter is subject to another implementation guide that will be published when ISO data types are used.

=== Focus of this document: HL7 Version 3 Data Types for CDA ===

The following chapters of this document will focus on the description of the data types and associated material. It will highlight the essentials in four chapters, all focusing on the Norwegian situation.
* '''Common aspects:''' explains common aspects of use of CDA and XML
* '''Data types:''' gives an overview and detailed specification of all data types used in CDA
* '''Identification schemes:''' explains major aspects of identification and the use in CDA
* '''Use of vocabulary:''' explains major aspects of vocabulary use in CDA.

=== Background ===

In many (European) countries, implementation guides for the use of data types in HL7 V3 are published. They take into account country specific constraints on the data types.

=== Legend of symbols ===

In this document several symbols are used.

{| class="hl7table" style="width:50%"
| [[File:Pfeil_rechts.png|50px]] || This is an important item
|-
| [[File:Issue.svg|50px]] || This is a known open issue
|-
| [[File:Faq.svg|50px]] || This is a frequently asked question (FAQ) with answer
|-
| [[File:Conformance.svg|50px]] || This is a constraint; in some situations also the rule identification is specified, e.g. dtr1-1-ANY, which links to the corresponding validation rule.
|}

=== Version history ===

{| class="hl7table" style="width:50%"
|+
! Version !! Date !! Description !! Author
|-
| 1.1 || 2019-04-24 || Refurbished guide based on earlier work || Kai U. Heitmann
|}

== Common aspects ==

=== Use of XML ===

HL7 Version 3 CDA uses the Extensible Markup Language (XML) as the exchange format. It is assumed that the reader is familiar with common XML aspects. However, some constraints are made regarding the use of CDA.

==== Character Set ====

{{ConstraintBox|
The character encoding of any CDA document shall be “UTF-8”.}}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="utf-8"?>
</syntaxhighlight>

=== CDA document structure ===

The XML namespace for CDA Release 2 documents is ''<nowiki>urn:hl7-org:v3</nowiki>''. This must be correctly mentioned in every XML instance.

CDA XML documents starts with the root element ''ClinicalDocument''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">


...

<component>
<structuredBody>
...
</structuredBody>
</component>

</ClinicalDocument>
</syntaxhighlight>

== Data types ==

=== Introduction ===

The following chapter describes the typical data types used in CDA implementation guides. For further information please refer to the HL7 V3 standard and its two parts concerning data types:
* Abstract Data type definition <ref>HL7 Version 3 Abstract Data type definition: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=264</ref>
* XML ITS for data types <ref>XML ITS for data types: https://www.hl7.org/documentcenter/public_temp_682D4D16-1C23-BA17-0C789BA52BEDB68E/wg/inm/datatypes-its-xml20050714.htm</ref>
Data types are properties of model class attributes and the basic building blocks of information in a CDA XML instance. For example, a model attribute named “time” has as its data type a time stamp “TS” (see Figure 1).

[[File:CDA_Core_Principles_Figure_1_CDA_Structure_Data_Types.png|700px]]

<ref group="Figure">CDA structure (left) and the data type specification (right)</ref> ''CDA structure (left) and the data type specification (right)''

=== XML representation of data types ===

Actual data is mostly carried in HL7 Version 3 by populating XML attributes and not as element content. Exceptions are names of persons and organizations as well as addresses.

The XML elements have names like the model attributes. For example, a model attribute “id” has a corresponding XML element named <id…>. The model determines the sequence of elements and their hierarchy. The data type itself determines the XML attributes within the start tag. The notation here is as follows:

{| class="hl7table"
|+
! Attribute !! DT !! Conf !! Description
|-
| (name of the model attribute or XML element) || Data type || Conformance, i.e. O, R, M || Textual description
|}

XML attributes (data type properties) are denoted as ''@attribute'' in order to distinguish their names from XML elements.

Example: in the example model above, the data type of the ''id'' attribute's is ''II'' (Instance Identifier). The corresponding XML attributes for that data type include ''@root'' and ''@extension''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id root="..." extension="..." />
</syntaxhighlight>

A description of the data types and their corresponding XML representation is contained in subsequent paragraphs of this guide.

==== Exceptions using XML element content ====

For most data types, the actual data is conveyed in XML attributes. However, there are some exceptions. For the data types binary (BIN), Encapsulated Data (ED), Entity Name (EN), Person Name (PN), Organization Name (ON), Trivial Name (TN), Address (AD) and character string data (ST), information is carried as element content.

Example: the components of an address <addr> are represented by sub elements with the data as element content (in the example shown in black).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr>
<streetAddressLine>Thormøhlens gate 12</streetAddressLine>
<postalCode>5006</postalCode>
<city>Bergen</city>
</addr>
</syntaxhighlight>

==== Combined data types ====

There are a number of so-called combined data types. For example, an interval with a lower and upper limit and a ratio that has a nominator and a denominator value.

In combined data types the substructure (e.g. <low> <high> in an interval) are represented as child elements of the relevant data type element.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110701"/>
<high value="20110729"/>
</effectiveTime>
</syntaxhighlight>

==== Conformance information ====

The conformance indicators distinguish kinds of conformance information described shortly here.

* '''O''': An optional item may be omitted if no data is present, i.e. no corresponding XML attribute or element is sent (marked as “O”)
* '''R''': For required items, lower cardinality is always zero or 1.
** Elements must be present and populated with data if present in the sending system. If no data is available (yet), a null flavor (see below) indicates and possibly classifies the missing information (marked as R).
** Attribute flagged as required must be present in the instance and populated.
* '''M''': For mandatory elements data must be sent and no missing values are allowed, i.e. if the sending system does not have information for mandatory elements the XML instance cannot be created and sent (marked as M).
* '''NP''': no data may be present at all (not permitted)
* '''C''': conditional conformance; typically a conformance table shows the circumstances (conditions) derived from information in the instance and the corresponding cardinalities and conformance statements.

=== Missing values (null flavor) ===

For every data type it is possible to specify a missing value including a kind of reason why data is missing. Instead of specifying any attribute of the corresponding element, a ''@nullFlavor'' attribute expresses the omission of data. Note that missing data is not allowed for mandatory elements (see above).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value nullFlavor="OTH"/>

<code nullFlavor="UNK"/>

<booleanInd nullFlavor="NI"/>

</syntaxhighlight>

The codes for the ''@nullFlavor'' attribute are drawn from the following hierarchical code system. It is a Coded Simple (CS), which means it has no code system (attribute ''@codeSystem'') specified.

{| class="hl7table"
|+<ref group="Table">NullFlavor</ref> ''NullFlavor''
! Code
! width=15% | Print Name
! Definition / Description
|-
| NI || No Information || No information whatsoever can be inferred from this exceptional value. This is the most general exceptional value. It is also the default exceptional value.
|-
|   OTH || other || The actual value is not an element in the value domain of a variable. (e.g., concept not provided by required code system).
|-
|     NINF || negative infinity || Negative infinity of numbers.
|-
|     PINF || positive infinity || Positive infinity of numbers.
|-
|   UNK || unknown || A proper value is applicable, but not known.
|-
|     ASKU || asked but unknown || Information was sought but not found (e.g., patient was asked but didn't know)
|-
|       NAV || temporarily unavailable || Information is not available at this time but it is expected that it will be available later.
|-
|       NASK || not asked || This information has not been sought (e.g., patient was not asked)
|-
|       TRC || trace || The content is greater than zero, but too small to be quantified.
|-
|   MSK || masked || There is information on this item available but it has not been provided by the sender due to security, privacy or other reasons. There may be an alternate mechanism for gaining access to this information.
Note: using this null flavour does provide information that may be a breach of confidentiality, even though no detail data is provided. Its primary purpose is for those circumstances where it is necessary to inform the receiver that the information does exist without providing any detail.
|-
|   NA || not applicable || No proper value is applicable in this context (e.g., last menstrual period for a male).
|-
| NP || not present || Value is not present in a message. This is only defined in messages, never in application data! All values not present in the message must be replaced by the applicable default, or no-information (NI) as the default of all defaults.
|}

=== ANY as the generic data type ===

This abstract data type is the basis for all other data types. Not a single value within a CDA document has the effective data type ANY, but any data type within HL7v3 is a specialization of ANY. This also means that any other data type inherits all properties of ANY (see [[#Missing_values_.28null_flavor.29|“Missing values (null flavor)”]]).

The ANY type is occasionally found in HL7 models when it comes to clinical finding etc. where – at model time – the actual data type of the value is not known. At instantiation time however, the actual data type ''is'' known and ANY is always replaced by a particular data type in an instance.

One example is the observation value (child element value in an observation), where in the model the data type of value cannot be anticipated. When instantiation is taking place, the data type is specified by the XML instance attribute ''@xsi:type''. This information can be used by the receiver to validate and process the value.

Attributes of an element with this data type are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@nullFlavor''' || <center>CS</center> || <center>–</center> || Classification of the missing value, see [[#Missing_values_.28null_flavor.29|3.3 Missing values (null flavor)]].
|}

{| class="hl7table" style="width:100%"
| width=8% | <center>[[File:Conformance.svg|50px]] dtr1-1-ANY</center> || If there is a ''nullFlavor'', there shall be no other attribute or element, unless it's ''nullFlavor="OTH"''.

In that case ''@codeSystem'' or ''originalText'' (see “code” data types) may have a value.
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">

<value xsi:type="CE" code="N11.9" codeSystem="2.16.840.1.113883.6.3"/>


<value xsi:type="PQ" value="12" unit="mL"/>


<value xsi:type="ED">this is text</value>
</syntaxhighlight>

=== Boolean (BL) ===

Elements of this data type refer to Boolean logic and have an attribute ''@value''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>BL</center> || <center>–</center> || Valued as “true” or “false”
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<negationInd value="false"/>

<deceasedInd value="true"/>

</syntaxhighlight>

In some situations, the BL data does not apply to an XML element, but an attribute. In that case, the attribute carries the Boolean value directly.
<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<support contextConductionInd ="false">
...
</support>
</syntaxhighlight>

=== Instance Identifier (II) ===

This data type identifies instances of classes like observations or entities (persons, organizations). Attributes are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@extension''' || <center>ST</center> || <center>O</center> || Identification
|-
| '''@root''' || <center>OID</center> || <center>R</center> || Source of identification
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id extension="13234453645" root="2.16.840.1.113883.2.6.15.3.427.1"/>
</syntaxhighlight>

The ''@root'' attribute is of type OID (object identifier), a unique identifier of the issuing authority or system. For example, a patient with a patient number 13234453645 created by a specific healthcare provider organization is uniquely identified by the number itself in ''@extension'' and the OID of the organization or the sending system, in the example 2.16.840.1.113883.2.6.15.3.427.1 in ''@root''.

In some cases, a single OID identifies an object uniquely. In that situation, only ''@root'' is populated and ''@extension'' is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Encapsulated Data (ED) ===

Elements of this data type carry multimedia content. The actual multimedia content is represented as element content. There are two situations for the use of ED:

* Inline: The full data is transmitted in the type. This form is mainly used for text.
* By reference: a thumbnail is provided which links to the full data by reference.

In an instance, the data type is normally determined by an ''xsi:type'' specification and some attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@mediaType''' || <center>CS</center> || <center>O</center> || MIME media type classification. At time of writing this specification, the following MIME types are allowed:
* text/plain (plain text)
* text/html (text with html markup)
* image/jpeg (JPEG image)
* application/pdf (a PDF, portable document format)
* application/hl7-sda+xml (CDA documents).
|-
| '''@representation''' || <center>CS</center> || <center>O</center> || Representation of the multimedia content. At time of writing this specification, the following representations are allowed:
* TXT (text, this is the default)
* B64 base 64 encoded data, for example for embedded CDA documents).
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<text xsi:type="ED" mediaType="text/plain">
Patient treated sucessfully
</text>

<text mediaType="application/hl7-sda+xml" representation="B64">PD94bWw..etc..==</text>

</syntaxhighlight>

To include referenced data the two sub elements ''thumbnail'' and ''reference'' are used.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''reference''' || <center>TEL</center> || <center>0..*</center> || <center>O</center> || Link (URI) to full data
|-
| '''thumbnail''' || <center>ED</center> || <center>0..*</center> || <center>O</center> || Thumbnail of referenced data
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value xsi:type="ED" mediaType="image/png" representation="B64">
<reference value="http://radiology.bergen.no/xrays/128s.png"/>
<thumbnail mediaType="image/jpeg" representation="B64"> MNY...83== </thumbnail>
</value>
</syntaxhighlight>

=== Strings (ST) ===

This data type is a specialization of the ED type where ''@mediaType'' is fixed “text/plain” and ''@representation'' is fixed “TXT”. It allows conveying a character string as '''element content'''. This data type is used in other data types it like the ''@extension'' in instance identifiers, or address and person name data type components.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<lotNumber> 143GT6DT </lotNumber>
</syntaxhighlight>

=== Concept Descriptor (CD) ===

This data type specifies a concept by means of a code and its code system (except for situations where no code is available).

A couple of specializations of data type CD exist, which differ in the main characteristics (properties) of the data type that may or may not be supported.

{| class="hl7table" style="width:50%"
|+<ref group="Table">Properties of data types used for codes</ref> ''Properties of data types used for codes''
! <div style="text-align: right">DataType</div> !! CD !! CE !! CV !! CO !! CS
|-
! <div style="text-align: left">Property</div> !! !! !! !! !!
|-
| '''@code''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||<center>X</center>
|-
| '''@codeSystem''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''@codeSystemVersion''' || <center>X</center> || <center>X</center> || <center>X</center>|| <center>X</center> ||
|-
| '''@displayName''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''originalText''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''translation''' || <center>X</center> || <center>X</center> || || ||
|-
| '''qualifier''' || <center>X</center> || || || ||
|}

Because the CE variant is most used in practice, the general explanation of the properties will be given with de description of CE (see below).

The only attribute that is unique to CD is briefly explained here.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@qualifier''' || <center>CR</center> || <center>O</center> || An additional qualifier for the code.
|}

Complex terminologies like SNOMED CT can be used only using data type CD.

=== Coded with Equivalents (CE) ===

With elements of this data type, a concept by means of a code and its coding system (except for situations where no code is available) can be specified. It optionally contains one or more equivalents using other code systems.
It may contain the following attributes:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@code''' || <center>ST</center> || <center>R</center> || The actual code
|-
| '''@codeSystem''' || <center>OID</center> || <center>R</center> || required to identify the code system were the code is drawn from. This is an OID (object identifier, see [[#Object_Identifiers_.28OIDs.29|Object Identifiers at 4.1]])
|-
| '''@displayName''' || <center>ST</center> || <center>O</center> || Optional textual representation of code. A display name may be specified representing the plain text of the code. The information of this attribute may not be used by the receiving system for interpretation, but only for display purposes. The display name may never be transmitted without a code and must have the same meaning as the code.
|-
| '''@codeSystemName''' || <center>ST</center> || <center>O</center> || A textual representation of the name of the code system
|-
| '''@codeSystemVersion''' || <center>ST</center> || <center>O</center> || A textual representation of the version of the code system
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"/>

<code code="AU" codeSystem="2.16.840.1.113883.5.33"/>

<storageCode code="AC" codeSystem="2.16.840.1.113883.5.34" displayName="active"/>

<code code="A45.0" displayName="Somatisierungsstörung" codeSystem="1.2.276.0.76.5.409" codeSystemName="ICD-10 GM 2012"/>
</syntaxhighlight>

There are some child elements of codes that can be used to express what the “original text” was that was used for the coding or to indicate that there are “translations” to other code systems than the primary code.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''originalText''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Textual representation of the concept, actually a description which was used to create the actual code
|}

No semantics may be assumed other than showing the ''@displayName'' to a user to clarify the code. A display name cannot occur without its code and must carry the same meaning.

In case no code is known, it is allowed to specify a ''@nullFlavor'' for the code element and to give information about the (not yet coded) concept in original text. However, this should be an exception.

If other codes than the primary code need to be conveyed adding a translation child element can be used.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<originalText>minor aphthous stomatitis</originalText>
</code>
</syntaxhighlight>

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''translation''' || <center>CD</center> || <center>0..*</center> || <center>O</center> || Alternative code(s)
|}

A ''translation'' element is also of type CD and shall have a code and a code system identified. It shall point to the same concept as the primary code. It is allowed that a translation conveys less conceptual details than the original code.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<translation code="528.2" codeSystem="2.16.840.1.113883.6.2" codeSystemName="ICD9" displayName="Oral aphthae"/>
</code>
</syntaxhighlight>

=== Coded Value (CV) ===

This is actually a specialization of CE (see above), with the exception that neither ''originalText'' nor ''translation'' child element are allowed.

=== Coded Simple Value (CS) ===

This is actually a specialization of CE (see above), with no code system attribute and no original text or translation child element allowed. It specifies a concept by means of a code from a ''predefined'' code system (table) where the code is drawn from. This data type is usually applied in the context of fixed predefined HL7 tables.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<statusCode code="completed"/>
</syntaxhighlight>

In this example ''statusCode'' is bound in the underlying model to the specific code system ''ActStatus''. Because it is predefined by means of the vocabulary binding, ''@codeSystem'' is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Telecommunication Address (TEL) ===

Elements of this type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>ST</center> || <center>R</center> || carries strings that represent telecommunication contact information
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

The actual data is preceded by the scheme (refer to Internet Standard “RFC 1738 Uniform Resource Locators (URL)” <ref>RFC 1738 Uniform Resource Locators (URL): http://www.ietf.org/rfc/rfc1738.txt</ref>.

Examples:
* telephone (tel:),
* fax (fax:),
* email (mailto:).

It must follow the rules defined in Internet “RFC 2806 URLs for Telephone Calls” <ref>RFC 2806 URLs for Telephone Calls: http://www.ietf.org/rfc/rfc2806.txt</ref>.

The following codes will be used in the “use” attribute:
* H – Home
* WP – Work
* MC can be used (in addition to H or WP) to denote that this is a mobile phone.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257" />

<telecom use="H" value="tel:55354257" />

<telecom use="H" value="fax:56542558" />

<telecom value="tel:+41.34.21.4765342"/>

<telecom value="mailto:opr@opr-sem.no"/>

<telecom use="WP MC" value="tel:97555786" />
</syntaxhighlight>

It is possible to express the useable period of a telecommunication contact. A child element ''useablePeriod'' is used as a time interval to indicate this period.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''useablePeriod''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257">
<useablePeriod>
<high value="20111201"/>
</useablePeriod>
</telecom>
</syntaxhighlight>

=== Postal Address (AD) ===

Elements of this data type have a substructure in order to represent a structured address specification. In this implementation guide only a selection of all possible child elements is allowed, the original HL7 specification is richer.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''streetAddressLine''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Street address, includes street name and house number
|-
| '''city''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || City
|-
| '''postalCode''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Postal code
|-
| '''country''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Country
|-
|}

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that the sequence of the sub elements is country specific, i.e. it has to follow “common” rules how to write an address. For example, an UK address and a German address have different sequences of address representation.
|}

A ''@use'' attribute can also be specified.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="WP">
<streetAddressLine>Anna-Louisa-Karsch-Str. 2</streetAddressLine>
<postalCode>10178</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="H WP">
<streetAddressLine>Tatungasse 34</streetAddressLine>
<postalCode>10825</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

Also, a country may be specified using the element ''country''.

=== Person Name (PN) ===

Elements of this data type do also have a substructure to represent the parts of a person name, like family or given name and prefixes.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>
<given>Franz</given>
<given>Ingrun</given>
<family>Nordmann</family>
</name>
</syntaxhighlight>

Previous or birth or maiden names are supported using the ''validTime'' element. ''validTime'' (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]]) specifies the validity range of the name.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">

<name>
<given>Jan</given>
<given>Olaf</given>
<family>Hendrikson</family>
<validTime>
<high value="20000101"/>
</validTime>
</name>
</syntaxhighlight>

Note that the name attribute is repeating, i.e. multiple (types of) names could be sent. It is up to the receiver (based on the value of the ''@use'' attribute, and ''validTime'') to decide what name it wants to use or import in its database.

=== Organisation Name (ON) ===

Elements of this data type represent a name of an organization.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name> Charité Berlin </name>
</syntaxhighlight>

The optional ''validTime'' element (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]] may be used to specify the validity range of the name of the organization.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name of the organization
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>The old hospital
<validTime>
<high value="20111231235959"/>
</validTime>
</name>
</syntaxhighlight>

Please note that the use of ''validTime'' yields XML mixed content which should be avoid-ed if possible.

=== Integer Number (INT) ===

Elements of this data type are used to specify integer numbers and have one attribute.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>int</center> || <center>R</center> || Integer value
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<sequenceNumber value="24"/>
</syntaxhighlight>

=== Physical Quantities (PQ) ===

Elements of this data type are physical quantities, i.e. a measurable quantity (or countable) value from the physical world. This is different from just a “number”, because there is a (natural) unit specified in which the measurable quantity is expressed.
Examples:
* an amount of blood 20 ml (sample volume)
* a cut with a length of 10 cm (result observation)
* a dose of 200 milligrams per administration (dosing)
* delivery of 60 pieces of a tablet (amount supplied).
Elements of this data type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>real</center> || <center>R</center> || value of the measurement
|-
| '''@unit''' || <center>CS</center> || <center>R</center> || unit of measurement
|}

In the unit of measurement unit is expressed following the ''Unified Code for Units of Measure'' (UCUM) specification. This specification is a collection of atomic units, prefixes and a corresponding grammar for valid combinations to build all-natural units of measurement. For a complete description of possible units, see the ''Unified Code for Units of Measure'' <ref>Unified Code for Units of Measure: http://unitsofmeasure.org/</ref> specification.
If a value is not countable or if measurable, for example expressed in milligrams or liters, then this unit is a valid UCUM unit like “mg” or “L”. If a value is countable, for example the number of tablets, then this attribute contains “1”.
In HL7 it is required that all PQ data type units are valid UCUM units.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<value value="165" unit="cm"/>

<value value="81.1" unit="kg"/>

<value value="120" unit="mm[Hg]"/>

<value value="5" unit="1"/>
</syntaxhighlight>

=== Point in Time (TS) ===

Elements of this data type have the attribute

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>TS</center> || <center>R</center> || Point in time
|}

and specify points in time in the format YYYYMMDDhhmmss±ZZZZ, where
* YYYY is the four-digit year,
* MM the two-digit month,
* DD the two-digit day,
* hh the two-digit hour,
* mm the two-digits minute and
* ss the two-digit second.
Optional a time zone ZZZZ, the four-digit time alignment with a preceding “-” or a “+” can be specified. If time zone is omitted, local time is assumed.
The point in time may be right truncated in respect to the precision of the information.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<effectiveTime value="20140412"/>

<effectiveTime value="201409091245"/>

<effectiveTime value="1996"/>

<birthTime value="19540714"/>

<effectiveTime value="20140412+0100"/>
</syntaxhighlight>

=== Intervals (IVL) ===

Intervals are defined only for data types with an ordinal or interval scale type. There are several possibilities to determine an interval (see Figure 2), for example to specify

* a lower <low> and an upper boundary <high> (a),
* a lower <low> boundary and width <width> (b)
* an upper boundary and width <width> (c) or
* the middle of the interval <nowiki><center></nowiki> and a width <width> (d).

[[File:CDA_Core_Principles_Figure_2_Determining_Intervals.png|700px]]

<ref group="Figure">Several possibilities to determine closed intervals</ref> ''Several possibilities to determine closed intervals''

{{ConstraintBox|
To indicate an interval, only the following combinations are permitted.
(1) A lower and an upper boundary may not be identical, and their accuracy has to be equal.

Correct examples:

{{BeginGreenBox|}}
Interval from 5 to 6
Interval from 20110607 until 20110612
{{EndGreenBox}}

Incorrect examples:

{{BeginRedBox|}}
Interval from 5 to 6.0
Interval from 20110101 to 2011
{{EndRedBox|}}

(2) A lower boundary and a width

(3) A lower limit boundary

(4) A upper limit boundary

(5) Only the middle of the interval

(6) Only the width of an interval}}

Accordingly, four child elements are available.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Lower boundary
|-
| '''high''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Upper boundary
|-
| '''center''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Where ''(T)'' is defined in this specification as one of the data types “TS” or “PQ”.

=== Interval of time (IVL_TS) ===

Elements of this data type represent time intervals. There are four possible child elements.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Lower boundary (start date/time)
|-
| '''high''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Upper boundary (end date/time)
|-
| '''center''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Normally, a lower and an upper boundary is given, both are points in time. Also, it is possible to specify open intervals like “since June 14, 1999” (left boundary given only) or “until September 24, 2006” (right boundary given).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110507"/>
<high value="20110909"/>
</effectiveTime>

<effectiveTime>
<low value="20110507"/>
</effectiveTime>

<value>
<low value="20110101"/>
<width value="120" unit="d"/>
</value>

<value>
<center value="20110101"/>
</value>
</syntaxhighlight>

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|It must be noted that intervals of time stamps in HL7 are equally treated as other interval types (e.g. integers). The statement, one may take 1–3 tablets (interval of integers), for example, says that you are allowed to take no more than three tablets, not 3½ or 3.5 tablets. On the other hand, when treat the words “until 12 June 2011” regarding the upper interval limit differently, particularly we assume that the entire day 12 June is still in-cluded in this time interval.
Thus, in human perception time intervals are handled differently com-pared to such as number intervals. This is a situation may lead to inconsist-encies in standardized communication. As a conclusion, an upper limit “12 June 2011” means that only the very first moment of the 12 June is included in the interval, but not, for example, the 12 June 13:00 hours.
Interpretation does not depend on the accuracy of the time:
* “after 2004” means “from January 1, 2005 00:00:00.000”,
* “after 20041201” means “from 2 December 2004 00:00:00.000 hours”,
* and “after 200412011200” means “from 1 December 2004 12:01:00.000”.

As a result, you have to carefully consider the specification and implemen-tation of time intervals upper boundaries. In order to prevent mis-understandings intervals are always specified with the date and time for an upper limit that would cover the whole day. Accordingly, “201106122359” means 12 June 2011 throughout the day.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="201106122359"/>
</effectiveTime>
</syntaxhighlight>

Because of the equal treatment of time intervals this is applied also to the lower limit boundaries of time intervals as “0000”. This means for example that “since 9 June 2011” is expressed as “201106090000”.
|}

The <width> element is of data type PQ (physical quantity). The value obviously shall relate to a period of time and it is required to include a “time” unit. These are the units “us” (microseconds), “ms” (milliseconds), “s” (seconds), “min” (minute), “h” (hours), “d” (day), “wk” (week), “mo” (month) and “a” (year).

{{ConstraintBox|
For interval of time stamps the @unit of a ''low'' or ''high'' child element shall use units
* us (microseconds),
* ms (milliseconds),
* s (seconds),
* min (minute),
* h (hours),
* d (day),
* wk (week),
* mo (month) or
* a (year).
}}

=== Interval of physical quantities (IVL_PQ) ===

Elements of this data type are used to indicate intervals of physical quantities (see also [[#Physical Quantities (PQ)|3.18 Physical Quantities (PQ)]]). In general, an upper and a lower boundary is specified. It is also possible to use ''center'' instead of ''low'' and ''high''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low || <center>TS</center> || <center>0..1</center> || <center>C</center> || the lower limit of the interval (i.e. the minimum amount).
|-
| '''high || <center>TS</center> || <center>0..1</center> || <center>C</center> || the upper limit of the interval (i.e. the maximum amount).
|-
| '''center || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of the interval
|}

The ''center'' child element is used when there is no interval, but an exact value. Alternative would be to demote IVL_PQ to data type PQ and populate the element’s ''@value'' attribute, but this is more difficult to process in XML. That is why the use of the ''center'' child element is deprecated.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<referenceRange>
<low value="7.5" unit="mmol/l"/>
<high value="10" unit="mmol/l"/>
</referenceRange>

<doseQuantity>
<center value="9" unit="1"/>
</doseQuantity>
</syntaxhighlight>

=== Ratio of quantities (RTO_QTY_QTY) ===

Elements of this data type specify ratios and have two child elements, a numerator and a denominator. The underlying QTY (Quantity) data type is an abstract data type and in a XML instance it has to be replaced by a specific data type using the ''@xsi:type'' instruction (see below).

In this specification only “PQ” or “INT” are allowed for the demotion of both ''numerator'' and ''denominator''. The relevant child elements are:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''numerator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the numerator of the ratio
|-
| '''denominator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the denominator of the ratio
|}

If a model attribute already is a RTO_QTY_QTY, you need to specify (demote) the OTY abstract data type for both ''numerator'' and ''denominator'' by using an ''@xsi:type'' instruction.
In some cases where the model attribute is of type “ANY”, also the root element shall carry an ''@xsi:type'' RTO_QTY_QTY instruction.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<maxDoseQuantity>
<numerator xsi:type="PQ" value="6"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="400" unit="mg"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="5"/>
<denominator xsi:type="PQ" value="1" unit="h"/>
</maxDoseQuantity>

<value xsi:type="RTO_QTY_QTY">
<numerator xsi:type="INT" value="1"/>
<denominator xsi:type="INT" value="10000"/>
</value>
</syntaxhighlight>

== Identification mechanisms ==

=== Object Identifiers (OIDs) ===

Standardized exchange of information using messages or documents also deals with unique identifications of objects and concepts, especially in environments where sender and receiver do not “know” each other necessarily.

It is important to understand the difference between identification of instances (ids) and code concepts (classifications). Within the context of HL7 interactions OIDs are quite often used.
An id points to a specific instance of an object or identification scheme (a particular methodology for the identification of a class of objects), for example a specific person as the patient or a physician, a specific lab observation or an X-ray photo.

In contrast to instance identifiers, a classification identifies a specific concept. The type of patient (inpatient, outpatient), the type of doctor (an anesthesiologist), the codes for gender or a lab observation (blood cell count) may serve as examples.

OIDs (object identifiers) are worldwide unique identifiers for objects. They are used in HL7 to specify identifications and classifications. An object in this sense is persistent, well-defined information, definitions or specifications and is represented with ids or codes.

Commonly used OIDs (i.e. used for a purpose that is wider in scope than the regional healthcare organization; used in communications between healthcare regions) can be found in OIDs registries such as

* [http://www.oid-info.com www.oid-info.com],
* [http://www.hl7.org www.hl7.org],
* [http://www.hl7.org.uk/version3group/oids.asp HL7 OID registry in the UK],
* [https://www.dimdi.de/dynamic/de/klassifikationen/weitere-klassifikationen-und-standards/oid/ OID registry Germany].

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|All OIDs with an element of 999 or 9999 are for documentation purposes only. They will be replaced by permanent OIDs once these have been as-signed/found/applied for.
|}

OID (Object Identifiers) are unique identifiers for any kind of objects. They are defined in Rec. ITU-T X.660 | ISO/IEC 9834-1. This identification system for objects and concepts makes reliable electronic information exchange possible. Administration and Registration is regulated by a set of rules, described in the corresponding chapter of this document.

Every artefact in ART-DECOR has an Object Identifier (OID). There are recommendations for the management and the exchange of Object Identifiers, partially defined in ISO TS 13582 <ref>ISO TS 13582: https://www.iso.org/standard/69652.html</ref>.

''HL7 International'' has created a type ontology for the OIDs in the HL7 registry to make it easier for the user community to search for OIDs they may be looking for and can be found at hl7.org.

From a policy perspective it is common practice in several healthcare related OID registries (HL7 International at http://www.hl7.org, OID Registry Germany at http://www.dimdi.de, OID registry Switzerland at http://oid.refdata.ch, and OID registry Austria at https://www.gesundheit.gv.at/OID_Frontend) to distinguish at least between the following types of OIDs:

{| class="hl7table" style="width:60%"
|+<ref group="Table">Recommended OID sub-branches for different artefacts</ref> ''Recommended OID sub-branches for different artefacts''
! Arc !! Description
|-
| .3 || organizational bodies and groups
|-
| .4 || identifier systems and namespaces
|-
| .5 || code systems
|-
| .7 || document artefacts
|-
| .9 || conformance profiles
|-
| .10 || templates
|-
| .11 || value sets
|-
| .19 || examples
|-
| .99 || experimental
|}

''Example: given that “your” root OID is 1.2.3.4.5, the first value set of your governance group is then to be 1.2.3.4.5.11.1, with .11 as the value set “branch” and the last .1 as the first artefact of that kind.''

In ART-DECOR a project typically is set into the .77 branch of a governance group. When setting up the project, the OID for that project also determines the artefact OIDs using throughout the ART-DECOR project. The following additional branches are used to distinguish between different OID types:

{| class="hl7table"
|+<ref group="Table">Recommended OID sub-branches for ART-DECOR projects</ref> ''Recommended OID sub-branches for different artefacts''
! Artefact code Description !! Recommended !! OID suffix
|-
| DS || dataset || .77.1
|-
| DE || dataset concept || .77.2
|-
| SC || scenario || .77.3
|-
| TR || transaction in scenario || .77.4
|-
| CS || code system || .77.5
|-
| IS || issue || .77.6
|-
| AC || actor in scenario || .77.7
|-
| CL || concept list in dataset || .77.8
|-
| EL || element in template || .77.9
|-
| TM || template || .77.10
|-
| VS || value set || .77.11
|-
| RL || rule for instances || .77.12
|-
| SX || test/example scenario || .77.18
|-
| EX || test/example instance || .77.19
|-
| QX || qualification test/example || .77.20
|-
| TX || test/example data element || .77.21
|-
| CM || community || .77.22
|-
| MP || concept map || .77.24
|}

In ART-DECOR a newly created project uses these OID branches automatically.

=== Instance identification ===

Instance identification is done with the id element of a class. Its type is II (instance identifier) and described in the data type section above. For example, a patient number can be represented as
* 2.16.578.1.34.1.5432.1, the root-OID of the issuing authority, for example a system/application in a hospital, and
* 67543242 as the ''@extension'', representing the patient number within the system defined by the ''@root'' attribute.

=== Coding scheme identification ===

Coding schemes have to be uniquely identified using OIDs as well. All coding tables used in this implementation guide show the corresponding OID that has to be specified in the ''@codeSystem'' attribute of coded elements. Both attributes ''@code'' and ''@codeSystem'' together allows a correct interpretation of concept and code.

=== List of identification schemes ===

The following are OIDs for commonly used identification schemes.

{| class="hl7table"
|+<ref group="Table">Commonly used identification scheme OIDs</ref> ''Commonly used identification scheme OIDs''
! OID !! Identification System Name !! Description !! Issuer
|-
| 1.2.276.0.76.4.8 || KV-Nummer || Krankenversichertennummer ||
|-
| 1.2.276.0.76.4.17 || BSNR || Betriebsstättennummer ||
|-
| 1.2.276.0.76.4.16 || LANR || lebenslange Arztnummer ||
|}

=== List of code systems ===

The following are OIDs for code systems.

{| class="hl7table"
|+<ref group="Table">Commonly used code system OIDs</ref> ''Commonly used code system OIDs''
! OID !! Code System Name !! Description !! Issuer
|-
| 2.16.840.1.113883.6.1 || LOINC || Logical Observation Identifiers Names and Codes (LOINC) || Regenstrief Institute
|-
| 2.16.840.1.113883.6.96 || SNOMED CT || Systemized Nomenclature in Medicine Reference Terminology (SNOMED CT) || SNOMED International
|-
| 1.0.3166.1.2 || ISO 3166-1 (second edition) || Country codes as per ISO 3166-1:2007 || ISO
|}

== Vocabulary ==

=== Code Systems ===

Within HL7, a ''Code System'' is defined as a collection of codes with associated designations and meanings. Examples of code systems include ICD-10, SNOMED CT, and LOINC.
To meet the requirements of a code system as defined by HL7, a given code must resolve to one and only one meaning within the code system. Given this definition, each code table in the HL7 Version 3 standard represents a different code system since codes are sometimes used in different tables to have different meanings.
For example, “M” in the administrative gender table (''AdministrativeGender'', OID 2.16.840.1.113883.5.1) means “male”, while “M” in the marital status table (''MaritalStatus'', OID 2.16.840.1.113883.5.2) means “married”.
In this specification, code system tables are not presented in detail.

=== Value Sets ===

A ''Value Set'' represents a uniquely identifiable set of valid concept representations, where any concept representation can be tested to determine whether or not it is a member of the value set.
Value set complexity may range from a simple flat list of concept codes drawn from a single code system, to an unbounded hierarchical set of possibly post-coordinated expressions drawn from multiple code systems.
Value sets exist to constrain the content for a coded element in an HL7 static model or data type property. Value sets cannot have null content and must contain at least one concept representation where any given concept is generally (but not required to be) represented by only a single code within the Value Set.

[[File:CDA_Core_Principles_Figure_3_ValueSet_Example.png|800px]]

<ref group="Figure">Example presentation of the value set “MaritalStatus”</ref> ''Example presentation of the value set “MaritalStatus”''

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that value set OIDs never appear in a CDA Release 2 document. They are used for constraint expressions, for example in implementation guides.
In order to send a specific code drawn from a value set, the corresponding code system has to be conveyed.
An example, in the implementation specification the constraint on the model element ''maritalStatusCode'' is expressed as “to be drawn from value set 2.16.840.1.113883.5.2 ''MaritalStatus''”.
To actually send a marital status of “M” (married) that is shown in the value set figure above, the corresponding HL7 CDA instance would say:
<syntaxhighlight lang="xml">
<maritalStatusCode code="M" codeSystem="2.16.840.1.113883.5.2"/>
</syntaxhighlight>
|}

In this specification, value set tables are not presented in detail.

==== Binding strength ====

There is an optional vocabulary strength for data types that support that feature (coded concepts). Examples include CD, CE, CV and CO. Values are required, extensible, preferred and example. Default is required.

Please note: the formerly supported values CNE (Coded No Extensibility) and CWE (Coded With Extensibility) in ART-DECOR are deprecated as of December 2017. Specification CNE is handled as required and CWE is handled as extensible.

{| class="hl7table"
|+<ref group="Table">Binding Strengths</ref> ''Binding Strengths''
! Strength !! Description
|-
|required||Required/CNE. Coded with no exceptions; this element SHALL be from the specified value set
|-
|extensible||Extensible/CWE. Coded with Exceptions; this element SHALL be from the specified value set if any of the codes within the value set can apply to the concept being communicated. If the value set does not cover the concept (based on human review), alternate codings (or, data type allowing, text) may be included instead.
|-
|preferred||Preferred. Instances are encouraged to draw from the specified codes for interoperability purposes but are not required to do so to be considered conformant.
|-
|example||Example. Instances are not expected or even encouraged to draw from the specified value set. The value set merely provides examples of the types of concepts intended to be included.
|}

Mismatches with required lead to validation errors (SHALL logic). Mismatches with extensible lead to validation warnings (SHOULD logic). Mismatches with preferred lead to validation information messages (MAY logic). Mismatches with example don't have any validation consequences.

== Appendix ==

=== References ===

<references/>

=== List of figures ===

<references group="Figure" />

=== List of tables ===

<references group="Table" />

HL7 CDA Core Principles

2019-06-16T11:08:42Z

Dammon: /* Instance Identifier (II) */

== Introduction ==

This implementation guide specifies the ''Core Principles'' of using the ''Clinical Document Architecture'' <ref>Clinical Document Architecture Release 2: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=7</ref>.

=== Scope ===

This guide focuses on ''Data Types Release 1'' <ref>HL7 Data Types Release 1: http://www.hl7.org</ref>. Meanwhile an ISO specification ISO 21090 is out, also known as Data Type Release 2. The latter is subject to another implementation guide that will be published when ISO data types are used.

=== Focus of this document: HL7 Version 3 Data Types for CDA ===

The following chapters of this document will focus on the description of the data types and associated material. It will highlight the essentials in four chapters, all focusing on the Norwegian situation.
* '''Common aspects:''' explains common aspects of use of CDA and XML
* '''Data types:''' gives an overview and detailed specification of all data types used in CDA
* '''Identification schemes:''' explains major aspects of identification and the use in CDA
* '''Use of vocabulary:''' explains major aspects of vocabulary use in CDA.

=== Background ===

In many (European) countries, implementation guides for the use of data types in HL7 V3 are published. They take into account country specific constraints on the data types.

=== Legend of symbols ===

In this document several symbols are used.

{| class="hl7table" style="width:50%"
| [[File:Pfeil_rechts.png|50px]] || This is an important item
|-
| [[File:Issue.svg|50px]] || This is a known open issue
|-
| [[File:Faq.svg|50px]] || This is a frequently asked question (FAQ) with answer
|-
| [[File:Conformance.svg|50px]] || This is a constraint; in some situations also the rule identification is specified, e.g. dtr1-1-ANY, which links to the corresponding validation rule.
|}

=== Version history ===

{| class="hl7table" style="width:50%"
|+
! Version !! Date !! Description !! Author
|-
| 1.1 || 2019-04-24 || Refurbished guide based on earlier work || Kai U. Heitmann
|}

== Common aspects ==

=== Use of XML ===

HL7 Version 3 CDA uses the Extensible Markup Language (XML) as the exchange format. It is assumed that the reader is familiar with common XML aspects. However, some constraints are made regarding the use of CDA.

==== Character Set ====

{{ConstraintBox|
The character encoding of any CDA document shall be “UTF-8”.}}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="utf-8"?>
</syntaxhighlight>

=== CDA document structure ===

The XML namespace for CDA Release 2 documents is ''<nowiki>urn:hl7-org:v3</nowiki>''. This must be correctly mentioned in every XML instance.

CDA XML documents starts with the root element ''ClinicalDocument''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">


...

<component>
<structuredBody>
...
</structuredBody>
</component>

</ClinicalDocument>
</syntaxhighlight>

== Data types ==

=== Introduction ===

The following chapter describes the typical data types used in CDA implementation guides. For further information please refer to the HL7 V3 standard and its two parts concerning data types:
* Abstract Data type definition <ref>HL7 Version 3 Abstract Data type definition: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=264</ref>
* XML ITS for data types <ref>XML ITS for data types: https://www.hl7.org/documentcenter/public_temp_682D4D16-1C23-BA17-0C789BA52BEDB68E/wg/inm/datatypes-its-xml20050714.htm</ref>
Data types are properties of model class attributes and the basic building blocks of information in a CDA XML instance. For example, a model attribute named “time” has as its data type a time stamp “TS” (see Figure 1).

[[File:CDA_Core_Principles_Figure_1_CDA_Structure_Data_Types.png|700px]]

<ref group="Figure">CDA structure (left) and the data type specification (right)</ref> ''CDA structure (left) and the data type specification (right)''

=== XML representation of data types ===

Actual data is mostly carried in HL7 Version 3 by populating XML attributes and not as element content. Exceptions are names of persons and organizations as well as addresses.

The XML elements have names like the model attributes. For example, a model attribute “id” has a corresponding XML element named <id…>. The model determines the sequence of elements and their hierarchy. The data type itself determines the XML attributes within the start tag. The notation here is as follows:

{| class="hl7table"
|+
! Attribute !! DT !! Conf !! Description
|-
| (name of the model attribute or XML element) || Data type || Conformance, i.e. O, R, M || Textual description
|}

XML attributes (data type properties) are denoted as ''@attribute'' in order to distinguish their names from XML elements.

Example: in the example model above, the data type of the ''id'' attribute's is ''II'' (Instance Identifier). The corresponding XML attributes for that data type include ''@root'' and ''@extension''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id root="..." extension="..." />
</syntaxhighlight>

A description of the data types and their corresponding XML representation is contained in subsequent paragraphs of this guide.

==== Exceptions using XML element content ====

For most data types, the actual data is conveyed in XML attributes. However, there are some exceptions. For the data types binary (BIN), Encapsulated Data (ED), Entity Name (EN), Person Name (PN), Organization Name (ON), Trivial Name (TN), Address (AD) and character string data (ST), information is carried as element content.

Example: the components of an address <addr> are represented by sub elements with the data as element content (in the example shown in black).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr>
<streetAddressLine>Thormøhlens gate 12</streetAddressLine>
<postalCode>5006</postalCode>
<city>Bergen</city>
</addr>
</syntaxhighlight>

==== Combined data types ====

There are a number of so-called combined data types. For example, an interval with a lower and upper limit and a ratio that has a nominator and a denominator value.

In combined data types the substructure (e.g. <low> <high> in an interval) are represented as child elements of the relevant data type element.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110701"/>
<high value="20110729"/>
</effectiveTime>
</syntaxhighlight>

==== Conformance information ====

The conformance indicators distinguish kinds of conformance information described shortly here.

* '''O''': An optional item may be omitted if no data is present, i.e. no corresponding XML attribute or element is sent (marked as “O”)
* '''R''': For required items, lower cardinality is always zero or 1.
** Elements must be present and populated with data if present in the sending system. If no data is available (yet), a null flavor (see below) indicates and possibly classifies the missing information (marked as R).
** Attribute flagged as required must be present in the instance and populated.
* '''M''': For mandatory elements data must be sent and no missing values are allowed, i.e. if the sending system does not have information for mandatory elements the XML instance cannot be created and sent (marked as M).
* '''NP''': no data may be present at all (not permitted)
* '''C''': conditional conformance; typically a conformance table shows the circumstances (conditions) derived from information in the instance and the corresponding cardinalities and conformance statements.

=== Missing values (null flavor) ===

For every data type it is possible to specify a missing value including a kind of reason why data is missing. Instead of specifying any attribute of the corresponding element, a ''@nullFlavor'' attribute expresses the omission of data. Note that missing data is not allowed for mandatory elements (see above).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value nullFlavor="OTH"/>

<code nullFlavor="UNK"/>

<booleanInd nullFlavor="NI"/>

</syntaxhighlight>

The codes for the ''@nullFlavor'' attribute are drawn from the following hierarchical code system. It is a Coded Simple (CS), which means it has no code system (attribute ''@codeSystem'') specified.

{| class="hl7table"
|+<ref group="Table">NullFlavor</ref> ''NullFlavor''
! Code
! width=15% | Print Name
! Definition / Description
|-
| NI || No Information || No information whatsoever can be inferred from this exceptional value. This is the most general exceptional value. It is also the default exceptional value.
|-
|   OTH || other || The actual value is not an element in the value domain of a variable. (e.g., concept not provided by required code system).
|-
|     NINF || negative infinity || Negative infinity of numbers.
|-
|     PINF || positive infinity || Positive infinity of numbers.
|-
|   UNK || unknown || A proper value is applicable, but not known.
|-
|     ASKU || asked but unknown || Information was sought but not found (e.g., patient was asked but didn't know)
|-
|       NAV || temporarily unavailable || Information is not available at this time but it is expected that it will be available later.
|-
|       NASK || not asked || This information has not been sought (e.g., patient was not asked)
|-
|       TRC || trace || The content is greater than zero, but too small to be quantified.
|-
|   MSK || masked || There is information on this item available but it has not been provided by the sender due to security, privacy or other reasons. There may be an alternate mechanism for gaining access to this information.
Note: using this null flavour does provide information that may be a breach of confidentiality, even though no detail data is provided. Its primary purpose is for those circumstances where it is necessary to inform the receiver that the information does exist without providing any detail.
|-
|   NA || not applicable || No proper value is applicable in this context (e.g., last menstrual period for a male).
|-
| NP || not present || Value is not present in a message. This is only defined in messages, never in application data! All values not present in the message must be replaced by the applicable default, or no-information (NI) as the default of all defaults.
|}

=== ANY as the generic data type ===

This abstract data type is the basis for all other data types. Not a single value within a CDA document has the effective data type ANY, but any data type within HL7v3 is a specialization of ANY. This also means that any other data type inherits all properties of ANY (see [[#Missing_values_.28null_flavor.29|“Missing values (null flavor)”]]).

The ANY type is occasionally found in HL7 models when it comes to clinical finding etc. where – at model time – the actual data type of the value is not known. At instantiation time however, the actual data type ''is'' known and ANY is always replaced by a particular data type in an instance.

One example is the observation value (child element value in an observation), where in the model the data type of value cannot be anticipated. When instantiation is taking place, the data type is specified by the XML instance attribute ''@xsi:type''. This information can be used by the receiver to validate and process the value.

Attributes of an element with this data type are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@nullFlavor''' || <center>CS</center> || <center>–</center> || Classification of the missing value, see [[#Missing_values_.28null_flavor.29|3.3 Missing values (null flavor)]].
|}

{| class="hl7table" style="width:100%"
| width=8% | <center>[[File:Conformance.svg|50px]] dtr1-1-ANY</center> || If there is a ''nullFlavor'', there shall be no other attribute or element, unless it's ''nullFlavor="OTH"''.

In that case ''@codeSystem'' or ''originalText'' (see “code” data types) may have a value.
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">

<value xsi:type="CE" code="N11.9" codeSystem="2.16.840.1.113883.6.3"/>


<value xsi:type="PQ" value="12" unit="mL"/>


<value xsi:type="ED">this is text</value>
</syntaxhighlight>

=== Boolean (BL) ===

Elements of this data type refer to Boolean logic and have an attribute ''@value''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>BL</center> || <center>–</center> || Valued as “true” or “false”
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<negationInd value="false"/>

<deceasedInd value="true"/>

</syntaxhighlight>

In some situations, the BL data does not apply to an XML element, but an attribute. In that case, the attribute carries the Boolean value directly.
<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<support contextConductionInd ="false">
...
</support>
</syntaxhighlight>

=== Instance Identifier (II) ===

This data type identifies instances of classes like observations or entities (persons, organizations). Attributes are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@extension''' || <center>ST</center> || <center>O</center> || Identification
|-
| '''@root''' || <center>OID</center> || <center>R</center> || Source of identification
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id extension="13234453645" root="2.16.840.1.113883.2.6.15.3.427.1"/>
</syntaxhighlight>

The ''@root'' attribute is of type OID (object identifier), a unique identifier of the issuing authority or system. For example, a patient with a patient number 13234453645 created by a specific healthcare provider organization is uniquely identified by the number itself in ''@extension'' and the OID of the organization or the sending system, in the example 2.16.840.1.113883.2.6.15.3.427.1 in ''@root''.

In some cases, a single OID identifies an object uniquely. In that situation, only ''@root'' is populated and ''@extension'' is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Encapsulated Data (ED) ===

Elements of this data type carry multimedia content. The actual multimedia content is represented as element content. There are two situations for the use of ED:

* Inline: The full data is transmitted in the type. This form is mainly used for text.
* By reference: a thumbnail is provided which links to the full data by reference.

In an instance, the data type is normally determined by an ''xsi:type'' specification and some attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@mediaType''' || <center>CS</center> || <center>O</center> || MIME media type classification. At time of writing this specification, the following MIME types are allowed:
* text/plain (plain text)
* text/html (text with html markup)
* image/jpeg (JPEG image)
* application/pdf (a PDF, portable document format)
* application/hl7-sda+xml (CDA documents).
|-
| '''@representation''' || <center>CS</center> || <center>O</center> || Representation of the multimedia content. At time of writing this specification, the following representations are allowed:
* TXT (text, this is the default)
* B64 base 64 encoded data, for example for embedded CDA documents).
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<text xsi:type="ED" mediaType="text/plain">
Patient treated sucessfully
</text>

<text mediaType="application/hl7-sda+xml" representation="B64">PD94bWw..etc..==</text>

</syntaxhighlight>

To include referenced data the two sub elements ''thumbnail'' and ''reference'' are used.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''reference''' || <center>TEL</center> || <center>0..*</center> || <center>O</center> || Link (URI) to full data
|-
| '''thumbnail''' || <center>ED</center> || <center>0..*</center> || <center>O</center> || Thumbnail of referenced data
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value xsi:type="ED" mediaType="image/png" representation="B64">
<reference value="http://radiology.bergen.no/xrays/128s.png"/>
<thumbnail mediaType="image/jpeg" representation="B64"> MNY...83== </thumbnail>
</value>
</syntaxhighlight>

=== Strings (ST) ===

This data type is a specialization of the ED type where ''@mediaType'' is fixed “text/plain” and ''@representation'' is fixed “TXT”. It allows conveying a character string as '''element content'''. This data type is used in other data types it like the ''@extension'' in instance identifiers, or address and person name data type components.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<lotNumber> 143GT6DT </lotNumber>
</syntaxhighlight>

=== Concept Descriptor (CD) ===

This data type specifies a concept by means of a code and its code system (except for situations where no code is available). A couple of specializations of data type CD exist, which differ in the main characteristics (properties) of the data type that may or may not be supported.

{| class="hl7table" style="width:50%"
|+<ref group="Table">Properties of data types used for codes</ref> ''Properties of data types used for codes''
! <div style="text-align: right">DataType</div> !! CD !! CE !! CV !! CO !! CS
|-
! <div style="text-align: left">Property</div> !! !! !! !! !!
|-
| '''@code''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||<center>X</center>
|-
| '''@codeSystem''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''@codeSystemVersion''' || <center>X</center> || <center>X</center> || <center>X</center>|| <center>X</center> ||
|-
| '''@displayName''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''originalText''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''translation''' || <center>X</center> || <center>X</center> || || ||
|-
| '''qualifier''' || <center>X</center> || || || ||
|}

Because the CE variant is most used in practice, the general explanation of the properties will be given with de description of CE (see below).

The only attribute that is unique to CD is briefly explained here.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@qualifier''' || <center>CR</center> || <center>O</center> || An additional qualifier for the code.
|}

Complex terminologies like SNOMED CT can be used only using data type CD.

=== Coded with Equivalents (CE) ===

With elements of this data type, a concept by means of a code and its coding system (except for situations where no code is available) can be specified. It optionally contains one or more equivalents using other code systems.
It may contain the following attributes:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@code''' || <center>ST</center> || <center>R</center> || The actual code
|-
| '''@codeSystem''' || <center>OID</center> || <center>R</center> || required to identify the code system were the code is drawn from. This is an OID (object identifier, see [[#Object_Identifiers_.28OIDs.29|Object Identifiers at 4.1]])
|-
| '''@displayName''' || <center>ST</center> || <center>O</center> || Optional textual representation of code. A display name may be specified representing the plain text of the code. The information of this attribute may not be used by the receiving system for interpretation, but only for display purposes. The display name may never be transmitted without a code and must have the same meaning as the code.
|-
| '''@codeSystemName''' || <center>ST</center> || <center>O</center> || A textual representation of the name of the code system
|-
| '''@codeSystemVersion''' || <center>ST</center> || <center>O</center> || A textual representation of the version of the code system
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"/>

<code code="AU" codeSystem="2.16.840.1.113883.5.33"/>

<storageCode code="AC" codeSystem="2.16.840.1.113883.5.34" displayName="active"/>

<code code="A45.0" displayName="Somatisierungsstörung" codeSystem="1.2.276.0.76.5.409" codeSystemName="ICD-10 GM 2012"/>
</syntaxhighlight>

There are some child elements of codes that can be used to express what the “original text” was that was used for the coding or to indicate that there are “translations” to other code systems than the primary code.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''originalText''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Textual representation of the concept, actually a description which was used to create the actual code
|}

No semantics may be assumed other than showing the ''@displayName'' to a user to clarify the code. A display name cannot occur without its code and must carry the same meaning.

In case no code is known, it is allowed to specify a ''@nullFlavor'' for the code element and to give information about the (not yet coded) concept in original text. However, this should be an exception.

If other codes than the primary code need to be conveyed adding a translation child element can be used.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<originalText>minor aphthous stomatitis</originalText>
</code>
</syntaxhighlight>

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''translation''' || <center>CD</center> || <center>0..*</center> || <center>O</center> || Alternative code(s)
|}

A ''translation'' element is also of type CD and shall have a code and a code system identified. It shall point to the same concept as the primary code. It is allowed that a translation conveys less conceptual details than the original code.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<translation code="528.2" codeSystem="2.16.840.1.113883.6.2" codeSystemName="ICD9" displayName="Oral aphthae"/>
</code>
</syntaxhighlight>

=== Coded Value (CV) ===

This is actually a specialization of CE (see above), with the exception that neither ''originalText'' nor ''translation'' child element are allowed.

=== Coded Simple Value (CS) ===

This is actually a specialization of CE (see above), with no code system attribute and no original text or translation child element allowed. It specifies a concept by means of a code from a ''predefined'' code system (table) where the code is drawn from. This data type is usually applied in the context of fixed predefined HL7 tables.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<statusCode code="completed"/>
</syntaxhighlight>

In this example ''statusCode'' is bound in the underlying model to the specific code system ''ActStatus''. Because it is predefined by means of the vocabulary binding, ''@codeSystem'' is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Telecommunication Address (TEL) ===

Elements of this type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>ST</center> || <center>R</center> || carries strings that represent telecommunication contact information
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

The actual data is preceded by the scheme (refer to Internet Standard “RFC 1738 Uniform Resource Locators (URL)” <ref>RFC 1738 Uniform Resource Locators (URL): http://www.ietf.org/rfc/rfc1738.txt</ref>.

Examples:
* telephone (tel:),
* fax (fax:),
* email (mailto:).

It must follow the rules defined in Internet “RFC 2806 URLs for Telephone Calls” <ref>RFC 2806 URLs for Telephone Calls: http://www.ietf.org/rfc/rfc2806.txt</ref>.

The following codes will be used in the “use” attribute:
* H – Home
* WP – Work
* MC can be used (in addition to H or WP) to denote that this is a mobile phone.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257" />

<telecom use="H" value="tel:55354257" />

<telecom use="H" value="fax:56542558" />

<telecom value="tel:+41.34.21.4765342"/>

<telecom value="mailto:opr@opr-sem.no"/>

<telecom use="WP MC" value="tel:97555786" />
</syntaxhighlight>

It is possible to express the useable period of a telecommunication contact. A child element ''useablePeriod'' is used as a time interval to indicate this period.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''useablePeriod''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257">
<useablePeriod>
<high value="20111201"/>
</useablePeriod>
</telecom>
</syntaxhighlight>

=== Postal Address (AD) ===

Elements of this data type have a substructure in order to represent a structured address specification. In this implementation guide only a selection of all possible child elements is allowed, the original HL7 specification is richer.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''streetAddressLine''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Street address, includes street name and house number
|-
| '''city''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || City
|-
| '''postalCode''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Postal code
|-
| '''country''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Country
|-
|}

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that the sequence of the sub elements is country specific, i.e. it has to follow “common” rules how to write an address. For example, an UK address and a German address have different sequences of address representation.
|}

A ''@use'' attribute can also be specified.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="WP">
<streetAddressLine>Anna-Louisa-Karsch-Str. 2</streetAddressLine>
<postalCode>10178</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="H WP">
<streetAddressLine>Tatungasse 34</streetAddressLine>
<postalCode>10825</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

Also, a country may be specified using the element ''country''.

=== Person Name (PN) ===

Elements of this data type do also have a substructure to represent the parts of a person name, like family or given name and prefixes.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>
<given>Franz</given>
<given>Ingrun</given>
<family>Nordmann</family>
</name>
</syntaxhighlight>

Previous or birth or maiden names are supported using the ''validTime'' element. ''validTime'' (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]]) specifies the validity range of the name.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">

<name>
<given>Jan</given>
<given>Olaf</given>
<family>Hendrikson</family>
<validTime>
<high value="20000101"/>
</validTime>
</name>
</syntaxhighlight>

Note that the name attribute is repeating, i.e. multiple (types of) names could be sent. It is up to the receiver (based on the value of the ''@use'' attribute, and ''validTime'') to decide what name it wants to use or import in its database.

=== Organisation Name (ON) ===

Elements of this data type represent a name of an organization.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name> Charité Berlin </name>
</syntaxhighlight>

The optional ''validTime'' element (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]] may be used to specify the validity range of the name of the organization.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name of the organization
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>The old hospital
<validTime>
<high value="20111231235959"/>
</validTime>
</name>
</syntaxhighlight>

Please note that the use of ''validTime'' yields XML mixed content which should be avoid-ed if possible.

=== Integer Number (INT) ===

Elements of this data type are used to specify integer numbers and have one attribute.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>int</center> || <center>R</center> || Integer value
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<sequenceNumber value="24"/>
</syntaxhighlight>

=== Physical Quantities (PQ) ===

Elements of this data type are physical quantities, i.e. a measurable quantity (or countable) value from the physical world. This is different from just a “number”, because there is a (natural) unit specified in which the measurable quantity is expressed.
Examples:
* an amount of blood 20 ml (sample volume)
* a cut with a length of 10 cm (result observation)
* a dose of 200 milligrams per administration (dosing)
* delivery of 60 pieces of a tablet (amount supplied).
Elements of this data type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>real</center> || <center>R</center> || value of the measurement
|-
| '''@unit''' || <center>CS</center> || <center>R</center> || unit of measurement
|}

In the unit of measurement unit is expressed following the ''Unified Code for Units of Measure'' (UCUM) specification. This specification is a collection of atomic units, prefixes and a corresponding grammar for valid combinations to build all-natural units of measurement. For a complete description of possible units, see the ''Unified Code for Units of Measure'' <ref>Unified Code for Units of Measure: http://unitsofmeasure.org/</ref> specification.
If a value is not countable or if measurable, for example expressed in milligrams or liters, then this unit is a valid UCUM unit like “mg” or “L”. If a value is countable, for example the number of tablets, then this attribute contains “1”.
In HL7 it is required that all PQ data type units are valid UCUM units.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<value value="165" unit="cm"/>

<value value="81.1" unit="kg"/>

<value value="120" unit="mm[Hg]"/>

<value value="5" unit="1"/>
</syntaxhighlight>

=== Point in Time (TS) ===

Elements of this data type have the attribute

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>TS</center> || <center>R</center> || Point in time
|}

and specify points in time in the format YYYYMMDDhhmmss±ZZZZ, where
* YYYY is the four-digit year,
* MM the two-digit month,
* DD the two-digit day,
* hh the two-digit hour,
* mm the two-digits minute and
* ss the two-digit second.
Optional a time zone ZZZZ, the four-digit time alignment with a preceding “-” or a “+” can be specified. If time zone is omitted, local time is assumed.
The point in time may be right truncated in respect to the precision of the information.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<effectiveTime value="20140412"/>

<effectiveTime value="201409091245"/>

<effectiveTime value="1996"/>

<birthTime value="19540714"/>

<effectiveTime value="20140412+0100"/>
</syntaxhighlight>

=== Intervals (IVL) ===

Intervals are defined only for data types with an ordinal or interval scale type. There are several possibilities to determine an interval (see Figure 2), for example to specify

* a lower <low> and an upper boundary <high> (a),
* a lower <low> boundary and width <width> (b)
* an upper boundary and width <width> (c) or
* the middle of the interval <nowiki><center></nowiki> and a width <width> (d).

[[File:CDA_Core_Principles_Figure_2_Determining_Intervals.png|700px]]

<ref group="Figure">Several possibilities to determine closed intervals</ref> ''Several possibilities to determine closed intervals''

{{ConstraintBox|
To indicate an interval, only the following combinations are permitted.
(1) A lower and an upper boundary may not be identical, and their accuracy has to be equal.

Correct examples:

{{BeginGreenBox|}}
Interval from 5 to 6
Interval from 20110607 until 20110612
{{EndGreenBox}}

Incorrect examples:

{{BeginRedBox|}}
Interval from 5 to 6.0
Interval from 20110101 to 2011
{{EndRedBox|}}

(2) A lower boundary and a width

(3) A lower limit boundary

(4) A upper limit boundary

(5) Only the middle of the interval

(6) Only the width of an interval}}

Accordingly, four child elements are available.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Lower boundary
|-
| '''high''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Upper boundary
|-
| '''center''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Where ''(T)'' is defined in this specification as one of the data types “TS” or “PQ”.

=== Interval of time (IVL_TS) ===

Elements of this data type represent time intervals. There are four possible child elements.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Lower boundary (start date/time)
|-
| '''high''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Upper boundary (end date/time)
|-
| '''center''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Normally, a lower and an upper boundary is given, both are points in time. Also, it is possible to specify open intervals like “since June 14, 1999” (left boundary given only) or “until September 24, 2006” (right boundary given).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110507"/>
<high value="20110909"/>
</effectiveTime>

<effectiveTime>
<low value="20110507"/>
</effectiveTime>

<value>
<low value="20110101"/>
<width value="120" unit="d"/>
</value>

<value>
<center value="20110101"/>
</value>
</syntaxhighlight>

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|It must be noted that intervals of time stamps in HL7 are equally treated as other interval types (e.g. integers). The statement, one may take 1–3 tablets (interval of integers), for example, says that you are allowed to take no more than three tablets, not 3½ or 3.5 tablets. On the other hand, when treat the words “until 12 June 2011” regarding the upper interval limit differently, particularly we assume that the entire day 12 June is still in-cluded in this time interval.
Thus, in human perception time intervals are handled differently com-pared to such as number intervals. This is a situation may lead to inconsist-encies in standardized communication. As a conclusion, an upper limit “12 June 2011” means that only the very first moment of the 12 June is included in the interval, but not, for example, the 12 June 13:00 hours.
Interpretation does not depend on the accuracy of the time:
* “after 2004” means “from January 1, 2005 00:00:00.000”,
* “after 20041201” means “from 2 December 2004 00:00:00.000 hours”,
* and “after 200412011200” means “from 1 December 2004 12:01:00.000”.

As a result, you have to carefully consider the specification and implemen-tation of time intervals upper boundaries. In order to prevent mis-understandings intervals are always specified with the date and time for an upper limit that would cover the whole day. Accordingly, “201106122359” means 12 June 2011 throughout the day.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="201106122359"/>
</effectiveTime>
</syntaxhighlight>

Because of the equal treatment of time intervals this is applied also to the lower limit boundaries of time intervals as “0000”. This means for example that “since 9 June 2011” is expressed as “201106090000”.
|}

The <width> element is of data type PQ (physical quantity). The value obviously shall relate to a period of time and it is required to include a “time” unit. These are the units “us” (microseconds), “ms” (milliseconds), “s” (seconds), “min” (minute), “h” (hours), “d” (day), “wk” (week), “mo” (month) and “a” (year).

{{ConstraintBox|
For interval of time stamps the @unit of a ''low'' or ''high'' child element shall use units
* us (microseconds),
* ms (milliseconds),
* s (seconds),
* min (minute),
* h (hours),
* d (day),
* wk (week),
* mo (month) or
* a (year).
}}

=== Interval of physical quantities (IVL_PQ) ===

Elements of this data type are used to indicate intervals of physical quantities (see also [[#Physical Quantities (PQ)|3.18 Physical Quantities (PQ)]]). In general, an upper and a lower boundary is specified. It is also possible to use ''center'' instead of ''low'' and ''high''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low || <center>TS</center> || <center>0..1</center> || <center>C</center> || the lower limit of the interval (i.e. the minimum amount).
|-
| '''high || <center>TS</center> || <center>0..1</center> || <center>C</center> || the upper limit of the interval (i.e. the maximum amount).
|-
| '''center || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of the interval
|}

The ''center'' child element is used when there is no interval, but an exact value. Alternative would be to demote IVL_PQ to data type PQ and populate the element’s ''@value'' attribute, but this is more difficult to process in XML. That is why the use of the ''center'' child element is deprecated.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<referenceRange>
<low value="7.5" unit="mmol/l"/>
<high value="10" unit="mmol/l"/>
</referenceRange>

<doseQuantity>
<center value="9" unit="1"/>
</doseQuantity>
</syntaxhighlight>

=== Ratio of quantities (RTO_QTY_QTY) ===

Elements of this data type specify ratios and have two child elements, a numerator and a denominator. The underlying QTY (Quantity) data type is an abstract data type and in a XML instance it has to be replaced by a specific data type using the ''@xsi:type'' instruction (see below).

In this specification only “PQ” or “INT” are allowed for the demotion of both ''numerator'' and ''denominator''. The relevant child elements are:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''numerator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the numerator of the ratio
|-
| '''denominator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the denominator of the ratio
|}

If a model attribute already is a RTO_QTY_QTY, you need to specify (demote) the OTY abstract data type for both ''numerator'' and ''denominator'' by using an ''@xsi:type'' instruction.
In some cases where the model attribute is of type “ANY”, also the root element shall carry an ''@xsi:type'' RTO_QTY_QTY instruction.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<maxDoseQuantity>
<numerator xsi:type="PQ" value="6"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="400" unit="mg"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="5"/>
<denominator xsi:type="PQ" value="1" unit="h"/>
</maxDoseQuantity>

<value xsi:type="RTO_QTY_QTY">
<numerator xsi:type="INT" value="1"/>
<denominator xsi:type="INT" value="10000"/>
</value>
</syntaxhighlight>

== Identification mechanisms ==

=== Object Identifiers (OIDs) ===

Standardized exchange of information using messages or documents also deals with unique identifications of objects and concepts, especially in environments where sender and receiver do not “know” each other necessarily.

It is important to understand the difference between identification of instances (ids) and code concepts (classifications). Within the context of HL7 interactions OIDs are quite often used.
An id points to a specific instance of an object or identification scheme (a particular methodology for the identification of a class of objects), for example a specific person as the patient or a physician, a specific lab observation or an X-ray photo.

In contrast to instance identifiers, a classification identifies a specific concept. The type of patient (inpatient, outpatient), the type of doctor (an anesthesiologist), the codes for gender or a lab observation (blood cell count) may serve as examples.

OIDs (object identifiers) are worldwide unique identifiers for objects. They are used in HL7 to specify identifications and classifications. An object in this sense is persistent, well-defined information, definitions or specifications and is represented with ids or codes.

Commonly used OIDs (i.e. used for a purpose that is wider in scope than the regional healthcare organization; used in communications between healthcare regions) can be found in OIDs registries such as

* [http://www.oid-info.com www.oid-info.com],
* [http://www.hl7.org www.hl7.org],
* [http://www.hl7.org.uk/version3group/oids.asp HL7 OID registry in the UK],
* [https://www.dimdi.de/dynamic/de/klassifikationen/weitere-klassifikationen-und-standards/oid/ OID registry Germany].

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|All OIDs with an element of 999 or 9999 are for documentation purposes only. They will be replaced by permanent OIDs once these have been as-signed/found/applied for.
|}

OID (Object Identifiers) are unique identifiers for any kind of objects. They are defined in Rec. ITU-T X.660 | ISO/IEC 9834-1. This identification system for objects and concepts makes reliable electronic information exchange possible. Administration and Registration is regulated by a set of rules, described in the corresponding chapter of this document.

Every artefact in ART-DECOR has an Object Identifier (OID). There are recommendations for the management and the exchange of Object Identifiers, partially defined in ISO TS 13582 <ref>ISO TS 13582: https://www.iso.org/standard/69652.html</ref>.

''HL7 International'' has created a type ontology for the OIDs in the HL7 registry to make it easier for the user community to search for OIDs they may be looking for and can be found at hl7.org.

From a policy perspective it is common practice in several healthcare related OID registries (HL7 International at http://www.hl7.org, OID Registry Germany at http://www.dimdi.de, OID registry Switzerland at http://oid.refdata.ch, and OID registry Austria at https://www.gesundheit.gv.at/OID_Frontend) to distinguish at least between the following types of OIDs:

{| class="hl7table" style="width:60%"
|+<ref group="Table">Recommended OID sub-branches for different artefacts</ref> ''Recommended OID sub-branches for different artefacts''
! Arc !! Description
|-
| .3 || organizational bodies and groups
|-
| .4 || identifier systems and namespaces
|-
| .5 || code systems
|-
| .7 || document artefacts
|-
| .9 || conformance profiles
|-
| .10 || templates
|-
| .11 || value sets
|-
| .19 || examples
|-
| .99 || experimental
|}

''Example: given that “your” root OID is 1.2.3.4.5, the first value set of your governance group is then to be 1.2.3.4.5.11.1, with .11 as the value set “branch” and the last .1 as the first artefact of that kind.''

In ART-DECOR a project typically is set into the .77 branch of a governance group. When setting up the project, the OID for that project also determines the artefact OIDs using throughout the ART-DECOR project. The following additional branches are used to distinguish between different OID types:

{| class="hl7table"
|+<ref group="Table">Recommended OID sub-branches for ART-DECOR projects</ref> ''Recommended OID sub-branches for different artefacts''
! Artefact code Description !! Recommended !! OID suffix
|-
| DS || dataset || .77.1
|-
| DE || dataset concept || .77.2
|-
| SC || scenario || .77.3
|-
| TR || transaction in scenario || .77.4
|-
| CS || code system || .77.5
|-
| IS || issue || .77.6
|-
| AC || actor in scenario || .77.7
|-
| CL || concept list in dataset || .77.8
|-
| EL || element in template || .77.9
|-
| TM || template || .77.10
|-
| VS || value set || .77.11
|-
| RL || rule for instances || .77.12
|-
| SX || test/example scenario || .77.18
|-
| EX || test/example instance || .77.19
|-
| QX || qualification test/example || .77.20
|-
| TX || test/example data element || .77.21
|-
| CM || community || .77.22
|-
| MP || concept map || .77.24
|}

In ART-DECOR a newly created project uses these OID branches automatically.

=== Instance identification ===

Instance identification is done with the id element of a class. Its type is II (instance identifier) and described in the data type section above. For example, a patient number can be represented as
* 2.16.578.1.34.1.5432.1, the root-OID of the issuing authority, for example a system/application in a hospital, and
* 67543242 as the ''@extension'', representing the patient number within the system defined by the ''@root'' attribute.

=== Coding scheme identification ===

Coding schemes have to be uniquely identified using OIDs as well. All coding tables used in this implementation guide show the corresponding OID that has to be specified in the ''@codeSystem'' attribute of coded elements. Both attributes ''@code'' and ''@codeSystem'' together allows a correct interpretation of concept and code.

=== List of identification schemes ===

The following are OIDs for commonly used identification schemes.

{| class="hl7table"
|+<ref group="Table">Commonly used identification scheme OIDs</ref> ''Commonly used identification scheme OIDs''
! OID !! Identification System Name !! Description !! Issuer
|-
| 1.2.276.0.76.4.8 || KV-Nummer || Krankenversichertennummer ||
|-
| 1.2.276.0.76.4.17 || BSNR || Betriebsstättennummer ||
|-
| 1.2.276.0.76.4.16 || LANR || lebenslange Arztnummer ||
|}

=== List of code systems ===

The following are OIDs for code systems.

{| class="hl7table"
|+<ref group="Table">Commonly used code system OIDs</ref> ''Commonly used code system OIDs''
! OID !! Code System Name !! Description !! Issuer
|-
| 2.16.840.1.113883.6.1 || LOINC || Logical Observation Identifiers Names and Codes (LOINC) || Regenstrief Institute
|-
| 2.16.840.1.113883.6.96 || SNOMED CT || Systemized Nomenclature in Medicine Reference Terminology (SNOMED CT) || SNOMED International
|-
| 1.0.3166.1.2 || ISO 3166-1 (second edition) || Country codes as per ISO 3166-1:2007 || ISO
|}

== Vocabulary ==

=== Code Systems ===

Within HL7, a ''Code System'' is defined as a collection of codes with associated designations and meanings. Examples of code systems include ICD-10, SNOMED CT, and LOINC.
To meet the requirements of a code system as defined by HL7, a given code must resolve to one and only one meaning within the code system. Given this definition, each code table in the HL7 Version 3 standard represents a different code system since codes are sometimes used in different tables to have different meanings.
For example, “M” in the administrative gender table (''AdministrativeGender'', OID 2.16.840.1.113883.5.1) means “male”, while “M” in the marital status table (''MaritalStatus'', OID 2.16.840.1.113883.5.2) means “married”.
In this specification, code system tables are not presented in detail.

=== Value Sets ===

A ''Value Set'' represents a uniquely identifiable set of valid concept representations, where any concept representation can be tested to determine whether or not it is a member of the value set.
Value set complexity may range from a simple flat list of concept codes drawn from a single code system, to an unbounded hierarchical set of possibly post-coordinated expressions drawn from multiple code systems.
Value sets exist to constrain the content for a coded element in an HL7 static model or data type property. Value sets cannot have null content and must contain at least one concept representation where any given concept is generally (but not required to be) represented by only a single code within the Value Set.

[[File:CDA_Core_Principles_Figure_3_ValueSet_Example.png|800px]]

<ref group="Figure">Example presentation of the value set “MaritalStatus”</ref> ''Example presentation of the value set “MaritalStatus”''

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that value set OIDs never appear in a CDA Release 2 document. They are used for constraint expressions, for example in implementation guides.
In order to send a specific code drawn from a value set, the corresponding code system has to be conveyed.
An example, in the implementation specification the constraint on the model element ''maritalStatusCode'' is expressed as “to be drawn from value set 2.16.840.1.113883.5.2 ''MaritalStatus''”.
To actually send a marital status of “M” (married) that is shown in the value set figure above, the corresponding HL7 CDA instance would say:
<syntaxhighlight lang="xml">
<maritalStatusCode code="M" codeSystem="2.16.840.1.113883.5.2"/>
</syntaxhighlight>
|}

In this specification, value set tables are not presented in detail.

==== Binding strength ====

There is an optional vocabulary strength for data types that support that feature (coded concepts). Examples include CD, CE, CV and CO. Values are required, extensible, preferred and example. Default is required.

Please note: the formerly supported values CNE (Coded No Extensibility) and CWE (Coded With Extensibility) in ART-DECOR are deprecated as of December 2017. Specification CNE is handled as required and CWE is handled as extensible.

{| class="hl7table"
|+<ref group="Table">Binding Strengths</ref> ''Binding Strengths''
! Strength !! Description
|-
|required||Required/CNE. Coded with no exceptions; this element SHALL be from the specified value set
|-
|extensible||Extensible/CWE. Coded with Exceptions; this element SHALL be from the specified value set if any of the codes within the value set can apply to the concept being communicated. If the value set does not cover the concept (based on human review), alternate codings (or, data type allowing, text) may be included instead.
|-
|preferred||Preferred. Instances are encouraged to draw from the specified codes for interoperability purposes but are not required to do so to be considered conformant.
|-
|example||Example. Instances are not expected or even encouraged to draw from the specified value set. The value set merely provides examples of the types of concepts intended to be included.
|}

Mismatches with required lead to validation errors (SHALL logic). Mismatches with extensible lead to validation warnings (SHOULD logic). Mismatches with preferred lead to validation information messages (MAY logic). Mismatches with example don't have any validation consequences.

== Appendix ==

=== References ===

<references/>

=== List of figures ===

<references group="Figure" />

=== List of tables ===

<references group="Table" />

HL7 CDA Core Principles

2019-06-16T11:07:35Z

Dammon: /* ANY as the generic data type */

== Introduction ==

This implementation guide specifies the ''Core Principles'' of using the ''Clinical Document Architecture'' <ref>Clinical Document Architecture Release 2: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=7</ref>.

=== Scope ===

This guide focuses on ''Data Types Release 1'' <ref>HL7 Data Types Release 1: http://www.hl7.org</ref>. Meanwhile an ISO specification ISO 21090 is out, also known as Data Type Release 2. The latter is subject to another implementation guide that will be published when ISO data types are used.

=== Focus of this document: HL7 Version 3 Data Types for CDA ===

The following chapters of this document will focus on the description of the data types and associated material. It will highlight the essentials in four chapters, all focusing on the Norwegian situation.
* '''Common aspects:''' explains common aspects of use of CDA and XML
* '''Data types:''' gives an overview and detailed specification of all data types used in CDA
* '''Identification schemes:''' explains major aspects of identification and the use in CDA
* '''Use of vocabulary:''' explains major aspects of vocabulary use in CDA.

=== Background ===

In many (European) countries, implementation guides for the use of data types in HL7 V3 are published. They take into account country specific constraints on the data types.

=== Legend of symbols ===

In this document several symbols are used.

{| class="hl7table" style="width:50%"
| [[File:Pfeil_rechts.png|50px]] || This is an important item
|-
| [[File:Issue.svg|50px]] || This is a known open issue
|-
| [[File:Faq.svg|50px]] || This is a frequently asked question (FAQ) with answer
|-
| [[File:Conformance.svg|50px]] || This is a constraint; in some situations also the rule identification is specified, e.g. dtr1-1-ANY, which links to the corresponding validation rule.
|}

=== Version history ===

{| class="hl7table" style="width:50%"
|+
! Version !! Date !! Description !! Author
|-
| 1.1 || 2019-04-24 || Refurbished guide based on earlier work || Kai U. Heitmann
|}

== Common aspects ==

=== Use of XML ===

HL7 Version 3 CDA uses the Extensible Markup Language (XML) as the exchange format. It is assumed that the reader is familiar with common XML aspects. However, some constraints are made regarding the use of CDA.

==== Character Set ====

{{ConstraintBox|
The character encoding of any CDA document shall be “UTF-8”.}}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="utf-8"?>
</syntaxhighlight>

=== CDA document structure ===

The XML namespace for CDA Release 2 documents is ''<nowiki>urn:hl7-org:v3</nowiki>''. This must be correctly mentioned in every XML instance.

CDA XML documents starts with the root element ''ClinicalDocument''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">


...

<component>
<structuredBody>
...
</structuredBody>
</component>

</ClinicalDocument>
</syntaxhighlight>

== Data types ==

=== Introduction ===

The following chapter describes the typical data types used in CDA implementation guides. For further information please refer to the HL7 V3 standard and its two parts concerning data types:
* Abstract Data type definition <ref>HL7 Version 3 Abstract Data type definition: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=264</ref>
* XML ITS for data types <ref>XML ITS for data types: https://www.hl7.org/documentcenter/public_temp_682D4D16-1C23-BA17-0C789BA52BEDB68E/wg/inm/datatypes-its-xml20050714.htm</ref>
Data types are properties of model class attributes and the basic building blocks of information in a CDA XML instance. For example, a model attribute named “time” has as its data type a time stamp “TS” (see Figure 1).

[[File:CDA_Core_Principles_Figure_1_CDA_Structure_Data_Types.png|700px]]

<ref group="Figure">CDA structure (left) and the data type specification (right)</ref> ''CDA structure (left) and the data type specification (right)''

=== XML representation of data types ===

Actual data is mostly carried in HL7 Version 3 by populating XML attributes and not as element content. Exceptions are names of persons and organizations as well as addresses.

The XML elements have names like the model attributes. For example, a model attribute “id” has a corresponding XML element named <id…>. The model determines the sequence of elements and their hierarchy. The data type itself determines the XML attributes within the start tag. The notation here is as follows:

{| class="hl7table"
|+
! Attribute !! DT !! Conf !! Description
|-
| (name of the model attribute or XML element) || Data type || Conformance, i.e. O, R, M || Textual description
|}

XML attributes (data type properties) are denoted as ''@attribute'' in order to distinguish their names from XML elements.

Example: in the example model above, the data type of the ''id'' attribute's is ''II'' (Instance Identifier). The corresponding XML attributes for that data type include ''@root'' and ''@extension''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id root="..." extension="..." />
</syntaxhighlight>

A description of the data types and their corresponding XML representation is contained in subsequent paragraphs of this guide.

==== Exceptions using XML element content ====

For most data types, the actual data is conveyed in XML attributes. However, there are some exceptions. For the data types binary (BIN), Encapsulated Data (ED), Entity Name (EN), Person Name (PN), Organization Name (ON), Trivial Name (TN), Address (AD) and character string data (ST), information is carried as element content.

Example: the components of an address <addr> are represented by sub elements with the data as element content (in the example shown in black).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr>
<streetAddressLine>Thormøhlens gate 12</streetAddressLine>
<postalCode>5006</postalCode>
<city>Bergen</city>
</addr>
</syntaxhighlight>

==== Combined data types ====

There are a number of so-called combined data types. For example, an interval with a lower and upper limit and a ratio that has a nominator and a denominator value.

In combined data types the substructure (e.g. <low> <high> in an interval) are represented as child elements of the relevant data type element.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110701"/>
<high value="20110729"/>
</effectiveTime>
</syntaxhighlight>

==== Conformance information ====

The conformance indicators distinguish kinds of conformance information described shortly here.

* '''O''': An optional item may be omitted if no data is present, i.e. no corresponding XML attribute or element is sent (marked as “O”)
* '''R''': For required items, lower cardinality is always zero or 1.
** Elements must be present and populated with data if present in the sending system. If no data is available (yet), a null flavor (see below) indicates and possibly classifies the missing information (marked as R).
** Attribute flagged as required must be present in the instance and populated.
* '''M''': For mandatory elements data must be sent and no missing values are allowed, i.e. if the sending system does not have information for mandatory elements the XML instance cannot be created and sent (marked as M).
* '''NP''': no data may be present at all (not permitted)
* '''C''': conditional conformance; typically a conformance table shows the circumstances (conditions) derived from information in the instance and the corresponding cardinalities and conformance statements.

=== Missing values (null flavor) ===

For every data type it is possible to specify a missing value including a kind of reason why data is missing. Instead of specifying any attribute of the corresponding element, a ''@nullFlavor'' attribute expresses the omission of data. Note that missing data is not allowed for mandatory elements (see above).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value nullFlavor="OTH"/>

<code nullFlavor="UNK"/>

<booleanInd nullFlavor="NI"/>

</syntaxhighlight>

The codes for the ''@nullFlavor'' attribute are drawn from the following hierarchical code system. It is a Coded Simple (CS), which means it has no code system (attribute ''@codeSystem'') specified.

{| class="hl7table"
|+<ref group="Table">NullFlavor</ref> ''NullFlavor''
! Code
! width=15% | Print Name
! Definition / Description
|-
| NI || No Information || No information whatsoever can be inferred from this exceptional value. This is the most general exceptional value. It is also the default exceptional value.
|-
|   OTH || other || The actual value is not an element in the value domain of a variable. (e.g., concept not provided by required code system).
|-
|     NINF || negative infinity || Negative infinity of numbers.
|-
|     PINF || positive infinity || Positive infinity of numbers.
|-
|   UNK || unknown || A proper value is applicable, but not known.
|-
|     ASKU || asked but unknown || Information was sought but not found (e.g., patient was asked but didn't know)
|-
|       NAV || temporarily unavailable || Information is not available at this time but it is expected that it will be available later.
|-
|       NASK || not asked || This information has not been sought (e.g., patient was not asked)
|-
|       TRC || trace || The content is greater than zero, but too small to be quantified.
|-
|   MSK || masked || There is information on this item available but it has not been provided by the sender due to security, privacy or other reasons. There may be an alternate mechanism for gaining access to this information.
Note: using this null flavour does provide information that may be a breach of confidentiality, even though no detail data is provided. Its primary purpose is for those circumstances where it is necessary to inform the receiver that the information does exist without providing any detail.
|-
|   NA || not applicable || No proper value is applicable in this context (e.g., last menstrual period for a male).
|-
| NP || not present || Value is not present in a message. This is only defined in messages, never in application data! All values not present in the message must be replaced by the applicable default, or no-information (NI) as the default of all defaults.
|}

=== ANY as the generic data type ===

This abstract data type is the basis for all other data types. Not a single value within a CDA document has the effective data type ANY, but any data type within HL7v3 is a specialization of ANY. This also means that any other data type inherits all properties of ANY (see [[#Missing_values_.28null_flavor.29|“Missing values (null flavor)”]]).

The ANY type is occasionally found in HL7 models when it comes to clinical finding etc. where – at model time – the actual data type of the value is not known. At instantiation time however, the actual data type ''is'' known and ANY is always replaced by a particular data type in an instance.

One example is the observation value (child element value in an observation), where in the model the data type of value cannot be anticipated. When instantiation is taking place, the data type is specified by the XML instance attribute ''@xsi:type''. This information can be used by the receiver to validate and process the value.

Attributes of an element with this data type are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@nullFlavor''' || <center>CS</center> || <center>–</center> || Classification of the missing value, see [[#Missing_values_.28null_flavor.29|3.3 Missing values (null flavor)]].
|}

{| class="hl7table" style="width:100%"
| width=8% | <center>[[File:Conformance.svg|50px]] dtr1-1-ANY</center> || If there is a ''nullFlavor'', there shall be no other attribute or element, unless it's ''nullFlavor="OTH"''.

In that case ''@codeSystem'' or ''originalText'' (see “code” data types) may have a value.
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">

<value xsi:type="CE" code="N11.9" codeSystem="2.16.840.1.113883.6.3"/>


<value xsi:type="PQ" value="12" unit="mL"/>


<value xsi:type="ED">this is text</value>
</syntaxhighlight>

=== Boolean (BL) ===

Elements of this data type refer to Boolean logic and have an attribute ''@value''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>BL</center> || <center>–</center> || Valued as “true” or “false”
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<negationInd value="false"/>

<deceasedInd value="true"/>

</syntaxhighlight>

In some situations, the BL data does not apply to an XML element, but an attribute. In that case, the attribute carries the Boolean value directly.
<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<support contextConductionInd ="false">
...
</support>
</syntaxhighlight>

=== Instance Identifier (II) ===

This data type identifies instances of classes like observations or entities (persons, organizations). Attributes are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@extension''' || <center>ST</center> || <center>O</center> || Identification
|-
| '''@root''' || <center>OID</center> || <center>R</center> || Source of identification
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id extension="13234453645" root="2.16.840.1.113883.2.6.15.3.427.1"/>
</syntaxhighlight>

The ''@root'' attribute is of type OID (object identifier), a unique identifier of the issuing authority or system. For example, a patient with a patient number 13234453645 created by a specific healthcare provider organization is uniquely identified by the number itself in ''@extension'' and the OID of the organization or the sending system, in the example 2.16.840.1.113883.2.6.15.3.427.1 in ''@root''.
In some cases, a single OID identifies an object uniquely. In that situation, only ''@root'' is populated and ''@extension'' is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Encapsulated Data (ED) ===

Elements of this data type carry multimedia content. The actual multimedia content is represented as element content. There are two situations for the use of ED:

* Inline: The full data is transmitted in the type. This form is mainly used for text.
* By reference: a thumbnail is provided which links to the full data by reference.

In an instance, the data type is normally determined by an ''xsi:type'' specification and some attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@mediaType''' || <center>CS</center> || <center>O</center> || MIME media type classification. At time of writing this specification, the following MIME types are allowed:
* text/plain (plain text)
* text/html (text with html markup)
* image/jpeg (JPEG image)
* application/pdf (a PDF, portable document format)
* application/hl7-sda+xml (CDA documents).
|-
| '''@representation''' || <center>CS</center> || <center>O</center> || Representation of the multimedia content. At time of writing this specification, the following representations are allowed:
* TXT (text, this is the default)
* B64 base 64 encoded data, for example for embedded CDA documents).
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<text xsi:type="ED" mediaType="text/plain">
Patient treated sucessfully
</text>

<text mediaType="application/hl7-sda+xml" representation="B64">PD94bWw..etc..==</text>

</syntaxhighlight>

To include referenced data the two sub elements ''thumbnail'' and ''reference'' are used.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''reference''' || <center>TEL</center> || <center>0..*</center> || <center>O</center> || Link (URI) to full data
|-
| '''thumbnail''' || <center>ED</center> || <center>0..*</center> || <center>O</center> || Thumbnail of referenced data
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value xsi:type="ED" mediaType="image/png" representation="B64">
<reference value="http://radiology.bergen.no/xrays/128s.png"/>
<thumbnail mediaType="image/jpeg" representation="B64"> MNY...83== </thumbnail>
</value>
</syntaxhighlight>

=== Strings (ST) ===

This data type is a specialization of the ED type where ''@mediaType'' is fixed “text/plain” and ''@representation'' is fixed “TXT”. It allows conveying a character string as '''element content'''. This data type is used in other data types it like the ''@extension'' in instance identifiers, or address and person name data type components.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<lotNumber> 143GT6DT </lotNumber>
</syntaxhighlight>

=== Concept Descriptor (CD) ===

This data type specifies a concept by means of a code and its code system (except for situations where no code is available). A couple of specializations of data type CD exist, which differ in the main characteristics (properties) of the data type that may or may not be supported.

{| class="hl7table" style="width:50%"
|+<ref group="Table">Properties of data types used for codes</ref> ''Properties of data types used for codes''
! <div style="text-align: right">DataType</div> !! CD !! CE !! CV !! CO !! CS
|-
! <div style="text-align: left">Property</div> !! !! !! !! !!
|-
| '''@code''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||<center>X</center>
|-
| '''@codeSystem''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''@codeSystemVersion''' || <center>X</center> || <center>X</center> || <center>X</center>|| <center>X</center> ||
|-
| '''@displayName''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''originalText''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''translation''' || <center>X</center> || <center>X</center> || || ||
|-
| '''qualifier''' || <center>X</center> || || || ||
|}

Because the CE variant is most used in practice, the general explanation of the properties will be given with de description of CE (see below).

The only attribute that is unique to CD is briefly explained here.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@qualifier''' || <center>CR</center> || <center>O</center> || An additional qualifier for the code.
|}

Complex terminologies like SNOMED CT can be used only using data type CD.

=== Coded with Equivalents (CE) ===

With elements of this data type, a concept by means of a code and its coding system (except for situations where no code is available) can be specified. It optionally contains one or more equivalents using other code systems.
It may contain the following attributes:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@code''' || <center>ST</center> || <center>R</center> || The actual code
|-
| '''@codeSystem''' || <center>OID</center> || <center>R</center> || required to identify the code system were the code is drawn from. This is an OID (object identifier, see [[#Object_Identifiers_.28OIDs.29|Object Identifiers at 4.1]])
|-
| '''@displayName''' || <center>ST</center> || <center>O</center> || Optional textual representation of code. A display name may be specified representing the plain text of the code. The information of this attribute may not be used by the receiving system for interpretation, but only for display purposes. The display name may never be transmitted without a code and must have the same meaning as the code.
|-
| '''@codeSystemName''' || <center>ST</center> || <center>O</center> || A textual representation of the name of the code system
|-
| '''@codeSystemVersion''' || <center>ST</center> || <center>O</center> || A textual representation of the version of the code system
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"/>

<code code="AU" codeSystem="2.16.840.1.113883.5.33"/>

<storageCode code="AC" codeSystem="2.16.840.1.113883.5.34" displayName="active"/>

<code code="A45.0" displayName="Somatisierungsstörung" codeSystem="1.2.276.0.76.5.409" codeSystemName="ICD-10 GM 2012"/>
</syntaxhighlight>

There are some child elements of codes that can be used to express what the “original text” was that was used for the coding or to indicate that there are “translations” to other code systems than the primary code.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''originalText''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Textual representation of the concept, actually a description which was used to create the actual code
|}

No semantics may be assumed other than showing the ''@displayName'' to a user to clarify the code. A display name cannot occur without its code and must carry the same meaning.

In case no code is known, it is allowed to specify a ''@nullFlavor'' for the code element and to give information about the (not yet coded) concept in original text. However, this should be an exception.

If other codes than the primary code need to be conveyed adding a translation child element can be used.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<originalText>minor aphthous stomatitis</originalText>
</code>
</syntaxhighlight>

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''translation''' || <center>CD</center> || <center>0..*</center> || <center>O</center> || Alternative code(s)
|}

A ''translation'' element is also of type CD and shall have a code and a code system identified. It shall point to the same concept as the primary code. It is allowed that a translation conveys less conceptual details than the original code.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<translation code="528.2" codeSystem="2.16.840.1.113883.6.2" codeSystemName="ICD9" displayName="Oral aphthae"/>
</code>
</syntaxhighlight>

=== Coded Value (CV) ===

This is actually a specialization of CE (see above), with the exception that neither ''originalText'' nor ''translation'' child element are allowed.

=== Coded Simple Value (CS) ===

This is actually a specialization of CE (see above), with no code system attribute and no original text or translation child element allowed. It specifies a concept by means of a code from a ''predefined'' code system (table) where the code is drawn from. This data type is usually applied in the context of fixed predefined HL7 tables.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<statusCode code="completed"/>
</syntaxhighlight>

In this example ''statusCode'' is bound in the underlying model to the specific code system ''ActStatus''. Because it is predefined by means of the vocabulary binding, ''@codeSystem'' is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Telecommunication Address (TEL) ===

Elements of this type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>ST</center> || <center>R</center> || carries strings that represent telecommunication contact information
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

The actual data is preceded by the scheme (refer to Internet Standard “RFC 1738 Uniform Resource Locators (URL)” <ref>RFC 1738 Uniform Resource Locators (URL): http://www.ietf.org/rfc/rfc1738.txt</ref>.

Examples:
* telephone (tel:),
* fax (fax:),
* email (mailto:).

It must follow the rules defined in Internet “RFC 2806 URLs for Telephone Calls” <ref>RFC 2806 URLs for Telephone Calls: http://www.ietf.org/rfc/rfc2806.txt</ref>.

The following codes will be used in the “use” attribute:
* H – Home
* WP – Work
* MC can be used (in addition to H or WP) to denote that this is a mobile phone.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257" />

<telecom use="H" value="tel:55354257" />

<telecom use="H" value="fax:56542558" />

<telecom value="tel:+41.34.21.4765342"/>

<telecom value="mailto:opr@opr-sem.no"/>

<telecom use="WP MC" value="tel:97555786" />
</syntaxhighlight>

It is possible to express the useable period of a telecommunication contact. A child element ''useablePeriod'' is used as a time interval to indicate this period.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''useablePeriod''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257">
<useablePeriod>
<high value="20111201"/>
</useablePeriod>
</telecom>
</syntaxhighlight>

=== Postal Address (AD) ===

Elements of this data type have a substructure in order to represent a structured address specification. In this implementation guide only a selection of all possible child elements is allowed, the original HL7 specification is richer.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''streetAddressLine''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Street address, includes street name and house number
|-
| '''city''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || City
|-
| '''postalCode''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Postal code
|-
| '''country''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Country
|-
|}

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that the sequence of the sub elements is country specific, i.e. it has to follow “common” rules how to write an address. For example, an UK address and a German address have different sequences of address representation.
|}

A ''@use'' attribute can also be specified.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="WP">
<streetAddressLine>Anna-Louisa-Karsch-Str. 2</streetAddressLine>
<postalCode>10178</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="H WP">
<streetAddressLine>Tatungasse 34</streetAddressLine>
<postalCode>10825</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

Also, a country may be specified using the element ''country''.

=== Person Name (PN) ===

Elements of this data type do also have a substructure to represent the parts of a person name, like family or given name and prefixes.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>
<given>Franz</given>
<given>Ingrun</given>
<family>Nordmann</family>
</name>
</syntaxhighlight>

Previous or birth or maiden names are supported using the ''validTime'' element. ''validTime'' (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]]) specifies the validity range of the name.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">

<name>
<given>Jan</given>
<given>Olaf</given>
<family>Hendrikson</family>
<validTime>
<high value="20000101"/>
</validTime>
</name>
</syntaxhighlight>

Note that the name attribute is repeating, i.e. multiple (types of) names could be sent. It is up to the receiver (based on the value of the ''@use'' attribute, and ''validTime'') to decide what name it wants to use or import in its database.

=== Organisation Name (ON) ===

Elements of this data type represent a name of an organization.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name> Charité Berlin </name>
</syntaxhighlight>

The optional ''validTime'' element (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]] may be used to specify the validity range of the name of the organization.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name of the organization
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>The old hospital
<validTime>
<high value="20111231235959"/>
</validTime>
</name>
</syntaxhighlight>

Please note that the use of ''validTime'' yields XML mixed content which should be avoid-ed if possible.

=== Integer Number (INT) ===

Elements of this data type are used to specify integer numbers and have one attribute.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>int</center> || <center>R</center> || Integer value
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<sequenceNumber value="24"/>
</syntaxhighlight>

=== Physical Quantities (PQ) ===

Elements of this data type are physical quantities, i.e. a measurable quantity (or countable) value from the physical world. This is different from just a “number”, because there is a (natural) unit specified in which the measurable quantity is expressed.
Examples:
* an amount of blood 20 ml (sample volume)
* a cut with a length of 10 cm (result observation)
* a dose of 200 milligrams per administration (dosing)
* delivery of 60 pieces of a tablet (amount supplied).
Elements of this data type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>real</center> || <center>R</center> || value of the measurement
|-
| '''@unit''' || <center>CS</center> || <center>R</center> || unit of measurement
|}

In the unit of measurement unit is expressed following the ''Unified Code for Units of Measure'' (UCUM) specification. This specification is a collection of atomic units, prefixes and a corresponding grammar for valid combinations to build all-natural units of measurement. For a complete description of possible units, see the ''Unified Code for Units of Measure'' <ref>Unified Code for Units of Measure: http://unitsofmeasure.org/</ref> specification.
If a value is not countable or if measurable, for example expressed in milligrams or liters, then this unit is a valid UCUM unit like “mg” or “L”. If a value is countable, for example the number of tablets, then this attribute contains “1”.
In HL7 it is required that all PQ data type units are valid UCUM units.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<value value="165" unit="cm"/>

<value value="81.1" unit="kg"/>

<value value="120" unit="mm[Hg]"/>

<value value="5" unit="1"/>
</syntaxhighlight>

=== Point in Time (TS) ===

Elements of this data type have the attribute

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>TS</center> || <center>R</center> || Point in time
|}

and specify points in time in the format YYYYMMDDhhmmss±ZZZZ, where
* YYYY is the four-digit year,
* MM the two-digit month,
* DD the two-digit day,
* hh the two-digit hour,
* mm the two-digits minute and
* ss the two-digit second.
Optional a time zone ZZZZ, the four-digit time alignment with a preceding “-” or a “+” can be specified. If time zone is omitted, local time is assumed.
The point in time may be right truncated in respect to the precision of the information.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<effectiveTime value="20140412"/>

<effectiveTime value="201409091245"/>

<effectiveTime value="1996"/>

<birthTime value="19540714"/>

<effectiveTime value="20140412+0100"/>
</syntaxhighlight>

=== Intervals (IVL) ===

Intervals are defined only for data types with an ordinal or interval scale type. There are several possibilities to determine an interval (see Figure 2), for example to specify

* a lower <low> and an upper boundary <high> (a),
* a lower <low> boundary and width <width> (b)
* an upper boundary and width <width> (c) or
* the middle of the interval <nowiki><center></nowiki> and a width <width> (d).

[[File:CDA_Core_Principles_Figure_2_Determining_Intervals.png|700px]]

<ref group="Figure">Several possibilities to determine closed intervals</ref> ''Several possibilities to determine closed intervals''

{{ConstraintBox|
To indicate an interval, only the following combinations are permitted.
(1) A lower and an upper boundary may not be identical, and their accuracy has to be equal.

Correct examples:

{{BeginGreenBox|}}
Interval from 5 to 6
Interval from 20110607 until 20110612
{{EndGreenBox}}

Incorrect examples:

{{BeginRedBox|}}
Interval from 5 to 6.0
Interval from 20110101 to 2011
{{EndRedBox|}}

(2) A lower boundary and a width

(3) A lower limit boundary

(4) A upper limit boundary

(5) Only the middle of the interval

(6) Only the width of an interval}}

Accordingly, four child elements are available.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Lower boundary
|-
| '''high''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Upper boundary
|-
| '''center''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Where ''(T)'' is defined in this specification as one of the data types “TS” or “PQ”.

=== Interval of time (IVL_TS) ===

Elements of this data type represent time intervals. There are four possible child elements.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Lower boundary (start date/time)
|-
| '''high''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Upper boundary (end date/time)
|-
| '''center''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Normally, a lower and an upper boundary is given, both are points in time. Also, it is possible to specify open intervals like “since June 14, 1999” (left boundary given only) or “until September 24, 2006” (right boundary given).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110507"/>
<high value="20110909"/>
</effectiveTime>

<effectiveTime>
<low value="20110507"/>
</effectiveTime>

<value>
<low value="20110101"/>
<width value="120" unit="d"/>
</value>

<value>
<center value="20110101"/>
</value>
</syntaxhighlight>

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|It must be noted that intervals of time stamps in HL7 are equally treated as other interval types (e.g. integers). The statement, one may take 1–3 tablets (interval of integers), for example, says that you are allowed to take no more than three tablets, not 3½ or 3.5 tablets. On the other hand, when treat the words “until 12 June 2011” regarding the upper interval limit differently, particularly we assume that the entire day 12 June is still in-cluded in this time interval.
Thus, in human perception time intervals are handled differently com-pared to such as number intervals. This is a situation may lead to inconsist-encies in standardized communication. As a conclusion, an upper limit “12 June 2011” means that only the very first moment of the 12 June is included in the interval, but not, for example, the 12 June 13:00 hours.
Interpretation does not depend on the accuracy of the time:
* “after 2004” means “from January 1, 2005 00:00:00.000”,
* “after 20041201” means “from 2 December 2004 00:00:00.000 hours”,
* and “after 200412011200” means “from 1 December 2004 12:01:00.000”.

As a result, you have to carefully consider the specification and implemen-tation of time intervals upper boundaries. In order to prevent mis-understandings intervals are always specified with the date and time for an upper limit that would cover the whole day. Accordingly, “201106122359” means 12 June 2011 throughout the day.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="201106122359"/>
</effectiveTime>
</syntaxhighlight>

Because of the equal treatment of time intervals this is applied also to the lower limit boundaries of time intervals as “0000”. This means for example that “since 9 June 2011” is expressed as “201106090000”.
|}

The <width> element is of data type PQ (physical quantity). The value obviously shall relate to a period of time and it is required to include a “time” unit. These are the units “us” (microseconds), “ms” (milliseconds), “s” (seconds), “min” (minute), “h” (hours), “d” (day), “wk” (week), “mo” (month) and “a” (year).

{{ConstraintBox|
For interval of time stamps the @unit of a ''low'' or ''high'' child element shall use units
* us (microseconds),
* ms (milliseconds),
* s (seconds),
* min (minute),
* h (hours),
* d (day),
* wk (week),
* mo (month) or
* a (year).
}}

=== Interval of physical quantities (IVL_PQ) ===

Elements of this data type are used to indicate intervals of physical quantities (see also [[#Physical Quantities (PQ)|3.18 Physical Quantities (PQ)]]). In general, an upper and a lower boundary is specified. It is also possible to use ''center'' instead of ''low'' and ''high''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low || <center>TS</center> || <center>0..1</center> || <center>C</center> || the lower limit of the interval (i.e. the minimum amount).
|-
| '''high || <center>TS</center> || <center>0..1</center> || <center>C</center> || the upper limit of the interval (i.e. the maximum amount).
|-
| '''center || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of the interval
|}

The ''center'' child element is used when there is no interval, but an exact value. Alternative would be to demote IVL_PQ to data type PQ and populate the element’s ''@value'' attribute, but this is more difficult to process in XML. That is why the use of the ''center'' child element is deprecated.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<referenceRange>
<low value="7.5" unit="mmol/l"/>
<high value="10" unit="mmol/l"/>
</referenceRange>

<doseQuantity>
<center value="9" unit="1"/>
</doseQuantity>
</syntaxhighlight>

=== Ratio of quantities (RTO_QTY_QTY) ===

Elements of this data type specify ratios and have two child elements, a numerator and a denominator. The underlying QTY (Quantity) data type is an abstract data type and in a XML instance it has to be replaced by a specific data type using the ''@xsi:type'' instruction (see below).

In this specification only “PQ” or “INT” are allowed for the demotion of both ''numerator'' and ''denominator''. The relevant child elements are:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''numerator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the numerator of the ratio
|-
| '''denominator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the denominator of the ratio
|}

If a model attribute already is a RTO_QTY_QTY, you need to specify (demote) the OTY abstract data type for both ''numerator'' and ''denominator'' by using an ''@xsi:type'' instruction.
In some cases where the model attribute is of type “ANY”, also the root element shall carry an ''@xsi:type'' RTO_QTY_QTY instruction.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<maxDoseQuantity>
<numerator xsi:type="PQ" value="6"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="400" unit="mg"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="5"/>
<denominator xsi:type="PQ" value="1" unit="h"/>
</maxDoseQuantity>

<value xsi:type="RTO_QTY_QTY">
<numerator xsi:type="INT" value="1"/>
<denominator xsi:type="INT" value="10000"/>
</value>
</syntaxhighlight>

== Identification mechanisms ==

=== Object Identifiers (OIDs) ===

Standardized exchange of information using messages or documents also deals with unique identifications of objects and concepts, especially in environments where sender and receiver do not “know” each other necessarily.

It is important to understand the difference between identification of instances (ids) and code concepts (classifications). Within the context of HL7 interactions OIDs are quite often used.
An id points to a specific instance of an object or identification scheme (a particular methodology for the identification of a class of objects), for example a specific person as the patient or a physician, a specific lab observation or an X-ray photo.

In contrast to instance identifiers, a classification identifies a specific concept. The type of patient (inpatient, outpatient), the type of doctor (an anesthesiologist), the codes for gender or a lab observation (blood cell count) may serve as examples.

OIDs (object identifiers) are worldwide unique identifiers for objects. They are used in HL7 to specify identifications and classifications. An object in this sense is persistent, well-defined information, definitions or specifications and is represented with ids or codes.

Commonly used OIDs (i.e. used for a purpose that is wider in scope than the regional healthcare organization; used in communications between healthcare regions) can be found in OIDs registries such as

* [http://www.oid-info.com www.oid-info.com],
* [http://www.hl7.org www.hl7.org],
* [http://www.hl7.org.uk/version3group/oids.asp HL7 OID registry in the UK],
* [https://www.dimdi.de/dynamic/de/klassifikationen/weitere-klassifikationen-und-standards/oid/ OID registry Germany].

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|All OIDs with an element of 999 or 9999 are for documentation purposes only. They will be replaced by permanent OIDs once these have been as-signed/found/applied for.
|}

OID (Object Identifiers) are unique identifiers for any kind of objects. They are defined in Rec. ITU-T X.660 | ISO/IEC 9834-1. This identification system for objects and concepts makes reliable electronic information exchange possible. Administration and Registration is regulated by a set of rules, described in the corresponding chapter of this document.

Every artefact in ART-DECOR has an Object Identifier (OID). There are recommendations for the management and the exchange of Object Identifiers, partially defined in ISO TS 13582 <ref>ISO TS 13582: https://www.iso.org/standard/69652.html</ref>.

''HL7 International'' has created a type ontology for the OIDs in the HL7 registry to make it easier for the user community to search for OIDs they may be looking for and can be found at hl7.org.

From a policy perspective it is common practice in several healthcare related OID registries (HL7 International at http://www.hl7.org, OID Registry Germany at http://www.dimdi.de, OID registry Switzerland at http://oid.refdata.ch, and OID registry Austria at https://www.gesundheit.gv.at/OID_Frontend) to distinguish at least between the following types of OIDs:

{| class="hl7table" style="width:60%"
|+<ref group="Table">Recommended OID sub-branches for different artefacts</ref> ''Recommended OID sub-branches for different artefacts''
! Arc !! Description
|-
| .3 || organizational bodies and groups
|-
| .4 || identifier systems and namespaces
|-
| .5 || code systems
|-
| .7 || document artefacts
|-
| .9 || conformance profiles
|-
| .10 || templates
|-
| .11 || value sets
|-
| .19 || examples
|-
| .99 || experimental
|}

''Example: given that “your” root OID is 1.2.3.4.5, the first value set of your governance group is then to be 1.2.3.4.5.11.1, with .11 as the value set “branch” and the last .1 as the first artefact of that kind.''

In ART-DECOR a project typically is set into the .77 branch of a governance group. When setting up the project, the OID for that project also determines the artefact OIDs using throughout the ART-DECOR project. The following additional branches are used to distinguish between different OID types:

{| class="hl7table"
|+<ref group="Table">Recommended OID sub-branches for ART-DECOR projects</ref> ''Recommended OID sub-branches for different artefacts''
! Artefact code Description !! Recommended !! OID suffix
|-
| DS || dataset || .77.1
|-
| DE || dataset concept || .77.2
|-
| SC || scenario || .77.3
|-
| TR || transaction in scenario || .77.4
|-
| CS || code system || .77.5
|-
| IS || issue || .77.6
|-
| AC || actor in scenario || .77.7
|-
| CL || concept list in dataset || .77.8
|-
| EL || element in template || .77.9
|-
| TM || template || .77.10
|-
| VS || value set || .77.11
|-
| RL || rule for instances || .77.12
|-
| SX || test/example scenario || .77.18
|-
| EX || test/example instance || .77.19
|-
| QX || qualification test/example || .77.20
|-
| TX || test/example data element || .77.21
|-
| CM || community || .77.22
|-
| MP || concept map || .77.24
|}

In ART-DECOR a newly created project uses these OID branches automatically.

=== Instance identification ===

Instance identification is done with the id element of a class. Its type is II (instance identifier) and described in the data type section above. For example, a patient number can be represented as
* 2.16.578.1.34.1.5432.1, the root-OID of the issuing authority, for example a system/application in a hospital, and
* 67543242 as the ''@extension'', representing the patient number within the system defined by the ''@root'' attribute.

=== Coding scheme identification ===

Coding schemes have to be uniquely identified using OIDs as well. All coding tables used in this implementation guide show the corresponding OID that has to be specified in the ''@codeSystem'' attribute of coded elements. Both attributes ''@code'' and ''@codeSystem'' together allows a correct interpretation of concept and code.

=== List of identification schemes ===

The following are OIDs for commonly used identification schemes.

{| class="hl7table"
|+<ref group="Table">Commonly used identification scheme OIDs</ref> ''Commonly used identification scheme OIDs''
! OID !! Identification System Name !! Description !! Issuer
|-
| 1.2.276.0.76.4.8 || KV-Nummer || Krankenversichertennummer ||
|-
| 1.2.276.0.76.4.17 || BSNR || Betriebsstättennummer ||
|-
| 1.2.276.0.76.4.16 || LANR || lebenslange Arztnummer ||
|}

=== List of code systems ===

The following are OIDs for code systems.

{| class="hl7table"
|+<ref group="Table">Commonly used code system OIDs</ref> ''Commonly used code system OIDs''
! OID !! Code System Name !! Description !! Issuer
|-
| 2.16.840.1.113883.6.1 || LOINC || Logical Observation Identifiers Names and Codes (LOINC) || Regenstrief Institute
|-
| 2.16.840.1.113883.6.96 || SNOMED CT || Systemized Nomenclature in Medicine Reference Terminology (SNOMED CT) || SNOMED International
|-
| 1.0.3166.1.2 || ISO 3166-1 (second edition) || Country codes as per ISO 3166-1:2007 || ISO
|}

== Vocabulary ==

=== Code Systems ===

Within HL7, a ''Code System'' is defined as a collection of codes with associated designations and meanings. Examples of code systems include ICD-10, SNOMED CT, and LOINC.
To meet the requirements of a code system as defined by HL7, a given code must resolve to one and only one meaning within the code system. Given this definition, each code table in the HL7 Version 3 standard represents a different code system since codes are sometimes used in different tables to have different meanings.
For example, “M” in the administrative gender table (''AdministrativeGender'', OID 2.16.840.1.113883.5.1) means “male”, while “M” in the marital status table (''MaritalStatus'', OID 2.16.840.1.113883.5.2) means “married”.
In this specification, code system tables are not presented in detail.

=== Value Sets ===

A ''Value Set'' represents a uniquely identifiable set of valid concept representations, where any concept representation can be tested to determine whether or not it is a member of the value set.
Value set complexity may range from a simple flat list of concept codes drawn from a single code system, to an unbounded hierarchical set of possibly post-coordinated expressions drawn from multiple code systems.
Value sets exist to constrain the content for a coded element in an HL7 static model or data type property. Value sets cannot have null content and must contain at least one concept representation where any given concept is generally (but not required to be) represented by only a single code within the Value Set.

[[File:CDA_Core_Principles_Figure_3_ValueSet_Example.png|800px]]

<ref group="Figure">Example presentation of the value set “MaritalStatus”</ref> ''Example presentation of the value set “MaritalStatus”''

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that value set OIDs never appear in a CDA Release 2 document. They are used for constraint expressions, for example in implementation guides.
In order to send a specific code drawn from a value set, the corresponding code system has to be conveyed.
An example, in the implementation specification the constraint on the model element ''maritalStatusCode'' is expressed as “to be drawn from value set 2.16.840.1.113883.5.2 ''MaritalStatus''”.
To actually send a marital status of “M” (married) that is shown in the value set figure above, the corresponding HL7 CDA instance would say:
<syntaxhighlight lang="xml">
<maritalStatusCode code="M" codeSystem="2.16.840.1.113883.5.2"/>
</syntaxhighlight>
|}

In this specification, value set tables are not presented in detail.

==== Binding strength ====

There is an optional vocabulary strength for data types that support that feature (coded concepts). Examples include CD, CE, CV and CO. Values are required, extensible, preferred and example. Default is required.

Please note: the formerly supported values CNE (Coded No Extensibility) and CWE (Coded With Extensibility) in ART-DECOR are deprecated as of December 2017. Specification CNE is handled as required and CWE is handled as extensible.

{| class="hl7table"
|+<ref group="Table">Binding Strengths</ref> ''Binding Strengths''
! Strength !! Description
|-
|required||Required/CNE. Coded with no exceptions; this element SHALL be from the specified value set
|-
|extensible||Extensible/CWE. Coded with Exceptions; this element SHALL be from the specified value set if any of the codes within the value set can apply to the concept being communicated. If the value set does not cover the concept (based on human review), alternate codings (or, data type allowing, text) may be included instead.
|-
|preferred||Preferred. Instances are encouraged to draw from the specified codes for interoperability purposes but are not required to do so to be considered conformant.
|-
|example||Example. Instances are not expected or even encouraged to draw from the specified value set. The value set merely provides examples of the types of concepts intended to be included.
|}

Mismatches with required lead to validation errors (SHALL logic). Mismatches with extensible lead to validation warnings (SHOULD logic). Mismatches with preferred lead to validation information messages (MAY logic). Mismatches with example don't have any validation consequences.

== Appendix ==

=== References ===

<references/>

=== List of figures ===

<references group="Figure" />

=== List of tables ===

<references group="Table" />

HL7 CDA Core Principles

2019-06-16T11:06:43Z

Dammon: /* Missing values (null flavor) */

== Introduction ==

This implementation guide specifies the ''Core Principles'' of using the ''Clinical Document Architecture'' <ref>Clinical Document Architecture Release 2: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=7</ref>.

=== Scope ===

This guide focuses on ''Data Types Release 1'' <ref>HL7 Data Types Release 1: http://www.hl7.org</ref>. Meanwhile an ISO specification ISO 21090 is out, also known as Data Type Release 2. The latter is subject to another implementation guide that will be published when ISO data types are used.

=== Focus of this document: HL7 Version 3 Data Types for CDA ===

The following chapters of this document will focus on the description of the data types and associated material. It will highlight the essentials in four chapters, all focusing on the Norwegian situation.
* '''Common aspects:''' explains common aspects of use of CDA and XML
* '''Data types:''' gives an overview and detailed specification of all data types used in CDA
* '''Identification schemes:''' explains major aspects of identification and the use in CDA
* '''Use of vocabulary:''' explains major aspects of vocabulary use in CDA.

=== Background ===

In many (European) countries, implementation guides for the use of data types in HL7 V3 are published. They take into account country specific constraints on the data types.

=== Legend of symbols ===

In this document several symbols are used.

{| class="hl7table" style="width:50%"
| [[File:Pfeil_rechts.png|50px]] || This is an important item
|-
| [[File:Issue.svg|50px]] || This is a known open issue
|-
| [[File:Faq.svg|50px]] || This is a frequently asked question (FAQ) with answer
|-
| [[File:Conformance.svg|50px]] || This is a constraint; in some situations also the rule identification is specified, e.g. dtr1-1-ANY, which links to the corresponding validation rule.
|}

=== Version history ===

{| class="hl7table" style="width:50%"
|+
! Version !! Date !! Description !! Author
|-
| 1.1 || 2019-04-24 || Refurbished guide based on earlier work || Kai U. Heitmann
|}

== Common aspects ==

=== Use of XML ===

HL7 Version 3 CDA uses the Extensible Markup Language (XML) as the exchange format. It is assumed that the reader is familiar with common XML aspects. However, some constraints are made regarding the use of CDA.

==== Character Set ====

{{ConstraintBox|
The character encoding of any CDA document shall be “UTF-8”.}}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="utf-8"?>
</syntaxhighlight>

=== CDA document structure ===

The XML namespace for CDA Release 2 documents is ''<nowiki>urn:hl7-org:v3</nowiki>''. This must be correctly mentioned in every XML instance.

CDA XML documents starts with the root element ''ClinicalDocument''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">


...

<component>
<structuredBody>
...
</structuredBody>
</component>

</ClinicalDocument>
</syntaxhighlight>

== Data types ==

=== Introduction ===

The following chapter describes the typical data types used in CDA implementation guides. For further information please refer to the HL7 V3 standard and its two parts concerning data types:
* Abstract Data type definition <ref>HL7 Version 3 Abstract Data type definition: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=264</ref>
* XML ITS for data types <ref>XML ITS for data types: https://www.hl7.org/documentcenter/public_temp_682D4D16-1C23-BA17-0C789BA52BEDB68E/wg/inm/datatypes-its-xml20050714.htm</ref>
Data types are properties of model class attributes and the basic building blocks of information in a CDA XML instance. For example, a model attribute named “time” has as its data type a time stamp “TS” (see Figure 1).

[[File:CDA_Core_Principles_Figure_1_CDA_Structure_Data_Types.png|700px]]

<ref group="Figure">CDA structure (left) and the data type specification (right)</ref> ''CDA structure (left) and the data type specification (right)''

=== XML representation of data types ===

Actual data is mostly carried in HL7 Version 3 by populating XML attributes and not as element content. Exceptions are names of persons and organizations as well as addresses.

The XML elements have names like the model attributes. For example, a model attribute “id” has a corresponding XML element named <id…>. The model determines the sequence of elements and their hierarchy. The data type itself determines the XML attributes within the start tag. The notation here is as follows:

{| class="hl7table"
|+
! Attribute !! DT !! Conf !! Description
|-
| (name of the model attribute or XML element) || Data type || Conformance, i.e. O, R, M || Textual description
|}

XML attributes (data type properties) are denoted as ''@attribute'' in order to distinguish their names from XML elements.

Example: in the example model above, the data type of the ''id'' attribute's is ''II'' (Instance Identifier). The corresponding XML attributes for that data type include ''@root'' and ''@extension''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id root="..." extension="..." />
</syntaxhighlight>

A description of the data types and their corresponding XML representation is contained in subsequent paragraphs of this guide.

==== Exceptions using XML element content ====

For most data types, the actual data is conveyed in XML attributes. However, there are some exceptions. For the data types binary (BIN), Encapsulated Data (ED), Entity Name (EN), Person Name (PN), Organization Name (ON), Trivial Name (TN), Address (AD) and character string data (ST), information is carried as element content.

Example: the components of an address <addr> are represented by sub elements with the data as element content (in the example shown in black).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr>
<streetAddressLine>Thormøhlens gate 12</streetAddressLine>
<postalCode>5006</postalCode>
<city>Bergen</city>
</addr>
</syntaxhighlight>

==== Combined data types ====

There are a number of so-called combined data types. For example, an interval with a lower and upper limit and a ratio that has a nominator and a denominator value.

In combined data types the substructure (e.g. <low> <high> in an interval) are represented as child elements of the relevant data type element.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110701"/>
<high value="20110729"/>
</effectiveTime>
</syntaxhighlight>

==== Conformance information ====

The conformance indicators distinguish kinds of conformance information described shortly here.

* '''O''': An optional item may be omitted if no data is present, i.e. no corresponding XML attribute or element is sent (marked as “O”)
* '''R''': For required items, lower cardinality is always zero or 1.
** Elements must be present and populated with data if present in the sending system. If no data is available (yet), a null flavor (see below) indicates and possibly classifies the missing information (marked as R).
** Attribute flagged as required must be present in the instance and populated.
* '''M''': For mandatory elements data must be sent and no missing values are allowed, i.e. if the sending system does not have information for mandatory elements the XML instance cannot be created and sent (marked as M).
* '''NP''': no data may be present at all (not permitted)
* '''C''': conditional conformance; typically a conformance table shows the circumstances (conditions) derived from information in the instance and the corresponding cardinalities and conformance statements.

=== Missing values (null flavor) ===

For every data type it is possible to specify a missing value including a kind of reason why data is missing. Instead of specifying any attribute of the corresponding element, a ''@nullFlavor'' attribute expresses the omission of data. Note that missing data is not allowed for mandatory elements (see above).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value nullFlavor="OTH"/>

<code nullFlavor="UNK"/>

<booleanInd nullFlavor="NI"/>

</syntaxhighlight>

The codes for the ''@nullFlavor'' attribute are drawn from the following hierarchical code system. It is a Coded Simple (CS), which means it has no code system (attribute ''@codeSystem'') specified.

{| class="hl7table"
|+<ref group="Table">NullFlavor</ref> ''NullFlavor''
! Code
! width=15% | Print Name
! Definition / Description
|-
| NI || No Information || No information whatsoever can be inferred from this exceptional value. This is the most general exceptional value. It is also the default exceptional value.
|-
|   OTH || other || The actual value is not an element in the value domain of a variable. (e.g., concept not provided by required code system).
|-
|     NINF || negative infinity || Negative infinity of numbers.
|-
|     PINF || positive infinity || Positive infinity of numbers.
|-
|   UNK || unknown || A proper value is applicable, but not known.
|-
|     ASKU || asked but unknown || Information was sought but not found (e.g., patient was asked but didn't know)
|-
|       NAV || temporarily unavailable || Information is not available at this time but it is expected that it will be available later.
|-
|       NASK || not asked || This information has not been sought (e.g., patient was not asked)
|-
|       TRC || trace || The content is greater than zero, but too small to be quantified.
|-
|   MSK || masked || There is information on this item available but it has not been provided by the sender due to security, privacy or other reasons. There may be an alternate mechanism for gaining access to this information.
Note: using this null flavour does provide information that may be a breach of confidentiality, even though no detail data is provided. Its primary purpose is for those circumstances where it is necessary to inform the receiver that the information does exist without providing any detail.
|-
|   NA || not applicable || No proper value is applicable in this context (e.g., last menstrual period for a male).
|-
| NP || not present || Value is not present in a message. This is only defined in messages, never in application data! All values not present in the message must be replaced by the applicable default, or no-information (NI) as the default of all defaults.
|}

=== ANY as the generic data type ===

This abstract data type is the basis for all other data types. Not a single value within a CDA document has the effective data type ANY, but any data type within HL7v3 is a specialization of ANY. This also means that any other data type inherits all properties of ANY (see [[#Missing_values_.28null_flavor.29|“Missing values (null flavor)”]]).

The ANY type is occasionally found in HL7 models when it comes to clinical finding etc. where – at model time – the actual data type of the value is not known. At instantiation time however, the actual data type ''is'' known and ANY is always replaced by a particular data type in an instance.

One example is the observation value (child element value in an observation), where in the model the data type of value cannot be anticipated. When instantiation is taking place, the data type is specified by the XML instance attribute ''@xsi:type''. This information can be used by the receiver to validate and process the value.

Attributes of an element with this data type are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@nullFlavor''' || <center>CS</center> || <center>–</center> || Classification of the missing value, see [[#Missing_values_.28null_flavor.29|3.3 Missing values (null flavor)]].
|}

{| class="hl7table" style="width:100%"
| width=8% | <center>[[File:Conformance.svg|50px]] dtr1-1-ANY</center> || If there is a ''nullFlavor'', there shall be no other attribute or element, unless it's ''nullFlavor="OTH"''. In that case ''@codeSystem'' or ''originalText'' (see “code” data types) may have a value.
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">

<value xsi:type="CE" code="N11.9" codeSystem="2.16.840.1.113883.6.3"/>


<value xsi:type="PQ" value="12" unit="mL"/>


<value xsi:type="ED">this is text</value>
</syntaxhighlight>

=== Boolean (BL) ===

Elements of this data type refer to Boolean logic and have an attribute ''@value''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>BL</center> || <center>–</center> || Valued as “true” or “false”
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<negationInd value="false"/>

<deceasedInd value="true"/>

</syntaxhighlight>

In some situations, the BL data does not apply to an XML element, but an attribute. In that case, the attribute carries the Boolean value directly.
<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<support contextConductionInd ="false">
...
</support>
</syntaxhighlight>

=== Instance Identifier (II) ===

This data type identifies instances of classes like observations or entities (persons, organizations). Attributes are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@extension''' || <center>ST</center> || <center>O</center> || Identification
|-
| '''@root''' || <center>OID</center> || <center>R</center> || Source of identification
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id extension="13234453645" root="2.16.840.1.113883.2.6.15.3.427.1"/>
</syntaxhighlight>

The ''@root'' attribute is of type OID (object identifier), a unique identifier of the issuing authority or system. For example, a patient with a patient number 13234453645 created by a specific healthcare provider organization is uniquely identified by the number itself in ''@extension'' and the OID of the organization or the sending system, in the example 2.16.840.1.113883.2.6.15.3.427.1 in ''@root''.
In some cases, a single OID identifies an object uniquely. In that situation, only ''@root'' is populated and ''@extension'' is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Encapsulated Data (ED) ===

Elements of this data type carry multimedia content. The actual multimedia content is represented as element content. There are two situations for the use of ED:

* Inline: The full data is transmitted in the type. This form is mainly used for text.
* By reference: a thumbnail is provided which links to the full data by reference.

In an instance, the data type is normally determined by an ''xsi:type'' specification and some attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@mediaType''' || <center>CS</center> || <center>O</center> || MIME media type classification. At time of writing this specification, the following MIME types are allowed:
* text/plain (plain text)
* text/html (text with html markup)
* image/jpeg (JPEG image)
* application/pdf (a PDF, portable document format)
* application/hl7-sda+xml (CDA documents).
|-
| '''@representation''' || <center>CS</center> || <center>O</center> || Representation of the multimedia content. At time of writing this specification, the following representations are allowed:
* TXT (text, this is the default)
* B64 base 64 encoded data, for example for embedded CDA documents).
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<text xsi:type="ED" mediaType="text/plain">
Patient treated sucessfully
</text>

<text mediaType="application/hl7-sda+xml" representation="B64">PD94bWw..etc..==</text>

</syntaxhighlight>

To include referenced data the two sub elements ''thumbnail'' and ''reference'' are used.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''reference''' || <center>TEL</center> || <center>0..*</center> || <center>O</center> || Link (URI) to full data
|-
| '''thumbnail''' || <center>ED</center> || <center>0..*</center> || <center>O</center> || Thumbnail of referenced data
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value xsi:type="ED" mediaType="image/png" representation="B64">
<reference value="http://radiology.bergen.no/xrays/128s.png"/>
<thumbnail mediaType="image/jpeg" representation="B64"> MNY...83== </thumbnail>
</value>
</syntaxhighlight>

=== Strings (ST) ===

This data type is a specialization of the ED type where ''@mediaType'' is fixed “text/plain” and ''@representation'' is fixed “TXT”. It allows conveying a character string as '''element content'''. This data type is used in other data types it like the ''@extension'' in instance identifiers, or address and person name data type components.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<lotNumber> 143GT6DT </lotNumber>
</syntaxhighlight>

=== Concept Descriptor (CD) ===

This data type specifies a concept by means of a code and its code system (except for situations where no code is available). A couple of specializations of data type CD exist, which differ in the main characteristics (properties) of the data type that may or may not be supported.

{| class="hl7table" style="width:50%"
|+<ref group="Table">Properties of data types used for codes</ref> ''Properties of data types used for codes''
! <div style="text-align: right">DataType</div> !! CD !! CE !! CV !! CO !! CS
|-
! <div style="text-align: left">Property</div> !! !! !! !! !!
|-
| '''@code''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||<center>X</center>
|-
| '''@codeSystem''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''@codeSystemVersion''' || <center>X</center> || <center>X</center> || <center>X</center>|| <center>X</center> ||
|-
| '''@displayName''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''originalText''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''translation''' || <center>X</center> || <center>X</center> || || ||
|-
| '''qualifier''' || <center>X</center> || || || ||
|}

Because the CE variant is most used in practice, the general explanation of the properties will be given with de description of CE (see below).

The only attribute that is unique to CD is briefly explained here.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@qualifier''' || <center>CR</center> || <center>O</center> || An additional qualifier for the code.
|}

Complex terminologies like SNOMED CT can be used only using data type CD.

=== Coded with Equivalents (CE) ===

With elements of this data type, a concept by means of a code and its coding system (except for situations where no code is available) can be specified. It optionally contains one or more equivalents using other code systems.
It may contain the following attributes:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@code''' || <center>ST</center> || <center>R</center> || The actual code
|-
| '''@codeSystem''' || <center>OID</center> || <center>R</center> || required to identify the code system were the code is drawn from. This is an OID (object identifier, see [[#Object_Identifiers_.28OIDs.29|Object Identifiers at 4.1]])
|-
| '''@displayName''' || <center>ST</center> || <center>O</center> || Optional textual representation of code. A display name may be specified representing the plain text of the code. The information of this attribute may not be used by the receiving system for interpretation, but only for display purposes. The display name may never be transmitted without a code and must have the same meaning as the code.
|-
| '''@codeSystemName''' || <center>ST</center> || <center>O</center> || A textual representation of the name of the code system
|-
| '''@codeSystemVersion''' || <center>ST</center> || <center>O</center> || A textual representation of the version of the code system
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"/>

<code code="AU" codeSystem="2.16.840.1.113883.5.33"/>

<storageCode code="AC" codeSystem="2.16.840.1.113883.5.34" displayName="active"/>

<code code="A45.0" displayName="Somatisierungsstörung" codeSystem="1.2.276.0.76.5.409" codeSystemName="ICD-10 GM 2012"/>
</syntaxhighlight>

There are some child elements of codes that can be used to express what the “original text” was that was used for the coding or to indicate that there are “translations” to other code systems than the primary code.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''originalText''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Textual representation of the concept, actually a description which was used to create the actual code
|}

No semantics may be assumed other than showing the ''@displayName'' to a user to clarify the code. A display name cannot occur without its code and must carry the same meaning.

In case no code is known, it is allowed to specify a ''@nullFlavor'' for the code element and to give information about the (not yet coded) concept in original text. However, this should be an exception.

If other codes than the primary code need to be conveyed adding a translation child element can be used.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<originalText>minor aphthous stomatitis</originalText>
</code>
</syntaxhighlight>

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''translation''' || <center>CD</center> || <center>0..*</center> || <center>O</center> || Alternative code(s)
|}

A ''translation'' element is also of type CD and shall have a code and a code system identified. It shall point to the same concept as the primary code. It is allowed that a translation conveys less conceptual details than the original code.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<translation code="528.2" codeSystem="2.16.840.1.113883.6.2" codeSystemName="ICD9" displayName="Oral aphthae"/>
</code>
</syntaxhighlight>

=== Coded Value (CV) ===

This is actually a specialization of CE (see above), with the exception that neither ''originalText'' nor ''translation'' child element are allowed.

=== Coded Simple Value (CS) ===

This is actually a specialization of CE (see above), with no code system attribute and no original text or translation child element allowed. It specifies a concept by means of a code from a ''predefined'' code system (table) where the code is drawn from. This data type is usually applied in the context of fixed predefined HL7 tables.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<statusCode code="completed"/>
</syntaxhighlight>

In this example ''statusCode'' is bound in the underlying model to the specific code system ''ActStatus''. Because it is predefined by means of the vocabulary binding, ''@codeSystem'' is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Telecommunication Address (TEL) ===

Elements of this type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>ST</center> || <center>R</center> || carries strings that represent telecommunication contact information
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

The actual data is preceded by the scheme (refer to Internet Standard “RFC 1738 Uniform Resource Locators (URL)” <ref>RFC 1738 Uniform Resource Locators (URL): http://www.ietf.org/rfc/rfc1738.txt</ref>.

Examples:
* telephone (tel:),
* fax (fax:),
* email (mailto:).

It must follow the rules defined in Internet “RFC 2806 URLs for Telephone Calls” <ref>RFC 2806 URLs for Telephone Calls: http://www.ietf.org/rfc/rfc2806.txt</ref>.

The following codes will be used in the “use” attribute:
* H – Home
* WP – Work
* MC can be used (in addition to H or WP) to denote that this is a mobile phone.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257" />

<telecom use="H" value="tel:55354257" />

<telecom use="H" value="fax:56542558" />

<telecom value="tel:+41.34.21.4765342"/>

<telecom value="mailto:opr@opr-sem.no"/>

<telecom use="WP MC" value="tel:97555786" />
</syntaxhighlight>

It is possible to express the useable period of a telecommunication contact. A child element ''useablePeriod'' is used as a time interval to indicate this period.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''useablePeriod''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257">
<useablePeriod>
<high value="20111201"/>
</useablePeriod>
</telecom>
</syntaxhighlight>

=== Postal Address (AD) ===

Elements of this data type have a substructure in order to represent a structured address specification. In this implementation guide only a selection of all possible child elements is allowed, the original HL7 specification is richer.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''streetAddressLine''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Street address, includes street name and house number
|-
| '''city''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || City
|-
| '''postalCode''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Postal code
|-
| '''country''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Country
|-
|}

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that the sequence of the sub elements is country specific, i.e. it has to follow “common” rules how to write an address. For example, an UK address and a German address have different sequences of address representation.
|}

A ''@use'' attribute can also be specified.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="WP">
<streetAddressLine>Anna-Louisa-Karsch-Str. 2</streetAddressLine>
<postalCode>10178</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="H WP">
<streetAddressLine>Tatungasse 34</streetAddressLine>
<postalCode>10825</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

Also, a country may be specified using the element ''country''.

=== Person Name (PN) ===

Elements of this data type do also have a substructure to represent the parts of a person name, like family or given name and prefixes.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>
<given>Franz</given>
<given>Ingrun</given>
<family>Nordmann</family>
</name>
</syntaxhighlight>

Previous or birth or maiden names are supported using the ''validTime'' element. ''validTime'' (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]]) specifies the validity range of the name.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">

<name>
<given>Jan</given>
<given>Olaf</given>
<family>Hendrikson</family>
<validTime>
<high value="20000101"/>
</validTime>
</name>
</syntaxhighlight>

Note that the name attribute is repeating, i.e. multiple (types of) names could be sent. It is up to the receiver (based on the value of the ''@use'' attribute, and ''validTime'') to decide what name it wants to use or import in its database.

=== Organisation Name (ON) ===

Elements of this data type represent a name of an organization.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name> Charité Berlin </name>
</syntaxhighlight>

The optional ''validTime'' element (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]] may be used to specify the validity range of the name of the organization.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name of the organization
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>The old hospital
<validTime>
<high value="20111231235959"/>
</validTime>
</name>
</syntaxhighlight>

Please note that the use of ''validTime'' yields XML mixed content which should be avoid-ed if possible.

=== Integer Number (INT) ===

Elements of this data type are used to specify integer numbers and have one attribute.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>int</center> || <center>R</center> || Integer value
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<sequenceNumber value="24"/>
</syntaxhighlight>

=== Physical Quantities (PQ) ===

Elements of this data type are physical quantities, i.e. a measurable quantity (or countable) value from the physical world. This is different from just a “number”, because there is a (natural) unit specified in which the measurable quantity is expressed.
Examples:
* an amount of blood 20 ml (sample volume)
* a cut with a length of 10 cm (result observation)
* a dose of 200 milligrams per administration (dosing)
* delivery of 60 pieces of a tablet (amount supplied).
Elements of this data type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>real</center> || <center>R</center> || value of the measurement
|-
| '''@unit''' || <center>CS</center> || <center>R</center> || unit of measurement
|}

In the unit of measurement unit is expressed following the ''Unified Code for Units of Measure'' (UCUM) specification. This specification is a collection of atomic units, prefixes and a corresponding grammar for valid combinations to build all-natural units of measurement. For a complete description of possible units, see the ''Unified Code for Units of Measure'' <ref>Unified Code for Units of Measure: http://unitsofmeasure.org/</ref> specification.
If a value is not countable or if measurable, for example expressed in milligrams or liters, then this unit is a valid UCUM unit like “mg” or “L”. If a value is countable, for example the number of tablets, then this attribute contains “1”.
In HL7 it is required that all PQ data type units are valid UCUM units.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<value value="165" unit="cm"/>

<value value="81.1" unit="kg"/>

<value value="120" unit="mm[Hg]"/>

<value value="5" unit="1"/>
</syntaxhighlight>

=== Point in Time (TS) ===

Elements of this data type have the attribute

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>TS</center> || <center>R</center> || Point in time
|}

and specify points in time in the format YYYYMMDDhhmmss±ZZZZ, where
* YYYY is the four-digit year,
* MM the two-digit month,
* DD the two-digit day,
* hh the two-digit hour,
* mm the two-digits minute and
* ss the two-digit second.
Optional a time zone ZZZZ, the four-digit time alignment with a preceding “-” or a “+” can be specified. If time zone is omitted, local time is assumed.
The point in time may be right truncated in respect to the precision of the information.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<effectiveTime value="20140412"/>

<effectiveTime value="201409091245"/>

<effectiveTime value="1996"/>

<birthTime value="19540714"/>

<effectiveTime value="20140412+0100"/>
</syntaxhighlight>

=== Intervals (IVL) ===

Intervals are defined only for data types with an ordinal or interval scale type. There are several possibilities to determine an interval (see Figure 2), for example to specify

* a lower <low> and an upper boundary <high> (a),
* a lower <low> boundary and width <width> (b)
* an upper boundary and width <width> (c) or
* the middle of the interval <nowiki><center></nowiki> and a width <width> (d).

[[File:CDA_Core_Principles_Figure_2_Determining_Intervals.png|700px]]

<ref group="Figure">Several possibilities to determine closed intervals</ref> ''Several possibilities to determine closed intervals''

{{ConstraintBox|
To indicate an interval, only the following combinations are permitted.
(1) A lower and an upper boundary may not be identical, and their accuracy has to be equal.

Correct examples:

{{BeginGreenBox|}}
Interval from 5 to 6
Interval from 20110607 until 20110612
{{EndGreenBox}}

Incorrect examples:

{{BeginRedBox|}}
Interval from 5 to 6.0
Interval from 20110101 to 2011
{{EndRedBox|}}

(2) A lower boundary and a width

(3) A lower limit boundary

(4) A upper limit boundary

(5) Only the middle of the interval

(6) Only the width of an interval}}

Accordingly, four child elements are available.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Lower boundary
|-
| '''high''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Upper boundary
|-
| '''center''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Where ''(T)'' is defined in this specification as one of the data types “TS” or “PQ”.

=== Interval of time (IVL_TS) ===

Elements of this data type represent time intervals. There are four possible child elements.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Lower boundary (start date/time)
|-
| '''high''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Upper boundary (end date/time)
|-
| '''center''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Normally, a lower and an upper boundary is given, both are points in time. Also, it is possible to specify open intervals like “since June 14, 1999” (left boundary given only) or “until September 24, 2006” (right boundary given).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110507"/>
<high value="20110909"/>
</effectiveTime>

<effectiveTime>
<low value="20110507"/>
</effectiveTime>

<value>
<low value="20110101"/>
<width value="120" unit="d"/>
</value>

<value>
<center value="20110101"/>
</value>
</syntaxhighlight>

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|It must be noted that intervals of time stamps in HL7 are equally treated as other interval types (e.g. integers). The statement, one may take 1–3 tablets (interval of integers), for example, says that you are allowed to take no more than three tablets, not 3½ or 3.5 tablets. On the other hand, when treat the words “until 12 June 2011” regarding the upper interval limit differently, particularly we assume that the entire day 12 June is still in-cluded in this time interval.
Thus, in human perception time intervals are handled differently com-pared to such as number intervals. This is a situation may lead to inconsist-encies in standardized communication. As a conclusion, an upper limit “12 June 2011” means that only the very first moment of the 12 June is included in the interval, but not, for example, the 12 June 13:00 hours.
Interpretation does not depend on the accuracy of the time:
* “after 2004” means “from January 1, 2005 00:00:00.000”,
* “after 20041201” means “from 2 December 2004 00:00:00.000 hours”,
* and “after 200412011200” means “from 1 December 2004 12:01:00.000”.

As a result, you have to carefully consider the specification and implemen-tation of time intervals upper boundaries. In order to prevent mis-understandings intervals are always specified with the date and time for an upper limit that would cover the whole day. Accordingly, “201106122359” means 12 June 2011 throughout the day.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="201106122359"/>
</effectiveTime>
</syntaxhighlight>

Because of the equal treatment of time intervals this is applied also to the lower limit boundaries of time intervals as “0000”. This means for example that “since 9 June 2011” is expressed as “201106090000”.
|}

The <width> element is of data type PQ (physical quantity). The value obviously shall relate to a period of time and it is required to include a “time” unit. These are the units “us” (microseconds), “ms” (milliseconds), “s” (seconds), “min” (minute), “h” (hours), “d” (day), “wk” (week), “mo” (month) and “a” (year).

{{ConstraintBox|
For interval of time stamps the @unit of a ''low'' or ''high'' child element shall use units
* us (microseconds),
* ms (milliseconds),
* s (seconds),
* min (minute),
* h (hours),
* d (day),
* wk (week),
* mo (month) or
* a (year).
}}

=== Interval of physical quantities (IVL_PQ) ===

Elements of this data type are used to indicate intervals of physical quantities (see also [[#Physical Quantities (PQ)|3.18 Physical Quantities (PQ)]]). In general, an upper and a lower boundary is specified. It is also possible to use ''center'' instead of ''low'' and ''high''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low || <center>TS</center> || <center>0..1</center> || <center>C</center> || the lower limit of the interval (i.e. the minimum amount).
|-
| '''high || <center>TS</center> || <center>0..1</center> || <center>C</center> || the upper limit of the interval (i.e. the maximum amount).
|-
| '''center || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of the interval
|}

The ''center'' child element is used when there is no interval, but an exact value. Alternative would be to demote IVL_PQ to data type PQ and populate the element’s ''@value'' attribute, but this is more difficult to process in XML. That is why the use of the ''center'' child element is deprecated.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<referenceRange>
<low value="7.5" unit="mmol/l"/>
<high value="10" unit="mmol/l"/>
</referenceRange>

<doseQuantity>
<center value="9" unit="1"/>
</doseQuantity>
</syntaxhighlight>

=== Ratio of quantities (RTO_QTY_QTY) ===

Elements of this data type specify ratios and have two child elements, a numerator and a denominator. The underlying QTY (Quantity) data type is an abstract data type and in a XML instance it has to be replaced by a specific data type using the ''@xsi:type'' instruction (see below).

In this specification only “PQ” or “INT” are allowed for the demotion of both ''numerator'' and ''denominator''. The relevant child elements are:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''numerator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the numerator of the ratio
|-
| '''denominator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the denominator of the ratio
|}

If a model attribute already is a RTO_QTY_QTY, you need to specify (demote) the OTY abstract data type for both ''numerator'' and ''denominator'' by using an ''@xsi:type'' instruction.
In some cases where the model attribute is of type “ANY”, also the root element shall carry an ''@xsi:type'' RTO_QTY_QTY instruction.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<maxDoseQuantity>
<numerator xsi:type="PQ" value="6"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="400" unit="mg"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="5"/>
<denominator xsi:type="PQ" value="1" unit="h"/>
</maxDoseQuantity>

<value xsi:type="RTO_QTY_QTY">
<numerator xsi:type="INT" value="1"/>
<denominator xsi:type="INT" value="10000"/>
</value>
</syntaxhighlight>

== Identification mechanisms ==

=== Object Identifiers (OIDs) ===

Standardized exchange of information using messages or documents also deals with unique identifications of objects and concepts, especially in environments where sender and receiver do not “know” each other necessarily.

It is important to understand the difference between identification of instances (ids) and code concepts (classifications). Within the context of HL7 interactions OIDs are quite often used.
An id points to a specific instance of an object or identification scheme (a particular methodology for the identification of a class of objects), for example a specific person as the patient or a physician, a specific lab observation or an X-ray photo.

In contrast to instance identifiers, a classification identifies a specific concept. The type of patient (inpatient, outpatient), the type of doctor (an anesthesiologist), the codes for gender or a lab observation (blood cell count) may serve as examples.

OIDs (object identifiers) are worldwide unique identifiers for objects. They are used in HL7 to specify identifications and classifications. An object in this sense is persistent, well-defined information, definitions or specifications and is represented with ids or codes.

Commonly used OIDs (i.e. used for a purpose that is wider in scope than the regional healthcare organization; used in communications between healthcare regions) can be found in OIDs registries such as

* [http://www.oid-info.com www.oid-info.com],
* [http://www.hl7.org www.hl7.org],
* [http://www.hl7.org.uk/version3group/oids.asp HL7 OID registry in the UK],
* [https://www.dimdi.de/dynamic/de/klassifikationen/weitere-klassifikationen-und-standards/oid/ OID registry Germany].

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|All OIDs with an element of 999 or 9999 are for documentation purposes only. They will be replaced by permanent OIDs once these have been as-signed/found/applied for.
|}

OID (Object Identifiers) are unique identifiers for any kind of objects. They are defined in Rec. ITU-T X.660 | ISO/IEC 9834-1. This identification system for objects and concepts makes reliable electronic information exchange possible. Administration and Registration is regulated by a set of rules, described in the corresponding chapter of this document.

Every artefact in ART-DECOR has an Object Identifier (OID). There are recommendations for the management and the exchange of Object Identifiers, partially defined in ISO TS 13582 <ref>ISO TS 13582: https://www.iso.org/standard/69652.html</ref>.

''HL7 International'' has created a type ontology for the OIDs in the HL7 registry to make it easier for the user community to search for OIDs they may be looking for and can be found at hl7.org.

From a policy perspective it is common practice in several healthcare related OID registries (HL7 International at http://www.hl7.org, OID Registry Germany at http://www.dimdi.de, OID registry Switzerland at http://oid.refdata.ch, and OID registry Austria at https://www.gesundheit.gv.at/OID_Frontend) to distinguish at least between the following types of OIDs:

{| class="hl7table" style="width:60%"
|+<ref group="Table">Recommended OID sub-branches for different artefacts</ref> ''Recommended OID sub-branches for different artefacts''
! Arc !! Description
|-
| .3 || organizational bodies and groups
|-
| .4 || identifier systems and namespaces
|-
| .5 || code systems
|-
| .7 || document artefacts
|-
| .9 || conformance profiles
|-
| .10 || templates
|-
| .11 || value sets
|-
| .19 || examples
|-
| .99 || experimental
|}

''Example: given that “your” root OID is 1.2.3.4.5, the first value set of your governance group is then to be 1.2.3.4.5.11.1, with .11 as the value set “branch” and the last .1 as the first artefact of that kind.''

In ART-DECOR a project typically is set into the .77 branch of a governance group. When setting up the project, the OID for that project also determines the artefact OIDs using throughout the ART-DECOR project. The following additional branches are used to distinguish between different OID types:

{| class="hl7table"
|+<ref group="Table">Recommended OID sub-branches for ART-DECOR projects</ref> ''Recommended OID sub-branches for different artefacts''
! Artefact code Description !! Recommended !! OID suffix
|-
| DS || dataset || .77.1
|-
| DE || dataset concept || .77.2
|-
| SC || scenario || .77.3
|-
| TR || transaction in scenario || .77.4
|-
| CS || code system || .77.5
|-
| IS || issue || .77.6
|-
| AC || actor in scenario || .77.7
|-
| CL || concept list in dataset || .77.8
|-
| EL || element in template || .77.9
|-
| TM || template || .77.10
|-
| VS || value set || .77.11
|-
| RL || rule for instances || .77.12
|-
| SX || test/example scenario || .77.18
|-
| EX || test/example instance || .77.19
|-
| QX || qualification test/example || .77.20
|-
| TX || test/example data element || .77.21
|-
| CM || community || .77.22
|-
| MP || concept map || .77.24
|}

In ART-DECOR a newly created project uses these OID branches automatically.

=== Instance identification ===

Instance identification is done with the id element of a class. Its type is II (instance identifier) and described in the data type section above. For example, a patient number can be represented as
* 2.16.578.1.34.1.5432.1, the root-OID of the issuing authority, for example a system/application in a hospital, and
* 67543242 as the ''@extension'', representing the patient number within the system defined by the ''@root'' attribute.

=== Coding scheme identification ===

Coding schemes have to be uniquely identified using OIDs as well. All coding tables used in this implementation guide show the corresponding OID that has to be specified in the ''@codeSystem'' attribute of coded elements. Both attributes ''@code'' and ''@codeSystem'' together allows a correct interpretation of concept and code.

=== List of identification schemes ===

The following are OIDs for commonly used identification schemes.

{| class="hl7table"
|+<ref group="Table">Commonly used identification scheme OIDs</ref> ''Commonly used identification scheme OIDs''
! OID !! Identification System Name !! Description !! Issuer
|-
| 1.2.276.0.76.4.8 || KV-Nummer || Krankenversichertennummer ||
|-
| 1.2.276.0.76.4.17 || BSNR || Betriebsstättennummer ||
|-
| 1.2.276.0.76.4.16 || LANR || lebenslange Arztnummer ||
|}

=== List of code systems ===

The following are OIDs for code systems.

{| class="hl7table"
|+<ref group="Table">Commonly used code system OIDs</ref> ''Commonly used code system OIDs''
! OID !! Code System Name !! Description !! Issuer
|-
| 2.16.840.1.113883.6.1 || LOINC || Logical Observation Identifiers Names and Codes (LOINC) || Regenstrief Institute
|-
| 2.16.840.1.113883.6.96 || SNOMED CT || Systemized Nomenclature in Medicine Reference Terminology (SNOMED CT) || SNOMED International
|-
| 1.0.3166.1.2 || ISO 3166-1 (second edition) || Country codes as per ISO 3166-1:2007 || ISO
|}

== Vocabulary ==

=== Code Systems ===

Within HL7, a ''Code System'' is defined as a collection of codes with associated designations and meanings. Examples of code systems include ICD-10, SNOMED CT, and LOINC.
To meet the requirements of a code system as defined by HL7, a given code must resolve to one and only one meaning within the code system. Given this definition, each code table in the HL7 Version 3 standard represents a different code system since codes are sometimes used in different tables to have different meanings.
For example, “M” in the administrative gender table (''AdministrativeGender'', OID 2.16.840.1.113883.5.1) means “male”, while “M” in the marital status table (''MaritalStatus'', OID 2.16.840.1.113883.5.2) means “married”.
In this specification, code system tables are not presented in detail.

=== Value Sets ===

A ''Value Set'' represents a uniquely identifiable set of valid concept representations, where any concept representation can be tested to determine whether or not it is a member of the value set.
Value set complexity may range from a simple flat list of concept codes drawn from a single code system, to an unbounded hierarchical set of possibly post-coordinated expressions drawn from multiple code systems.
Value sets exist to constrain the content for a coded element in an HL7 static model or data type property. Value sets cannot have null content and must contain at least one concept representation where any given concept is generally (but not required to be) represented by only a single code within the Value Set.

[[File:CDA_Core_Principles_Figure_3_ValueSet_Example.png|800px]]

<ref group="Figure">Example presentation of the value set “MaritalStatus”</ref> ''Example presentation of the value set “MaritalStatus”''

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that value set OIDs never appear in a CDA Release 2 document. They are used for constraint expressions, for example in implementation guides.
In order to send a specific code drawn from a value set, the corresponding code system has to be conveyed.
An example, in the implementation specification the constraint on the model element ''maritalStatusCode'' is expressed as “to be drawn from value set 2.16.840.1.113883.5.2 ''MaritalStatus''”.
To actually send a marital status of “M” (married) that is shown in the value set figure above, the corresponding HL7 CDA instance would say:
<syntaxhighlight lang="xml">
<maritalStatusCode code="M" codeSystem="2.16.840.1.113883.5.2"/>
</syntaxhighlight>
|}

In this specification, value set tables are not presented in detail.

==== Binding strength ====

There is an optional vocabulary strength for data types that support that feature (coded concepts). Examples include CD, CE, CV and CO. Values are required, extensible, preferred and example. Default is required.

Please note: the formerly supported values CNE (Coded No Extensibility) and CWE (Coded With Extensibility) in ART-DECOR are deprecated as of December 2017. Specification CNE is handled as required and CWE is handled as extensible.

{| class="hl7table"
|+<ref group="Table">Binding Strengths</ref> ''Binding Strengths''
! Strength !! Description
|-
|required||Required/CNE. Coded with no exceptions; this element SHALL be from the specified value set
|-
|extensible||Extensible/CWE. Coded with Exceptions; this element SHALL be from the specified value set if any of the codes within the value set can apply to the concept being communicated. If the value set does not cover the concept (based on human review), alternate codings (or, data type allowing, text) may be included instead.
|-
|preferred||Preferred. Instances are encouraged to draw from the specified codes for interoperability purposes but are not required to do so to be considered conformant.
|-
|example||Example. Instances are not expected or even encouraged to draw from the specified value set. The value set merely provides examples of the types of concepts intended to be included.
|}

Mismatches with required lead to validation errors (SHALL logic). Mismatches with extensible lead to validation warnings (SHOULD logic). Mismatches with preferred lead to validation information messages (MAY logic). Mismatches with example don't have any validation consequences.

== Appendix ==

=== References ===

<references/>

=== List of figures ===

<references group="Figure" />

=== List of tables ===

<references group="Table" />

HL7 CDA Core Principles

2019-06-16T11:00:41Z

Dammon: /* XML representation of data types */

== Introduction ==

This implementation guide specifies the ''Core Principles'' of using the ''Clinical Document Architecture'' <ref>Clinical Document Architecture Release 2: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=7</ref>.

=== Scope ===

This guide focuses on ''Data Types Release 1'' <ref>HL7 Data Types Release 1: http://www.hl7.org</ref>. Meanwhile an ISO specification ISO 21090 is out, also known as Data Type Release 2. The latter is subject to another implementation guide that will be published when ISO data types are used.

=== Focus of this document: HL7 Version 3 Data Types for CDA ===

The following chapters of this document will focus on the description of the data types and associated material. It will highlight the essentials in four chapters, all focusing on the Norwegian situation.
* '''Common aspects:''' explains common aspects of use of CDA and XML
* '''Data types:''' gives an overview and detailed specification of all data types used in CDA
* '''Identification schemes:''' explains major aspects of identification and the use in CDA
* '''Use of vocabulary:''' explains major aspects of vocabulary use in CDA.

=== Background ===

In many (European) countries, implementation guides for the use of data types in HL7 V3 are published. They take into account country specific constraints on the data types.

=== Legend of symbols ===

In this document several symbols are used.

{| class="hl7table" style="width:50%"
| [[File:Pfeil_rechts.png|50px]] || This is an important item
|-
| [[File:Issue.svg|50px]] || This is a known open issue
|-
| [[File:Faq.svg|50px]] || This is a frequently asked question (FAQ) with answer
|-
| [[File:Conformance.svg|50px]] || This is a constraint; in some situations also the rule identification is specified, e.g. dtr1-1-ANY, which links to the corresponding validation rule.
|}

=== Version history ===

{| class="hl7table" style="width:50%"
|+
! Version !! Date !! Description !! Author
|-
| 1.1 || 2019-04-24 || Refurbished guide based on earlier work || Kai U. Heitmann
|}

== Common aspects ==

=== Use of XML ===

HL7 Version 3 CDA uses the Extensible Markup Language (XML) as the exchange format. It is assumed that the reader is familiar with common XML aspects. However, some constraints are made regarding the use of CDA.

==== Character Set ====

{{ConstraintBox|
The character encoding of any CDA document shall be “UTF-8”.}}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="utf-8"?>
</syntaxhighlight>

=== CDA document structure ===

The XML namespace for CDA Release 2 documents is ''<nowiki>urn:hl7-org:v3</nowiki>''. This must be correctly mentioned in every XML instance.

CDA XML documents starts with the root element ''ClinicalDocument''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">


...

<component>
<structuredBody>
...
</structuredBody>
</component>

</ClinicalDocument>
</syntaxhighlight>

== Data types ==

=== Introduction ===

The following chapter describes the typical data types used in CDA implementation guides. For further information please refer to the HL7 V3 standard and its two parts concerning data types:
* Abstract Data type definition <ref>HL7 Version 3 Abstract Data type definition: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=264</ref>
* XML ITS for data types <ref>XML ITS for data types: https://www.hl7.org/documentcenter/public_temp_682D4D16-1C23-BA17-0C789BA52BEDB68E/wg/inm/datatypes-its-xml20050714.htm</ref>
Data types are properties of model class attributes and the basic building blocks of information in a CDA XML instance. For example, a model attribute named “time” has as its data type a time stamp “TS” (see Figure 1).

[[File:CDA_Core_Principles_Figure_1_CDA_Structure_Data_Types.png|700px]]

<ref group="Figure">CDA structure (left) and the data type specification (right)</ref> ''CDA structure (left) and the data type specification (right)''

=== XML representation of data types ===

Actual data is mostly carried in HL7 Version 3 by populating XML attributes and not as element content. Exceptions are names of persons and organizations as well as addresses.

The XML elements have names like the model attributes. For example, a model attribute “id” has a corresponding XML element named <id…>. The model determines the sequence of elements and their hierarchy. The data type itself determines the XML attributes within the start tag. The notation here is as follows:

{| class="hl7table"
|+
! Attribute !! DT !! Conf !! Description
|-
| (name of the model attribute or XML element) || Data type || Conformance, i.e. O, R, M || Textual description
|}

XML attributes (data type properties) are denoted as ''@attribute'' in order to distinguish their names from XML elements.

Example: in the example model above, the data type of the ''id'' attribute's is ''II'' (Instance Identifier). The corresponding XML attributes for that data type include ''@root'' and ''@extension''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id root="..." extension="..." />
</syntaxhighlight>

A description of the data types and their corresponding XML representation is contained in subsequent paragraphs of this guide.

==== Exceptions using XML element content ====

For most data types, the actual data is conveyed in XML attributes. However, there are some exceptions. For the data types binary (BIN), Encapsulated Data (ED), Entity Name (EN), Person Name (PN), Organization Name (ON), Trivial Name (TN), Address (AD) and character string data (ST), information is carried as element content.

Example: the components of an address <addr> are represented by sub elements with the data as element content (in the example shown in black).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr>
<streetAddressLine>Thormøhlens gate 12</streetAddressLine>
<postalCode>5006</postalCode>
<city>Bergen</city>
</addr>
</syntaxhighlight>

==== Combined data types ====

There are a number of so-called combined data types. For example, an interval with a lower and upper limit and a ratio that has a nominator and a denominator value.

In combined data types the substructure (e.g. <low> <high> in an interval) are represented as child elements of the relevant data type element.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110701"/>
<high value="20110729"/>
</effectiveTime>
</syntaxhighlight>

==== Conformance information ====

The conformance indicators distinguish kinds of conformance information described shortly here.

* '''O''': An optional item may be omitted if no data is present, i.e. no corresponding XML attribute or element is sent (marked as “O”)
* '''R''': For required items, lower cardinality is always zero or 1.
** Elements must be present and populated with data if present in the sending system. If no data is available (yet), a null flavor (see below) indicates and possibly classifies the missing information (marked as R).
** Attribute flagged as required must be present in the instance and populated.
* '''M''': For mandatory elements data must be sent and no missing values are allowed, i.e. if the sending system does not have information for mandatory elements the XML instance cannot be created and sent (marked as M).
* '''NP''': no data may be present at all (not permitted)
* '''C''': conditional conformance; typically a conformance table shows the circumstances (conditions) derived from information in the instance and the corresponding cardinalities and conformance statements.

=== Missing values (null flavor) ===

For every data type it is possible to specify a missing value including a kind of reason why data is missing. Instead of specifying any attribute of the corresponding element, a ''@nullFlavor'' attribute expresses the omission of data. Note that missing data is not allowed for mandatory elements (see above).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value nullFlavor="OTH"/>

<code nullFlavor="UNK"/>

<booleanInd nullFlavor="NI"/>

</syntaxhighlight>

The codes for the ''@nullFlavor'' attribute are drawn from the following hierarchical code system. It is a Coded Simple (CS), which means it has no code system (attribute ''@codeSystem'') specified.

{| class="hl7table"
|+<ref group="Table">NullFlavor</ref> ''NullFlavor''
! Code
! width=15% | Print Name
! Definition / Description
|-
| NI || No Information || No information whatsoever can be inferred from this exceptional value. This is the most general exceptional value. It is also the default exceptional value.
|-
| OTH || other || The actual value is not an element in the value domain of a variable. (e.g., concept not provided by required code system).
|-
| NINF || negative infinity || Negative infinity of numbers.
|-
| PINF || positive infinity || Positive infinity of numbers.
|-
| UNK || unknown || A proper value is applicable, but not known.
|-
| ASKU || asked but unknown || Information was sought but not found (e.g., patient was asked but didn't know)
|-
| NAV || temporarily unavailable || Information is not available at this time but it is expected that it will be available later.
|-
| NASK || not asked || This information has not been sought (e.g., patient was not asked)
|-
| TRC || trace || The content is greater than zero, but too small to be quantified.
|-
| MSK || masked || There is information on this item available but it has not been provided by the sender due to security, privacy or other reasons. There may be an alternate mechanism for gaining access to this information.
Note: using this null flavour does provide information that may be a breach of confidentiality, even though no detail data is provided. Its primary purpose is for those circumstances where it is necessary to inform the receiver that the information does exist without providing any detail.
|-
| NA || not applicable || No proper value is applicable in this context (e.g., last menstrual period for a male).
|-
| NP || not present || Value is not present in a message. This is only defined in messages, never in application data! All values not present in the message must be replaced by the applicable default, or no-information (NI) as the default of all defaults.
|}

=== ANY as the generic data type ===

This abstract data type is the basis for all other data types. Not a single value within a CDA document has the effective data type ANY, but any data type within HL7v3 is a specialization of ANY. This also means that any other data type inherits all properties of ANY (see [[#Missing_values_.28null_flavor.29|“Missing values (null flavor)”]]).

The ANY type is occasionally found in HL7 models when it comes to clinical finding etc. where – at model time – the actual data type of the value is not known. At instantiation time however, the actual data type ''is'' known and ANY is always replaced by a particular data type in an instance.

One example is the observation value (child element value in an observation), where in the model the data type of value cannot be anticipated. When instantiation is taking place, the data type is specified by the XML instance attribute ''@xsi:type''. This information can be used by the receiver to validate and process the value.

Attributes of an element with this data type are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@nullFlavor''' || <center>CS</center> || <center>–</center> || Classification of the missing value, see [[#Missing_values_.28null_flavor.29|3.3 Missing values (null flavor)]].
|}

{| class="hl7table" style="width:100%"
| width=8% | <center>[[File:Conformance.svg|50px]] dtr1-1-ANY</center> || If there is a ''nullFlavor'', there shall be no other attribute or element, unless it's ''nullFlavor="OTH"''. In that case ''@codeSystem'' or ''originalText'' (see “code” data types) may have a value.
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">

<value xsi:type="CE" code="N11.9" codeSystem="2.16.840.1.113883.6.3"/>


<value xsi:type="PQ" value="12" unit="mL"/>


<value xsi:type="ED">this is text</value>
</syntaxhighlight>

=== Boolean (BL) ===

Elements of this data type refer to Boolean logic and have an attribute ''@value''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>BL</center> || <center>–</center> || Valued as “true” or “false”
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<negationInd value="false"/>

<deceasedInd value="true"/>

</syntaxhighlight>

In some situations, the BL data does not apply to an XML element, but an attribute. In that case, the attribute carries the Boolean value directly.
<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<support contextConductionInd ="false">
...
</support>
</syntaxhighlight>

=== Instance Identifier (II) ===

This data type identifies instances of classes like observations or entities (persons, organizations). Attributes are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@extension''' || <center>ST</center> || <center>O</center> || Identification
|-
| '''@root''' || <center>OID</center> || <center>R</center> || Source of identification
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id extension="13234453645" root="2.16.840.1.113883.2.6.15.3.427.1"/>
</syntaxhighlight>

The ''@root'' attribute is of type OID (object identifier), a unique identifier of the issuing authority or system. For example, a patient with a patient number 13234453645 created by a specific healthcare provider organization is uniquely identified by the number itself in ''@extension'' and the OID of the organization or the sending system, in the example 2.16.840.1.113883.2.6.15.3.427.1 in ''@root''.
In some cases, a single OID identifies an object uniquely. In that situation, only ''@root'' is populated and ''@extension'' is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Encapsulated Data (ED) ===

Elements of this data type carry multimedia content. The actual multimedia content is represented as element content. There are two situations for the use of ED:

* Inline: The full data is transmitted in the type. This form is mainly used for text.
* By reference: a thumbnail is provided which links to the full data by reference.

In an instance, the data type is normally determined by an ''xsi:type'' specification and some attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@mediaType''' || <center>CS</center> || <center>O</center> || MIME media type classification. At time of writing this specification, the following MIME types are allowed:
* text/plain (plain text)
* text/html (text with html markup)
* image/jpeg (JPEG image)
* application/pdf (a PDF, portable document format)
* application/hl7-sda+xml (CDA documents).
|-
| '''@representation''' || <center>CS</center> || <center>O</center> || Representation of the multimedia content. At time of writing this specification, the following representations are allowed:
* TXT (text, this is the default)
* B64 base 64 encoded data, for example for embedded CDA documents).
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<text xsi:type="ED" mediaType="text/plain">
Patient treated sucessfully
</text>

<text mediaType="application/hl7-sda+xml" representation="B64">PD94bWw..etc..==</text>

</syntaxhighlight>

To include referenced data the two sub elements ''thumbnail'' and ''reference'' are used.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''reference''' || <center>TEL</center> || <center>0..*</center> || <center>O</center> || Link (URI) to full data
|-
| '''thumbnail''' || <center>ED</center> || <center>0..*</center> || <center>O</center> || Thumbnail of referenced data
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value xsi:type="ED" mediaType="image/png" representation="B64">
<reference value="http://radiology.bergen.no/xrays/128s.png"/>
<thumbnail mediaType="image/jpeg" representation="B64"> MNY...83== </thumbnail>
</value>
</syntaxhighlight>

=== Strings (ST) ===

This data type is a specialization of the ED type where ''@mediaType'' is fixed “text/plain” and ''@representation'' is fixed “TXT”. It allows conveying a character string as '''element content'''. This data type is used in other data types it like the ''@extension'' in instance identifiers, or address and person name data type components.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<lotNumber> 143GT6DT </lotNumber>
</syntaxhighlight>

=== Concept Descriptor (CD) ===

This data type specifies a concept by means of a code and its code system (except for situations where no code is available). A couple of specializations of data type CD exist, which differ in the main characteristics (properties) of the data type that may or may not be supported.

{| class="hl7table" style="width:50%"
|+<ref group="Table">Properties of data types used for codes</ref> ''Properties of data types used for codes''
! <div style="text-align: right">DataType</div> !! CD !! CE !! CV !! CO !! CS
|-
! <div style="text-align: left">Property</div> !! !! !! !! !!
|-
| '''@code''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||<center>X</center>
|-
| '''@codeSystem''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''@codeSystemVersion''' || <center>X</center> || <center>X</center> || <center>X</center>|| <center>X</center> ||
|-
| '''@displayName''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''originalText''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''translation''' || <center>X</center> || <center>X</center> || || ||
|-
| '''qualifier''' || <center>X</center> || || || ||
|}

Because the CE variant is most used in practice, the general explanation of the properties will be given with de description of CE (see below).

The only attribute that is unique to CD is briefly explained here.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@qualifier''' || <center>CR</center> || <center>O</center> || An additional qualifier for the code.
|}

Complex terminologies like SNOMED CT can be used only using data type CD.

=== Coded with Equivalents (CE) ===

With elements of this data type, a concept by means of a code and its coding system (except for situations where no code is available) can be specified. It optionally contains one or more equivalents using other code systems.
It may contain the following attributes:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@code''' || <center>ST</center> || <center>R</center> || The actual code
|-
| '''@codeSystem''' || <center>OID</center> || <center>R</center> || required to identify the code system were the code is drawn from. This is an OID (object identifier, see [[#Object_Identifiers_.28OIDs.29|Object Identifiers at 4.1]])
|-
| '''@displayName''' || <center>ST</center> || <center>O</center> || Optional textual representation of code. A display name may be specified representing the plain text of the code. The information of this attribute may not be used by the receiving system for interpretation, but only for display purposes. The display name may never be transmitted without a code and must have the same meaning as the code.
|-
| '''@codeSystemName''' || <center>ST</center> || <center>O</center> || A textual representation of the name of the code system
|-
| '''@codeSystemVersion''' || <center>ST</center> || <center>O</center> || A textual representation of the version of the code system
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"/>

<code code="AU" codeSystem="2.16.840.1.113883.5.33"/>

<storageCode code="AC" codeSystem="2.16.840.1.113883.5.34" displayName="active"/>

<code code="A45.0" displayName="Somatisierungsstörung" codeSystem="1.2.276.0.76.5.409" codeSystemName="ICD-10 GM 2012"/>
</syntaxhighlight>

There are some child elements of codes that can be used to express what the “original text” was that was used for the coding or to indicate that there are “translations” to other code systems than the primary code.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''originalText''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Textual representation of the concept, actually a description which was used to create the actual code
|}

No semantics may be assumed other than showing the ''@displayName'' to a user to clarify the code. A display name cannot occur without its code and must carry the same meaning.

In case no code is known, it is allowed to specify a ''@nullFlavor'' for the code element and to give information about the (not yet coded) concept in original text. However, this should be an exception.

If other codes than the primary code need to be conveyed adding a translation child element can be used.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<originalText>minor aphthous stomatitis</originalText>
</code>
</syntaxhighlight>

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''translation''' || <center>CD</center> || <center>0..*</center> || <center>O</center> || Alternative code(s)
|}

A ''translation'' element is also of type CD and shall have a code and a code system identified. It shall point to the same concept as the primary code. It is allowed that a translation conveys less conceptual details than the original code.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<translation code="528.2" codeSystem="2.16.840.1.113883.6.2" codeSystemName="ICD9" displayName="Oral aphthae"/>
</code>
</syntaxhighlight>

=== Coded Value (CV) ===

This is actually a specialization of CE (see above), with the exception that neither ''originalText'' nor ''translation'' child element are allowed.

=== Coded Simple Value (CS) ===

This is actually a specialization of CE (see above), with no code system attribute and no original text or translation child element allowed. It specifies a concept by means of a code from a ''predefined'' code system (table) where the code is drawn from. This data type is usually applied in the context of fixed predefined HL7 tables.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<statusCode code="completed"/>
</syntaxhighlight>

In this example ''statusCode'' is bound in the underlying model to the specific code system ''ActStatus''. Because it is predefined by means of the vocabulary binding, ''@codeSystem'' is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Telecommunication Address (TEL) ===

Elements of this type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>ST</center> || <center>R</center> || carries strings that represent telecommunication contact information
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

The actual data is preceded by the scheme (refer to Internet Standard “RFC 1738 Uniform Resource Locators (URL)” <ref>RFC 1738 Uniform Resource Locators (URL): http://www.ietf.org/rfc/rfc1738.txt</ref>.

Examples:
* telephone (tel:),
* fax (fax:),
* email (mailto:).

It must follow the rules defined in Internet “RFC 2806 URLs for Telephone Calls” <ref>RFC 2806 URLs for Telephone Calls: http://www.ietf.org/rfc/rfc2806.txt</ref>.

The following codes will be used in the “use” attribute:
* H – Home
* WP – Work
* MC can be used (in addition to H or WP) to denote that this is a mobile phone.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257" />

<telecom use="H" value="tel:55354257" />

<telecom use="H" value="fax:56542558" />

<telecom value="tel:+41.34.21.4765342"/>

<telecom value="mailto:opr@opr-sem.no"/>

<telecom use="WP MC" value="tel:97555786" />
</syntaxhighlight>

It is possible to express the useable period of a telecommunication contact. A child element ''useablePeriod'' is used as a time interval to indicate this period.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''useablePeriod''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257">
<useablePeriod>
<high value="20111201"/>
</useablePeriod>
</telecom>
</syntaxhighlight>

=== Postal Address (AD) ===

Elements of this data type have a substructure in order to represent a structured address specification. In this implementation guide only a selection of all possible child elements is allowed, the original HL7 specification is richer.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''streetAddressLine''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Street address, includes street name and house number
|-
| '''city''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || City
|-
| '''postalCode''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Postal code
|-
| '''country''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Country
|-
|}

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that the sequence of the sub elements is country specific, i.e. it has to follow “common” rules how to write an address. For example, an UK address and a German address have different sequences of address representation.
|}

A ''@use'' attribute can also be specified.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="WP">
<streetAddressLine>Anna-Louisa-Karsch-Str. 2</streetAddressLine>
<postalCode>10178</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="H WP">
<streetAddressLine>Tatungasse 34</streetAddressLine>
<postalCode>10825</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

Also, a country may be specified using the element ''country''.

=== Person Name (PN) ===

Elements of this data type do also have a substructure to represent the parts of a person name, like family or given name and prefixes.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>
<given>Franz</given>
<given>Ingrun</given>
<family>Nordmann</family>
</name>
</syntaxhighlight>

Previous or birth or maiden names are supported using the ''validTime'' element. ''validTime'' (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]]) specifies the validity range of the name.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">

<name>
<given>Jan</given>
<given>Olaf</given>
<family>Hendrikson</family>
<validTime>
<high value="20000101"/>
</validTime>
</name>
</syntaxhighlight>

Note that the name attribute is repeating, i.e. multiple (types of) names could be sent. It is up to the receiver (based on the value of the ''@use'' attribute, and ''validTime'') to decide what name it wants to use or import in its database.

=== Organisation Name (ON) ===

Elements of this data type represent a name of an organization.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name> Charité Berlin </name>
</syntaxhighlight>

The optional ''validTime'' element (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]] may be used to specify the validity range of the name of the organization.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name of the organization
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>The old hospital
<validTime>
<high value="20111231235959"/>
</validTime>
</name>
</syntaxhighlight>

Please note that the use of ''validTime'' yields XML mixed content which should be avoid-ed if possible.

=== Integer Number (INT) ===

Elements of this data type are used to specify integer numbers and have one attribute.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>int</center> || <center>R</center> || Integer value
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<sequenceNumber value="24"/>
</syntaxhighlight>

=== Physical Quantities (PQ) ===

Elements of this data type are physical quantities, i.e. a measurable quantity (or countable) value from the physical world. This is different from just a “number”, because there is a (natural) unit specified in which the measurable quantity is expressed.
Examples:
* an amount of blood 20 ml (sample volume)
* a cut with a length of 10 cm (result observation)
* a dose of 200 milligrams per administration (dosing)
* delivery of 60 pieces of a tablet (amount supplied).
Elements of this data type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>real</center> || <center>R</center> || value of the measurement
|-
| '''@unit''' || <center>CS</center> || <center>R</center> || unit of measurement
|}

In the unit of measurement unit is expressed following the ''Unified Code for Units of Measure'' (UCUM) specification. This specification is a collection of atomic units, prefixes and a corresponding grammar for valid combinations to build all-natural units of measurement. For a complete description of possible units, see the ''Unified Code for Units of Measure'' <ref>Unified Code for Units of Measure: http://unitsofmeasure.org/</ref> specification.
If a value is not countable or if measurable, for example expressed in milligrams or liters, then this unit is a valid UCUM unit like “mg” or “L”. If a value is countable, for example the number of tablets, then this attribute contains “1”.
In HL7 it is required that all PQ data type units are valid UCUM units.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<value value="165" unit="cm"/>

<value value="81.1" unit="kg"/>

<value value="120" unit="mm[Hg]"/>

<value value="5" unit="1"/>
</syntaxhighlight>

=== Point in Time (TS) ===

Elements of this data type have the attribute

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>TS</center> || <center>R</center> || Point in time
|}

and specify points in time in the format YYYYMMDDhhmmss±ZZZZ, where
* YYYY is the four-digit year,
* MM the two-digit month,
* DD the two-digit day,
* hh the two-digit hour,
* mm the two-digits minute and
* ss the two-digit second.
Optional a time zone ZZZZ, the four-digit time alignment with a preceding “-” or a “+” can be specified. If time zone is omitted, local time is assumed.
The point in time may be right truncated in respect to the precision of the information.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<effectiveTime value="20140412"/>

<effectiveTime value="201409091245"/>

<effectiveTime value="1996"/>

<birthTime value="19540714"/>

<effectiveTime value="20140412+0100"/>
</syntaxhighlight>

=== Intervals (IVL) ===

Intervals are defined only for data types with an ordinal or interval scale type. There are several possibilities to determine an interval (see Figure 2), for example to specify

* a lower <low> and an upper boundary <high> (a),
* a lower <low> boundary and width <width> (b)
* an upper boundary and width <width> (c) or
* the middle of the interval <nowiki><center></nowiki> and a width <width> (d).

[[File:CDA_Core_Principles_Figure_2_Determining_Intervals.png|700px]]

<ref group="Figure">Several possibilities to determine closed intervals</ref> ''Several possibilities to determine closed intervals''

{{ConstraintBox|
To indicate an interval, only the following combinations are permitted.
(1) A lower and an upper boundary may not be identical, and their accuracy has to be equal.

Correct examples:

{{BeginGreenBox|}}
Interval from 5 to 6
Interval from 20110607 until 20110612
{{EndGreenBox}}

Incorrect examples:

{{BeginRedBox|}}
Interval from 5 to 6.0
Interval from 20110101 to 2011
{{EndRedBox|}}

(2) A lower boundary and a width

(3) A lower limit boundary

(4) A upper limit boundary

(5) Only the middle of the interval

(6) Only the width of an interval}}

Accordingly, four child elements are available.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Lower boundary
|-
| '''high''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Upper boundary
|-
| '''center''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Where ''(T)'' is defined in this specification as one of the data types “TS” or “PQ”.

=== Interval of time (IVL_TS) ===

Elements of this data type represent time intervals. There are four possible child elements.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Lower boundary (start date/time)
|-
| '''high''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Upper boundary (end date/time)
|-
| '''center''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Normally, a lower and an upper boundary is given, both are points in time. Also, it is possible to specify open intervals like “since June 14, 1999” (left boundary given only) or “until September 24, 2006” (right boundary given).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110507"/>
<high value="20110909"/>
</effectiveTime>

<effectiveTime>
<low value="20110507"/>
</effectiveTime>

<value>
<low value="20110101"/>
<width value="120" unit="d"/>
</value>

<value>
<center value="20110101"/>
</value>
</syntaxhighlight>

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|It must be noted that intervals of time stamps in HL7 are equally treated as other interval types (e.g. integers). The statement, one may take 1–3 tablets (interval of integers), for example, says that you are allowed to take no more than three tablets, not 3½ or 3.5 tablets. On the other hand, when treat the words “until 12 June 2011” regarding the upper interval limit differently, particularly we assume that the entire day 12 June is still in-cluded in this time interval.
Thus, in human perception time intervals are handled differently com-pared to such as number intervals. This is a situation may lead to inconsist-encies in standardized communication. As a conclusion, an upper limit “12 June 2011” means that only the very first moment of the 12 June is included in the interval, but not, for example, the 12 June 13:00 hours.
Interpretation does not depend on the accuracy of the time:
* “after 2004” means “from January 1, 2005 00:00:00.000”,
* “after 20041201” means “from 2 December 2004 00:00:00.000 hours”,
* and “after 200412011200” means “from 1 December 2004 12:01:00.000”.

As a result, you have to carefully consider the specification and implemen-tation of time intervals upper boundaries. In order to prevent mis-understandings intervals are always specified with the date and time for an upper limit that would cover the whole day. Accordingly, “201106122359” means 12 June 2011 throughout the day.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="201106122359"/>
</effectiveTime>
</syntaxhighlight>

Because of the equal treatment of time intervals this is applied also to the lower limit boundaries of time intervals as “0000”. This means for example that “since 9 June 2011” is expressed as “201106090000”.
|}

The <width> element is of data type PQ (physical quantity). The value obviously shall relate to a period of time and it is required to include a “time” unit. These are the units “us” (microseconds), “ms” (milliseconds), “s” (seconds), “min” (minute), “h” (hours), “d” (day), “wk” (week), “mo” (month) and “a” (year).

{{ConstraintBox|
For interval of time stamps the @unit of a ''low'' or ''high'' child element shall use units
* us (microseconds),
* ms (milliseconds),
* s (seconds),
* min (minute),
* h (hours),
* d (day),
* wk (week),
* mo (month) or
* a (year).
}}

=== Interval of physical quantities (IVL_PQ) ===

Elements of this data type are used to indicate intervals of physical quantities (see also [[#Physical Quantities (PQ)|3.18 Physical Quantities (PQ)]]). In general, an upper and a lower boundary is specified. It is also possible to use ''center'' instead of ''low'' and ''high''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low || <center>TS</center> || <center>0..1</center> || <center>C</center> || the lower limit of the interval (i.e. the minimum amount).
|-
| '''high || <center>TS</center> || <center>0..1</center> || <center>C</center> || the upper limit of the interval (i.e. the maximum amount).
|-
| '''center || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of the interval
|}

The ''center'' child element is used when there is no interval, but an exact value. Alternative would be to demote IVL_PQ to data type PQ and populate the element’s ''@value'' attribute, but this is more difficult to process in XML. That is why the use of the ''center'' child element is deprecated.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<referenceRange>
<low value="7.5" unit="mmol/l"/>
<high value="10" unit="mmol/l"/>
</referenceRange>

<doseQuantity>
<center value="9" unit="1"/>
</doseQuantity>
</syntaxhighlight>

=== Ratio of quantities (RTO_QTY_QTY) ===

Elements of this data type specify ratios and have two child elements, a numerator and a denominator. The underlying QTY (Quantity) data type is an abstract data type and in a XML instance it has to be replaced by a specific data type using the ''@xsi:type'' instruction (see below).

In this specification only “PQ” or “INT” are allowed for the demotion of both ''numerator'' and ''denominator''. The relevant child elements are:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''numerator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the numerator of the ratio
|-
| '''denominator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the denominator of the ratio
|}

If a model attribute already is a RTO_QTY_QTY, you need to specify (demote) the OTY abstract data type for both ''numerator'' and ''denominator'' by using an ''@xsi:type'' instruction.
In some cases where the model attribute is of type “ANY”, also the root element shall carry an ''@xsi:type'' RTO_QTY_QTY instruction.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<maxDoseQuantity>
<numerator xsi:type="PQ" value="6"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="400" unit="mg"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="5"/>
<denominator xsi:type="PQ" value="1" unit="h"/>
</maxDoseQuantity>

<value xsi:type="RTO_QTY_QTY">
<numerator xsi:type="INT" value="1"/>
<denominator xsi:type="INT" value="10000"/>
</value>
</syntaxhighlight>

== Identification mechanisms ==

=== Object Identifiers (OIDs) ===

Standardized exchange of information using messages or documents also deals with unique identifications of objects and concepts, especially in environments where sender and receiver do not “know” each other necessarily.

It is important to understand the difference between identification of instances (ids) and code concepts (classifications). Within the context of HL7 interactions OIDs are quite often used.
An id points to a specific instance of an object or identification scheme (a particular methodology for the identification of a class of objects), for example a specific person as the patient or a physician, a specific lab observation or an X-ray photo.

In contrast to instance identifiers, a classification identifies a specific concept. The type of patient (inpatient, outpatient), the type of doctor (an anesthesiologist), the codes for gender or a lab observation (blood cell count) may serve as examples.

OIDs (object identifiers) are worldwide unique identifiers for objects. They are used in HL7 to specify identifications and classifications. An object in this sense is persistent, well-defined information, definitions or specifications and is represented with ids or codes.

Commonly used OIDs (i.e. used for a purpose that is wider in scope than the regional healthcare organization; used in communications between healthcare regions) can be found in OIDs registries such as

* [http://www.oid-info.com www.oid-info.com],
* [http://www.hl7.org www.hl7.org],
* [http://www.hl7.org.uk/version3group/oids.asp HL7 OID registry in the UK],
* [https://www.dimdi.de/dynamic/de/klassifikationen/weitere-klassifikationen-und-standards/oid/ OID registry Germany].

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|All OIDs with an element of 999 or 9999 are for documentation purposes only. They will be replaced by permanent OIDs once these have been as-signed/found/applied for.
|}

OID (Object Identifiers) are unique identifiers for any kind of objects. They are defined in Rec. ITU-T X.660 | ISO/IEC 9834-1. This identification system for objects and concepts makes reliable electronic information exchange possible. Administration and Registration is regulated by a set of rules, described in the corresponding chapter of this document.

Every artefact in ART-DECOR has an Object Identifier (OID). There are recommendations for the management and the exchange of Object Identifiers, partially defined in ISO TS 13582 <ref>ISO TS 13582: https://www.iso.org/standard/69652.html</ref>.

''HL7 International'' has created a type ontology for the OIDs in the HL7 registry to make it easier for the user community to search for OIDs they may be looking for and can be found at hl7.org.

From a policy perspective it is common practice in several healthcare related OID registries (HL7 International at http://www.hl7.org, OID Registry Germany at http://www.dimdi.de, OID registry Switzerland at http://oid.refdata.ch, and OID registry Austria at https://www.gesundheit.gv.at/OID_Frontend) to distinguish at least between the following types of OIDs:

{| class="hl7table" style="width:60%"
|+<ref group="Table">Recommended OID sub-branches for different artefacts</ref> ''Recommended OID sub-branches for different artefacts''
! Arc !! Description
|-
| .3 || organizational bodies and groups
|-
| .4 || identifier systems and namespaces
|-
| .5 || code systems
|-
| .7 || document artefacts
|-
| .9 || conformance profiles
|-
| .10 || templates
|-
| .11 || value sets
|-
| .19 || examples
|-
| .99 || experimental
|}

''Example: given that “your” root OID is 1.2.3.4.5, the first value set of your governance group is then to be 1.2.3.4.5.11.1, with .11 as the value set “branch” and the last .1 as the first artefact of that kind.''

In ART-DECOR a project typically is set into the .77 branch of a governance group. When setting up the project, the OID for that project also determines the artefact OIDs using throughout the ART-DECOR project. The following additional branches are used to distinguish between different OID types:

{| class="hl7table"
|+<ref group="Table">Recommended OID sub-branches for ART-DECOR projects</ref> ''Recommended OID sub-branches for different artefacts''
! Artefact code Description !! Recommended !! OID suffix
|-
| DS || dataset || .77.1
|-
| DE || dataset concept || .77.2
|-
| SC || scenario || .77.3
|-
| TR || transaction in scenario || .77.4
|-
| CS || code system || .77.5
|-
| IS || issue || .77.6
|-
| AC || actor in scenario || .77.7
|-
| CL || concept list in dataset || .77.8
|-
| EL || element in template || .77.9
|-
| TM || template || .77.10
|-
| VS || value set || .77.11
|-
| RL || rule for instances || .77.12
|-
| SX || test/example scenario || .77.18
|-
| EX || test/example instance || .77.19
|-
| QX || qualification test/example || .77.20
|-
| TX || test/example data element || .77.21
|-
| CM || community || .77.22
|-
| MP || concept map || .77.24
|}

In ART-DECOR a newly created project uses these OID branches automatically.

=== Instance identification ===

Instance identification is done with the id element of a class. Its type is II (instance identifier) and described in the data type section above. For example, a patient number can be represented as
* 2.16.578.1.34.1.5432.1, the root-OID of the issuing authority, for example a system/application in a hospital, and
* 67543242 as the ''@extension'', representing the patient number within the system defined by the ''@root'' attribute.

=== Coding scheme identification ===

Coding schemes have to be uniquely identified using OIDs as well. All coding tables used in this implementation guide show the corresponding OID that has to be specified in the ''@codeSystem'' attribute of coded elements. Both attributes ''@code'' and ''@codeSystem'' together allows a correct interpretation of concept and code.

=== List of identification schemes ===

The following are OIDs for commonly used identification schemes.

{| class="hl7table"
|+<ref group="Table">Commonly used identification scheme OIDs</ref> ''Commonly used identification scheme OIDs''
! OID !! Identification System Name !! Description !! Issuer
|-
| 1.2.276.0.76.4.8 || KV-Nummer || Krankenversichertennummer ||
|-
| 1.2.276.0.76.4.17 || BSNR || Betriebsstättennummer ||
|-
| 1.2.276.0.76.4.16 || LANR || lebenslange Arztnummer ||
|}

=== List of code systems ===

The following are OIDs for code systems.

{| class="hl7table"
|+<ref group="Table">Commonly used code system OIDs</ref> ''Commonly used code system OIDs''
! OID !! Code System Name !! Description !! Issuer
|-
| 2.16.840.1.113883.6.1 || LOINC || Logical Observation Identifiers Names and Codes (LOINC) || Regenstrief Institute
|-
| 2.16.840.1.113883.6.96 || SNOMED CT || Systemized Nomenclature in Medicine Reference Terminology (SNOMED CT) || SNOMED International
|-
| 1.0.3166.1.2 || ISO 3166-1 (second edition) || Country codes as per ISO 3166-1:2007 || ISO
|}

== Vocabulary ==

=== Code Systems ===

Within HL7, a ''Code System'' is defined as a collection of codes with associated designations and meanings. Examples of code systems include ICD-10, SNOMED CT, and LOINC.
To meet the requirements of a code system as defined by HL7, a given code must resolve to one and only one meaning within the code system. Given this definition, each code table in the HL7 Version 3 standard represents a different code system since codes are sometimes used in different tables to have different meanings.
For example, “M” in the administrative gender table (''AdministrativeGender'', OID 2.16.840.1.113883.5.1) means “male”, while “M” in the marital status table (''MaritalStatus'', OID 2.16.840.1.113883.5.2) means “married”.
In this specification, code system tables are not presented in detail.

=== Value Sets ===

A ''Value Set'' represents a uniquely identifiable set of valid concept representations, where any concept representation can be tested to determine whether or not it is a member of the value set.
Value set complexity may range from a simple flat list of concept codes drawn from a single code system, to an unbounded hierarchical set of possibly post-coordinated expressions drawn from multiple code systems.
Value sets exist to constrain the content for a coded element in an HL7 static model or data type property. Value sets cannot have null content and must contain at least one concept representation where any given concept is generally (but not required to be) represented by only a single code within the Value Set.

[[File:CDA_Core_Principles_Figure_3_ValueSet_Example.png|800px]]

<ref group="Figure">Example presentation of the value set “MaritalStatus”</ref> ''Example presentation of the value set “MaritalStatus”''

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that value set OIDs never appear in a CDA Release 2 document. They are used for constraint expressions, for example in implementation guides.
In order to send a specific code drawn from a value set, the corresponding code system has to be conveyed.
An example, in the implementation specification the constraint on the model element ''maritalStatusCode'' is expressed as “to be drawn from value set 2.16.840.1.113883.5.2 ''MaritalStatus''”.
To actually send a marital status of “M” (married) that is shown in the value set figure above, the corresponding HL7 CDA instance would say:
<syntaxhighlight lang="xml">
<maritalStatusCode code="M" codeSystem="2.16.840.1.113883.5.2"/>
</syntaxhighlight>
|}

In this specification, value set tables are not presented in detail.

==== Binding strength ====

There is an optional vocabulary strength for data types that support that feature (coded concepts). Examples include CD, CE, CV and CO. Values are required, extensible, preferred and example. Default is required.

Please note: the formerly supported values CNE (Coded No Extensibility) and CWE (Coded With Extensibility) in ART-DECOR are deprecated as of December 2017. Specification CNE is handled as required and CWE is handled as extensible.

{| class="hl7table"
|+<ref group="Table">Binding Strengths</ref> ''Binding Strengths''
! Strength !! Description
|-
|required||Required/CNE. Coded with no exceptions; this element SHALL be from the specified value set
|-
|extensible||Extensible/CWE. Coded with Exceptions; this element SHALL be from the specified value set if any of the codes within the value set can apply to the concept being communicated. If the value set does not cover the concept (based on human review), alternate codings (or, data type allowing, text) may be included instead.
|-
|preferred||Preferred. Instances are encouraged to draw from the specified codes for interoperability purposes but are not required to do so to be considered conformant.
|-
|example||Example. Instances are not expected or even encouraged to draw from the specified value set. The value set merely provides examples of the types of concepts intended to be included.
|}

Mismatches with required lead to validation errors (SHALL logic). Mismatches with extensible lead to validation warnings (SHOULD logic). Mismatches with preferred lead to validation information messages (MAY logic). Mismatches with example don't have any validation consequences.

== Appendix ==

=== References ===

<references/>

=== List of figures ===

<references group="Figure" />

=== List of tables ===

<references group="Table" />

HL7 CDA Core Principles

2019-06-16T10:57:33Z

Dammon: /* CDA document structure */

== Introduction ==

This implementation guide specifies the ''Core Principles'' of using the ''Clinical Document Architecture'' <ref>Clinical Document Architecture Release 2: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=7</ref>.

=== Scope ===

This guide focuses on ''Data Types Release 1'' <ref>HL7 Data Types Release 1: http://www.hl7.org</ref>. Meanwhile an ISO specification ISO 21090 is out, also known as Data Type Release 2. The latter is subject to another implementation guide that will be published when ISO data types are used.

=== Focus of this document: HL7 Version 3 Data Types for CDA ===

The following chapters of this document will focus on the description of the data types and associated material. It will highlight the essentials in four chapters, all focusing on the Norwegian situation.
* '''Common aspects:''' explains common aspects of use of CDA and XML
* '''Data types:''' gives an overview and detailed specification of all data types used in CDA
* '''Identification schemes:''' explains major aspects of identification and the use in CDA
* '''Use of vocabulary:''' explains major aspects of vocabulary use in CDA.

=== Background ===

In many (European) countries, implementation guides for the use of data types in HL7 V3 are published. They take into account country specific constraints on the data types.

=== Legend of symbols ===

In this document several symbols are used.

{| class="hl7table" style="width:50%"
| [[File:Pfeil_rechts.png|50px]] || This is an important item
|-
| [[File:Issue.svg|50px]] || This is a known open issue
|-
| [[File:Faq.svg|50px]] || This is a frequently asked question (FAQ) with answer
|-
| [[File:Conformance.svg|50px]] || This is a constraint; in some situations also the rule identification is specified, e.g. dtr1-1-ANY, which links to the corresponding validation rule.
|}

=== Version history ===

{| class="hl7table" style="width:50%"
|+
! Version !! Date !! Description !! Author
|-
| 1.1 || 2019-04-24 || Refurbished guide based on earlier work || Kai U. Heitmann
|}

== Common aspects ==

=== Use of XML ===

HL7 Version 3 CDA uses the Extensible Markup Language (XML) as the exchange format. It is assumed that the reader is familiar with common XML aspects. However, some constraints are made regarding the use of CDA.

==== Character Set ====

{{ConstraintBox|
The character encoding of any CDA document shall be “UTF-8”.}}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="utf-8"?>
</syntaxhighlight>

=== CDA document structure ===

The XML namespace for CDA Release 2 documents is ''<nowiki>urn:hl7-org:v3</nowiki>''. This must be correctly mentioned in every XML instance.

CDA XML documents starts with the root element ''ClinicalDocument''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">


...

<component>
<structuredBody>
...
</structuredBody>
</component>

</ClinicalDocument>
</syntaxhighlight>

== Data types ==

=== Introduction ===

The following chapter describes the typical data types used in CDA implementation guides. For further information please refer to the HL7 V3 standard and its two parts concerning data types:
* Abstract Data type definition <ref>HL7 Version 3 Abstract Data type definition: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=264</ref>
* XML ITS for data types <ref>XML ITS for data types: https://www.hl7.org/documentcenter/public_temp_682D4D16-1C23-BA17-0C789BA52BEDB68E/wg/inm/datatypes-its-xml20050714.htm</ref>
Data types are properties of model class attributes and the basic building blocks of information in a CDA XML instance. For example, a model attribute named “time” has as its data type a time stamp “TS” (see Figure 1).

[[File:CDA_Core_Principles_Figure_1_CDA_Structure_Data_Types.png|700px]]

<ref group="Figure">CDA structure (left) and the data type specification (right)</ref> ''CDA structure (left) and the data type specification (right)''

=== XML representation of data types ===

Actual data is mostly carried in HL7 Version 3 by populating XML attributes and not as element content. Exceptions are names of persons and organizations as well as addresses.
The XML elements have names like the model attributes. For example, a model attribute “id” has a corresponding XML element named <id…>. The model determines the sequence of elements and their hierarchy. The data type itself determines the XML attributes within the start tag. The notation here is as follows:

{| class="hl7table"
|+
! Attribute !! DT !! Conf !! Description
|-
| (name of the model attribute or XML element) || Data type || Conformance, i.e. O, R, M || Textual description
|}

XML attributes (data type properties) are denoted as ''@attribute'' in order to distinguish their names from XML elements.

Example: in the example model above, the data type of the ''id'' attribute's is ''II'' (Instance Identifier). The corresponding XML attributes for that data type include ''@root'' and ''@extension''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id root="…" extension="..." />
</syntaxhighlight>

A description of the data types and their corresponding XML representation is contained in subsequent paragraphs of this guide.

==== Exceptions using XML element content ====

For most data types, the actual data is conveyed in XML attributes. However, there are some exceptions. For the data types binary (BIN), Encapsulated Data (ED), Entity Name (EN), Person Name (PN), Organization Name (ON), Trivial Name (TN), Address (AD) and character string data (ST), information is carried as element content.

Example: the components of an address <addr> are represented by sub elements with the data as element content (in the example shown in black).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr>
<streetAddressLine>Thormøhlens gate 12</streetAddressLine>
<postalCode>5006</postalCode>
<city>Bergen</city>
</addr>
</syntaxhighlight>

==== Combined data types ====

There are a number of socalled combined data types. For example, an interval with a lower and upper limit and a ratio that has a nominator and a denominator value.
In combined data types the substructure (e.g. <low> <high> in an interval) are represented as child elements of the relevant data type element.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110701"/>
<high value="20110729"/>
</effectiveTime>
</syntaxhighlight>

==== Conformance information ====

The conformance indicators distinguish kinds of conformance information described shortly here.

* '''O''': An optional item may be omitted if no data is present, i.e. no corresponding XML attribute or element is sent (marked as “O”)
* '''R''': For required items, lower cardinality is always zero or 1.
** Elements must be present and populated with data if present in the sending system. If no data is available (yet), a null flavor (see below) indicates and possibly classifies the missing information (marked as R).
** Attribute flagged as required must be present in the instance and populated.
* '''M''': For mandatory elements data must be sent and no missing values are allowed, i.e. if the sending system does not have information for mandatory elements the XML instance cannot be created and sent (marked as M).
* '''NP''': no data may be present at all (not permitted)
* '''C''': conditional conformance; typically a conformance table shows the circumstances (conditions) derived from information in the instance and the corresponding cardinalities and conformance statements.

=== Missing values (null flavor) ===

For every data type it is possible to specify a missing value including a kind of reason why data is missing. Instead of specifying any attribute of the corresponding element, a ''@nullFlavor'' attribute expresses the omission of data. Note that missing data is not allowed for mandatory elements (see above).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value nullFlavor="OTH"/>

<code nullFlavor="UNK"/>

<booleanInd nullFlavor="NI"/>

</syntaxhighlight>

The codes for the ''@nullFlavor'' attribute are drawn from the following hierarchical code system. It is a Coded Simple (CS), which means it has no code system (attribute ''@codeSystem'') specified.

{| class="hl7table"
|+<ref group="Table">NullFlavor</ref> ''NullFlavor''
! Code
! width=15% | Print Name
! Definition / Description
|-
| NI || No Information || No information whatsoever can be inferred from this exceptional value. This is the most general exceptional value. It is also the default exceptional value.
|-
| OTH || other || The actual value is not an element in the value domain of a variable. (e.g., concept not provided by required code system).
|-
| NINF || negative infinity || Negative infinity of numbers.
|-
| PINF || positive infinity || Positive infinity of numbers.
|-
| UNK || unknown || A proper value is applicable, but not known.
|-
| ASKU || asked but unknown || Information was sought but not found (e.g., patient was asked but didn't know)
|-
| NAV || temporarily unavailable || Information is not available at this time but it is expected that it will be available later.
|-
| NASK || not asked || This information has not been sought (e.g., patient was not asked)
|-
| TRC || trace || The content is greater than zero, but too small to be quantified.
|-
| MSK || masked || There is information on this item available but it has not been provided by the sender due to security, privacy or other reasons. There may be an alternate mechanism for gaining access to this information.
Note: using this null flavour does provide information that may be a breach of confidentiality, even though no detail data is provided. Its primary purpose is for those circumstances where it is necessary to inform the receiver that the information does exist without providing any detail.
|-
| NA || not applicable || No proper value is applicable in this context (e.g., last menstrual period for a male).
|-
| NP || not present || Value is not present in a message. This is only defined in messages, never in application data! All values not present in the message must be replaced by the applicable default, or no-information (NI) as the default of all defaults.
|}

=== ANY as the generic data type ===

This abstract data type is the basis for all other data types. Not a single value within a CDA document has the effective data type ANY, but any data type within HL7v3 is a specialization of ANY. This also means that any other data type inherits all properties of ANY (see [[#Missing_values_.28null_flavor.29|“Missing values (null flavor)”]]).

The ANY type is occasionally found in HL7 models when it comes to clinical finding etc. where – at model time – the actual data type of the value is not known. At instantiation time however, the actual data type ''is'' known and ANY is always replaced by a particular data type in an instance.

One example is the observation value (child element value in an observation), where in the model the data type of value cannot be anticipated. When instantiation is taking place, the data type is specified by the XML instance attribute ''@xsi:type''. This information can be used by the receiver to validate and process the value.

Attributes of an element with this data type are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@nullFlavor''' || <center>CS</center> || <center>–</center> || Classification of the missing value, see [[#Missing_values_.28null_flavor.29|3.3 Missing values (null flavor)]].
|}

{| class="hl7table" style="width:100%"
| width=8% | <center>[[File:Conformance.svg|50px]] dtr1-1-ANY</center> || If there is a ''nullFlavor'', there shall be no other attribute or element, unless it's ''nullFlavor="OTH"''. In that case ''@codeSystem'' or ''originalText'' (see “code” data types) may have a value.
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">

<value xsi:type="CE" code="N11.9" codeSystem="2.16.840.1.113883.6.3"/>


<value xsi:type="PQ" value="12" unit="mL"/>


<value xsi:type="ED">this is text</value>
</syntaxhighlight>

=== Boolean (BL) ===

Elements of this data type refer to Boolean logic and have an attribute ''@value''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>BL</center> || <center>–</center> || Valued as “true” or “false”
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<negationInd value="false"/>

<deceasedInd value="true"/>

</syntaxhighlight>

In some situations, the BL data does not apply to an XML element, but an attribute. In that case, the attribute carries the Boolean value directly.
<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<support contextConductionInd ="false">
...
</support>
</syntaxhighlight>

=== Instance Identifier (II) ===

This data type identifies instances of classes like observations or entities (persons, organizations). Attributes are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@extension''' || <center>ST</center> || <center>O</center> || Identification
|-
| '''@root''' || <center>OID</center> || <center>R</center> || Source of identification
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id extension="13234453645" root="2.16.840.1.113883.2.6.15.3.427.1"/>
</syntaxhighlight>

The ''@root'' attribute is of type OID (object identifier), a unique identifier of the issuing authority or system. For example, a patient with a patient number 13234453645 created by a specific healthcare provider organization is uniquely identified by the number itself in ''@extension'' and the OID of the organization or the sending system, in the example 2.16.840.1.113883.2.6.15.3.427.1 in ''@root''.
In some cases, a single OID identifies an object uniquely. In that situation, only ''@root'' is populated and ''@extension'' is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Encapsulated Data (ED) ===

Elements of this data type carry multimedia content. The actual multimedia content is represented as element content. There are two situations for the use of ED:

* Inline: The full data is transmitted in the type. This form is mainly used for text.
* By reference: a thumbnail is provided which links to the full data by reference.

In an instance, the data type is normally determined by an ''xsi:type'' specification and some attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@mediaType''' || <center>CS</center> || <center>O</center> || MIME media type classification. At time of writing this specification, the following MIME types are allowed:
* text/plain (plain text)
* text/html (text with html markup)
* image/jpeg (JPEG image)
* application/pdf (a PDF, portable document format)
* application/hl7-sda+xml (CDA documents).
|-
| '''@representation''' || <center>CS</center> || <center>O</center> || Representation of the multimedia content. At time of writing this specification, the following representations are allowed:
* TXT (text, this is the default)
* B64 base 64 encoded data, for example for embedded CDA documents).
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<text xsi:type="ED" mediaType="text/plain">
Patient treated sucessfully
</text>

<text mediaType="application/hl7-sda+xml" representation="B64">PD94bWw..etc..==</text>

</syntaxhighlight>

To include referenced data the two sub elements ''thumbnail'' and ''reference'' are used.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''reference''' || <center>TEL</center> || <center>0..*</center> || <center>O</center> || Link (URI) to full data
|-
| '''thumbnail''' || <center>ED</center> || <center>0..*</center> || <center>O</center> || Thumbnail of referenced data
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value xsi:type="ED" mediaType="image/png" representation="B64">
<reference value="http://radiology.bergen.no/xrays/128s.png"/>
<thumbnail mediaType="image/jpeg" representation="B64"> MNY...83== </thumbnail>
</value>
</syntaxhighlight>

=== Strings (ST) ===

This data type is a specialization of the ED type where ''@mediaType'' is fixed “text/plain” and ''@representation'' is fixed “TXT”. It allows conveying a character string as '''element content'''. This data type is used in other data types it like the ''@extension'' in instance identifiers, or address and person name data type components.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<lotNumber> 143GT6DT </lotNumber>
</syntaxhighlight>

=== Concept Descriptor (CD) ===

This data type specifies a concept by means of a code and its code system (except for situations where no code is available). A couple of specializations of data type CD exist, which differ in the main characteristics (properties) of the data type that may or may not be supported.

{| class="hl7table" style="width:50%"
|+<ref group="Table">Properties of data types used for codes</ref> ''Properties of data types used for codes''
! <div style="text-align: right">DataType</div> !! CD !! CE !! CV !! CO !! CS
|-
! <div style="text-align: left">Property</div> !! !! !! !! !!
|-
| '''@code''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||<center>X</center>
|-
| '''@codeSystem''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''@codeSystemVersion''' || <center>X</center> || <center>X</center> || <center>X</center>|| <center>X</center> ||
|-
| '''@displayName''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''originalText''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''translation''' || <center>X</center> || <center>X</center> || || ||
|-
| '''qualifier''' || <center>X</center> || || || ||
|}

Because the CE variant is most used in practice, the general explanation of the properties will be given with de description of CE (see below).

The only attribute that is unique to CD is briefly explained here.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@qualifier''' || <center>CR</center> || <center>O</center> || An additional qualifier for the code.
|}

Complex terminologies like SNOMED CT can be used only using data type CD.

=== Coded with Equivalents (CE) ===

With elements of this data type, a concept by means of a code and its coding system (except for situations where no code is available) can be specified. It optionally contains one or more equivalents using other code systems.
It may contain the following attributes:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@code''' || <center>ST</center> || <center>R</center> || The actual code
|-
| '''@codeSystem''' || <center>OID</center> || <center>R</center> || required to identify the code system were the code is drawn from. This is an OID (object identifier, see [[#Object_Identifiers_.28OIDs.29|Object Identifiers at 4.1]])
|-
| '''@displayName''' || <center>ST</center> || <center>O</center> || Optional textual representation of code. A display name may be specified representing the plain text of the code. The information of this attribute may not be used by the receiving system for interpretation, but only for display purposes. The display name may never be transmitted without a code and must have the same meaning as the code.
|-
| '''@codeSystemName''' || <center>ST</center> || <center>O</center> || A textual representation of the name of the code system
|-
| '''@codeSystemVersion''' || <center>ST</center> || <center>O</center> || A textual representation of the version of the code system
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"/>

<code code="AU" codeSystem="2.16.840.1.113883.5.33"/>

<storageCode code="AC" codeSystem="2.16.840.1.113883.5.34" displayName="active"/>

<code code="A45.0" displayName="Somatisierungsstörung" codeSystem="1.2.276.0.76.5.409" codeSystemName="ICD-10 GM 2012"/>
</syntaxhighlight>

There are some child elements of codes that can be used to express what the “original text” was that was used for the coding or to indicate that there are “translations” to other code systems than the primary code.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''originalText''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Textual representation of the concept, actually a description which was used to create the actual code
|}

No semantics may be assumed other than showing the ''@displayName'' to a user to clarify the code. A display name cannot occur without its code and must carry the same meaning.

In case no code is known, it is allowed to specify a ''@nullFlavor'' for the code element and to give information about the (not yet coded) concept in original text. However, this should be an exception.

If other codes than the primary code need to be conveyed adding a translation child element can be used.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<originalText>minor aphthous stomatitis</originalText>
</code>
</syntaxhighlight>

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''translation''' || <center>CD</center> || <center>0..*</center> || <center>O</center> || Alternative code(s)
|}

A ''translation'' element is also of type CD and shall have a code and a code system identified. It shall point to the same concept as the primary code. It is allowed that a translation conveys less conceptual details than the original code.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<translation code="528.2" codeSystem="2.16.840.1.113883.6.2" codeSystemName="ICD9" displayName="Oral aphthae"/>
</code>
</syntaxhighlight>

=== Coded Value (CV) ===

This is actually a specialization of CE (see above), with the exception that neither ''originalText'' nor ''translation'' child element are allowed.

=== Coded Simple Value (CS) ===

This is actually a specialization of CE (see above), with no code system attribute and no original text or translation child element allowed. It specifies a concept by means of a code from a ''predefined'' code system (table) where the code is drawn from. This data type is usually applied in the context of fixed predefined HL7 tables.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<statusCode code="completed"/>
</syntaxhighlight>

In this example ''statusCode'' is bound in the underlying model to the specific code system ''ActStatus''. Because it is predefined by means of the vocabulary binding, ''@codeSystem'' is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Telecommunication Address (TEL) ===

Elements of this type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>ST</center> || <center>R</center> || carries strings that represent telecommunication contact information
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

The actual data is preceded by the scheme (refer to Internet Standard “RFC 1738 Uniform Resource Locators (URL)” <ref>RFC 1738 Uniform Resource Locators (URL): http://www.ietf.org/rfc/rfc1738.txt</ref>.

Examples:
* telephone (tel:),
* fax (fax:),
* email (mailto:).

It must follow the rules defined in Internet “RFC 2806 URLs for Telephone Calls” <ref>RFC 2806 URLs for Telephone Calls: http://www.ietf.org/rfc/rfc2806.txt</ref>.

The following codes will be used in the “use” attribute:
* H – Home
* WP – Work
* MC can be used (in addition to H or WP) to denote that this is a mobile phone.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257" />

<telecom use="H" value="tel:55354257" />

<telecom use="H" value="fax:56542558" />

<telecom value="tel:+41.34.21.4765342"/>

<telecom value="mailto:opr@opr-sem.no"/>

<telecom use="WP MC" value="tel:97555786" />
</syntaxhighlight>

It is possible to express the useable period of a telecommunication contact. A child element ''useablePeriod'' is used as a time interval to indicate this period.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''useablePeriod''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257">
<useablePeriod>
<high value="20111201"/>
</useablePeriod>
</telecom>
</syntaxhighlight>

=== Postal Address (AD) ===

Elements of this data type have a substructure in order to represent a structured address specification. In this implementation guide only a selection of all possible child elements is allowed, the original HL7 specification is richer.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''streetAddressLine''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Street address, includes street name and house number
|-
| '''city''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || City
|-
| '''postalCode''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Postal code
|-
| '''country''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Country
|-
|}

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that the sequence of the sub elements is country specific, i.e. it has to follow “common” rules how to write an address. For example, an UK address and a German address have different sequences of address representation.
|}

A ''@use'' attribute can also be specified.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="WP">
<streetAddressLine>Anna-Louisa-Karsch-Str. 2</streetAddressLine>
<postalCode>10178</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="H WP">
<streetAddressLine>Tatungasse 34</streetAddressLine>
<postalCode>10825</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

Also, a country may be specified using the element ''country''.

=== Person Name (PN) ===

Elements of this data type do also have a substructure to represent the parts of a person name, like family or given name and prefixes.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>
<given>Franz</given>
<given>Ingrun</given>
<family>Nordmann</family>
</name>
</syntaxhighlight>

Previous or birth or maiden names are supported using the ''validTime'' element. ''validTime'' (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]]) specifies the validity range of the name.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">

<name>
<given>Jan</given>
<given>Olaf</given>
<family>Hendrikson</family>
<validTime>
<high value="20000101"/>
</validTime>
</name>
</syntaxhighlight>

Note that the name attribute is repeating, i.e. multiple (types of) names could be sent. It is up to the receiver (based on the value of the ''@use'' attribute, and ''validTime'') to decide what name it wants to use or import in its database.

=== Organisation Name (ON) ===

Elements of this data type represent a name of an organization.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name> Charité Berlin </name>
</syntaxhighlight>

The optional ''validTime'' element (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]] may be used to specify the validity range of the name of the organization.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name of the organization
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>The old hospital
<validTime>
<high value="20111231235959"/>
</validTime>
</name>
</syntaxhighlight>

Please note that the use of ''validTime'' yields XML mixed content which should be avoid-ed if possible.

=== Integer Number (INT) ===

Elements of this data type are used to specify integer numbers and have one attribute.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>int</center> || <center>R</center> || Integer value
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<sequenceNumber value="24"/>
</syntaxhighlight>

=== Physical Quantities (PQ) ===

Elements of this data type are physical quantities, i.e. a measurable quantity (or countable) value from the physical world. This is different from just a “number”, because there is a (natural) unit specified in which the measurable quantity is expressed.
Examples:
* an amount of blood 20 ml (sample volume)
* a cut with a length of 10 cm (result observation)
* a dose of 200 milligrams per administration (dosing)
* delivery of 60 pieces of a tablet (amount supplied).
Elements of this data type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>real</center> || <center>R</center> || value of the measurement
|-
| '''@unit''' || <center>CS</center> || <center>R</center> || unit of measurement
|}

In the unit of measurement unit is expressed following the ''Unified Code for Units of Measure'' (UCUM) specification. This specification is a collection of atomic units, prefixes and a corresponding grammar for valid combinations to build all-natural units of measurement. For a complete description of possible units, see the ''Unified Code for Units of Measure'' <ref>Unified Code for Units of Measure: http://unitsofmeasure.org/</ref> specification.
If a value is not countable or if measurable, for example expressed in milligrams or liters, then this unit is a valid UCUM unit like “mg” or “L”. If a value is countable, for example the number of tablets, then this attribute contains “1”.
In HL7 it is required that all PQ data type units are valid UCUM units.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<value value="165" unit="cm"/>

<value value="81.1" unit="kg"/>

<value value="120" unit="mm[Hg]"/>

<value value="5" unit="1"/>
</syntaxhighlight>

=== Point in Time (TS) ===

Elements of this data type have the attribute

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>TS</center> || <center>R</center> || Point in time
|}

and specify points in time in the format YYYYMMDDhhmmss±ZZZZ, where
* YYYY is the four-digit year,
* MM the two-digit month,
* DD the two-digit day,
* hh the two-digit hour,
* mm the two-digits minute and
* ss the two-digit second.
Optional a time zone ZZZZ, the four-digit time alignment with a preceding “-” or a “+” can be specified. If time zone is omitted, local time is assumed.
The point in time may be right truncated in respect to the precision of the information.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<effectiveTime value="20140412"/>

<effectiveTime value="201409091245"/>

<effectiveTime value="1996"/>

<birthTime value="19540714"/>

<effectiveTime value="20140412+0100"/>
</syntaxhighlight>

=== Intervals (IVL) ===

Intervals are defined only for data types with an ordinal or interval scale type. There are several possibilities to determine an interval (see Figure 2), for example to specify

* a lower <low> and an upper boundary <high> (a),
* a lower <low> boundary and width <width> (b)
* an upper boundary and width <width> (c) or
* the middle of the interval <nowiki><center></nowiki> and a width <width> (d).

[[File:CDA_Core_Principles_Figure_2_Determining_Intervals.png|700px]]

<ref group="Figure">Several possibilities to determine closed intervals</ref> ''Several possibilities to determine closed intervals''

{{ConstraintBox|
To indicate an interval, only the following combinations are permitted.
(1) A lower and an upper boundary may not be identical, and their accuracy has to be equal.

Correct examples:

{{BeginGreenBox|}}
Interval from 5 to 6
Interval from 20110607 until 20110612
{{EndGreenBox}}

Incorrect examples:

{{BeginRedBox|}}
Interval from 5 to 6.0
Interval from 20110101 to 2011
{{EndRedBox|}}

(2) A lower boundary and a width

(3) A lower limit boundary

(4) A upper limit boundary

(5) Only the middle of the interval

(6) Only the width of an interval}}

Accordingly, four child elements are available.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Lower boundary
|-
| '''high''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Upper boundary
|-
| '''center''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Where ''(T)'' is defined in this specification as one of the data types “TS” or “PQ”.

=== Interval of time (IVL_TS) ===

Elements of this data type represent time intervals. There are four possible child elements.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Lower boundary (start date/time)
|-
| '''high''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Upper boundary (end date/time)
|-
| '''center''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Normally, a lower and an upper boundary is given, both are points in time. Also, it is possible to specify open intervals like “since June 14, 1999” (left boundary given only) or “until September 24, 2006” (right boundary given).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110507"/>
<high value="20110909"/>
</effectiveTime>

<effectiveTime>
<low value="20110507"/>
</effectiveTime>

<value>
<low value="20110101"/>
<width value="120" unit="d"/>
</value>

<value>
<center value="20110101"/>
</value>
</syntaxhighlight>

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|It must be noted that intervals of time stamps in HL7 are equally treated as other interval types (e.g. integers). The statement, one may take 1–3 tablets (interval of integers), for example, says that you are allowed to take no more than three tablets, not 3½ or 3.5 tablets. On the other hand, when treat the words “until 12 June 2011” regarding the upper interval limit differently, particularly we assume that the entire day 12 June is still in-cluded in this time interval.
Thus, in human perception time intervals are handled differently com-pared to such as number intervals. This is a situation may lead to inconsist-encies in standardized communication. As a conclusion, an upper limit “12 June 2011” means that only the very first moment of the 12 June is included in the interval, but not, for example, the 12 June 13:00 hours.
Interpretation does not depend on the accuracy of the time:
* “after 2004” means “from January 1, 2005 00:00:00.000”,
* “after 20041201” means “from 2 December 2004 00:00:00.000 hours”,
* and “after 200412011200” means “from 1 December 2004 12:01:00.000”.

As a result, you have to carefully consider the specification and implemen-tation of time intervals upper boundaries. In order to prevent mis-understandings intervals are always specified with the date and time for an upper limit that would cover the whole day. Accordingly, “201106122359” means 12 June 2011 throughout the day.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="201106122359"/>
</effectiveTime>
</syntaxhighlight>

Because of the equal treatment of time intervals this is applied also to the lower limit boundaries of time intervals as “0000”. This means for example that “since 9 June 2011” is expressed as “201106090000”.
|}

The <width> element is of data type PQ (physical quantity). The value obviously shall relate to a period of time and it is required to include a “time” unit. These are the units “us” (microseconds), “ms” (milliseconds), “s” (seconds), “min” (minute), “h” (hours), “d” (day), “wk” (week), “mo” (month) and “a” (year).

{{ConstraintBox|
For interval of time stamps the @unit of a ''low'' or ''high'' child element shall use units
* us (microseconds),
* ms (milliseconds),
* s (seconds),
* min (minute),
* h (hours),
* d (day),
* wk (week),
* mo (month) or
* a (year).
}}

=== Interval of physical quantities (IVL_PQ) ===

Elements of this data type are used to indicate intervals of physical quantities (see also [[#Physical Quantities (PQ)|3.18 Physical Quantities (PQ)]]). In general, an upper and a lower boundary is specified. It is also possible to use ''center'' instead of ''low'' and ''high''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low || <center>TS</center> || <center>0..1</center> || <center>C</center> || the lower limit of the interval (i.e. the minimum amount).
|-
| '''high || <center>TS</center> || <center>0..1</center> || <center>C</center> || the upper limit of the interval (i.e. the maximum amount).
|-
| '''center || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of the interval
|}

The ''center'' child element is used when there is no interval, but an exact value. Alternative would be to demote IVL_PQ to data type PQ and populate the element’s ''@value'' attribute, but this is more difficult to process in XML. That is why the use of the ''center'' child element is deprecated.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<referenceRange>
<low value="7.5" unit="mmol/l"/>
<high value="10" unit="mmol/l"/>
</referenceRange>

<doseQuantity>
<center value="9" unit="1"/>
</doseQuantity>
</syntaxhighlight>

=== Ratio of quantities (RTO_QTY_QTY) ===

Elements of this data type specify ratios and have two child elements, a numerator and a denominator. The underlying QTY (Quantity) data type is an abstract data type and in a XML instance it has to be replaced by a specific data type using the ''@xsi:type'' instruction (see below).

In this specification only “PQ” or “INT” are allowed for the demotion of both ''numerator'' and ''denominator''. The relevant child elements are:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''numerator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the numerator of the ratio
|-
| '''denominator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the denominator of the ratio
|}

If a model attribute already is a RTO_QTY_QTY, you need to specify (demote) the OTY abstract data type for both ''numerator'' and ''denominator'' by using an ''@xsi:type'' instruction.
In some cases where the model attribute is of type “ANY”, also the root element shall carry an ''@xsi:type'' RTO_QTY_QTY instruction.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<maxDoseQuantity>
<numerator xsi:type="PQ" value="6"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="400" unit="mg"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="5"/>
<denominator xsi:type="PQ" value="1" unit="h"/>
</maxDoseQuantity>

<value xsi:type="RTO_QTY_QTY">
<numerator xsi:type="INT" value="1"/>
<denominator xsi:type="INT" value="10000"/>
</value>
</syntaxhighlight>

== Identification mechanisms ==

=== Object Identifiers (OIDs) ===

Standardized exchange of information using messages or documents also deals with unique identifications of objects and concepts, especially in environments where sender and receiver do not “know” each other necessarily.

It is important to understand the difference between identification of instances (ids) and code concepts (classifications). Within the context of HL7 interactions OIDs are quite often used.
An id points to a specific instance of an object or identification scheme (a particular methodology for the identification of a class of objects), for example a specific person as the patient or a physician, a specific lab observation or an X-ray photo.

In contrast to instance identifiers, a classification identifies a specific concept. The type of patient (inpatient, outpatient), the type of doctor (an anesthesiologist), the codes for gender or a lab observation (blood cell count) may serve as examples.

OIDs (object identifiers) are worldwide unique identifiers for objects. They are used in HL7 to specify identifications and classifications. An object in this sense is persistent, well-defined information, definitions or specifications and is represented with ids or codes.

Commonly used OIDs (i.e. used for a purpose that is wider in scope than the regional healthcare organization; used in communications between healthcare regions) can be found in OIDs registries such as

* [http://www.oid-info.com www.oid-info.com],
* [http://www.hl7.org www.hl7.org],
* [http://www.hl7.org.uk/version3group/oids.asp HL7 OID registry in the UK],
* [https://www.dimdi.de/dynamic/de/klassifikationen/weitere-klassifikationen-und-standards/oid/ OID registry Germany].

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|All OIDs with an element of 999 or 9999 are for documentation purposes only. They will be replaced by permanent OIDs once these have been as-signed/found/applied for.
|}

OID (Object Identifiers) are unique identifiers for any kind of objects. They are defined in Rec. ITU-T X.660 | ISO/IEC 9834-1. This identification system for objects and concepts makes reliable electronic information exchange possible. Administration and Registration is regulated by a set of rules, described in the corresponding chapter of this document.

Every artefact in ART-DECOR has an Object Identifier (OID). There are recommendations for the management and the exchange of Object Identifiers, partially defined in ISO TS 13582 <ref>ISO TS 13582: https://www.iso.org/standard/69652.html</ref>.

''HL7 International'' has created a type ontology for the OIDs in the HL7 registry to make it easier for the user community to search for OIDs they may be looking for and can be found at hl7.org.

From a policy perspective it is common practice in several healthcare related OID registries (HL7 International at http://www.hl7.org, OID Registry Germany at http://www.dimdi.de, OID registry Switzerland at http://oid.refdata.ch, and OID registry Austria at https://www.gesundheit.gv.at/OID_Frontend) to distinguish at least between the following types of OIDs:

{| class="hl7table" style="width:60%"
|+<ref group="Table">Recommended OID sub-branches for different artefacts</ref> ''Recommended OID sub-branches for different artefacts''
! Arc !! Description
|-
| .3 || organizational bodies and groups
|-
| .4 || identifier systems and namespaces
|-
| .5 || code systems
|-
| .7 || document artefacts
|-
| .9 || conformance profiles
|-
| .10 || templates
|-
| .11 || value sets
|-
| .19 || examples
|-
| .99 || experimental
|}

''Example: given that “your” root OID is 1.2.3.4.5, the first value set of your governance group is then to be 1.2.3.4.5.11.1, with .11 as the value set “branch” and the last .1 as the first artefact of that kind.''

In ART-DECOR a project typically is set into the .77 branch of a governance group. When setting up the project, the OID for that project also determines the artefact OIDs using throughout the ART-DECOR project. The following additional branches are used to distinguish between different OID types:

{| class="hl7table"
|+<ref group="Table">Recommended OID sub-branches for ART-DECOR projects</ref> ''Recommended OID sub-branches for different artefacts''
! Artefact code Description !! Recommended !! OID suffix
|-
| DS || dataset || .77.1
|-
| DE || dataset concept || .77.2
|-
| SC || scenario || .77.3
|-
| TR || transaction in scenario || .77.4
|-
| CS || code system || .77.5
|-
| IS || issue || .77.6
|-
| AC || actor in scenario || .77.7
|-
| CL || concept list in dataset || .77.8
|-
| EL || element in template || .77.9
|-
| TM || template || .77.10
|-
| VS || value set || .77.11
|-
| RL || rule for instances || .77.12
|-
| SX || test/example scenario || .77.18
|-
| EX || test/example instance || .77.19
|-
| QX || qualification test/example || .77.20
|-
| TX || test/example data element || .77.21
|-
| CM || community || .77.22
|-
| MP || concept map || .77.24
|}

In ART-DECOR a newly created project uses these OID branches automatically.

=== Instance identification ===

Instance identification is done with the id element of a class. Its type is II (instance identifier) and described in the data type section above. For example, a patient number can be represented as
* 2.16.578.1.34.1.5432.1, the root-OID of the issuing authority, for example a system/application in a hospital, and
* 67543242 as the ''@extension'', representing the patient number within the system defined by the ''@root'' attribute.

=== Coding scheme identification ===

Coding schemes have to be uniquely identified using OIDs as well. All coding tables used in this implementation guide show the corresponding OID that has to be specified in the ''@codeSystem'' attribute of coded elements. Both attributes ''@code'' and ''@codeSystem'' together allows a correct interpretation of concept and code.

=== List of identification schemes ===

The following are OIDs for commonly used identification schemes.

{| class="hl7table"
|+<ref group="Table">Commonly used identification scheme OIDs</ref> ''Commonly used identification scheme OIDs''
! OID !! Identification System Name !! Description !! Issuer
|-
| 1.2.276.0.76.4.8 || KV-Nummer || Krankenversichertennummer ||
|-
| 1.2.276.0.76.4.17 || BSNR || Betriebsstättennummer ||
|-
| 1.2.276.0.76.4.16 || LANR || lebenslange Arztnummer ||
|}

=== List of code systems ===

The following are OIDs for code systems.

{| class="hl7table"
|+<ref group="Table">Commonly used code system OIDs</ref> ''Commonly used code system OIDs''
! OID !! Code System Name !! Description !! Issuer
|-
| 2.16.840.1.113883.6.1 || LOINC || Logical Observation Identifiers Names and Codes (LOINC) || Regenstrief Institute
|-
| 2.16.840.1.113883.6.96 || SNOMED CT || Systemized Nomenclature in Medicine Reference Terminology (SNOMED CT) || SNOMED International
|-
| 1.0.3166.1.2 || ISO 3166-1 (second edition) || Country codes as per ISO 3166-1:2007 || ISO
|}

== Vocabulary ==

=== Code Systems ===

Within HL7, a ''Code System'' is defined as a collection of codes with associated designations and meanings. Examples of code systems include ICD-10, SNOMED CT, and LOINC.
To meet the requirements of a code system as defined by HL7, a given code must resolve to one and only one meaning within the code system. Given this definition, each code table in the HL7 Version 3 standard represents a different code system since codes are sometimes used in different tables to have different meanings.
For example, “M” in the administrative gender table (''AdministrativeGender'', OID 2.16.840.1.113883.5.1) means “male”, while “M” in the marital status table (''MaritalStatus'', OID 2.16.840.1.113883.5.2) means “married”.
In this specification, code system tables are not presented in detail.

=== Value Sets ===

A ''Value Set'' represents a uniquely identifiable set of valid concept representations, where any concept representation can be tested to determine whether or not it is a member of the value set.
Value set complexity may range from a simple flat list of concept codes drawn from a single code system, to an unbounded hierarchical set of possibly post-coordinated expressions drawn from multiple code systems.
Value sets exist to constrain the content for a coded element in an HL7 static model or data type property. Value sets cannot have null content and must contain at least one concept representation where any given concept is generally (but not required to be) represented by only a single code within the Value Set.

[[File:CDA_Core_Principles_Figure_3_ValueSet_Example.png|800px]]

<ref group="Figure">Example presentation of the value set “MaritalStatus”</ref> ''Example presentation of the value set “MaritalStatus”''

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that value set OIDs never appear in a CDA Release 2 document. They are used for constraint expressions, for example in implementation guides.
In order to send a specific code drawn from a value set, the corresponding code system has to be conveyed.
An example, in the implementation specification the constraint on the model element ''maritalStatusCode'' is expressed as “to be drawn from value set 2.16.840.1.113883.5.2 ''MaritalStatus''”.
To actually send a marital status of “M” (married) that is shown in the value set figure above, the corresponding HL7 CDA instance would say:
<syntaxhighlight lang="xml">
<maritalStatusCode code="M" codeSystem="2.16.840.1.113883.5.2"/>
</syntaxhighlight>
|}

In this specification, value set tables are not presented in detail.

==== Binding strength ====

There is an optional vocabulary strength for data types that support that feature (coded concepts). Examples include CD, CE, CV and CO. Values are required, extensible, preferred and example. Default is required.

Please note: the formerly supported values CNE (Coded No Extensibility) and CWE (Coded With Extensibility) in ART-DECOR are deprecated as of December 2017. Specification CNE is handled as required and CWE is handled as extensible.

{| class="hl7table"
|+<ref group="Table">Binding Strengths</ref> ''Binding Strengths''
! Strength !! Description
|-
|required||Required/CNE. Coded with no exceptions; this element SHALL be from the specified value set
|-
|extensible||Extensible/CWE. Coded with Exceptions; this element SHALL be from the specified value set if any of the codes within the value set can apply to the concept being communicated. If the value set does not cover the concept (based on human review), alternate codings (or, data type allowing, text) may be included instead.
|-
|preferred||Preferred. Instances are encouraged to draw from the specified codes for interoperability purposes but are not required to do so to be considered conformant.
|-
|example||Example. Instances are not expected or even encouraged to draw from the specified value set. The value set merely provides examples of the types of concepts intended to be included.
|}

Mismatches with required lead to validation errors (SHALL logic). Mismatches with extensible lead to validation warnings (SHOULD logic). Mismatches with preferred lead to validation information messages (MAY logic). Mismatches with example don't have any validation consequences.

== Appendix ==

=== References ===

<references/>

=== List of figures ===

<references group="Figure" />

=== List of tables ===

<references group="Table" />

Medizininformatik-Initiative

2019-06-15T07:49:05Z

Dammon: /* Wichtige Dokumente */

MI-Initiative: Modellierung in ART-DECOR

2019-06-15T07:47:13Z

Dammon: Die Seite wurde neu angelegt: „== Zweck == Die vorliegende Seite dient der Sammlung von Entscheidungen / Empfehlungen zur Modellierung von Datenelementen und Szenarien sowie zur Assoziation…“

== Zweck ==

Die vorliegende Seite dient der Sammlung von Entscheidungen / Empfehlungen zur Modellierung von Datenelementen und Szenarien sowie zur Assoziation von Terminologien und Value Sets im Werkzeug [[ART-DECOR]] für die Weiterentwicklung des [[Medizininformatik-Initiative#Kerndatensatz|MII-Kerndatensatzes]] und für davon abgeleitete Use Cases.

== Nutzung von ART-DECOR in der MI-Initiative ==

Auf Vorlage der [https://www.medizininformatik-initiative.de/de/zusammenarbeit/arbeitsgruppe-interoperabilitaet MII-AG Interoperabilität] hat das [https://www.medizininformatik-initiative.de/de/zusammenarbeit/nationales-steuerungsgremium Nationale Steuerungsgremium] am 8. April 2019 einen Beschluss zur Nutzung von ART-DECOR und Forge / Simplifier als Werkzeuge für die technische Spezifikation sowie zur Beschaffung einer Simplifier-Enterprise-Lizenz getroffen.

ART-DECOR wird dabei für die Auswahl von Datasets und -Items, deren Nutzungsszenarien und benötigte Kardinalitäten sowie für die Assoziation von Daten-Items mit Terminologien und Value Sets dienen. Forge und Simplifier werden dann verwendet, um diese nichttechnischen Modelle im konkreten Format der FHIR-Profile als implementierbare Spezifikationen abzubilden.

Medizininformatik-Initiative

2019-06-15T07:38:35Z

Dammon:

HL7 CDA Core Principles

2019-06-14T20:19:01Z

Dammon: /* Concept Descriptor (CD) */

== Introduction ==

This implementation guide specifies the ''Core Principles'' of using the ''Clinical Document Architecture'' <ref>Clinical Document Architecture Release 2: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=7</ref>.

=== Scope ===

This guide focuses on ''Data Types Release 1'' <ref>HL7 Data Types Release 1: http://www.hl7.org</ref>. Meanwhile an ISO specification ISO 21090 is out, also known as Data Type Release 2. The latter is subject to another implementation guide that will be published when ISO data types are used.

=== Focus of this document: HL7 Version 3 Data Types for CDA ===

The following chapters of this document will focus on the description of the data types and associated material. It will highlight the essentials in four chapters, all focusing on the Norwegian situation.
* '''Common aspects:''' explains common aspects of use of CDA and XML
* '''Data types:''' gives an overview and detailed specification of all data types used in CDA
* '''Identification schemes:''' explains major aspects of identification and the use in CDA
* '''Use of vocabulary:''' explains major aspects of vocabulary use in CDA.

=== Background ===

In many (European) countries, implementation guides for the use of data types in HL7 V3 are published. They take into account country specific constraints on the data types.

=== Legend of symbols ===

In this document several symbols are used.

{| class="hl7table" style="width:50%"
| [[File:Pfeil_rechts.png|50px]] || This is an important item
|-
| [[File:Issue.svg|50px]] || This is a known open issue
|-
| [[File:Faq.svg|50px]] || This is a frequently asked question (FAQ) with answer
|-
| [[File:Conformance.svg|50px]] || This is a constraint; in some situations also the rule identification is specified, e.g. dtr1-1-ANY, which links to the corresponding validation rule.
|}

=== Version history ===

{| class="hl7table" style="width:50%"
|+
! Version !! Date !! Description !! Author
|-
| 1.1 || 2019-04-24 || Refurbished guide based on earlier work || Kai U. Heitmann
|}

== Common aspects ==

=== Use of XML ===

HL7 Version 3 CDA uses the Extensible Markup Language (XML) as the exchange format. It is assumed that the reader is familiar with common XML aspects. However, some constraints are made regarding the use of CDA.

==== Character Set ====

{{ConstraintBox|
The character encoding of any CDA document shall be “UTF-8”.}}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="utf-8"?>
</syntaxhighlight>

=== CDA document structure ===

The XML namespace for CDA Release 2 documents is ''<nowiki>urn:hl7-org:v3</nowiki>''. This must be correctly mentioned in every XML instance.
CDA XML documents starts with the root element ''ClinicalDocument''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">


...

<component>
<structuredBody>
...
</structuredBody>
</component>

</ClinicalDocument>
</syntaxhighlight>

== Data types ==

=== Introduction ===

The following chapter describes the typical data types used in CDA implementation guides. For further information please refer to the HL7 V3 standard and its two parts concerning data types:
* Abstract Data type definition <ref>HL7 Version 3 Abstract Data type definition: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=264</ref>
* XML ITS for data types <ref>XML ITS for data types: https://www.hl7.org/documentcenter/public_temp_682D4D16-1C23-BA17-0C789BA52BEDB68E/wg/inm/datatypes-its-xml20050714.htm</ref>
Data types are properties of model class attributes and the basic building blocks of information in a CDA XML instance. For example, a model attribute named “time” has as its data type a time stamp “TS” (see Figure 1).

[[File:CDA_Core_Principles_Figure_1_CDA_Structure_Data_Types.png|700px]]

<ref group="Figure">CDA structure (left) and the data type specification (right)</ref> ''CDA structure (left) and the data type specification (right)''

=== XML representation of data types ===

Actual data is mostly carried in HL7 Version 3 by populating XML attributes and not as element content. Exceptions are names of persons and organizations as well as addresses.
The XML elements have names like the model attributes. For example, a model attribute “id” has a corresponding XML element named <id…>. The model determines the sequence of elements and their hierarchy. The data type itself determines the XML attributes within the start tag. The notation here is as follows:

{| class="hl7table"
|+
! Attribute !! DT !! Conf !! Description
|-
| (name of the model attribute or XML element) || Data type || Conformance, i.e. O, R, M || Textual description
|}

XML attributes (data type properties) are denoted as ''@attribute'' in order to distinguish their names from XML elements.

Example: in the example model above, the data type of the ''id'' attribute's is ''II'' (Instance Identifier). The corresponding XML attributes for that data type include ''@root'' and ''@extension''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id root="…" extension="..." />
</syntaxhighlight>

A description of the data types and their corresponding XML representation is contained in subsequent paragraphs of this guide.

==== Exceptions using XML element content ====

For most data types, the actual data is conveyed in XML attributes. However, there are some exceptions. For the data types binary (BIN), Encapsulated Data (ED), Entity Name (EN), Person Name (PN), Organization Name (ON), Trivial Name (TN), Address (AD) and character string data (ST), information is carried as element content.

Example: the components of an address <addr> are represented by sub elements with the data as element content (in the example shown in black).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr>
<streetAddressLine>Thormøhlens gate 12</streetAddressLine>
<postalCode>5006</postalCode>
<city>Bergen</city>
</addr>
</syntaxhighlight>

==== Combined data types ====

There are a number of socalled combined data types. For example, an interval with a lower and upper limit and a ratio that has a nominator and a denominator value.
In combined data types the substructure (e.g. <low> <high> in an interval) are represented as child elements of the relevant data type element.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110701"/>
<high value="20110729"/>
</effectiveTime>
</syntaxhighlight>

==== Conformance information ====

The conformance indicators distinguish kinds of conformance information described shortly here.

* '''O''': An optional item may be omitted if no data is present, i.e. no corresponding XML attribute or element is sent (marked as “O”)
* '''R''': For required items, lower cardinality is always zero or 1.
** Elements must be present and populated with data if present in the sending system. If no data is available (yet), a null flavor (see below) indicates and possibly classifies the missing information (marked as R).
** Attribute flagged as required must be present in the instance and populated.
* '''M''': For mandatory elements data must be sent and no missing values are allowed, i.e. if the sending system does not have information for mandatory elements the XML instance cannot be created and sent (marked as M).
* '''NP''': no data may be present at all (not permitted)
* '''C''': conditional conformance; typically a conformance table shows the circumstances (conditions) derived from information in the instance and the corresponding cardinalities and conformance statements.

=== Missing values (null flavor) ===

For every data type it is possible to specify a missing value including a kind of reason why data is missing. Instead of specifying any attribute of the corresponding element, a ''@nullFlavor'' attribute expresses the omission of data. Note that missing data is not allowed for mandatory elements (see above).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value nullFlavor="OTH"/>

<code nullFlavor="UNK"/>

<booleanInd nullFlavor="NI"/>

</syntaxhighlight>

The codes for the ''@nullFlavor'' attribute are drawn from the following hierarchical code system. It is a Coded Simple (CS), which means it has no code system (attribute ''@codeSystem'') specified.

{| class="hl7table"
|+<ref group="Table">NullFlavor</ref> ''NullFlavor''
! Code
! width=15% | Print Name
! Definition / Description
|-
| NI || No Information || No information whatsoever can be inferred from this exceptional value. This is the most general exceptional value. It is also the default exceptional value.
|-
| OTH || other || The actual value is not an element in the value domain of a variable. (e.g., concept not provided by required code system).
|-
| NINF || negative infinity || Negative infinity of numbers.
|-
| PINF || positive infinity || Positive infinity of numbers.
|-
| UNK || unknown || A proper value is applicable, but not known.
|-
| ASKU || asked but unknown || Information was sought but not found (e.g., patient was asked but didn't know)
|-
| NAV || temporarily unavailable || Information is not available at this time but it is expected that it will be available later.
|-
| NASK || not asked || This information has not been sought (e.g., patient was not asked)
|-
| TRC || trace || The content is greater than zero, but too small to be quantified.
|-
| MSK || masked || There is information on this item available but it has not been provided by the sender due to security, privacy or other reasons. There may be an alternate mechanism for gaining access to this information.
Note: using this null flavour does provide information that may be a breach of confidentiality, even though no detail data is provided. Its primary purpose is for those circumstances where it is necessary to inform the receiver that the information does exist without providing any detail.
|-
| NA || not applicable || No proper value is applicable in this context (e.g., last menstrual period for a male).
|-
| NP || not present || Value is not present in a message. This is only defined in messages, never in application data! All values not present in the message must be replaced by the applicable default, or no-information (NI) as the default of all defaults.
|}

=== ANY as the generic data type ===

This abstract data type is the basis for all other data types. Not a single value within a CDA document has the effective data type ANY, but any data type within HL7v3 is a specialization of ANY. This also means that any other data type inherits all properties of ANY (see [[#Missing_values_.28null_flavor.29|“Missing values (null flavor)”]]).

The ANY type is occasionally found in HL7 models when it comes to clinical finding etc. where – at model time – the actual data type of the value is not known. At instantiation time however, the actual data type ''is'' known and ANY is always replaced by a particular data type in an instance.

One example is the observation value (child element value in an observation), where in the model the data type of value cannot be anticipated. When instantiation is taking place, the data type is specified by the XML instance attribute ''@xsi:type''. This information can be used by the receiver to validate and process the value.

Attributes of an element with this data type are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@nullFlavor''' || <center>CS</center> || <center>–</center> || Classification of the missing value, see [[#Missing_values_.28null_flavor.29|3.3 Missing values (null flavor)]].
|}

{| class="hl7table" style="width:100%"
| width=8% | <center>[[File:Conformance.svg|50px]] dtr1-1-ANY</center> || If there is a ''nullFlavor'', there shall be no other attribute or element, unless it's ''nullFlavor="OTH"''. In that case ''@codeSystem'' or ''originalText'' (see “code” data types) may have a value.
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">

<value xsi:type="CE" code="N11.9" codeSystem="2.16.840.1.113883.6.3"/>


<value xsi:type="PQ" value="12" unit="mL"/>


<value xsi:type="ED">this is text</value>
</syntaxhighlight>

=== Boolean (BL) ===

Elements of this data type refer to Boolean logic and have an attribute ''@value''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>BL</center> || <center>–</center> || Valued as “true” or “false”
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<negationInd value="false"/>

<deceasedInd value="true"/>

</syntaxhighlight>

In some situations, the BL data does not apply to an XML element, but an attribute. In that case, the attribute carries the Boolean value directly.
<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<support contextConductionInd ="false">
...
</support>
</syntaxhighlight>

=== Instance Identifier (II) ===

This data type identifies instances of classes like observations or entities (persons, organizations). Attributes are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@extension''' || <center>ST</center> || <center>O</center> || Identification
|-
| '''@root''' || <center>OID</center> || <center>R</center> || Source of identification
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id extension="13234453645" root="2.16.840.1.113883.2.6.15.3.427.1"/>
</syntaxhighlight>

The ''@root'' attribute is of type OID (object identifier), a unique identifier of the issuing authority or system. For example, a patient with a patient number 13234453645 created by a specific healthcare provider organization is uniquely identified by the number itself in ''@extension'' and the OID of the organization or the sending system, in the example 2.16.840.1.113883.2.6.15.3.427.1 in ''@root''.
In some cases, a single OID identifies an object uniquely. In that situation, only ''@root'' is populated and ''@extension'' is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Encapsulated Data (ED) ===

Elements of this data type carry multimedia content. The actual multimedia content is represented as element content. There are two situations for the use of ED:

* Inline: The full data is transmitted in the type. This form is mainly used for text.
* By reference: a thumbnail is provided which links to the full data by reference.

In an instance, the data type is normally determined by an ''xsi:type'' specification and some attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@mediaType''' || <center>CS</center> || <center>O</center> || MIME media type classification. At time of writing this specification, the following MIME types are allowed:
* text/plain (plain text)
* text/html (text with html markup)
* image/jpeg (JPEG image)
* application/pdf (a PDF, portable document format)
* application/hl7-sda+xml (CDA documents).
|-
| '''@representation''' || <center>CS</center> || <center>O</center> || Representation of the multimedia content. At time of writing this specification, the following representations are allowed:
* TXT (text, this is the default)
* B64 base 64 encoded data, for example for embedded CDA documents).
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<text xsi:type="ED" mediaType="text/plain">
Patient treated sucessfully
</text>

<text mediaType="application/hl7-sda+xml" representation="B64">PD94bWw..etc..==</text>

</syntaxhighlight>

To include referenced data the two sub elements ''thumbnail'' and ''reference'' are used.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''reference''' || <center>TEL</center> || <center>0..*</center> || <center>O</center> || Link (URI) to full data
|-
| '''thumbnail''' || <center>ED</center> || <center>0..*</center> || <center>O</center> || Thumbnail of referenced data
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value xsi:type="ED" mediaType="image/png" representation="B64">
<reference value="http://radiology.bergen.no/xrays/128s.png"/>
<thumbnail mediaType="image/jpeg" representation="B64"> MNY...83== </thumbnail>
</value>
</syntaxhighlight>

=== Strings (ST) ===

This data type is a specialization of the ED type where ''@mediaType'' is fixed “text/plain” and ''@representation'' is fixed “TXT”. It allows conveying a character string as '''element content'''. This data type is used in other data types it like the ''@extension'' in instance identifiers, or address and person name data type components.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<lotNumber> 143GT6DT </lotNumber>
</syntaxhighlight>

=== Concept Descriptor (CD) ===

This data type specifies a concept by means of a code and its code system (except for situations where no code is available). A couple of specializations of data type CD exist, which differ in the main characteristics (properties) of the data type that may or may not be supported.

{| class="hl7table" style="width:50%"
|+ Table 1: Properties of data types used for codes
! <div style="text-align: right">DataType</div> !! CD !! CE !! CV !! CO !! CS
|-
! <div style="text-align: left">Property</div> !! !! !! !! !!
|-
| '''@code''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||<center>X</center>
|-
| '''@codeSystem''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''@codeSystemVersion''' || <center>X</center> || <center>X</center> || <center>X</center>|| <center>X</center> ||
|-
| '''@displayName''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''originalText''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''translation''' || <center>X</center> || <center>X</center> || || ||
|-
| '''qualifier''' || <center>X</center> || || || ||
|}

Because the CE variant is most used in practice, the general explanation of the properties will be given with de description of CE (see below).

The only attribute that is unique to CD is briefly explained here.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@qualifier''' || <center>CR</center> || <center>O</center> || An additional qualifier for the code.
|}

Complex terminologies like SNOMED CT can be used only using data type CD.

=== Coded with Equivalents (CE) ===

With elements of this data type, a concept by means of a code and its coding system (except for situations where no code is available) can be specified. It optionally contains one or more equivalents using other code systems.
It may contain the following attributes:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@code''' || <center>ST</center> || <center>R</center> || The actual code
|-
| '''@codeSystem''' || <center>OID</center> || <center>R</center> || required to identify the code system were the code is drawn from. This is an OID (object identifier, see [[#Object_Identifiers_.28OIDs.29|Object Identifiers at 4.1]])
|-
| '''@displayName''' || <center>ST</center> || <center>O</center> || Optional textual representation of code. A display name may be specified representing the plain text of the code. The information of this attribute may not be used by the receiving system for interpretation, but only for display purposes. The display name may never be transmitted without a code and must have the same meaning as the code.
|-
| '''@codeSystemName''' || <center>ST</center> || <center>O</center> || A textual representation of the name of the code system
|-
| '''@codeSystemVersion''' || <center>ST</center> || <center>O</center> || A textual representation of the version of the code system
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"/>

<code code="AU" codeSystem="2.16.840.1.113883.5.33"/>

<storageCode code="AC" codeSystem="2.16.840.1.113883.5.34" displayName="active"/>

<code code="A45.0" displayName="Somatisierungsstörung" codeSystem="1.2.276.0.76.5.409" codeSystemName="ICD-10 GM 2012"/>
</syntaxhighlight>

There are some child elements of codes that can be used to express what the “original text” was that was used for the coding or to indicate that there are “translations” to other code systems than the primary code.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''originalText''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Textual representation of the concept, actually a description which was used to create the actual code
|}

No semantics may be assumed other than showing the ''@displayName'' to a user to clarify the code. A display name cannot occur without its code and must carry the same meaning.

In case no code is known, it is allowed to specify a ''@nullFlavor'' for the code element and to give information about the (not yet coded) concept in original text. However, this should be an exception.

If other codes than the primary code need to be conveyed adding a translation child element can be used.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<originalText>minor aphthous stomatitis</originalText>
</code>
</syntaxhighlight>

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''translation''' || <center>CD</center> || <center>0..*</center> || <center>O</center> || Alternative code(s)
|}

A ''translation'' element is also of type CD and shall have a code and a code system identified. It shall point to the same concept as the primary code. It is allowed that a translation conveys less conceptual details than the original code.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<translation code="528.2" codeSystem="2.16.840.1.113883.6.2" codeSystemName="ICD9" displayName="Oral aphthae"/>
</code>
</syntaxhighlight>

=== Coded Value (CV) ===

This is actually a specialization of CE (see above), with the exception that neither ''originalText'' nor ''translation'' child element are allowed.

=== Coded Simple Value (CS) ===

This is actually a specialization of CE (see above), with no code system attribute and no original text or translation child element allowed. It specifies a concept by means of a code from a ''predefined'' code system (table) where the code is drawn from. This data type is usually applied in the context of fixed predefined HL7 tables.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<statusCode code="completed"/>
</syntaxhighlight>

In this example ''statusCode'' is bound in the underlying model to the specific code system ''ActStatus''. Because it is predefined by means of the vocabulary binding, ''@codeSystem'' is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Telecommunication Address (TEL) ===

Elements of this type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>ST</center> || <center>R</center> || carries strings that represent telecommunication contact information
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

The actual data is preceded by the scheme (refer to Internet Standard “RFC 1738 Uniform Resource Locators (URL)” <ref>RFC 1738 Uniform Resource Locators (URL): http://www.ietf.org/rfc/rfc1738.txt</ref>.

Examples:
* telephone (tel:),
* fax (fax:),
* email (mailto:).

It must follow the rules defined in Internet “RFC 2806 URLs for Telephone Calls” <ref>RFC 2806 URLs for Telephone Calls: http://www.ietf.org/rfc/rfc2806.txt</ref>.

The following codes will be used in the “use” attribute:
* H – Home
* WP – Work
* MC can be used (in addition to H or WP) to denote that this is a mobile phone.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257" />

<telecom use="H" value="tel:55354257" />

<telecom use="H" value="fax:56542558" />

<telecom value="tel:+41.34.21.4765342"/>

<telecom value="mailto:opr@opr-sem.no"/>

<telecom use="WP MC" value="tel:97555786" />
</syntaxhighlight>

It is possible to express the useable period of a telecommunication contact. A child element ''useablePeriod'' is used as a time interval to indicate this period.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''useablePeriod''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257">
<useablePeriod>
<high value="20111201"/>
</useablePeriod>
</telecom>
</syntaxhighlight>

=== Postal Address (AD) ===

Elements of this data type have a substructure in order to represent a structured address specification. In this implementation guide only a selection of all possible child elements is allowed, the original HL7 specification is richer.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''streetAddressLine''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Street address, includes street name and house number
|-
| '''city''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || City
|-
| '''postalCode''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Postal code
|-
| '''country''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Country
|-
|}

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that the sequence of the sub elements is country specific, i.e. it has to follow “common” rules how to write an address. For example, an UK address and a German address have different sequences of address representation.
|}

A ''@use'' attribute can also be specified.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="WP">
<streetAddressLine>Anna-Louisa-Karsch-Str. 2</streetAddressLine>
<postalCode>10178</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="H WP">
<streetAddressLine>Tatungasse 34</streetAddressLine>
<postalCode>10825</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

Also, a country may be specified using the element ''country''.

=== Person Name (PN) ===

Elements of this data type do also have a substructure to represent the parts of a person name, like family or given name and prefixes.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>
<given>Franz</given>
<given>Ingrun</given>
<family>Nordmann</family>
</name>
</syntaxhighlight>

Previous or birth or maiden names are supported using the ''validTime'' element. ''validTime'' (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]]) specifies the validity range of the name.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">

<name>
<given>Jan</given>
<given>Olaf</given>
<family>Hendrikson</family>
<validTime>
<high value="20000101"/>
</validTime>
</name>
</syntaxhighlight>

Note that the name attribute is repeating, i.e. multiple (types of) names could be sent. It is up to the receiver (based on the value of the ''@use'' attribute, and ''validTime'') to decide what name it wants to use or import in its database.

=== Organisation Name (ON) ===

Elements of this data type represent a name of an organization.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name> Charité Berlin </name>
</syntaxhighlight>

The optional ''validTime'' element (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]] may be used to specify the validity range of the name of the organization.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name of the organization
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>The old hospital
<validTime>
<high value="20111231235959"/>
</validTime>
</name>
</syntaxhighlight>

Please note that the use of ''validTime'' yields XML mixed content which should be avoid-ed if possible.

=== Integer Number (INT) ===

Elements of this data type are used to specify integer numbers and have one attribute.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>int</center> || <center>R</center> || Integer value
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<sequenceNumber value="24"/>
</syntaxhighlight>

=== Physical Quantities (PQ) ===

Elements of this data type are physical quantities, i.e. a measurable quantity (or countable) value from the physical world. This is different from just a “number”, because there is a (natural) unit specified in which the measurable quantity is expressed.
Examples:
* an amount of blood 20 ml (sample volume)
* a cut with a length of 10 cm (result observation)
* a dose of 200 milligrams per administration (dosing)
* delivery of 60 pieces of a tablet (amount supplied).
Elements of this data type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>real</center> || <center>R</center> || value of the measurement
|-
| '''@unit''' || <center>CS</center> || <center>R</center> || unit of measurement
|}

In the unit of measurement unit is expressed following the ''Unified Code for Units of Measure'' (UCUM) specification. This specification is a collection of atomic units, prefixes and a corresponding grammar for valid combinations to build all-natural units of measurement. For a complete description of possible units, see the ''Unified Code for Units of Measure'' <ref>Unified Code for Units of Measure: http://unitsofmeasure.org/</ref> specification.
If a value is not countable or if measurable, for example expressed in milligrams or liters, then this unit is a valid UCUM unit like “mg” or “L”. If a value is countable, for example the number of tablets, then this attribute contains “1”.
In HL7 it is required that all PQ data type units are valid UCUM units.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<value value="165" unit="cm"/>

<value value="81.1" unit="kg"/>

<value value="120" unit="mm[Hg]"/>

<value value="5" unit="1"/>
</syntaxhighlight>

=== Point in Time (TS) ===

Elements of this data type have the attribute

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>TS</center> || <center>R</center> || Point in time
|}

and specify points in time in the format YYYYMMDDhhmmss±ZZZZ, where
* YYYY is the four-digit year,
* MM the two-digit month,
* DD the two-digit day,
* hh the two-digit hour,
* mm the two-digits minute and
* ss the two-digit second.
Optional a time zone ZZZZ, the four-digit time alignment with a preceding “-” or a “+” can be specified. If time zone is omitted, local time is assumed.
The point in time may be right truncated in respect to the precision of the information.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<effectiveTime value="20140412"/>

<effectiveTime value="201409091245"/>

<effectiveTime value="1996"/>

<birthTime value="19540714"/>

<effectiveTime value="20140412+0100"/>
</syntaxhighlight>

=== Intervals (IVL) ===

Intervals are defined only for data types with an ordinal or interval scale type. There are several possibilities to determine an interval (see Figure 2), for example to specify

* a lower <low> and an upper boundary <high> (a),
* a lower <low> boundary and width <width> (b)
* an upper boundary and width <width> (c) or
* the middle of the interval <nowiki><center></nowiki> and a width <width> (d).

[[File:CDA_Core_Principles_Figure_2_Determining_Intervals.png|700px]]

<ref group="Figure">Several possibilities to determine closed intervals</ref> ''Several possibilities to determine closed intervals''

{{ConstraintBox|
To indicate an interval, only the following combinations are permitted.
(1) A lower and an upper boundary may not be identical, and their accuracy has to be equal.

Correct examples:

{{BeginGreenBox|}}
Interval from 5 to 6
Interval from 20110607 until 20110612
{{EndGreenBox}}

Incorrect examples:

{{BeginRedBox|}}
Interval from 5 to 6.0
Interval from 20110101 to 2011
{{EndRedBox|}}

(2) A lower boundary and a width

(3) A lower limit boundary

(4) A upper limit boundary

(5) Only the middle of the interval

(6) Only the width of an interval}}

Accordingly, four child elements are available.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Lower boundary
|-
| '''high''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Upper boundary
|-
| '''center''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Where ''(T)'' is defined in this specification as one of the data types “TS” or “PQ”.

=== Interval of time (IVL_TS) ===

Elements of this data type represent time intervals. There are four possible child elements.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Lower boundary (start date/time)
|-
| '''high''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Upper boundary (end date/time)
|-
| '''center''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Normally, a lower and an upper boundary is given, both are points in time. Also, it is possible to specify open intervals like “since June 14, 1999” (left boundary given only) or “until September 24, 2006” (right boundary given).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110507"/>
<high value="20110909"/>
</effectiveTime>

<effectiveTime>
<low value="20110507"/>
</effectiveTime>

<value>
<low value="20110101"/>
<width value="120" unit="d"/>
</value>

<value>
<center value="20110101"/>
</value>
</syntaxhighlight>

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|It must be noted that intervals of time stamps in HL7 are equally treated as other interval types (e.g. integers). The statement, one may take 1–3 tablets (interval of integers), for example, says that you are allowed to take no more than three tablets, not 3½ or 3.5 tablets. On the other hand, when treat the words “until 12 June 2011” regarding the upper interval limit differently, particularly we assume that the entire day 12 June is still in-cluded in this time interval.
Thus, in human perception time intervals are handled differently com-pared to such as number intervals. This is a situation may lead to inconsist-encies in standardized communication. As a conclusion, an upper limit “12 June 2011” means that only the very first moment of the 12 June is included in the interval, but not, for example, the 12 June 13:00 hours.
Interpretation does not depend on the accuracy of the time:
* “after 2004” means “from January 1, 2005 00:00:00.000”,
* “after 20041201” means “from 2 December 2004 00:00:00.000 hours”,
* and “after 200412011200” means “from 1 December 2004 12:01:00.000”.

As a result, you have to carefully consider the specification and implemen-tation of time intervals upper boundaries. In order to prevent mis-understandings intervals are always specified with the date and time for an upper limit that would cover the whole day. Accordingly, “201106122359” means 12 June 2011 throughout the day.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="201106122359"/>
</effectiveTime>
</syntaxhighlight>

Because of the equal treatment of time intervals this is applied also to the lower limit boundaries of time intervals as “0000”. This means for example that “since 9 June 2011” is expressed as “201106090000”.
|}

The <width> element is of data type PQ (physical quantity). The value obviously shall relate to a period of time and it is required to include a “time” unit. These are the units “us” (microseconds), “ms” (milliseconds), “s” (seconds), “min” (minute), “h” (hours), “d” (day), “wk” (week), “mo” (month) and “a” (year).

{{ConstraintBox|
For interval of time stamps the @unit of a ''low'' or ''high'' child element shall use units
* us (microseconds),
* ms (milliseconds),
* s (seconds),
* min (minute),
* h (hours),
* d (day),
* wk (week),
* mo (month) or
* a (year).
}}

=== Interval of physical quantities (IVL_PQ) ===

Elements of this data type are used to indicate intervals of physical quantities (see also [[#Physical Quantities (PQ)|3.18 Physical Quantities (PQ)]]). In general, an upper and a lower boundary is specified. It is also possible to use ''center'' instead of ''low'' and ''high''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low || <center>TS</center> || <center>0..1</center> || <center>C</center> || the lower limit of the interval (i.e. the minimum amount).
|-
| '''high || <center>TS</center> || <center>0..1</center> || <center>C</center> || the upper limit of the interval (i.e. the maximum amount).
|-
| '''center || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of the interval
|}

The ''center'' child element is used when there is no interval, but an exact value. Alternative would be to demote IVL_PQ to data type PQ and populate the element’s ''@value'' attribute, but this is more difficult to process in XML. That is why the use of the ''center'' child element is deprecated.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<referenceRange>
<low value="7.5" unit="mmol/l"/>
<high value="10" unit="mmol/l"/>
</referenceRange>

<doseQuantity>
<center value="9" unit="1"/>
</doseQuantity>
</syntaxhighlight>

=== Ratio of quantities (RTO_QTY_QTY) ===

Elements of this data type specify ratios and have two child elements, a numerator and a denominator. The underlying QTY (Quantity) data type is an abstract data type and in a XML instance it has to be replaced by a specific data type using the ''@xsi:type'' instruction (see below).

In this specification only “PQ” or “INT” are allowed for the demotion of both ''numerator'' and ''denominator''. The relevant child elements are:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''numerator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the numerator of the ratio
|-
| '''denominator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the denominator of the ratio
|}

If a model attribute already is a RTO_QTY_QTY, you need to specify (demote) the OTY abstract data type for both ''numerator'' and ''denominator'' by using an ''@xsi:type'' instruction.
In some cases where the model attribute is of type “ANY”, also the root element shall carry an ''@xsi:type'' RTO_QTY_QTY instruction.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<maxDoseQuantity>
<numerator xsi:type="PQ" value="6"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="400" unit="mg"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="5"/>
<denominator xsi:type="PQ" value="1" unit="h"/>
</maxDoseQuantity>

<value xsi:type="RTO_QTY_QTY">
<numerator xsi:type="INT" value="1"/>
<denominator xsi:type="INT" value="10000"/>
</value>
</syntaxhighlight>

== Identification mechanisms ==

=== Object Identifiers (OIDs) ===

Standardized exchange of information using messages or documents also deals with unique identifications of objects and concepts, especially in environments where sender and receiver do not “know” each other necessarily.

It is important to understand the difference between identification of instances (ids) and code concepts (classifications). Within the context of HL7 interactions OIDs are quite often used.
An id points to a specific instance of an object or identification scheme (a particular methodology for the identification of a class of objects), for example a specific person as the patient or a physician, a specific lab observation or an X-ray photo.

In contrast to instance identifiers, a classification identifies a specific concept. The type of patient (inpatient, outpatient), the type of doctor (an anesthesiologist), the codes for gender or a lab observation (blood cell count) may serve as examples.

OIDs (object identifiers) are worldwide unique identifiers for objects. They are used in HL7 to specify identifications and classifications. An object in this sense is persistent, well-defined information, definitions or specifications and is represented with ids or codes.

Commonly used OIDs (i.e. used for a purpose that is wider in scope than the regional healthcare organization; used in communications between healthcare regions) can be found in OIDs registries such as

* [http://www.oid-info.com www.oid-info.com],
* [http://www.hl7.org www.hl7.org],
* [http://www.hl7.org.uk/version3group/oids.asp HL7 OID registry in the UK],
* [https://www.dimdi.de/dynamic/de/klassifikationen/weitere-klassifikationen-und-standards/oid/ OID registry Germany].

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|All OIDs with an element of 999 or 9999 are for documentation purposes only. They will be replaced by permanent OIDs once these have been as-signed/found/applied for.
|}

OID (Object Identifiers) are unique identifiers for any kind of objects. They are defined in Rec. ITU-T X.660 | ISO/IEC 9834-1. This identification system for objects and concepts makes reliable electronic information exchange possible. Administration and Registration is regulated by a set of rules, described in the corresponding chapter of this document.

Every artefact in ART-DECOR has an Object Identifier (OID). There are recommendations for the management and the exchange of Object Identifiers, partially defined in ISO TS 13582 <ref>ISO TS 13582: https://www.iso.org/standard/69652.html</ref>.

''HL7 International'' has created a type ontology for the OIDs in the HL7 registry to make it easier for the user community to search for OIDs they may be looking for and can be found at hl7.org.

From a policy perspective it is common practice in several healthcare related OID registries (HL7 International at http://www.hl7.org, OID Registry Germany at http://www.dimdi.de, OID registry Switzerland at http://oid.refdata.ch, and OID registry Austria at https://www.gesundheit.gv.at/OID_Frontend) to distinguish at least between the following types of OIDs:

{| class="hl7table" style="width:60%"
|+<ref group="Table">Recommended OID sub-branches for different artefacts</ref> ''Recommended OID sub-branches for different artefacts''
! Arc !! Description
|-
| .3 || organizational bodies and groups
|-
| .4 || identifier systems and namespaces
|-
| .5 || code systems
|-
| .7 || document artefacts
|-
| .9 || conformance profiles
|-
| .10 || templates
|-
| .11 || value sets
|-
| .19 || examples
|-
| .99 || experimental
|}

''Example: given that “your” root OID is 1.2.3.4.5, the first value set of your governance group is then to be 1.2.3.4.5.11.1, with .11 as the value set “branch” and the last .1 as the first artefact of that kind.''

In ART-DECOR a project typically is set into the .77 branch of a governance group. When setting up the project, the OID for that project also determines the artefact OIDs using throughout the ART-DECOR project. The following additional branches are used to distinguish between different OID types:

{| class="hl7table"
|+<ref group="Table">Recommended OID sub-branches for ART-DECOR projects</ref> ''Recommended OID sub-branches for different artefacts''
! Artefact code Description !! Recommended !! OID suffix
|-
| DS || dataset || .77.1
|-
| DE || dataset concept || .77.2
|-
| SC || scenario || .77.3
|-
| TR || transaction in scenario || .77.4
|-
| CS || code system || .77.5
|-
| IS || issue || .77.6
|-
| AC || actor in scenario || .77.7
|-
| CL || concept list in dataset || .77.8
|-
| EL || element in template || .77.9
|-
| TM || template || .77.10
|-
| VS || value set || .77.11
|-
| RL || rule for instances || .77.12
|-
| SX || test/example scenario || .77.18
|-
| EX || test/example instance || .77.19
|-
| QX || qualification test/example || .77.20
|-
| TX || test/example data element || .77.21
|-
| CM || community || .77.22
|-
| MP || concept map || .77.24
|}

In ART-DECOR a newly created project uses these OID branches automatically.

=== Instance identification ===

Instance identification is done with the id element of a class. Its type is II (instance identifier) and described in the data type section above. For example, a patient number can be represented as
* 2.16.578.1.34.1.5432.1, the root-OID of the issuing authority, for example a system/application in a hospital, and
* 67543242 as the ''@extension'', representing the patient number within the system defined by the ''@root'' attribute.

=== Coding scheme identification ===

Coding schemes have to be uniquely identified using OIDs as well. All coding tables used in this implementation guide show the corresponding OID that has to be specified in the ''@codeSystem'' attribute of coded elements. Both attributes ''@code'' and ''@codeSystem'' together allows a correct interpretation of concept and code.

=== List of identification schemes ===

The following are OIDs for commonly used identification schemes.

{| class="hl7table"
|+<ref group="Table">Commonly used identification scheme OIDs</ref> ''Commonly used identification scheme OIDs''
! OID !! Identification System Name !! Description !! Issuer
|-
| 1.2.276.0.76.4.8 || KV-Nummer || Krankenversichertennummer ||
|-
| 1.2.276.0.76.4.17 || BSNR || Betriebsstättennummer ||
|-
| 1.2.276.0.76.4.16 || LANR || lebenslange Arztnummer ||
|}

=== List of code systems ===

The following are OIDs for code systems.

{| class="hl7table"
|+<ref group="Table">Commonly used code system OIDs</ref> ''Commonly used code system OIDs''
! OID !! Code System Name !! Description !! Issuer
|-
| 2.16.840.1.113883.6.1 || LOINC || Logical Observation Identifiers Names and Codes (LOINC) || Regenstrief Institute
|-
| 2.16.840.1.113883.6.96 || SNOMED CT || Systemized Nomenclature in Medicine Reference Terminology (SNOMED CT) || SNOMED International
|-
| 1.0.3166.1.2 || ISO 3166-1 (second edition) || Country codes as per ISO 3166-1:2007 || ISO
|}

== Vocabulary ==

=== Code Systems ===

Within HL7, a ''Code System'' is defined as a collection of codes with associated designations and meanings. Examples of code systems include ICD-10, SNOMED CT, and LOINC.
To meet the requirements of a code system as defined by HL7, a given code must resolve to one and only one meaning within the code system. Given this definition, each code table in the HL7 Version 3 standard represents a different code system since codes are sometimes used in different tables to have different meanings.
For example, “M” in the administrative gender table (''AdministrativeGender'', OID 2.16.840.1.113883.5.1) means “male”, while “M” in the marital status table (''MaritalStatus'', OID 2.16.840.1.113883.5.2) means “married”.
In this specification, code system tables are not presented in detail.

=== Value Sets ===

A ''Value Set'' represents a uniquely identifiable set of valid concept representations, where any concept representation can be tested to determine whether or not it is a member of the value set.
Value set complexity may range from a simple flat list of concept codes drawn from a single code system, to an unbounded hierarchical set of possibly post-coordinated expressions drawn from multiple code systems.
Value sets exist to constrain the content for a coded element in an HL7 static model or data type property. Value sets cannot have null content and must contain at least one concept representation where any given concept is generally (but not required to be) represented by only a single code within the Value Set.

[[File:CDA_Core_Principles_Figure_3_ValueSet_Example.png|800px]]

<ref group="Figure">Example presentation of the value set “MaritalStatus”</ref> ''Example presentation of the value set “MaritalStatus”''

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that value set OIDs never appear in a CDA Release 2 document. They are used for constraint expressions, for example in implementation guides.
In order to send a specific code drawn from a value set, the corresponding code system has to be conveyed.
An example, in the implementation specification the constraint on the model element ''maritalStatusCode'' is expressed as “to be drawn from value set 2.16.840.1.113883.5.2 ''MaritalStatus''”.
To actually send a marital status of “M” (married) that is shown in the value set figure above, the corresponding HL7 CDA instance would say:
<syntaxhighlight lang="xml">
<maritalStatusCode code="M" codeSystem="2.16.840.1.113883.5.2"/>
</syntaxhighlight>
|}

In this specification, value set tables are not presented in detail.

==== Binding strength ====

There is an optional vocabulary strength for data types that support that feature (coded concepts). Examples include CD, CE, CV and CO. Values are required, extensible, preferred and example. Default is required.

Please note: the formerly supported values CNE (Coded No Extensibility) and CWE (Coded With Extensibility) in ART-DECOR are deprecated as of December 2017. Specification CNE is handled as required and CWE is handled as extensible.

{| class="hl7table"
|+<ref group="Table">Binding Strengths</ref> ''Binding Strengths''
! Strength !! Description
|-
|required||Required/CNE. Coded with no exceptions; this element SHALL be from the specified value set
|-
|extensible||Extensible/CWE. Coded with Exceptions; this element SHALL be from the specified value set if any of the codes within the value set can apply to the concept being communicated. If the value set does not cover the concept (based on human review), alternate codings (or, data type allowing, text) may be included instead.
|-
|preferred||Preferred. Instances are encouraged to draw from the specified codes for interoperability purposes but are not required to do so to be considered conformant.
|-
|example||Example. Instances are not expected or even encouraged to draw from the specified value set. The value set merely provides examples of the types of concepts intended to be included.
|}

Mismatches with required lead to validation errors (SHALL logic). Mismatches with extensible lead to validation warnings (SHOULD logic). Mismatches with preferred lead to validation information messages (MAY logic). Mismatches with example don't have any validation consequences.

== Appendix ==

=== References ===

<references/>

=== List of figures ===

<references group="Figure" />

=== List of tables ===

<references group="Table" />

HL7 CDA Core Principles

2019-06-14T20:18:24Z

Dammon: /* Encapsulated Data (ED) */

== Introduction ==

This implementation guide specifies the ''Core Principles'' of using the ''Clinical Document Architecture'' <ref>Clinical Document Architecture Release 2: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=7</ref>.

=== Scope ===

This guide focuses on ''Data Types Release 1'' <ref>HL7 Data Types Release 1: http://www.hl7.org</ref>. Meanwhile an ISO specification ISO 21090 is out, also known as Data Type Release 2. The latter is subject to another implementation guide that will be published when ISO data types are used.

=== Focus of this document: HL7 Version 3 Data Types for CDA ===

The following chapters of this document will focus on the description of the data types and associated material. It will highlight the essentials in four chapters, all focusing on the Norwegian situation.
* '''Common aspects:''' explains common aspects of use of CDA and XML
* '''Data types:''' gives an overview and detailed specification of all data types used in CDA
* '''Identification schemes:''' explains major aspects of identification and the use in CDA
* '''Use of vocabulary:''' explains major aspects of vocabulary use in CDA.

=== Background ===

In many (European) countries, implementation guides for the use of data types in HL7 V3 are published. They take into account country specific constraints on the data types.

=== Legend of symbols ===

In this document several symbols are used.

{| class="hl7table" style="width:50%"
| [[File:Pfeil_rechts.png|50px]] || This is an important item
|-
| [[File:Issue.svg|50px]] || This is a known open issue
|-
| [[File:Faq.svg|50px]] || This is a frequently asked question (FAQ) with answer
|-
| [[File:Conformance.svg|50px]] || This is a constraint; in some situations also the rule identification is specified, e.g. dtr1-1-ANY, which links to the corresponding validation rule.
|}

=== Version history ===

{| class="hl7table" style="width:50%"
|+
! Version !! Date !! Description !! Author
|-
| 1.1 || 2019-04-24 || Refurbished guide based on earlier work || Kai U. Heitmann
|}

== Common aspects ==

=== Use of XML ===

HL7 Version 3 CDA uses the Extensible Markup Language (XML) as the exchange format. It is assumed that the reader is familiar with common XML aspects. However, some constraints are made regarding the use of CDA.

==== Character Set ====

{{ConstraintBox|
The character encoding of any CDA document shall be “UTF-8”.}}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="utf-8"?>
</syntaxhighlight>

=== CDA document structure ===

The XML namespace for CDA Release 2 documents is ''<nowiki>urn:hl7-org:v3</nowiki>''. This must be correctly mentioned in every XML instance.
CDA XML documents starts with the root element ''ClinicalDocument''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">


...

<component>
<structuredBody>
...
</structuredBody>
</component>

</ClinicalDocument>
</syntaxhighlight>

== Data types ==

=== Introduction ===

The following chapter describes the typical data types used in CDA implementation guides. For further information please refer to the HL7 V3 standard and its two parts concerning data types:
* Abstract Data type definition <ref>HL7 Version 3 Abstract Data type definition: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=264</ref>
* XML ITS for data types <ref>XML ITS for data types: https://www.hl7.org/documentcenter/public_temp_682D4D16-1C23-BA17-0C789BA52BEDB68E/wg/inm/datatypes-its-xml20050714.htm</ref>
Data types are properties of model class attributes and the basic building blocks of information in a CDA XML instance. For example, a model attribute named “time” has as its data type a time stamp “TS” (see Figure 1).

[[File:CDA_Core_Principles_Figure_1_CDA_Structure_Data_Types.png|700px]]

<ref group="Figure">CDA structure (left) and the data type specification (right)</ref> ''CDA structure (left) and the data type specification (right)''

=== XML representation of data types ===

Actual data is mostly carried in HL7 Version 3 by populating XML attributes and not as element content. Exceptions are names of persons and organizations as well as addresses.
The XML elements have names like the model attributes. For example, a model attribute “id” has a corresponding XML element named <id…>. The model determines the sequence of elements and their hierarchy. The data type itself determines the XML attributes within the start tag. The notation here is as follows:

{| class="hl7table"
|+
! Attribute !! DT !! Conf !! Description
|-
| (name of the model attribute or XML element) || Data type || Conformance, i.e. O, R, M || Textual description
|}

XML attributes (data type properties) are denoted as ''@attribute'' in order to distinguish their names from XML elements.

Example: in the example model above, the data type of the ''id'' attribute's is ''II'' (Instance Identifier). The corresponding XML attributes for that data type include ''@root'' and ''@extension''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id root="…" extension="..." />
</syntaxhighlight>

A description of the data types and their corresponding XML representation is contained in subsequent paragraphs of this guide.

==== Exceptions using XML element content ====

For most data types, the actual data is conveyed in XML attributes. However, there are some exceptions. For the data types binary (BIN), Encapsulated Data (ED), Entity Name (EN), Person Name (PN), Organization Name (ON), Trivial Name (TN), Address (AD) and character string data (ST), information is carried as element content.

Example: the components of an address <addr> are represented by sub elements with the data as element content (in the example shown in black).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr>
<streetAddressLine>Thormøhlens gate 12</streetAddressLine>
<postalCode>5006</postalCode>
<city>Bergen</city>
</addr>
</syntaxhighlight>

==== Combined data types ====

There are a number of socalled combined data types. For example, an interval with a lower and upper limit and a ratio that has a nominator and a denominator value.
In combined data types the substructure (e.g. <low> <high> in an interval) are represented as child elements of the relevant data type element.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110701"/>
<high value="20110729"/>
</effectiveTime>
</syntaxhighlight>

==== Conformance information ====

The conformance indicators distinguish kinds of conformance information described shortly here.

* '''O''': An optional item may be omitted if no data is present, i.e. no corresponding XML attribute or element is sent (marked as “O”)
* '''R''': For required items, lower cardinality is always zero or 1.
** Elements must be present and populated with data if present in the sending system. If no data is available (yet), a null flavor (see below) indicates and possibly classifies the missing information (marked as R).
** Attribute flagged as required must be present in the instance and populated.
* '''M''': For mandatory elements data must be sent and no missing values are allowed, i.e. if the sending system does not have information for mandatory elements the XML instance cannot be created and sent (marked as M).
* '''NP''': no data may be present at all (not permitted)
* '''C''': conditional conformance; typically a conformance table shows the circumstances (conditions) derived from information in the instance and the corresponding cardinalities and conformance statements.

=== Missing values (null flavor) ===

For every data type it is possible to specify a missing value including a kind of reason why data is missing. Instead of specifying any attribute of the corresponding element, a ''@nullFlavor'' attribute expresses the omission of data. Note that missing data is not allowed for mandatory elements (see above).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value nullFlavor="OTH"/>

<code nullFlavor="UNK"/>

<booleanInd nullFlavor="NI"/>

</syntaxhighlight>

The codes for the ''@nullFlavor'' attribute are drawn from the following hierarchical code system. It is a Coded Simple (CS), which means it has no code system (attribute ''@codeSystem'') specified.

{| class="hl7table"
|+<ref group="Table">NullFlavor</ref> ''NullFlavor''
! Code
! width=15% | Print Name
! Definition / Description
|-
| NI || No Information || No information whatsoever can be inferred from this exceptional value. This is the most general exceptional value. It is also the default exceptional value.
|-
| OTH || other || The actual value is not an element in the value domain of a variable. (e.g., concept not provided by required code system).
|-
| NINF || negative infinity || Negative infinity of numbers.
|-
| PINF || positive infinity || Positive infinity of numbers.
|-
| UNK || unknown || A proper value is applicable, but not known.
|-
| ASKU || asked but unknown || Information was sought but not found (e.g., patient was asked but didn't know)
|-
| NAV || temporarily unavailable || Information is not available at this time but it is expected that it will be available later.
|-
| NASK || not asked || This information has not been sought (e.g., patient was not asked)
|-
| TRC || trace || The content is greater than zero, but too small to be quantified.
|-
| MSK || masked || There is information on this item available but it has not been provided by the sender due to security, privacy or other reasons. There may be an alternate mechanism for gaining access to this information.
Note: using this null flavour does provide information that may be a breach of confidentiality, even though no detail data is provided. Its primary purpose is for those circumstances where it is necessary to inform the receiver that the information does exist without providing any detail.
|-
| NA || not applicable || No proper value is applicable in this context (e.g., last menstrual period for a male).
|-
| NP || not present || Value is not present in a message. This is only defined in messages, never in application data! All values not present in the message must be replaced by the applicable default, or no-information (NI) as the default of all defaults.
|}

=== ANY as the generic data type ===

This abstract data type is the basis for all other data types. Not a single value within a CDA document has the effective data type ANY, but any data type within HL7v3 is a specialization of ANY. This also means that any other data type inherits all properties of ANY (see [[#Missing_values_.28null_flavor.29|“Missing values (null flavor)”]]).

The ANY type is occasionally found in HL7 models when it comes to clinical finding etc. where – at model time – the actual data type of the value is not known. At instantiation time however, the actual data type ''is'' known and ANY is always replaced by a particular data type in an instance.

One example is the observation value (child element value in an observation), where in the model the data type of value cannot be anticipated. When instantiation is taking place, the data type is specified by the XML instance attribute ''@xsi:type''. This information can be used by the receiver to validate and process the value.

Attributes of an element with this data type are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@nullFlavor''' || <center>CS</center> || <center>–</center> || Classification of the missing value, see [[#Missing_values_.28null_flavor.29|3.3 Missing values (null flavor)]].
|}

{| class="hl7table" style="width:100%"
| width=8% | <center>[[File:Conformance.svg|50px]] dtr1-1-ANY</center> || If there is a ''nullFlavor'', there shall be no other attribute or element, unless it's ''nullFlavor="OTH"''. In that case ''@codeSystem'' or ''originalText'' (see “code” data types) may have a value.
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">

<value xsi:type="CE" code="N11.9" codeSystem="2.16.840.1.113883.6.3"/>


<value xsi:type="PQ" value="12" unit="mL"/>


<value xsi:type="ED">this is text</value>
</syntaxhighlight>

=== Boolean (BL) ===

Elements of this data type refer to Boolean logic and have an attribute ''@value''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>BL</center> || <center>–</center> || Valued as “true” or “false”
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<negationInd value="false"/>

<deceasedInd value="true"/>

</syntaxhighlight>

In some situations, the BL data does not apply to an XML element, but an attribute. In that case, the attribute carries the Boolean value directly.
<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<support contextConductionInd ="false">
...
</support>
</syntaxhighlight>

=== Instance Identifier (II) ===

This data type identifies instances of classes like observations or entities (persons, organizations). Attributes are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@extension''' || <center>ST</center> || <center>O</center> || Identification
|-
| '''@root''' || <center>OID</center> || <center>R</center> || Source of identification
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id extension="13234453645" root="2.16.840.1.113883.2.6.15.3.427.1"/>
</syntaxhighlight>

The ''@root'' attribute is of type OID (object identifier), a unique identifier of the issuing authority or system. For example, a patient with a patient number 13234453645 created by a specific healthcare provider organization is uniquely identified by the number itself in ''@extension'' and the OID of the organization or the sending system, in the example 2.16.840.1.113883.2.6.15.3.427.1 in ''@root''.
In some cases, a single OID identifies an object uniquely. In that situation, only ''@root'' is populated and ''@extension'' is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Encapsulated Data (ED) ===

Elements of this data type carry multimedia content. The actual multimedia content is represented as element content. There are two situations for the use of ED:

* Inline: The full data is transmitted in the type. This form is mainly used for text.
* By reference: a thumbnail is provided which links to the full data by reference.

In an instance, the data type is normally determined by an ''xsi:type'' specification and some attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@mediaType''' || <center>CS</center> || <center>O</center> || MIME media type classification. At time of writing this specification, the following MIME types are allowed:
* text/plain (plain text)
* text/html (text with html markup)
* image/jpeg (JPEG image)
* application/pdf (a PDF, portable document format)
* application/hl7-sda+xml (CDA documents).
|-
| '''@representation''' || <center>CS</center> || <center>O</center> || Representation of the multimedia content. At time of writing this specification, the following representations are allowed:
* TXT (text, this is the default)
* B64 base 64 encoded data, for example for embedded CDA documents).
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<text xsi:type="ED" mediaType="text/plain">
Patient treated sucessfully
</text>

<text mediaType="application/hl7-sda+xml" representation="B64">PD94bWw..etc..==</text>

</syntaxhighlight>

To include referenced data the two sub elements ''thumbnail'' and ''reference'' are used.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''reference''' || <center>TEL</center> || <center>0..*</center> || <center>O</center> || Link (URI) to full data
|-
| '''thumbnail''' || <center>ED</center> || <center>0..*</center> || <center>O</center> || Thumbnail of referenced data
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value xsi:type="ED" mediaType="image/png" representation="B64">
<reference value="http://radiology.bergen.no/xrays/128s.png"/>
<thumbnail mediaType="image/jpeg" representation="B64"> MNY...83== </thumbnail>
</value>
</syntaxhighlight>

=== Strings (ST) ===

This data type is a specialization of the ED type where ''@mediaType'' is fixed “text/plain” and ''@representation'' is fixed “TXT”. It allows conveying a character string as '''element content'''. This data type is used in other data types it like the ''@extension'' in instance identifiers, or address and person name data type components.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<lotNumber> 143GT6DT </lotNumber>
</syntaxhighlight>

=== Concept Descriptor (CD) ===

This data type specifies a concept by means of a code and its code system (except for situations where no code is available). A couple of specializations of data type CD exist, which differ in the main characteristics (properties) of the data type that may or may not be supported.

{| class="hl7table" style="width:50%"
|+ Table 1: Properties of data types used for codes
! <div style="text-align: right">DataType</div> !! CD !! CE !! CV !! CO !! CS
|-
! <div style="text-align: left">Property</div> !! !! !! !! !!
|-
| '''@code''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||<center>X</center>
|-
| '''@codeSystem''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''@codeSystemVersion''' || <center>X</center> || <center>X</center> || <center>X</center>|| <center>X</center> ||
|-
| '''@displayName''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''originalText''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''translation''' || <center>X</center> || <center>X</center> || || ||
|-
| '''qualifier''' || <center>X</center> || || || ||
|}

Because the CE variant is most used in practice, the general explanation of the proper-ties will be given with de description of CE (see below).
The only attribute that is unique to CD is briefly explained here.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@qualifier''' || <center>CR</center> || <center>O</center> || An additional qualifier for the code.
|}

Complex terminologies like SNOMED CT can be used only using data type CD.

=== Coded with Equivalents (CE) ===

With elements of this data type, a concept by means of a code and its coding system (except for situations where no code is available) can be specified. It optionally contains one or more equivalents using other code systems.
It may contain the following attributes:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@code''' || <center>ST</center> || <center>R</center> || The actual code
|-
| '''@codeSystem''' || <center>OID</center> || <center>R</center> || required to identify the code system were the code is drawn from. This is an OID (object identifier, see [[#Object_Identifiers_.28OIDs.29|Object Identifiers at 4.1]])
|-
| '''@displayName''' || <center>ST</center> || <center>O</center> || Optional textual representation of code. A display name may be specified representing the plain text of the code. The information of this attribute may not be used by the receiving system for interpretation, but only for display purposes. The display name may never be transmitted without a code and must have the same meaning as the code.
|-
| '''@codeSystemName''' || <center>ST</center> || <center>O</center> || A textual representation of the name of the code system
|-
| '''@codeSystemVersion''' || <center>ST</center> || <center>O</center> || A textual representation of the version of the code system
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"/>

<code code="AU" codeSystem="2.16.840.1.113883.5.33"/>

<storageCode code="AC" codeSystem="2.16.840.1.113883.5.34" displayName="active"/>

<code code="A45.0" displayName="Somatisierungsstörung" codeSystem="1.2.276.0.76.5.409" codeSystemName="ICD-10 GM 2012"/>
</syntaxhighlight>

There are some child elements of codes that can be used to express what the “original text” was that was used for the coding or to indicate that there are “translations” to other code systems than the primary code.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''originalText''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Textual representation of the concept, actually a description which was used to create the actual code
|}

No semantics may be assumed other than showing the ''@displayName'' to a user to clarify the code. A display name cannot occur without its code and must carry the same meaning.

In case no code is known, it is allowed to specify a ''@nullFlavor'' for the code element and to give information about the (not yet coded) concept in original text. However, this should be an exception.

If other codes than the primary code need to be conveyed adding a translation child element can be used.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<originalText>minor aphthous stomatitis</originalText>
</code>
</syntaxhighlight>

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''translation''' || <center>CD</center> || <center>0..*</center> || <center>O</center> || Alternative code(s)
|}

A ''translation'' element is also of type CD and shall have a code and a code system identified. It shall point to the same concept as the primary code. It is allowed that a translation conveys less conceptual details than the original code.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<translation code="528.2" codeSystem="2.16.840.1.113883.6.2" codeSystemName="ICD9" displayName="Oral aphthae"/>
</code>
</syntaxhighlight>

=== Coded Value (CV) ===

This is actually a specialization of CE (see above), with the exception that neither ''originalText'' nor ''translation'' child element are allowed.

=== Coded Simple Value (CS) ===

This is actually a specialization of CE (see above), with no code system attribute and no original text or translation child element allowed. It specifies a concept by means of a code from a ''predefined'' code system (table) where the code is drawn from. This data type is usually applied in the context of fixed predefined HL7 tables.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<statusCode code="completed"/>
</syntaxhighlight>

In this example ''statusCode'' is bound in the underlying model to the specific code system ''ActStatus''. Because it is predefined by means of the vocabulary binding, ''@codeSystem'' is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Telecommunication Address (TEL) ===

Elements of this type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>ST</center> || <center>R</center> || carries strings that represent telecommunication contact information
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

The actual data is preceded by the scheme (refer to Internet Standard “RFC 1738 Uniform Resource Locators (URL)” <ref>RFC 1738 Uniform Resource Locators (URL): http://www.ietf.org/rfc/rfc1738.txt</ref>.

Examples:
* telephone (tel:),
* fax (fax:),
* email (mailto:).

It must follow the rules defined in Internet “RFC 2806 URLs for Telephone Calls” <ref>RFC 2806 URLs for Telephone Calls: http://www.ietf.org/rfc/rfc2806.txt</ref>.

The following codes will be used in the “use” attribute:
* H – Home
* WP – Work
* MC can be used (in addition to H or WP) to denote that this is a mobile phone.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257" />

<telecom use="H" value="tel:55354257" />

<telecom use="H" value="fax:56542558" />

<telecom value="tel:+41.34.21.4765342"/>

<telecom value="mailto:opr@opr-sem.no"/>

<telecom use="WP MC" value="tel:97555786" />
</syntaxhighlight>

It is possible to express the useable period of a telecommunication contact. A child element ''useablePeriod'' is used as a time interval to indicate this period.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''useablePeriod''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257">
<useablePeriod>
<high value="20111201"/>
</useablePeriod>
</telecom>
</syntaxhighlight>

=== Postal Address (AD) ===

Elements of this data type have a substructure in order to represent a structured address specification. In this implementation guide only a selection of all possible child elements is allowed, the original HL7 specification is richer.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''streetAddressLine''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Street address, includes street name and house number
|-
| '''city''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || City
|-
| '''postalCode''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Postal code
|-
| '''country''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Country
|-
|}

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that the sequence of the sub elements is country specific, i.e. it has to follow “common” rules how to write an address. For example, an UK address and a German address have different sequences of address representation.
|}

A ''@use'' attribute can also be specified.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="WP">
<streetAddressLine>Anna-Louisa-Karsch-Str. 2</streetAddressLine>
<postalCode>10178</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="H WP">
<streetAddressLine>Tatungasse 34</streetAddressLine>
<postalCode>10825</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

Also, a country may be specified using the element ''country''.

=== Person Name (PN) ===

Elements of this data type do also have a substructure to represent the parts of a person name, like family or given name and prefixes.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>
<given>Franz</given>
<given>Ingrun</given>
<family>Nordmann</family>
</name>
</syntaxhighlight>

Previous or birth or maiden names are supported using the ''validTime'' element. ''validTime'' (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]]) specifies the validity range of the name.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">

<name>
<given>Jan</given>
<given>Olaf</given>
<family>Hendrikson</family>
<validTime>
<high value="20000101"/>
</validTime>
</name>
</syntaxhighlight>

Note that the name attribute is repeating, i.e. multiple (types of) names could be sent. It is up to the receiver (based on the value of the ''@use'' attribute, and ''validTime'') to decide what name it wants to use or import in its database.

=== Organisation Name (ON) ===

Elements of this data type represent a name of an organization.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name> Charité Berlin </name>
</syntaxhighlight>

The optional ''validTime'' element (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]] may be used to specify the validity range of the name of the organization.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name of the organization
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>The old hospital
<validTime>
<high value="20111231235959"/>
</validTime>
</name>
</syntaxhighlight>

Please note that the use of ''validTime'' yields XML mixed content which should be avoid-ed if possible.

=== Integer Number (INT) ===

Elements of this data type are used to specify integer numbers and have one attribute.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>int</center> || <center>R</center> || Integer value
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<sequenceNumber value="24"/>
</syntaxhighlight>

=== Physical Quantities (PQ) ===

Elements of this data type are physical quantities, i.e. a measurable quantity (or countable) value from the physical world. This is different from just a “number”, because there is a (natural) unit specified in which the measurable quantity is expressed.
Examples:
* an amount of blood 20 ml (sample volume)
* a cut with a length of 10 cm (result observation)
* a dose of 200 milligrams per administration (dosing)
* delivery of 60 pieces of a tablet (amount supplied).
Elements of this data type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>real</center> || <center>R</center> || value of the measurement
|-
| '''@unit''' || <center>CS</center> || <center>R</center> || unit of measurement
|}

In the unit of measurement unit is expressed following the ''Unified Code for Units of Measure'' (UCUM) specification. This specification is a collection of atomic units, prefixes and a corresponding grammar for valid combinations to build all-natural units of measurement. For a complete description of possible units, see the ''Unified Code for Units of Measure'' <ref>Unified Code for Units of Measure: http://unitsofmeasure.org/</ref> specification.
If a value is not countable or if measurable, for example expressed in milligrams or liters, then this unit is a valid UCUM unit like “mg” or “L”. If a value is countable, for example the number of tablets, then this attribute contains “1”.
In HL7 it is required that all PQ data type units are valid UCUM units.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<value value="165" unit="cm"/>

<value value="81.1" unit="kg"/>

<value value="120" unit="mm[Hg]"/>

<value value="5" unit="1"/>
</syntaxhighlight>

=== Point in Time (TS) ===

Elements of this data type have the attribute

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>TS</center> || <center>R</center> || Point in time
|}

and specify points in time in the format YYYYMMDDhhmmss±ZZZZ, where
* YYYY is the four-digit year,
* MM the two-digit month,
* DD the two-digit day,
* hh the two-digit hour,
* mm the two-digits minute and
* ss the two-digit second.
Optional a time zone ZZZZ, the four-digit time alignment with a preceding “-” or a “+” can be specified. If time zone is omitted, local time is assumed.
The point in time may be right truncated in respect to the precision of the information.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<effectiveTime value="20140412"/>

<effectiveTime value="201409091245"/>

<effectiveTime value="1996"/>

<birthTime value="19540714"/>

<effectiveTime value="20140412+0100"/>
</syntaxhighlight>

=== Intervals (IVL) ===

Intervals are defined only for data types with an ordinal or interval scale type. There are several possibilities to determine an interval (see Figure 2), for example to specify

* a lower <low> and an upper boundary <high> (a),
* a lower <low> boundary and width <width> (b)
* an upper boundary and width <width> (c) or
* the middle of the interval <nowiki><center></nowiki> and a width <width> (d).

[[File:CDA_Core_Principles_Figure_2_Determining_Intervals.png|700px]]

<ref group="Figure">Several possibilities to determine closed intervals</ref> ''Several possibilities to determine closed intervals''

{{ConstraintBox|
To indicate an interval, only the following combinations are permitted.
(1) A lower and an upper boundary may not be identical, and their accuracy has to be equal.

Correct examples:

{{BeginGreenBox|}}
Interval from 5 to 6
Interval from 20110607 until 20110612
{{EndGreenBox}}

Incorrect examples:

{{BeginRedBox|}}
Interval from 5 to 6.0
Interval from 20110101 to 2011
{{EndRedBox|}}

(2) A lower boundary and a width

(3) A lower limit boundary

(4) A upper limit boundary

(5) Only the middle of the interval

(6) Only the width of an interval}}

Accordingly, four child elements are available.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Lower boundary
|-
| '''high''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Upper boundary
|-
| '''center''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Where ''(T)'' is defined in this specification as one of the data types “TS” or “PQ”.

=== Interval of time (IVL_TS) ===

Elements of this data type represent time intervals. There are four possible child elements.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Lower boundary (start date/time)
|-
| '''high''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Upper boundary (end date/time)
|-
| '''center''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Normally, a lower and an upper boundary is given, both are points in time. Also, it is possible to specify open intervals like “since June 14, 1999” (left boundary given only) or “until September 24, 2006” (right boundary given).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110507"/>
<high value="20110909"/>
</effectiveTime>

<effectiveTime>
<low value="20110507"/>
</effectiveTime>

<value>
<low value="20110101"/>
<width value="120" unit="d"/>
</value>

<value>
<center value="20110101"/>
</value>
</syntaxhighlight>

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|It must be noted that intervals of time stamps in HL7 are equally treated as other interval types (e.g. integers). The statement, one may take 1–3 tablets (interval of integers), for example, says that you are allowed to take no more than three tablets, not 3½ or 3.5 tablets. On the other hand, when treat the words “until 12 June 2011” regarding the upper interval limit differently, particularly we assume that the entire day 12 June is still in-cluded in this time interval.
Thus, in human perception time intervals are handled differently com-pared to such as number intervals. This is a situation may lead to inconsist-encies in standardized communication. As a conclusion, an upper limit “12 June 2011” means that only the very first moment of the 12 June is included in the interval, but not, for example, the 12 June 13:00 hours.
Interpretation does not depend on the accuracy of the time:
* “after 2004” means “from January 1, 2005 00:00:00.000”,
* “after 20041201” means “from 2 December 2004 00:00:00.000 hours”,
* and “after 200412011200” means “from 1 December 2004 12:01:00.000”.

As a result, you have to carefully consider the specification and implemen-tation of time intervals upper boundaries. In order to prevent mis-understandings intervals are always specified with the date and time for an upper limit that would cover the whole day. Accordingly, “201106122359” means 12 June 2011 throughout the day.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="201106122359"/>
</effectiveTime>
</syntaxhighlight>

Because of the equal treatment of time intervals this is applied also to the lower limit boundaries of time intervals as “0000”. This means for example that “since 9 June 2011” is expressed as “201106090000”.
|}

The <width> element is of data type PQ (physical quantity). The value obviously shall relate to a period of time and it is required to include a “time” unit. These are the units “us” (microseconds), “ms” (milliseconds), “s” (seconds), “min” (minute), “h” (hours), “d” (day), “wk” (week), “mo” (month) and “a” (year).

{{ConstraintBox|
For interval of time stamps the @unit of a ''low'' or ''high'' child element shall use units
* us (microseconds),
* ms (milliseconds),
* s (seconds),
* min (minute),
* h (hours),
* d (day),
* wk (week),
* mo (month) or
* a (year).
}}

=== Interval of physical quantities (IVL_PQ) ===

Elements of this data type are used to indicate intervals of physical quantities (see also [[#Physical Quantities (PQ)|3.18 Physical Quantities (PQ)]]). In general, an upper and a lower boundary is specified. It is also possible to use ''center'' instead of ''low'' and ''high''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low || <center>TS</center> || <center>0..1</center> || <center>C</center> || the lower limit of the interval (i.e. the minimum amount).
|-
| '''high || <center>TS</center> || <center>0..1</center> || <center>C</center> || the upper limit of the interval (i.e. the maximum amount).
|-
| '''center || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of the interval
|}

The ''center'' child element is used when there is no interval, but an exact value. Alternative would be to demote IVL_PQ to data type PQ and populate the element’s ''@value'' attribute, but this is more difficult to process in XML. That is why the use of the ''center'' child element is deprecated.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<referenceRange>
<low value="7.5" unit="mmol/l"/>
<high value="10" unit="mmol/l"/>
</referenceRange>

<doseQuantity>
<center value="9" unit="1"/>
</doseQuantity>
</syntaxhighlight>

=== Ratio of quantities (RTO_QTY_QTY) ===

Elements of this data type specify ratios and have two child elements, a numerator and a denominator. The underlying QTY (Quantity) data type is an abstract data type and in a XML instance it has to be replaced by a specific data type using the ''@xsi:type'' instruction (see below).

In this specification only “PQ” or “INT” are allowed for the demotion of both ''numerator'' and ''denominator''. The relevant child elements are:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''numerator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the numerator of the ratio
|-
| '''denominator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the denominator of the ratio
|}

If a model attribute already is a RTO_QTY_QTY, you need to specify (demote) the OTY abstract data type for both ''numerator'' and ''denominator'' by using an ''@xsi:type'' instruction.
In some cases where the model attribute is of type “ANY”, also the root element shall carry an ''@xsi:type'' RTO_QTY_QTY instruction.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<maxDoseQuantity>
<numerator xsi:type="PQ" value="6"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="400" unit="mg"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="5"/>
<denominator xsi:type="PQ" value="1" unit="h"/>
</maxDoseQuantity>

<value xsi:type="RTO_QTY_QTY">
<numerator xsi:type="INT" value="1"/>
<denominator xsi:type="INT" value="10000"/>
</value>
</syntaxhighlight>

== Identification mechanisms ==

=== Object Identifiers (OIDs) ===

Standardized exchange of information using messages or documents also deals with unique identifications of objects and concepts, especially in environments where sender and receiver do not “know” each other necessarily.

It is important to understand the difference between identification of instances (ids) and code concepts (classifications). Within the context of HL7 interactions OIDs are quite often used.
An id points to a specific instance of an object or identification scheme (a particular methodology for the identification of a class of objects), for example a specific person as the patient or a physician, a specific lab observation or an X-ray photo.

In contrast to instance identifiers, a classification identifies a specific concept. The type of patient (inpatient, outpatient), the type of doctor (an anesthesiologist), the codes for gender or a lab observation (blood cell count) may serve as examples.

OIDs (object identifiers) are worldwide unique identifiers for objects. They are used in HL7 to specify identifications and classifications. An object in this sense is persistent, well-defined information, definitions or specifications and is represented with ids or codes.

Commonly used OIDs (i.e. used for a purpose that is wider in scope than the regional healthcare organization; used in communications between healthcare regions) can be found in OIDs registries such as

* [http://www.oid-info.com www.oid-info.com],
* [http://www.hl7.org www.hl7.org],
* [http://www.hl7.org.uk/version3group/oids.asp HL7 OID registry in the UK],
* [https://www.dimdi.de/dynamic/de/klassifikationen/weitere-klassifikationen-und-standards/oid/ OID registry Germany].

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|All OIDs with an element of 999 or 9999 are for documentation purposes only. They will be replaced by permanent OIDs once these have been as-signed/found/applied for.
|}

OID (Object Identifiers) are unique identifiers for any kind of objects. They are defined in Rec. ITU-T X.660 | ISO/IEC 9834-1. This identification system for objects and concepts makes reliable electronic information exchange possible. Administration and Registration is regulated by a set of rules, described in the corresponding chapter of this document.

Every artefact in ART-DECOR has an Object Identifier (OID). There are recommendations for the management and the exchange of Object Identifiers, partially defined in ISO TS 13582 <ref>ISO TS 13582: https://www.iso.org/standard/69652.html</ref>.

''HL7 International'' has created a type ontology for the OIDs in the HL7 registry to make it easier for the user community to search for OIDs they may be looking for and can be found at hl7.org.

From a policy perspective it is common practice in several healthcare related OID registries (HL7 International at http://www.hl7.org, OID Registry Germany at http://www.dimdi.de, OID registry Switzerland at http://oid.refdata.ch, and OID registry Austria at https://www.gesundheit.gv.at/OID_Frontend) to distinguish at least between the following types of OIDs:

{| class="hl7table" style="width:60%"
|+<ref group="Table">Recommended OID sub-branches for different artefacts</ref> ''Recommended OID sub-branches for different artefacts''
! Arc !! Description
|-
| .3 || organizational bodies and groups
|-
| .4 || identifier systems and namespaces
|-
| .5 || code systems
|-
| .7 || document artefacts
|-
| .9 || conformance profiles
|-
| .10 || templates
|-
| .11 || value sets
|-
| .19 || examples
|-
| .99 || experimental
|}

''Example: given that “your” root OID is 1.2.3.4.5, the first value set of your governance group is then to be 1.2.3.4.5.11.1, with .11 as the value set “branch” and the last .1 as the first artefact of that kind.''

In ART-DECOR a project typically is set into the .77 branch of a governance group. When setting up the project, the OID for that project also determines the artefact OIDs using throughout the ART-DECOR project. The following additional branches are used to distinguish between different OID types:

{| class="hl7table"
|+<ref group="Table">Recommended OID sub-branches for ART-DECOR projects</ref> ''Recommended OID sub-branches for different artefacts''
! Artefact code Description !! Recommended !! OID suffix
|-
| DS || dataset || .77.1
|-
| DE || dataset concept || .77.2
|-
| SC || scenario || .77.3
|-
| TR || transaction in scenario || .77.4
|-
| CS || code system || .77.5
|-
| IS || issue || .77.6
|-
| AC || actor in scenario || .77.7
|-
| CL || concept list in dataset || .77.8
|-
| EL || element in template || .77.9
|-
| TM || template || .77.10
|-
| VS || value set || .77.11
|-
| RL || rule for instances || .77.12
|-
| SX || test/example scenario || .77.18
|-
| EX || test/example instance || .77.19
|-
| QX || qualification test/example || .77.20
|-
| TX || test/example data element || .77.21
|-
| CM || community || .77.22
|-
| MP || concept map || .77.24
|}

In ART-DECOR a newly created project uses these OID branches automatically.

=== Instance identification ===

Instance identification is done with the id element of a class. Its type is II (instance identifier) and described in the data type section above. For example, a patient number can be represented as
* 2.16.578.1.34.1.5432.1, the root-OID of the issuing authority, for example a system/application in a hospital, and
* 67543242 as the ''@extension'', representing the patient number within the system defined by the ''@root'' attribute.

=== Coding scheme identification ===

Coding schemes have to be uniquely identified using OIDs as well. All coding tables used in this implementation guide show the corresponding OID that has to be specified in the ''@codeSystem'' attribute of coded elements. Both attributes ''@code'' and ''@codeSystem'' together allows a correct interpretation of concept and code.

=== List of identification schemes ===

The following are OIDs for commonly used identification schemes.

{| class="hl7table"
|+<ref group="Table">Commonly used identification scheme OIDs</ref> ''Commonly used identification scheme OIDs''
! OID !! Identification System Name !! Description !! Issuer
|-
| 1.2.276.0.76.4.8 || KV-Nummer || Krankenversichertennummer ||
|-
| 1.2.276.0.76.4.17 || BSNR || Betriebsstättennummer ||
|-
| 1.2.276.0.76.4.16 || LANR || lebenslange Arztnummer ||
|}

=== List of code systems ===

The following are OIDs for code systems.

{| class="hl7table"
|+<ref group="Table">Commonly used code system OIDs</ref> ''Commonly used code system OIDs''
! OID !! Code System Name !! Description !! Issuer
|-
| 2.16.840.1.113883.6.1 || LOINC || Logical Observation Identifiers Names and Codes (LOINC) || Regenstrief Institute
|-
| 2.16.840.1.113883.6.96 || SNOMED CT || Systemized Nomenclature in Medicine Reference Terminology (SNOMED CT) || SNOMED International
|-
| 1.0.3166.1.2 || ISO 3166-1 (second edition) || Country codes as per ISO 3166-1:2007 || ISO
|}

== Vocabulary ==

=== Code Systems ===

Within HL7, a ''Code System'' is defined as a collection of codes with associated designations and meanings. Examples of code systems include ICD-10, SNOMED CT, and LOINC.
To meet the requirements of a code system as defined by HL7, a given code must resolve to one and only one meaning within the code system. Given this definition, each code table in the HL7 Version 3 standard represents a different code system since codes are sometimes used in different tables to have different meanings.
For example, “M” in the administrative gender table (''AdministrativeGender'', OID 2.16.840.1.113883.5.1) means “male”, while “M” in the marital status table (''MaritalStatus'', OID 2.16.840.1.113883.5.2) means “married”.
In this specification, code system tables are not presented in detail.

=== Value Sets ===

A ''Value Set'' represents a uniquely identifiable set of valid concept representations, where any concept representation can be tested to determine whether or not it is a member of the value set.
Value set complexity may range from a simple flat list of concept codes drawn from a single code system, to an unbounded hierarchical set of possibly post-coordinated expressions drawn from multiple code systems.
Value sets exist to constrain the content for a coded element in an HL7 static model or data type property. Value sets cannot have null content and must contain at least one concept representation where any given concept is generally (but not required to be) represented by only a single code within the Value Set.

[[File:CDA_Core_Principles_Figure_3_ValueSet_Example.png|800px]]

<ref group="Figure">Example presentation of the value set “MaritalStatus”</ref> ''Example presentation of the value set “MaritalStatus”''

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that value set OIDs never appear in a CDA Release 2 document. They are used for constraint expressions, for example in implementation guides.
In order to send a specific code drawn from a value set, the corresponding code system has to be conveyed.
An example, in the implementation specification the constraint on the model element ''maritalStatusCode'' is expressed as “to be drawn from value set 2.16.840.1.113883.5.2 ''MaritalStatus''”.
To actually send a marital status of “M” (married) that is shown in the value set figure above, the corresponding HL7 CDA instance would say:
<syntaxhighlight lang="xml">
<maritalStatusCode code="M" codeSystem="2.16.840.1.113883.5.2"/>
</syntaxhighlight>
|}

In this specification, value set tables are not presented in detail.

==== Binding strength ====

There is an optional vocabulary strength for data types that support that feature (coded concepts). Examples include CD, CE, CV and CO. Values are required, extensible, preferred and example. Default is required.

Please note: the formerly supported values CNE (Coded No Extensibility) and CWE (Coded With Extensibility) in ART-DECOR are deprecated as of December 2017. Specification CNE is handled as required and CWE is handled as extensible.

{| class="hl7table"
|+<ref group="Table">Binding Strengths</ref> ''Binding Strengths''
! Strength !! Description
|-
|required||Required/CNE. Coded with no exceptions; this element SHALL be from the specified value set
|-
|extensible||Extensible/CWE. Coded with Exceptions; this element SHALL be from the specified value set if any of the codes within the value set can apply to the concept being communicated. If the value set does not cover the concept (based on human review), alternate codings (or, data type allowing, text) may be included instead.
|-
|preferred||Preferred. Instances are encouraged to draw from the specified codes for interoperability purposes but are not required to do so to be considered conformant.
|-
|example||Example. Instances are not expected or even encouraged to draw from the specified value set. The value set merely provides examples of the types of concepts intended to be included.
|}

Mismatches with required lead to validation errors (SHALL logic). Mismatches with extensible lead to validation warnings (SHOULD logic). Mismatches with preferred lead to validation information messages (MAY logic). Mismatches with example don't have any validation consequences.

== Appendix ==

=== References ===

<references/>

=== List of figures ===

<references group="Figure" />

=== List of tables ===

<references group="Table" />

HL7 CDA Core Principles

2019-06-14T20:17:07Z

Dammon: /* XML representation of data types */

== Introduction ==

This implementation guide specifies the ''Core Principles'' of using the ''Clinical Document Architecture'' <ref>Clinical Document Architecture Release 2: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=7</ref>.

=== Scope ===

This guide focuses on ''Data Types Release 1'' <ref>HL7 Data Types Release 1: http://www.hl7.org</ref>. Meanwhile an ISO specification ISO 21090 is out, also known as Data Type Release 2. The latter is subject to another implementation guide that will be published when ISO data types are used.

=== Focus of this document: HL7 Version 3 Data Types for CDA ===

The following chapters of this document will focus on the description of the data types and associated material. It will highlight the essentials in four chapters, all focusing on the Norwegian situation.
* '''Common aspects:''' explains common aspects of use of CDA and XML
* '''Data types:''' gives an overview and detailed specification of all data types used in CDA
* '''Identification schemes:''' explains major aspects of identification and the use in CDA
* '''Use of vocabulary:''' explains major aspects of vocabulary use in CDA.

=== Background ===

In many (European) countries, implementation guides for the use of data types in HL7 V3 are published. They take into account country specific constraints on the data types.

=== Legend of symbols ===

In this document several symbols are used.

{| class="hl7table" style="width:50%"
| [[File:Pfeil_rechts.png|50px]] || This is an important item
|-
| [[File:Issue.svg|50px]] || This is a known open issue
|-
| [[File:Faq.svg|50px]] || This is a frequently asked question (FAQ) with answer
|-
| [[File:Conformance.svg|50px]] || This is a constraint; in some situations also the rule identification is specified, e.g. dtr1-1-ANY, which links to the corresponding validation rule.
|}

=== Version history ===

{| class="hl7table" style="width:50%"
|+
! Version !! Date !! Description !! Author
|-
| 1.1 || 2019-04-24 || Refurbished guide based on earlier work || Kai U. Heitmann
|}

== Common aspects ==

=== Use of XML ===

HL7 Version 3 CDA uses the Extensible Markup Language (XML) as the exchange format. It is assumed that the reader is familiar with common XML aspects. However, some constraints are made regarding the use of CDA.

==== Character Set ====

{{ConstraintBox|
The character encoding of any CDA document shall be “UTF-8”.}}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="utf-8"?>
</syntaxhighlight>

=== CDA document structure ===

The XML namespace for CDA Release 2 documents is ''<nowiki>urn:hl7-org:v3</nowiki>''. This must be correctly mentioned in every XML instance.
CDA XML documents starts with the root element ''ClinicalDocument''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">


...

<component>
<structuredBody>
...
</structuredBody>
</component>

</ClinicalDocument>
</syntaxhighlight>

== Data types ==

=== Introduction ===

The following chapter describes the typical data types used in CDA implementation guides. For further information please refer to the HL7 V3 standard and its two parts concerning data types:
* Abstract Data type definition <ref>HL7 Version 3 Abstract Data type definition: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=264</ref>
* XML ITS for data types <ref>XML ITS for data types: https://www.hl7.org/documentcenter/public_temp_682D4D16-1C23-BA17-0C789BA52BEDB68E/wg/inm/datatypes-its-xml20050714.htm</ref>
Data types are properties of model class attributes and the basic building blocks of information in a CDA XML instance. For example, a model attribute named “time” has as its data type a time stamp “TS” (see Figure 1).

[[File:CDA_Core_Principles_Figure_1_CDA_Structure_Data_Types.png|700px]]

<ref group="Figure">CDA structure (left) and the data type specification (right)</ref> ''CDA structure (left) and the data type specification (right)''

=== XML representation of data types ===

Actual data is mostly carried in HL7 Version 3 by populating XML attributes and not as element content. Exceptions are names of persons and organizations as well as addresses.
The XML elements have names like the model attributes. For example, a model attribute “id” has a corresponding XML element named <id…>. The model determines the sequence of elements and their hierarchy. The data type itself determines the XML attributes within the start tag. The notation here is as follows:

{| class="hl7table"
|+
! Attribute !! DT !! Conf !! Description
|-
| (name of the model attribute or XML element) || Data type || Conformance, i.e. O, R, M || Textual description
|}

XML attributes (data type properties) are denoted as ''@attribute'' in order to distinguish their names from XML elements.

Example: in the example model above, the data type of the ''id'' attribute's is ''II'' (Instance Identifier). The corresponding XML attributes for that data type include ''@root'' and ''@extension''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id root="…" extension="..." />
</syntaxhighlight>

A description of the data types and their corresponding XML representation is contained in subsequent paragraphs of this guide.

==== Exceptions using XML element content ====

For most data types, the actual data is conveyed in XML attributes. However, there are some exceptions. For the data types binary (BIN), Encapsulated Data (ED), Entity Name (EN), Person Name (PN), Organization Name (ON), Trivial Name (TN), Address (AD) and character string data (ST), information is carried as element content.

Example: the components of an address <addr> are represented by sub elements with the data as element content (in the example shown in black).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr>
<streetAddressLine>Thormøhlens gate 12</streetAddressLine>
<postalCode>5006</postalCode>
<city>Bergen</city>
</addr>
</syntaxhighlight>

==== Combined data types ====

There are a number of socalled combined data types. For example, an interval with a lower and upper limit and a ratio that has a nominator and a denominator value.
In combined data types the substructure (e.g. <low> <high> in an interval) are represented as child elements of the relevant data type element.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110701"/>
<high value="20110729"/>
</effectiveTime>
</syntaxhighlight>

==== Conformance information ====

The conformance indicators distinguish kinds of conformance information described shortly here.

* '''O''': An optional item may be omitted if no data is present, i.e. no corresponding XML attribute or element is sent (marked as “O”)
* '''R''': For required items, lower cardinality is always zero or 1.
** Elements must be present and populated with data if present in the sending system. If no data is available (yet), a null flavor (see below) indicates and possibly classifies the missing information (marked as R).
** Attribute flagged as required must be present in the instance and populated.
* '''M''': For mandatory elements data must be sent and no missing values are allowed, i.e. if the sending system does not have information for mandatory elements the XML instance cannot be created and sent (marked as M).
* '''NP''': no data may be present at all (not permitted)
* '''C''': conditional conformance; typically a conformance table shows the circumstances (conditions) derived from information in the instance and the corresponding cardinalities and conformance statements.

=== Missing values (null flavor) ===

For every data type it is possible to specify a missing value including a kind of reason why data is missing. Instead of specifying any attribute of the corresponding element, a ''@nullFlavor'' attribute expresses the omission of data. Note that missing data is not allowed for mandatory elements (see above).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value nullFlavor="OTH"/>

<code nullFlavor="UNK"/>

<booleanInd nullFlavor="NI"/>

</syntaxhighlight>

The codes for the ''@nullFlavor'' attribute are drawn from the following hierarchical code system. It is a Coded Simple (CS), which means it has no code system (attribute ''@codeSystem'') specified.

{| class="hl7table"
|+<ref group="Table">NullFlavor</ref> ''NullFlavor''
! Code
! width=15% | Print Name
! Definition / Description
|-
| NI || No Information || No information whatsoever can be inferred from this exceptional value. This is the most general exceptional value. It is also the default exceptional value.
|-
| OTH || other || The actual value is not an element in the value domain of a variable. (e.g., concept not provided by required code system).
|-
| NINF || negative infinity || Negative infinity of numbers.
|-
| PINF || positive infinity || Positive infinity of numbers.
|-
| UNK || unknown || A proper value is applicable, but not known.
|-
| ASKU || asked but unknown || Information was sought but not found (e.g., patient was asked but didn't know)
|-
| NAV || temporarily unavailable || Information is not available at this time but it is expected that it will be available later.
|-
| NASK || not asked || This information has not been sought (e.g., patient was not asked)
|-
| TRC || trace || The content is greater than zero, but too small to be quantified.
|-
| MSK || masked || There is information on this item available but it has not been provided by the sender due to security, privacy or other reasons. There may be an alternate mechanism for gaining access to this information.
Note: using this null flavour does provide information that may be a breach of confidentiality, even though no detail data is provided. Its primary purpose is for those circumstances where it is necessary to inform the receiver that the information does exist without providing any detail.
|-
| NA || not applicable || No proper value is applicable in this context (e.g., last menstrual period for a male).
|-
| NP || not present || Value is not present in a message. This is only defined in messages, never in application data! All values not present in the message must be replaced by the applicable default, or no-information (NI) as the default of all defaults.
|}

=== ANY as the generic data type ===

This abstract data type is the basis for all other data types. Not a single value within a CDA document has the effective data type ANY, but any data type within HL7v3 is a specialization of ANY. This also means that any other data type inherits all properties of ANY (see [[#Missing_values_.28null_flavor.29|“Missing values (null flavor)”]]).

The ANY type is occasionally found in HL7 models when it comes to clinical finding etc. where – at model time – the actual data type of the value is not known. At instantiation time however, the actual data type ''is'' known and ANY is always replaced by a particular data type in an instance.

One example is the observation value (child element value in an observation), where in the model the data type of value cannot be anticipated. When instantiation is taking place, the data type is specified by the XML instance attribute ''@xsi:type''. This information can be used by the receiver to validate and process the value.

Attributes of an element with this data type are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@nullFlavor''' || <center>CS</center> || <center>–</center> || Classification of the missing value, see [[#Missing_values_.28null_flavor.29|3.3 Missing values (null flavor)]].
|}

{| class="hl7table" style="width:100%"
| width=8% | <center>[[File:Conformance.svg|50px]] dtr1-1-ANY</center> || If there is a ''nullFlavor'', there shall be no other attribute or element, unless it's ''nullFlavor="OTH"''. In that case ''@codeSystem'' or ''originalText'' (see “code” data types) may have a value.
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">

<value xsi:type="CE" code="N11.9" codeSystem="2.16.840.1.113883.6.3"/>


<value xsi:type="PQ" value="12" unit="mL"/>


<value xsi:type="ED">this is text</value>
</syntaxhighlight>

=== Boolean (BL) ===

Elements of this data type refer to Boolean logic and have an attribute ''@value''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>BL</center> || <center>–</center> || Valued as “true” or “false”
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<negationInd value="false"/>

<deceasedInd value="true"/>

</syntaxhighlight>

In some situations, the BL data does not apply to an XML element, but an attribute. In that case, the attribute carries the Boolean value directly.
<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<support contextConductionInd ="false">
...
</support>
</syntaxhighlight>

=== Instance Identifier (II) ===

This data type identifies instances of classes like observations or entities (persons, organizations). Attributes are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@extension''' || <center>ST</center> || <center>O</center> || Identification
|-
| '''@root''' || <center>OID</center> || <center>R</center> || Source of identification
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id extension="13234453645" root="2.16.840.1.113883.2.6.15.3.427.1"/>
</syntaxhighlight>

The ''@root'' attribute is of type OID (object identifier), a unique identifier of the issuing authority or system. For example, a patient with a patient number 13234453645 created by a specific healthcare provider organization is uniquely identified by the number itself in ''@extension'' and the OID of the organization or the sending system, in the example 2.16.840.1.113883.2.6.15.3.427.1 in ''@root''.
In some cases, a single OID identifies an object uniquely. In that situation, only ''@root'' is populated and ''@extension'' is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Encapsulated Data (ED) ===

Elements of this data type carry multimedia content. The actual multimedia content is represented as element content. There are two situations for the use of ED:
* Inline: The full data is transmitted in the type. This form is mainly used for text.
* By reference: a thumbnail is provided which links to the full data by reference.
In an instance, the data type is normally determined by an xsi:type specification and some attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@mediaType''' || <center>CS</center> || <center>O</center> || MIME media type classification. At time of writing this specification, the following MIME types are allowed:
* text/plain (plain text)
* text/html (text with html markup)
* image/jpeg (JPEG image)
* application/pdf (a PDF, portable document format)
* application/hl7-sda+xml (CDA documents).
|-
| '''@representation''' || <center>CS</center> || <center>O</center> || Representation of the multimedia content. At time of writing this specification, the following representations are allowed:
* TXT (text, this is the default)
* B64 base 64 encoded data, for example for embedded CDA documents).
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<text xsi:type="ED" mediaType="text/plain">
Patient treated sucessfully
</text>

<text mediaType="application/hl7-sda+xml" representation="B64">PD94bWw..etc..==</text>

</syntaxhighlight>

To include referenced data the two sub elements ''thumbnail'' and ''reference'' are used.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''reference''' || <center>TEL</center> || <center>0..*</center> || <center>O</center> || Link (URI) to full data
|-
| '''thumbnail''' || <center>ED</center> || <center>0..*</center> || <center>O</center> || Thumbnail of referenced data
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value xsi:type="ED" mediaType="image/png" representation="B64">
<reference value="http://radiology.bergen.no/xrays/128s.png"/>
<thumbnail mediaType="image/jpeg" representation="B64"> MNY...83== </thumbnail>
</value>
</syntaxhighlight>

=== Strings (ST) ===

This data type is a specialization of the ED type where ''@mediaType'' is fixed “text/plain” and ''@representation'' is fixed “TXT”. It allows conveying a character string as '''element content'''. This data type is used in other data types it like the ''@extension'' in instance identifiers, or address and person name data type components.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<lotNumber> 143GT6DT </lotNumber>
</syntaxhighlight>

=== Concept Descriptor (CD) ===

This data type specifies a concept by means of a code and its code system (except for situations where no code is available). A couple of specializations of data type CD exist, which differ in the main characteristics (properties) of the data type that may or may not be supported.

{| class="hl7table" style="width:50%"
|+ Table 1: Properties of data types used for codes
! <div style="text-align: right">DataType</div> !! CD !! CE !! CV !! CO !! CS
|-
! <div style="text-align: left">Property</div> !! !! !! !! !!
|-
| '''@code''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||<center>X</center>
|-
| '''@codeSystem''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''@codeSystemVersion''' || <center>X</center> || <center>X</center> || <center>X</center>|| <center>X</center> ||
|-
| '''@displayName''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''originalText''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''translation''' || <center>X</center> || <center>X</center> || || ||
|-
| '''qualifier''' || <center>X</center> || || || ||
|}

Because the CE variant is most used in practice, the general explanation of the proper-ties will be given with de description of CE (see below).
The only attribute that is unique to CD is briefly explained here.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@qualifier''' || <center>CR</center> || <center>O</center> || An additional qualifier for the code.
|}

Complex terminologies like SNOMED CT can be used only using data type CD.

=== Coded with Equivalents (CE) ===

With elements of this data type, a concept by means of a code and its coding system (except for situations where no code is available) can be specified. It optionally contains one or more equivalents using other code systems.
It may contain the following attributes:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@code''' || <center>ST</center> || <center>R</center> || The actual code
|-
| '''@codeSystem''' || <center>OID</center> || <center>R</center> || required to identify the code system were the code is drawn from. This is an OID (object identifier, see [[#Object_Identifiers_.28OIDs.29|Object Identifiers at 4.1]])
|-
| '''@displayName''' || <center>ST</center> || <center>O</center> || Optional textual representation of code. A display name may be specified representing the plain text of the code. The information of this attribute may not be used by the receiving system for interpretation, but only for display purposes. The display name may never be transmitted without a code and must have the same meaning as the code.
|-
| '''@codeSystemName''' || <center>ST</center> || <center>O</center> || A textual representation of the name of the code system
|-
| '''@codeSystemVersion''' || <center>ST</center> || <center>O</center> || A textual representation of the version of the code system
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"/>

<code code="AU" codeSystem="2.16.840.1.113883.5.33"/>

<storageCode code="AC" codeSystem="2.16.840.1.113883.5.34" displayName="active"/>

<code code="A45.0" displayName="Somatisierungsstörung" codeSystem="1.2.276.0.76.5.409" codeSystemName="ICD-10 GM 2012"/>
</syntaxhighlight>

There are some child elements of codes that can be used to express what the “original text” was that was used for the coding or to indicate that there are “translations” to other code systems than the primary code.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''originalText''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Textual representation of the concept, actually a description which was used to create the actual code
|}

No semantics may be assumed other than showing the ''@displayName'' to a user to clarify the code. A display name cannot occur without its code and must carry the same meaning.

In case no code is known, it is allowed to specify a ''@nullFlavor'' for the code element and to give information about the (not yet coded) concept in original text. However, this should be an exception.

If other codes than the primary code need to be conveyed adding a translation child element can be used.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<originalText>minor aphthous stomatitis</originalText>
</code>
</syntaxhighlight>

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''translation''' || <center>CD</center> || <center>0..*</center> || <center>O</center> || Alternative code(s)
|}

A ''translation'' element is also of type CD and shall have a code and a code system identified. It shall point to the same concept as the primary code. It is allowed that a translation conveys less conceptual details than the original code.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<translation code="528.2" codeSystem="2.16.840.1.113883.6.2" codeSystemName="ICD9" displayName="Oral aphthae"/>
</code>
</syntaxhighlight>

=== Coded Value (CV) ===

This is actually a specialization of CE (see above), with the exception that neither ''originalText'' nor ''translation'' child element are allowed.

=== Coded Simple Value (CS) ===

This is actually a specialization of CE (see above), with no code system attribute and no original text or translation child element allowed. It specifies a concept by means of a code from a ''predefined'' code system (table) where the code is drawn from. This data type is usually applied in the context of fixed predefined HL7 tables.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<statusCode code="completed"/>
</syntaxhighlight>

In this example ''statusCode'' is bound in the underlying model to the specific code system ''ActStatus''. Because it is predefined by means of the vocabulary binding, ''@codeSystem'' is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Telecommunication Address (TEL) ===

Elements of this type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>ST</center> || <center>R</center> || carries strings that represent telecommunication contact information
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

The actual data is preceded by the scheme (refer to Internet Standard “RFC 1738 Uniform Resource Locators (URL)” <ref>RFC 1738 Uniform Resource Locators (URL): http://www.ietf.org/rfc/rfc1738.txt</ref>.

Examples:
* telephone (tel:),
* fax (fax:),
* email (mailto:).

It must follow the rules defined in Internet “RFC 2806 URLs for Telephone Calls” <ref>RFC 2806 URLs for Telephone Calls: http://www.ietf.org/rfc/rfc2806.txt</ref>.

The following codes will be used in the “use” attribute:
* H – Home
* WP – Work
* MC can be used (in addition to H or WP) to denote that this is a mobile phone.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257" />

<telecom use="H" value="tel:55354257" />

<telecom use="H" value="fax:56542558" />

<telecom value="tel:+41.34.21.4765342"/>

<telecom value="mailto:opr@opr-sem.no"/>

<telecom use="WP MC" value="tel:97555786" />
</syntaxhighlight>

It is possible to express the useable period of a telecommunication contact. A child element ''useablePeriod'' is used as a time interval to indicate this period.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''useablePeriod''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257">
<useablePeriod>
<high value="20111201"/>
</useablePeriod>
</telecom>
</syntaxhighlight>

=== Postal Address (AD) ===

Elements of this data type have a substructure in order to represent a structured address specification. In this implementation guide only a selection of all possible child elements is allowed, the original HL7 specification is richer.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''streetAddressLine''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Street address, includes street name and house number
|-
| '''city''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || City
|-
| '''postalCode''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Postal code
|-
| '''country''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Country
|-
|}

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that the sequence of the sub elements is country specific, i.e. it has to follow “common” rules how to write an address. For example, an UK address and a German address have different sequences of address representation.
|}

A ''@use'' attribute can also be specified.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="WP">
<streetAddressLine>Anna-Louisa-Karsch-Str. 2</streetAddressLine>
<postalCode>10178</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="H WP">
<streetAddressLine>Tatungasse 34</streetAddressLine>
<postalCode>10825</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

Also, a country may be specified using the element ''country''.

=== Person Name (PN) ===

Elements of this data type do also have a substructure to represent the parts of a person name, like family or given name and prefixes.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>
<given>Franz</given>
<given>Ingrun</given>
<family>Nordmann</family>
</name>
</syntaxhighlight>

Previous or birth or maiden names are supported using the ''validTime'' element. ''validTime'' (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]]) specifies the validity range of the name.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">

<name>
<given>Jan</given>
<given>Olaf</given>
<family>Hendrikson</family>
<validTime>
<high value="20000101"/>
</validTime>
</name>
</syntaxhighlight>

Note that the name attribute is repeating, i.e. multiple (types of) names could be sent. It is up to the receiver (based on the value of the ''@use'' attribute, and ''validTime'') to decide what name it wants to use or import in its database.

=== Organisation Name (ON) ===

Elements of this data type represent a name of an organization.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name> Charité Berlin </name>
</syntaxhighlight>

The optional ''validTime'' element (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]] may be used to specify the validity range of the name of the organization.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name of the organization
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>The old hospital
<validTime>
<high value="20111231235959"/>
</validTime>
</name>
</syntaxhighlight>

Please note that the use of ''validTime'' yields XML mixed content which should be avoid-ed if possible.

=== Integer Number (INT) ===

Elements of this data type are used to specify integer numbers and have one attribute.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>int</center> || <center>R</center> || Integer value
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<sequenceNumber value="24"/>
</syntaxhighlight>

=== Physical Quantities (PQ) ===

Elements of this data type are physical quantities, i.e. a measurable quantity (or countable) value from the physical world. This is different from just a “number”, because there is a (natural) unit specified in which the measurable quantity is expressed.
Examples:
* an amount of blood 20 ml (sample volume)
* a cut with a length of 10 cm (result observation)
* a dose of 200 milligrams per administration (dosing)
* delivery of 60 pieces of a tablet (amount supplied).
Elements of this data type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>real</center> || <center>R</center> || value of the measurement
|-
| '''@unit''' || <center>CS</center> || <center>R</center> || unit of measurement
|}

In the unit of measurement unit is expressed following the ''Unified Code for Units of Measure'' (UCUM) specification. This specification is a collection of atomic units, prefixes and a corresponding grammar for valid combinations to build all-natural units of measurement. For a complete description of possible units, see the ''Unified Code for Units of Measure'' <ref>Unified Code for Units of Measure: http://unitsofmeasure.org/</ref> specification.
If a value is not countable or if measurable, for example expressed in milligrams or liters, then this unit is a valid UCUM unit like “mg” or “L”. If a value is countable, for example the number of tablets, then this attribute contains “1”.
In HL7 it is required that all PQ data type units are valid UCUM units.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<value value="165" unit="cm"/>

<value value="81.1" unit="kg"/>

<value value="120" unit="mm[Hg]"/>

<value value="5" unit="1"/>
</syntaxhighlight>

=== Point in Time (TS) ===

Elements of this data type have the attribute

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>TS</center> || <center>R</center> || Point in time
|}

and specify points in time in the format YYYYMMDDhhmmss±ZZZZ, where
* YYYY is the four-digit year,
* MM the two-digit month,
* DD the two-digit day,
* hh the two-digit hour,
* mm the two-digits minute and
* ss the two-digit second.
Optional a time zone ZZZZ, the four-digit time alignment with a preceding “-” or a “+” can be specified. If time zone is omitted, local time is assumed.
The point in time may be right truncated in respect to the precision of the information.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<effectiveTime value="20140412"/>

<effectiveTime value="201409091245"/>

<effectiveTime value="1996"/>

<birthTime value="19540714"/>

<effectiveTime value="20140412+0100"/>
</syntaxhighlight>

=== Intervals (IVL) ===

Intervals are defined only for data types with an ordinal or interval scale type. There are several possibilities to determine an interval (see Figure 2), for example to specify

* a lower <low> and an upper boundary <high> (a),
* a lower <low> boundary and width <width> (b)
* an upper boundary and width <width> (c) or
* the middle of the interval <nowiki><center></nowiki> and a width <width> (d).

[[File:CDA_Core_Principles_Figure_2_Determining_Intervals.png|700px]]

<ref group="Figure">Several possibilities to determine closed intervals</ref> ''Several possibilities to determine closed intervals''

{{ConstraintBox|
To indicate an interval, only the following combinations are permitted.
(1) A lower and an upper boundary may not be identical, and their accuracy has to be equal.

Correct examples:

{{BeginGreenBox|}}
Interval from 5 to 6
Interval from 20110607 until 20110612
{{EndGreenBox}}

Incorrect examples:

{{BeginRedBox|}}
Interval from 5 to 6.0
Interval from 20110101 to 2011
{{EndRedBox|}}

(2) A lower boundary and a width

(3) A lower limit boundary

(4) A upper limit boundary

(5) Only the middle of the interval

(6) Only the width of an interval}}

Accordingly, four child elements are available.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Lower boundary
|-
| '''high''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Upper boundary
|-
| '''center''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Where ''(T)'' is defined in this specification as one of the data types “TS” or “PQ”.

=== Interval of time (IVL_TS) ===

Elements of this data type represent time intervals. There are four possible child elements.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Lower boundary (start date/time)
|-
| '''high''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Upper boundary (end date/time)
|-
| '''center''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Normally, a lower and an upper boundary is given, both are points in time. Also, it is possible to specify open intervals like “since June 14, 1999” (left boundary given only) or “until September 24, 2006” (right boundary given).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110507"/>
<high value="20110909"/>
</effectiveTime>

<effectiveTime>
<low value="20110507"/>
</effectiveTime>

<value>
<low value="20110101"/>
<width value="120" unit="d"/>
</value>

<value>
<center value="20110101"/>
</value>
</syntaxhighlight>

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|It must be noted that intervals of time stamps in HL7 are equally treated as other interval types (e.g. integers). The statement, one may take 1–3 tablets (interval of integers), for example, says that you are allowed to take no more than three tablets, not 3½ or 3.5 tablets. On the other hand, when treat the words “until 12 June 2011” regarding the upper interval limit differently, particularly we assume that the entire day 12 June is still in-cluded in this time interval.
Thus, in human perception time intervals are handled differently com-pared to such as number intervals. This is a situation may lead to inconsist-encies in standardized communication. As a conclusion, an upper limit “12 June 2011” means that only the very first moment of the 12 June is included in the interval, but not, for example, the 12 June 13:00 hours.
Interpretation does not depend on the accuracy of the time:
* “after 2004” means “from January 1, 2005 00:00:00.000”,
* “after 20041201” means “from 2 December 2004 00:00:00.000 hours”,
* and “after 200412011200” means “from 1 December 2004 12:01:00.000”.

As a result, you have to carefully consider the specification and implemen-tation of time intervals upper boundaries. In order to prevent mis-understandings intervals are always specified with the date and time for an upper limit that would cover the whole day. Accordingly, “201106122359” means 12 June 2011 throughout the day.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="201106122359"/>
</effectiveTime>
</syntaxhighlight>

Because of the equal treatment of time intervals this is applied also to the lower limit boundaries of time intervals as “0000”. This means for example that “since 9 June 2011” is expressed as “201106090000”.
|}

The <width> element is of data type PQ (physical quantity). The value obviously shall relate to a period of time and it is required to include a “time” unit. These are the units “us” (microseconds), “ms” (milliseconds), “s” (seconds), “min” (minute), “h” (hours), “d” (day), “wk” (week), “mo” (month) and “a” (year).

{{ConstraintBox|
For interval of time stamps the @unit of a ''low'' or ''high'' child element shall use units
* us (microseconds),
* ms (milliseconds),
* s (seconds),
* min (minute),
* h (hours),
* d (day),
* wk (week),
* mo (month) or
* a (year).
}}

=== Interval of physical quantities (IVL_PQ) ===

Elements of this data type are used to indicate intervals of physical quantities (see also [[#Physical Quantities (PQ)|3.18 Physical Quantities (PQ)]]). In general, an upper and a lower boundary is specified. It is also possible to use ''center'' instead of ''low'' and ''high''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low || <center>TS</center> || <center>0..1</center> || <center>C</center> || the lower limit of the interval (i.e. the minimum amount).
|-
| '''high || <center>TS</center> || <center>0..1</center> || <center>C</center> || the upper limit of the interval (i.e. the maximum amount).
|-
| '''center || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of the interval
|}

The ''center'' child element is used when there is no interval, but an exact value. Alternative would be to demote IVL_PQ to data type PQ and populate the element’s ''@value'' attribute, but this is more difficult to process in XML. That is why the use of the ''center'' child element is deprecated.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<referenceRange>
<low value="7.5" unit="mmol/l"/>
<high value="10" unit="mmol/l"/>
</referenceRange>

<doseQuantity>
<center value="9" unit="1"/>
</doseQuantity>
</syntaxhighlight>

=== Ratio of quantities (RTO_QTY_QTY) ===

Elements of this data type specify ratios and have two child elements, a numerator and a denominator. The underlying QTY (Quantity) data type is an abstract data type and in a XML instance it has to be replaced by a specific data type using the ''@xsi:type'' instruction (see below).

In this specification only “PQ” or “INT” are allowed for the demotion of both ''numerator'' and ''denominator''. The relevant child elements are:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''numerator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the numerator of the ratio
|-
| '''denominator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the denominator of the ratio
|}

If a model attribute already is a RTO_QTY_QTY, you need to specify (demote) the OTY abstract data type for both ''numerator'' and ''denominator'' by using an ''@xsi:type'' instruction.
In some cases where the model attribute is of type “ANY”, also the root element shall carry an ''@xsi:type'' RTO_QTY_QTY instruction.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<maxDoseQuantity>
<numerator xsi:type="PQ" value="6"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="400" unit="mg"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="5"/>
<denominator xsi:type="PQ" value="1" unit="h"/>
</maxDoseQuantity>

<value xsi:type="RTO_QTY_QTY">
<numerator xsi:type="INT" value="1"/>
<denominator xsi:type="INT" value="10000"/>
</value>
</syntaxhighlight>

== Identification mechanisms ==

=== Object Identifiers (OIDs) ===

Standardized exchange of information using messages or documents also deals with unique identifications of objects and concepts, especially in environments where sender and receiver do not “know” each other necessarily.

It is important to understand the difference between identification of instances (ids) and code concepts (classifications). Within the context of HL7 interactions OIDs are quite often used.
An id points to a specific instance of an object or identification scheme (a particular methodology for the identification of a class of objects), for example a specific person as the patient or a physician, a specific lab observation or an X-ray photo.

In contrast to instance identifiers, a classification identifies a specific concept. The type of patient (inpatient, outpatient), the type of doctor (an anesthesiologist), the codes for gender or a lab observation (blood cell count) may serve as examples.

OIDs (object identifiers) are worldwide unique identifiers for objects. They are used in HL7 to specify identifications and classifications. An object in this sense is persistent, well-defined information, definitions or specifications and is represented with ids or codes.

Commonly used OIDs (i.e. used for a purpose that is wider in scope than the regional healthcare organization; used in communications between healthcare regions) can be found in OIDs registries such as

* [http://www.oid-info.com www.oid-info.com],
* [http://www.hl7.org www.hl7.org],
* [http://www.hl7.org.uk/version3group/oids.asp HL7 OID registry in the UK],
* [https://www.dimdi.de/dynamic/de/klassifikationen/weitere-klassifikationen-und-standards/oid/ OID registry Germany].

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|All OIDs with an element of 999 or 9999 are for documentation purposes only. They will be replaced by permanent OIDs once these have been as-signed/found/applied for.
|}

OID (Object Identifiers) are unique identifiers for any kind of objects. They are defined in Rec. ITU-T X.660 | ISO/IEC 9834-1. This identification system for objects and concepts makes reliable electronic information exchange possible. Administration and Registration is regulated by a set of rules, described in the corresponding chapter of this document.

Every artefact in ART-DECOR has an Object Identifier (OID). There are recommendations for the management and the exchange of Object Identifiers, partially defined in ISO TS 13582 <ref>ISO TS 13582: https://www.iso.org/standard/69652.html</ref>.

''HL7 International'' has created a type ontology for the OIDs in the HL7 registry to make it easier for the user community to search for OIDs they may be looking for and can be found at hl7.org.

From a policy perspective it is common practice in several healthcare related OID registries (HL7 International at http://www.hl7.org, OID Registry Germany at http://www.dimdi.de, OID registry Switzerland at http://oid.refdata.ch, and OID registry Austria at https://www.gesundheit.gv.at/OID_Frontend) to distinguish at least between the following types of OIDs:

{| class="hl7table" style="width:60%"
|+<ref group="Table">Recommended OID sub-branches for different artefacts</ref> ''Recommended OID sub-branches for different artefacts''
! Arc !! Description
|-
| .3 || organizational bodies and groups
|-
| .4 || identifier systems and namespaces
|-
| .5 || code systems
|-
| .7 || document artefacts
|-
| .9 || conformance profiles
|-
| .10 || templates
|-
| .11 || value sets
|-
| .19 || examples
|-
| .99 || experimental
|}

''Example: given that “your” root OID is 1.2.3.4.5, the first value set of your governance group is then to be 1.2.3.4.5.11.1, with .11 as the value set “branch” and the last .1 as the first artefact of that kind.''

In ART-DECOR a project typically is set into the .77 branch of a governance group. When setting up the project, the OID for that project also determines the artefact OIDs using throughout the ART-DECOR project. The following additional branches are used to distinguish between different OID types:

{| class="hl7table"
|+<ref group="Table">Recommended OID sub-branches for ART-DECOR projects</ref> ''Recommended OID sub-branches for different artefacts''
! Artefact code Description !! Recommended !! OID suffix
|-
| DS || dataset || .77.1
|-
| DE || dataset concept || .77.2
|-
| SC || scenario || .77.3
|-
| TR || transaction in scenario || .77.4
|-
| CS || code system || .77.5
|-
| IS || issue || .77.6
|-
| AC || actor in scenario || .77.7
|-
| CL || concept list in dataset || .77.8
|-
| EL || element in template || .77.9
|-
| TM || template || .77.10
|-
| VS || value set || .77.11
|-
| RL || rule for instances || .77.12
|-
| SX || test/example scenario || .77.18
|-
| EX || test/example instance || .77.19
|-
| QX || qualification test/example || .77.20
|-
| TX || test/example data element || .77.21
|-
| CM || community || .77.22
|-
| MP || concept map || .77.24
|}

In ART-DECOR a newly created project uses these OID branches automatically.

=== Instance identification ===

Instance identification is done with the id element of a class. Its type is II (instance identifier) and described in the data type section above. For example, a patient number can be represented as
* 2.16.578.1.34.1.5432.1, the root-OID of the issuing authority, for example a system/application in a hospital, and
* 67543242 as the ''@extension'', representing the patient number within the system defined by the ''@root'' attribute.

=== Coding scheme identification ===

Coding schemes have to be uniquely identified using OIDs as well. All coding tables used in this implementation guide show the corresponding OID that has to be specified in the ''@codeSystem'' attribute of coded elements. Both attributes ''@code'' and ''@codeSystem'' together allows a correct interpretation of concept and code.

=== List of identification schemes ===

The following are OIDs for commonly used identification schemes.

{| class="hl7table"
|+<ref group="Table">Commonly used identification scheme OIDs</ref> ''Commonly used identification scheme OIDs''
! OID !! Identification System Name !! Description !! Issuer
|-
| 1.2.276.0.76.4.8 || KV-Nummer || Krankenversichertennummer ||
|-
| 1.2.276.0.76.4.17 || BSNR || Betriebsstättennummer ||
|-
| 1.2.276.0.76.4.16 || LANR || lebenslange Arztnummer ||
|}

=== List of code systems ===

The following are OIDs for code systems.

{| class="hl7table"
|+<ref group="Table">Commonly used code system OIDs</ref> ''Commonly used code system OIDs''
! OID !! Code System Name !! Description !! Issuer
|-
| 2.16.840.1.113883.6.1 || LOINC || Logical Observation Identifiers Names and Codes (LOINC) || Regenstrief Institute
|-
| 2.16.840.1.113883.6.96 || SNOMED CT || Systemized Nomenclature in Medicine Reference Terminology (SNOMED CT) || SNOMED International
|-
| 1.0.3166.1.2 || ISO 3166-1 (second edition) || Country codes as per ISO 3166-1:2007 || ISO
|}

== Vocabulary ==

=== Code Systems ===

Within HL7, a ''Code System'' is defined as a collection of codes with associated designations and meanings. Examples of code systems include ICD-10, SNOMED CT, and LOINC.
To meet the requirements of a code system as defined by HL7, a given code must resolve to one and only one meaning within the code system. Given this definition, each code table in the HL7 Version 3 standard represents a different code system since codes are sometimes used in different tables to have different meanings.
For example, “M” in the administrative gender table (''AdministrativeGender'', OID 2.16.840.1.113883.5.1) means “male”, while “M” in the marital status table (''MaritalStatus'', OID 2.16.840.1.113883.5.2) means “married”.
In this specification, code system tables are not presented in detail.

=== Value Sets ===

A ''Value Set'' represents a uniquely identifiable set of valid concept representations, where any concept representation can be tested to determine whether or not it is a member of the value set.
Value set complexity may range from a simple flat list of concept codes drawn from a single code system, to an unbounded hierarchical set of possibly post-coordinated expressions drawn from multiple code systems.
Value sets exist to constrain the content for a coded element in an HL7 static model or data type property. Value sets cannot have null content and must contain at least one concept representation where any given concept is generally (but not required to be) represented by only a single code within the Value Set.

[[File:CDA_Core_Principles_Figure_3_ValueSet_Example.png|800px]]

<ref group="Figure">Example presentation of the value set “MaritalStatus”</ref> ''Example presentation of the value set “MaritalStatus”''

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that value set OIDs never appear in a CDA Release 2 document. They are used for constraint expressions, for example in implementation guides.
In order to send a specific code drawn from a value set, the corresponding code system has to be conveyed.
An example, in the implementation specification the constraint on the model element ''maritalStatusCode'' is expressed as “to be drawn from value set 2.16.840.1.113883.5.2 ''MaritalStatus''”.
To actually send a marital status of “M” (married) that is shown in the value set figure above, the corresponding HL7 CDA instance would say:
<syntaxhighlight lang="xml">
<maritalStatusCode code="M" codeSystem="2.16.840.1.113883.5.2"/>
</syntaxhighlight>
|}

In this specification, value set tables are not presented in detail.

==== Binding strength ====

There is an optional vocabulary strength for data types that support that feature (coded concepts). Examples include CD, CE, CV and CO. Values are required, extensible, preferred and example. Default is required.

Please note: the formerly supported values CNE (Coded No Extensibility) and CWE (Coded With Extensibility) in ART-DECOR are deprecated as of December 2017. Specification CNE is handled as required and CWE is handled as extensible.

{| class="hl7table"
|+<ref group="Table">Binding Strengths</ref> ''Binding Strengths''
! Strength !! Description
|-
|required||Required/CNE. Coded with no exceptions; this element SHALL be from the specified value set
|-
|extensible||Extensible/CWE. Coded with Exceptions; this element SHALL be from the specified value set if any of the codes within the value set can apply to the concept being communicated. If the value set does not cover the concept (based on human review), alternate codings (or, data type allowing, text) may be included instead.
|-
|preferred||Preferred. Instances are encouraged to draw from the specified codes for interoperability purposes but are not required to do so to be considered conformant.
|-
|example||Example. Instances are not expected or even encouraged to draw from the specified value set. The value set merely provides examples of the types of concepts intended to be included.
|}

Mismatches with required lead to validation errors (SHALL logic). Mismatches with extensible lead to validation warnings (SHOULD logic). Mismatches with preferred lead to validation information messages (MAY logic). Mismatches with example don't have any validation consequences.

== Appendix ==

=== References ===

<references/>

=== List of figures ===

<references group="Figure" />

=== List of tables ===

<references group="Table" />

HL7 CDA Core Principles

2019-06-14T20:15:46Z

Dammon:

== Introduction ==

This implementation guide specifies the ''Core Principles'' of using the ''Clinical Document Architecture'' <ref>Clinical Document Architecture Release 2: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=7</ref>.

=== Scope ===

This guide focuses on ''Data Types Release 1'' <ref>HL7 Data Types Release 1: http://www.hl7.org</ref>. Meanwhile an ISO specification ISO 21090 is out, also known as Data Type Release 2. The latter is subject to another implementation guide that will be published when ISO data types are used.

=== Focus of this document: HL7 Version 3 Data Types for CDA ===

The following chapters of this document will focus on the description of the data types and associated material. It will highlight the essentials in four chapters, all focusing on the Norwegian situation.
* '''Common aspects:''' explains common aspects of use of CDA and XML
* '''Data types:''' gives an overview and detailed specification of all data types used in CDA
* '''Identification schemes:''' explains major aspects of identification and the use in CDA
* '''Use of vocabulary:''' explains major aspects of vocabulary use in CDA.

=== Background ===

In many (European) countries, implementation guides for the use of data types in HL7 V3 are published. They take into account country specific constraints on the data types.

=== Legend of symbols ===

In this document several symbols are used.

{| class="hl7table" style="width:50%"
| [[File:Pfeil_rechts.png|50px]] || This is an important item
|-
| [[File:Issue.svg|50px]] || This is a known open issue
|-
| [[File:Faq.svg|50px]] || This is a frequently asked question (FAQ) with answer
|-
| [[File:Conformance.svg|50px]] || This is a constraint; in some situations also the rule identification is specified, e.g. dtr1-1-ANY, which links to the corresponding validation rule.
|}

=== Version history ===

{| class="hl7table" style="width:50%"
|+
! Version !! Date !! Description !! Author
|-
| 1.1 || 2019-04-24 || Refurbished guide based on earlier work || Kai U. Heitmann
|}

== Common aspects ==

=== Use of XML ===

HL7 Version 3 CDA uses the Extensible Markup Language (XML) as the exchange format. It is assumed that the reader is familiar with common XML aspects. However, some constraints are made regarding the use of CDA.

==== Character Set ====

{{ConstraintBox|
The character encoding of any CDA document shall be “UTF-8”.}}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="utf-8"?>
</syntaxhighlight>

=== CDA document structure ===

The XML namespace for CDA Release 2 documents is ''<nowiki>urn:hl7-org:v3</nowiki>''. This must be correctly mentioned in every XML instance.
CDA XML documents starts with the root element ''ClinicalDocument''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">


...

<component>
<structuredBody>
...
</structuredBody>
</component>

</ClinicalDocument>
</syntaxhighlight>

== Data types ==

=== Introduction ===

The following chapter describes the typical data types used in CDA implementation guides. For further information please refer to the HL7 V3 standard and its two parts concerning data types:
* Abstract Data type definition <ref>HL7 Version 3 Abstract Data type definition: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=264</ref>
* XML ITS for data types <ref>XML ITS for data types: https://www.hl7.org/documentcenter/public_temp_682D4D16-1C23-BA17-0C789BA52BEDB68E/wg/inm/datatypes-its-xml20050714.htm</ref>
Data types are properties of model class attributes and the basic building blocks of information in a CDA XML instance. For example, a model attribute named “time” has as its data type a time stamp “TS” (see Figure 1).

[[File:CDA_Core_Principles_Figure_1_CDA_Structure_Data_Types.png|700px]]

<ref group="Figure">CDA structure (left) and the data type specification (right)</ref> ''CDA structure (left) and the data type specification (right)''

=== XML representation of data types ===

Actual data is mostly carried in HL7 Version 3 by populating XML attributes and not as element content. Exceptions are names of persons and organizations as well as addresses.
The XML elements have names like the model attributes. For example, a model attribute “id” has a corresponding XML element named <id…>. The model determines the sequence of elements and their hierarchy. The data type itself determines the XML attributes within the start tag. The notation here is as follows:
{| class="hl7table"
|+
! Attribute !! DT !! Conf !! Description
|-
| (name of the model attribute or XML element) || Data type || Conformance, i.e. O, R, M || Textual description
|}

XML attributes (data type properties) are denoted as ''@attribute'' in order to distinguish their names from XML elements.

Example: in the example model above, the data type of the ''id'' attribute's is II (Instance Identifier). The corresponding XML attributes for that data type include ''@root'' and ''@extension''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id root="…" extension="..." />
</syntaxhighlight>
A description of the data types and their corresponding XML representation is contained in subsequent paragraphs of this guide.

==== Exceptions using XML element content ====
For most data types, the actual data is conveyed in XML attributes. However, there are some exceptions. For the data types binary (BIN), Encapsulated Data (ED), Entity Name (EN), Person Name (PN), Organization Name (ON), Trivial Name (TN), Address (AD) and character string data (ST), information is carried as element content.
Example: the components of an address <addr> are represented by sub elements with the data as element content (in the example shown in black).
<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr>
<streetAddressLine>Thormøhlens gate 12</streetAddressLine>
<postalCode>5006</postalCode>
<city>Bergen</city>
</addr>
</syntaxhighlight>

==== Combined data types ====
There are a number of socalled combined data types. For example, an interval with a lower and upper limit and a ratio that has a nominator and a denominator value.
In combined data types the substructure (e.g. <low> <high> in an interval) are represented as child elements of the relevant data type element.
<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110701"/>
<high value="20110729"/>
</effectiveTime>
</syntaxhighlight>

==== Conformance information ====

The conformance indicators distinguish kinds of conformance information described shortly here.

* '''O''': An optional item may be omitted if no data is present, i.e. no corresponding XML attribute or element is sent (marked as “O”)
* '''R''': For required items, lower cardinality is always zero or 1.
** Elements must be present and populated with data if present in the sending system. If no data is available (yet), a null flavor (see below) indicates and possibly classifies the missing information (marked as R).
** Attribute flagged as required must be present in the instance and populated.
* '''M''': For mandatory elements data must be sent and no missing values are allowed, i.e. if the sending system does not have information for mandatory elements the XML instance cannot be created and sent (marked as M).
* '''NP''': no data may be present at all (not permitted)
* '''C''': conditional conformance; typically a conformance table shows the circumstances (conditions) derived from information in the instance and the corresponding cardinalities and conformance statements.

=== Missing values (null flavor) ===

For every data type it is possible to specify a missing value including a kind of reason why data is missing. Instead of specifying any attribute of the corresponding element, a ''@nullFlavor'' attribute expresses the omission of data. Note that missing data is not allowed for mandatory elements (see above).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value nullFlavor="OTH"/>

<code nullFlavor="UNK"/>

<booleanInd nullFlavor="NI"/>

</syntaxhighlight>

The codes for the ''@nullFlavor'' attribute are drawn from the following hierarchical code system. It is a Coded Simple (CS), which means it has no code system (attribute ''@codeSystem'') specified.

{| class="hl7table"
|+<ref group="Table">NullFlavor</ref> ''NullFlavor''
! Code
! width=15% | Print Name
! Definition / Description
|-
| NI || No Information || No information whatsoever can be inferred from this exceptional value. This is the most general exceptional value. It is also the default exceptional value.
|-
| OTH || other || The actual value is not an element in the value domain of a variable. (e.g., concept not provided by required code system).
|-
| NINF || negative infinity || Negative infinity of numbers.
|-
| PINF || positive infinity || Positive infinity of numbers.
|-
| UNK || unknown || A proper value is applicable, but not known.
|-
| ASKU || asked but unknown || Information was sought but not found (e.g., patient was asked but didn't know)
|-
| NAV || temporarily unavailable || Information is not available at this time but it is expected that it will be available later.
|-
| NASK || not asked || This information has not been sought (e.g., patient was not asked)
|-
| TRC || trace || The content is greater than zero, but too small to be quantified.
|-
| MSK || masked || There is information on this item available but it has not been provided by the sender due to security, privacy or other reasons. There may be an alternate mechanism for gaining access to this information.
Note: using this null flavour does provide information that may be a breach of confidentiality, even though no detail data is provided. Its primary purpose is for those circumstances where it is necessary to inform the receiver that the information does exist without providing any detail.
|-
| NA || not applicable || No proper value is applicable in this context (e.g., last menstrual period for a male).
|-
| NP || not present || Value is not present in a message. This is only defined in messages, never in application data! All values not present in the message must be replaced by the applicable default, or no-information (NI) as the default of all defaults.
|}

=== ANY as the generic data type ===

This abstract data type is the basis for all other data types. Not a single value within a CDA document has the effective data type ANY, but any data type within HL7v3 is a specialization of ANY. This also means that any other data type inherits all properties of ANY (see [[#Missing_values_.28null_flavor.29|“Missing values (null flavor)”]]).

The ANY type is occasionally found in HL7 models when it comes to clinical finding etc. where – at model time – the actual data type of the value is not known. At instantiation time however, the actual data type ''is'' known and ANY is always replaced by a particular data type in an instance.

One example is the observation value (child element value in an observation), where in the model the data type of value cannot be anticipated. When instantiation is taking place, the data type is specified by the XML instance attribute ''@xsi:type''. This information can be used by the receiver to validate and process the value.

Attributes of an element with this data type are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@nullFlavor''' || <center>CS</center> || <center>–</center> || Classification of the missing value, see [[#Missing_values_.28null_flavor.29|3.3 Missing values (null flavor)]].
|}

{| class="hl7table" style="width:100%"
| width=8% | <center>[[File:Conformance.svg|50px]] dtr1-1-ANY</center> || If there is a ''nullFlavor'', there shall be no other attribute or element, unless it's ''nullFlavor="OTH"''. In that case ''@codeSystem'' or ''originalText'' (see “code” data types) may have a value.
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">

<value xsi:type="CE" code="N11.9" codeSystem="2.16.840.1.113883.6.3"/>


<value xsi:type="PQ" value="12" unit="mL"/>


<value xsi:type="ED">this is text</value>
</syntaxhighlight>

=== Boolean (BL) ===

Elements of this data type refer to Boolean logic and have an attribute ''@value''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>BL</center> || <center>–</center> || Valued as “true” or “false”
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<negationInd value="false"/>

<deceasedInd value="true"/>

</syntaxhighlight>

In some situations, the BL data does not apply to an XML element, but an attribute. In that case, the attribute carries the Boolean value directly.
<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<support contextConductionInd ="false">
...
</support>
</syntaxhighlight>

=== Instance Identifier (II) ===

This data type identifies instances of classes like observations or entities (persons, organizations). Attributes are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@extension''' || <center>ST</center> || <center>O</center> || Identification
|-
| '''@root''' || <center>OID</center> || <center>R</center> || Source of identification
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id extension="13234453645" root="2.16.840.1.113883.2.6.15.3.427.1"/>
</syntaxhighlight>

The ''@root'' attribute is of type OID (object identifier), a unique identifier of the issuing authority or system. For example, a patient with a patient number 13234453645 created by a specific healthcare provider organization is uniquely identified by the number itself in ''@extension'' and the OID of the organization or the sending system, in the example 2.16.840.1.113883.2.6.15.3.427.1 in ''@root''.
In some cases, a single OID identifies an object uniquely. In that situation, only ''@root'' is populated and ''@extension'' is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Encapsulated Data (ED) ===

Elements of this data type carry multimedia content. The actual multimedia content is represented as element content. There are two situations for the use of ED:
* Inline: The full data is transmitted in the type. This form is mainly used for text.
* By reference: a thumbnail is provided which links to the full data by reference.
In an instance, the data type is normally determined by an xsi:type specification and some attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@mediaType''' || <center>CS</center> || <center>O</center> || MIME media type classification. At time of writing this specification, the following MIME types are allowed:
* text/plain (plain text)
* text/html (text with html markup)
* image/jpeg (JPEG image)
* application/pdf (a PDF, portable document format)
* application/hl7-sda+xml (CDA documents).
|-
| '''@representation''' || <center>CS</center> || <center>O</center> || Representation of the multimedia content. At time of writing this specification, the following representations are allowed:
* TXT (text, this is the default)
* B64 base 64 encoded data, for example for embedded CDA documents).
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<text xsi:type="ED" mediaType="text/plain">
Patient treated sucessfully
</text>

<text mediaType="application/hl7-sda+xml" representation="B64">PD94bWw..etc..==</text>

</syntaxhighlight>

To include referenced data the two sub elements ''thumbnail'' and ''reference'' are used.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''reference''' || <center>TEL</center> || <center>0..*</center> || <center>O</center> || Link (URI) to full data
|-
| '''thumbnail''' || <center>ED</center> || <center>0..*</center> || <center>O</center> || Thumbnail of referenced data
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value xsi:type="ED" mediaType="image/png" representation="B64">
<reference value="http://radiology.bergen.no/xrays/128s.png"/>
<thumbnail mediaType="image/jpeg" representation="B64"> MNY...83== </thumbnail>
</value>
</syntaxhighlight>

=== Strings (ST) ===

This data type is a specialization of the ED type where ''@mediaType'' is fixed “text/plain” and ''@representation'' is fixed “TXT”. It allows conveying a character string as '''element content'''. This data type is used in other data types it like the ''@extension'' in instance identifiers, or address and person name data type components.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<lotNumber> 143GT6DT </lotNumber>
</syntaxhighlight>

=== Concept Descriptor (CD) ===

This data type specifies a concept by means of a code and its code system (except for situations where no code is available). A couple of specializations of data type CD exist, which differ in the main characteristics (properties) of the data type that may or may not be supported.

{| class="hl7table" style="width:50%"
|+ Table 1: Properties of data types used for codes
! <div style="text-align: right">DataType</div> !! CD !! CE !! CV !! CO !! CS
|-
! <div style="text-align: left">Property</div> !! !! !! !! !!
|-
| '''@code''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||<center>X</center>
|-
| '''@codeSystem''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''@codeSystemVersion''' || <center>X</center> || <center>X</center> || <center>X</center>|| <center>X</center> ||
|-
| '''@displayName''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''originalText''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''translation''' || <center>X</center> || <center>X</center> || || ||
|-
| '''qualifier''' || <center>X</center> || || || ||
|}

Because the CE variant is most used in practice, the general explanation of the proper-ties will be given with de description of CE (see below).
The only attribute that is unique to CD is briefly explained here.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@qualifier''' || <center>CR</center> || <center>O</center> || An additional qualifier for the code.
|}

Complex terminologies like SNOMED CT can be used only using data type CD.

=== Coded with Equivalents (CE) ===

With elements of this data type, a concept by means of a code and its coding system (except for situations where no code is available) can be specified. It optionally contains one or more equivalents using other code systems.
It may contain the following attributes:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@code''' || <center>ST</center> || <center>R</center> || The actual code
|-
| '''@codeSystem''' || <center>OID</center> || <center>R</center> || required to identify the code system were the code is drawn from. This is an OID (object identifier, see [[#Object_Identifiers_.28OIDs.29|Object Identifiers at 4.1]])
|-
| '''@displayName''' || <center>ST</center> || <center>O</center> || Optional textual representation of code. A display name may be specified representing the plain text of the code. The information of this attribute may not be used by the receiving system for interpretation, but only for display purposes. The display name may never be transmitted without a code and must have the same meaning as the code.
|-
| '''@codeSystemName''' || <center>ST</center> || <center>O</center> || A textual representation of the name of the code system
|-
| '''@codeSystemVersion''' || <center>ST</center> || <center>O</center> || A textual representation of the version of the code system
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"/>

<code code="AU" codeSystem="2.16.840.1.113883.5.33"/>

<storageCode code="AC" codeSystem="2.16.840.1.113883.5.34" displayName="active"/>

<code code="A45.0" displayName="Somatisierungsstörung" codeSystem="1.2.276.0.76.5.409" codeSystemName="ICD-10 GM 2012"/>
</syntaxhighlight>

There are some child elements of codes that can be used to express what the “original text” was that was used for the coding or to indicate that there are “translations” to other code systems than the primary code.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''originalText''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Textual representation of the concept, actually a description which was used to create the actual code
|}

No semantics may be assumed other than showing the ''@displayName'' to a user to clarify the code. A display name cannot occur without its code and must carry the same meaning.

In case no code is known, it is allowed to specify a ''@nullFlavor'' for the code element and to give information about the (not yet coded) concept in original text. However, this should be an exception.

If other codes than the primary code need to be conveyed adding a translation child element can be used.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<originalText>minor aphthous stomatitis</originalText>
</code>
</syntaxhighlight>

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''translation''' || <center>CD</center> || <center>0..*</center> || <center>O</center> || Alternative code(s)
|}

A ''translation'' element is also of type CD and shall have a code and a code system identified. It shall point to the same concept as the primary code. It is allowed that a translation conveys less conceptual details than the original code.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<translation code="528.2" codeSystem="2.16.840.1.113883.6.2" codeSystemName="ICD9" displayName="Oral aphthae"/>
</code>
</syntaxhighlight>

=== Coded Value (CV) ===

This is actually a specialization of CE (see above), with the exception that neither ''originalText'' nor ''translation'' child element are allowed.

=== Coded Simple Value (CS) ===

This is actually a specialization of CE (see above), with no code system attribute and no original text or translation child element allowed. It specifies a concept by means of a code from a ''predefined'' code system (table) where the code is drawn from. This data type is usually applied in the context of fixed predefined HL7 tables.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<statusCode code="completed"/>
</syntaxhighlight>

In this example ''statusCode'' is bound in the underlying model to the specific code system ''ActStatus''. Because it is predefined by means of the vocabulary binding, ''@codeSystem'' is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Telecommunication Address (TEL) ===

Elements of this type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>ST</center> || <center>R</center> || carries strings that represent telecommunication contact information
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

The actual data is preceded by the scheme (refer to Internet Standard “RFC 1738 Uniform Resource Locators (URL)” <ref>RFC 1738 Uniform Resource Locators (URL): http://www.ietf.org/rfc/rfc1738.txt</ref>.

Examples:
* telephone (tel:),
* fax (fax:),
* email (mailto:).

It must follow the rules defined in Internet “RFC 2806 URLs for Telephone Calls” <ref>RFC 2806 URLs for Telephone Calls: http://www.ietf.org/rfc/rfc2806.txt</ref>.

The following codes will be used in the “use” attribute:
* H – Home
* WP – Work
* MC can be used (in addition to H or WP) to denote that this is a mobile phone.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257" />

<telecom use="H" value="tel:55354257" />

<telecom use="H" value="fax:56542558" />

<telecom value="tel:+41.34.21.4765342"/>

<telecom value="mailto:opr@opr-sem.no"/>

<telecom use="WP MC" value="tel:97555786" />
</syntaxhighlight>

It is possible to express the useable period of a telecommunication contact. A child element ''useablePeriod'' is used as a time interval to indicate this period.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''useablePeriod''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257">
<useablePeriod>
<high value="20111201"/>
</useablePeriod>
</telecom>
</syntaxhighlight>

=== Postal Address (AD) ===

Elements of this data type have a substructure in order to represent a structured address specification. In this implementation guide only a selection of all possible child elements is allowed, the original HL7 specification is richer.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''streetAddressLine''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Street address, includes street name and house number
|-
| '''city''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || City
|-
| '''postalCode''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Postal code
|-
| '''country''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Country
|-
|}

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that the sequence of the sub elements is country specific, i.e. it has to follow “common” rules how to write an address. For example, an UK address and a German address have different sequences of address representation.
|}

A ''@use'' attribute can also be specified.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="WP">
<streetAddressLine>Anna-Louisa-Karsch-Str. 2</streetAddressLine>
<postalCode>10178</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="H WP">
<streetAddressLine>Tatungasse 34</streetAddressLine>
<postalCode>10825</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

Also, a country may be specified using the element ''country''.

=== Person Name (PN) ===

Elements of this data type do also have a substructure to represent the parts of a person name, like family or given name and prefixes.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>
<given>Franz</given>
<given>Ingrun</given>
<family>Nordmann</family>
</name>
</syntaxhighlight>

Previous or birth or maiden names are supported using the ''validTime'' element. ''validTime'' (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]]) specifies the validity range of the name.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">

<name>
<given>Jan</given>
<given>Olaf</given>
<family>Hendrikson</family>
<validTime>
<high value="20000101"/>
</validTime>
</name>
</syntaxhighlight>

Note that the name attribute is repeating, i.e. multiple (types of) names could be sent. It is up to the receiver (based on the value of the ''@use'' attribute, and ''validTime'') to decide what name it wants to use or import in its database.

=== Organisation Name (ON) ===

Elements of this data type represent a name of an organization.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name> Charité Berlin </name>
</syntaxhighlight>

The optional ''validTime'' element (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]] may be used to specify the validity range of the name of the organization.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name of the organization
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>The old hospital
<validTime>
<high value="20111231235959"/>
</validTime>
</name>
</syntaxhighlight>

Please note that the use of ''validTime'' yields XML mixed content which should be avoid-ed if possible.

=== Integer Number (INT) ===

Elements of this data type are used to specify integer numbers and have one attribute.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>int</center> || <center>R</center> || Integer value
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<sequenceNumber value="24"/>
</syntaxhighlight>

=== Physical Quantities (PQ) ===

Elements of this data type are physical quantities, i.e. a measurable quantity (or countable) value from the physical world. This is different from just a “number”, because there is a (natural) unit specified in which the measurable quantity is expressed.
Examples:
* an amount of blood 20 ml (sample volume)
* a cut with a length of 10 cm (result observation)
* a dose of 200 milligrams per administration (dosing)
* delivery of 60 pieces of a tablet (amount supplied).
Elements of this data type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>real</center> || <center>R</center> || value of the measurement
|-
| '''@unit''' || <center>CS</center> || <center>R</center> || unit of measurement
|}

In the unit of measurement unit is expressed following the ''Unified Code for Units of Measure'' (UCUM) specification. This specification is a collection of atomic units, prefixes and a corresponding grammar for valid combinations to build all-natural units of measurement. For a complete description of possible units, see the ''Unified Code for Units of Measure'' <ref>Unified Code for Units of Measure: http://unitsofmeasure.org/</ref> specification.
If a value is not countable or if measurable, for example expressed in milligrams or liters, then this unit is a valid UCUM unit like “mg” or “L”. If a value is countable, for example the number of tablets, then this attribute contains “1”.
In HL7 it is required that all PQ data type units are valid UCUM units.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<value value="165" unit="cm"/>

<value value="81.1" unit="kg"/>

<value value="120" unit="mm[Hg]"/>

<value value="5" unit="1"/>
</syntaxhighlight>

=== Point in Time (TS) ===

Elements of this data type have the attribute

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>TS</center> || <center>R</center> || Point in time
|}

and specify points in time in the format YYYYMMDDhhmmss±ZZZZ, where
* YYYY is the four-digit year,
* MM the two-digit month,
* DD the two-digit day,
* hh the two-digit hour,
* mm the two-digits minute and
* ss the two-digit second.
Optional a time zone ZZZZ, the four-digit time alignment with a preceding “-” or a “+” can be specified. If time zone is omitted, local time is assumed.
The point in time may be right truncated in respect to the precision of the information.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<effectiveTime value="20140412"/>

<effectiveTime value="201409091245"/>

<effectiveTime value="1996"/>

<birthTime value="19540714"/>

<effectiveTime value="20140412+0100"/>
</syntaxhighlight>

=== Intervals (IVL) ===

Intervals are defined only for data types with an ordinal or interval scale type. There are several possibilities to determine an interval (see Figure 2), for example to specify

* a lower <low> and an upper boundary <high> (a),
* a lower <low> boundary and width <width> (b)
* an upper boundary and width <width> (c) or
* the middle of the interval <nowiki><center></nowiki> and a width <width> (d).

[[File:CDA_Core_Principles_Figure_2_Determining_Intervals.png|700px]]

<ref group="Figure">Several possibilities to determine closed intervals</ref> ''Several possibilities to determine closed intervals''

{{ConstraintBox|
To indicate an interval, only the following combinations are permitted.
(1) A lower and an upper boundary may not be identical, and their accuracy has to be equal.

Correct examples:

{{BeginGreenBox|}}
Interval from 5 to 6
Interval from 20110607 until 20110612
{{EndGreenBox}}

Incorrect examples:

{{BeginRedBox|}}
Interval from 5 to 6.0
Interval from 20110101 to 2011
{{EndRedBox|}}

(2) A lower boundary and a width

(3) A lower limit boundary

(4) A upper limit boundary

(5) Only the middle of the interval

(6) Only the width of an interval}}

Accordingly, four child elements are available.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Lower boundary
|-
| '''high''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Upper boundary
|-
| '''center''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Where ''(T)'' is defined in this specification as one of the data types “TS” or “PQ”.

=== Interval of time (IVL_TS) ===

Elements of this data type represent time intervals. There are four possible child elements.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Lower boundary (start date/time)
|-
| '''high''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Upper boundary (end date/time)
|-
| '''center''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Normally, a lower and an upper boundary is given, both are points in time. Also, it is possible to specify open intervals like “since June 14, 1999” (left boundary given only) or “until September 24, 2006” (right boundary given).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110507"/>
<high value="20110909"/>
</effectiveTime>

<effectiveTime>
<low value="20110507"/>
</effectiveTime>

<value>
<low value="20110101"/>
<width value="120" unit="d"/>
</value>

<value>
<center value="20110101"/>
</value>
</syntaxhighlight>

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|It must be noted that intervals of time stamps in HL7 are equally treated as other interval types (e.g. integers). The statement, one may take 1–3 tablets (interval of integers), for example, says that you are allowed to take no more than three tablets, not 3½ or 3.5 tablets. On the other hand, when treat the words “until 12 June 2011” regarding the upper interval limit differently, particularly we assume that the entire day 12 June is still in-cluded in this time interval.
Thus, in human perception time intervals are handled differently com-pared to such as number intervals. This is a situation may lead to inconsist-encies in standardized communication. As a conclusion, an upper limit “12 June 2011” means that only the very first moment of the 12 June is included in the interval, but not, for example, the 12 June 13:00 hours.
Interpretation does not depend on the accuracy of the time:
* “after 2004” means “from January 1, 2005 00:00:00.000”,
* “after 20041201” means “from 2 December 2004 00:00:00.000 hours”,
* and “after 200412011200” means “from 1 December 2004 12:01:00.000”.

As a result, you have to carefully consider the specification and implemen-tation of time intervals upper boundaries. In order to prevent mis-understandings intervals are always specified with the date and time for an upper limit that would cover the whole day. Accordingly, “201106122359” means 12 June 2011 throughout the day.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="201106122359"/>
</effectiveTime>
</syntaxhighlight>

Because of the equal treatment of time intervals this is applied also to the lower limit boundaries of time intervals as “0000”. This means for example that “since 9 June 2011” is expressed as “201106090000”.
|}

The <width> element is of data type PQ (physical quantity). The value obviously shall relate to a period of time and it is required to include a “time” unit. These are the units “us” (microseconds), “ms” (milliseconds), “s” (seconds), “min” (minute), “h” (hours), “d” (day), “wk” (week), “mo” (month) and “a” (year).

{{ConstraintBox|
For interval of time stamps the @unit of a ''low'' or ''high'' child element shall use units
* us (microseconds),
* ms (milliseconds),
* s (seconds),
* min (minute),
* h (hours),
* d (day),
* wk (week),
* mo (month) or
* a (year).
}}

=== Interval of physical quantities (IVL_PQ) ===

Elements of this data type are used to indicate intervals of physical quantities (see also [[#Physical Quantities (PQ)|3.18 Physical Quantities (PQ)]]). In general, an upper and a lower boundary is specified. It is also possible to use ''center'' instead of ''low'' and ''high''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low || <center>TS</center> || <center>0..1</center> || <center>C</center> || the lower limit of the interval (i.e. the minimum amount).
|-
| '''high || <center>TS</center> || <center>0..1</center> || <center>C</center> || the upper limit of the interval (i.e. the maximum amount).
|-
| '''center || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of the interval
|}

The ''center'' child element is used when there is no interval, but an exact value. Alternative would be to demote IVL_PQ to data type PQ and populate the element’s ''@value'' attribute, but this is more difficult to process in XML. That is why the use of the ''center'' child element is deprecated.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<referenceRange>
<low value="7.5" unit="mmol/l"/>
<high value="10" unit="mmol/l"/>
</referenceRange>

<doseQuantity>
<center value="9" unit="1"/>
</doseQuantity>
</syntaxhighlight>

=== Ratio of quantities (RTO_QTY_QTY) ===

Elements of this data type specify ratios and have two child elements, a numerator and a denominator. The underlying QTY (Quantity) data type is an abstract data type and in a XML instance it has to be replaced by a specific data type using the ''@xsi:type'' instruction (see below).

In this specification only “PQ” or “INT” are allowed for the demotion of both ''numerator'' and ''denominator''. The relevant child elements are:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''numerator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the numerator of the ratio
|-
| '''denominator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the denominator of the ratio
|}

If a model attribute already is a RTO_QTY_QTY, you need to specify (demote) the OTY abstract data type for both ''numerator'' and ''denominator'' by using an ''@xsi:type'' instruction.
In some cases where the model attribute is of type “ANY”, also the root element shall carry an ''@xsi:type'' RTO_QTY_QTY instruction.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<maxDoseQuantity>
<numerator xsi:type="PQ" value="6"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="400" unit="mg"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="5"/>
<denominator xsi:type="PQ" value="1" unit="h"/>
</maxDoseQuantity>

<value xsi:type="RTO_QTY_QTY">
<numerator xsi:type="INT" value="1"/>
<denominator xsi:type="INT" value="10000"/>
</value>
</syntaxhighlight>

== Identification mechanisms ==

=== Object Identifiers (OIDs) ===

Standardized exchange of information using messages or documents also deals with unique identifications of objects and concepts, especially in environments where sender and receiver do not “know” each other necessarily.

It is important to understand the difference between identification of instances (ids) and code concepts (classifications). Within the context of HL7 interactions OIDs are quite often used.
An id points to a specific instance of an object or identification scheme (a particular methodology for the identification of a class of objects), for example a specific person as the patient or a physician, a specific lab observation or an X-ray photo.

In contrast to instance identifiers, a classification identifies a specific concept. The type of patient (inpatient, outpatient), the type of doctor (an anesthesiologist), the codes for gender or a lab observation (blood cell count) may serve as examples.

OIDs (object identifiers) are worldwide unique identifiers for objects. They are used in HL7 to specify identifications and classifications. An object in this sense is persistent, well-defined information, definitions or specifications and is represented with ids or codes.

Commonly used OIDs (i.e. used for a purpose that is wider in scope than the regional healthcare organization; used in communications between healthcare regions) can be found in OIDs registries such as

* [http://www.oid-info.com www.oid-info.com],
* [http://www.hl7.org www.hl7.org],
* [http://www.hl7.org.uk/version3group/oids.asp HL7 OID registry in the UK],
* [https://www.dimdi.de/dynamic/de/klassifikationen/weitere-klassifikationen-und-standards/oid/ OID registry Germany].

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|All OIDs with an element of 999 or 9999 are for documentation purposes only. They will be replaced by permanent OIDs once these have been as-signed/found/applied for.
|}

OID (Object Identifiers) are unique identifiers for any kind of objects. They are defined in Rec. ITU-T X.660 | ISO/IEC 9834-1. This identification system for objects and concepts makes reliable electronic information exchange possible. Administration and Registration is regulated by a set of rules, described in the corresponding chapter of this document.

Every artefact in ART-DECOR has an Object Identifier (OID). There are recommendations for the management and the exchange of Object Identifiers, partially defined in ISO TS 13582 <ref>ISO TS 13582: https://www.iso.org/standard/69652.html</ref>.

''HL7 International'' has created a type ontology for the OIDs in the HL7 registry to make it easier for the user community to search for OIDs they may be looking for and can be found at hl7.org.

From a policy perspective it is common practice in several healthcare related OID registries (HL7 International at http://www.hl7.org, OID Registry Germany at http://www.dimdi.de, OID registry Switzerland at http://oid.refdata.ch, and OID registry Austria at https://www.gesundheit.gv.at/OID_Frontend) to distinguish at least between the following types of OIDs:

{| class="hl7table" style="width:60%"
|+<ref group="Table">Recommended OID sub-branches for different artefacts</ref> ''Recommended OID sub-branches for different artefacts''
! Arc !! Description
|-
| .3 || organizational bodies and groups
|-
| .4 || identifier systems and namespaces
|-
| .5 || code systems
|-
| .7 || document artefacts
|-
| .9 || conformance profiles
|-
| .10 || templates
|-
| .11 || value sets
|-
| .19 || examples
|-
| .99 || experimental
|}

''Example: given that “your” root OID is 1.2.3.4.5, the first value set of your governance group is then to be 1.2.3.4.5.11.1, with .11 as the value set “branch” and the last .1 as the first artefact of that kind.''

In ART-DECOR a project typically is set into the .77 branch of a governance group. When setting up the project, the OID for that project also determines the artefact OIDs using throughout the ART-DECOR project. The following additional branches are used to distinguish between different OID types:

{| class="hl7table"
|+<ref group="Table">Recommended OID sub-branches for ART-DECOR projects</ref> ''Recommended OID sub-branches for different artefacts''
! Artefact code Description !! Recommended !! OID suffix
|-
| DS || dataset || .77.1
|-
| DE || dataset concept || .77.2
|-
| SC || scenario || .77.3
|-
| TR || transaction in scenario || .77.4
|-
| CS || code system || .77.5
|-
| IS || issue || .77.6
|-
| AC || actor in scenario || .77.7
|-
| CL || concept list in dataset || .77.8
|-
| EL || element in template || .77.9
|-
| TM || template || .77.10
|-
| VS || value set || .77.11
|-
| RL || rule for instances || .77.12
|-
| SX || test/example scenario || .77.18
|-
| EX || test/example instance || .77.19
|-
| QX || qualification test/example || .77.20
|-
| TX || test/example data element || .77.21
|-
| CM || community || .77.22
|-
| MP || concept map || .77.24
|}

In ART-DECOR a newly created project uses these OID branches automatically.

=== Instance identification ===

Instance identification is done with the id element of a class. Its type is II (instance identifier) and described in the data type section above. For example, a patient number can be represented as
* 2.16.578.1.34.1.5432.1, the root-OID of the issuing authority, for example a system/application in a hospital, and
* 67543242 as the ''@extension'', representing the patient number within the system defined by the ''@root'' attribute.

=== Coding scheme identification ===

Coding schemes have to be uniquely identified using OIDs as well. All coding tables used in this implementation guide show the corresponding OID that has to be specified in the ''@codeSystem'' attribute of coded elements. Both attributes ''@code'' and ''@codeSystem'' together allows a correct interpretation of concept and code.

=== List of identification schemes ===

The following are OIDs for commonly used identification schemes.

{| class="hl7table"
|+<ref group="Table">Commonly used identification scheme OIDs</ref> ''Commonly used identification scheme OIDs''
! OID !! Identification System Name !! Description !! Issuer
|-
| 1.2.276.0.76.4.8 || KV-Nummer || Krankenversichertennummer ||
|-
| 1.2.276.0.76.4.17 || BSNR || Betriebsstättennummer ||
|-
| 1.2.276.0.76.4.16 || LANR || lebenslange Arztnummer ||
|}

=== List of code systems ===

The following are OIDs for code systems.

{| class="hl7table"
|+<ref group="Table">Commonly used code system OIDs</ref> ''Commonly used code system OIDs''
! OID !! Code System Name !! Description !! Issuer
|-
| 2.16.840.1.113883.6.1 || LOINC || Logical Observation Identifiers Names and Codes (LOINC) || Regenstrief Institute
|-
| 2.16.840.1.113883.6.96 || SNOMED CT || Systemized Nomenclature in Medicine Reference Terminology (SNOMED CT) || SNOMED International
|-
| 1.0.3166.1.2 || ISO 3166-1 (second edition) || Country codes as per ISO 3166-1:2007 || ISO
|}

== Vocabulary ==

=== Code Systems ===

Within HL7, a ''Code System'' is defined as a collection of codes with associated designations and meanings. Examples of code systems include ICD-10, SNOMED CT, and LOINC.
To meet the requirements of a code system as defined by HL7, a given code must resolve to one and only one meaning within the code system. Given this definition, each code table in the HL7 Version 3 standard represents a different code system since codes are sometimes used in different tables to have different meanings.
For example, “M” in the administrative gender table (''AdministrativeGender'', OID 2.16.840.1.113883.5.1) means “male”, while “M” in the marital status table (''MaritalStatus'', OID 2.16.840.1.113883.5.2) means “married”.
In this specification, code system tables are not presented in detail.

=== Value Sets ===

A ''Value Set'' represents a uniquely identifiable set of valid concept representations, where any concept representation can be tested to determine whether or not it is a member of the value set.
Value set complexity may range from a simple flat list of concept codes drawn from a single code system, to an unbounded hierarchical set of possibly post-coordinated expressions drawn from multiple code systems.
Value sets exist to constrain the content for a coded element in an HL7 static model or data type property. Value sets cannot have null content and must contain at least one concept representation where any given concept is generally (but not required to be) represented by only a single code within the Value Set.

[[File:CDA_Core_Principles_Figure_3_ValueSet_Example.png|800px]]

<ref group="Figure">Example presentation of the value set “MaritalStatus”</ref> ''Example presentation of the value set “MaritalStatus”''

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that value set OIDs never appear in a CDA Release 2 document. They are used for constraint expressions, for example in implementation guides.
In order to send a specific code drawn from a value set, the corresponding code system has to be conveyed.
An example, in the implementation specification the constraint on the model element ''maritalStatusCode'' is expressed as “to be drawn from value set 2.16.840.1.113883.5.2 ''MaritalStatus''”.
To actually send a marital status of “M” (married) that is shown in the value set figure above, the corresponding HL7 CDA instance would say:
<syntaxhighlight lang="xml">
<maritalStatusCode code="M" codeSystem="2.16.840.1.113883.5.2"/>
</syntaxhighlight>
|}

In this specification, value set tables are not presented in detail.

==== Binding strength ====

There is an optional vocabulary strength for data types that support that feature (coded concepts). Examples include CD, CE, CV and CO. Values are required, extensible, preferred and example. Default is required.

Please note: the formerly supported values CNE (Coded No Extensibility) and CWE (Coded With Extensibility) in ART-DECOR are deprecated as of December 2017. Specification CNE is handled as required and CWE is handled as extensible.

{| class="hl7table"
|+<ref group="Table">Binding Strengths</ref> ''Binding Strengths''
! Strength !! Description
|-
|required||Required/CNE. Coded with no exceptions; this element SHALL be from the specified value set
|-
|extensible||Extensible/CWE. Coded with Exceptions; this element SHALL be from the specified value set if any of the codes within the value set can apply to the concept being communicated. If the value set does not cover the concept (based on human review), alternate codings (or, data type allowing, text) may be included instead.
|-
|preferred||Preferred. Instances are encouraged to draw from the specified codes for interoperability purposes but are not required to do so to be considered conformant.
|-
|example||Example. Instances are not expected or even encouraged to draw from the specified value set. The value set merely provides examples of the types of concepts intended to be included.
|}

Mismatches with required lead to validation errors (SHALL logic). Mismatches with extensible lead to validation warnings (SHOULD logic). Mismatches with preferred lead to validation information messages (MAY logic). Mismatches with example don't have any validation consequences.

== Appendix ==

=== References ===

<references/>

=== List of figures ===

<references group="Figure" />

=== List of tables ===

<references group="Table" />

HL7 CDA Core Principles

2019-06-14T20:08:06Z

Dammon: /* ANY as the generic data type */

== Introduction ==

This implementation guide specifies the ''Core Principles'' of using the ''Clinical Document Architecture'' <ref>Clinical Document Architecture Release 2: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=7</ref>.

=== Scope ===

This guide focuses on ''Data Types Release 1'' <ref>HL7 Data Types Release 1: http://www.hl7.org</ref>. Meanwhile an ISO specification ISO 21090 is out, also known as Data Type Release 2. The latter is subject to another implementation guide that will be published when ISO data types are used.

=== Focus of this document: HL7 Version 3 Data Types for CDA ===

The following chapters of this document will focus on the description of the data types and associated material. It will highlight the essentials in four chapters, all focusing on the Norwegian situation.
* '''Common aspects:''' explains common aspects of use of CDA and XML
* '''Data types:''' gives an overview and detailed specification of all data types used in CDA
* '''Identification schemes:''' explains major aspects of identification and the use in CDA
* '''Use of vocabulary:''' explains major aspects of vocabulary use in CDA.

=== Background ===

In many (European) countries, implementation guides for the use of data types in HL7 V3 are published. They take into account country specific constraints on the data types.

=== Legend of symbols ===

In this document several symbols are used.

{| class="hl7table" style="width:50%"
| [[File:Pfeil_rechts.png|50px]] || This is an important item
|-
| [[File:Issue.svg|50px]] || This is a known open issue
|-
| [[File:Faq.svg|50px]] || This is a frequently asked question (FAQ) with answer
|-
| [[File:Conformance.svg|50px]] || This is a constraint; in some situations also the rule identification is specified, e.g. dtr1-1-ANY, which links to the corresponding validation rule.
|}

=== Version history ===

{| class="hl7table" style="width:50%"
|+
! Version !! Date !! Description !! Author
|-
| 1.1 || 2019-04-24 || Refurbished guide based on earlier work || Kai U. Heitmann
|}

== Common aspects ==

=== Use of XML ===

HL7 Version 3 CDA uses the Extensible Markup Language (XML) as the exchange format. It is assumed that the reader is familiar with common XML aspects. However, some constraints are made regarding the use of CDA.

==== Character Set ====

{{ConstraintBox|
The character encoding of any CDA document shall be “UTF-8”.}}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="utf-8"?>
</syntaxhighlight>

=== CDA document structure ===

The XML namespace for CDA Release 2 documents is ''<nowiki>urn:hl7-org:v3</nowiki>''. This must be correctly mentioned in every XML instance.
CDA XML documents starts with the root element ''ClinicalDocument''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">


...

<component>
<structuredBody>
...
</structuredBody>
</component>

</ClinicalDocument>
</syntaxhighlight>

== Data types ==

=== Introduction ===

The following chapter describes the typical data types used in CDA implementation guides. For further information please refer to the HL7 V3 standard and its two parts concerning data types:
* Abstract Data type definition <ref>HL7 Version 3 Abstract Data type definition: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=264</ref>
* XML ITS for data types <ref>XML ITS for data types: https://www.hl7.org/documentcenter/public_temp_682D4D16-1C23-BA17-0C789BA52BEDB68E/wg/inm/datatypes-its-xml20050714.htm</ref>
Data types are properties of model class attributes and the basic building blocks of information in a CDA XML instance. For example, a model attribute named “time” has as its data type a time stamp “TS” (see Figure 1).

[[File:CDA_Core_Principles_Figure_1_CDA_Structure_Data_Types.png|700px]]

<ref group="Figure">CDA structure (left) and the data type specification (right)</ref> ''CDA structure (left) and the data type specification (right)''

=== XML representation of data types ===

Actual data is mostly carried in HL7 Version 3 by populating XML attributes and not as element content. Exceptions are names of persons and organizations as well as addresses.
The XML elements have names like the model attributes. For example, a model attribute “id” has a corresponding XML element named <id…>. The model determines the sequence of elements and their hierarchy. The data type itself determines the XML attributes within the start tag. The notation here is as follows:
{| class="hl7table"
|+
! Attribute !! DT !! Conf !! Description
|-
| (name of the model attribute or XML element) || Data type || Conformance, i.e. O, R, M || Textual description
|}

XML attributes (data type properties) are denoted as @attribute in order to distinguish their names from XML elements.
Example: in the example model above, the data type of the id attribute's is II (Instance Identifier). The corresponding XML attributes for that data type include @root and @extension.
<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id root="…" extension="..." />
</syntaxhighlight>
A description of the data types and their corresponding XML representation is contained in subsequent paragraphs of this guide.

==== Exceptions using XML element content ====
For most data types, the actual data is conveyed in XML attributes. However, there are some exceptions. For the data types binary (BIN), Encapsulated Data (ED), Entity Name (EN), Person Name (PN), Organization Name (ON), Trivial Name (TN), Address (AD) and character string data (ST), information is carried as element content.
Example: the components of an address <addr> are represented by sub elements with the data as element content (in the example shown in black).
<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr>
<streetAddressLine>Thormøhlens gate 12</streetAddressLine>
<postalCode>5006</postalCode>
<city>Bergen</city>
</addr>
</syntaxhighlight>

==== Combined data types ====
There are a number of socalled combined data types. For example, an interval with a lower and upper limit and a ratio that has a nominator and a denominator value.
In combined data types the substructure (e.g. <low> <high> in an interval) are represented as child elements of the relevant data type element.
<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110701"/>
<high value="20110729"/>
</effectiveTime>
</syntaxhighlight>

==== Conformance information ====
The conformance indicators distinguish kinds of conformance information described shortly here.
* '''O''': An optional item may be omitted if no data is present, i.e. no corresponding XML attribute or element is sent (marked as “O”)
* '''R''': For required items, lower cardinality is always zero or 1.
** Elements must be present and populated with data if present in the sending system. If no data is available (yet), a null flavor (see below) indicates and possibly classifies the missing information (marked as R).
** Attribute flagged as required must be present in the instance and populated.
* '''M''': For mandatory elements data must be sent and no missing values are allowed, i.e. if the sending system does not have information for mandatory elements the XML instance cannot be created and sent (marked as M).
* '''NP''': no data may be present at all (not permitted)
* '''C''': conditional conformance; typically a conformance table shows the circumstances (conditions) derived from information in the instance and the corresponding cardinalities and conformance statements.

=== Missing values (null flavor) ===
For every data type it is possible to specify a missing value including a kind of reason why data is missing. Instead of specifying any attribute of the corresponding element, a @nullFlavor attribute expresses the omission of data. Note that missing data is not allowed for mandatory elements (see above).
<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value nullFlavor="OTH"/>

<code nullFlavor="UNK"/>

<booleanInd nullFlavor="NI"/>

</syntaxhighlight>

The codes for the @nullFlavor attribute are drawn from the following hierarchical code system. It is a Coded Simple (CS), which means it has no code system (attribute @codeSystem) specified.
{| class="hl7table"
|+<ref group="Table">NullFlavor</ref> ''NullFlavor''
! Code
! width=15% | Print Name
! Definition / Description
|-
| NI || No Information || No information whatsoever can be inferred from this exceptional value. This is the most general exceptional value. It is also the default exceptional value.
|-
| OTH || other || The actual value is not an element in the value domain of a variable. (e.g., concept not provided by required code system).
|-
| NINF || negative infinity || Negative infinity of numbers.
|-
| PINF || positive infinity || Positive infinity of numbers.
|-
| UNK || unknown || A proper value is applicable, but not known.
|-
| ASKU || asked but unknown || Information was sought but not found (e.g., patient was asked but didn't know)
|-
| NAV || temporarily unavailable || Information is not available at this time but it is expected that it will be available later.
|-
| NASK || not asked || This information has not been sought (e.g., patient was not asked)
|-
| TRC || trace || The content is greater than zero, but too small to be quantified.
|-
| MSK || masked || There is information on this item available but it has not been provided by the sender due to security, privacy or other reasons. There may be an alternate mechanism for gaining access to this information.
Note: using this null flavour does provide information that may be a breach of confidentiality, even though no detail data is provided. Its primary purpose is for those circumstances where it is necessary to inform the receiver that the information does exist without providing any detail.
|-
| NA || not applicable || No proper value is applicable in this context (e.g., last menstrual period for a male).
|-
| NP || not present || Value is not present in a message. This is only defined in messages, never in application data! All values not present in the message must be replaced by the applicable default, or no-information (NI) as the default of all defaults.
|}

=== ANY as the generic data type ===

This abstract data type is the basis for all other data types. Not a single value within a CDA document has the effective data type ANY, but any data type within HL7v3 is a specialization of ANY. This also means that any other data type inherits all properties of ANY (see [[#Missing_values_.28null_flavor.29|“Missing values (null flavor)”]]).

The ANY type is occasionally found in HL7 models when it comes to clinical finding etc. where – at model time – the actual data type of the value is not known. At instantiation time however, the actual data type ''is'' known and ANY is always replaced by a particular data type in an instance.

One example is the observation value (child element value in an observation), where in the model the data type of value cannot be anticipated. When instantiation is taking place, the data type is specified by the XML instance attribute ''@xsi:type''. This information can be used by the receiver to validate and process the value.

Attributes of an element with this data type are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@nullFlavor''' || <center>CS</center> || <center>–</center> || Classification of the missing value, see [[#Missing_values_.28null_flavor.29|3.3 Missing values (null flavor)]].
|}

{| class="hl7table" style="width:100%"
| width=8% | <center>[[File:Conformance.svg|50px]] dtr1-1-ANY</center> || If there is a ''nullFlavor'', there shall be no other attribute or element, unless it's ''nullFlavor="OTH"''. In that case ''@codeSystem'' or ''originalText'' (see “code” data types) may have a value.
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">

<value xsi:type="CE" code="N11.9" codeSystem="2.16.840.1.113883.6.3"/>


<value xsi:type="PQ" value="12" unit="mL"/>


<value xsi:type="ED">this is text</value>
</syntaxhighlight>

=== Boolean (BL) ===

Elements of this data type refer to Boolean logic and have an attribute @value.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>BL</center> || <center>–</center> || Valued as “true” or “false”
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<negationInd value="false"/>

<deceasedInd value="true"/>

</syntaxhighlight>

In some situations, the BL data does not apply to an XML element, but an attribute. In that case, the attribute carries the Boolean value directly.
<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<support contextConductionInd ="false">
...
</support>
</syntaxhighlight>

=== Instance Identifier (II) ===

This data type identifies instances of classes like observations or entities (persons, organizations). Attributes are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@extension''' || <center>ST</center> || <center>O</center> || Identification
|-
| '''@root''' || <center>OID</center> || <center>R</center> || Source of identification
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id extension="13234453645" root="2.16.840.1.113883.2.6.15.3.427.1"/>
</syntaxhighlight>

The @root attribute is of type OID (object identifier), a unique identifier of the issuing authority or system. For example, a patient with a patient number 13234453645 created by a specific healthcare provider organization is uniquely identified by the number itself in @extension and the OID of the organization or the sending system, in the example 2.16.840.1.113883.2.6.15.3.427.1 in @root.
In some cases, a single OID identifies an object uniquely. In that situation, only @root is populated and @extension is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Encapsulated Data (ED) ===

Elements of this data type carry multimedia content. The actual multimedia content is represented as element content. There are two situations for the use of ED:
* Inline: The full data is transmitted in the type. This form is mainly used for text.
* By reference: a thumbnail is provided which links to the full data by reference.
In an instance, the data type is normally determined by an xsi:type specification and some attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@mediaType''' || <center>CS</center> || <center>O</center> || MIME media type classification. At time of writing this specification, the following MIME types are allowed:
* text/plain (plain text)
* text/html (text with html markup)
* image/jpeg (JPEG image)
* application/pdf (a PDF, portable document format)
* application/hl7-sda+xml (CDA documents).
|-
| '''@representation''' || <center>CS</center> || <center>O</center> || Representation of the multimedia content. At time of writing this specification, the following representations are allowed:
* TXT (text, this is the default)
* B64 base 64 encoded data, for example for embedded CDA documents).
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<text xsi:type="ED" mediaType="text/plain">
Patient treated sucessfully
</text>

<text mediaType="application/hl7-sda+xml" representation="B64">PD94bWw..etc..==</text>

</syntaxhighlight>

To include referenced data the two sub elements thumbnail and reference are used.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''reference''' || <center>TEL</center> || <center>0..*</center> || <center>O</center> || Link (URI) to full data
|-
| '''thumbnail''' || <center>ED</center> || <center>0..*</center> || <center>O</center> || Thumbnail of referenced data
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value xsi:type="ED" mediaType="image/png" representation="B64">
<reference value="http://radiology.bergen.no/xrays/128s.png"/>
<thumbnail mediaType="image/jpeg" representation="B64"> MNY...83== </thumbnail>
</value>
</syntaxhighlight>

=== Strings (ST) ===

This data type is a specialization of the ED type where @mediaType is fixed “text/plain” and @representation is fixed “TXT”. It allows conveying a character string as element content. This data type is used in other data types it like the @extension in instance identifiers, or address and person name data type components.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<lotNumber> 143GT6DT </lotNumber>
</syntaxhighlight>

=== Concept Descriptor (CD) ===

This data type specifies a concept by means of a code and its code system (except for situations where no code is available). A couple of specializations of data type CD exist, which differ in the main characteristics (properties) of the data type that may or may not be supported.

{| class="hl7table" style="width:50%"
|+ Table 1: Properties of data types used for codes
! <div style="text-align: right">DataType</div> !! CD !! CE !! CV !! CO !! CS
|-
! <div style="text-align: left">Property</div> !! !! !! !! !!
|-
| '''@code''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||<center>X</center>
|-
| '''@codeSystem''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''@codeSystemVersion''' || <center>X</center> || <center>X</center> || <center>X</center>|| <center>X</center> ||
|-
| '''@displayName''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''originalText''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''translation''' || <center>X</center> || <center>X</center> || || ||
|-
| '''qualifier''' || <center>X</center> || || || ||
|}

Because the CE variant is most used in practice, the general explanation of the proper-ties will be given with de description of CE (see below).
The only attribute that is unique to CD is briefly explained here.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@qualifier''' || <center>CR</center> || <center>O</center> || An additional qualifier for the code.
|}

Complex terminologies like SNOMED CT can be used only using data type CD.

=== Coded with Equivalents (CE) ===

With elements of this data type, a concept by means of a code and its coding system (except for situations where no code is available) can be specified. It optionally contains one or more equivalents using other code systems.
It may contain the following attributes:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@code''' || <center>ST</center> || <center>R</center> || The actual code
|-
| '''@codeSystem''' || <center>OID</center> || <center>R</center> || required to identify the code system were the code is drawn from. This is an OID (object identifier, see [[#Object_Identifiers_.28OIDs.29|Object Identifiers at 4.1]])
|-
| '''@displayName''' || <center>ST</center> || <center>O</center> || Optional textual representation of code. A display name may be specified representing the plain text of the code. The information of this attribute may not be used by the receiving system for interpretation, but only for display purposes. The display name may never be transmitted without a code and must have the same meaning as the code.
|-
| '''@codeSystemName''' || <center>ST</center> || <center>O</center> || A textual representation of the name of the code system
|-
| '''@codeSystemVersion''' || <center>ST</center> || <center>O</center> || A textual representation of the version of the code system
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"/>

<code code="AU" codeSystem="2.16.840.1.113883.5.33"/>

<storageCode code="AC" codeSystem="2.16.840.1.113883.5.34" displayName="active"/>

<code code="A45.0" displayName="Somatisierungsstörung" codeSystem="1.2.276.0.76.5.409" codeSystemName="ICD-10 GM 2012"/>
</syntaxhighlight>

There are some child elements of codes that can be used to express what the “original text” was that was used for the coding or to indicate that there are “translations” to other code systems than the primary code.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''originalText''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Textual representation of the concept, actually a description which was used to create the actual code
|}

No semantics may be assumed other than showing the ''@displayName'' to a user to clarify the code. A display name cannot occur without its code and must carry the same meaning.

In case no code is known, it is allowed to specify a ''@nullFlavor'' for the code element and to give information about the (not yet coded) concept in original text. However, this should be an exception.

If other codes than the primary code need to be conveyed adding a translation child element can be used.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<originalText>minor aphthous stomatitis</originalText>
</code>
</syntaxhighlight>

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''translation''' || <center>CD</center> || <center>0..*</center> || <center>O</center> || Alternative code(s)
|}

A ''translation'' element is also of type CD and shall have a code and a code system identified. It shall point to the same concept as the primary code. It is allowed that a translation conveys less conceptual details than the original code.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<translation code="528.2" codeSystem="2.16.840.1.113883.6.2" codeSystemName="ICD9" displayName="Oral aphthae"/>
</code>
</syntaxhighlight>

=== Coded Value (CV) ===

This is actually a specialization of CE (see above), with the exception that neither ''originalText'' nor ''translation'' child element are allowed.

=== Coded Simple Value (CS) ===

This is actually a specialization of CE (see above), with no code system attribute and no original text or translation child element allowed. It specifies a concept by means of a code from a ''predefined'' code system (table) where the code is drawn from. This data type is usually applied in the context of fixed predefined HL7 tables.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<statusCode code="completed"/>
</syntaxhighlight>

In this example ''statusCode'' is bound in the underlying model to the specific code system ''ActStatus''. Because it is predefined by means of the vocabulary binding, ''@codeSystem'' is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Telecommunication Address (TEL) ===

Elements of this type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>ST</center> || <center>R</center> || carries strings that represent telecommunication contact information
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

The actual data is preceded by the scheme (refer to Internet Standard “RFC 1738 Uniform Resource Locators (URL)” <ref>RFC 1738 Uniform Resource Locators (URL): http://www.ietf.org/rfc/rfc1738.txt</ref>.

Examples:
* telephone (tel:),
* fax (fax:),
* email (mailto:).

It must follow the rules defined in Internet “RFC 2806 URLs for Telephone Calls” <ref>RFC 2806 URLs for Telephone Calls: http://www.ietf.org/rfc/rfc2806.txt</ref>.

The following codes will be used in the “use” attribute:
* H – Home
* WP – Work
* MC can be used (in addition to H or WP) to denote that this is a mobile phone.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257" />

<telecom use="H" value="tel:55354257" />

<telecom use="H" value="fax:56542558" />

<telecom value="tel:+41.34.21.4765342"/>

<telecom value="mailto:opr@opr-sem.no"/>

<telecom use="WP MC" value="tel:97555786" />
</syntaxhighlight>

It is possible to express the useable period of a telecommunication contact. A child element ''useablePeriod'' is used as a time interval to indicate this period.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''useablePeriod''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257">
<useablePeriod>
<high value="20111201"/>
</useablePeriod>
</telecom>
</syntaxhighlight>

=== Postal Address (AD) ===

Elements of this data type have a substructure in order to represent a structured address specification. In this implementation guide only a selection of all possible child elements is allowed, the original HL7 specification is richer.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''streetAddressLine''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Street address, includes street name and house number
|-
| '''city''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || City
|-
| '''postalCode''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Postal code
|-
| '''country''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Country
|-
|}

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that the sequence of the sub elements is country specific, i.e. it has to follow “common” rules how to write an address. For example, an UK address and a German address have different sequences of address representation.
|}

A ''@use'' attribute can also be specified.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="WP">
<streetAddressLine>Anna-Louisa-Karsch-Str. 2</streetAddressLine>
<postalCode>10178</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="H WP">
<streetAddressLine>Tatungasse 34</streetAddressLine>
<postalCode>10825</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

Also, a country may be specified using the element ''country''.

=== Person Name (PN) ===

Elements of this data type do also have a substructure to represent the parts of a person name, like family or given name and prefixes.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>
<given>Franz</given>
<given>Ingrun</given>
<family>Nordmann</family>
</name>
</syntaxhighlight>

Previous or birth or maiden names are supported using the ''validTime'' element. ''validTime'' (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]]) specifies the validity range of the name.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">

<name>
<given>Jan</given>
<given>Olaf</given>
<family>Hendrikson</family>
<validTime>
<high value="20000101"/>
</validTime>
</name>
</syntaxhighlight>

Note that the name attribute is repeating, i.e. multiple (types of) names could be sent. It is up to the receiver (based on the value of the ''@use'' attribute, and ''validTime'') to decide what name it wants to use or import in its database.

=== Organisation Name (ON) ===

Elements of this data type represent a name of an organization.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name> Charité Berlin </name>
</syntaxhighlight>

The optional ''validTime'' element (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]] may be used to specify the validity range of the name of the organization.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name of the organization
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>The old hospital
<validTime>
<high value="20111231235959"/>
</validTime>
</name>
</syntaxhighlight>

Please note that the use of ''validTime'' yields XML mixed content which should be avoid-ed if possible.

=== Integer Number (INT) ===

Elements of this data type are used to specify integer numbers and have one attribute.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>int</center> || <center>R</center> || Integer value
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<sequenceNumber value="24"/>
</syntaxhighlight>

=== Physical Quantities (PQ) ===

Elements of this data type are physical quantities, i.e. a measurable quantity (or countable) value from the physical world. This is different from just a “number”, because there is a (natural) unit specified in which the measurable quantity is expressed.
Examples:
* an amount of blood 20 ml (sample volume)
* a cut with a length of 10 cm (result observation)
* a dose of 200 milligrams per administration (dosing)
* delivery of 60 pieces of a tablet (amount supplied).
Elements of this data type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>real</center> || <center>R</center> || value of the measurement
|-
| '''@unit''' || <center>CS</center> || <center>R</center> || unit of measurement
|}

In the unit of measurement unit is expressed following the ''Unified Code for Units of Measure'' (UCUM) specification. This specification is a collection of atomic units, prefixes and a corresponding grammar for valid combinations to build all-natural units of measurement. For a complete description of possible units, see the ''Unified Code for Units of Measure'' <ref>Unified Code for Units of Measure: http://unitsofmeasure.org/</ref> specification.
If a value is not countable or if measurable, for example expressed in milligrams or liters, then this unit is a valid UCUM unit like “mg” or “L”. If a value is countable, for example the number of tablets, then this attribute contains “1”.
In HL7 it is required that all PQ data type units are valid UCUM units.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<value value="165" unit="cm"/>

<value value="81.1" unit="kg"/>

<value value="120" unit="mm[Hg]"/>

<value value="5" unit="1"/>
</syntaxhighlight>

=== Point in Time (TS) ===

Elements of this data type have the attribute

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>TS</center> || <center>R</center> || Point in time
|}

and specify points in time in the format YYYYMMDDhhmmss±ZZZZ, where
* YYYY is the four-digit year,
* MM the two-digit month,
* DD the two-digit day,
* hh the two-digit hour,
* mm the two-digits minute and
* ss the two-digit second.
Optional a time zone ZZZZ, the four-digit time alignment with a preceding “-” or a “+” can be specified. If time zone is omitted, local time is assumed.
The point in time may be right truncated in respect to the precision of the information.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<effectiveTime value="20140412"/>

<effectiveTime value="201409091245"/>

<effectiveTime value="1996"/>

<birthTime value="19540714"/>

<effectiveTime value="20140412+0100"/>
</syntaxhighlight>

=== Intervals (IVL) ===

Intervals are defined only for data types with an ordinal or interval scale type. There are several possibilities to determine an interval (see Figure 2), for example to specify

* a lower <low> and an upper boundary <high> (a),
* a lower <low> boundary and width <width> (b)
* an upper boundary and width <width> (c) or
* the middle of the interval <nowiki><center></nowiki> and a width <width> (d).

[[File:CDA_Core_Principles_Figure_2_Determining_Intervals.png|700px]]

<ref group="Figure">Several possibilities to determine closed intervals</ref> ''Several possibilities to determine closed intervals''

{{ConstraintBox|
To indicate an interval, only the following combinations are permitted.
(1) A lower and an upper boundary may not be identical, and their accuracy has to be equal.

Correct examples:

{{BeginGreenBox|}}
Interval from 5 to 6
Interval from 20110607 until 20110612
{{EndGreenBox}}

Incorrect examples:

{{BeginRedBox|}}
Interval from 5 to 6.0
Interval from 20110101 to 2011
{{EndRedBox|}}

(2) A lower boundary and a width

(3) A lower limit boundary

(4) A upper limit boundary

(5) Only the middle of the interval

(6) Only the width of an interval}}

Accordingly, four child elements are available.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Lower boundary
|-
| '''high''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Upper boundary
|-
| '''center''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Where ''(T)'' is defined in this specification as one of the data types “TS” or “PQ”.

=== Interval of time (IVL_TS) ===

Elements of this data type represent time intervals. There are four possible child elements.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Lower boundary (start date/time)
|-
| '''high''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Upper boundary (end date/time)
|-
| '''center''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Normally, a lower and an upper boundary is given, both are points in time. Also, it is possible to specify open intervals like “since June 14, 1999” (left boundary given only) or “until September 24, 2006” (right boundary given).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110507"/>
<high value="20110909"/>
</effectiveTime>

<effectiveTime>
<low value="20110507"/>
</effectiveTime>

<value>
<low value="20110101"/>
<width value="120" unit="d"/>
</value>

<value>
<center value="20110101"/>
</value>
</syntaxhighlight>

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|It must be noted that intervals of time stamps in HL7 are equally treated as other interval types (e.g. integers). The statement, one may take 1–3 tablets (interval of integers), for example, says that you are allowed to take no more than three tablets, not 3½ or 3.5 tablets. On the other hand, when treat the words “until 12 June 2011” regarding the upper interval limit differently, particularly we assume that the entire day 12 June is still in-cluded in this time interval.
Thus, in human perception time intervals are handled differently com-pared to such as number intervals. This is a situation may lead to inconsist-encies in standardized communication. As a conclusion, an upper limit “12 June 2011” means that only the very first moment of the 12 June is included in the interval, but not, for example, the 12 June 13:00 hours.
Interpretation does not depend on the accuracy of the time:
* “after 2004” means “from January 1, 2005 00:00:00.000”,
* “after 20041201” means “from 2 December 2004 00:00:00.000 hours”,
* and “after 200412011200” means “from 1 December 2004 12:01:00.000”.

As a result, you have to carefully consider the specification and implemen-tation of time intervals upper boundaries. In order to prevent mis-understandings intervals are always specified with the date and time for an upper limit that would cover the whole day. Accordingly, “201106122359” means 12 June 2011 throughout the day.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="201106122359"/>
</effectiveTime>
</syntaxhighlight>

Because of the equal treatment of time intervals this is applied also to the lower limit boundaries of time intervals as “0000”. This means for example that “since 9 June 2011” is expressed as “201106090000”.
|}

The <width> element is of data type PQ (physical quantity). The value obviously shall relate to a period of time and it is required to include a “time” unit. These are the units “us” (microseconds), “ms” (milliseconds), “s” (seconds), “min” (minute), “h” (hours), “d” (day), “wk” (week), “mo” (month) and “a” (year).

{{ConstraintBox|
For interval of time stamps the @unit of a ''low'' or ''high'' child element shall use units
* us (microseconds),
* ms (milliseconds),
* s (seconds),
* min (minute),
* h (hours),
* d (day),
* wk (week),
* mo (month) or
* a (year).
}}

=== Interval of physical quantities (IVL_PQ) ===

Elements of this data type are used to indicate intervals of physical quantities (see also [[#Physical Quantities (PQ)|3.18 Physical Quantities (PQ)]]). In general, an upper and a lower boundary is specified. It is also possible to use ''center'' instead of ''low'' and ''high''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low || <center>TS</center> || <center>0..1</center> || <center>C</center> || the lower limit of the interval (i.e. the minimum amount).
|-
| '''high || <center>TS</center> || <center>0..1</center> || <center>C</center> || the upper limit of the interval (i.e. the maximum amount).
|-
| '''center || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of the interval
|}

The ''center'' child element is used when there is no interval, but an exact value. Alternative would be to demote IVL_PQ to data type PQ and populate the element’s ''@value'' attribute, but this is more difficult to process in XML. That is why the use of the ''center'' child element is deprecated.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<referenceRange>
<low value="7.5" unit="mmol/l"/>
<high value="10" unit="mmol/l"/>
</referenceRange>

<doseQuantity>
<center value="9" unit="1"/>
</doseQuantity>
</syntaxhighlight>

=== Ratio of quantities (RTO_QTY_QTY) ===

Elements of this data type specify ratios and have two child elements, a numerator and a denominator. The underlying QTY (Quantity) data type is an abstract data type and in a XML instance it has to be replaced by a specific data type using the ''@xsi:type'' instruction (see below).

In this specification only “PQ” or “INT” are allowed for the demotion of both ''numerator'' and ''denominator''. The relevant child elements are:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''numerator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the numerator of the ratio
|-
| '''denominator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the denominator of the ratio
|}

If a model attribute already is a RTO_QTY_QTY, you need to specify (demote) the OTY abstract data type for both ''numerator'' and ''denominator'' by using an ''@xsi:type'' instruction.
In some cases where the model attribute is of type “ANY”, also the root element shall carry an ''@xsi:type'' RTO_QTY_QTY instruction.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<maxDoseQuantity>
<numerator xsi:type="PQ" value="6"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="400" unit="mg"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="5"/>
<denominator xsi:type="PQ" value="1" unit="h"/>
</maxDoseQuantity>

<value xsi:type="RTO_QTY_QTY">
<numerator xsi:type="INT" value="1"/>
<denominator xsi:type="INT" value="10000"/>
</value>
</syntaxhighlight>

== Identification mechanisms ==

=== Object Identifiers (OIDs) ===

Standardized exchange of information using messages or documents also deals with unique identifications of objects and concepts, especially in environments where sender and receiver do not “know” each other necessarily.

It is important to understand the difference between identification of instances (ids) and code concepts (classifications). Within the context of HL7 interactions OIDs are quite often used.
An id points to a specific instance of an object or identification scheme (a particular methodology for the identification of a class of objects), for example a specific person as the patient or a physician, a specific lab observation or an X-ray photo.

In contrast to instance identifiers, a classification identifies a specific concept. The type of patient (inpatient, outpatient), the type of doctor (an anesthesiologist), the codes for gender or a lab observation (blood cell count) may serve as examples.

OIDs (object identifiers) are worldwide unique identifiers for objects. They are used in HL7 to specify identifications and classifications. An object in this sense is persistent, well-defined information, definitions or specifications and is represented with ids or codes.

Commonly used OIDs (i.e. used for a purpose that is wider in scope than the regional healthcare organization; used in communications between healthcare regions) can be found in OIDs registries such as

* [http://www.oid-info.com www.oid-info.com],
* [http://www.hl7.org www.hl7.org],
* [http://www.hl7.org.uk/version3group/oids.asp HL7 OID registry in the UK],
* [https://www.dimdi.de/dynamic/de/klassifikationen/weitere-klassifikationen-und-standards/oid/ OID registry Germany].

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|All OIDs with an element of 999 or 9999 are for documentation purposes only. They will be replaced by permanent OIDs once these have been as-signed/found/applied for.
|}

OID (Object Identifiers) are unique identifiers for any kind of objects. They are defined in Rec. ITU-T X.660 | ISO/IEC 9834-1. This identification system for objects and concepts makes reliable electronic information exchange possible. Administration and Registration is regulated by a set of rules, described in the corresponding chapter of this document.

Every artefact in ART-DECOR has an Object Identifier (OID). There are recommendations for the management and the exchange of Object Identifiers, partially defined in ISO TS 13582 <ref>ISO TS 13582: https://www.iso.org/standard/69652.html</ref>.

''HL7 International'' has created a type ontology for the OIDs in the HL7 registry to make it easier for the user community to search for OIDs they may be looking for and can be found at hl7.org.

From a policy perspective it is common practice in several healthcare related OID registries (HL7 International at http://www.hl7.org, OID Registry Germany at http://www.dimdi.de, OID registry Switzerland at http://oid.refdata.ch, and OID registry Austria at https://www.gesundheit.gv.at/OID_Frontend) to distinguish at least between the following types of OIDs:

{| class="hl7table" style="width:60%"
|+<ref group="Table">Recommended OID sub-branches for different artefacts</ref> ''Recommended OID sub-branches for different artefacts''
! Arc !! Description
|-
| .3 || organizational bodies and groups
|-
| .4 || identifier systems and namespaces
|-
| .5 || code systems
|-
| .7 || document artefacts
|-
| .9 || conformance profiles
|-
| .10 || templates
|-
| .11 || value sets
|-
| .19 || examples
|-
| .99 || experimental
|}

''Example: given that “your” root OID is 1.2.3.4.5, the first value set of your governance group is then to be 1.2.3.4.5.11.1, with .11 as the value set “branch” and the last .1 as the first artefact of that kind.''

In ART-DECOR a project typically is set into the .77 branch of a governance group. When setting up the project, the OID for that project also determines the artefact OIDs using throughout the ART-DECOR project. The following additional branches are used to distinguish between different OID types:

{| class="hl7table"
|+<ref group="Table">Recommended OID sub-branches for ART-DECOR projects</ref> ''Recommended OID sub-branches for different artefacts''
! Artefact code Description !! Recommended !! OID suffix
|-
| DS || dataset || .77.1
|-
| DE || dataset concept || .77.2
|-
| SC || scenario || .77.3
|-
| TR || transaction in scenario || .77.4
|-
| CS || code system || .77.5
|-
| IS || issue || .77.6
|-
| AC || actor in scenario || .77.7
|-
| CL || concept list in dataset || .77.8
|-
| EL || element in template || .77.9
|-
| TM || template || .77.10
|-
| VS || value set || .77.11
|-
| RL || rule for instances || .77.12
|-
| SX || test/example scenario || .77.18
|-
| EX || test/example instance || .77.19
|-
| QX || qualification test/example || .77.20
|-
| TX || test/example data element || .77.21
|-
| CM || community || .77.22
|-
| MP || concept map || .77.24
|}

In ART-DECOR a newly created project uses these OID branches automatically.

=== Instance identification ===

Instance identification is done with the id element of a class. Its type is II (instance identifier) and described in the data type section above. For example, a patient number can be represented as
* 2.16.578.1.34.1.5432.1, the root-OID of the issuing authority, for example a system/application in a hospital, and
* 67543242 as the ''@extension'', representing the patient number within the system defined by the ''@root'' attribute.

=== Coding scheme identification ===

Coding schemes have to be uniquely identified using OIDs as well. All coding tables used in this implementation guide show the corresponding OID that has to be specified in the ''@codeSystem'' attribute of coded elements. Both attributes ''@code'' and ''@codeSystem'' together allows a correct interpretation of concept and code.

=== List of identification schemes ===

The following are OIDs for commonly used identification schemes.

{| class="hl7table"
|+<ref group="Table">Commonly used identification scheme OIDs</ref> ''Commonly used identification scheme OIDs''
! OID !! Identification System Name !! Description !! Issuer
|-
| 1.2.276.0.76.4.8 || KV-Nummer || Krankenversichertennummer ||
|-
| 1.2.276.0.76.4.17 || BSNR || Betriebsstättennummer ||
|-
| 1.2.276.0.76.4.16 || LANR || lebenslange Arztnummer ||
|}

=== List of code systems ===

The following are OIDs for code systems.

{| class="hl7table"
|+<ref group="Table">Commonly used code system OIDs</ref> ''Commonly used code system OIDs''
! OID !! Code System Name !! Description !! Issuer
|-
| 2.16.840.1.113883.6.1 || LOINC || Logical Observation Identifiers Names and Codes (LOINC) || Regenstrief Institute
|-
| 2.16.840.1.113883.6.96 || SNOMED CT || Systemized Nomenclature in Medicine Reference Terminology (SNOMED CT) || SNOMED International
|-
| 1.0.3166.1.2 || ISO 3166-1 (second edition) || Country codes as per ISO 3166-1:2007 || ISO
|}

== Vocabulary ==

=== Code Systems ===

Within HL7, a ''Code System'' is defined as a collection of codes with associated designations and meanings. Examples of code systems include ICD-10, SNOMED CT, and LOINC.
To meet the requirements of a code system as defined by HL7, a given code must resolve to one and only one meaning within the code system. Given this definition, each code table in the HL7 Version 3 standard represents a different code system since codes are sometimes used in different tables to have different meanings.
For example, “M” in the administrative gender table (''AdministrativeGender'', OID 2.16.840.1.113883.5.1) means “male”, while “M” in the marital status table (''MaritalStatus'', OID 2.16.840.1.113883.5.2) means “married”.
In this specification, code system tables are not presented in detail.

=== Value Sets ===

A ''Value Set'' represents a uniquely identifiable set of valid concept representations, where any concept representation can be tested to determine whether or not it is a member of the value set.
Value set complexity may range from a simple flat list of concept codes drawn from a single code system, to an unbounded hierarchical set of possibly post-coordinated expressions drawn from multiple code systems.
Value sets exist to constrain the content for a coded element in an HL7 static model or data type property. Value sets cannot have null content and must contain at least one concept representation where any given concept is generally (but not required to be) represented by only a single code within the Value Set.

[[File:CDA_Core_Principles_Figure_3_ValueSet_Example.png|800px]]

<ref group="Figure">Example presentation of the value set “MaritalStatus”</ref> ''Example presentation of the value set “MaritalStatus”''

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that value set OIDs never appear in a CDA Release 2 document. They are used for constraint expressions, for example in implementation guides.
In order to send a specific code drawn from a value set, the corresponding code system has to be conveyed.
An example, in the implementation specification the constraint on the model element ''maritalStatusCode'' is expressed as “to be drawn from value set 2.16.840.1.113883.5.2 ''MaritalStatus''”.
To actually send a marital status of “M” (married) that is shown in the value set figure above, the corresponding HL7 CDA instance would say:
<syntaxhighlight lang="xml">
<maritalStatusCode code="M" codeSystem="2.16.840.1.113883.5.2"/>
</syntaxhighlight>
|}

In this specification, value set tables are not presented in detail.

==== Binding strength ====

There is an optional vocabulary strength for data types that support that feature (coded concepts). Examples include CD, CE, CV and CO. Values are required, extensible, preferred and example. Default is required.

Please note: the formerly supported values CNE (Coded No Extensibility) and CWE (Coded With Extensibility) in ART-DECOR are deprecated as of December 2017. Specification CNE is handled as required and CWE is handled as extensible.

{| class="hl7table"
|+<ref group="Table">Binding Strengths</ref> ''Binding Strengths''
! Strength !! Description
|-
|required||Required/CNE. Coded with no exceptions; this element SHALL be from the specified value set
|-
|extensible||Extensible/CWE. Coded with Exceptions; this element SHALL be from the specified value set if any of the codes within the value set can apply to the concept being communicated. If the value set does not cover the concept (based on human review), alternate codings (or, data type allowing, text) may be included instead.
|-
|preferred||Preferred. Instances are encouraged to draw from the specified codes for interoperability purposes but are not required to do so to be considered conformant.
|-
|example||Example. Instances are not expected or even encouraged to draw from the specified value set. The value set merely provides examples of the types of concepts intended to be included.
|}

Mismatches with required lead to validation errors (SHALL logic). Mismatches with extensible lead to validation warnings (SHOULD logic). Mismatches with preferred lead to validation information messages (MAY logic). Mismatches with example don't have any validation consequences.

== Appendix ==

=== References ===

<references/>

=== List of figures ===

<references group="Figure" />

=== List of tables ===

<references group="Table" />

HL7 CDA Core Principles

2019-06-14T20:06:12Z

Dammon:

== Introduction ==

This implementation guide specifies the ''Core Principles'' of using the ''Clinical Document Architecture'' <ref>Clinical Document Architecture Release 2: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=7</ref>.

=== Scope ===

This guide focuses on ''Data Types Release 1'' <ref>HL7 Data Types Release 1: http://www.hl7.org</ref>. Meanwhile an ISO specification ISO 21090 is out, also known as Data Type Release 2. The latter is subject to another implementation guide that will be published when ISO data types are used.

=== Focus of this document: HL7 Version 3 Data Types for CDA ===

The following chapters of this document will focus on the description of the data types and associated material. It will highlight the essentials in four chapters, all focusing on the Norwegian situation.
* '''Common aspects:''' explains common aspects of use of CDA and XML
* '''Data types:''' gives an overview and detailed specification of all data types used in CDA
* '''Identification schemes:''' explains major aspects of identification and the use in CDA
* '''Use of vocabulary:''' explains major aspects of vocabulary use in CDA.

=== Background ===

In many (European) countries, implementation guides for the use of data types in HL7 V3 are published. They take into account country specific constraints on the data types.

=== Legend of symbols ===

In this document several symbols are used.

{| class="hl7table" style="width:50%"
| [[File:Pfeil_rechts.png|50px]] || This is an important item
|-
| [[File:Issue.svg|50px]] || This is a known open issue
|-
| [[File:Faq.svg|50px]] || This is a frequently asked question (FAQ) with answer
|-
| [[File:Conformance.svg|50px]] || This is a constraint; in some situations also the rule identification is specified, e.g. dtr1-1-ANY, which links to the corresponding validation rule.
|}

=== Version history ===

{| class="hl7table" style="width:50%"
|+
! Version !! Date !! Description !! Author
|-
| 1.1 || 2019-04-24 || Refurbished guide based on earlier work || Kai U. Heitmann
|}

== Common aspects ==

=== Use of XML ===

HL7 Version 3 CDA uses the Extensible Markup Language (XML) as the exchange format. It is assumed that the reader is familiar with common XML aspects. However, some constraints are made regarding the use of CDA.

==== Character Set ====

{{ConstraintBox|
The character encoding of any CDA document shall be “UTF-8”.}}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="utf-8"?>
</syntaxhighlight>

=== CDA document structure ===

The XML namespace for CDA Release 2 documents is ''<nowiki>urn:hl7-org:v3</nowiki>''. This must be correctly mentioned in every XML instance.
CDA XML documents starts with the root element ''ClinicalDocument''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">


...

<component>
<structuredBody>
...
</structuredBody>
</component>

</ClinicalDocument>
</syntaxhighlight>

== Data types ==

=== Introduction ===

The following chapter describes the typical data types used in CDA implementation guides. For further information please refer to the HL7 V3 standard and its two parts concerning data types:
* Abstract Data type definition <ref>HL7 Version 3 Abstract Data type definition: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=264</ref>
* XML ITS for data types <ref>XML ITS for data types: https://www.hl7.org/documentcenter/public_temp_682D4D16-1C23-BA17-0C789BA52BEDB68E/wg/inm/datatypes-its-xml20050714.htm</ref>
Data types are properties of model class attributes and the basic building blocks of information in a CDA XML instance. For example, a model attribute named “time” has as its data type a time stamp “TS” (see Figure 1).

[[File:CDA_Core_Principles_Figure_1_CDA_Structure_Data_Types.png|700px]]

<ref group="Figure">CDA structure (left) and the data type specification (right)</ref> ''CDA structure (left) and the data type specification (right)''

=== XML representation of data types ===

Actual data is mostly carried in HL7 Version 3 by populating XML attributes and not as element content. Exceptions are names of persons and organizations as well as addresses.
The XML elements have names like the model attributes. For example, a model attribute “id” has a corresponding XML element named <id…>. The model determines the sequence of elements and their hierarchy. The data type itself determines the XML attributes within the start tag. The notation here is as follows:
{| class="hl7table"
|+
! Attribute !! DT !! Conf !! Description
|-
| (name of the model attribute or XML element) || Data type || Conformance, i.e. O, R, M || Textual description
|}

XML attributes (data type properties) are denoted as @attribute in order to distinguish their names from XML elements.
Example: in the example model above, the data type of the id attribute's is II (Instance Identifier). The corresponding XML attributes for that data type include @root and @extension.
<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id root="…" extension="..." />
</syntaxhighlight>
A description of the data types and their corresponding XML representation is contained in subsequent paragraphs of this guide.

==== Exceptions using XML element content ====
For most data types, the actual data is conveyed in XML attributes. However, there are some exceptions. For the data types binary (BIN), Encapsulated Data (ED), Entity Name (EN), Person Name (PN), Organization Name (ON), Trivial Name (TN), Address (AD) and character string data (ST), information is carried as element content.
Example: the components of an address <addr> are represented by sub elements with the data as element content (in the example shown in black).
<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr>
<streetAddressLine>Thormøhlens gate 12</streetAddressLine>
<postalCode>5006</postalCode>
<city>Bergen</city>
</addr>
</syntaxhighlight>

==== Combined data types ====
There are a number of socalled combined data types. For example, an interval with a lower and upper limit and a ratio that has a nominator and a denominator value.
In combined data types the substructure (e.g. <low> <high> in an interval) are represented as child elements of the relevant data type element.
<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110701"/>
<high value="20110729"/>
</effectiveTime>
</syntaxhighlight>

==== Conformance information ====
The conformance indicators distinguish kinds of conformance information described shortly here.
* '''O''': An optional item may be omitted if no data is present, i.e. no corresponding XML attribute or element is sent (marked as “O”)
* '''R''': For required items, lower cardinality is always zero or 1.
** Elements must be present and populated with data if present in the sending system. If no data is available (yet), a null flavor (see below) indicates and possibly classifies the missing information (marked as R).
** Attribute flagged as required must be present in the instance and populated.
* '''M''': For mandatory elements data must be sent and no missing values are allowed, i.e. if the sending system does not have information for mandatory elements the XML instance cannot be created and sent (marked as M).
* '''NP''': no data may be present at all (not permitted)
* '''C''': conditional conformance; typically a conformance table shows the circumstances (conditions) derived from information in the instance and the corresponding cardinalities and conformance statements.

=== Missing values (null flavor) ===
For every data type it is possible to specify a missing value including a kind of reason why data is missing. Instead of specifying any attribute of the corresponding element, a @nullFlavor attribute expresses the omission of data. Note that missing data is not allowed for mandatory elements (see above).
<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value nullFlavor="OTH"/>

<code nullFlavor="UNK"/>

<booleanInd nullFlavor="NI"/>

</syntaxhighlight>

The codes for the @nullFlavor attribute are drawn from the following hierarchical code system. It is a Coded Simple (CS), which means it has no code system (attribute @codeSystem) specified.
{| class="hl7table"
|+<ref group="Table">NullFlavor</ref> ''NullFlavor''
! Code
! width=15% | Print Name
! Definition / Description
|-
| NI || No Information || No information whatsoever can be inferred from this exceptional value. This is the most general exceptional value. It is also the default exceptional value.
|-
| OTH || other || The actual value is not an element in the value domain of a variable. (e.g., concept not provided by required code system).
|-
| NINF || negative infinity || Negative infinity of numbers.
|-
| PINF || positive infinity || Positive infinity of numbers.
|-
| UNK || unknown || A proper value is applicable, but not known.
|-
| ASKU || asked but unknown || Information was sought but not found (e.g., patient was asked but didn't know)
|-
| NAV || temporarily unavailable || Information is not available at this time but it is expected that it will be available later.
|-
| NASK || not asked || This information has not been sought (e.g., patient was not asked)
|-
| TRC || trace || The content is greater than zero, but too small to be quantified.
|-
| MSK || masked || There is information on this item available but it has not been provided by the sender due to security, privacy or other reasons. There may be an alternate mechanism for gaining access to this information.
Note: using this null flavour does provide information that may be a breach of confidentiality, even though no detail data is provided. Its primary purpose is for those circumstances where it is necessary to inform the receiver that the information does exist without providing any detail.
|-
| NA || not applicable || No proper value is applicable in this context (e.g., last menstrual period for a male).
|-
| NP || not present || Value is not present in a message. This is only defined in messages, never in application data! All values not present in the message must be replaced by the applicable default, or no-information (NI) as the default of all defaults.
|}

=== ANY as the generic data type ===

This abstract data type is the basis for all other data types. Not a single value within a CDA document has the effective data type ANY, but any data type within HL7v3 is a specialization of ANY. This also means that any other data type inherits all properties of ANY (see [[#Missing_values_.28null_flavor.29|“Missing values (null flavor)”]]).

The ANY type is occasionally found in HL7 models when it comes to clinical finding etc. where – at model time – the actual data type of the value is not known. At instantiation time however, the actual data type ''is'' known and ANY is always replaced by a particular data type in an instance.

One example is the observation value (child element value in an observation), where in the model the data type of value cannot be anticipated. When instantiation is taking place, the data type is specified by the XML instance attribute ''@xsi:type''. This information can be used by the receiver to validate and process the value.

Attributes of an element with this data type are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@nullFlavor''' || <center>CS</center> || <center>–</center> || Classification of the missing value, see [[#Missing_values_.28null_flavor.29|3.3 Missing values (null flavor)]].
|}

{| class="hl7table" style="width:100%"
| <center>[[File:Conformance.svg|50px]] dtr1-1-ANY</center> || If there is a ''nullFlavor'', there shall be no other attribute or element, unless it's ''nullFlavor="OTH"''. In that case ''@codeSystem'' or ''originalText'' (see “code” data types) may have a value.
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">

<value xsi:type="CE" code="N11.9" codeSystem="2.16.840.1.113883.6.3"/>


<value xsi:type="PQ" value="12" unit="mL"/>


<value xsi:type="ED">this is text</value>
</syntaxhighlight>

=== Boolean (BL) ===

Elements of this data type refer to Boolean logic and have an attribute @value.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>BL</center> || <center>–</center> || Valued as “true” or “false”
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<negationInd value="false"/>

<deceasedInd value="true"/>

</syntaxhighlight>

In some situations, the BL data does not apply to an XML element, but an attribute. In that case, the attribute carries the Boolean value directly.
<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<support contextConductionInd ="false">
...
</support>
</syntaxhighlight>

=== Instance Identifier (II) ===

This data type identifies instances of classes like observations or entities (persons, organizations). Attributes are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@extension''' || <center>ST</center> || <center>O</center> || Identification
|-
| '''@root''' || <center>OID</center> || <center>R</center> || Source of identification
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id extension="13234453645" root="2.16.840.1.113883.2.6.15.3.427.1"/>
</syntaxhighlight>

The @root attribute is of type OID (object identifier), a unique identifier of the issuing authority or system. For example, a patient with a patient number 13234453645 created by a specific healthcare provider organization is uniquely identified by the number itself in @extension and the OID of the organization or the sending system, in the example 2.16.840.1.113883.2.6.15.3.427.1 in @root.
In some cases, a single OID identifies an object uniquely. In that situation, only @root is populated and @extension is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Encapsulated Data (ED) ===

Elements of this data type carry multimedia content. The actual multimedia content is represented as element content. There are two situations for the use of ED:
* Inline: The full data is transmitted in the type. This form is mainly used for text.
* By reference: a thumbnail is provided which links to the full data by reference.
In an instance, the data type is normally determined by an xsi:type specification and some attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@mediaType''' || <center>CS</center> || <center>O</center> || MIME media type classification. At time of writing this specification, the following MIME types are allowed:
* text/plain (plain text)
* text/html (text with html markup)
* image/jpeg (JPEG image)
* application/pdf (a PDF, portable document format)
* application/hl7-sda+xml (CDA documents).
|-
| '''@representation''' || <center>CS</center> || <center>O</center> || Representation of the multimedia content. At time of writing this specification, the following representations are allowed:
* TXT (text, this is the default)
* B64 base 64 encoded data, for example for embedded CDA documents).
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<text xsi:type="ED" mediaType="text/plain">
Patient treated sucessfully
</text>

<text mediaType="application/hl7-sda+xml" representation="B64">PD94bWw..etc..==</text>

</syntaxhighlight>

To include referenced data the two sub elements thumbnail and reference are used.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''reference''' || <center>TEL</center> || <center>0..*</center> || <center>O</center> || Link (URI) to full data
|-
| '''thumbnail''' || <center>ED</center> || <center>0..*</center> || <center>O</center> || Thumbnail of referenced data
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value xsi:type="ED" mediaType="image/png" representation="B64">
<reference value="http://radiology.bergen.no/xrays/128s.png"/>
<thumbnail mediaType="image/jpeg" representation="B64"> MNY...83== </thumbnail>
</value>
</syntaxhighlight>

=== Strings (ST) ===

This data type is a specialization of the ED type where @mediaType is fixed “text/plain” and @representation is fixed “TXT”. It allows conveying a character string as element content. This data type is used in other data types it like the @extension in instance identifiers, or address and person name data type components.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<lotNumber> 143GT6DT </lotNumber>
</syntaxhighlight>

=== Concept Descriptor (CD) ===

This data type specifies a concept by means of a code and its code system (except for situations where no code is available). A couple of specializations of data type CD exist, which differ in the main characteristics (properties) of the data type that may or may not be supported.

{| class="hl7table" style="width:50%"
|+ Table 1: Properties of data types used for codes
! <div style="text-align: right">DataType</div> !! CD !! CE !! CV !! CO !! CS
|-
! <div style="text-align: left">Property</div> !! !! !! !! !!
|-
| '''@code''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||<center>X</center>
|-
| '''@codeSystem''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''@codeSystemVersion''' || <center>X</center> || <center>X</center> || <center>X</center>|| <center>X</center> ||
|-
| '''@displayName''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''originalText''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''translation''' || <center>X</center> || <center>X</center> || || ||
|-
| '''qualifier''' || <center>X</center> || || || ||
|}

Because the CE variant is most used in practice, the general explanation of the proper-ties will be given with de description of CE (see below).
The only attribute that is unique to CD is briefly explained here.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@qualifier''' || <center>CR</center> || <center>O</center> || An additional qualifier for the code.
|}

Complex terminologies like SNOMED CT can be used only using data type CD.

=== Coded with Equivalents (CE) ===

With elements of this data type, a concept by means of a code and its coding system (except for situations where no code is available) can be specified. It optionally contains one or more equivalents using other code systems.
It may contain the following attributes:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@code''' || <center>ST</center> || <center>R</center> || The actual code
|-
| '''@codeSystem''' || <center>OID</center> || <center>R</center> || required to identify the code system were the code is drawn from. This is an OID (object identifier, see [[#Object_Identifiers_.28OIDs.29|Object Identifiers at 4.1]])
|-
| '''@displayName''' || <center>ST</center> || <center>O</center> || Optional textual representation of code. A display name may be specified representing the plain text of the code. The information of this attribute may not be used by the receiving system for interpretation, but only for display purposes. The display name may never be transmitted without a code and must have the same meaning as the code.
|-
| '''@codeSystemName''' || <center>ST</center> || <center>O</center> || A textual representation of the name of the code system
|-
| '''@codeSystemVersion''' || <center>ST</center> || <center>O</center> || A textual representation of the version of the code system
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"/>

<code code="AU" codeSystem="2.16.840.1.113883.5.33"/>

<storageCode code="AC" codeSystem="2.16.840.1.113883.5.34" displayName="active"/>

<code code="A45.0" displayName="Somatisierungsstörung" codeSystem="1.2.276.0.76.5.409" codeSystemName="ICD-10 GM 2012"/>
</syntaxhighlight>

There are some child elements of codes that can be used to express what the “original text” was that was used for the coding or to indicate that there are “translations” to other code systems than the primary code.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''originalText''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Textual representation of the concept, actually a description which was used to create the actual code
|}

No semantics may be assumed other than showing the ''@displayName'' to a user to clarify the code. A display name cannot occur without its code and must carry the same meaning.

In case no code is known, it is allowed to specify a ''@nullFlavor'' for the code element and to give information about the (not yet coded) concept in original text. However, this should be an exception.

If other codes than the primary code need to be conveyed adding a translation child element can be used.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<originalText>minor aphthous stomatitis</originalText>
</code>
</syntaxhighlight>

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''translation''' || <center>CD</center> || <center>0..*</center> || <center>O</center> || Alternative code(s)
|}

A ''translation'' element is also of type CD and shall have a code and a code system identified. It shall point to the same concept as the primary code. It is allowed that a translation conveys less conceptual details than the original code.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<translation code="528.2" codeSystem="2.16.840.1.113883.6.2" codeSystemName="ICD9" displayName="Oral aphthae"/>
</code>
</syntaxhighlight>

=== Coded Value (CV) ===

This is actually a specialization of CE (see above), with the exception that neither ''originalText'' nor ''translation'' child element are allowed.

=== Coded Simple Value (CS) ===

This is actually a specialization of CE (see above), with no code system attribute and no original text or translation child element allowed. It specifies a concept by means of a code from a ''predefined'' code system (table) where the code is drawn from. This data type is usually applied in the context of fixed predefined HL7 tables.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<statusCode code="completed"/>
</syntaxhighlight>

In this example ''statusCode'' is bound in the underlying model to the specific code system ''ActStatus''. Because it is predefined by means of the vocabulary binding, ''@codeSystem'' is omitted.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Telecommunication Address (TEL) ===

Elements of this type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>ST</center> || <center>R</center> || carries strings that represent telecommunication contact information
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

The actual data is preceded by the scheme (refer to Internet Standard “RFC 1738 Uniform Resource Locators (URL)” <ref>RFC 1738 Uniform Resource Locators (URL): http://www.ietf.org/rfc/rfc1738.txt</ref>.

Examples:
* telephone (tel:),
* fax (fax:),
* email (mailto:).

It must follow the rules defined in Internet “RFC 2806 URLs for Telephone Calls” <ref>RFC 2806 URLs for Telephone Calls: http://www.ietf.org/rfc/rfc2806.txt</ref>.

The following codes will be used in the “use” attribute:
* H – Home
* WP – Work
* MC can be used (in addition to H or WP) to denote that this is a mobile phone.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257" />

<telecom use="H" value="tel:55354257" />

<telecom use="H" value="fax:56542558" />

<telecom value="tel:+41.34.21.4765342"/>

<telecom value="mailto:opr@opr-sem.no"/>

<telecom use="WP MC" value="tel:97555786" />
</syntaxhighlight>

It is possible to express the useable period of a telecommunication contact. A child element ''useablePeriod'' is used as a time interval to indicate this period.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''useablePeriod''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257">
<useablePeriod>
<high value="20111201"/>
</useablePeriod>
</telecom>
</syntaxhighlight>

=== Postal Address (AD) ===

Elements of this data type have a substructure in order to represent a structured address specification. In this implementation guide only a selection of all possible child elements is allowed, the original HL7 specification is richer.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''streetAddressLine''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Street address, includes street name and house number
|-
| '''city''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || City
|-
| '''postalCode''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Postal code
|-
| '''country''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Country
|-
|}

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that the sequence of the sub elements is country specific, i.e. it has to follow “common” rules how to write an address. For example, an UK address and a German address have different sequences of address representation.
|}

A ''@use'' attribute can also be specified.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="WP">
<streetAddressLine>Anna-Louisa-Karsch-Str. 2</streetAddressLine>
<postalCode>10178</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="H WP">
<streetAddressLine>Tatungasse 34</streetAddressLine>
<postalCode>10825</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

Also, a country may be specified using the element ''country''.

=== Person Name (PN) ===

Elements of this data type do also have a substructure to represent the parts of a person name, like family or given name and prefixes.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>
<given>Franz</given>
<given>Ingrun</given>
<family>Nordmann</family>
</name>
</syntaxhighlight>

Previous or birth or maiden names are supported using the ''validTime'' element. ''validTime'' (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]]) specifies the validity range of the name.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">

<name>
<given>Jan</given>
<given>Olaf</given>
<family>Hendrikson</family>
<validTime>
<high value="20000101"/>
</validTime>
</name>
</syntaxhighlight>

Note that the name attribute is repeating, i.e. multiple (types of) names could be sent. It is up to the receiver (based on the value of the ''@use'' attribute, and ''validTime'') to decide what name it wants to use or import in its database.

=== Organisation Name (ON) ===

Elements of this data type represent a name of an organization.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name> Charité Berlin </name>
</syntaxhighlight>

The optional ''validTime'' element (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]] may be used to specify the validity range of the name of the organization.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name of the organization
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>The old hospital
<validTime>
<high value="20111231235959"/>
</validTime>
</name>
</syntaxhighlight>

Please note that the use of ''validTime'' yields XML mixed content which should be avoid-ed if possible.

=== Integer Number (INT) ===

Elements of this data type are used to specify integer numbers and have one attribute.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>int</center> || <center>R</center> || Integer value
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<sequenceNumber value="24"/>
</syntaxhighlight>

=== Physical Quantities (PQ) ===

Elements of this data type are physical quantities, i.e. a measurable quantity (or countable) value from the physical world. This is different from just a “number”, because there is a (natural) unit specified in which the measurable quantity is expressed.
Examples:
* an amount of blood 20 ml (sample volume)
* a cut with a length of 10 cm (result observation)
* a dose of 200 milligrams per administration (dosing)
* delivery of 60 pieces of a tablet (amount supplied).
Elements of this data type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>real</center> || <center>R</center> || value of the measurement
|-
| '''@unit''' || <center>CS</center> || <center>R</center> || unit of measurement
|}

In the unit of measurement unit is expressed following the ''Unified Code for Units of Measure'' (UCUM) specification. This specification is a collection of atomic units, prefixes and a corresponding grammar for valid combinations to build all-natural units of measurement. For a complete description of possible units, see the ''Unified Code for Units of Measure'' <ref>Unified Code for Units of Measure: http://unitsofmeasure.org/</ref> specification.
If a value is not countable or if measurable, for example expressed in milligrams or liters, then this unit is a valid UCUM unit like “mg” or “L”. If a value is countable, for example the number of tablets, then this attribute contains “1”.
In HL7 it is required that all PQ data type units are valid UCUM units.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<value value="165" unit="cm"/>

<value value="81.1" unit="kg"/>

<value value="120" unit="mm[Hg]"/>

<value value="5" unit="1"/>
</syntaxhighlight>

=== Point in Time (TS) ===

Elements of this data type have the attribute

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>TS</center> || <center>R</center> || Point in time
|}

and specify points in time in the format YYYYMMDDhhmmss±ZZZZ, where
* YYYY is the four-digit year,
* MM the two-digit month,
* DD the two-digit day,
* hh the two-digit hour,
* mm the two-digits minute and
* ss the two-digit second.
Optional a time zone ZZZZ, the four-digit time alignment with a preceding “-” or a “+” can be specified. If time zone is omitted, local time is assumed.
The point in time may be right truncated in respect to the precision of the information.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<effectiveTime value="20140412"/>

<effectiveTime value="201409091245"/>

<effectiveTime value="1996"/>

<birthTime value="19540714"/>

<effectiveTime value="20140412+0100"/>
</syntaxhighlight>

=== Intervals (IVL) ===

Intervals are defined only for data types with an ordinal or interval scale type. There are several possibilities to determine an interval (see Figure 2), for example to specify

* a lower <low> and an upper boundary <high> (a),
* a lower <low> boundary and width <width> (b)
* an upper boundary and width <width> (c) or
* the middle of the interval <nowiki><center></nowiki> and a width <width> (d).

[[File:CDA_Core_Principles_Figure_2_Determining_Intervals.png|700px]]

<ref group="Figure">Several possibilities to determine closed intervals</ref> ''Several possibilities to determine closed intervals''

{{ConstraintBox|
To indicate an interval, only the following combinations are permitted.
(1) A lower and an upper boundary may not be identical, and their accuracy has to be equal.

Correct examples:

{{BeginGreenBox|}}
Interval from 5 to 6
Interval from 20110607 until 20110612
{{EndGreenBox}}

Incorrect examples:

{{BeginRedBox|}}
Interval from 5 to 6.0
Interval from 20110101 to 2011
{{EndRedBox|}}

(2) A lower boundary and a width

(3) A lower limit boundary

(4) A upper limit boundary

(5) Only the middle of the interval

(6) Only the width of an interval}}

Accordingly, four child elements are available.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Lower boundary
|-
| '''high''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Upper boundary
|-
| '''center''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Where ''(T)'' is defined in this specification as one of the data types “TS” or “PQ”.

=== Interval of time (IVL_TS) ===

Elements of this data type represent time intervals. There are four possible child elements.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Lower boundary (start date/time)
|-
| '''high''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Upper boundary (end date/time)
|-
| '''center''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Normally, a lower and an upper boundary is given, both are points in time. Also, it is possible to specify open intervals like “since June 14, 1999” (left boundary given only) or “until September 24, 2006” (right boundary given).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110507"/>
<high value="20110909"/>
</effectiveTime>

<effectiveTime>
<low value="20110507"/>
</effectiveTime>

<value>
<low value="20110101"/>
<width value="120" unit="d"/>
</value>

<value>
<center value="20110101"/>
</value>
</syntaxhighlight>

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|It must be noted that intervals of time stamps in HL7 are equally treated as other interval types (e.g. integers). The statement, one may take 1–3 tablets (interval of integers), for example, says that you are allowed to take no more than three tablets, not 3½ or 3.5 tablets. On the other hand, when treat the words “until 12 June 2011” regarding the upper interval limit differently, particularly we assume that the entire day 12 June is still in-cluded in this time interval.
Thus, in human perception time intervals are handled differently com-pared to such as number intervals. This is a situation may lead to inconsist-encies in standardized communication. As a conclusion, an upper limit “12 June 2011” means that only the very first moment of the 12 June is included in the interval, but not, for example, the 12 June 13:00 hours.
Interpretation does not depend on the accuracy of the time:
* “after 2004” means “from January 1, 2005 00:00:00.000”,
* “after 20041201” means “from 2 December 2004 00:00:00.000 hours”,
* and “after 200412011200” means “from 1 December 2004 12:01:00.000”.

As a result, you have to carefully consider the specification and implemen-tation of time intervals upper boundaries. In order to prevent mis-understandings intervals are always specified with the date and time for an upper limit that would cover the whole day. Accordingly, “201106122359” means 12 June 2011 throughout the day.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="201106122359"/>
</effectiveTime>
</syntaxhighlight>

Because of the equal treatment of time intervals this is applied also to the lower limit boundaries of time intervals as “0000”. This means for example that “since 9 June 2011” is expressed as “201106090000”.
|}

The <width> element is of data type PQ (physical quantity). The value obviously shall relate to a period of time and it is required to include a “time” unit. These are the units “us” (microseconds), “ms” (milliseconds), “s” (seconds), “min” (minute), “h” (hours), “d” (day), “wk” (week), “mo” (month) and “a” (year).

{{ConstraintBox|
For interval of time stamps the @unit of a ''low'' or ''high'' child element shall use units
* us (microseconds),
* ms (milliseconds),
* s (seconds),
* min (minute),
* h (hours),
* d (day),
* wk (week),
* mo (month) or
* a (year).
}}

=== Interval of physical quantities (IVL_PQ) ===

Elements of this data type are used to indicate intervals of physical quantities (see also [[#Physical Quantities (PQ)|3.18 Physical Quantities (PQ)]]). In general, an upper and a lower boundary is specified. It is also possible to use ''center'' instead of ''low'' and ''high''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low || <center>TS</center> || <center>0..1</center> || <center>C</center> || the lower limit of the interval (i.e. the minimum amount).
|-
| '''high || <center>TS</center> || <center>0..1</center> || <center>C</center> || the upper limit of the interval (i.e. the maximum amount).
|-
| '''center || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of the interval
|}

The ''center'' child element is used when there is no interval, but an exact value. Alternative would be to demote IVL_PQ to data type PQ and populate the element’s ''@value'' attribute, but this is more difficult to process in XML. That is why the use of the ''center'' child element is deprecated.

{| class="hl7table" style="width:100%"
| width=5% | [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<referenceRange>
<low value="7.5" unit="mmol/l"/>
<high value="10" unit="mmol/l"/>
</referenceRange>

<doseQuantity>
<center value="9" unit="1"/>
</doseQuantity>
</syntaxhighlight>

=== Ratio of quantities (RTO_QTY_QTY) ===

Elements of this data type specify ratios and have two child elements, a numerator and a denominator. The underlying QTY (Quantity) data type is an abstract data type and in a XML instance it has to be replaced by a specific data type using the ''@xsi:type'' instruction (see below).

In this specification only “PQ” or “INT” are allowed for the demotion of both ''numerator'' and ''denominator''. The relevant child elements are:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''numerator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the numerator of the ratio
|-
| '''denominator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the denominator of the ratio
|}

If a model attribute already is a RTO_QTY_QTY, you need to specify (demote) the OTY abstract data type for both ''numerator'' and ''denominator'' by using an ''@xsi:type'' instruction.
In some cases where the model attribute is of type “ANY”, also the root element shall carry an ''@xsi:type'' RTO_QTY_QTY instruction.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<maxDoseQuantity>
<numerator xsi:type="PQ" value="6"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="400" unit="mg"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="5"/>
<denominator xsi:type="PQ" value="1" unit="h"/>
</maxDoseQuantity>

<value xsi:type="RTO_QTY_QTY">
<numerator xsi:type="INT" value="1"/>
<denominator xsi:type="INT" value="10000"/>
</value>
</syntaxhighlight>

== Identification mechanisms ==

=== Object Identifiers (OIDs) ===

Standardized exchange of information using messages or documents also deals with unique identifications of objects and concepts, especially in environments where sender and receiver do not “know” each other necessarily.

It is important to understand the difference between identification of instances (ids) and code concepts (classifications). Within the context of HL7 interactions OIDs are quite often used.
An id points to a specific instance of an object or identification scheme (a particular methodology for the identification of a class of objects), for example a specific person as the patient or a physician, a specific lab observation or an X-ray photo.

In contrast to instance identifiers, a classification identifies a specific concept. The type of patient (inpatient, outpatient), the type of doctor (an anesthesiologist), the codes for gender or a lab observation (blood cell count) may serve as examples.

OIDs (object identifiers) are worldwide unique identifiers for objects. They are used in HL7 to specify identifications and classifications. An object in this sense is persistent, well-defined information, definitions or specifications and is represented with ids or codes.

Commonly used OIDs (i.e. used for a purpose that is wider in scope than the regional healthcare organization; used in communications between healthcare regions) can be found in OIDs registries such as

* [http://www.oid-info.com www.oid-info.com],
* [http://www.hl7.org www.hl7.org],
* [http://www.hl7.org.uk/version3group/oids.asp HL7 OID registry in the UK],
* [https://www.dimdi.de/dynamic/de/klassifikationen/weitere-klassifikationen-und-standards/oid/ OID registry Germany].

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|All OIDs with an element of 999 or 9999 are for documentation purposes only. They will be replaced by permanent OIDs once these have been as-signed/found/applied for.
|}

OID (Object Identifiers) are unique identifiers for any kind of objects. They are defined in Rec. ITU-T X.660 | ISO/IEC 9834-1. This identification system for objects and concepts makes reliable electronic information exchange possible. Administration and Registration is regulated by a set of rules, described in the corresponding chapter of this document.

Every artefact in ART-DECOR has an Object Identifier (OID). There are recommendations for the management and the exchange of Object Identifiers, partially defined in ISO TS 13582 <ref>ISO TS 13582: https://www.iso.org/standard/69652.html</ref>.

''HL7 International'' has created a type ontology for the OIDs in the HL7 registry to make it easier for the user community to search for OIDs they may be looking for and can be found at hl7.org.

From a policy perspective it is common practice in several healthcare related OID registries (HL7 International at http://www.hl7.org, OID Registry Germany at http://www.dimdi.de, OID registry Switzerland at http://oid.refdata.ch, and OID registry Austria at https://www.gesundheit.gv.at/OID_Frontend) to distinguish at least between the following types of OIDs:

{| class="hl7table" style="width:60%"
|+<ref group="Table">Recommended OID sub-branches for different artefacts</ref> ''Recommended OID sub-branches for different artefacts''
! Arc !! Description
|-
| .3 || organizational bodies and groups
|-
| .4 || identifier systems and namespaces
|-
| .5 || code systems
|-
| .7 || document artefacts
|-
| .9 || conformance profiles
|-
| .10 || templates
|-
| .11 || value sets
|-
| .19 || examples
|-
| .99 || experimental
|}

''Example: given that “your” root OID is 1.2.3.4.5, the first value set of your governance group is then to be 1.2.3.4.5.11.1, with .11 as the value set “branch” and the last .1 as the first artefact of that kind.''

In ART-DECOR a project typically is set into the .77 branch of a governance group. When setting up the project, the OID for that project also determines the artefact OIDs using throughout the ART-DECOR project. The following additional branches are used to distinguish between different OID types:

{| class="hl7table"
|+<ref group="Table">Recommended OID sub-branches for ART-DECOR projects</ref> ''Recommended OID sub-branches for different artefacts''
! Artefact code Description !! Recommended !! OID suffix
|-
| DS || dataset || .77.1
|-
| DE || dataset concept || .77.2
|-
| SC || scenario || .77.3
|-
| TR || transaction in scenario || .77.4
|-
| CS || code system || .77.5
|-
| IS || issue || .77.6
|-
| AC || actor in scenario || .77.7
|-
| CL || concept list in dataset || .77.8
|-
| EL || element in template || .77.9
|-
| TM || template || .77.10
|-
| VS || value set || .77.11
|-
| RL || rule for instances || .77.12
|-
| SX || test/example scenario || .77.18
|-
| EX || test/example instance || .77.19
|-
| QX || qualification test/example || .77.20
|-
| TX || test/example data element || .77.21
|-
| CM || community || .77.22
|-
| MP || concept map || .77.24
|}

In ART-DECOR a newly created project uses these OID branches automatically.

=== Instance identification ===

Instance identification is done with the id element of a class. Its type is II (instance identifier) and described in the data type section above. For example, a patient number can be represented as
* 2.16.578.1.34.1.5432.1, the root-OID of the issuing authority, for example a system/application in a hospital, and
* 67543242 as the ''@extension'', representing the patient number within the system defined by the ''@root'' attribute.

=== Coding scheme identification ===

Coding schemes have to be uniquely identified using OIDs as well. All coding tables used in this implementation guide show the corresponding OID that has to be specified in the ''@codeSystem'' attribute of coded elements. Both attributes ''@code'' and ''@codeSystem'' together allows a correct interpretation of concept and code.

=== List of identification schemes ===

The following are OIDs for commonly used identification schemes.

{| class="hl7table"
|+<ref group="Table">Commonly used identification scheme OIDs</ref> ''Commonly used identification scheme OIDs''
! OID !! Identification System Name !! Description !! Issuer
|-
| 1.2.276.0.76.4.8 || KV-Nummer || Krankenversichertennummer ||
|-
| 1.2.276.0.76.4.17 || BSNR || Betriebsstättennummer ||
|-
| 1.2.276.0.76.4.16 || LANR || lebenslange Arztnummer ||
|}

=== List of code systems ===

The following are OIDs for code systems.

{| class="hl7table"
|+<ref group="Table">Commonly used code system OIDs</ref> ''Commonly used code system OIDs''
! OID !! Code System Name !! Description !! Issuer
|-
| 2.16.840.1.113883.6.1 || LOINC || Logical Observation Identifiers Names and Codes (LOINC) || Regenstrief Institute
|-
| 2.16.840.1.113883.6.96 || SNOMED CT || Systemized Nomenclature in Medicine Reference Terminology (SNOMED CT) || SNOMED International
|-
| 1.0.3166.1.2 || ISO 3166-1 (second edition) || Country codes as per ISO 3166-1:2007 || ISO
|}

== Vocabulary ==

=== Code Systems ===

Within HL7, a ''Code System'' is defined as a collection of codes with associated designations and meanings. Examples of code systems include ICD-10, SNOMED CT, and LOINC.
To meet the requirements of a code system as defined by HL7, a given code must resolve to one and only one meaning within the code system. Given this definition, each code table in the HL7 Version 3 standard represents a different code system since codes are sometimes used in different tables to have different meanings.
For example, “M” in the administrative gender table (''AdministrativeGender'', OID 2.16.840.1.113883.5.1) means “male”, while “M” in the marital status table (''MaritalStatus'', OID 2.16.840.1.113883.5.2) means “married”.
In this specification, code system tables are not presented in detail.

=== Value Sets ===

A ''Value Set'' represents a uniquely identifiable set of valid concept representations, where any concept representation can be tested to determine whether or not it is a member of the value set.
Value set complexity may range from a simple flat list of concept codes drawn from a single code system, to an unbounded hierarchical set of possibly post-coordinated expressions drawn from multiple code systems.
Value sets exist to constrain the content for a coded element in an HL7 static model or data type property. Value sets cannot have null content and must contain at least one concept representation where any given concept is generally (but not required to be) represented by only a single code within the Value Set.

[[File:CDA_Core_Principles_Figure_3_ValueSet_Example.png|800px]]

<ref group="Figure">Example presentation of the value set “MaritalStatus”</ref> ''Example presentation of the value set “MaritalStatus”''

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that value set OIDs never appear in a CDA Release 2 document. They are used for constraint expressions, for example in implementation guides.
In order to send a specific code drawn from a value set, the corresponding code system has to be conveyed.
An example, in the implementation specification the constraint on the model element ''maritalStatusCode'' is expressed as “to be drawn from value set 2.16.840.1.113883.5.2 ''MaritalStatus''”.
To actually send a marital status of “M” (married) that is shown in the value set figure above, the corresponding HL7 CDA instance would say:
<syntaxhighlight lang="xml">
<maritalStatusCode code="M" codeSystem="2.16.840.1.113883.5.2"/>
</syntaxhighlight>
|}

In this specification, value set tables are not presented in detail.

==== Binding strength ====

There is an optional vocabulary strength for data types that support that feature (coded concepts). Examples include CD, CE, CV and CO. Values are required, extensible, preferred and example. Default is required.

Please note: the formerly supported values CNE (Coded No Extensibility) and CWE (Coded With Extensibility) in ART-DECOR are deprecated as of December 2017. Specification CNE is handled as required and CWE is handled as extensible.

{| class="hl7table"
|+<ref group="Table">Binding Strengths</ref> ''Binding Strengths''
! Strength !! Description
|-
|required||Required/CNE. Coded with no exceptions; this element SHALL be from the specified value set
|-
|extensible||Extensible/CWE. Coded with Exceptions; this element SHALL be from the specified value set if any of the codes within the value set can apply to the concept being communicated. If the value set does not cover the concept (based on human review), alternate codings (or, data type allowing, text) may be included instead.
|-
|preferred||Preferred. Instances are encouraged to draw from the specified codes for interoperability purposes but are not required to do so to be considered conformant.
|-
|example||Example. Instances are not expected or even encouraged to draw from the specified value set. The value set merely provides examples of the types of concepts intended to be included.
|}

Mismatches with required lead to validation errors (SHALL logic). Mismatches with extensible lead to validation warnings (SHOULD logic). Mismatches with preferred lead to validation information messages (MAY logic). Mismatches with example don't have any validation consequences.

== Appendix ==

=== References ===

<references/>

=== List of figures ===

<references group="Figure" />

=== List of tables ===

<references group="Table" />

HL7 CDA Core Principles

2019-06-14T20:02:24Z

Dammon:

== Introduction ==

This implementation guide specifies the ''Core Principles'' of using the ''Clinical Document Architecture'' <ref>Clinical Document Architecture Release 2: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=7</ref>.

=== Scope ===

This guide focuses on ''Data Types Release 1'' <ref>HL7 Data Types Release 1: http://www.hl7.org</ref>. Meanwhile an ISO specification ISO 21090 is out, also known as Data Type Release 2. The latter is subject to another implementation guide that will be published when ISO data types are used.

=== Focus of this document: HL7 Version 3 Data Types for CDA ===

The following chapters of this document will focus on the description of the data types and associated material. It will highlight the essentials in four chapters, all focusing on the Norwegian situation.
* '''Common aspects:''' explains common aspects of use of CDA and XML
* '''Data types:''' gives an overview and detailed specification of all data types used in CDA
* '''Identification schemes:''' explains major aspects of identification and the use in CDA
* '''Use of vocabulary:''' explains major aspects of vocabulary use in CDA.

=== Background ===

In many (European) countries, implementation guides for the use of data types in HL7 V3 are published. They take into account country specific constraints on the data types.

=== Legend of symbols ===

In this document several symbols are used.

{| class="hl7table" style="width:50%"
| [[File:Pfeil_rechts.png|50px]] || This is an important item
|-
| [[File:Issue.svg|50px]] || This is a known open issue
|-
| [[File:Faq.svg|50px]] || This is a frequently asked question (FAQ) with answer
|-
| [[File:Conformance.svg|50px]] || This is a constraint; in some situations also the rule identification is specified, e.g. dtr1-1-ANY, which links to the corresponding validation rule.
|}

=== Version history ===

{| class="hl7table" style="width:50%"
|+
! Version !! Date !! Description !! Author
|-
| 1.1 || 2019-04-24 || Refurbished guide based on earlier work || Kai U. Heitmann
|}

== Common aspects ==

=== Use of XML ===

HL7 Version 3 CDA uses the Extensible Markup Language (XML) as the exchange format. It is assumed that the reader is familiar with common XML aspects. However, some constraints are made regarding the use of CDA.

==== Character Set ====

{{ConstraintBox|
The character encoding of any CDA document shall be “UTF-8”.}}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="utf-8"?>
</syntaxhighlight>

=== CDA document structure ===

The XML namespace for CDA Release 2 documents is ''<nowiki>urn:hl7-org:v3</nowiki>''. This must be correctly mentioned in every XML instance.
CDA XML documents starts with the root element ''ClinicalDocument''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">


...

<component>
<structuredBody>
...
</structuredBody>
</component>

</ClinicalDocument>
</syntaxhighlight>

== Data types ==

=== Introduction ===

The following chapter describes the typical data types used in CDA implementation guides. For further information please refer to the HL7 V3 standard and its two parts concerning data types:
* Abstract Data type definition <ref>HL7 Version 3 Abstract Data type definition: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=264</ref>
* XML ITS for data types <ref>XML ITS for data types: https://www.hl7.org/documentcenter/public_temp_682D4D16-1C23-BA17-0C789BA52BEDB68E/wg/inm/datatypes-its-xml20050714.htm</ref>
Data types are properties of model class attributes and the basic building blocks of information in a CDA XML instance. For example, a model attribute named “time” has as its data type a time stamp “TS” (see Figure 1).

[[File:CDA_Core_Principles_Figure_1_CDA_Structure_Data_Types.png|700px]]

<ref group="Figure">CDA structure (left) and the data type specification (right)</ref> ''CDA structure (left) and the data type specification (right)''

=== XML representation of data types ===

Actual data is mostly carried in HL7 Version 3 by populating XML attributes and not as element content. Exceptions are names of persons and organizations as well as addresses.
The XML elements have names like the model attributes. For example, a model attribute “id” has a corresponding XML element named <id…>. The model determines the sequence of elements and their hierarchy. The data type itself determines the XML attributes within the start tag. The notation here is as follows:
{| class="hl7table"
|+
! Attribute !! DT !! Conf !! Description
|-
| (name of the model attribute or XML element) || Data type || Conformance, i.e. O, R, M || Textual description
|}

XML attributes (data type properties) are denoted as @attribute in order to distinguish their names from XML elements.
Example: in the example model above, the data type of the id attribute's is II (Instance Identifier). The corresponding XML attributes for that data type include @root and @extension.
<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id root="…" extension="..." />
</syntaxhighlight>
A description of the data types and their corresponding XML representation is contained in subsequent paragraphs of this guide.

==== Exceptions using XML element content ====
For most data types, the actual data is conveyed in XML attributes. However, there are some exceptions. For the data types binary (BIN), Encapsulated Data (ED), Entity Name (EN), Person Name (PN), Organization Name (ON), Trivial Name (TN), Address (AD) and character string data (ST), information is carried as element content.
Example: the components of an address <addr> are represented by sub elements with the data as element content (in the example shown in black).
<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr>
<streetAddressLine>Thormøhlens gate 12</streetAddressLine>
<postalCode>5006</postalCode>
<city>Bergen</city>
</addr>
</syntaxhighlight>

==== Combined data types ====
There are a number of socalled combined data types. For example, an interval with a lower and upper limit and a ratio that has a nominator and a denominator value.
In combined data types the substructure (e.g. <low> <high> in an interval) are represented as child elements of the relevant data type element.
<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110701"/>
<high value="20110729"/>
</effectiveTime>
</syntaxhighlight>

==== Conformance information ====
The conformance indicators distinguish kinds of conformance information described shortly here.
* '''O''': An optional item may be omitted if no data is present, i.e. no corresponding XML attribute or element is sent (marked as “O”)
* '''R''': For required items, lower cardinality is always zero or 1.
** Elements must be present and populated with data if present in the sending system. If no data is available (yet), a null flavor (see below) indicates and possibly classifies the missing information (marked as R).
** Attribute flagged as required must be present in the instance and populated.
* '''M''': For mandatory elements data must be sent and no missing values are allowed, i.e. if the sending system does not have information for mandatory elements the XML instance cannot be created and sent (marked as M).
* '''NP''': no data may be present at all (not permitted)
* '''C''': conditional conformance; typically a conformance table shows the circumstances (conditions) derived from information in the instance and the corresponding cardinalities and conformance statements.

=== Missing values (null flavor) ===
For every data type it is possible to specify a missing value including a kind of reason why data is missing. Instead of specifying any attribute of the corresponding element, a @nullFlavor attribute expresses the omission of data. Note that missing data is not allowed for mandatory elements (see above).
<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value nullFlavor="OTH"/>

<code nullFlavor="UNK"/>

<booleanInd nullFlavor="NI"/>

</syntaxhighlight>

The codes for the @nullFlavor attribute are drawn from the following hierarchical code system. It is a Coded Simple (CS), which means it has no code system (attribute @codeSystem) specified.
{| class="hl7table"
|+<ref group="Table">NullFlavor</ref> ''NullFlavor''
! Code
! width=15% | Print Name
! Definition / Description
|-
| NI || No Information || No information whatsoever can be inferred from this exceptional value. This is the most general exceptional value. It is also the default exceptional value.
|-
| OTH || other || The actual value is not an element in the value domain of a variable. (e.g., concept not provided by required code system).
|-
| NINF || negative infinity || Negative infinity of numbers.
|-
| PINF || positive infinity || Positive infinity of numbers.
|-
| UNK || unknown || A proper value is applicable, but not known.
|-
| ASKU || asked but unknown || Information was sought but not found (e.g., patient was asked but didn't know)
|-
| NAV || temporarily unavailable || Information is not available at this time but it is expected that it will be available later.
|-
| NASK || not asked || This information has not been sought (e.g., patient was not asked)
|-
| TRC || trace || The content is greater than zero, but too small to be quantified.
|-
| MSK || masked || There is information on this item available but it has not been provided by the sender due to security, privacy or other reasons. There may be an alternate mechanism for gaining access to this information.
Note: using this null flavour does provide information that may be a breach of confidentiality, even though no detail data is provided. Its primary purpose is for those circumstances where it is necessary to inform the receiver that the information does exist without providing any detail.
|-
| NA || not applicable || No proper value is applicable in this context (e.g., last menstrual period for a male).
|-
| NP || not present || Value is not present in a message. This is only defined in messages, never in application data! All values not present in the message must be replaced by the applicable default, or no-information (NI) as the default of all defaults.
|}

=== ANY as the generic data type ===

This abstract data type is the basis for all other data types. Not a single value within a CDA document has the effective data type ANY, but any data type within HL7v3 is a specialization of ANY. This also means that any other data type inherits all properties of ANY (see [[#Missing_values_.28null_flavor.29|“Missing values (null flavor)”]]).

The ANY type is occasionally found in HL7 models when it comes to clinical finding etc. where – at model time – the actual data type of the value is not known. At instantiation time however, the actual data type ''is'' known and ANY is always replaced by a particular data type in an instance.

One example is the observation value (child element value in an observation), where in the model the data type of value cannot be anticipated. When instantiation is taking place, the data type is specified by the XML instance attribute ''@xsi:type''. This information can be used by the receiver to validate and process the value.

Attributes of an element with this data type are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@nullFlavor''' || <center>CS</center> || <center>–</center> || Classification of the missing value, see [[#Missing_values_.28null_flavor.29|3.3 Missing values (null flavor)]].
|}

{| class="hl7table" style="width:100%"
| <center>[[File:Conformance.svg|50px]] dtr1-1-ANY</center> || If there is a ''nullFlavor'', there shall be no other attribute or element, unless it's ''nullFlavor="OTH"''. In that case ''@codeSystem'' or ''originalText'' (see “code” data types) may have a value.
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">

<value xsi:type="CE" code="N11.9" codeSystem="2.16.840.1.113883.6.3"/>


<value xsi:type="PQ" value="12" unit="mL"/>


<value xsi:type="ED">this is text</value>
</syntaxhighlight>

=== Boolean (BL) ===

Elements of this data type refer to Boolean logic and have an attribute @value.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>BL</center> || <center>–</center> || Valued as “true” or “false”
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<negationInd value="false"/>

<deceasedInd value="true"/>

</syntaxhighlight>

In some situations, the BL data does not apply to an XML element, but an attribute. In that case, the attribute carries the Boolean value directly.
<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<support contextConductionInd ="false">
...
</support>
</syntaxhighlight>

=== Instance Identifier (II) ===

This data type identifies instances of classes like observations or entities (persons, organizations). Attributes are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@extension''' || <center>ST</center> || <center>O</center> || Identification
|-
| '''@root''' || <center>OID</center> || <center>R</center> || Source of identification
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id extension="13234453645" root="2.16.840.1.113883.2.6.15.3.427.1"/>
</syntaxhighlight>

The @root attribute is of type OID (object identifier), a unique identifier of the issuing authority or system. For example, a patient with a patient number 13234453645 created by a specific healthcare provider organization is uniquely identified by the number itself in @extension and the OID of the organization or the sending system, in the example 2.16.840.1.113883.2.6.15.3.427.1 in @root.
In some cases, a single OID identifies an object uniquely. In that situation, only @root is populated and @extension is omitted.

{| class="hl7table" style="width:100%"
| [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Encapsulated Data (ED) ===

Elements of this data type carry multimedia content. The actual multimedia content is represented as element content. There are two situations for the use of ED:
* Inline: The full data is transmitted in the type. This form is mainly used for text.
* By reference: a thumbnail is provided which links to the full data by reference.
In an instance, the data type is normally determined by an xsi:type specification and some attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@mediaType''' || <center>CS</center> || <center>O</center> || MIME media type classification. At time of writing this specification, the following MIME types are allowed:
* text/plain (plain text)
* text/html (text with html markup)
* image/jpeg (JPEG image)
* application/pdf (a PDF, portable document format)
* application/hl7-sda+xml (CDA documents).
|-
| '''@representation''' || <center>CS</center> || <center>O</center> || Representation of the multimedia content. At time of writing this specification, the following representations are allowed:
* TXT (text, this is the default)
* B64 base 64 encoded data, for example for embedded CDA documents).
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<text xsi:type="ED" mediaType="text/plain">
Patient treated sucessfully
</text>

<text mediaType="application/hl7-sda+xml" representation="B64">PD94bWw..etc..==</text>

</syntaxhighlight>

To include referenced data the two sub elements thumbnail and reference are used.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''reference''' || <center>TEL</center> || <center>0..*</center> || <center>O</center> || Link (URI) to full data
|-
| '''thumbnail''' || <center>ED</center> || <center>0..*</center> || <center>O</center> || Thumbnail of referenced data
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value xsi:type="ED" mediaType="image/png" representation="B64">
<reference value="http://radiology.bergen.no/xrays/128s.png"/>
<thumbnail mediaType="image/jpeg" representation="B64"> MNY...83== </thumbnail>
</value>
</syntaxhighlight>

=== Strings (ST) ===

This data type is a specialization of the ED type where @mediaType is fixed “text/plain” and @representation is fixed “TXT”. It allows conveying a character string as element content. This data type is used in other data types it like the @extension in instance identifiers, or address and person name data type components.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<lotNumber> 143GT6DT </lotNumber>
</syntaxhighlight>

=== Concept Descriptor (CD) ===

This data type specifies a concept by means of a code and its code system (except for situations where no code is available). A couple of specializations of data type CD exist, which differ in the main characteristics (properties) of the data type that may or may not be supported.

{| class="hl7table" style="width:50%"
|+ Table 1: Properties of data types used for codes
! <div style="text-align: right">DataType</div> !! CD !! CE !! CV !! CO !! CS
|-
! <div style="text-align: left">Property</div> !! !! !! !! !!
|-
| '''@code''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||<center>X</center>
|-
| '''@codeSystem''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''@codeSystemVersion''' || <center>X</center> || <center>X</center> || <center>X</center>|| <center>X</center> ||
|-
| '''@displayName''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''originalText''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''translation''' || <center>X</center> || <center>X</center> || || ||
|-
| '''qualifier''' || <center>X</center> || || || ||
|}

Because the CE variant is most used in practice, the general explanation of the proper-ties will be given with de description of CE (see below).
The only attribute that is unique to CD is briefly explained here.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@qualifier''' || <center>CR</center> || <center>O</center> || An additional qualifier for the code.
|}

Complex terminologies like SNOMED CT can be used only using data type CD.

=== Coded with Equivalents (CE) ===

With elements of this data type, a concept by means of a code and its coding system (except for situations where no code is available) can be specified. It optionally contains one or more equivalents using other code systems.
It may contain the following attributes:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@code''' || <center>ST</center> || <center>R</center> || The actual code
|-
| '''@codeSystem''' || <center>OID</center> || <center>R</center> || required to identify the code system were the code is drawn from. This is an OID (object identifier, see [[#Object_Identifiers_.28OIDs.29|Object Identifiers at 4.1]])
|-
| '''@displayName''' || <center>ST</center> || <center>O</center> || Optional textual representation of code. A display name may be specified representing the plain text of the code. The information of this attribute may not be used by the receiving system for interpretation, but only for display purposes. The display name may never be transmitted without a code and must have the same meaning as the code.
|-
| '''@codeSystemName''' || <center>ST</center> || <center>O</center> || A textual representation of the name of the code system
|-
| '''@codeSystemVersion''' || <center>ST</center> || <center>O</center> || A textual representation of the version of the code system
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"/>

<code code="AU" codeSystem="2.16.840.1.113883.5.33"/>

<storageCode code="AC" codeSystem="2.16.840.1.113883.5.34" displayName="active"/>

<code code="A45.0" displayName="Somatisierungsstörung" codeSystem="1.2.276.0.76.5.409" codeSystemName="ICD-10 GM 2012"/>
</syntaxhighlight>

There are some child elements of codes that can be used to express what the “original text” was that was used for the coding or to indicate that there are “translations” to other code systems than the primary code.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''originalText''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Textual representation of the concept, actually a description which was used to create the actual code
|}

No semantics may be assumed other than showing the ''@displayName'' to a user to clarify the code. A display name cannot occur without its code and must carry the same meaning.

In case no code is known, it is allowed to specify a ''@nullFlavor'' for the code element and to give information about the (not yet coded) concept in original text. However, this should be an exception.

If other codes than the primary code need to be conveyed adding a translation child element can be used.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<originalText>minor aphthous stomatitis</originalText>
</code>
</syntaxhighlight>

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''translation''' || <center>CD</center> || <center>0..*</center> || <center>O</center> || Alternative code(s)
|}

A ''translation'' element is also of type CD and shall have a code and a code system identified. It shall point to the same concept as the primary code. It is allowed that a translation conveys less conceptual details than the original code.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<translation code="528.2" codeSystem="2.16.840.1.113883.6.2" codeSystemName="ICD9" displayName="Oral aphthae"/>
</code>
</syntaxhighlight>

=== Coded Value (CV) ===

This is actually a specialization of CE (see above), with the exception that neither ''originalText'' nor ''translation'' child element are allowed.

=== Coded Simple Value (CS) ===

This is actually a specialization of CE (see above), with no code system attribute and no original text or translation child element allowed. It specifies a concept by means of a code from a ''predefined'' code system (table) where the code is drawn from. This data type is usually applied in the context of fixed predefined HL7 tables.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<statusCode code="completed"/>
</syntaxhighlight>

In this example ''statusCode'' is bound in the underlying model to the specific code system ''ActStatus''. Because it is predefined by means of the vocabulary binding, ''@codeSystem'' is omitted.

{| class="hl7table" style="width:100%"
| [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Telecommunication Address (TEL) ===

Elements of this type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>ST</center> || <center>R</center> || carries strings that represent telecommunication contact information
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

The actual data is preceded by the scheme (refer to Internet Standard “RFC 1738 Uniform Resource Locators (URL)” <ref>RFC 1738 Uniform Resource Locators (URL): http://www.ietf.org/rfc/rfc1738.txt</ref>.

Examples:
* telephone (tel:),
* fax (fax:),
* email (mailto:).

It must follow the rules defined in Internet “RFC 2806 URLs for Telephone Calls” <ref>RFC 2806 URLs for Telephone Calls: http://www.ietf.org/rfc/rfc2806.txt</ref>.

The following codes will be used in the “use” attribute:
* H – Home
* WP – Work
* MC can be used (in addition to H or WP) to denote that this is a mobile phone.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257" />

<telecom use="H" value="tel:55354257" />

<telecom use="H" value="fax:56542558" />

<telecom value="tel:+41.34.21.4765342"/>

<telecom value="mailto:opr@opr-sem.no"/>

<telecom use="WP MC" value="tel:97555786" />
</syntaxhighlight>

It is possible to express the useable period of a telecommunication contact. A child element ''useablePeriod'' is used as a time interval to indicate this period.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''useablePeriod''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257">
<useablePeriod>
<high value="20111201"/>
</useablePeriod>
</telecom>
</syntaxhighlight>

=== Postal Address (AD) ===

Elements of this data type have a substructure in order to represent a structured address specification. In this implementation guide only a selection of all possible child elements is allowed, the original HL7 specification is richer.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''streetAddressLine''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Street address, includes street name and house number
|-
| '''city''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || City
|-
| '''postalCode''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Postal code
|-
| '''country''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Country
|-
|}

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that the sequence of the sub elements is country specific, i.e. it has to follow “common” rules how to write an address. For example, an UK address and a German address have different sequences of address representation.
|}

A ''@use'' attribute can also be specified.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="WP">
<streetAddressLine>Anna-Louisa-Karsch-Str. 2</streetAddressLine>
<postalCode>10178</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="H WP">
<streetAddressLine>Tatungasse 34</streetAddressLine>
<postalCode>10825</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

Also, a country may be specified using the element ''country''.

=== Person Name (PN) ===

Elements of this data type do also have a substructure to represent the parts of a person name, like family or given name and prefixes.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>
<given>Franz</given>
<given>Ingrun</given>
<family>Nordmann</family>
</name>
</syntaxhighlight>

Previous or birth or maiden names are supported using the ''validTime'' element. ''validTime'' (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]]) specifies the validity range of the name.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">

<name>
<given>Jan</given>
<given>Olaf</given>
<family>Hendrikson</family>
<validTime>
<high value="20000101"/>
</validTime>
</name>
</syntaxhighlight>

Note that the name attribute is repeating, i.e. multiple (types of) names could be sent. It is up to the receiver (based on the value of the ''@use'' attribute, and ''validTime'') to decide what name it wants to use or import in its database.

=== Organisation Name (ON) ===

Elements of this data type represent a name of an organization.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name> Charité Berlin </name>
</syntaxhighlight>

The optional ''validTime'' element (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]] may be used to specify the validity range of the name of the organization.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name of the organization
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>The old hospital
<validTime>
<high value="20111231235959"/>
</validTime>
</name>
</syntaxhighlight>

Please note that the use of ''validTime'' yields XML mixed content which should be avoid-ed if possible.

=== Integer Number (INT) ===

Elements of this data type are used to specify integer numbers and have one attribute.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>int</center> || <center>R</center> || Integer value
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<sequenceNumber value="24"/>
</syntaxhighlight>

=== Physical Quantities (PQ) ===

Elements of this data type are physical quantities, i.e. a measurable quantity (or countable) value from the physical world. This is different from just a “number”, because there is a (natural) unit specified in which the measurable quantity is expressed.
Examples:
* an amount of blood 20 ml (sample volume)
* a cut with a length of 10 cm (result observation)
* a dose of 200 milligrams per administration (dosing)
* delivery of 60 pieces of a tablet (amount supplied).
Elements of this data type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>real</center> || <center>R</center> || value of the measurement
|-
| '''@unit''' || <center>CS</center> || <center>R</center> || unit of measurement
|}

In the unit of measurement unit is expressed following the ''Unified Code for Units of Measure'' (UCUM) specification. This specification is a collection of atomic units, prefixes and a corresponding grammar for valid combinations to build all-natural units of measurement. For a complete description of possible units, see the ''Unified Code for Units of Measure'' <ref>Unified Code for Units of Measure: http://unitsofmeasure.org/</ref> specification.
If a value is not countable or if measurable, for example expressed in milligrams or liters, then this unit is a valid UCUM unit like “mg” or “L”. If a value is countable, for example the number of tablets, then this attribute contains “1”.
In HL7 it is required that all PQ data type units are valid UCUM units.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<value value="165" unit="cm"/>

<value value="81.1" unit="kg"/>

<value value="120" unit="mm[Hg]"/>

<value value="5" unit="1"/>
</syntaxhighlight>

=== Point in Time (TS) ===

Elements of this data type have the attribute

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>TS</center> || <center>R</center> || Point in time
|}

and specify points in time in the format YYYYMMDDhhmmss±ZZZZ, where
* YYYY is the four-digit year,
* MM the two-digit month,
* DD the two-digit day,
* hh the two-digit hour,
* mm the two-digits minute and
* ss the two-digit second.
Optional a time zone ZZZZ, the four-digit time alignment with a preceding “-” or a “+” can be specified. If time zone is omitted, local time is assumed.
The point in time may be right truncated in respect to the precision of the information.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<effectiveTime value="20140412"/>

<effectiveTime value="201409091245"/>

<effectiveTime value="1996"/>

<birthTime value="19540714"/>

<effectiveTime value="20140412+0100"/>
</syntaxhighlight>

=== Intervals (IVL) ===

Intervals are defined only for data types with an ordinal or interval scale type. There are several possibilities to determine an interval (see Figure 2), for example to specify

* a lower <low> and an upper boundary <high> (a),
* a lower <low> boundary and width <width> (b)
* an upper boundary and width <width> (c) or
* the middle of the interval <nowiki><center></nowiki> and a width <width> (d).

[[File:CDA_Core_Principles_Figure_2_Determining_Intervals.png|700px]]

<ref group="Figure">Several possibilities to determine closed intervals</ref> ''Several possibilities to determine closed intervals''

{{ConstraintBox|
To indicate an interval, only the following combinations are permitted.
(1) A lower and an upper boundary may not be identical, and their accuracy has to be equal.

Correct examples:

{{BeginGreenBox|}}
Interval from 5 to 6
Interval from 20110607 until 20110612
{{EndGreenBox}}

Incorrect examples:

{{BeginRedBox|}}
Interval from 5 to 6.0
Interval from 20110101 to 2011
{{EndRedBox|}}

(2) A lower boundary and a width

(3) A lower limit boundary

(4) A upper limit boundary

(5) Only the middle of the interval

(6) Only the width of an interval}}

Accordingly, four child elements are available.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Lower boundary
|-
| '''high''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Upper boundary
|-
| '''center''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Where ''(T)'' is defined in this specification as one of the data types “TS” or “PQ”.

=== Interval of time (IVL_TS) ===

Elements of this data type represent time intervals. There are four possible child elements.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Lower boundary (start date/time)
|-
| '''high''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Upper boundary (end date/time)
|-
| '''center''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Normally, a lower and an upper boundary is given, both are points in time. Also, it is possible to specify open intervals like “since June 14, 1999” (left boundary given only) or “until September 24, 2006” (right boundary given).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110507"/>
<high value="20110909"/>
</effectiveTime>

<effectiveTime>
<low value="20110507"/>
</effectiveTime>

<value>
<low value="20110101"/>
<width value="120" unit="d"/>
</value>

<value>
<center value="20110101"/>
</value>
</syntaxhighlight>

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|It must be noted that intervals of time stamps in HL7 are equally treated as other interval types (e.g. integers). The statement, one may take 1–3 tablets (interval of integers), for example, says that you are allowed to take no more than three tablets, not 3½ or 3.5 tablets. On the other hand, when treat the words “until 12 June 2011” regarding the upper interval limit differently, particularly we assume that the entire day 12 June is still in-cluded in this time interval.
Thus, in human perception time intervals are handled differently com-pared to such as number intervals. This is a situation may lead to inconsist-encies in standardized communication. As a conclusion, an upper limit “12 June 2011” means that only the very first moment of the 12 June is included in the interval, but not, for example, the 12 June 13:00 hours.
Interpretation does not depend on the accuracy of the time:
* “after 2004” means “from January 1, 2005 00:00:00.000”,
* “after 20041201” means “from 2 December 2004 00:00:00.000 hours”,
* and “after 200412011200” means “from 1 December 2004 12:01:00.000”.

As a result, you have to carefully consider the specification and implemen-tation of time intervals upper boundaries. In order to prevent mis-understandings intervals are always specified with the date and time for an upper limit that would cover the whole day. Accordingly, “201106122359” means 12 June 2011 throughout the day.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="201106122359"/>
</effectiveTime>
</syntaxhighlight>

Because of the equal treatment of time intervals this is applied also to the lower limit boundaries of time intervals as “0000”. This means for example that “since 9 June 2011” is expressed as “201106090000”.
|}

The <width> element is of data type PQ (physical quantity). The value obviously shall relate to a period of time and it is required to include a “time” unit. These are the units “us” (microseconds), “ms” (milliseconds), “s” (seconds), “min” (minute), “h” (hours), “d” (day), “wk” (week), “mo” (month) and “a” (year).

{{ConstraintBox|
For interval of time stamps the @unit of a ''low'' or ''high'' child element shall use units
* us (microseconds),
* ms (milliseconds),
* s (seconds),
* min (minute),
* h (hours),
* d (day),
* wk (week),
* mo (month) or
* a (year).
}}

=== Interval of physical quantities (IVL_PQ) ===

Elements of this data type are used to indicate intervals of physical quantities (see also [[#Physical Quantities (PQ)|3.18 Physical Quantities (PQ)]]). In general, an upper and a lower boundary is specified. It is also possible to use ''center'' instead of ''low'' and ''high''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low || <center>TS</center> || <center>0..1</center> || <center>C</center> || the lower limit of the interval (i.e. the minimum amount).
|-
| '''high || <center>TS</center> || <center>0..1</center> || <center>C</center> || the upper limit of the interval (i.e. the maximum amount).
|-
| '''center || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of the interval
|}

The ''center'' child element is used when there is no interval, but an exact value. Alternative would be to demote IVL_PQ to data type PQ and populate the element’s ''@value'' attribute, but this is more difficult to process in XML. That is why the use of the ''center'' child element is deprecated.

{| class="hl7table" style="width:100%"
| [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<referenceRange>
<low value="7.5" unit="mmol/l"/>
<high value="10" unit="mmol/l"/>
</referenceRange>

<doseQuantity>
<center value="9" unit="1"/>
</doseQuantity>
</syntaxhighlight>

=== Ratio of quantities (RTO_QTY_QTY) ===

Elements of this data type specify ratios and have two child elements, a numerator and a denominator. The underlying QTY (Quantity) data type is an abstract data type and in a XML instance it has to be replaced by a specific data type using the ''@xsi:type'' instruction (see below).

In this specification only “PQ” or “INT” are allowed for the demotion of both ''numerator'' and ''denominator''. The relevant child elements are:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''numerator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the numerator of the ratio
|-
| '''denominator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the denominator of the ratio
|}

If a model attribute already is a RTO_QTY_QTY, you need to specify (demote) the OTY abstract data type for both ''numerator'' and ''denominator'' by using an ''@xsi:type'' instruction.
In some cases where the model attribute is of type “ANY”, also the root element shall carry an ''@xsi:type'' RTO_QTY_QTY instruction.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<maxDoseQuantity>
<numerator xsi:type="PQ" value="6"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="400" unit="mg"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="5"/>
<denominator xsi:type="PQ" value="1" unit="h"/>
</maxDoseQuantity>

<value xsi:type="RTO_QTY_QTY">
<numerator xsi:type="INT" value="1"/>
<denominator xsi:type="INT" value="10000"/>
</value>
</syntaxhighlight>

== Identification mechanisms ==

=== Object Identifiers (OIDs) ===

Standardized exchange of information using messages or documents also deals with unique identifications of objects and concepts, especially in environments where sender and receiver do not “know” each other necessarily.

It is important to understand the difference between identification of instances (ids) and code concepts (classifications). Within the context of HL7 interactions OIDs are quite often used.
An id points to a specific instance of an object or identification scheme (a particular methodology for the identification of a class of objects), for example a specific person as the patient or a physician, a specific lab observation or an X-ray photo.

In contrast to instance identifiers, a classification identifies a specific concept. The type of patient (inpatient, outpatient), the type of doctor (an anesthesiologist), the codes for gender or a lab observation (blood cell count) may serve as examples.

OIDs (object identifiers) are worldwide unique identifiers for objects. They are used in HL7 to specify identifications and classifications. An object in this sense is persistent, well-defined information, definitions or specifications and is represented with ids or codes.

Commonly used OIDs (i.e. used for a purpose that is wider in scope than the regional healthcare organization; used in communications between healthcare regions) can be found in OIDs registries such as

* [http://www.oid-info.com www.oid-info.com],
* [http://www.hl7.org www.hl7.org],
* [http://www.hl7.org.uk/version3group/oids.asp HL7 OID registry in the UK],
* [https://www.dimdi.de/dynamic/de/klassifikationen/weitere-klassifikationen-und-standards/oid/ OID registry Germany].

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|All OIDs with an element of 999 or 9999 are for documentation purposes only. They will be replaced by permanent OIDs once these have been as-signed/found/applied for.
|}

OID (Object Identifiers) are unique identifiers for any kind of objects. They are defined in Rec. ITU-T X.660 | ISO/IEC 9834-1. This identification system for objects and concepts makes reliable electronic information exchange possible. Administration and Registration is regulated by a set of rules, described in the corresponding chapter of this document.

Every artefact in ART-DECOR has an Object Identifier (OID). There are recommendations for the management and the exchange of Object Identifiers, partially defined in ISO TS 13582 <ref>ISO TS 13582: https://www.iso.org/standard/69652.html</ref>.

''HL7 International'' has created a type ontology for the OIDs in the HL7 registry to make it easier for the user community to search for OIDs they may be looking for and can be found at hl7.org.

From a policy perspective it is common practice in several healthcare related OID registries (HL7 International at http://www.hl7.org, OID Registry Germany at http://www.dimdi.de, OID registry Switzerland at http://oid.refdata.ch, and OID registry Austria at https://www.gesundheit.gv.at/OID_Frontend) to distinguish at least between the following types of OIDs:

{| class="hl7table" style="width:60%"
|+<ref group="Table">Recommended OID sub-branches for different artefacts</ref> ''Recommended OID sub-branches for different artefacts''
! Arc !! Description
|-
| .3 || organizational bodies and groups
|-
| .4 || identifier systems and namespaces
|-
| .5 || code systems
|-
| .7 || document artefacts
|-
| .9 || conformance profiles
|-
| .10 || templates
|-
| .11 || value sets
|-
| .19 || examples
|-
| .99 || experimental
|}

''Example: given that “your” root OID is 1.2.3.4.5, the first value set of your governance group is then to be 1.2.3.4.5.11.1, with .11 as the value set “branch” and the last .1 as the first artefact of that kind.''

In ART-DECOR a project typically is set into the .77 branch of a governance group. When setting up the project, the OID for that project also determines the artefact OIDs using throughout the ART-DECOR project. The following additional branches are used to distinguish between different OID types:

{| class="hl7table"
|+<ref group="Table">Recommended OID sub-branches for ART-DECOR projects</ref> ''Recommended OID sub-branches for different artefacts''
! Artefact code Description !! Recommended !! OID suffix
|-
| DS || dataset || .77.1
|-
| DE || dataset concept || .77.2
|-
| SC || scenario || .77.3
|-
| TR || transaction in scenario || .77.4
|-
| CS || code system || .77.5
|-
| IS || issue || .77.6
|-
| AC || actor in scenario || .77.7
|-
| CL || concept list in dataset || .77.8
|-
| EL || element in template || .77.9
|-
| TM || template || .77.10
|-
| VS || value set || .77.11
|-
| RL || rule for instances || .77.12
|-
| SX || test/example scenario || .77.18
|-
| EX || test/example instance || .77.19
|-
| QX || qualification test/example || .77.20
|-
| TX || test/example data element || .77.21
|-
| CM || community || .77.22
|-
| MP || concept map || .77.24
|}

In ART-DECOR a newly created project uses these OID branches automatically.

=== Instance identification ===

Instance identification is done with the id element of a class. Its type is II (instance identifier) and described in the data type section above. For example, a patient number can be represented as
* 2.16.578.1.34.1.5432.1, the root-OID of the issuing authority, for example a system/application in a hospital, and
* 67543242 as the ''@extension'', representing the patient number within the system defined by the ''@root'' attribute.

=== Coding scheme identification ===

Coding schemes have to be uniquely identified using OIDs as well. All coding tables used in this implementation guide show the corresponding OID that has to be specified in the ''@codeSystem'' attribute of coded elements. Both attributes ''@code'' and ''@codeSystem'' together allows a correct interpretation of concept and code.

=== List of identification schemes ===

The following are OIDs for commonly used identification schemes.

{| class="hl7table"
|+<ref group="Table">Commonly used identification scheme OIDs</ref> ''Commonly used identification scheme OIDs''
! OID !! Identification System Name !! Description !! Issuer
|-
| 1.2.276.0.76.4.8 || KV-Nummer || Krankenversichertennummer ||
|-
| 1.2.276.0.76.4.17 || BSNR || Betriebsstättennummer ||
|-
| 1.2.276.0.76.4.16 || LANR || lebenslange Arztnummer ||
|}

=== List of code systems ===

The following are OIDs for code systems.

{| class="hl7table"
|+<ref group="Table">Commonly used code system OIDs</ref> ''Commonly used code system OIDs''
! OID !! Code System Name !! Description !! Issuer
|-
| 2.16.840.1.113883.6.1 || LOINC || Logical Observation Identifiers Names and Codes (LOINC) || Regenstrief Institute
|-
| 2.16.840.1.113883.6.96 || SNOMED CT || Systemized Nomenclature in Medicine Reference Terminology (SNOMED CT) || SNOMED International
|-
| 1.0.3166.1.2 || ISO 3166-1 (second edition) || Country codes as per ISO 3166-1:2007 || ISO
|}

== Vocabulary ==

=== Code Systems ===

Within HL7, a ''Code System'' is defined as a collection of codes with associated designations and meanings. Examples of code systems include ICD-10, SNOMED CT, and LOINC.
To meet the requirements of a code system as defined by HL7, a given code must resolve to one and only one meaning within the code system. Given this definition, each code table in the HL7 Version 3 standard represents a different code system since codes are sometimes used in different tables to have different meanings.
For example, “M” in the administrative gender table (''AdministrativeGender'', OID 2.16.840.1.113883.5.1) means “male”, while “M” in the marital status table (''MaritalStatus'', OID 2.16.840.1.113883.5.2) means “married”.
In this specification, code system tables are not presented in detail.

=== Value Sets ===

A ''Value Set'' represents a uniquely identifiable set of valid concept representations, where any concept representation can be tested to determine whether or not it is a member of the value set.
Value set complexity may range from a simple flat list of concept codes drawn from a single code system, to an unbounded hierarchical set of possibly post-coordinated expressions drawn from multiple code systems.
Value sets exist to constrain the content for a coded element in an HL7 static model or data type property. Value sets cannot have null content and must contain at least one concept representation where any given concept is generally (but not required to be) represented by only a single code within the Value Set.

[[File:CDA_Core_Principles_Figure_3_ValueSet_Example.png|800px]]

<ref group="Figure">Example presentation of the value set “MaritalStatus”</ref> ''Example presentation of the value set “MaritalStatus”''

{| class="hl7table" style="width:100%"
| [[File:Pfeil_rechts.png|50px]]
|Please note that value set OIDs never appear in a CDA Release 2 document. They are used for constraint expressions, for example in implementation guides.
In order to send a specific code drawn from a value set, the corresponding code system has to be conveyed.
An example, in the implementation specification the constraint on the model element ''maritalStatusCode'' is expressed as “to be drawn from value set 2.16.840.1.113883.5.2 ''MaritalStatus''”.
To actually send a marital status of “M” (married) that is shown in the value set figure above, the corresponding HL7 CDA instance would say:
<syntaxhighlight lang="xml">
<maritalStatusCode code="M" codeSystem="2.16.840.1.113883.5.2"/>
</syntaxhighlight>
|}

In this specification, value set tables are not presented in detail.

==== Binding strength ====

There is an optional vocabulary strength for data types that support that feature (coded concepts). Examples include CD, CE, CV and CO. Values are required, extensible, preferred and example. Default is required.

Please note: the formerly supported values CNE (Coded No Extensibility) and CWE (Coded With Extensibility) in ART-DECOR are deprecated as of December 2017. Specification CNE is handled as required and CWE is handled as extensible.

{| class="hl7table"
|+<ref group="Table">Binding Strengths</ref> ''Binding Strengths''
! Strength !! Description
|-
|required||Required/CNE. Coded with no exceptions; this element SHALL be from the specified value set
|-
|extensible||Extensible/CWE. Coded with Exceptions; this element SHALL be from the specified value set if any of the codes within the value set can apply to the concept being communicated. If the value set does not cover the concept (based on human review), alternate codings (or, data type allowing, text) may be included instead.
|-
|preferred||Preferred. Instances are encouraged to draw from the specified codes for interoperability purposes but are not required to do so to be considered conformant.
|-
|example||Example. Instances are not expected or even encouraged to draw from the specified value set. The value set merely provides examples of the types of concepts intended to be included.
|}

Mismatches with required lead to validation errors (SHALL logic). Mismatches with extensible lead to validation warnings (SHOULD logic). Mismatches with preferred lead to validation information messages (MAY logic). Mismatches with example don't have any validation consequences.

== Appendix ==

=== References ===

<references/>

=== List of figures ===

<references group="Figure" />

=== List of tables ===

<references group="Table" />

HL7 CDA Core Principles

2019-06-14T19:59:00Z

Dammon: /* Version history */

== Introduction ==

This implementation guide specifies the ''Core Principles'' of using the ''Clinical Document Architecture'' <ref>Clinical Document Architecture Release 2: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=7</ref>.

=== Scope ===

This guide focuses on ''Data Types Release 1'' <ref>HL7 Data Types Release 1: http://www.hl7.org</ref>. Meanwhile an ISO specification ISO 21090 is out, also known as Data Type Release 2. The latter is subject to another implementation guide that will be published when ISO data types are used.

=== Focus of this document: HL7 Version 3 Data Types for CDA ===

The following chapters of this document will focus on the description of the data types and associated material. It will highlight the essentials in four chapters, all focusing on the Norwegian situation.
* '''Common aspects:''' explains common aspects of use of CDA and XML
* '''Data types:''' gives an overview and detailed specification of all data types used in CDA
* '''Identification schemes:''' explains major aspects of identification and the use in CDA
* '''Use of vocabulary:''' explains major aspects of vocabulary use in CDA.

=== Background ===

In many (European) countries, implementation guides for the use of data types in HL7 V3 are published. They take into account country specific constraints on the data types.

=== Legend of symbols ===

In this document several symbols are used.

{| class="hl7table" style="width:50%"
| [[File:Pfeil_rechts.png|50px]] || This is an important item
|-
| [[File:Issue.svg|50px]] || This is a known open issue
|-
| [[File:Faq.svg|50px]] || This is a frequently asked question (FAQ) with answer
|-
| [[File:Conformance.svg|50px]] || This is a constraint; in some situations also the rule identification is specified, e.g. dtr1-1-ANY, which links to the corresponding validation rule.
|}

=== Version history ===

{| class="hl7table" style="width:50%"
|+
! Version !! Date !! Description !! Author
|-
| 1.1 || 2019-04-24 || Refurbished guide based on earlier work || Kai U. Heitmann
|}

== Common aspects ==

=== Use of XML ===

HL7 Version 3 CDA uses the Extensible Markup Language (XML) as the exchange format. It is assumed that the reader is familiar with common XML aspects. However, some constraints are made regarding the use of CDA.

==== Character Set ====

{{ConstraintBox|
The character encoding of any CDA document shall be “UTF-8”.}}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="utf-8"?>
</syntaxhighlight>

=== CDA document structure ===

The XML namespace for CDA Release 2 documents is ''<nowiki>urn:hl7-org:v3</nowiki>''. This must be correctly mentioned in every XML instance.
CDA XML documents starts with the root element ''ClinicalDocument''.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">


...

<component>
<structuredBody>
...
</structuredBody>
</component>

</ClinicalDocument>
</syntaxhighlight>

== Data types ==

=== Introduction ===

The following chapter describes the typical data types used in CDA implementation guides. For further information please refer to the HL7 V3 standard and its two parts concerning data types:
* Abstract Data type definition <ref>HL7 Version 3 Abstract Data type definition: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=264</ref>
* XML ITS for data types <ref>XML ITS for data types: https://www.hl7.org/documentcenter/public_temp_682D4D16-1C23-BA17-0C789BA52BEDB68E/wg/inm/datatypes-its-xml20050714.htm</ref>
Data types are properties of model class attributes and the basic building blocks of information in a CDA XML instance. For example, a model attribute named “time” has as its data type a time stamp “TS” (see Figure 1).

[[File:CDA_Core_Principles_Figure_1_CDA_Structure_Data_Types.png|700px]]

<ref group="Figure">CDA structure (left) and the data type specification (right)</ref> ''CDA structure (left) and the data type specification (right)''

=== XML representation of data types ===

Actual data is mostly carried in HL7 Version 3 by populating XML attributes and not as element content. Exceptions are names of persons and organizations as well as addresses.
The XML elements have names like the model attributes. For example, a model attribute “id” has a corresponding XML element named <id…>. The model determines the sequence of elements and their hierarchy. The data type itself determines the XML attributes within the start tag. The notation here is as follows:
{| class="hl7table"
|+
! Attribute !! DT !! Conf !! Description
|-
| (name of the model attribute or XML element) || Data type || Conformance, i.e. O, R, M || Textual description
|}

XML attributes (data type properties) are denoted as @attribute in order to distinguish their names from XML elements.
Example: in the example model above, the data type of the id attribute's is II (Instance Identifier). The corresponding XML attributes for that data type include @root and @extension.
<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id root="…" extension="..." />
</syntaxhighlight>
A description of the data types and their corresponding XML representation is contained in subsequent paragraphs of this guide.

==== Exceptions using XML element content ====
For most data types, the actual data is conveyed in XML attributes. However, there are some exceptions. For the data types binary (BIN), Encapsulated Data (ED), Entity Name (EN), Person Name (PN), Organization Name (ON), Trivial Name (TN), Address (AD) and character string data (ST), information is carried as element content.
Example: the components of an address <addr> are represented by sub elements with the data as element content (in the example shown in black).
<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr>
<streetAddressLine>Thormøhlens gate 12</streetAddressLine>
<postalCode>5006</postalCode>
<city>Bergen</city>
</addr>
</syntaxhighlight>

==== Combined data types ====
There are a number of socalled combined data types. For example, an interval with a lower and upper limit and a ratio that has a nominator and a denominator value.
In combined data types the substructure (e.g. <low> <high> in an interval) are represented as child elements of the relevant data type element.
<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110701"/>
<high value="20110729"/>
</effectiveTime>
</syntaxhighlight>

==== Conformance information ====
The conformance indicators distinguish kinds of conformance information described shortly here.
* '''O''': An optional item may be omitted if no data is present, i.e. no corresponding XML attribute or element is sent (marked as “O”)
* '''R''': For required items, lower cardinality is always zero or 1.
** Elements must be present and populated with data if present in the sending system. If no data is available (yet), a null flavor (see below) indicates and possibly classifies the missing information (marked as R).
** Attribute flagged as required must be present in the instance and populated.
* '''M''': For mandatory elements data must be sent and no missing values are allowed, i.e. if the sending system does not have information for mandatory elements the XML instance cannot be created and sent (marked as M).
* '''NP''': no data may be present at all (not permitted)
* '''C''': conditional conformance; typically a conformance table shows the circumstances (conditions) derived from information in the instance and the corresponding cardinalities and conformance statements.

=== Missing values (null flavor) ===
For every data type it is possible to specify a missing value including a kind of reason why data is missing. Instead of specifying any attribute of the corresponding element, a @nullFlavor attribute expresses the omission of data. Note that missing data is not allowed for mandatory elements (see above).
<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value nullFlavor="OTH"/>

<code nullFlavor="UNK"/>

<booleanInd nullFlavor="NI"/>

</syntaxhighlight>

The codes for the @nullFlavor attribute are drawn from the following hierarchical code system. It is a Coded Simple (CS), which means it has no code system (attribute @codeSystem) specified.
{| class="hl7table"
|+<ref group="Table">NullFlavor</ref> ''NullFlavor''
! Code
! width=15% | Print Name
! Definition / Description
|-
| NI || No Information || No information whatsoever can be inferred from this exceptional value. This is the most general exceptional value. It is also the default exceptional value.
|-
| OTH || other || The actual value is not an element in the value domain of a variable. (e.g., concept not provided by required code system).
|-
| NINF || negative infinity || Negative infinity of numbers.
|-
| PINF || positive infinity || Positive infinity of numbers.
|-
| UNK || unknown || A proper value is applicable, but not known.
|-
| ASKU || asked but unknown || Information was sought but not found (e.g., patient was asked but didn't know)
|-
| NAV || temporarily unavailable || Information is not available at this time but it is expected that it will be available later.
|-
| NASK || not asked || This information has not been sought (e.g., patient was not asked)
|-
| TRC || trace || The content is greater than zero, but too small to be quantified.
|-
| MSK || masked || There is information on this item available but it has not been provided by the sender due to security, privacy or other reasons. There may be an alternate mechanism for gaining access to this information.
Note: using this null flavour does provide information that may be a breach of confidentiality, even though no detail data is provided. Its primary purpose is for those circumstances where it is necessary to inform the receiver that the information does exist without providing any detail.
|-
| NA || not applicable || No proper value is applicable in this context (e.g., last menstrual period for a male).
|-
| NP || not present || Value is not present in a message. This is only defined in messages, never in application data! All values not present in the message must be replaced by the applicable default, or no-information (NI) as the default of all defaults.
|}

=== ANY as the generic data type ===

This abstract data type is the basis for all other data types. Not a single value within a CDA document has the effective data type ANY, but any data type within HL7v3 is a specialization of ANY. This also means that any other data type inherits all properties of ANY (see [[#Missing_values_.28null_flavor.29|“Missing values (null flavor)”]]).

The ANY type is occasionally found in HL7 models when it comes to clinical finding etc. where – at model time – the actual data type of the value is not known. At instantiation time however, the actual data type ''is'' known and ANY is always replaced by a particular data type in an instance.

One example is the observation value (child element value in an observation), where in the model the data type of value cannot be anticipated. When instantiation is taking place, the data type is specified by the XML instance attribute ''@xsi:type''. This information can be used by the receiver to validate and process the value.

Attributes of an element with this data type are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@nullFlavor''' || <center>CS</center> || <center>–</center> || Classification of the missing value, see [[#Missing_values_.28null_flavor.29|3.3 Missing values (null flavor)]].
|}

{| class="hl7table"
| <center>[[File:Conformance.svg|50px]] dtr1-1-ANY</center> || If there is a ''nullFlavor'', there shall be no other attribute or element, unless it's ''nullFlavor="OTH"''. In that case ''@codeSystem'' or ''originalText'' (see “code” data types) may have a value.
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">

<value xsi:type="CE" code="N11.9" codeSystem="2.16.840.1.113883.6.3"/>


<value xsi:type="PQ" value="12" unit="mL"/>


<value xsi:type="ED">this is text</value>
</syntaxhighlight>

=== Boolean (BL) ===

Elements of this data type refer to Boolean logic and have an attribute @value.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>BL</center> || <center>–</center> || Valued as “true” or “false”
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<negationInd value="false"/>

<deceasedInd value="true"/>

</syntaxhighlight>

In some situations, the BL data does not apply to an XML element, but an attribute. In that case, the attribute carries the Boolean value directly.
<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<support contextConductionInd ="false">
...
</support>
</syntaxhighlight>

=== Instance Identifier (II) ===

This data type identifies instances of classes like observations or entities (persons, organizations). Attributes are

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@extension''' || <center>ST</center> || <center>O</center> || Identification
|-
| '''@root''' || <center>OID</center> || <center>R</center> || Source of identification
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<id extension="13234453645" root="2.16.840.1.113883.2.6.15.3.427.1"/>
</syntaxhighlight>

The @root attribute is of type OID (object identifier), a unique identifier of the issuing authority or system. For example, a patient with a patient number 13234453645 created by a specific healthcare provider organization is uniquely identified by the number itself in @extension and the OID of the organization or the sending system, in the example 2.16.840.1.113883.2.6.15.3.427.1 in @root.
In some cases, a single OID identifies an object uniquely. In that situation, only @root is populated and @extension is omitted.

{| class="hl7table"
| [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Encapsulated Data (ED) ===

Elements of this data type carry multimedia content. The actual multimedia content is represented as element content. There are two situations for the use of ED:
* Inline: The full data is transmitted in the type. This form is mainly used for text.
* By reference: a thumbnail is provided which links to the full data by reference.
In an instance, the data type is normally determined by an xsi:type specification and some attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@mediaType''' || <center>CS</center> || <center>O</center> || MIME media type classification. At time of writing this specification, the following MIME types are allowed:
* text/plain (plain text)
* text/html (text with html markup)
* image/jpeg (JPEG image)
* application/pdf (a PDF, portable document format)
* application/hl7-sda+xml (CDA documents).
|-
| '''@representation''' || <center>CS</center> || <center>O</center> || Representation of the multimedia content. At time of writing this specification, the following representations are allowed:
* TXT (text, this is the default)
* B64 base 64 encoded data, for example for embedded CDA documents).
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<text xsi:type="ED" mediaType="text/plain">
Patient treated sucessfully
</text>

<text mediaType="application/hl7-sda+xml" representation="B64">PD94bWw..etc..==</text>

</syntaxhighlight>

To include referenced data the two sub elements thumbnail and reference are used.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''reference''' || <center>TEL</center> || <center>0..*</center> || <center>O</center> || Link (URI) to full data
|-
| '''thumbnail''' || <center>ED</center> || <center>0..*</center> || <center>O</center> || Thumbnail of referenced data
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<value xsi:type="ED" mediaType="image/png" representation="B64">
<reference value="http://radiology.bergen.no/xrays/128s.png"/>
<thumbnail mediaType="image/jpeg" representation="B64"> MNY...83== </thumbnail>
</value>
</syntaxhighlight>

=== Strings (ST) ===

This data type is a specialization of the ED type where @mediaType is fixed “text/plain” and @representation is fixed “TXT”. It allows conveying a character string as element content. This data type is used in other data types it like the @extension in instance identifiers, or address and person name data type components.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<lotNumber> 143GT6DT </lotNumber>
</syntaxhighlight>

=== Concept Descriptor (CD) ===

This data type specifies a concept by means of a code and its code system (except for situations where no code is available). A couple of specializations of data type CD exist, which differ in the main characteristics (properties) of the data type that may or may not be supported.

{| class="hl7table" style="width:50%"
|+ Table 1: Properties of data types used for codes
! <div style="text-align: right">DataType</div> !! CD !! CE !! CV !! CO !! CS
|-
! <div style="text-align: left">Property</div> !! !! !! !! !!
|-
| '''@code''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||<center>X</center>
|-
| '''@codeSystem''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''@codeSystemVersion''' || <center>X</center> || <center>X</center> || <center>X</center>|| <center>X</center> ||
|-
| '''@displayName''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''originalText''' || <center>X</center> || <center>X</center> || <center>X</center> || <center>X</center> ||
|-
| '''translation''' || <center>X</center> || <center>X</center> || || ||
|-
| '''qualifier''' || <center>X</center> || || || ||
|}

Because the CE variant is most used in practice, the general explanation of the proper-ties will be given with de description of CE (see below).
The only attribute that is unique to CD is briefly explained here.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@qualifier''' || <center>CR</center> || <center>O</center> || An additional qualifier for the code.
|}

Complex terminologies like SNOMED CT can be used only using data type CD.

=== Coded with Equivalents (CE) ===

With elements of this data type, a concept by means of a code and its coding system (except for situations where no code is available) can be specified. It optionally contains one or more equivalents using other code systems.
It may contain the following attributes:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@code''' || <center>ST</center> || <center>R</center> || The actual code
|-
| '''@codeSystem''' || <center>OID</center> || <center>R</center> || required to identify the code system were the code is drawn from. This is an OID (object identifier, see [[#Object_Identifiers_.28OIDs.29|Object Identifiers at 4.1]])
|-
| '''@displayName''' || <center>ST</center> || <center>O</center> || Optional textual representation of code. A display name may be specified representing the plain text of the code. The information of this attribute may not be used by the receiving system for interpretation, but only for display purposes. The display name may never be transmitted without a code and must have the same meaning as the code.
|-
| '''@codeSystemName''' || <center>ST</center> || <center>O</center> || A textual representation of the name of the code system
|-
| '''@codeSystemVersion''' || <center>ST</center> || <center>O</center> || A textual representation of the version of the code system
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"/>

<code code="AU" codeSystem="2.16.840.1.113883.5.33"/>

<storageCode code="AC" codeSystem="2.16.840.1.113883.5.34" displayName="active"/>

<code code="A45.0" displayName="Somatisierungsstörung" codeSystem="1.2.276.0.76.5.409" codeSystemName="ICD-10 GM 2012"/>
</syntaxhighlight>

There are some child elements of codes that can be used to express what the “original text” was that was used for the coding or to indicate that there are “translations” to other code systems than the primary code.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''originalText''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Textual representation of the concept, actually a description which was used to create the actual code
|}

No semantics may be assumed other than showing the ''@displayName'' to a user to clarify the code. A display name cannot occur without its code and must carry the same meaning.

In case no code is known, it is allowed to specify a ''@nullFlavor'' for the code element and to give information about the (not yet coded) concept in original text. However, this should be an exception.

If other codes than the primary code need to be conveyed adding a translation child element can be used.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<originalText>minor aphthous stomatitis</originalText>
</code>
</syntaxhighlight>

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''translation''' || <center>CD</center> || <center>0..*</center> || <center>O</center> || Alternative code(s)
|}

A ''translation'' element is also of type CD and shall have a code and a code system identified. It shall point to the same concept as the primary code. It is allowed that a translation conveys less conceptual details than the original code.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<code code="K12.0" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" displayName="Recurrent oral aphthae">
<translation code="528.2" codeSystem="2.16.840.1.113883.6.2" codeSystemName="ICD9" displayName="Oral aphthae"/>
</code>
</syntaxhighlight>

=== Coded Value (CV) ===

This is actually a specialization of CE (see above), with the exception that neither ''originalText'' nor ''translation'' child element are allowed.

=== Coded Simple Value (CS) ===

This is actually a specialization of CE (see above), with no code system attribute and no original text or translation child element allowed. It specifies a concept by means of a code from a ''predefined'' code system (table) where the code is drawn from. This data type is usually applied in the context of fixed predefined HL7 tables.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<statusCode code="completed"/>
</syntaxhighlight>

In this example ''statusCode'' is bound in the underlying model to the specific code system ''ActStatus''. Because it is predefined by means of the vocabulary binding, ''@codeSystem'' is omitted.

{| class="hl7table"
| [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

=== Telecommunication Address (TEL) ===

Elements of this type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>ST</center> || <center>R</center> || carries strings that represent telecommunication contact information
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

The actual data is preceded by the scheme (refer to Internet Standard “RFC 1738 Uniform Resource Locators (URL)” <ref>RFC 1738 Uniform Resource Locators (URL): http://www.ietf.org/rfc/rfc1738.txt</ref>.

Examples:
* telephone (tel:),
* fax (fax:),
* email (mailto:).

It must follow the rules defined in Internet “RFC 2806 URLs for Telephone Calls” <ref>RFC 2806 URLs for Telephone Calls: http://www.ietf.org/rfc/rfc2806.txt</ref>.

The following codes will be used in the “use” attribute:
* H – Home
* WP – Work
* MC can be used (in addition to H or WP) to denote that this is a mobile phone.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257" />

<telecom use="H" value="tel:55354257" />

<telecom use="H" value="fax:56542558" />

<telecom value="tel:+41.34.21.4765342"/>

<telecom value="mailto:opr@opr-sem.no"/>

<telecom use="WP MC" value="tel:97555786" />
</syntaxhighlight>

It is possible to express the useable period of a telecommunication contact. A child element ''useablePeriod'' is used as a time interval to indicate this period.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''useablePeriod''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<telecom value="tel:55354257">
<useablePeriod>
<high value="20111201"/>
</useablePeriod>
</telecom>
</syntaxhighlight>

=== Postal Address (AD) ===

Elements of this data type have a substructure in order to represent a structured address specification. In this implementation guide only a selection of all possible child elements is allowed, the original HL7 specification is richer.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''streetAddressLine''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Street address, includes street name and house number
|-
| '''city''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || City
|-
| '''postalCode''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Postal code
|-
| '''country''' || <center>ST</center> || <center>0..*</center> || <center>O</center> || Country
|-
|}

{| class="hl7table"
| [[File:Pfeil_rechts.png|50px]]
|Please note that the sequence of the sub elements is country specific, i.e. it has to follow “common” rules how to write an address. For example, an UK address and a German address have different sequences of address representation.
|}

A ''@use'' attribute can also be specified.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@use''' || <center>CS</center> || <center>O</center> || Represents the type of the telecommunication contact
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="WP">
<streetAddressLine>Anna-Louisa-Karsch-Str. 2</streetAddressLine>
<postalCode>10178</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<addr use="H WP">
<streetAddressLine>Tatungasse 34</streetAddressLine>
<postalCode>10825</postalCode>
<city>Berlin</city>
</addr>
</syntaxhighlight>

Also, a country may be specified using the element ''country''.

=== Person Name (PN) ===

Elements of this data type do also have a substructure to represent the parts of a person name, like family or given name and prefixes.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>
<given>Franz</given>
<given>Ingrun</given>
<family>Nordmann</family>
</name>
</syntaxhighlight>

Previous or birth or maiden names are supported using the ''validTime'' element. ''validTime'' (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]]) specifies the validity range of the name.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">

<name>
<given>Jan</given>
<given>Olaf</given>
<family>Hendrikson</family>
<validTime>
<high value="20000101"/>
</validTime>
</name>
</syntaxhighlight>

Note that the name attribute is repeating, i.e. multiple (types of) names could be sent. It is up to the receiver (based on the value of the ''@use'' attribute, and ''validTime'') to decide what name it wants to use or import in its database.

=== Organisation Name (ON) ===

Elements of this data type represent a name of an organization.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name> Charité Berlin </name>
</syntaxhighlight>

The optional ''validTime'' element (with child elements low and high, see data type [[#Interval_of_time_.28IVL_TS.29|IVL_TS at 3.21]] may be used to specify the validity range of the name of the organization.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''validTime''' || <center>IVL_TS</center> || <center>0..*</center> || <center>O</center> || validity range of the name of the organization
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<name>The old hospital
<validTime>
<high value="20111231235959"/>
</validTime>
</name>
</syntaxhighlight>

Please note that the use of ''validTime'' yields XML mixed content which should be avoid-ed if possible.

=== Integer Number (INT) ===

Elements of this data type are used to specify integer numbers and have one attribute.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>int</center> || <center>R</center> || Integer value
|}

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<sequenceNumber value="24"/>
</syntaxhighlight>

=== Physical Quantities (PQ) ===

Elements of this data type are physical quantities, i.e. a measurable quantity (or countable) value from the physical world. This is different from just a “number”, because there is a (natural) unit specified in which the measurable quantity is expressed.
Examples:
* an amount of blood 20 ml (sample volume)
* a cut with a length of 10 cm (result observation)
* a dose of 200 milligrams per administration (dosing)
* delivery of 60 pieces of a tablet (amount supplied).
Elements of this data type have the following attributes.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attributes
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>real</center> || <center>R</center> || value of the measurement
|-
| '''@unit''' || <center>CS</center> || <center>R</center> || unit of measurement
|}

In the unit of measurement unit is expressed following the ''Unified Code for Units of Measure'' (UCUM) specification. This specification is a collection of atomic units, prefixes and a corresponding grammar for valid combinations to build all-natural units of measurement. For a complete description of possible units, see the ''Unified Code for Units of Measure'' <ref>Unified Code for Units of Measure: http://unitsofmeasure.org/</ref> specification.
If a value is not countable or if measurable, for example expressed in milligrams or liters, then this unit is a valid UCUM unit like “mg” or “L”. If a value is countable, for example the number of tablets, then this attribute contains “1”.
In HL7 it is required that all PQ data type units are valid UCUM units.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<value value="165" unit="cm"/>

<value value="81.1" unit="kg"/>

<value value="120" unit="mm[Hg]"/>

<value value="5" unit="1"/>
</syntaxhighlight>

=== Point in Time (TS) ===

Elements of this data type have the attribute

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Attribute
! width=8% | DT
! width=8% | Conf
! width=64% | Description
|-
| '''@value''' || <center>TS</center> || <center>R</center> || Point in time
|}

and specify points in time in the format YYYYMMDDhhmmss±ZZZZ, where
* YYYY is the four-digit year,
* MM the two-digit month,
* DD the two-digit day,
* hh the two-digit hour,
* mm the two-digits minute and
* ss the two-digit second.
Optional a time zone ZZZZ, the four-digit time alignment with a preceding “-” or a “+” can be specified. If time zone is omitted, local time is assumed.
The point in time may be right truncated in respect to the precision of the information.

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<effectiveTime value="20140412"/>

<effectiveTime value="201409091245"/>

<effectiveTime value="1996"/>

<birthTime value="19540714"/>

<effectiveTime value="20140412+0100"/>
</syntaxhighlight>

=== Intervals (IVL) ===

Intervals are defined only for data types with an ordinal or interval scale type. There are several possibilities to determine an interval (see Figure 2), for example to specify

* a lower <low> and an upper boundary <high> (a),
* a lower <low> boundary and width <width> (b)
* an upper boundary and width <width> (c) or
* the middle of the interval <nowiki><center></nowiki> and a width <width> (d).

[[File:CDA_Core_Principles_Figure_2_Determining_Intervals.png|700px]]

<ref group="Figure">Several possibilities to determine closed intervals</ref> ''Several possibilities to determine closed intervals''

{{ConstraintBox|
To indicate an interval, only the following combinations are permitted.
(1) A lower and an upper boundary may not be identical, and their accuracy has to be equal.

Correct examples:

{{BeginGreenBox|}}
Interval from 5 to 6
Interval from 20110607 until 20110612
{{EndGreenBox}}

Incorrect examples:

{{BeginRedBox|}}
Interval from 5 to 6.0
Interval from 20110101 to 2011
{{EndRedBox|}}

(2) A lower boundary and a width

(3) A lower limit boundary

(4) A upper limit boundary

(5) Only the middle of the interval

(6) Only the width of an interval}}

Accordingly, four child elements are available.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Element
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Lower boundary
|-
| '''high''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Upper boundary
|-
| '''center''' || <center>''(T)''</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Where ''(T)'' is defined in this specification as one of the data types “TS” or “PQ”.

=== Interval of time (IVL_TS) ===

Elements of this data type represent time intervals. There are four possible child elements.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Lower boundary (start date/time)
|-
| '''high''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Upper boundary (end date/time)
|-
| '''center''' || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of an interval
|-
| '''width''' || <center>PQ</center> || <center>0..1</center> || <center>C</center> || Width of an interval
|}

Normally, a lower and an upper boundary is given, both are points in time. Also, it is possible to specify open intervals like “since June 14, 1999” (left boundary given only) or “until September 24, 2006” (right boundary given).

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="20110507"/>
<high value="20110909"/>
</effectiveTime>

<effectiveTime>
<low value="20110507"/>
</effectiveTime>

<value>
<low value="20110101"/>
<width value="120" unit="d"/>
</value>

<value>
<center value="20110101"/>
</value>
</syntaxhighlight>

{| class="hl7table"
| [[File:Pfeil_rechts.png|50px]]
|It must be noted that intervals of time stamps in HL7 are equally treated as other interval types (e.g. integers). The statement, one may take 1–3 tablets (interval of integers), for example, says that you are allowed to take no more than three tablets, not 3½ or 3.5 tablets. On the other hand, when treat the words “until 12 June 2011” regarding the upper interval limit differently, particularly we assume that the entire day 12 June is still in-cluded in this time interval.
Thus, in human perception time intervals are handled differently com-pared to such as number intervals. This is a situation may lead to inconsist-encies in standardized communication. As a conclusion, an upper limit “12 June 2011” means that only the very first moment of the 12 June is included in the interval, but not, for example, the 12 June 13:00 hours.
Interpretation does not depend on the accuracy of the time:
* “after 2004” means “from January 1, 2005 00:00:00.000”,
* “after 20041201” means “from 2 December 2004 00:00:00.000 hours”,
* and “after 200412011200” means “from 1 December 2004 12:01:00.000”.

As a result, you have to carefully consider the specification and implemen-tation of time intervals upper boundaries. In order to prevent mis-understandings intervals are always specified with the date and time for an upper limit that would cover the whole day. Accordingly, “201106122359” means 12 June 2011 throughout the day.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<effectiveTime>
<low value="201106122359"/>
</effectiveTime>
</syntaxhighlight>

Because of the equal treatment of time intervals this is applied also to the lower limit boundaries of time intervals as “0000”. This means for example that “since 9 June 2011” is expressed as “201106090000”.
|}

The <width> element is of data type PQ (physical quantity). The value obviously shall relate to a period of time and it is required to include a “time” unit. These are the units “us” (microseconds), “ms” (milliseconds), “s” (seconds), “min” (minute), “h” (hours), “d” (day), “wk” (week), “mo” (month) and “a” (year).

{{ConstraintBox|
For interval of time stamps the @unit of a ''low'' or ''high'' child element shall use units
* us (microseconds),
* ms (milliseconds),
* s (seconds),
* min (minute),
* h (hours),
* d (day),
* wk (week),
* mo (month) or
* a (year).
}}

=== Interval of physical quantities (IVL_PQ) ===

Elements of this data type are used to indicate intervals of physical quantities (see also [[#Physical Quantities (PQ)|3.18 Physical Quantities (PQ)]]). In general, an upper and a lower boundary is specified. It is also possible to use ''center'' instead of ''low'' and ''high''.

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''low || <center>TS</center> || <center>0..1</center> || <center>C</center> || the lower limit of the interval (i.e. the minimum amount).
|-
| '''high || <center>TS</center> || <center>0..1</center> || <center>C</center> || the upper limit of the interval (i.e. the maximum amount).
|-
| '''center || <center>TS</center> || <center>0..1</center> || <center>C</center> || Center of the interval
|}

The ''center'' child element is used when there is no interval, but an exact value. Alternative would be to demote IVL_PQ to data type PQ and populate the element’s ''@value'' attribute, but this is more difficult to process in XML. That is why the use of the ''center'' child element is deprecated.

{| class="hl7table"
| [[File:Conformance.svg|50px]]||
All conformance statements applicable to this data type can be found at the [https://art-decor.org/mediawiki/index.php?title=Table_of_Version3_Datatypes ART-DECOR table of V3 data types].
|}

<center>''XML Example snippets''</center>
<syntaxhighlight lang="xml">
<referenceRange>
<low value="7.5" unit="mmol/l"/>
<high value="10" unit="mmol/l"/>
</referenceRange>

<doseQuantity>
<center value="9" unit="1"/>
</doseQuantity>
</syntaxhighlight>

=== Ratio of quantities (RTO_QTY_QTY) ===

Elements of this data type specify ratios and have two child elements, a numerator and a denominator. The underlying QTY (Quantity) data type is an abstract data type and in a XML instance it has to be replaced by a specific data type using the ''@xsi:type'' instruction (see below).

In this specification only “PQ” or “INT” are allowed for the demotion of both ''numerator'' and ''denominator''. The relevant child elements are:

{| class="hl7table" style="width:50%"
|+
! width=20% | Core Elements
! width=8% | DT
! width=8% | Card
! width=8% | Conf
! width=56% | Description
|-
| '''numerator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the numerator of the ratio
|-
| '''denominator || <center>(T)</center> || <center>1..1</center> || <center>R</center> || The amount of the denominator of the ratio
|}

If a model attribute already is a RTO_QTY_QTY, you need to specify (demote) the OTY abstract data type for both ''numerator'' and ''denominator'' by using an ''@xsi:type'' instruction.
In some cases where the model attribute is of type “ANY”, also the root element shall carry an ''@xsi:type'' RTO_QTY_QTY instruction.

<center>''XML Example snippet''</center>
<syntaxhighlight lang="xml">
<maxDoseQuantity>
<numerator xsi:type="PQ" value="6"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="400" unit="mg"/>
<denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

<maxDoseQuantity>
<numerator xsi:type="PQ" value="5"/>
<denominator xsi:type="PQ" value="1" unit="h"/>
</maxDoseQuantity>

<value xsi:type="RTO_QTY_QTY">
<numerator xsi:type="INT" value="1"/>
<denominator xsi:type="INT" value="10000"/>
</value>
</syntaxhighlight>

== Identification mechanisms ==

=== Object Identifiers (OIDs) ===

Standardized exchange of information using messages or documents also deals with unique identifications of objects and concepts, especially in environments where sender and receiver do not “know” each other necessarily.

It is important to understand the difference between identification of instances (ids) and code concepts (classifications). Within the context of HL7 interactions OIDs are quite often used.
An id points to a specific instance of an object or identification scheme (a particular methodology for the identification of a class of objects), for example a specific person as the patient or a physician, a specific lab observation or an X-ray photo.

In contrast to instance identifiers, a classification identifies a specific concept. The type of patient (inpatient, outpatient), the type of doctor (an anesthesiologist), the codes for gender or a lab observation (blood cell count) may serve as examples.

OIDs (object identifiers) are worldwide unique identifiers for objects. They are used in HL7 to specify identifications and classifications. An object in this sense is persistent, well-defined information, definitions or specifications and is represented with ids or codes.

Commonly used OIDs (i.e. used for a purpose that is wider in scope than the regional healthcare organization; used in communications between healthcare regions) can be found in OIDs registries such as

* [http://www.oid-info.com www.oid-info.com],
* [http://www.hl7.org www.hl7.org],
* [http://www.hl7.org.uk/version3group/oids.asp HL7 OID registry in the UK],
* [https://www.dimdi.de/dynamic/de/klassifikationen/weitere-klassifikationen-und-standards/oid/ OID registry Germany].

{| class="hl7table"
| [[File:Pfeil_rechts.png|50px]]
|All OIDs with an element of 999 or 9999 are for documentation purposes only. They will be replaced by permanent OIDs once these have been as-signed/found/applied for.
|}

OID (Object Identifiers) are unique identifiers for any kind of objects. They are defined in Rec. ITU-T X.660 | ISO/IEC 9834-1. This identification system for objects and concepts makes reliable electronic information exchange possible. Administration and Registration is regulated by a set of rules, described in the corresponding chapter of this document.

Every artefact in ART-DECOR has an Object Identifier (OID). There are recommendations for the management and the exchange of Object Identifiers, partially defined in ISO TS 13582 <ref>ISO TS 13582: https://www.iso.org/standard/69652.html</ref>.

''HL7 International'' has created a type ontology for the OIDs in the HL7 registry to make it easier for the user community to search for OIDs they may be looking for and can be found at hl7.org.

From a policy perspective it is common practice in several healthcare related OID registries (HL7 International at http://www.hl7.org, OID Registry Germany at http://www.dimdi.de, OID registry Switzerland at http://oid.refdata.ch, and OID registry Austria at https://www.gesundheit.gv.at/OID_Frontend) to distinguish at least between the following types of OIDs:

{| style="width: 60%;" class="hl7table"
|+<ref group="Table">Recommended OID sub-branches for different artefacts</ref> ''Recommended OID sub-branches for different artefacts''
! Arc !! Description
|-
| .3 || organizational bodies and groups
|-
| .4 || identifier systems and namespaces
|-
| .5 || code systems
|-
| .7 || document artefacts
|-
| .9 || conformance profiles
|-
| .10 || templates
|-
| .11 || value sets
|-
| .19 || examples
|-
| .99 || experimental
|}

''Example: given that “your” root OID is 1.2.3.4.5, the first value set of your governance group is then to be 1.2.3.4.5.11.1, with .11 as the value set “branch” and the last .1 as the first artefact of that kind.''

In ART-DECOR a project typically is set into the .77 branch of a governance group. When setting up the project, the OID for that project also determines the artefact OIDs using throughout the ART-DECOR project. The following additional branches are used to distinguish between different OID types:

{| class="hl7table"
|+<ref group="Table">Recommended OID sub-branches for ART-DECOR projects</ref> ''Recommended OID sub-branches for different artefacts''
! Artefact code Description !! Recommended !! OID suffix
|-
| DS || dataset || .77.1
|-
| DE || dataset concept || .77.2
|-
| SC || scenario || .77.3
|-
| TR || transaction in scenario || .77.4
|-
| CS || code system || .77.5
|-
| IS || issue || .77.6
|-
| AC || actor in scenario || .77.7
|-
| CL || concept list in dataset || .77.8
|-
| EL || element in template || .77.9
|-
| TM || template || .77.10
|-
| VS || value set || .77.11
|-
| RL || rule for instances || .77.12
|-
| SX || test/example scenario || .77.18
|-
| EX || test/example instance || .77.19
|-
| QX || qualification test/example || .77.20
|-
| TX || test/example data element || .77.21
|-
| CM || community || .77.22
|-
| MP || concept map || .77.24
|}

In ART-DECOR a newly created project uses these OID branches automatically.

=== Instance identification ===

Instance identification is done with the id element of a class. Its type is II (instance identifier) and described in the data type section above. For example, a patient number can be represented as
* 2.16.578.1.34.1.5432.1, the root-OID of the issuing authority, for example a system/application in a hospital, and
* 67543242 as the ''@extension'', representing the patient number within the system defined by the ''@root'' attribute.

=== Coding scheme identification ===

Coding schemes have to be uniquely identified using OIDs as well. All coding tables used in this implementation guide show the corresponding OID that has to be specified in the ''@codeSystem'' attribute of coded elements. Both attributes ''@code'' and ''@codeSystem'' together allows a correct interpretation of concept and code.

=== List of identification schemes ===

The following are OIDs for commonly used identification schemes.

{| class="hl7table"
|+<ref group="Table">Commonly used identification scheme OIDs</ref> ''Commonly used identification scheme OIDs''
! OID !! Identification System Name !! Description !! Issuer
|-
| 1.2.276.0.76.4.8 || KV-Nummer || Krankenversichertennummer ||
|-
| 1.2.276.0.76.4.17 || BSNR || Betriebsstättennummer ||
|-
| 1.2.276.0.76.4.16 || LANR || lebenslange Arztnummer ||
|}

=== List of code systems ===

The following are OIDs for code systems.

{| class="hl7table"
|+<ref group="Table">Commonly used code system OIDs</ref> ''Commonly used code system OIDs''
! OID !! Code System Name !! Description !! Issuer
|-
| 2.16.840.1.113883.6.1 || LOINC || Logical Observation Identifiers Names and Codes (LOINC) || Regenstrief Institute
|-
| 2.16.840.1.113883.6.96 || SNOMED CT || Systemized Nomenclature in Medicine Reference Terminology (SNOMED CT) || SNOMED International
|-
| 1.0.3166.1.2 || ISO 3166-1 (second edition) || Country codes as per ISO 3166-1:2007 || ISO
|}

== Vocabulary ==

=== Code Systems ===

Within HL7, a ''Code System'' is defined as a collection of codes with associated designations and meanings. Examples of code systems include ICD-10, SNOMED CT, and LOINC.
To meet the requirements of a code system as defined by HL7, a given code must resolve to one and only one meaning within the code system. Given this definition, each code table in the HL7 Version 3 standard represents a different code system since codes are sometimes used in different tables to have different meanings.
For example, “M” in the administrative gender table (''AdministrativeGender'', OID 2.16.840.1.113883.5.1) means “male”, while “M” in the marital status table (''MaritalStatus'', OID 2.16.840.1.113883.5.2) means “married”.
In this specification, code system tables are not presented in detail.

=== Value Sets ===

A ''Value Set'' represents a uniquely identifiable set of valid concept representations, where any concept representation can be tested to determine whether or not it is a member of the value set.
Value set complexity may range from a simple flat list of concept codes drawn from a single code system, to an unbounded hierarchical set of possibly post-coordinated expressions drawn from multiple code systems.
Value sets exist to constrain the content for a coded element in an HL7 static model or data type property. Value sets cannot have null content and must contain at least one concept representation where any given concept is generally (but not required to be) represented by only a single code within the Value Set.

[[File:CDA_Core_Principles_Figure_3_ValueSet_Example.png|800px]]

<ref group="Figure">Example presentation of the value set “MaritalStatus”</ref> ''Example presentation of the value set “MaritalStatus”''

{| class="hl7table"
| [[File:Pfeil_rechts.png|50px]]
|Please note that value set OIDs never appear in a CDA Release 2 document. They are used for constraint expressions, for example in implementation guides.
In order to send a specific code drawn from a value set, the corresponding code system has to be conveyed.
An example, in the implementation specification the constraint on the model element ''maritalStatusCode'' is expressed as “to be drawn from value set 2.16.840.1.113883.5.2 ''MaritalStatus''”.
To actually send a marital status of “M” (married) that is shown in the value set figure above, the corresponding HL7 CDA instance would say:
<syntaxhighlight lang="xml">
<maritalStatusCode code="M" codeSystem="2.16.840.1.113883.5.2"/>
</syntaxhighlight>
|}

In this specification, value set tables are not presented in detail.

==== Binding strength ====

There is an optional vocabulary strength for data types that support that feature (coded concepts). Examples include CD, CE, CV and CO. Values are required, extensible, preferred and example. Default is required.

Please note: the formerly supported values CNE (Coded No Extensibility) and CWE (Coded With Extensibility) in ART-DECOR are deprecated as of December 2017. Specification CNE is handled as required and CWE is handled as extensible.

{| class="hl7table"
|+<ref group="Table">Binding Strengths</ref> ''Binding Strengths''
! Strength !! Description
|-
|required||Required/CNE. Coded with no exceptions; this element SHALL be from the specified value set
|-
|extensible||Extensible/CWE. Coded with Exceptions; this element SHALL be from the specified value set if any of the codes within the value set can apply to the concept being communicated. If the value set does not cover the concept (based on human review), alternate codings (or, data type allowing, text) may be included instead.
|-
|preferred||Preferred. Instances are encouraged to draw from the specified codes for interoperability purposes but are not required to do so to be considered conformant.
|-
|example||Example. Instances are not expected or even encouraged to draw from the specified value set. The value set merely provides examples of the types of concepts intended to be included.
|}

Mismatches with required lead to validation errors (SHALL logic). Mismatches with extensible lead to validation warnings (SHOULD logic). Mismatches with preferred lead to validation information messages (MAY logic). Mismatches with example don't have any validation consequences.

== Appendix ==

=== References ===

<references/>

=== List of figures ===

<references group="Figure" />

=== List of tables ===

<references group="Table" />