Difference between revisions of "PHARM Templates Implementationguide"
| Line 17: | Line 17: | ||
}} | }} | ||
| − | + | ||
{{:PHARM_Authors_and_Contributors}} | {{:PHARM_Authors_and_Contributors}} | ||
Revision as of 12:18, 16 March 2019
This document contains: HL7 STU Ballot Pharmacy Templates (1.50). The text materials belong to category cdapharm.
Pharmacy Templates, Release 1
© 2016-2019 Health Level Seven International ® ALL RIGHTS RESERVED. The reproduction of this material in any form is strictly forbidden without the written permission of the publisher. HL7 and Health Level Seven are registered trademarks of Health Level Seven International.
| Co-Chair, Primary Editor | Melva Peters Jenaker Consulting melva@jenakerconsulting.com |
| Co-Chair, Primary Editor | John Hatem jnhatem@hotmail.com |
| Co-Chair | Scott Robertson PharmD scott.m.robertson@kp.org |
| Co-Chair | Jean Duteau jean@duteaudesign.com |
| Contributor | Dr Kai U. Heitmann Heitmann Consulting and Services, ART-DECOR Open Tools GmbH, HL7 Germany info@kheitmann.de |
| Contributor | Giorgio Cangioli, PhD Consultant, HL7 Italy giorgio.cangioli@gmail.com |
| Contributor | Tom de Jong VZVZ, HL7 The Netherlands tom@nova-pro.nl |
| Contributor | Dr Christof Geßner Gematik GmbH, HL7 Germany christof.gessner@gematik.de |
Contents
Introduction
This Implementation Guide provides CDA R2 templates for Medication Order and Medication Statement that can be used by HL7 standards developers and external projects to develop models for pharmacy related content. The implementation guide is intended to provide consistency of pharmacy related models across all uses regardless of the method of transport by creating a library of Universal (UV) Pharmacy Templates that can be used by other Work Groups to derive constrained versions.
Purpose
Background
Historically multiple HL7 Work Groups have developed specifications for pharmacy related content and as a result, there is inconsistency in how medication related content is represented in HL7 V2, V3, CDA and FHIR. The Pharmacy Work Group often receives questions as to how to model pharmacy related content but in some cases, the use case cannot be met with the existing models.
This Implementation Guide provides a CDA R2 library of pharmacy templates that can be used by HL7 Work Groups or external projects to derive constrained versions of models for pharmacy related content.
Scope
The scope of the Implementation Guide is limited to Medication Order and Medication Statement. The content was developed by aligning and harmonizing the existing specifications for Consolidated CDA (C-CDA Release 2.1[1]).
Future releases of the Implementation Guide will include Medication Dispense and Medication Administration.
Ballot Status of the Document
The Implementation Guide is being balloted as Standard for Trial Use (STU) and then to Normative.
Audience
- Clinical and Public Health laboratories
- Immunization Registries
- Pharmaceutical Vendors
- EHR/PHR vendors
- Clinical Decision Support Systems
- HIS Vendors
- Emergency Services Providers
- Healthcare Institutions
- Pharmacists
- Physicians and other Clinicians
Relationships with other projects and guides
- Consolidated CDA (C-CDA)
- HL7 Version 3 Pharmacy Models
- HL7 FHIR® Pharmacy Resources
- International Patient Summary (IPS), where all pharmacy related templates are specialisations of the corresponding templates defined in this guide
Principles and background
The Pharmacy Work Group has a set of rich set of existing models that were used as the basis for the implementation guide including HL7 V3 models and FHIR resources.
This implementation guide was created by the Pharmacy Work Group using the following approach:
- Review of Consolidated CDA (C-CDA[1]) to identify templates that include pharmacy related content
- Compare C-CDA templates to existing Pharmacy HL7 V3 models and Pharmacy FHIR resources to identify differences and gaps
- Create universal templates to that can be constrained for use for new templates
For the Medication Model, R_Medication Universal” (COCT_MT230100UV02), Release 2 (as published in HL7 V3 2017 ) (V2.0.2 Dec 2010) (derived from Common Product Model) was used.
The template rules are formalized using the computable format defined by the HL7 Templates Standard: Specification and Use of Reusable Information Constraint Templates, Release 1[2] in order to facilitate also the automatic generation of consistent testing and validation capabilities.
Technical Background
What is a CDA
CDA R2 is "… a document markup standard that specifies the structure and semantics of clinical documents for the purpose of exchange” [CDA R2, Section 1.1]. Clinical documents, according to CDA, have the following characteristics:
- Persistence
- Stewardship
- Potential for authentication
- Context
- Wholeness
- Human readability
CDA defines a header for classification and management and a document body that carries the clinical record. While the header metadata are prescriptive and designed for consistency across all instances, the body is highly generic, leaving the designation of semantic requirements to implementation.
Templated CDA
CDA R2 can be constrained by mechanisms defined in the “Refinement and Localization” section of the HL7 Version 3 Interoperability Standards. The mechanism most commonly used to constrain CDA is referred to as “templated CDA”. This specification created a set of artifacts containing modular CDA templates (and associated value sets) for the purpose of the International Patient Summary, and the templates can be reused across any number of CDA document types.
There are different kinds of templates that might be created. Among them, the most common ones are:
- CDA Document Level Templates constrain fields in the Clinical Document Architecture (CDA) header, and define containment relationships to CDA sections.
For example, a History-and-Physical document-level template might require that the patient’s name be present, and that the document contain a Physical Exam section. - CDA Header Level Templates constrain fields for parts of the CDA header, like the patient (record target), the author, participations or the service event.
- CDA Section Level Templates constrain fields in the CDA section, and define containment relationships to CDA entries.
For example, a Physical-exam section-level template might require that the section/code be fixed to a particular LOINC code, and that the section contain a Systolic Blood Pressure observation. - CDA Entry Level Templates constrain the CDA clinical statement model in accordance with real world observations and acts.
For example, a Systolic-blood-pressure entry-level template defines how the CDA Observation class is constrained (how to populate observation/code, how to populate observation/value, etc.) to represent the notion of a systolic blood pressure.
Open and Closed Templates
Open templates permit anything to be done in the underlying standard that is not explicitly prohibited. This allows templates to be built up over time that extend and go beyond the original use cases for which they were originally designed.
Closed templates only permit what has been defined in the template, and do not permit anything beyond that. There are good reasons to use closed templates, sometimes having to do with local policy. For example, in communicating information from a healthcare provider to an insurance company, some information may need to be omitted to ensure patient privacy laws are followed. Most templates developed for CDA are of the open sort.
Template versioning
Template versioning is needed to enable template designs to evolve over time.
Template versioning enables template designers to control and shape the conformance statements that make up a template’s design over time tailoring the design to fit the template’s intended purpose.
Each template version is associated with a particular template. The template – as a whole – has a mandatory globally unique, non-semantic, identifier. The identifier serves as the identifier of the original intent of the template and as the identifier of the set of versions that represent the template over time.
Template versions have a mandatory timestamp (date and optional time), called the “effective date”. The date can be seen as the point in time when the template version “came into being”, i.e. was recognized as existent by the governance group. Use of the template prior to this date would be considered an invalid use of the template.
For further information on Templates, Template Versions and related topics refer to the HL7 Templates Standard[2].
Identifiers for Templates and Value Sets
This specification specifies CDA Entry Level Templates only. They can be re-used in any appropriate context, such as an Entry of a medication section.
Two "root" Entry Templates are provided as entry points for the two described use cases:
- UV Medication Order (2.16.840.1.113883.10.21.4.1)
- UV Medication Statement (2.16.840.1.113883.10.21.4.7)
These templates use other Entry Level Templates that are all listed in a subsequent section of this document.
This specification uses the following OIDs for the artefacts that are registered at the HL7 OID registry.
- The root OID for templates is 2.16.840.1.113883.10.21
- Entry Level templates are summarized under 2.16.840.1.113883.10.21.4, e.g. 2.16.840.1.113883.10.21.4.5 UV Substitution Permission
- “other” assistance templates are summarized under 2.16.840.1.113883.10.21.9, e.g. 2.16.840.1.113883.10.22.9.1 UV Use Period
- The root OID for Value Sets is 2.16.840.1.113883.11
The sub branches for templates follow the recommendations of HL7 International and ISO 13582[3].
Namespace Identifier
The CDA extensions for Pharmacy defined by the Pharmacy Workgroup are handled under the XML namespace identifier urn:hl7-org:pharm and typically use the namespace prefix pharm:.
How to read this document
All artifacts (templates, value sets etc.) listed with the status 
Draft or 
Pending are subject to ballot comments.
Artifacts with other status information, especially 
Final or Active are not (directly) part of the ballot and some artifacts actually even come from external sources. Reference artifacts are indicated by the symbol
. These reference artifacts are also not subject to the ballot, as they might be balloted elsewhere already.
The PDF version contains a ruler on the left side of the pages. A ruler has the page number on top of it and allows locating a line at the page by simply specifying the number at the scale tick. This is more precise and allows also commenting on graphics and pictures.
For example if you have a comment on page 29 because of a typo (see figure), you simply specify the error with its location p0029-04.
Of course you can also refer by classical chapter and section numbers. The use of the ruler has the ballot team's preference, though.
[Figure 1] To locate a typo on page 29 as a ballot comment, simply specify the location p0029-04.
Reading Publication Artefacts
A reading guide is available that explains the formalisms used to express the publication artefacts, i.e. template meta data and template design. For convenience the guide is included in the appendix.
Functional requirements and high-level use cases
The following use cases are relevant to the pharmacy domain for both community and institutional settings:
- Prescribing a medication (aka Prescription or Order or Request)
- Dispensing a medication
- Recording the administration of a medication
- Recording the use of a medication (in the past, current or future)
The following definitions are relevant to this Implementation Guide:
- "Prescribing" is an activity that can be performed by a variety of healthcare professionals and involves a variety of orderable items (see glossary entry). For the purposes of the following Implementation Guide, prescribing is defined as the act of authorizing the usage of a medication" in various settings for example, inpatient, community, and long term care. This could include initiating a new medication order or making all kinds of modifications to existing orders.
- "Dispensing" is the provision of a medication or other material to a caregiver in fulfillment of a prescription or medication order. It supplies the materials needed to perform the prescribed actions by those who will perform them. Examples of dispensing include eyeglasses, contact lenses and medications.
For the purposes of the following ballot material, dispensing is defined as supplying a medication in fulfillment of a prescription or medication order. While dispensing is usually performed by a pharmacist, other health care providers such as nurses or physicians may also dispense.
- "Administration" is an activity undertaken to give medication to the patient. In the community, this process is usually not recorded, since the majority occurs in the patient's home; only administrations undertaken by a healthcare professional, such as vaccination, tend to be formally documented. Administration of medication in the institutional setting is usually recorded on a dose-by-dose basis, and may be messaged on that basis, or a summary of all the administrations occurring during an inpatient stay may be described.
- "Medication Statement" is an activity that can be performed by a variety of healthcare professionals, or the patient, or non-healthcare professionals. Examples of recording medication statements include taking a patient's medication history, recording reported use of medications where the source of the patient information is from a third party and not the patient e.g. a family member when the patient is unable to communicate their medication history.
Templates
Use Case Entry Level Templates
As mentioned before, this specification defines two "root" Entry Level Templates, one for each of the covered use cases.
UV Medication Order
The following graph gives an overview of the high-level template components of this template, followed by the actual definition.
Note: If you need to include multiple prescribed medications as part of a single order, you can include multiple CDA entries under one CDA section. CDA Section definitions are not part of this guide.
|
The boxes reflect the CDA Template Types. Symbols: * denotes templates with more than one classification, @ indicates a recursion in the definition
Appendix (Informative)
Acronyms and abbreviations
- C-CDA: Consolidated CDA
- CDA: Clinical Document Architecture
- DSTU: Draft Standard for Trial Use
- EDQM: European Directorate for the Quality of Medicines & Healthcare
- EHR: Electronic Healthcare Record
- HL7: Health Level Seven
- HP: Healthcare Professional
- IDMP: IDentification of Medicinal Products (ISO Standard)
- IHE: Integrating the Healthcare Enterprise
- ISO: International Organization for Standardization
- JIC: Joint Initiative Council on SDO Global Health Informatics Standardization
- LOINC: Logical Observation Identifiers Names & Codes
- MPID: Medicinal Product Identifier
- PCID : Medicinal Product Package Identifier
- PhPID(s): Pharmaceutical Product Identifier(s)
- SDO: Standard Developing Organization
- STU: Standard for Trial Use
- UCUM: Unified Code for Units of Measure
Glossary
- Prescribing is an activity that can be performed by a variety of healthcare professionals and involves a variety of orderable items (see glossary entry). For the purposes of the following Implementation Guide, prescribing is defined as the act of prescribing a medication in either an ambulatory or an institutional setting. This could include initiating a new medication order or making all kinds of modifications to existing orders.
- Dispensing is an activity undertaken to fulfill the logistical requirements of a prescription. It supplies the materials needed to perform the prescribed actions by those who will perform them. Examples of dispensing include eyeglasses, contact lenses and medications. For the purposes of the following ballot material, dispensing is defined as supplying a medication in fulfillment of a prescription or medication order. While dispensing in these circumstances would usually be performed by a pharmacist, other health care providers such as nurses or physicians might also dispense medications.
- Administration is an activity undertaken to give medication to the patient. In the community, this process is usually not recorded, since the majority occurs in the patient's home; only administrations undertaken by a healthcare professional, such as vaccination, tend to be formally documented. Administration of medication in the institutional setting is usually recorded on a dose-by-dose basis, and may be messaged on that basis, or a summary of all the administrations occurring during an inpatient stay may be described.
Integrated examples
The Medication on CDA specification releases are published at the Pharmacy Templates Project Publication Page[4]. The actual release has a link to the XML materials as which the W3C schemas are part of; it also includes example CDA document instances. A set of use cases have been defined and represented in Medication on CDA format.
It is likely that the publication site will move to hl7.org permanently, we will inform about that process.
Validation artifacts
You can test your implementation (instances) against the Medication on CDA specification. To download materials to your computer for local testing and validation consider...
- ...the W3C schemas (actually valid for any CDA specification) located at the Publication Page[4]. The actual release has a link to the XML materials as which the W3C schemas are part of; it also includes example CDA document instances.
- ..the ISO schematron, automatically generated by the tool. These are files to do validation locally by associating IPS CDA instances with the main schematron using an XML editor or to use the derived XSLT conversions and apply the according XSLT derivation to your local IPS CDA instance.
For further information you can follow the documentation.
Operational information
- The original specification is hosted on the logical ART-DECOR main server art-decor.org under the Governance Group HL7 International, the project is reachable at the Project Live Landing Page[5].
- Any Medication on CDA specification release in HTML format resides at the Publication Page[4]. It is likely that the publication site will move to hl7.org permanently, we will inform about that process.
Licenses
Following is a non-exhaustive list of third-party terminologies that may require a separate license:
- SNOMED CT: SNOMED International (formerly know as International Healthcare Terminology Standards Development Organization IHTSDO)[6] or info@ihtsdo.org
- Logical Observation Identifiers Names & Codes (LOINC): The Regenstrief Institute, Inc.
- Unified Code for Units of Measure (UCUM) : Regenstrief Institute, Inc. and the UCUM Organization
List of all artifacts used in this guide
CDA Templates
- 2.16.840.1.113883.10.21.4.1 UV Medication Order
- 2.16.840.1.113883.10.21.4.2 UV Dispense Request
- 2.16.840.1.113883.10.21.4.3 UV ClinicalStatement Observation
- 2.16.840.1.113883.10.21.4.4 UV ClinicalStatement Encounter
- 2.16.840.1.113883.10.21.4.5 UV Substitution Permission
- 2.16.840.1.113883.10.21.4.6 UV Subordinate Substance Administration
- 2.16.840.1.113883.10.21.4.7 UV Medication Statement
- 2.16.840.1.113883.10.21.4.8 UV Medication Order Reference
- 2.16.840.1.113883.10.21.4.9 UV Dispense Event Reference
- 2.16.840.1.113883.10.21.4.10 UV Medication Information (simple)
- 2.16.840.1.113883.10.21.4.11 UV Medication Information (detail)
- 2.16.840.1.113883.10.21.4.12 UV Comment Activity
- 2.16.840.1.113883.10.21.9.1 UV Use Period
References (re-used) from current C-CDA
- 2.16.840.1.113883.10.20.22.4.19 Indication (V2)
Unconstrained Templates from the original CDA specification
- 2.16.840.1.113883.10.12.151 CDA Organization
- 2.16.840.1.113883.10.12.152 CDA Person
- 2.16.840.1.113883.10.12.153 CDA AssignedEntity
- 2.16.840.1.113883.10.12.310 CDA LabeledDrug
- 2.16.840.1.113883.10.12.311 CDA Material
- 2.16.840.1.113883.10.12.312 CDA ManufacturedProduct
- 2.16.840.1.113883.10.12.313 CDA PlayingEntity
- 2.16.840.1.113883.10.12.315 CDA Device
- 2.16.840.1.113883.10.12.316 CDA RelatedEntity
- 2.16.840.1.113883.10.12.318 CDA Author (Body)
- 2.16.840.1.113883.10.12.319 CDA Informant (Body)
- 2.16.840.1.113883.10.12.320 CDA Subject (Body)
- 2.16.840.1.113883.10.12.321 CDA Participant (Body)
- 2.16.840.1.113883.10.12.322 CDA Specimen
- 2.16.840.1.113883.10.12.323 CDA Performer (Body)
- 2.16.840.1.113883.10.12.324 CDA Reference
- 2.16.840.1.113883.10.12.325 CDA ExternalAct
- 2.16.840.1.113883.10.12.326 CDA ExternalObservation
- 2.16.840.1.113883.10.12.327 CDA ExternalProcedure
- 2.16.840.1.113883.10.12.328 CDA ExternalDocument
- 2.16.840.1.113883.10.12.329 CDA Precondition
Value Sets
Medication Time Units (UCUM)
| This terminology is a snapshot as of . Terminologies may evolve over time. If you need recent (dynamic) versions of this terminology, please retrieve it from the source. | |||||||||||||||||||||||||||||||||||||||
| Id | 2.16.840.1.113883.11.21.1 | Effective Date | 2023‑02‑01 11:12:08 | ||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Status | Final | Version Label | 3.0 | ||||||||||||||||||||||||||||||||||||
| Name | MedicationTimeUnits | Display Name | Medication Time Units (UCUM) | ||||||||||||||||||||||||||||||||||||
| Description | Medication Time Units, expressed in UCUM | ||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||
| Source Code System | 2.16.840.1.113883.6.8 - Unified Code for Units of Measure - FHIR: http://unitsofmeasure.org - HL7 V2: UCUM | ||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||
| Legenda: Type L=leaf, S=specializable, A=abstract, D=deprecated. NullFlavor OTH (other) suggests text in originalText. HL7 V3: NullFlavors to appear in @nullFlavor attribute instead of @code. | |||||||||||||||||||||||||||||||||||||||
ActStatusActiveCompletedAbortedSuspended
| This terminology is a snapshot as of . Terminologies may evolve over time. If you need recent (dynamic) versions of this terminology, please retrieve it from the source. | |||||||||||||||||||||||||||||
| Id | 2.16.840.1.113883.11.21.2 | Effective Date | 2017‑03‑06 | ||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Status | Draft | Version Label | |||||||||||||||||||||||||||
| Name | ActStatusCodeActiveCompletedAbortedSuspended | Display Name | ActStatusActiveCompletedAbortedSuspended | ||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||
| Source Code System | 2.16.840.1.113883.5.14 - ActStatus - FHIR: http://terminology.hl7.org/CodeSystem/v3-ActStatus | ||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||
| Legenda: Type L=leaf, S=specializable, A=abstract, D=deprecated. NullFlavor OTH (other) suggests text in originalText. HL7 V3: NullFlavors to appear in @nullFlavor attribute instead of @code. | |||||||||||||||||||||||||||||
Substance Administration Code
| This terminology is a snapshot as of . Terminologies may evolve over time. If you need recent (dynamic) versions of this terminology, please retrieve it from the source. | ||||||||||||||||||||||||||||
| Id | 2.16.840.1.113883.11.21.3 | Effective Date | 2018‑02‑16 | |||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Status | Draft | Version Label | ||||||||||||||||||||||||||
| Name | SubstanceAdministrationCode | Display Name | Substance Administration Code | |||||||||||||||||||||||||
| Source Code System | 2.16.840.1.113883.5.4 - Act Code - FHIR: http://terminology.hl7.org/CodeSystem/v3-ActCode - HL7 V2: ACTCODE | |||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||
| Legenda: Type L=leaf, S=specializable, A=abstract, D=deprecated. NullFlavor OTH (other) suggests text in originalText. HL7 V3: NullFlavors to appear in @nullFlavor attribute instead of @code. | ||||||||||||||||||||||||||||
Mood Code Evn Int Rqo
| This terminology is a snapshot as of . Terminologies may evolve over time. If you need recent (dynamic) versions of this terminology, please retrieve it from the source. | |||||||||||||||||||||||
| Id | 2.16.840.1.113883.11.21.4 | Effective Date | 2018‑03‑21 | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Status | Draft | Version Label | |||||||||||||||||||||
| Name | MoodCodeEvnIntRqo | Display Name | Mood Code Evn Int Rqo | ||||||||||||||||||||
| |||||||||||||||||||||||
| Source Code System | 2.16.840.1.113883.5.1001 - Act Mood - FHIR: http://terminology.hl7.org/CodeSystem/v3-ActMood | ||||||||||||||||||||||
| |||||||||||||||||||||||
| Legenda: Type L=leaf, S=specializable, A=abstract, D=deprecated. NullFlavor OTH (other) suggests text in originalText. HL7 V3: NullFlavors to appear in @nullFlavor attribute instead of @code. | |||||||||||||||||||||||
Unknown or absent medication
| This terminology is a snapshot as of . Terminologies may evolve over time. If you need recent (dynamic) versions of this terminology, please retrieve it from the source. | ||||||||||||||||||||||||||
| Id | 2.16.840.1.113883.11.21.5 | Effective Date | 2018‑03‑21 | |||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Status | Draft | Version Label | ||||||||||||||||||||||||
| Name | Unknownorabsentmedication | Display Name | Unknown or absent medication | |||||||||||||||||||||||
| Copyright | This artefact includes content from SNOMED Clinical Terms® (SNOMED CT®) which is copyright of the International Health Terminology Standards Development Organisation (IHTSDO). Implementers of these artefacts must have the appropriate SNOMED CT Affiliate license - for more information contact http://www.snomed.org/snomed-ct/getsnomed-ct or info@snomed.org. | |||||||||||||||||||||||||
| ||||||||||||||||||||||||||
| Source Code System | 2.16.840.1.113883.6.96 - SNOMED Clinical Terms - FHIR: http://snomed.info/sct - HL7 V2: SCT | |||||||||||||||||||||||||
| ||||||||||||||||||||||||||
| Legenda: Type L=leaf, S=specializable, A=abstract, D=deprecated. NullFlavor OTH (other) suggests text in originalText. HL7 V3: NullFlavors to appear in @nullFlavor attribute instead of @code. | ||||||||||||||||||||||||||
Referenced HL7 Version 3 Value Sets
- 2.16.840.1.113883.1.11.13955 ActEncounterCode
- 2.16.840.1.113883.1.11.16208 ActPharmacySupplyType
- 2.16.840.1.113883.1.11.16866 ActPriority
- 2.16.840.1.113883.1.11.15933 ActStatus
- 2.16.840.1.113883.1.11.19708 ActSubstanceAdministrationCode
- 2.16.840.1.113883.1.11.16621 ActSubstanceAdminSubstitutionCode
- 2.16.840.1.113883.1.11.14570 AdministrableDrugForm
- 2.16.840.1.113883.1.11.11526 HumanLanguage
- 2.16.840.1.113883.11.20.9.18 MoodCodeEvnInt
- 2.16.840.1.113883.1.11.78 Observation Interpretation
- 2.16.840.1.113883.1.11.14079 ObservationMethod
- 2.16.840.1.113883.1.11.14581 RouteOfAdministration
- 2.16.840.1.113883.1.11.19719 SubstanceAdminSubstitutionNotAllowedReason
- 2.16.840.1.113883.1.11.10706 TimingEvent
- 2.16.840.1.113883.1.11.19447 x_ActRelationshipEntryRelationship
- 2.16.840.1.113883.1.11.19890 x_ActStatusActiveComplete
Datatypes
Datatypes for element definitions used
- ANY – ANY
- BL – Boolean
- CD – Concept Descriptor
- CE – Coded with Equivalents
- CS – Coded Simple Value
- ED – Encapsulated Data
- EN – Entity Name
- II – Instance Identifier
- INT – Integer
- INT.NONNEG – Interval of Integer, non-negative
- IVL_INT – Interval of Integer
- IVL_PQ – Interval of Physical Quantity
- IVL_TS – Interval of Time Stamp
- IVXB_TS – Interval Boundary of Time Stamp
- PIVL_TS – Periodic Interval of Timezone
- PQ – Physical Quantity
- RTO_PQ_PQ – Ratio Physical Quantity / Physical Quantity
- ST – Character String
- TEL – Telecommunication Address
- TS – Time Stamp
Datatypes for attributes used
- bl – boolean code
- cs – code
- uid – identifier
How to read the table view for templates
The template definitions are shown in a table view. It is comprised of Template Meta data and the Template Design. For further information please refer to the HL7 Templates Standard: Specification and Use of Reusable Information Constraint Templates, Release 1[2].
Templates may also be included in the hierarchical graph view (often used for CDA), see below.
Template Meta data
The upper right part of the template table contains the template meta data. Template id, status and the template name are shown (1). Furthermore the Version (effective date), a possible version label and the display name are shown (2).
The description area (plain or an accordion) contains the template descriptions/purpose (3), followed by classifications and whether the template is defined as open or closed (4).
The usage part (5) may list templates that uses this template or what templates this templates uses. A relationship list (6) may show all relationships to other templates or models.
Examples may show the correct use of the template by an XML fragment (7).
The relationship list shows all relationships to other templates or models for this template. It is divided in the "Used by" part listing templates that make use of this template, and a "Uses" listing all templates that are used by this templates, either as inclusion or containment. Indirect relationships like the parent Document Level Template for a Section Level Template are marked with a chain symbol.
The PDF version is rendered in the same way, but maybe with different fonts etc. to fit customized publication requirements.
Table view of Template Design
The headings of the table view of a template design are:
Item (1) contains the XML document tree view of all elements and attributes specified in the template design. Elements are denoted by a preceding triangle and attributes by a preceding "@".
DT (2) data types, contains the data type of the item, for more information on valid data types for element and attributes (see [2]).
Card / Conf (3) cardinality (Card) and conformance (Conf) of the item. Cardinality is the usual notion of min and max occurrences of the element. For attributes 0..1 denotes optionality, 1..1 say that the attribute is required and NP denotes prohibited attributes. Conformance may display values as shown in the following table.
| Conf | Short | Description |
|---|---|---|
| O | optional | Data is truly optional |
| R | required | If data is present and not masked (e.g. for privacy reasons), it must be provided, otherwise it may be omitted or explicitly null flavored. Sender and receiver must support this element. |
| M | mandatory | The data must be populated with a valid value from the associated value domain, otherwise the instance is not valid and may not be communicated. Sender and receiver must support this element. |
| C | conditional | There are conditions when data has to be provided (e.g. co-constraints like "information about pregnancy IF the patient is "female". Sender and receiver must support this element. |
| F | fixed | The data has a fixed value. |
| NP | not permitted | Data shall not be present |
Description (4) contains a textual description of the item, may also contain constraints and values for fixed attributes.
Label (5) is a human readable label that is displayed upon errors, warnings or notes during validation.
Details of the table view
The actual template design shows the XML structure in a hierarchical list of elements (items) that are typically prefixed by the namespace "hl7:" or "cda:" (1).
Elements are denoted with a triangle, attributes with an @ sign (2).
Data types are specified according to the list of supported data types (3). They may be simple data types (lowercase), regular data types (uppercase) or flavors thereof. In case of coded elements, the coding strength (Required/CNE, Extensible/CWE, Preferred or Example) can be highlighted near the datatype (e.g. “CD.IPS (Extensible/CWE)”) ; the absence of indications about the strength (e.g. “CE.IPS”) shall be interpreted as “Required/CNE”.
| Strength | Displayed as | 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. |
The cardinality and conformance column is explained above (4).
Fixed values for e.g. attributes are also shown in the "description" column (5), preceded by a "F" in the Conf column.
Conformance statements are shown together with a CONF box, e.g. a @code and a @codeSystem with fixed and required values (6).
An optional label is displayed at the rightmost column (7).
Inclusion or containments of other templates, e.g. an entry within a section, are shown accordingly (8) along with their template id, display name and flexibility/stability indication, i.e. "DYNAMIC" (the most recent version) or a STATIC binding together with a version date.
Choices of elements are shown as a choice list with the elements in questions summarised in a bullet point list.
A typical Conformance Statement is the binding of a coded element to a value set. This is expressed in the way shown. The value set is represented with the id, display name and the flexibility/stability of the binding.
In case a constraint is expressed in words, a box "Constraint" accompanies the textual expression of the constraint.
In cases where constraints are expressed by formalised rules in ISO Schematron, the rule along with the role (error, warning), the test and the assertion message is shown.
How to read the Templates hierarchical graph view
Templates are often included in the hierarchical graph view (often used for CDA). It gives an overview of e.g. section and entries and their nesting/relationships.
In case a template has more that one type (CDA Person for header, section and entry templates), it is denoted with a *, if a recursive definition is detected, this is shown with the symbol @.
How to read the where criteria
Templates sometimes include criteria for identifying distinct elements from a list (e.g. in a choice).
The criteria used to identify the items are shown in square brackets using the assertion where [ criteria ]
Criteria can be:
- an xpath expression as in the example : where [hl7:low or hl7:high]
- or an integer indexing the items of the list: e.g. where [1]; where [2]
References
Literature
- Boone KW: The CDA Book. Springer 2011, ISBN 978-0-85729-336-7
Links
- ↑ 1.0 1.1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379
- ↑ 2.0 2.1 2.2 2.3 HL7 Templates Standard: Specification and Use of Reusable Information Constraint Templates, Release 1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=377
- ↑ ISO/TS 13582:2013 Health informatics -- Sharing of OID registry information
- ↑ 4.0 4.1 4.2 Pharmacy Templates Project Publication Page http://hl7intl.art-decor.org/index.php?prefix=pharmcda-
- ↑ Pharmacy Templates Project Live Landing Page http://art-decor.org/art-decor/decor-project--pharmcda-
- ↑ Get SNOMED CT http://www.ihtsdo.org/snomed-ct/get-snomed-ct
Figures
- ↑ Locating ballot comments
