This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Use of HL7 templates in CP"

From HL7Wiki
Jump to navigation Jump to search
Line 134: Line 134:
 
Changes to the Template that do not change the semantics or intention of the template will constitute a new version of the Template being created. This means that the id of the former template remains the same and the @effectiveDate is changed to the date when the new version of the template was created.
 
Changes to the Template that do not change the semantics or intention of the template will constitute a new version of the Template being created. This means that the id of the former template remains the same and the @effectiveDate is changed to the date when the new version of the template was created.
 
Any change to the semantic meaning of the template will constitute the creation of a new template. This means that a new template will get a new @id.
 
Any change to the semantic meaning of the template will constitute the creation of a new template. This means that a new template will get a new @id.
 +
 +
=== 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.
 +
Examples of class attributes in table format, with different attribute names, data types (DT), cardinalitiy (Card), conformance (Conf) and description.
  
 
=== Cardinality ===
 
=== Cardinality ===

Revision as of 16:43, 24 February 2012

Patient Care | Patient Care Normative Ballot Content

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.

Template Metadata

Template metadata is mainly defined in the “Business Requirements for Template Registries”. In order to support template registries and to allow the appropriate use of templates, the following metadata is associated with each template.

@id

A mandatory globally unique, non-semantic, identifier for the template as the primary identifier.

@name

A required name for the template as a secondary identifier. Please note that there is no guarantee that the name is globally unique.

@effectiveDate

The mandatory date after which the template can be considered for use. Use of the template prior to this date would be considered an invalid use of the template.

@expirationDate

The optional date at which the concept represented by this template becomes stale, and should be reviewed for (clinical) relevance and accuracy. Use of the template after this date would be considered venturesome.

@statusCode

The mandatory status of the template. According to the Business Requirements for Template Registries the following status codes of a template shall be supported.

statusCode Description
draft Template under development (nascent). Metadata and template may be incomplete. Entered primarily to encourage other users to be aware of ongoing process.
active Template has been published by the custodian organization and deemed fit for use. May have associated adoption and annotation metadata
retired Template retired: No longer fit for use. Information available for historical reference.
inactive Template never recommended for use. For example, rejected, withdrawn or found another template fit for use of the one under development. Will not have associated adoption metadata.
rejected Template is rejected
cancelled Template is withdrawn
update Template under Update (adoption metadata): adopter adds adoption metadata and/or grouping metadata: these are the only actions an adopter organization can perform. The template(s) in the “under update (adoption metadata)” status are unavailable for any other status or metadata changes until the “under update/adoption metadata” action has been completed.
pending Template is in pre-publication review: the template is complete, pending appropriate review. Entered primarily to encourage other users to be aware of and/or participate in the review process. The custodian organization has not given it an “Active” status (i.e. it has not been published); and it may still be rejected (transitioned to an inactive status). E.g. the template may be under ballot by an SDO.
review Template is in Review: a post-publication state; may result in a new version or a retirement or no change at all. A new version is one that adds clarity but not new intent; the version number is incremented by one, but the identifier is unchanged. A retirement is a template that is no longer fit for purpose, and which may be replaced by a different a template with a different identifier, which is linked to the retired template.

@displayName

The optional human readable display name for the template for orientation purposes. This is not intended for machine processing.

@versionLabel

The optional human readable version label for the template to be able to determine the correct version of a template. This is not intended for machine processing.

desc

An optional free text natural language description of the intent and scope of the template. The purpose is to provide the author’s initial intent for the template. A description may be present in different languages.

context

An optional context of the template, i.e. where in an XML instance the template rules are considered to applied to. From a practical viewpoint templates may have no context. In this case the template is not “exposed” for external use, but rather used for internal inclusion in other templates. If the template is intended to be published for external purposes, it shall have a context. Typically there are three types of context specifications.

sibling node context

The template rules apply to all sibling elements and descendent nodes in the instance.

Example

CDA section level templates are often defined in sibling node context. 
parent node context

The template rules apply to the siblings of the parent node and all descendent nodes in the instance. Example

CDA entry level templates are often defined in parent node context. 
pathname specified context

A pathname (making use of XPath expressions) is specified, which allows to activate templates in an instance without the need to have template id elements in an instance. Example

Assume a recordTarget in an instance is considered to be unique for the payload. Then a template containing rules for the record target can be defined in the context of pathname “hl7:recordTarget”.

item

The item is used as an identification mechanism when it comes to error messages by derived validation scripts. For example if each constraint has a (unique) number, it may be used to precede every error message. Example

A CDA “encounter” section level template defines the section code to be 46240-8 drawn from LOINC. Each constraint is uniquely identified by an identifier at or near the end of the constraint (e.g., CONF:7941).
Every error, warning or information that is raised during validation carries this constraint identifier.
The default is the template id.

example

Templates may have zero to many example fragments to illustrate valid instances. In addition, each class attribute definition may have also an example fragment.

Versioning aspects

Changes to the Template that do not change the semantics or intention of the template will constitute a new version of the Template being created. This means that the id of the former template remains the same and the @effectiveDate is changed to the date when the new version of the template was created. Any change to the semantic meaning of the template will constitute the creation of a new template. This means that a new template will get a new @id.

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. Examples of class attributes in table format, with different attribute names, data types (DT), cardinalitiy (Card), conformance (Conf) and description.

Cardinality

The cardinality indicator specifies the allowable occurrences within a message instance. The cardinality indicators are interpreted with the following format “m…n” where m represents the least and n the most:

  • 0..1 zero or one
  • 1..1 exactly one
  • 1..* at least one
  • 0..* zero or more
  • 1..n at least one and not more than n

Conformance

Vocabulary Conformance

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

Model and template hierarchy example

Clinical Statement Pattern (unconstraint model)

Assessment Scale (constraint model on Clinical Statement)

APGAR score (constraint model on Assessment Scale)