HL7/ Implementation Guide (US Realm) Draft Standard for Trial Use September 2013 Publication of this draft standard for trial use and comment has been approved by Health Level Seven International (HL7). This draft standard is not an accredited American National Standard. The comment period for use of this draft standard shall end 24 months from the date of publication. Suggestions for revision should be submitted at http://www.hl7.org/dstucomments/index.cfm. Following this 24 month evaluation period, this draft standard, revised as necessary, will be submitted to a normative ballot in preparation for approval by ANSI as an American National Standard. Implementations of this draft standard shall be viable throughout the normative ballot process and for up to six months after publication of the relevant normative standard. Copyright 2013 Health Level Seven International ALL RIGHTS RESERVED. The reproduction of this material in any form is strictly forbidden without the written permission of the publisher. HL7 International and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.
IMPORTANT NOTES: A. If you are the individual that downloaded or ordered this HL7 Standard, specification or other work (in each and every instance "Material"), the following describes the permitted uses of the Material. B. If you are NOT such individual, you are not authorized to make any use of the Material. To obtain an authorized copy of this Material, please visit http://www.hl7.org/implement/standards/index.cfm. C. If you are not an HL7 Organizational Member, the following are your permitted uses of this Material: 1. Read and Copy License Only. HL7 hereby grants you the right, without charge, to download and copy (for personal use only) this Material for study purposes only. This license grant does not include the right to sublicense or modify the Material, or to implement the Material, either in whole in part, in any product or service. Please see http://www.hl7.org/legal/ippolicy.cfm for the full license terms governing the Material. D. If you are an HL7 Organizational Member, the following are your permitted uses of this Material. 1. Implementation License Terms. 1.1 Definitions. As used in this Agreement, the following terms shall have the following definitions: "Compliant Product" is a product or service that implements Material that is an HL7 Specification in whole or in part. "End User" is a company, entity or individual that is the ultimate purchaser or licensee from Licensee of a Compliant Product. 1.2 License. In consideration of becoming an Organizational member of HL7 and continuing to pay the appropriate HL7 Organizational membership fees in full, HL7 hereby grants to you without additional charge, on a perpetual (except as provided for in the full license terms governing the Material), non-exclusive and worldwide basis, the right to (a) download, copy (for internal purposes only) and share this Material with your employees and consultants for study purposes, and (b) utilize the Material for the purpose of developing, making, having made, using, marketing, importing, offering to sell or license, and selling or licensing, and to otherwise distribute, Compliant Products, in all cases subject to the conditions set forth in this Agreement and any relevant patent and other intellectual property rights of third parties (which may include members of HL7). No other license, sublicense, or other rights of any kind are granted under this Agreement. Please see http://www.hl7.org/legal/ippolicy.cfm for the full license terms governing the Material. Page 2 HL7/ Implementation Guide 2013 Health Level Seven, Inc. All rights reserved. September 2013
Primary Co- Chair: Brett Marquard River Rock Associates brett@riverrockassociates.com Primary Co- Chair: Calvin Beebe Mayo Clinic cbeebe@mayo.edu Primary Co- Chair Ted Klein ted@tklein.com Primary Co- Chair Rob Hausam rrhausam@gmail.com Primary Government Sponsor Nancy Orvis DoD/TRICARE Management Activity nancy.orvis@tma.osd.mil Primary Government Sponsor Patricia Greim DoD/Dept. of Veterans Affairs patricia.greim@va.gov Primary Author Erik Pupo Deloitte Consulting LLP erpupo@deloitte.com Primary Author Russell Ott Deloitte Consulting LLP rott@deloitte.com HL7/ Implementation Guide Page 3 September 2013 2013 Health Level Seven, Inc. All rights reserved.
Acknowledgments This guide was produced and developed through the joint efforts of the Department of Defense (DOD) and Department of Veterans Affairs (VA) The co-editors appreciate the support and sponsorship of the HL7 Structured Documents Working Group (SDWG) and the HL7 Vocabulary Working Group. This material contains content from SNOMED CT (http://www.ihtsdo.org/snomed-ct/). SNOMED CT is a registered trademark of the International Health Terminology Standard Development Organisation (IHTSDO). This material contains content from LOINC (http://loinc.org). The LOINC table, LOINC codes, and LOINC panels and forms file are copyright 1995-2012, Regenstrief Institute, Inc. and the Logical Observation Identifiers Names and Codes (LOINC) Committee and available at no cost under the license at http://loinc.org/terms-of-use. Page 4 HL7/ Implementation Guide 2013 Health Level Seven, Inc. All rights reserved. September 2013
Table of Contents 1 INTRODUCTION... 11 1.1 Audience... 11 1.2 Purpose... 11 1.2.1 Problem Statement... 12 1.2.2 Value Proposition for Interoperability... 13 1.3 Scope... 13 1.4 Proposed Development Lifecycle... 15 1.4.1 Proposed Stakeholders for Development... 16 1.5 Organization of This Guide... 16 1.6 Conformance Conventions Used in This Guide... 17 1.7 to Readers... 18 1.7.1 Use of Local LOINC Codes and Names... 19 1.8 Content of the Package... 19 2 GENERAL ONTOLOGY STRUCTURE... 20 2.1 Technical Approach... 20 2.1.1 Ontological Approach... 20 2.1.2 Metadata and Query Approach... 21 2.1.3 Ontology Extensions... 22 2.1.4 Ontological Models... 22 2.2 Technical Structure... 22 2.2.1 Identifiers and Terms... 23 2.2.2 Structure of Ontology... 23 2.2.3 Structure of Clinical Document Name... 23 3 DOCUMENT ONTOLOGY... 24 3.1 Domain... 25 3.1.1 Allergy and Immunology... 25 3.1.2 Anesthesiology... 25 3.1.3 Audiology... 26 3.1.4 Cardiology... 26 3.1.5 Chiropractic Medicine... 26 3.1.6 Critical Care Medicine... 26 3.1.7 Dentistry... 26 3.1.8 Dermatology... 26 3.1.9 Diabetology... 27 HL7/ Implementation Guide Page 5 September 2013 2013 Health Level Seven, Inc. All rights reserved.
3.1.10 Emergency Medicine... 27 3.1.11 Endocrinology... 27 3.1.12 Family Practice... 27 3.1.13 General Medicine... 28 3.1.14 Internal Medicine... 28 3.1.15 Medical Genetics... 30 3.1.16 Mental Health... 31 3.1.17 Multi-specialty Program... 31 3.1.18 Neurological Surgery... 31 3.1.19 Neurology... 32 3.1.20 Nuclear Medicine... 32 3.1.21 Nutrition and Dietetics... 32 3.1.22 Obstetrics and Gynecology... 32 3.1.23 Occupational Health... 33 3.1.24 Occupational Therapy... 33 3.1.25 Oncology... 33 3.1.26 Ophthalmology... 33 3.1.27 Optometry... 33 3.1.28 Oral Surgery... 34 3.1.29 Orthopedic Surgery... 34 3.1.30 Otolaryngology... 34 3.1.31 Pastoral Care... 34 3.1.32 Pathology... 34 3.1.33 Pediatrics... 35 3.1.34 Pharmacy... 38 3.1.35 Physical Medicine and Rehabilitation... 38 3.1.36 Physical Therapy... 39 3.1.37 Plastic Surgery... 39 3.1.38 Podiatry... 39 3.1.39 Primary Care... 40 3.1.40 Radiology... 40 3.1.41 Recreational Therapy... 40 3.1.42 Research... 40 3.1.43 Respiratory Therapy... 41 3.1.44 Rheumatology... 41 3.1.45 Social Work... 41 Page 6 HL7/ Implementation Guide 2013 Health Level Seven, Inc. All rights reserved. September 2013
3.1.46 Speech Pathology... 41 3.1.47 Surgery... 41 3.1.48 Urology... 42 3.2 Type of Note (Kind of Document)... 43 3.2.1 Administrative note... 43 3.2.2 Advance directive... 47 3.2.3 Consultation Note... 47 3.2.4 Correspondence... 48 3.2.5 Counseling Note... 48 3.2.6 Diagram... 48 3.2.7 Education Note... 49 3.2.8 Encounter Note... 49 3.2.9 Form... 50 3.2.10 Letter... 50 3.2.11 Note... 50 3.2.12 Report... 50 3.2.13 Public Health Document... 50 3.2.14 Restraint Note... 51 3.2.15 Referral Note... 51 3.3 Role... 51 3.3.1 Assistant... 51 3.3.2 Case Manager... 52 3.3.3 Clerical... 52 3.3.4 Counselor... 52 3.3.5 Hygienist... 52 3.3.6 Interdisciplinary... 52 3.3.7 Medical Assistant... 52 3.3.8 Nurse... 53 3.3.9 Patient... 54 3.3.10 Physician... 54 3.3.11 Student... 55 3.3.12 Technician... 56 3.3.13 Therapist... 56 3.4 Type of Setting... 56 3.4.1 Ambulance Transport... 57 3.4.2 Birthing Center... 57 HL7/ Implementation Guide Page 7 September 2013 2013 Health Level Seven, Inc. All rights reserved.
3.4.3 Emergency Department... 57 3.4.4 Home Health... 57 3.4.5 Hospital... 58 3.4.6 Inpatient Hospital... 58 3.4.7 Intensive Care Unit... 58 3.4.8 Long Term Care Facility... 58 3.4.9 Outpatient... 59 3.4.10 Rehabilitation Hospital... 60 3.4.11 Telehealth... 60 3.4.12 Telephone Encounter... 60 3.5 Type of Care Provided (Service)... 60 3.5.1 Communication... 61 3.5.2 Conference... 61 3.5.3 Consultation... 61 3.5.4 Individual Counseling... 61 3.5.5 Group Counseling... 61 3.5.6 Diagnostic Study... 62 3.5.7 Education... 62 3.5.8 Evaluation and Management... 63 3.5.9 Evaluation and Management of a Specific Problem... 64 3.5.10 Disability Examination... 65 3.5.11 Exercise Testing... 81 3.5.12 Medication Management... 81 3.5.13 Procedure... 81 3.5.14 Referral... 82 3.5.15 Respite... 82 3.5.16 Supervisory Direction... 82 3.5.17 Triage... 83 3.6 Proposed... 83 4 IMPLEMENTATION OF THE ONTOLOGY... 106 4.1 Implementation Basics... 106 4.2 Summary of Conformance Statements... 106 4.3 Using the Ontology... 106 4.3.1 Example of LOINC Ontology Usage... 107 4.3.2 Use of Metadata for implementation... 108 4.4 Reuse of Existing Taxonomies... 108 Page 8 HL7/ Implementation Guide 2013 Health Level Seven, Inc. All rights reserved. September 2013
4.4.1 LOINC... 108 4.4.2 HL7... 109 4.4.3 ABMS... 109 4.4.4 NUCC... 110 4.4.5 SNOMED-CT... 110 4.5 Implementation Approaches for Document Type Representation... 110 4.5.1 XML Representation... 110 4.5.2 RDF Representation... 111 4.5.3 JSON Representation... 111 4.6 Implementation Approaches to Queries... 111 4.6.1 Use of Existing Metadata Registries... 111 4.6.2 Use of XD* Metadata... 112 4.6.3 Use of FHIR and REST... 112 5 PROPOSED USE CASES FOR IMPLEMENTATION... 114 5.1 Query using RESTful API... 114 5.2 Query Examples using IHE XD*... 114 5.2.1 Querying within the Domain of Implementation... 114 5.2.2 Querying using the Document Type... 114 5.2.3 Querying using the Role... 114 5.2.4 Querying using the Care Setting... 114 5.2.5 Querying using the Type of Service Provided... 114 5.3 Querying Remote Registries or Repositories... 114 5.4 Vocabulary Considerations for SNOMED-CT... 115 5.4.1 Populate value sets for individual dimensions... 115 5.4.2 Generate full (combinatorial) ontology... 115 5.4.3 Map legacy LOINC codes into new ontology... 115 5.5 Long Term Implementation Considerations... 115 6 VALUE SET MAPPING TO ONTOLOGY... 116 7 REFERENCES... 117 APPENDIX A ACRONYMS AND ABBREVIATIONS... 118 APPENDIX B CHANGE HISTORY ON ONTOLOGY... 120 APPENDIX C - CONFORMANCE VERBS... 121 APPENDIX D - EXTENSIONS TO LOINC DOCUMENT ONTOLOGY... 123 HL7/ Implementation Guide Page 9 September 2013 2013 Health Level Seven, Inc. All rights reserved.
Table of Figures No table of figures entries found. Table of Tables Table 1 Implementation Guide Lifecycle... 16 Table 2 Stakeholders for... 16 Table 3 Package for Implementation Guide... 19 Table 4 Structure of... 25 Table 6 Proposed LOINC Clinical Document Types... 83 Table 7 Mapping to IHE XD* Metadata... 112 Page 10 HL7/ Implementation Guide 2013 Health Level Seven, Inc. All rights reserved. September 2013
1 I N T R O D U C T I O N The purpose for this implementation guide is to define a LOINC Taxonomy for clinical documents that are most commonly used by the Department of Defense (DOD) and the Department of Veterans Affairs as a foundation for the development of a taxonomy of clinical document types. This ontology is a conceptual and implementable structure of how clinical documents should be arranged and available for access. Consistent with the vision of a healthcare learning system, the need for a document taxonomy has become acute as health information exchange and interoperability requirements dictate an increased level of data liquidity. To support the need for increased information exchange, some level of classification is needed to identify all possible resources. The DOD and VA wish to develop an implementation guide that will detail the taxonomy for developers, and will also include implementation guidance to facilitate queries and retrieval of clinical documents and notes by clinicians and administrative or financial staff. The acute need for an ontology of this nature has become apparent with the challenges inherent to establishing interoperability between the DOD and VA medical systems. For example, VA physicians have expressed increasing frustration with searching through hundreds of irregularly structured document titles in the Computerized Patient Record System (CPRS) in Veterans Affairs (VA) medical centers. 1.1 Audience The audiences for this implementation guide are the architects and developers of healthcare information technology (HIT) systems in the US Realm that exchange patient clinical data. Business analysts and policy managers can also benefit from an understanding of the ontology documented in this implementation guide, as it applies to multliple implementation scenarios for use of an ontology of this type. 1.2 Purpose The primary purpose of this implementation guide is to establish the LOINC Clinical Document Ontology is to establish the ontology as a standard for the representation of clinical document types, and to provide implementation guidance for using the LOINC Clinical Document Ontology within other interoperability standards, specifically HL7 document and messaging standards. A primary question that arises in this implementation guide is why is an implementation guide needed in support of an existing ontology? While the initial driver for standardization of the is the DOD and VA, the expected downstream benefits of pursuing this implementation The purpose of this implementation guide is to support two implementation purposes: HL7/ Implementation Guide Page 11 September 2013 2013 Health Level Seven, Inc. All rights reserved.
Ability to search for specific clinical document types using a common taxonomy of clinical document names. The specific need for the taxonomy is to provide semantics for names of clinical documents that are exchanged between health information technology (HIT) systems Ability to use metadata in association with a clinical document that can be leveraged to locate specific clinical document types. NOTE: this implementation guide does not establish a specific query mechanism for implementers but defines metadata and the methodology for accessing that metadata. This ensures a generic implementation framework that can be applied to specific implementation environments. The implementation guide format used here is meant to serve as the documented baseline to be used going forward in maintaining a national standard for all clinical document types. A supporting set of modeling files will be creating using OWL to show the ontological structure and to provide as a formal model for systems to use in implementing the ontology. 1.2.1 Problem Statement While much of the existing content and transport mechanisms for health interoperability have started to take shape or already exist, there are still gaps in standards to support interoperability. Many of these gaps are diligently being worked through both standards development organizations (SDOs) as well as those organizations responsible for managing controlled terminologies. However, the need for an overarching, high level index of interoperability has not yet been achieved as a formal standard to guide interoperability efforts. Standards and profiles have been developed based on the premise of being able to find and retrieve all types of clinical data, without any one standard being specified for how to conduct that search. The concept of a Google for healthcare information interoperability is an elusive goal, but the idea of an index to serve as the initial standard for finding clinical data is a realstic goal in the short and long term. The has already been established as an ontological representation of clinical data, that serves as a valuable baseline for locating clinical data. The other challenge is while the LOINC Clinical Document Ontology already exists to serve in the role of a high level index of clinical data, no standard has been specified by any current SDO or other organization to serve as the index. Standards such as CDA R3 have been specified as critical for meaningful use yet these interoperability standards are reliant on LOINC codes that have not been formally introduced as a standard for interoperability. This could potentially lead to a larger problem as health information is structured, but is structured in an increasingly disparate fashion using local LOINC codes, or other controlled terminologies that cannot be mapped to the LOINC Clinical Document Ontology. It would also lead to challenges for patients, who may lack the level of depth to search for clinical data and would need some standard to guide them for what to search for. It is inherent throughout this implementation guide that the LOINC Clinical Document Ontology is seen as the possible standard to use for querying and retrieving data based on a clinical document type value. Many questions arise as to if the standard already Page 12 HL7/ Implementation Guide 2013 Health Level Seven, Inc. All rights reserved. September 2013
exists, or the ontology is already documented in a tool such as RELMA, why is an implementation guide needed? Another problem statement this implementation guide seeks to address is exactly that challenge that while an ontology exists, it is not documented to the level needed to support widespread implementation. 1.2.2 Value Proposition for Interoperability The primary driver for an implementatiuon guide to represent the LOINC Clinical Document Ontology is the need to establish a formal ontological standard that can be used for future interoperability projects that organizations such as HL7 would pursue. An implementation guide of this type would be used in multiple clinical and administrative contexts and would have broad reach across other standards used in the implementation of interoperable healthcare solutions, including those established within HL7. Several examples of existing interoperability challenges exist where a clinical document ontology would be crucial: Because clinical decision support services are driven by the need to both collect information to generate alerts and guidelines, and the need to output these alerts and guidelines in a standarsdized format, the use of clinical document types would help a decision support service (DSS) to be able to locate and retrieve the crucial information needed to provide alerts and guidelines at the point of care Another area of focus would be quality measurement, where the use of clinical document types can be used to support the assembly of the data elements needed to populate clinical quality measures. Further focus is concentrated on the administrative domain of healthcare, where the need to use document types that may not be clinical in nature (specifically to support patient registration and enrollment activities, as well as eligiblity checks) require an ontology to support administrative domains to locate information This implementation guide does not prescribe specific implementation vehicles for the (although examples are included within this implementation guide) as a certain degree of flexibility will be necessary to ensure that initial piloting and testing efforts of the can be supported. 1.3 Scope The scope of this implementation guide will be driven by unique constraints that are not always prevalent in existing standards or implementation guides. Thus, scope is an important tangible in developing this implementation guide, to ensure that what is being proposed as a standard to HL7 and to Regenstrief reuses existing work done to date while being constrained to the specific need that the LOINC Clinical Document Ontology is being proposed for. The scope of this implementation guide is to document an ontology that defines clinical document types for the following functions: Searching for specific document types using a defined ontological structure Defining the metadata attributes that can be used to search the LOINC Document Ontology HL7/ Implementation Guide Page 13 September 2013 2013 Health Level Seven, Inc. All rights reserved.
Establishing a formal mechanism through Regenstrief (and HL7) to accept extensions to the, and to promote reuse of the by standards development organizations. The scope of implementation recognizes that previous work has already been developed in this area, specifically the work of the HL7/LOINC Document Ontology Task Force and the current, and this work serves as an important driver and guidepost for all existing efforts. Additional guidance is provided in support of implementing the ontology utilizing a variety of approaches: Using generic metadata guidance to implement the traversing of the LOINC Clinical Document Ontology Providing implementation approaches to query documents that address the same or related problem in order for determination to be made while increasing specificity to short determination time. Providing a formal and recognized channel for all stakeholders in health information technology and healthcare to follow for submission of LOINC Document Ontology terms that are needed to expand the depth of the ontology To test the scope of the implementation guide, further work was done to propose harmonization of local LOINC codes that are used within the United States Department of Veterans Affairs (VA) to the, which are included as part of this implementation guide. This ontology is also scoped to support descriptions of clinical documents and the hierarchy used to describe clinical document types, that will essentially produce the elements of the as already defined within tools such as RELMA. This serves several important objectives: Identify important concepts that should be expressed in an ontology Establish standardized names for those concepts to be evaluated and searchable Give those concepts clear, precise textual definitions drawn from existing sources and subject to stringent peer review Constitute an authoritative ontology, with concepts that are: o Formally and unambiguously defined (to the extent practical) and expressed in a language such as OWL o Classified in a well-organized taxonomy (class hierarchy). o Connected in meaningful relationships to be used for search and query o Mutually consistent across any possible representation to eliminate ambiguity Support consistent and effective Healthcare IT software implementations, thus: o Providing a sound basis for convenient, interoperable specification of clinical document types, which: stable over time). possible. Page 14 HL7/ Implementation Guide 2013 Health Level Seven, Inc. All rights reserved. September 2013
o Achieving sound clinical decisions. Inform other work within HL7 workgroups Other Healthcare IT terminologies such as SNOMED CT and the HL7 vocabularies, as appropriate, may have additional mappings that need to be tied back to LOINC, and these are determined to NOT be in scope for this implementation guide. Additional scope limitations which have been noted include the following: Aspects of HIPAA must be incorporated into the ontology to ensure that it does not violate any existing regulatory language. The implementation guide will be reviewed with members of the HL7 Security Workgroup to ensure that HIPAA constraints are appropriately addressed, and guidance from HL7 experts is provided. The LOINC Document Ontology proposes support for those document types that would cover legal aspects of medical care, such as advance directives. However, the scope of this implementation guide does NOT cover aspects of what constitutes a legal clinical document. Combinations that would define a letter (such as a letter provided by a primary care physician operating in the DOD care setting to a specialist operating in the VA care setting) References that do not serve as a formal clinical document type, such as library resources, patient education material, clinical practice guidelines, and prescription drug package inserts. 1.4 Proposed Development Lifecycle The proposed development timeline for this ontology will occur in multiple phases to support ongoing requirements and dependencies that are occurring Phase 1 Initial development of the implementation guide Phase 2 Development of the ontology using OWL (Protégé) Phase 3 Broad stakeholder review of the ontology Phase 4 Propose structural enhancements to LOINC if ontology implementation indicates need The initial development of the implementation guide is focused on using the LOINC Clinical Document Ontology as a base implementation of clinical document types for location and retrieval of clinical documents Once the ontology is in development through HL7 and LOINC, additional work will be done to also model the ontology using OWL. This model will be developed to support implementation of the ontology within a wide variety of infrastructures The development of the implementation guide will initially be targeted for pilot implementation within the DOD and VA, but will require broader review from HL7 and LOINC, as well as other stakeholders involved in interoperability efforts. During this review, further pilot efforts will be identified and a thorough review cycle will be scheduled with key experts within HL7 workgroups and with leaders within Regenstrief. Based on the pilot implementation process that is proposed, additional enhancements may then be needed to the actual structure of the LOINC Clinical Document Ontology, to include recommended changes to be passed to Regenstrief for consideration at future LOINC meetings for how the LOINC Clinical Document Ontology may require modification HL7/ Implementation Guide Page 15 September 2013 2013 Health Level Seven, Inc. All rights reserved.
Table 1 Implementation Guide Lifecycle 1.4.1 Proposed Stakeholders for Development In order to make an implementation guide for an ontology successful, the need to identify and respond to the needs of key stakeholders is absolutely critical. The concept of making an ontology into an implementation guide is a serious challenge that requires broad review to ensure it is designed correctly. This implementation guide will be an ongoing effort and guide development is anticipated to be closely coordinated with the following groups: HL7 Structured Documents Working Group HL7 Vocabulary Working Group LOINC (Document Ontology Workgroup) and Regenstrief The HL7 Structured Documents Workgroup is the primary mechanism for development of the implementation guide and serves as the main body for initial review and improvement. This body of experts is needed to evaluate the usefulness of an ontology implementation guide and the best way to represent such an ontology within a format that can be acceptable as a nationally adopted standard The HL7 Vocabulary Workgroup provides additional support and expertise to the implementation guide development and review, as well as a forum for any proposed vocabulary harmonization proposals that may be necessary. LOINC is expected to support the development of the implementation guide with an additional group of subject matter experts, and with the additonal engagement on the implementation guide as the primary owner of the Clinical Document Ontology upon which the implementation guide is based. It is important to note that within the hierarchy of stakeholders involved with the LOINC Clinical Document Ontology, Regenstrief serves as the primary body for adjudication and ownership of the ontology that this implementation guide is based on. Table 2 Stakeholders for 1.5 Organization of This Guide This guide includes a set of implementation building blocks and the formal ontology for use of a set of specific clinical document types (formally referred to throughout as the ) The main chapters are: Page 16 HL7/ Implementation Guide 2013 Health Level Seven, Inc. All rights reserved. September 2013
Chapter 2. General Ontology Structure. This chapter defines the structure and technical approach for use and implementation of the LOINC Clinical Document Ontology Chapter 3. Document Ontology. This chapter defines each of the axes of the. It also defines specific constraints for implementation as a list of clinical document types that the ontology would support Chapter 4. Implementation of the Ontology. This chapter defines the implementation approaches that are defined in this implementation guide for using clinical document types for the querying and retrieval of information Chapter 5. Proposed Use Cases for Implementation. This chapter defines specific use cases for piloting and validing implementation of clinical document types as a mechanism for the querying and retrieval of information shown in Section 5.1 as Query Examples, with a set of query examples that show the use of the to specify both a type and supporting metadata to locate and retrieve patient and administrative information Appendices - The Appendices include non-normative content to support implementers of the. It includes a Change Appendix summary of previous and updated clinical document types 1.6 Conformance Conventions Used in This Guide Expectations related to conformance for the LOINC Document Ontology will differ from other HL7 standards. The specific conformance language proposed in this implementation guide would provide much looser levels of constraint as implementation of the ontology would be expected to occur in other interoperability standards. For example, a CDA implementation guide focused on newborn screening would constrain document templates to a certain coded value within the LOINC Clinical Document Ontology. General conformance statements for this ontology include the following: A conformant system SHALL encode clinical document types. A conformant system SHOULD assign metadata in accordance with organizational-specific policy A conformant system SHOULD process, manage, and retrieve metadata associated with clinical document types as expressed in the LOINC Clinical Document Ontology A conformant system SHALL rely on the for the definitions and relationships of the terms and concepts that are necessary for making access control decisions. (Note that the HL7 RBAC Healthcare Permission Catalog is authoritative for definitions of terms and concepts specified therein; the HL7 Security and Privacy Ontology reproduces those definitions verbatim, defines additional terms and concepts, and adds relationships, especially hierarchical relationships among concepts.) This conformance criterion MAY encompass all access control system components, including the following: HL7/ Implementation Guide Page 17 September 2013 2013 Health Level Seven, Inc. All rights reserved.
A conformant access control system policy administration point SHALL invoke HL7 Security and Privacy Ontology terminology services to support encoding and retrieval of applicable policies for a conformant access control system policy administration point. b. A conformant access control system policy information point SHALL invoke HL7 Security and Privacy Ontology terminology services to support retrieval of applicable initiator, resource, context, and request access control decision information needed to generate an access control decision. c. A conformant access control system policy decision point SHALL invoke HL7 Security and Privacy Ontology terminology services to support access control decisions. d. A conformant access control system policy enforcement point SHALL invoke HL7 Security and Privacy Ontology terminology services to support access control enforcement within the custodian enterprise, in transit and in intermediary systems, and in end user clients. HL7 Security and Privacy Ontology terminology services SHOULD be invoked by means of HL7 Common Terminology Services 2 (CTS2) (5), or another suitable service implementation for accessing the ontology content, such as a service supporting the OWL API (http://owlapi.sourceforge.net/). HL7 Security and Privacy Ontology terminology services SHALL be invoked directly at run time, e.g., while making access control decisions, or at build time, e.g., to suitably populate whatever data store the access control system or other application prefers to use internally. 1.7 to Readers This document is primary; the formal OWL representation of the ontology is secondary in the sense that this document will prevail in case of inadvertent conflict. Nonetheless, the intent is to produce a single shared ontology for use across the HL7 constituency. While this document serves to introduce, motivate and explain the LOINC Document Ontology, the inherent limitations of linear text make it impossible to fully convey the richly interconnected, formal logic-based nature of the ontology itself. Examples in this document and/or the ontology are not considered normative. The definition of an ontology used in this guide are: In the context of computer and information sciences, an ontology defines a set of representational primitives with which to model a domain of knowledge or discourse. The representational primitives are typically classes (or sets), attributes (or properties), and relationships (or relations among class members). The definitions of the representational primitives include information about their meaning and constraints on their logically consistent application. In the context of database systems, ontology can be viewed as a level of abstraction of data models, analogous to hierarchical and relational models, but intended for modeling knowledge about individuals, their attributes, and their relationships to other individuals. Ontologies are typically specified in languages that allow abstraction away from data structures and implementation strategies; in practice, the languages of ontologies are closer in expressive power to first-order logic than languages used to model databases. For this reason, ontologies are said to be at the "semantic" level, whereas database schema are models of data at the Page 18 HL7/ Implementation Guide 2013 Health Level Seven, Inc. All rights reserved. September 2013
"logical" or "physical" level. Due to their independence from lower level data models, ontologies are used for integrating heterogeneous databases, enabling interoperability among disparate systems, and specifying interfaces to independent, knowledge-based services. In the technology stack of the Semantic Web standards, ontologies are called out as an explicit layer. There are now standard languages and a variety of commercial and open source tools for creating and working with ontologies. 1.7.1 Use of Local LOINC Codes and Names One of the largest challenges in building an implementation guide for the LOINC Document Ontology is recognizing the need to support a large number of LOINC clinical document types that would be designated at the local/organizational level. The use of local codes and names would be discouraged but not forbidden based on the text defined in this document. There is no specific implementation path by which HL7 or any other organization can specifically force conformance. 1.8 Content of the Package The following files have been included in this implementation guide initial release Filename Standards Applicability HL7 Implementation Guide Word Main guide for review Table 3 Package for Implementation Guide HL7/ Implementation Guide Page 19 September 2013 2013 Health Level Seven, Inc. All rights reserved.
2 G E N E R A L O N T O L O G Y S T R U CTU R E The LOINC Document Ontology structure is based on the current LOINC Clinical Document Ontology (CDO). There are several aspects to the ontology that are documented within this implementation guide section, specifically: The technical approach used in the creation of this implementation guide how was the ontology documented The technical structure of the ontology, as directly drawn from the current approach 2.1 Technical Approach The principles behind balloting the current LOINC Document Ontology as a standard are as follows: Increase discrimination by providing greater detail regarding document type definition within an implementation guide Associate each document type with metadata that would be useful in a query Allow (but not require) specification of additional detail than what is currently part of the Encourage query by property/metadata rather than query by LOINC number to broaden use of clinical document types as a method for querying clinical data Fully define properties to support document query API Improve guidance on how to classify documents and define new document types Improve descriptions and separate overloaded axis Harmonize property value sets with reference terminologies and extended hierarchy Revise document type hierarchy to reflect subsumption Map DoD and VA documents based on criteria to identify comparable documents. Use the axis value sets from the LOINC User Guide. The technical approach proposed in this implementation guide has several parts needed for implementation: Documentation of the current as-is Documentation of the use of metadata to support queries of clinical document types defined in the Mechanisms for extending the within the parameters of the current Regesntrief processes 2.1.1 Ontological Approach Page 20 HL7/ Implementation Guide 2013 Health Level Seven, Inc. All rights reserved. September 2013
In this approach, the LOINC Document Ontology becomes a value set of document types, similar to constrained value sets of document types. All subsequent value sets that are created would use this base implementation guide to support implementation For example, HITSP C80 includes a specific value set for document types (2.16.840.1.113883.3.88.12.80.47 ) constrained specifically for HITSP s puposes, and used in conjunction with an XDS affinity domain. This approach to constraining an ontology is the expected path for implementation of the LOINC Clinicial Document Ontology, where the ontology serves as the source terminology for all future document types, and is managed primarily by Regenstrief with expert input from HL7. Eventual implementation through HL7 is proposed to allow for the integration of the LOINC Document Ontology directly into existing HL7 standards. For example, it would be expected that conformance requirements going forward for HL7 standards and implementation guides would include the following conformance statements: These conformance statements would be developed in coordination with the HL7 Technical Standards Committee and the HL7 Structured Documents Working Group, with significant input and discussion welcome from all HL7 stakeholder bodies 2.1.2 Metadata and Query Approach The primary purpose in developing this implementation guide would be to use the LOINC document ontology as a tool to locate and query for clinical documents and other forms of documented data (such as an image or a general artifact). The implementation of the ontology and associated metadata is an important piece to driving forward with implementation of the. The document ontology does not include the scope of the following: Use of specific metadata associated with a specific approach for using clinical document types. This implementation guide DOES NOT mandate specific conformance with a specific approach for associating metadata with LOINC codes. Definition of specific query mechanisms to use in association with a specific clinical document type. Again, this implementation guide DOES NOT mandate speciifc approaches for querying and retrieving clinical documents. Instead, the approach for metadata and querying of metadata is to define the following: Allow for specification of additional detail to query for clinical document types, but DO NOT require a specific query mechanism or specific required metadata attributes Support query mechanisms that allow for query by specific LOINC properties or metadata associated with a LOINC clinical document type rather than query by specific LOINC codes. Support additional metadata to be associated with each clinical document type that is outside the scope of the ontology and can be defined by the implementer HL7/ Implementation Guide Page 21 September 2013 2013 Health Level Seven, Inc. All rights reserved.
2.1.3 Ontology Extensions The design of the LOINC Document Ontology is focused on establishing a baseline for all clinical document types specific to information exchange. While this is a worthy outcome, it is well recognized that not all clinical document types would be documented in an initial ontology that is the subject of an implementation guide. It is also not appropriate to include a specific process or approach within an implementation guide for the management of an underlyhing standard. Consequently, a specific sub-ontology can easily be extended and/or further constrained by importing it into a corresponding new sub-ontology, then adding more classes and/or OWL restrictions involving imported classes. Moreover, specific subontologies can be replaced. For example, a national realm might choose to standardize on a different set of clinical document types. It is thus recognized that this implementation guide SHOULD NOT constrain extensions to the LOINC Clinical Document Ontology. This implementation guide recognizes the established process already in place for managing and updating the current. The additional process proposed for extensions to the is further review by HL7 (specifically the Structured Documents and Vocabulary workgroups) to ensure coordination and inclusion in those standards where clinical document types are needed (for example, in a CDA R2 implementation guide that requires specification of a specific clinicaldocumenttype. This review of extensions for all HL7 standards is proposed for the following reasons Increase awareness and usage of the document ontology in the development of existing HL7 standards Begin to standardize typecode values for HL7 This section is proposed as draft pending further review and discussion among the following groups within HL7 HL7 Vocabulary Working Group HL7 Structured Documents Working Group (SDWG) Hl7 Technical Standards Committee (TSC) 2.1.4 Ontological Models Central to the idea of supporting the LOINC Document Ontology is the need for an underlying model that further explains the Clinical Document Ontology (CDO). Although not included in the immediate short-term approach for LOINC Clinical Document Ontology implementation, the 2014 version of this implementation guide will include a supporting OWL-based version of the. To further enhance implementation of LOINC, additional work was performed to design and develop a formal ontology using OWL as the primary language for specification. This will be included as a fully documented portion of the implementation guide. 2.2 Technical Structure Page 22 HL7/ Implementation Guide 2013 Health Level Seven, Inc. All rights reserved. September 2013
The proposed technical approach uses structure as the dominating context for the implementation of the ontology. No changes to the current technical structure are anticipated and no changes are directly defined in this implementation guide. The level of the detail in the implementation guide is reflective of the detailed structure of the underlying standard, while also providing specific implementation guidance for how to use the as a mechanism to improve query and retrieval of clinical documents. Types are established based on shared structural properties for a specific instance of a clinical document. 2.2.1 Identifiers and Terms The current implementaton guide uses the same identifiers and terms as those specified for the LOINC Document Ontology. The intention is not to introduce new terms that would be unfamiliar to those who already work with the current ontology. The only identifiers and terms that would be introduced in this implementation guide would be identifiers and terms associated with metadata for a clinical document type. 2.2.2 Structure of Ontology The structure of the ontology is designed in several pieces as part of a larger package: The implementation guide for the ontology contains descriptive information about each class contained in the ontology and how to implement and query these classes as a clinical document type Each of the layers within the ontology will be modeled as an OWL file subsequent to release of the LOINC Document Ontology. The use of a package of RDF files would then allow for the development of system designs from the ontology that would maintain class relationships and associations. 2.2.3 Structure of Clinical Document Name The structure of the clinical document name is based on the current LOINC Document Ontology and its naming structure. No changes are proposed to the structure of the names that are used within the ontology. This structure specifies that any document name listed in this implementation guide must contain a Kind of Document value (as expressed through the component part) as well as information provided through at least one of the other axes as specified in the ontology: Property Time System Scale Method This approach ensures that queries that are based on the document type display name can be executed as an alternative implementation approach, and ensures no changes are made to the LOINC Document Ontology multi-axial approach. HL7/ Implementation Guide Page 23 September 2013 2013 Health Level Seven, Inc. All rights reserved.
3 D O C U M E N T ONT O L O G Y The LOINC Document Ontology is intended to be used as the primary source ontology for defining valid document types, with specific use as part of application ontologies that are implemented to represent document types, such as those in an XDS affinity domain. This will allow for the flexibility to use additional local LOINC codes if necessary, for the description of document types that may be specific to a domain or organization. The goal of documenting each of the axes listed in this section is to document the current as a baseline ontology that can be represented in an implementation guide format, for review by both HL7 and Regenstrief, and to begin further phases of review for additional LOINC codes to be included as proposed additions to the current ontology within the appropriate LOINC working groups. The schema that is proposed within the LOINC Clinical Document Taxonomy uses the following structure: Domain Type of Note (referred to as Document Type) Role Type of Setting (Inpatient, Outpatient as examples) Type of Care Provided This is the current structure as defined by Regenstrief within LOINC and this implementation guide adopts the current structure specified for the LOINC Clinical Document Ontology as is. The proposed approach used within the tables provided is shown in the example below: LOINC_NUMBER A description of the intended meaning for the LOINC code in the context of the Clinical Document Ontology. Wherever possible, the implementation guide will seek to draw from the existing The specific LOINC code that applies to this clinical document type. There can be several variations of this field that are shown but the primary field used is the current LOINC code as specified from as part of LOINC 2.4 This field can include local proposed codes as part of this implementation guide, which are proposed by organizations such as the DOD and VA as additions to the LOINC Clinical Document Ontology. These would be highlighted in yellow if populated An additional level of specification in which the LOINC part number is provided. The part number is also specified with the specific axe it pertains to. A super class would indicate the level of this code within the LOINC hierarchy that this particular LOINC code inherits from. This is the core levels of the ontology. As this is an ontology, the super class is the highest level class within the ontology that this Page 24 HL7/ Implementation Guide 2013 Health Level Seven, Inc. All rights reserved. September 2013
specific LOINC code resides in, and would specify classes at higher levels for the root class, and classes 1 level above as the ontology is traversed. Associated notes for the specified LOINC code. can take a wide variety of forms but are intended to represent implementation details for specific use by the implementer The specific source of information used for this document type. A primary source for many of these codes will by Regenstrief and use of the RELMA tool. For many codes within the ontology, there is no existing LOINC code defined within the and this is noted in yellow Table 4 Structure of 3.1 Domain Individual clinical domains are established at the top of the ontological structure to allow for initial query functions to be implemented through traversing a clinical domain. The domains within the ontology are used to classify the subject matter domain of a specific clinical document. All proposed codes for this axe are drawn from the Method LOINC part. Unless otherwise specified, all codes in this section are specific to those defined in the Subject Matter Domain (SMD) section of the LOINC Users Guide. 3.1.1 Allergy and Immunology LP135585-0 Method 3.1.2 Anesthesiology LP135585-0 Method 3.1.2.1 Pain Medicine LP135585-0 Anesthesiology HL7/ Implementation Guide Page 25 September 2013 2013 Health Level Seven, Inc. All rights reserved.