Use of HL7 templates in CP
Patient Care | Patient Care Normative Ballot Content
Contents
- 1 Use of Templates in Care Provision
- 1.1 HL7 Templates
- 1.2 Kinds of Patient Care templates
- 1.3 Template Identifiers in instances
- 1.4 Open and Closed Templates
- 1.5 Expressing Constraints in Templates
- 1.6 Containment Relationship
- 1.7 Co-Occurance
- 1.8 Originator Responsibilities: General Case
- 1.9 Recipient Responsibilities: General Case
- 1.10 Examples
Use of Templates in Care Provision
HL7 Templates
An HL7 template is a constraint on models based on the HL7 Reference Information Model (RIM). It expresses the data content needed in a specific clinical or administrative context.
In healthcare there are prescribed patterns by which, for example, multiple observations may be combined to describe selected, gross observations. Some observations may be simple, such as the single lab result (e.g. potassium in blood is 4.4 mEq/L) or the blood pressure concept, which involves a set of expected observations (i.e., systolic, diastolic, patient position, method, etc.). Other more elaborate diagnostic procedures may involve hundreds of related pieces of information, including anatomy, orientation, sequences of measurements, etc.
In HL7, more or less generic models exist; the Patient Care model, especially the Care Statements = Clinical Statement Pattern (CSP) is one of it. Templates provide a method of describing rules for combining and constraining HL7 v3 XML instances like a Patient Care message. Templates can be used for three purposes:
- To have a guideline to create (a fragment of) a Patient Care message instance
- To validate an instance whether it conforms to the specified template rules
- To have a guidance while processing a Patient Care message instance.
The last point should be considered carefully, because an instance must convey fully semantics even without knowing the underlying template.
Based on user need and preference, the template ideally is a structure that can be used as a building block and, once defined, can be re-used whenever appropriate.
Kinds of Patient Care templates
The Patient Care standard describes conformance requirements in terms of two general levels:
- Message root level templates: they define / refine the overall structure of a message starting from the Care Provision class, which templates are contained in the message and whether they are optional or required.
- Substructure level templates (patient, provider etc.)
- Clinical Statement level templates: impose the Clinical Statement Pattern of a Patient Care message; they define the constraints on the classes, class attributes, data types and class relationships.
Template Identifiers in instances
Template identifiers (templateId) are assigned at the Message root level and Clinical Statement level. When valued in an instance, the template identifier signals the imposition of a set of template-defined constraints. The value of this attribute, e.g.
<templateId root="2.16.840.1.113883.10.1.2.3" />
provides a unique identifier for the template in question.
If a template is a specialization of another template, its first constraint indicates the more general template. The general template is not always required. In all cases where a more specific template conforms to a more general template, asserting the more specific template also implies conformance to the more general template.
Open and Closed Templates
In open templates, all of the features of the Patient Care based specification are allowed except as constrained by the templates. By contrast, a closed template specifies everything that is allowed and nothing further may be included.
Open templates allow HL7 implementers to develop additional content not constrained within the template. HL7 encourages implementers to bring their use cases forward as candidate requirements to be formalized in a subsequent version of the standard to maximize the use of shared semantics.
In general, Patient Care defines open templates only.
Expressing Constraints in Templates
Constraints expressed in templates may determine
- The data type or a data type flavor
- The cardinality
- The conformance, e.g. if data may be absent (nullFlavor)
- Vocabulary bindings and coding strengths
- Possible fixed values
- Additional properties such as units (measurements), ranges, fraction digits
of a class attribute. In general this means to determine the properties of an XML element or an XML attribute. In addition, containment relationship and co-occurances of items may also be determined.
Containment Relationship
The containment relationship constraints between a specific structure (context) in an XML instance and sub-structures in that context (child elements).
They may be indirect, meaning that where a structure asserts containment of a substructure, that substructure can either be a direct child or a further descendent of that structure, or be direct, meaning that the contained substructure shall be a direct child of the structure.
A report about the first prenatal visit of a pregnant woman with historical findings recorded by an obstetrician or a midwife should contain an observation about the number of pregnancies so far (including the actual pregnancy), also known as “gravidity”.
Assume that the underlying model allows for clinical statements like an observation via a component relationship.
| Attribute | DT | Card | Conf | Description/Fixed value |
|---|---|---|---|---|
| component | 1..1 | R | Contains GravidityObservation template id 2.16.840.1.113883.2.4.6.10.90.1053 | |
| @typeCode | CS | 1..1 | F | COMP |
Verbatim:
- SHALL contain exactly one [1..1] component such that it
- SHALL contain exactly one [1..1] @typeCode="COMP" (CodeSystem: HL7ActRelationshipType 2.16.840.1.113883.5.1002)
- SHALL contain exactly one [1..1] GravidityObservation (template id 2.16.840.1.113883.2.4.6.10.90.1053)
Assume that the referenced template is an observation with a LOINC code 11996-6 (number of pregnancies, reported), then the above example could be properly expressed as follows.
<component typeCode="COMP">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.2.4.6.10.90.1053"/>
Co-Occurance
Assume, that if the number of fetuses of a pregnant woman is more than 1 (multiple gestation), than an Amnionicity observation – number of fluid filled / (amniotic) sacs – and a Chorionicity observation– type of placentation – need to be reported.
| Attribute | DT | Card | Conf | Description/Fixed value | |
|---|---|---|---|---|---|
| component | C | Conditionally contains AmnionicityObservation template id 2.16.840.1.113883.2.4.6.10.90.1054 | |||
| Card | Conf | Predicate | |||
| 1..1 | M | If number of fetuses > 1 | |||
| NP | otherwise | ||||
| @typeCode | CS | 1..1 | F | COMP | |
| component | C | Conditionally contains ChorionicityObservation template id 2.16.840.1.113883.2.4.6.10.90.1055 | |||
| Card | Conf | Predicate | |||
| 1..1 | M | If number of fetuses > 1 | |||
| NP | otherwise | ||||
| @typeCode | CS | 1..1 | F | COMP |
An Immunization Activity can also include that a certain vaccination was not given (expressed as a negationInd/actNegationInd of the associated substance administration is valued “true”).
Assume that a business rule says that in this case an Immunization Refusal Reason shall be stated.
Table:
| Attribute | DT | Card | Conf | Description/Fixed value |
|---|---|---|---|---|
| substanceAdministration | ||||
| @classCode | CS | 1..1 | F | SBADM |
| @moodCode | CS | 1..1 | F | EVN |
| @negationInd | BL | 0..1 | O | Refusal yes/no |
| ... | ||||
| entryRelationship | C | Contains ImmunizationRefusalReason template id 2.16.840.1.113883.2.4.6.10.90.1054 | ||
| Card | Conf | Predicate | ||
| 1..1 | M | If @negationInd = true | ||
| 0..1 | O | otherwise | ||
| @typeCode | 1..1 | M | RSON |
- An APGAR score (assessment scale) is a simple and repeatable method to quickly and summarily assess the health of newborn children immediately after birth
- The APGAR the sum comprises of five axes (Appearance, Pulse, Grimace, Activity, Respiration) each of it reported as 0, 1 or 2, resulting in valid sum scores values between 0 and 10. Normally the particular axes are not reported.
- An APGAR panel contains exactly one APGAR sum score and contains all five sub scores as component observations.
- Assume that a business rules says that iIf APGAR sum score < 4 (which is considered to be critical) then the whole panel its required to be included, otherwise sum score only is considered to be sufficient.
Originator Responsibilities: General Case
An originator can apply a templateId if there is a desire to assert conformance with a particular template.
In the most general forms of CDA exchange, an originator need not apply a templateId for every template that an object in an instance document conforms to. The implementation guide (IG) shall assert whenever templateIds are required for conformance.
Recipient Responsibilities: General Case
A recipient may reject an instance that does not contain a particular templateId (e.g., a recipient looking to receive only Procedure Note documents can reject an instance without the appropriate templateId).
A recipient may process objects in an instance document that do not contain a templateId (e.g., a recipient can process entries that contain Observation acts within a Problems section, even if the entries do not have templateIds).
Examples
This is an example of a template defined in DECOR* (Data Elements, Codes, OIDs and Rules). The example is about the number of gravidities of a woman including a possible actual one, e.g. a woman is gravida 2, i.e. she has been or is pregnant two times so far. The observation code is bound to 11996-6 from LOINC. The number of gravidities is (observation value) is demoted to be a count (INT) and restricted to be valued zero up to 75 (no reports seen so far about a number of pregnancies larger than 75). The template comes with a valid example.
<template id="2.999.999.997.10.1002" name="Gravidity" displayName="Gravidity" effectiveDate="2011-06-22T00:00:00" statusCode="active">
<element name="hl7:observation">
<example>
<observation classCode="OBS" moodCode="EVN">
*DECOR allows a consistent collection of information from a clinical view (functional specification), codes (i.e. value set definitions), identifiers (OIDs), and rules (templates to constrain XML instances). As for the "rules" part the DECOR canonical format is transformed into a package of schematron rules (including references to all used value sets and data types) which is called the "runtime" environment. In addition, a documentation of the template definitions (among others in HTML format that can be made directly accessible thru schematron error, warning and information messages).
This is an example template in DECOR format defining a person's body height. A short description is given in three languages. The observation is a physical quantity (PQ) and has either a unit "m" (meters) with a valid range of 0..3 with two fraction digits required, or a unit "cm" (centimeters) with a value ranged 0..300 (tallest human ever documented was 272 cm so far). This template can act as a parent template that further restricts the use of the value to be e.g. "cm" only, ranged from 120..245 etc.
<template id="2.999.999.997.10.1000" name="BodyHeight" displayName="Body height" effectiveDate="2011-07-14T00:00:00" statusCode="active">
<desc language="nl-NL">Lichaamslengte van een persoon</desc>
<desc language="de-DE">Körperlänge einer Person</desc>
<desc language="en-US">Body height of a person</desc>
<element name="hl7:observation">
<example>
<observation classCode="OBS" moodCode="EVN">
