Use of HL7 templates in CP

Patient Care

Patient Care Normative Ballot Content

Use of Templates in Care Provision

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.

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.

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.