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 1: Line 1:
[[Patient Care]]
+
[[Patient Care]] | [[Patient Care Normative Ballot Content]]
  
[[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.
 +
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.
  
== '''Use of Templates in Care Provision'''==
+
=== Kinds of Patient Care templates ===
 
+
The Patient Care standard describes conformance requirements in terms of two general levels:
The Care Provision Domain D-MIMs and R-MIMs for specific message topics depend on the RIM, vocabulary and modeling approaches like any message domain. However, two HL7 base materials are fundamental for all the Care Provision messages. These are the Clinical Statement Pattern (CSP), specifically the CMET COCT_MT530000 (A_SupportingClinicalStatement universal), which in this normative materials replaces the earlier Care_Statement CMET, and a templating approach. The Care Provision D-MIM has the A_SupportingClinicalStatement as core specification mechanism for the numerous date elements for clinical content in Care Records and Care Record based messages. In the D-MIM there are pointers to underlying R-MIMs via the Entry Points. Each Entry Point refers to a RIM based structure that specifies a particular message model. Each of these Entry Points uses the 2011 template approach, which is described here briefly.
+
* 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.)
Care Provision D-MIM uses the CSP as whole, which can also be used as the source for an HL7 template. Or more precise: a CSP-derived R-MIM model can be used to create a more specialized HL7 template.  Care Provision does not include a full description of HL7 templates (see the HL7 template specification "Specification and Use of Reusable Constraint Templates" and the Sept 2011 DSTU work on templates for that). However, since all Care Provision message models depend on the template approach, it is explained here in basic terms.  An CSP based HL7 template used in Care Provision is a RIM-based model that is applied on top or as further specification of another RIM model. It can be in the form of a series of RIM compatible assertions (commonly seen in CDA templates, e.g. CCD), or it can be a graphical RIM-based model, such as Patient Care has developed several as roll outs or constraints on the CSP. Any RIM model can be used as a template. All HL7 CMETs for instance are capable of being used as templates, as is the CSP as a whole, or any model using the CSP or being derived from the CSP. Templates are more of a method of combining several models than a technique for individual modeling.
+
* 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.
 
 
To use an HL7 graphical template e.g. an R-MIM, on the Care Provision model, you simply create another RIM based model that is a true constraint of Care Provision and CSP (for example, an assessment scale). This new model is your template. Your implementation guide then states that all messages must conform to the existing Care Provision model in the normal way, to the CSP in the normal way, and additionally, the parts of message instances that deal with the assessment scale must conform to your new assessment scale instance template. This does not mean that all parts of a Care Provision must look like assessment scales, only the parts of it that you specify. Patient Care is specifying several clinical contents materials into Detailed Clinical Models (DCM). These normally allow multiple terminology and code bindings. Once the DCMs are specified to function in Care Provision R-MIMs, they are transformed into Clinical Statements / clinical statement based HL7 templates. In this process, one action is to choose one code only for implementation. So creating an implementation specification from a DCM means that the specified clinical content will adhere to the CSP in general, and has to confirm to the instance template specification for codes among other constraints.  
 
A whole series of different CSP derived templates can be used on top of a compatible model (such as CDA in general and CCD in particular) to describe the various clinical data sets, codes and value sets, and other constraints that are needed.  
 
Unfortunately there is no tooling that directly supports checking of the clinical part of the message against the CSP and the template, although it is possible to create XSD schemas and schematron to do this second stage validation in addition to the normal HL7 XSD check.
 
Each Clinical Statement use in Patient Care is organized as follows:
 
 
 
* Each topic has a narrative description defining the scope and use case.
 
* Each topic has an associated Figure, showing a subset of the Care Provision model and/or Clinical Statement model being constrained. It should be noted that the entire Care Provision D-MIM and Clinical Statement models are available for use, and that the topics are only focusing on specific use cases and required constraints.
 
*  Each topic has a set of constraints, expressed using conformance verbs (e.g. "shall", "should", "may").
 
*  Each topic has a template identifier, which can be used to populate the InfrastructureRoot.templateId attribute of an instance. An instance that thus populates the templateId attribute is claiming conformance to the corresponding topic.
 

Revision as of 11:39, 3 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.

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.