1 / 22

HL7 Templates

HL7 Templates. A means to Manage Complexity. Objectives. What is an HL7 Template? What types of constraints can HL7 Templates define? What types of HL7 Templates are contemplated? Why do we need HL7 Templates? How are they created? How are they used in message instances?

kaden-craft
Download Presentation

HL7 Templates

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. HL7 Templates A means to Manage Complexity

  2. Objectives • What is an HL7 Template? • What types of constraints can HL7 Templates define? • What types of HL7 Templates are contemplated? • Why do we need HL7 Templates? • How are they created? • How are they used in message instances? • What is the current state of HL7 Templates as formal specifications? • What are early implementers doing with HL7 Templates? • Recommendations for HL7 Template Use for Infoway EBE

  3. What is an HL7 Template? • Formally, an HL7 Template is a registered set of constraints on a balloted HL7 static model. • HL7 balloted static models are all derived from the HL7 Reference Information Model • Balloted static models are expressed in XML according to the HL7 Model Interchange Format (MIF) • Static models describe the information structure of messages documents that are defined according to the Clinical Document Architecture • Work is underway to determine how EHRs Services use static models

  4. What types of constraints can HL7 Templates Define? • HL7 Templates constrain both structure and content • Structural constraints further restrict model elements such as cardinality, new class clones derived from balloted class clones, their attributes, relationships and HL7 data-types • Non-structural constraints include valid value set expressions and conditional constraints affecting more than one model element • Currently, non-structural constraints are to be expressed in Object Constraint Language (OCL) • OCL can specifies some, but not all, of the kinds of desirable constraints • OCL has few tools available to help correctly author constraints in a static model • Other approaches to constraining static models are being explored in various implementable technologies that have their own formal language • Current Tooling supports “constraint boxes” that allows text to be used to describe constraints

  5. Types of HL7 Templates • Document Templates • Atomic Concept Definition Templates • CEN Archetypes • Aggregate Measures Templates • Computed Measures Templates • “Assembly” or “sub-assembly” Templates

  6. Document Templates • A template applied to the CDA schema to produce a desired level of information structure and content for a particular purpose – a particular type of document • Analogous to a paper form with mandatory and optional sections and described level of detail for each section • If sections can be coded, the specific coding scheme and any additional constraints are usually specified • May reference other templates applied to specific sections or entries

  7. Atomic Concept Definition Templates • A template applied to part of a static model that specifies the structure and permitted coding to completely define a particular clinical concept • Any constraints on coded elements or value ranges are specified • Optional relevant components that may add nuances in particular circumstances are included • Atomic Concept Definition Templates are designed to be reusable in many different contexts • CEN defines Archetypes as atomic concept definitions formally approved by recognized clinical bodies • The stereotypical example is Blood Pressure, composed of 2 numerical measures with optional additional information about patient positioning, cuff size, etc.

  8. Aggregate Measures Templates • A template applied to an observation with multiple components that constrains the content and relationship of components • Constraints may be to optionality or to valid value ranges or coded value sets • Application of constraints may be conditional depending on values in other components • HL7 balloted static models have the information structures that can describe these component relationships, but to define a specific named set that can be referenced consistently would be a template

  9. Computed Measures Templates • A template applied to an observation that has multiple components. • The constraints apply to the content and relationships of the components, but also describes the computational algorithm that derives a computed measure from the component measures • An APGAR score is an example

  10. “Assembly” Templates • HL7 Templates applied to an “organizer” level of a static model that defines the content of components for a particular purpose • Constraints can be any structural or non structural variety and may reference other templates • In effect, the “Assembly” constraints are the sum total of all the constraints expressed in referenced templates plus any associated with the “Assembly” as a whole

  11. Why do we need HL7 Templates • Health Information is fractal • Information is being electronically recorded with widely varying content • Clinical information standards need to be defined by Clinicians • The estimated number of “purpose specific” clinical information standards needed is daunting

  12. Health Information is fractal • a single topic of interest has information that ranges from general to specific • How general or how specific a topic of information needs to be varies depending on the expected use of the information • Humans are very adept at adjusting to the level of specificity as the use of information changes • Computers require very explicit context and instructions to adapt to changes in information use • Information recorded in very specific detail can be accurately transformed to more general levels of detail • Information recorded at a general level of detail cannot be used for purposes requiring more specific details

  13. Varying Information Structure and Content • Health Information is currently being recorded with widely varying levels of detail and structure • Only structured information can be individually retrieved from electronic storage • Structured information may be interpretable by computers or only expected to be interpreted by humans • Different strategies of recording information limits the degree to which the information can be safely retrieved and interpreted outside the original context of recording • Encoded information must be understood within the context of both content (the specific code scheme) and structure (the information model) • Recorded information can be interpreted safely only if both the meaning and the format are managed explicitly • Different approaches to recording information can be interpreted as equivalent if they are indexed to common concepts

  14. Clinical information standards need to be defined by Clinicians • Clinical information standards are more than standardized classifications, vocabularies and nomenclatures • Clinical information standards need to be determined based on how information is expected to be recorded AND on how information is intended to be used for clinical decisions • Different clinical specialties will define the same topic using different language that reflects the degree of specificity required for their purposes • Information sharing within specialties require different emphasis and specificity than information sharing between specialties

  15. Sheer Number of Needed Purpose Specific Information Standards • Existing V3 Ballot has hundreds of static models • Balloted Static Models include RMIMs, CMETS, Message Types • These Static Models lay the foundation for information exchange • Even the most specific types of static models intended for specific operational processes may need to be further constrained in implementations • Managing customized implementations is exceeds manual management strategies • The Health System needs a way of easily determining the scope and degree of interoperability of information structure and content to be successful

  16. How can HL7 Templates be Used? • Point of Care System - sending • During data entry to ensure only conformant data is recorded • During data assembly to ensure data are appropriate to a particular document or message • Integration Services • During configuration for new types of documents or messages • Verifying compliance when new applications are included • Point of Care System (and EHRS) - receiving • validation for further processing and indexing for storage • Knowledge Representation and Heuristic Reasoning • while this is the end stage goal, the level of formal language to express and then computationally validate is still in the R&D stage

  17. How are Templates Created? • Different approaches have been used • A static model derived from a balloted static model using the HL7 Design tools • limited to structural constraints • further constraints recorded as text • Derive and then hand refine a static model schema - VIHA • relies on human judgment to ensure derived model validity • used Schematron to validate business rules • New tools that start with a balloted static model and add constraints . . . prototype available – see MIFCDACCR.pdf • HL7 Tooling committee has template authoring on it’s high priority list – currently not resourced • NIST HL7 Registry available to register prototypes – International Affiliates and early adopter projects are welcome to use http://hcxw2k1.nist.gov:8080/hl7services/index.jsp

  18. What does a template look like? • Look in the May 2005 V3 • As a V3 model • See Genomics RMIM • In a schema • see Clinical Document Architecture RMIM XSD • In an instance • next slide

  19. Template Instance Example – constraint on CDA

  20. Technical Details • Templates artifact ids are in a data-type ii which is an root which must be a registered OID or a GUID and a string extension. The extension string should be the parent artifact id, and if a constraint on a subset of the balloted model, append the root class name. • Example = system generated UUID followed by POCD_MT000030.InformationRecipient would be the artifact id of a Template constraining the CDA Information Recipient Class Clone • An instance would reference this identifier in the XML attribute Template Id of the Class in question. • See Charlie McCay’s example

  21. Current Status of Template Architecture at HL7 • A single document was offered in the Dec 2004 ballot at committee level and passed with comments • Contents were generally approved but agreement to harmonize with other HL7 V3 documents meant changes were sufficiently significant that another committee ballot is required. • Sufficient work needed to be done that it is not included in the May 2005 Ballot cycle • Anticipate the summer ballot cycle will see a revised section in the ballot package that is more focused and aligned with other portions of the HL7 methodology

  22. Conclusions and Recommendations • Templates are still under development at HL7 but necessary core has stabilized • Much attention and work-in-progress is occurring globally • Infoway doesn’t have to wait to take advantage of the template strategy • There are no alternative strategies apparent that will meet the needs to manage complexity of information structure and content standards

More Related