PRE-BALLOT DRAFT HL7/LOINC Clinical Document Ontology 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.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
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.
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.
1.2.1 Problem Statement..............................................................................................131.2.2 Value Proposition for Interoperability..................................................................14
1.3 Scope........................................................................................................................141.4 Proposed Development Lifecycle...............................................................................16
1.4.1 Proposed Stakeholders for Development.............................................................171.5 Organization of This Guide........................................................................................171.6 Conformance Conventions Used in This Guide..........................................................181.7 Notes to Readers.......................................................................................................19
1.7.1 Use of Local LOINC Codes and Names.................................................................201.8 Content of the Package.............................................................................................20
2 GENERAL ONTOLOGY STRUCTURE...................................................................................212.1 Technical Approach...................................................................................................21
2.2 Technical Structure....................................................................................................232.2.1 Identifiers and Terms...........................................................................................242.2.2 Structure of Ontology Description.......................................................................242.2.3 Structure of Clinical Document Name..................................................................24
3.2 Type of Note (Kind of Document)..............................................................................443.2.1 Administrative note.............................................................................................443.2.2 Advance directive................................................................................................483.2.3 Consultation Note................................................................................................483.2.4 Correspondence..................................................................................................493.2.5 Counseling Note..................................................................................................493.2.6 Diagram...............................................................................................................493.2.7 Education Note....................................................................................................503.2.8 Encounter Note....................................................................................................503.2.9 Form....................................................................................................................513.2.10 Letter.................................................................................................................513.2.11 Note...................................................................................................................513.2.12 Report...............................................................................................................513.2.13 Public Health Document....................................................................................513.2.14 Restraint Note...................................................................................................523.2.15 Referral Note.....................................................................................................52
3.3 Role...........................................................................................................................523.3.1 Assistant..............................................................................................................523.3.2 Case Manager......................................................................................................533.3.3 Clerical................................................................................................................533.3.4 Counselor............................................................................................................533.3.5 Hygienist.............................................................................................................533.3.6 Interdisciplinary...................................................................................................533.3.7 Medical Assistant.................................................................................................533.3.8 Nurse...................................................................................................................543.3.9 Patient.................................................................................................................553.3.10 Physician...........................................................................................................553.3.11 Student..............................................................................................................563.3.12 Technician.........................................................................................................573.3.13 Therapist...........................................................................................................57
3.4 Type of Setting..........................................................................................................573.4.1 Ambulance Transport..........................................................................................583.4.2 Birthing Center....................................................................................................583.4.3 Emergency Department......................................................................................583.4.4 Home Health.......................................................................................................58
3.4.5 Hospital...............................................................................................................593.4.6 Inpatient Hospital................................................................................................593.4.7 Intensive Care Unit..............................................................................................593.4.8 Long Term Care Facility.......................................................................................593.4.9 Outpatient...........................................................................................................603.4.10 Rehabilitation Hospital.......................................................................................613.4.11 Telehealth.........................................................................................................613.4.12 Telephone Encounter.........................................................................................61
3.5 Type of Care Provided (Service)................................................................................613.5.1 Communication...................................................................................................623.5.2 Conference..........................................................................................................623.5.3 Consultation........................................................................................................623.5.4 Individual Counseling..........................................................................................623.5.5 Group Counseling................................................................................................623.5.6 Diagnostic Study.................................................................................................633.5.7 Education............................................................................................................633.5.8 Evaluation and Management...............................................................................643.5.9 Evaluation and Management of a Specific Problem.............................................653.5.10 Disability Examination.......................................................................................663.5.11 Exercise Testing................................................................................................823.5.12 Medication Management...................................................................................823.5.13 Procedure..........................................................................................................823.5.14 Referral..............................................................................................................833.5.15 Respite..............................................................................................................833.5.16 Supervisory Direction........................................................................................843.5.17 Triage................................................................................................................84
4 IMPLEMENTATION OF THE ONTOLOGY...........................................................................1074.1 Implementation Basics............................................................................................1074.2 Summary of Conformance Statements....................................................................1074.3 Using the Ontology..................................................................................................107
4.3.1 Example of LOINC Ontology Usage....................................................................1084.3.2 Use of Metadata for implementation.................................................................109
4.4 Reuse of Existing Taxonomies.................................................................................1094.4.1 LOINC................................................................................................................1094.4.2 HL7....................................................................................................................110
4.5 Implementation Approaches for Document Type Representation............................1114.5.1 XML Representation..........................................................................................1114.5.2 RDF Representation...........................................................................................1124.5.3 JSON Representation.........................................................................................112
4.6 Implementation Approaches to Queries...................................................................1124.6.1 Use of Existing Metadata Registries..................................................................1124.6.2 Use of XD* Metadata.........................................................................................1134.6.3 Use of FHIR and REST........................................................................................113
5 PROPOSED USE CASES FOR IMPLEMENTATION..............................................................1155.1 Query Using RESTful API..........................................................................................115
5.1.1 Query FHIR Resource Bundle specified by Domain............................................1155.1.2 Query FHIR Resource Bundle specified by Document Type...............................1155.1.3 Query FHIR Resource Bundle specified by Role.................................................1155.1.4 Query FHIR Resource Bundle specified by Care Setting.....................................1165.1.5 Query FHIR Resource Bundle specified by Type of Service................................1165.1.6 Query hData Root File with Domain...................................................................1165.1.7 Query hData Root File with Document Type......................................................1165.1.8 Query hData Root File with Role........................................................................1165.1.9 Query hData Root File with Care Setting...........................................................1165.1.10 Query hData Root File with Type of Service.....................................................117
5.2 Query in Existing SOA Environment.........................................................................1175.2.1 Use of HL7 RLUS with LOINC Clinical Document Ontology.................................117
5.3 Query Using IHE XD*...............................................................................................1175.3.1 Querying within the Domain of Implementation................................................1185.3.2 Querying using the Document Type..................................................................1185.3.3 Querying using the Role....................................................................................1185.3.4 Querying using the Care Setting........................................................................1195.3.5 Querying using the Type of Service Provided....................................................119
5.4 Querying Remote Registries or Repositories...........................................................1195.4.1 Query using IHE XCA.........................................................................................119
5.5 Vocabulary Considerations for SNOMED-CT.............................................................1195.5.1 Populate value sets for individual dimensions...................................................1195.5.2 Generate full (combinatorial) ontology..............................................................120
5.5.3 Map legacy LOINC codes into SNOMED-CT Ontology.........................................1205.6 Long Term Implementation Considerations.............................................................120
6 VALUE SET MAPPING TO ONTOLOGY..............................................................................121
1 INTRODUCTIONThe 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 AudienceThe 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 PurposeThe 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 LOINC Clinical Document Ontology is the DOD and VA, the expected downstream benefits of pursuing this implementationThe purpose of this implementation guide is to support two implementation purposes:
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 StatementWhile 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 LOINC Clinical Document Ontology 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 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 InteroperabilityThe 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 LOINC Clinical Document Ontology (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 LOINC Clinical Document Ontology can be supported.
1.3 ScopeThe 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
• Establishing a formal mechanism through Regenstrief (and HL7) to accept extensions to the LOINC Clinical Document Ontology, and to promote reuse of the LOINC Clinical Document Ontology 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 LOINC Clinical Document Ontology, 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 LOINC Clinical Document Ontology, 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 LOINC Clinical Document Ontology 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:
Are expressed at appropriate levels of abstraction (thus appropriate and stable over time). Can be rigorously checked for coherence, compared, and combined if possible.
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 LifecycleThe 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
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
Phase 2 – Development of the ontology using OWL (Protégé)
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
Phase 3 – Broad stakeholder review of the ontology
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.
Phase 4 – Propose structural enhancements to LOINC if ontology implementation
Based on the pilot implementation process that is proposed, additional enhancements may then be needed to the actual structure of the LOINC Clinical
indicates need 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
1.4.1 Proposed Stakeholders for DevelopmentIn 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
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
HL7 Vocabulary Working Group
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 (Document Ontology Workgroup) and Regenstrief
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 LOINC Clinical Document Ontology
1.5 Organization of This GuideThis 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 LOINC Clinical Document Ontology) The main chapters are: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 LOINC Clinical Document Ontology. It also defines specific constraints for implementation as a list of clinical document types that the ontology would supportChapter 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 informationChapter 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 LOINC Clinical Document Ontology to specify both a type and supporting metadata to locate and retrieve patient and administrative informationAppendices - The Appendices include non-normative content to support implementers of the LOINC Clinical Document Ontology. It includes a Change Appendix summary of previous and updated clinical document types
1.6 Conformance Conventions Used in This GuideExpectations 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 LOINC Clinical Document Ontology 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:
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 Notes 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 "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 NamesOne 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 PackageThe following files have been included in this implementation guide initial releaseFilename Description Standards
2 GENERAL ONTOLOGY STRUCTUREThe 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 LOINC Clinical Document Ontology approach
2.1 Technical ApproachThe 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 LOINC Clinical Document Ontology 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 LOINC Clinical Document Ontology as-is Documentation of the use of metadata to support queries of clinical document
types defined in the LOINC Clinical Document Ontology Mechanisms for extending the LOINC Clinical Document Ontology within the
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 ApproachThe 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 LOINC Clinical Document Ontology.
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
2.1.3 Ontology ExtensionsThe 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 sub-ontologies 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 LOINC Clinical Document Ontology. The additional process proposed for extensions to the LOINC Clinical Document Ontology 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 ModelsCentral 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 LOINC Clinical Document Ontology.
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.
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 LOINC Clinical Document Ontology 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 Description
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 NameThe 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:
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.
3 DOCUMENT ONTOLOGYThe 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 LOINC Clinical Document Ontology 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:
Description 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
LOINC_NUMBER 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 LOINC Clinical Document Ontology 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
PART_NUMBER 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.
Super Class 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
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.
Notes Associated notes for the specified LOINC code. Notes can take a wide variety of forms but are intended to represent implementation details for specific use by the implementer
Source 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 LOINC Clinical Document Ontology and this is noted in yellow
Table 4 – Structure of LOINC Clinical Document Ontology
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 ImmunologyDescriptionPART_NUMBER LP135585-0Super Class MethodNotesSource LOINC Clinical Document Ontology
3.1.2 AnesthesiologyDescriptionPART_NUMBER LP135585-0Super Class MethodNotesSource LOINC Clinical Document Ontology
3.1.2.1 Pain Medicine
DescriptionPART_NUMBER LP135585-0Super Class AnesthesiologyNotesSource LOINC Clinical Document Ontology
The type of note specifically maps the Component axe, as specification of the Kind of Document, and is a base axe that is combined with at least 1 other axe to produce the LOINC clinical document type.
Unless otherwise specified, all codes in this section are specific to those defined in the “Kind of Document” section of the LOINC Users Guide.
3.2.1 Administrative note Description An administrative document addresses non-clinical topics in the
healthcare setting. These include financial documents, bills, an account summary, contracts, employee schedules, the HIPPA mandated notice of privacy practices. In addition, some types of consent document fall under this category, as they deal with purely administrative functions, such as release of records, or consenting to an inter-facility transfer. Administrative documents and clinical documents do share some overlap, for example physician orders for admission, discharge or transfer.
LOINC_NUMBER 51851-4PART_NUMBER LP73899-4Super Class ComponentNotesSource LOINC Clinical Document Ontology
3.2.1.1 Against Medical Advice NoteDescriptionLOINC_NUMBERPART_NUMBER None defined – requires LOINC partSuper Class Administrative NoteNotesSource LOINC Clinical Document Ontology
3.2.1.2 AgreementDescriptionLOINC_NUMBERPART_NUMBER None defined – requires LOINC partSuper Class Administrative NoteNotesSource LOINC Clinical Document Ontology
3.2.1.3 CertificateDescriptionLOINC_NUMBERPART_NUMBER LP149091-3Super Class Administrative NoteNotesSource LOINC Clinical Document Ontology
DescriptionLOINC_NUMBER 61358-8PART_NUMBER LP102489-4Super Class ConsentNotesSource LOINC Clinical Document Ontology
3.2.1.5 ContractDescriptionLOINC_NUMBERPART_NUMBER None defined – requires LOINC partSuper Class Administrative NoteNotesSource LOINC Users Guide
3.2.1.6 Health insurance cardDescriptionLOINC_NUMBER 64290-0PART_NUMBER LP116194-4Super Class Administrative NoteNotesSource LOINC Clinical Document Ontology
3.2.1.7 Health insurance-related formDescriptionLOINC_NUMBER 64291-8PART_NUMBER LP116195-1Super Class Administrative NoteNotesSource LOINC Clinical Document Ontology
3.2.1.8 Health record cover sheetDescriptionLOINC_NUMBER 64289-2PART_NUMBER LP116193-6Super Class Administrative NoteNotesSource LOINC Clinical Document Ontology
3.2.1.9 Legal document
DescriptionLOINC_NUMBER 64299-1PART_NUMBER LP116198-5Super Class Administrative NoteNotesSource LOINC Clinical Document Ontology
3.2.1.9.1 Power of attorneyDescriptionLOINC_NUMBER 64298-3PART_NUMBER LP116225-6Super Class Administrative NoteNotesSource LOINC Clinical Document Ontology
DescriptionLOINC_NUMBER 45474-4PART_NUMBER LP74448-9Super Class Advance DirectiveNotesSource LOINC Clinical Document Ontology
3.2.2.2 Living will
DescriptionLOINC_NUMBER 45473-6PART_NUMBER LP74450-5Super Class Advance DirectiveNotesSource LOINC Clinical Document Ontology
3.2.3 Consultation NoteDescription Consultation note is generated by a physician or nonphysician
practitioner's (NPP) upon request for an opinion or advice from another physician or NPP. Consultations involve face-to-face time with the patient or telemedicine visits. A Consultation Note must be provided to the referring physician or NPP and include the reason for the referral, history of present illness, physical examination, and decision-making component (Assessment and Plan).
LOINC_NUMBER 11488-4PART_NUMBER LP72311-1Super Class ComponentNotesSource Proposed by iEHR
3.2.8 Encounter NoteDescriptionPART_NUMBER None defined – requires LOINC partSuper Class General Document TypeNotes Proposed by VASource Submitted by VA
3.2.8.1 Encounter Note- ConsultationDescriptionPART_NUMBER None defined – requires LOINC partSuper Class Encounter NoteNotes Proposed by VASource Submitted by VA
3.2.8.2 Encounter Note- CounselingDescriptionPART_NUMBER None defined – requires LOINC partSuper Class Encounter NoteNotes Proposed by VASource Submitted by VA
3.2.8.3 Encounter Note - History & PhysicalDescriptionPART_NUMBER None defined – requires LOINC partSuper Class Encounter NoteNotes Proposed by VASource Submitted by VA
3.2.9 FormDescriptionPART_NUMBER LP29994-8Super Class General Document TypeNotesSource Proposed through this implementation guide as a new LOINC
DescriptionPART_NUMBER None defined – requires LOINC partSuper Class NoteNotesSource LOINC Clinical Document Ontology
3.2.12 ReportDescriptionPART_NUMBER LP7554-1Super Class ComponentNotesSource LOINC Clinical Document Ontology
3.2.13 Public Health DocumentDescription Used to classify all public health document types. Public health
documents convey information between clinicians and public health officials. For example, the CDC has an ongoing iatrogenic infection surveillance program which uses CDA R2 to transmit case and rate information from individual hospitals. Vital records and quarantine orders are examples of public health documents which are also legal documents. Finally, public health officials use case report forms in a manner very similar to clinical research.
LOINC_NUMBER 55751-2PART_NUMBER LP94951-8Super Class ComponentNotes Proposed as new higher level document typeSource Proposed by iEHR
PART_NUMBER LP135445-7Super Class ComponentNotesSource Proposed by iEHR
3.2.15 Referral NoteDescription A referral note is a note that is sent to a consultant for a
consultation (e.g. opinion, testing, etc). This might often be initiated by a primary care provider seeking advice from a specialist while the overall care remains with the PCP.
LOINC_NUMBER 57133-1PART_NUMBER LP97117-3Super Class ComponentNotesSource Proposed by iEHR
3.3 RoleRole would be defined as an enumerated list to support the searching and querying of specific clinical document types. “Role” in the context of the LOINC Document Ontology may also refer to an individuals training or professional level.
Role represents the third tier of the ontology and maps to the Method axe. Role also is aligned to the Subject Matter Domain (SMD) which shares the same axe.
Unless otherwise specified, all codes in this section are specific to those defined in the “Role” section of the LOINC Users Guide.
3.3.1 AssistantDescriptionLOINC_NUMBERPART_NUMBER None defined – requires LOINC partSuper Class MethodNotesSource LOINC Clinical Document Ontology
3.3.2 Case ManagerDescriptionPART_NUMBER LP32202-1Super Class MethodNotesSource LOINC Clinical Document Ontology
LOINC_NUMBERPART_NUMBER None defined – requires LOINC partSuper Class MethodNotesSource LOINC Clinical Document Ontology
3.3.4 CounselorDescriptionLOINC_NUMBERPART_NUMBER None defined – requires LOINC partSuper Class MethodNotesSource LOINC Clinical Document Ontology
3.3.5 HygienistDescriptionLOINC_NUMBERPART_NUMBER None defined – requires LOINC partSuper Class MethodNotesSource LOINC Clinical Document Ontology
3.3.6 InterdisciplinaryDescriptionLOINC_NUMBERPART_NUMBER None defined – requires LOINC partSuper Class MethodNotesSource LOINC Clinical Document Ontology
3.3.7 Medical AssistantDescriptionLOINC_NUMBERPART_NUMBER None defined – requires LOINC partSuper Class MethodNotesSource LOINC Clinical Document Ontology
3.3.8 NurseDescriptionLOINC_NUMBERPART_NUMBER LP32983-6Super Class MethodNotesSource LOINC Clinical Document Ontology
3.3.12 TechnicianDescriptionLOINC_NUMBERPART_NUMBER None defined – requires LOINC partSuper Class MethodNotesSource LOINC Clinical Document Ontology
3.3.13 TherapistDescriptionLOINC_NUMBERPART_NUMBER None defined – requires LOINC partSuper Class MethodNotesSource LOINC Clinical Document Ontology
3.4 Type of Setting
The establishment of setting within the ontology model is used to establish an initial level of classification of the types of settings where clinical documents are created and used. Setting is not meant to be analogous to location, but meant to correlate to CMS definitions surrounding the setting in which a service is provided.
Most clinical report names would include a setting (at least at the top level) to avoid confusion between important classes of reports. For example, an admission H&P is usually taken to be the Hospital Admissio H & P, but it could be confused with the nursing home H&P if not distinguished by the setting.
Within the LOINC Document Ontology, setting is not a required component of the name. The fourth tier of the ontology maps to the System axe.
Unless otherwise specified, all codes in this section are specific to those defined in the “Setting” section of the LOINC Users Guide.
3.4.1 Ambulance TransportDescriptionLOINC_NUMBERPART_NUMBER LP6999-9Super Class SystemNotesSource LOINC Clinical Document Ontology
3.4.6 Inpatient HospitalDescriptionPART_NUMBER LP66708-6Super Class SystemNotesSource LOINC Clinical Document Ontology
3.4.7 Intensive Care UnitDescriptionPART_NUMBER LP76050-1Super Class Hospital UnitNotes SystemSource LOINC Clinical Document Ontology
3.4.8 Long Term Care FacilityDescriptionPART_NUMBER LP66709-4Super Class SystemNotesSource LOINC Clinical Document Ontology
3.4.8.1 Custodial Care FacilityDescriptionLOINC_NUMBERPART_NUMBER None defined – requires LOINC partSuper Class Long Term Care FacilityNotesSource LOINC Clinical Document Ontology
3.4.8.2 Nursing FacilityDescriptionLOINC_NUMBERPART_NUMBER None defined – requires LOINC partSuper Class Long Term Care FacilityNotesSource LOINC Clinical Document Ontology
3.4.8.2.1 Skilled Nursing Facility (SNF)
DescriptionPART_NUMBER LP135588-4Super Class Nursing FacilityNotesSource LOINC Clinical Document Ontology
In the fifth tier of the ontology, the specific type of care provided to a patient provides specific detail about the type of care delivered within the document type.The fifth tier of the ontology maps to the Component axe along with the Kind of Document.Unless otherwise specified, all codes in this section are specific to those defined in the “Kind of Document” section of the LOINC Users Guide.
3.5.1 Communication Description The exchange or transmission of ideas, attitudes, or beliefs
between individuals or groups.LOINC LP57380-5Super Class ComponentNotesSource National Library of Medicine, MeSH 2006
DescriptionPART_NUMBER None defined – requires LOINC partSuper Class Evaluation and ManagementNotesSource LOINC Clinical Document Ontology
3.5.8.2 Assessment
Description Used to represent all assessment notesPART_NUMBER- LP74507-2Super Class Evaluation and ManagementNotesSource LOINC Clinical Document Ontology
3.5.8.2.1 Functional Status Assessment
DescriptionPART_NUMBER LP72616-3Super Class AssessmentNotesSource LOINC Clinical Document Ontology
3.5.8.2.2 Readiness for Military Duty Assessment
DescriptionPART_NUMBER LP116216-5Super Class AssessmentNotesSource LOINC Clinical Document Ontology
3.5.8.2.3 Risk Assessment and Screening
DescriptionPART_NUMBER LP149830-4Super Class AssessmentNotesSource LOINC Clinical Document Ontology
3.5.8.2.3.1 Fall Risk Assessment
DescriptionPART_NUMBER LP97198-3Super Class Risk Assessment ScreeningNotesSource LOINC Clinical Document Ontology
3.5.9 Evaluation and Management of a Specific Problem
3.5.14 ReferralDescription A referral note is a note that is sent to a consultant for a
consultation (e.g. opinion, testing, etc). This might often be initiated by a primary care provider seeking advice from a specialist while the overall care remains with the PCP.
LOINC_NUMBER 57133-1Super Class ComponentNotesSource LOINC Clinical Document Ontology
3.5.14.1Transfer of Care ReferralDescriptionLOINC_NUMBER 34140-4Super Class ReferralNotesSource LOINC Clinical Document Ontology
3.5.15 RespiteDescriptionPART_NUMBER LP75581-6Super Class ComponentNotes This is a component classSource LOINC Clinical Document Ontology
LOINC Users Guide
3.5.16 Supervisory DirectionDescriptionPART_NUMBER LP57354-0Super Class ComponentNotesSource LOINC Clinical Document Ontology
LOINC Users Guide
3.5.17 TriageDescriptionPART_NUMBER LP76330-7Super Class ComponentNotes Formally defined within the ontology as a “triage note”Source LOINC Clinical Document Ontology
To support the 5 axes defined in this ontology, a proposed list of clinical document types is defined in this implementation guide, as derived from the current LOINC Clinical Document Ontology and standard rules that exist through the LOINC Users Guide in defining document types. It is recognized that potential combinations dictated by the ontology can stretch to almost 2000 different combinations so this list is proposed as a constrained version that would be recommended as the standard list, that can then be extended per the rules defined in Appendix D of this implementation guide
Parent Part Part Definition LOINC ID Document Type (LOINC LONG_COMMON_NAME)LP73895-2 Abortion consent 52027-0 Abortion consentLP73899-4 Administrative note 51851-4 Administrative noteLP72056-2 Admission evaluation note 67851-6 Admission evaluation note
LP57350-8 Counseling note 47042-7 Counseling noteLP57350-8 Counseling note 34864-9 Mental health Counseling noteLP57350-8 Counseling note 34869-8 Pharmacy Counseling noteLP57350-8 Counseling note 34865-6 Psychiatry Counseling noteLP57350-8 Counseling note 34866-4 Psychology Counseling noteLP57350-8 Counseling note 34872-2 Social work Counseling noteLP116197-7 Death certificate 64297-5 Death certificateLP134108-2 Diagnostic study note 68611-3 Adolescent medicine Diagnostic study noteLP134108-2 Diagnostic study note 68625-3 Allergy and immunology Diagnostic study noteLP134108-2 Diagnostic study note 68635-2 Audiology Diagnostic study noteLP134108-2 Diagnostic study note 68640-2 Audiology Hospital Diagnostic study noteLP134108-2 Diagnostic study note 68641-0 Child and adolescent psychiatry Diagnostic study noteLP134108-2 Diagnostic study note 68652-7 Clinical genetics Diagnostic study noteLP134108-2 Diagnostic study note 70004-7 Diagnostic study noteLP134108-2 Diagnostic study note 68673-3 Multi-specialty program Diagnostic study noteLP134108-2 Diagnostic study note 68687-3 Neurological surgery Diagnostic study noteLP134108-2 Diagnostic study note 68556-0 Neurology Diagnostic study note
LP134108-2 Diagnostic study note 68696-4Neurology w special qualifications in child neuro Diagnostic study note
LP134108-2 Diagnostic study note 68706-1Neurology w special qualifications in child neuro Hospital Diagnostic study note
LP134108-2 Diagnostic study note 68557-8 Obstetrics and Gynecology Diagnostic study noteLP134108-2 Diagnostic study note 68577-6 Orthopedic surgery Diagnostic study noteLP134108-2 Diagnostic study note 68708-7 Pain medicine Diagnostic study noteLP134108-2 Diagnostic study note 68718-6 Pediatric cardiology Diagnostic study noteLP134108-2 Diagnostic study note 68748-3 Pediatric hematology-oncology Diagnostic study noteLP134108-2 Diagnostic study note 68767-3 Pediatric nephrology Diagnostic study noteLP134108-2 Diagnostic study note 68778-0 Pediatric pulmonology Diagnostic study noteLP134108-2 Diagnostic study note 68788-9 Pediatric pulmonology Hospital Diagnostic study noteLP134108-2 Diagnostic study note 68794-7 Pediatric surgery Diagnostic study noteLP134108-2 Diagnostic study note 68855-6 Pediatric transplant hepatology Diagnostic study noteLP134108-2 Diagnostic study note 68804-4 Pediatric urology Diagnostic study noteLP134108-2 Diagnostic study note 68822-6 Pediatrics Hospital Diagnostic study noteLP134108-2 Diagnostic study note 68604-8 Radiology Diagnostic study note
LP156982-3 Digital photographic image 72170-4Digital photographic image Unspecified body region Document
LP101193-3 Discharge instructions 60280-5Discharge instructions Emergency department Document
LP135361-6Evaluation and management of hyperlipidemia note 34859-9 Evaluation and management of hyperlipidemia
LP135362-4Evaluation and management of hypertension note 34860-7 Evaluation and management of hypertension
LP135363-2Evaluation and management of smoking cessation note 70005-4 Evaluation and management of smoking cessation
LP135363-2Evaluation and management of smoking cessation note 64142-3
Hospital Evaluation and management of smoking cessation
LP57351-6 Group counseling note 47043-5 Group counseling noteLP57351-6 Group counseling note 34114-9 Hospital Group counseling noteLP57351-6 Group counseling note 34787-2 Mental health Group counseling noteLP57351-6 Group counseling note 34790-6 Psychiatry Group counseling noteLP57351-6 Group counseling note 34793-0 Psychology Group counseling noteLP57351-6 Group counseling note 34843-3 Social work Group counseling noteLP116194-4 Health insurance card 64290-0 Health insurance cardLP116195-1 Health insurance-related form 64291-8 Health insurance-related formLP116193-6 Health record cover sheet 64289-2 Health record cover sheetLP72701-3 History and physical note 68614-7 Adolescent medicine History and physical note
LP72701-3 History and physical note 68622-0Advanced heart failure and transplant cardiology History and physical note
LP72701-3 History and physical note 68628-7 Allergy and immunology History and physical noteLP72701-3 History and physical note 68637-8 Audiology History and physical note
LP72701-3 History and physical note 68644-4Child and adolescent psychiatry History and physical note
LP72701-3 History and physical note 68655-0 Clinical genetics History and physical note
LP72701-3 History and physical note 68665-9Developmental-behavioral pediatrics History and physical note
LP72701-3 History and physical note 34117-2 History and physical noteLP72701-3 History and physical note 34115-6 Medical student Hospital History and physical noteLP72701-3 History and physical note 68676-6 Multi-specialty program History and physical noteLP72701-3 History and physical note 68683-2 Neonatal perinatal medicine History and physical noteLP72701-3 History and physical note 68690-7 Neurological surgery History and physical note
LP72701-3 History and physical note 68699-8Neurology w special qualifications in child neuro History and physical note
LP72701-3 History and physical note 67856-5 Nursing facility History and physical noteLP72701-3 History and physical note 68560-2 Obstetrics and Gynecology History and physical noteLP72701-3 History and physical note 68573-5 Ophthalmology History and physical noteLP72701-3 History and physical note 68580-0 Orthopedic surgery History and physical noteLP72701-3 History and physical note 68711-1 Pain medicine History and physical noteLP72701-3 History and physical note 68721-0 Pediatric cardiology History and physical noteLP72701-3 History and physical note 68731-9 Pediatric dermatology History and physical noteLP72701-3 History and physical note 68735-0 Pediatric endocrinology History and physical noteLP72701-3 History and physical note 68740-0 Pediatric gastroenterology History and physical note
LP72701-3 History and physical note 68751-7 Pediatric hematology-oncology History and physical noteLP72701-3 History and physical note 68760-8 Pediatric infectious diseases History and physical noteLP72701-3 History and physical note 68770-7 Pediatric nephrology History and physical noteLP72701-3 History and physical note 68775-6 Pediatric otolaryngology History and physical noteLP72701-3 History and physical note 68781-4 Pediatric pulmonology History and physical noteLP72701-3 History and physical note 68791-3 Pediatric rheumatology History and physical noteLP72701-3 History and physical note 68797-0 Pediatric surgery History and physical note
LP72701-3 History and physical note 68858-0Pediatric transplant hepatology History and physical note
LP72701-3 History and physical note 68807-7 Pediatric urology History and physical noteLP72701-3 History and physical note 68817-6 Pediatrics History and physical noteLP72701-3 History and physical note 68825-9 Pediatrics Hospital History and physical noteLP72701-3 History and physical note 28626-0 Physician History and physical noteLP72701-3 History and physical note 34116-4 Physician Nursing facility History and physical noteLP72701-3 History and physical note 68592-5 Plastic surgery History and physical noteLP72701-3 History and physical note 68833-3 Primary care History and physical noteLP72701-3 History and physical note 11492-6 Provider-unspecifed, History and physical noteLP72701-3 History and physical note 68599-0 Psychiatry History and physical noteLP72701-3 History and physical note 68843-2 Speech-language pathology History and physical noteLP72701-3 History and physical note 34774-0 Surgery History and physical noteLP72701-3 History and physical note 68849-9 Transplant surgery History and physical noteLP72753-4 Hospital discharge instructions 8653-8 Hospital discharge instructions [Text] NarrativeLP74106-3 Hysterectomy consent 52028-8 Hysterectomy consentLP72798-9 Informed consent obtained 19826-7 Informed consent obtainedLP57352-4 Initial evaluation note 64065-6 Case manager Hospital Initial assessment noteLP57352-4 Initial evaluation note 28581-7 Chiropractor Initial assessment noteLP57352-4 Initial evaluation note 28572-6 Dentist Initial assessment noteLP57352-4 Initial evaluation note 68553-7 Hematology and oncology Initial assessment noteLP57352-4 Initial evaluation note 34118-0 Home health Initial assessment noteLP57352-4 Initial evaluation note 47044-3 Hospital Initial assessment noteLP57352-4 Initial evaluation note 29753-1 Nurse Initial assessment noteLP57352-4 Initial evaluation note 28621-1 Nurse practitioner Initial assessment noteLP57352-4 Initial evaluation note 34119-8 Nursing facility Initial assessment noteLP57352-4 Initial evaluation note 18734-4 Occupational therapy Initial assessment noteLP57352-4 Initial evaluation note 34120-6 Outpatient Initial assessment noteLP57352-4 Initial evaluation note 18735-1 Physical therapy Initial assessment noteLP57352-4 Initial evaluation note 28654-2 Physician attending Initial assessment noteLP57352-4 Initial evaluation note 18763-3 Physician consulting Initial assessment noteLP57352-4 Initial evaluation note 18736-9 Physician Initial assessment noteLP57352-4 Initial evaluation note 18737-7 Podiatry Initial assessment noteLP57352-4 Initial evaluation note 28636-9 Provider-unspecified Initial assessmentLP57352-4 Initial evaluation note 28635-1 Psychiatry Initial assessment noteLP57352-4 Initial evaluation note 18738-5 Psychology Initial assessment note
LP96926-8Labor and delivery admission history and physical note 57056-4 Labor and delivery admission history and physical note
LP96927-6Labor and delivery summary note 57057-2 Labor and delivery summary note
LP116198-5 Legal document 64299-1 Legal documentLP74130-3 Letter 68620-4 Adolescent medicine Hospital Letter
LP74130-3 Letter 68624-6Advanced heart failure and transplant cardiology Hospital Letter
LP74130-3 Letter 68634-5 Allergy and immunology Hospital LetterLP74130-3 Letter 68649-3 Child and adolescent psychiatry Hospital LetterLP74130-3 Letter 68662-6 Clinical genetics Hospital LetterLP74130-3 Letter 68671-7 Developmental-behavioral pediatrics Hospital LetterLP74130-3 Letter 68555-2 Hematology and oncology Hospital LetterLP74130-3 Letter 68609-7 Hospital LetterLP74130-3 Letter 51852-2 LetterLP74130-3 Letter 68682-4 Multi-specialty program Hospital LetterLP74130-3 Letter 68686-5 Neonatal perinatal medicine Hospital LetterLP74130-3 Letter 68684-0 Neonatal perinatal medicine LetterLP74130-3 Letter 68695-6 Neurological surgery Hospital Letter
LP74130-3 Letter 68707-9Neurology w special qualifications in child neuro Hospital Letter
LP74130-3 Letter 68567-7 Obstetrics and Gynecology Hospital LetterLP74130-3 Letter 68571-9 Occupational therapy Hospital LetterLP74130-3 Letter 68576-8 Ophthalmology Hospital LetterLP74130-3 Letter 68585-9 Orthopedic surgery Hospital LetterLP74130-3 Letter 68717-8 Pain medicine Hospital LetterLP74130-3 Letter 68728-5 Pediatric cardiology Hospital LetterLP74130-3 Letter 68893-7 Pediatric dermatology Hospital LetterLP74130-3 Letter 68898-6 Pediatric endocrinology Hospital LetterLP74130-3 Letter 68747-5 Pediatric gastroenterology Hospital LetterLP74130-3 Letter 68758-2 Pediatric hematology-oncology Hospital LetterLP74130-3 Letter 68766-5 Pediatric infectious diseases Hospital LetterLP74130-3 Letter 68870-5 Pediatric nephrology Hospital LetterLP74130-3 Letter 68866-3 Pediatric nephrology LetterLP74130-3 Letter 68875-4 Pediatric otolaryngology Hospital LetterLP74130-3 Letter 68789-7 Pediatric pulmonology Hospital LetterLP74130-3 Letter 68880-4 Pediatric rheumatology Hospital Letter
LP74130-3 Letter 68803-6 Pediatric surgery Hospital LetterLP74130-3 Letter 68865-5 Pediatric transplant hepatology Hospital LetterLP74130-3 Letter 68813-5 Pediatric urology Hospital LetterLP74130-3 Letter 68826-7 Pediatrics Hospital LetterLP74130-3 Letter 68598-2 Plastic surgery Hospital LetterLP74130-3 Letter 68593-3 Plastic surgery LetterLP74130-3 Letter 68838-2 Primary care Hospital LetterLP74130-3 Letter 68847-3 Speech-language pathology Hospital LetterLP74130-3 Letter 68853-1 Transplant surgery Hospital Letter
LP73490-2Targeted history and physical note 34138-8 Targeted history and physical note
LP73545-3 Transfer of care referral note 34140-4 Transfer of care referral noteLP73546-1 Transfer summarization note 68618-8 Adolescent medicine Transfer summarization noteLP73546-1 Transfer summarization note 68632-9 Allergy and immunology Transfer summarization noteLP73546-1 Transfer summarization note 68647-7 Child and adolescent psychiatry Transfer summarization
noteLP73546-1 Transfer summarization note 68660-0 Clinical genetics Transfer summarization noteLP73546-1 Transfer summarization note 34755-9 Critical Care Medicine Transfer summarization note
LP73546-1 Transfer summarization note 68669-1Developmental-behavioral pediatrics Transfer summarization note
LP73546-1 Transfer summarization note 34770-8 General medicine Transfer summarization noteLP73546-1 Transfer summarization note 68680-8 Multi-specialty program Transfer summarization note
LP73546-1 Transfer summarization note 68704-6Neurology w special qualifications in child neuro Transfer summarization note
LP73546-1 Transfer summarization note 68482-9 Nurse Hospital Transfer summarization noteLP73546-1 Transfer summarization note 28651-8 Nurse Transfer noteLP73546-1 Transfer summarization note 68565-1 Obstetrics and Gynecology Transfer summarization noteLP73546-1 Transfer summarization note 68569-3 Occupational therapy Transfer summarization noteLP73546-1 Transfer summarization note 68887-9 Ophthalmology Transfer summarization noteLP73546-1 Transfer summarization note 68583-4 Orthopedic surgery Transfer summarization noteLP73546-1 Transfer summarization note 68715-2 Pain medicine Transfer summarization noteLP73546-1 Transfer summarization note 68726-9 Pediatric cardiology Transfer summarization noteLP73546-1 Transfer summarization note 68737-6 Pediatric endocrinology Transfer summarization noteLP73546-1 Transfer summarization note 68745-9 Pediatric gastroenterology Transfer summarization note
LP73546-1 Transfer summarization note 68756-6Pediatric hematology-oncology Transfer summarization note
LP73546-1 Transfer summarization note 68764-0Pediatric infectious diseases Transfer summarization note
LP73546-1 Transfer summarization note 68772-3 Pediatric nephrology Transfer summarization noteLP73546-1 Transfer summarization note 68777-2 Pediatric otolaryngology Transfer summarization noteLP73546-1 Transfer summarization note 68786-3 Pediatric pulmonology Transfer summarization noteLP73546-1 Transfer summarization note 68793-9 Pediatric rheumatology Transfer summarization noteLP73546-1 Transfer summarization note 68801-0 Pediatric surgery Transfer summarization note
LP73546-1 Transfer summarization note 68863-0Pediatric transplant hepatology Transfer summarization note
LP73546-1 Transfer summarization note 68811-9 Pediatric urology Transfer summarization noteLP73546-1 Transfer summarization note 68884-6 Pediatrics Hospital Transfer summarization noteLP73546-1 Transfer summarization note 68883-8 Pediatrics Transfer summarization noteLP73546-1 Transfer summarization note 28616-1 Physician Transfer noteLP73546-1 Transfer summarization note 68596-6 Plastic surgery Transfer summarization noteLP73546-1 Transfer summarization note 18761-7 Provider-unspecified Transfer summaryLP76330-7 Triage note 54094-8 Emergency department Triage noteLP96924-3 Triage+care note 57054-9 Nurse Emergency department Triage+care note
LP73592-5VA C&P exam.acromegaly note 38932-0
VA Compensation and Pension (C and P) examination acromegaly
LP73593-3
VA C&P exam.aid and attendance &or housebound note 38933-8
VA Compensation and Pension (C and P) examination aid and attendance/housebound
LP73594-1 VA C&P exam.arrhythmias 38934-6 VA Compensation and Pension (C and P) examination
4 IMPLEMENTATION OF THE ONTOLOGYThe LOINC Clinical Document Ontology is an existing ontology that is developed and maintained by Regenstrief. This section of the implementation guide goes beyond the current structure of the Clinical Document Ontology and specifically speaks to the proposed implementation characteristics for use of the ontology.
This section forms the core of the purpose for implementation of an ontology of clinical documents – mainly, that with the ontology already defined and maintained through Regenstrief, the core pupose for implementation is to increase standardized adoption of LOINC clinical document types as a way to enhance semantic interoperability.
4.1 Implementation BasicsTo establish use of the LOINC Clinical Document Ontology in settings beyond that specified for current usage, it is necessary to establish implementation guidance for its usage, which is the basis for this document. This section establishes a framework for implementation by presenting various implementation options for the ontology using existing HL7, IHE, and other interoperability standards.This implementation framework is expected to undergo extensive review by clinicians and implementers as it passes through balloting, and will then be maintained as an ongoing implementation guide to serve as the normative standard for usage of LOINC clinical document types.The operating basis for implementation is to NOT change the current ontology within the implementation guide, so scope of implementation is specific to the current ontology, and the use of supporting standards to enhance its value.
4.2 Summary of Conformance StatementsConformance is not a specific focus of the implementation guide, as this guide exists primarily as a framework for use. Thus, no specific conformance statements for implementation are established through this guide. Instead, similar to the approach adopted by HITSP, the clinical document types within the ontology serve as a source for further constraint and extension of acceptable values.An example of conformance from HITSP would be how the document type value set was defined. The value set was specified as a dynamic value set that is tied to the LOINC clinical document ontology and then is tied to implementation (in this case an XDS Affinity Domain).The Registry Stored Query and Retrieve Document Set transactions within the IHE XD* stack then specifically constrain to a set of coded values needed to represent clinical document types. As IHE is a profile, the level of constraint and conformance is specific to the implementer.
In the proposed approach for the LOINC Document Ontology, there are multiple use cases that will be developed to support the implementation of the ontology. These use cases for implementation are outlined in Section 5 of this implementation guide. These use cases were developed to support the notion of initial conceptual implementation of the ontology for the purposes of future piloting efforts.
The most basic use case is the searching of a specific clinical document type based on the current LOINC Clinical Document Ontology based on the current version of LOINC esablished and maintained
Additional use cases would expand upon this base use case to support broader search parameters and to allow for retrieval by LOINC Part Number, for example, where the registry supports use of only Type of Setting, for example, and the Component axe as the search parameter.
To use the ontology, an implementer would create LOINC codes for all required combinations as documented by DOD and VA for the iEHR. This approach would NOT document all possible combinations of codes, but only those codes that are required for iEHR implementation
As a proposed national standard, the LOINC Document Ontology would then be designed to support these required combinations. Additional possible combinations could be supported through either of the following processes:
1. Submission to HL7 and LOINC for recognition as a required combination2. Implementation within the local organization’s ontology by extending the base
ontology to support additional possible combinations
A more advanced use case is searching for specific clinical document types based on more complex pairings of axesEach name within the ontology would be ordered as follows:
4.3.1 Example of LOINC Ontology UsageA Disability Claims Adjudicator within the VBA received a claim for disability for debilitating back pain. The disability determination requires a history of illness in order to process the claim and ensure against fraud and abuse. The adjudicator needs to have a predictable way to query for related documents in order to gather the information needed to make a determination.
Specific to the LOINC Ontology, the Adjudicator performed a query request using a LOINC document code. This proves problematic since many documents would be returned, increasing determination time. An example of this quandary would be a search of the following LOINC code:
Several issues exist when related to disability of service members and the need to search for documents associated with a disability:
DoD performs disability evaluations of injured/ill service members as part of the Medical Evaluation Boards.
VA performs disability evaluations of injured/ill former service members as part of Compensation and Pension.
SSA requires disability evaluations of injured/ill former service members as part of Social Security Disability insurance.
There are additional challenges in this example:
Additional properties will not fit into the existing LOINC table LOINC defining axis is used inconsistently LOINC defining axis is overloaded.
4.3.2 Use of Metadata for implementationAn important building block in this implementation guide is expression of metadata with the clinical document type. This is the main purpose of the implementation guide – define implementation using existing standards and show how specific metadata can be applied to LOINC clinical document types to further enhance query and retrieval capabilities.
4.3.2.1 Expected Metadata AttributesFor each clinical document type, additional metadata attributes can be associated with the clinical document type, including the following attributes:
Author of the clinical document Location of the service performed Date of the service performed Status of the clinical document Use of security and privacy metadata
There would be no specific standardization proposed for these metadata elements within this implementation guide. Instead, the framework proposed is to provide different examples of how this metadata could be applied with clinical document types (such as part of the metadata associated with a XD* transaction) that an actor such as a Document Consumer could locate and review.
4.4 Reuse of Existing TaxonomiesThere are several existing taxonomies that are also defined by other organizations as prospective terminologies to reference and align the LOINC Document Ontology to. Each of these taxonomies is proposed within this implementation guide as possible taxonomies to use in the population of metadata surrounding a clinical document type.
4.4.1 LOINCA key source for the current implementation guide is the past work of the HL7/LOINC Document Ontology Task Force. This task force developed much of the current clinical document ontology that is now in use within LOINC and would be relied on as a primary source of expert review and consultation for the current implementation guide proposed for the LOINC Clinical Document Ontology.As noted throughout this implementation guide, Regenstrief (and LOINC) serve as the primary owners for the LOINC Clinical Document Ontology and revisions and changes to its content and structure are managed through Regenstrief-specific processes.
4.4.2 HL7 The LOINC Document Ontology would have potential overlap with those values provided in support of HL7 2.x messaging. The HL7 document type code domain will overlap with similar concepts found in HL7 V2.x (user defined table 0270 Document Types; user defined table 0496 Consent Types).
The proposed approach for reuse is to provide a mapping from LOINC codes proposed in this ontology to HL7 V2.x document codes as a future appendix within this implementation guide. It is also recognized that the HL7 V3 domain may contain concepts that are not present in the V2.x tables and will also require a future mapping to be developed as an appendix to this implementation guide.
This use of terminologies is consistent with text as defined in the LOINC Users Guide:
HL7 will use LOINC codes for clinical document codes, and will not develop an independent document code system for clinical documents. At its option, HL7 may choose to limit its domain to a subset of LOINC codes. HL7 can incorporate any LOINC document code into the HL7 domain.
4.4.2.1 HL7 Consent VocabulariesBecause of the increasingly sensitive nature of patient data a consideration for including supporting metadata to manage sensitive document types is also proposed within this implementation guide.
The proposed LOINC Document Ontology would seek to incorporate HL7 vocabularies that support definition of specialized document types that have the potential of containing highly sensitive information. The use of consent vocabularies would be accomplished through including additional support for metadata that is associated with clinical document types.
4.4.3 ABMSABMS helps to define the specific medical specialties that would be used to populate the Role axe for a specific LOINC code associated with a clinical document type. The primary role of ABMS (American Board of Medical Specialties) is to leverage the current list of Approved ABMS Specialty Boards & Certificates as part of defining the Role value within the LOINC Clinical Document Ontology.
Usage of ABMS vocabularies would be subject to specific approval by ABMS and by Regenstrief.
4.4.4 NUCCThe provider types defined by NUCC for a healthcare provider taxonomy (commonly referred to as Healthcare Provider Type Taxonomy) serve as another source for populating the Method and System axes that are needed to define a clinical document type.
The proposed approach for reuse is to ensure a mapping is available from the provider types listed within the NUCC Healthcare Provider Type taxonomy to the following axes:
Type of Setting – as defined in the System axe Role – as defined in the Method axe
4.4.5 SNOMED-CTOne of the challenges in using LOINC to build a document ontology is that other terminologies have characteristics which would support their usage as potential code systems for implementing an ontology of this type. An example of this challenge is SNOMED-CT, which can also be used as a document type identifier.
The proposed reuse of SNOMED-CT for the LOINC Document Ontology is to support development of a supporting clinical document map (LOINC to SNOMED-CT) which would be available to support the identification of LOINC document type codes by using a SNOMED-CT code. This is envisioned as a longer term goal as the implementation guide for the LOINC Clinical Document Ontology moves closer to normative status.
4.5 Implementation Approaches for Document Type Representation
In addition to methods of implementation for the querying of a clinical document type, representation of the ontology is also critical for implementation. This implementation guide does not define a single method of representation but supports multiple proposals whereby each of the document types defined in this guide can be expressed using one or more representational formats, that can be shared and used in multiple environments.
4.5.1 XML RepresentationThe most common representation that is used for clinical document types is as part of an XML representation. For example, CDA represents clinical document types using XML, as shown in the example below:
<code codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" code="34133-9" displayName="Summarization of Episode Note"/> <title>Community Health and Hospitals: Health Summary</title>
4.5.2 RDF RepresentationAn alternative representation that may also work within the context of implementation for a LOINC clinical document type is use of RDF. This would be especially relevant for implementations such as those associated with FHIR, where a Document or DocumentReference resource can be expressed in different formats, including RDF
4.5.3 JSON RepresentationSimilar to possible usage of RDF as a format, the use of JSON to represent document types is also supported. This supports the use of XPath queries for the specific JSON element representing the type. The following example highlights how this approach would work:
4.6 Implementation Approaches to QueriesThe initial scope of this implementation guide is not to specifically define an implementation approach that would be required to be implemented at a national level but to lay out various options for implementation that would be used for piloting and implementation. This includes the area of queries and the use of a standardized and structured document type to represent the data
Support existing implementation using a standard metadata registry provided within the implementation environment
Support existing implementations using an XDS document repository Support existing implementations using a RESTful API to access a FHIR
resource
4.6.1 Use of Existing Metadata RegistriesUsing a metadata registry that already exists within an existing health information exchange (HIE) or other implementation environment is another approach supported for implementation of the LOINC Clinical Document Ontology. The DOD/VA use case is predicated on the idea of implementation the LOINC Clinical Document Ontology within a metadata registry and as the primary source of clinical document types within an internal implementation
An example of this approach is using a metadata registry that would support the querying of metadata to search for a locally mapped set of document codes (such as a bundle of unstructured documentation or a set of LOINC clinical document types as defined in the LOINC Clinical Document Ontology that map to several local LOINC document codes)
The proposed implementation approach for use of existing metadata registries would also support the mapping of metadata included in a local registry to the attributes of the LOINC Clinical Document Ontology. The LOINC Document Ontology would have no major changes needed to support this approach. The implementation would rely on the local implementation to ensure that conformance to the Clinical Document Ontology was enforced.
4.6.2 Use of XD* MetadataTo support the necessary query and search functions that use of a LOINC Document Ontology would support, coordination with IHE as a representative standards body would be needed. The main methods for using XDS to search for LOINC would be the use of XD* metadata to search for a specified LOINC code that represents the clinical document type that is being queried for.
The proposed approach in this implementation guide would be to map XD* metadata to the existing fields that would needed from the LOINC clinical document type to support this implementation approach.
typeCode Machine computable LOINC code that represents the LOINC clinical document type from this implementation guide
classCode Tied to typeCodeeventCode Aligned to LOINC Clinical Document Ontology.TimepracticeSettingCode Aligned to LOINC Clinical Document Ontology.Care
SettingauthorSpecialty Aligned to LOINC Clinical Document Ontology.SMDauthorRole Aligned to LOINC Clinical Document Ontology.RolespecialtyCode Aligned to LOINC Clinical Document Ontology.SMDformatCode Aligned to LOINC Clinical Document Ontology.Scale
value where value=”DOC”mimeTypeCode Specific to the metadata registry being used, the
mimeTypeCode
Table 6 – Mapping LOINC Clinical Document Ontology to IHE XD* Metadata
4.6.3 Use of FHIR and RESTThe Clinical Document Ontology would also support enviornments where implementation of document types as a bundle of FHIR resources may be desirable.For example, in the DOD/VA approach, specific clinical documents would be defined using the Fast Healthcare Interoperability Resource, or FHIR, specification.
The document codes as defined in the LOINC Document Ontology would be used as the formal resource identifiers for each of these resources, to expedite identification of FHIR resources and resource bundles to better support interoperability.
The proposed approach to using FHIR to query for document types could have multiple options, and each can be leveraged to include additional metadata with the clinical document type to include information such as privacy and security metadata, provenance metadata, etc…
4.6.3.1 Use of Clinical Document Type with FHIR Document resource
In this implementation approach, the FHIR document resource would be used to represent the metadata for the clinical document type
The example below shows the base definition of th
4.6.3.2 Use of Clinical Document Type with FHIR DocumentReference resource
Similar to the approach used for Document resource, the clinical document type is also expressed using the <type> element, as shown in the example below:
This is specifically used for situations where non-FHIR specific resources are specified with a clinical document type.
4.6.3.3 Use of Clinical Document Type with FHIR resource bundleIn this implementation approach, the ResourceReference field can be populated using the LOINC clinical document type to show the different clinical document types expressed in the bundle.Implementation details on this approach are ongoing and are specified in implementation scenarios defined in sections 5.1.1 through 5.1.5
4.6.3.4 Use of Clinical Document Type with hData implementation
In this approach, the implementation of the clinical document type would occur within the root document of the hData hierarchy. Implementation details on this approach are ongoing and are specified in implementation scenarios defined in sections 5.1.6 through 5.1.10
To support development and design of the LOINC Clinical Document Ontology (CDO) as a potential standard to be balloted within an implementation guide, a series of use cases are outlined below, that represent POSSIBLE uses of the LOINC Clinical Document Ontology within the context of an implementation.
These use cases are defined within the implementation guide to identify specific, acute use cases that the LOINC Clinical Document Ontology and its implementation can solve.
These use cases are summarized below and are intended to support this implementation guide as initial implementation approaches that can be developed within separate implementation guides/profiles:
5.1 Query Using RESTful API
The use of a LOINC clinical document type would be supported in those approaches that rely on implementation of a RESTful API to support specific operations, such as GET or PUT. An immediate example of this approach in action would be use of the FHIR REST-based framework, and the need to locate and retrieve FHIR resources exposed through a FHIR-based server or other mechanism used to support exposing FHIR resources on a network.
Initial implementation using REST would focus on using an implementation scheme that allows for combination of FHIR with a local mapping approach that stuctures content into a specific hierarchy. This can be done using a locally defined approach and or using a more specific standard, such as work to standardize hData within HL7 as an approach for organizing resources.
To make these implementation use cases work, it is important to leverage existing standards where possible. To this manner, the primary standards to support recommendation of this implementation approach would be FHIR and hData, which can be implemented together or in parallel.
5.1.1 Query FHIR Resource Bundle specified by DomainIn this scenario, the FHIR resource bundle includes metadata specific to the subject matter domain. This metadata can be expressed within the FHIR DocumentReference resource and this metadat
5.1.2 Query FHIR Resource Bundle specified by Document TypeIn this scenario, the FHIR resource bundle includes metadata specific to the document type. This metadata can be expressed within the FHIR DocumentReference resource
5.1.3 Query FHIR Resource Bundle specified by RoleIn this scenario, the FHIR resource bundle includes metadata specific to the role surrounding the resources within the bundle. This metadata can be expressed within the FHIR DocumentReference resource
5.1.4 Query FHIR Resource Bundle specified by Care SettingIn this scenario, the FHIR resource bundle contains information surrounding the specific care setting. This metadata can be expressed within the FHIR DocumentReference resource
5.1.5 Query FHIR Resource Bundle specified by Type of ServiceIn this scenario, the FHIR resource bundle contains information surrounding the specific type of service. This metadata can be expressed within the FHIR DocumentReference resource
5.1.6 Query hData Root File with DomainIn this scenario, the hData root file contains information surrounding the specific subject matter domain, expressed as an hData extension.
This approach would center on using an extension to the hData root file to express a value for the subject matter domain, and constraining the value for the extension to the LOINC Clinical Document Ontology – Subject Matter Domain value set.
5.1.7 Query hData Root File with Document TypeIn this scenario, the hData root file contains information surrounding the specific document type, expressed as an hData extension.
This approach would center on using an extension to the hData root file to express a value for the document type, and constraining the value for the extension to the LOINC Clinical Document Ontology – Document Type value set.
5.1.8 Query hData Root File with RoleIn this scenario, the hData root file contains information surrounding the specific role that the resources within the folder are expected to contain. This metadata element would be expressed as part of an hData extension.
This approach would center on using an extension to the hData root file to express a value for the role, and constraining the value for the extension to the LOINC Clinical Document Ontology – Role value set.
5.1.9 Query hData Root File with Care SettingIn this scenario, the hData root file contains information surrounding the specific care setting, expressed as an hData extension.
This approach would center on using an extension to the hData root file to express a value for the care setting, and constraining the value for the extension to the LOINC Clinical Document Ontology – Care Setting value set.
5.1.10 Query hData Root File with Type of ServiceIn this scenario, the hData root file contains information surrounding the specific care setting, expressed as an hData extension.
This approach would center on using an extension to the hData root file to express a value for the type of service, and constraining the value for the extension to the LOINC Clinical Document Ontology – Type of Service value set.
5.2 Query in Existing SOA Environment
The use of SOA with a LOINC clinical document type is a natural implementation fit for those environments that already use an SOA architecture. In this scenario, the LOINC Clinical Document Ontology is exposed. Thus, the ontology is used as a pointer by requests to an Enterprise Service Bus for resource location.
5.2.1 Use of HL7 RLUS with LOINC Clinical Document Ontology
One of the most straightforward approaches for implementation of the LOINC Clinical Document Ontology is to use the ontology in combination with another service that would be primarily responsible for locating clinical document types available from data sources.For example, in an approach utilizing the HL7 Retrieve, Locate, and Update Service (RLUS), the LOINC Clinical Document Ontology would be represented within the primary <RLUSSearchStruct> WSDL files developed by an organization, to allow Locate (), Get (), and Retrieve () operations to directly support service interfaces that can identify clinical document types available from multiple data sources exposed as service endpoints.An example of this implementation approach is shown in the following scenario, which utilizes RLUS to perform a Locate () and Get () operation as part of the <RLUSSearchStruct>.
5.3 Query Using IHE XD*
The IHE XD* profiles represent an existing approach that can leverage metadata to search for and retrieve specific clinical document types. IHE XD* approaches are used across a variety of current information exchange environments and would not require extensive updates to existing specifications to support implementation.
The IHE approach is dependent upon use of specific format codes as specified by IHE, and this proposed approach would augment the use of standard IHE format codes by
supporting use of specific axes within the LOINC clinical document ontology as another expression of folder hierarchy to support documents and document sets.
It is important to note that this section of the document will require further IHE ITI and committee reviews as the expert opinion of IHE subject matter experts are required to validate the proposed approaches.
5.3.1 Querying within the Domain of ImplementationIn this scenario, XD* metadata would be structured to support queries of specific folders within the XD* repository that are specific to a subject matter domain.
5.3.1.1 Using XD* to Query for DomainXD* metadata would be structured to support queries of a Document Registry using subject matter domain information.
The query would be performed using one of two codes that are available:
These values would be constrained to LOINC PART NUMBERS as specified in the LOINC Clinical Document Ontology – Subject Matter Domain value set.
5.3.2 Querying using the Document TypeIn this scenario, XD* metadata would be structured to support queries of a Document Registry using the XDSDocumentEntry.authorSpecialty as the primary metadata, and XDSDocumentEntry.specialtyCode as the secondary metadata.
5.3.2.1 Using XD* to Query for Document TypeIn this scenario, XD* metadata would be structured to support queries of a Document Registry. The query would be performed using the XDSDocumentEntry.typeCode, and this value would be constrained to LOINC PART NUMBERS as specified in the LOINC Clinical Document Ontology – Document Type value set.
5.3.3 Querying using the RoleThe Registry Stored Query transaction that occurs would focus on querying for documents using the XDSDocumentEntry.authorRole value.
5.3.3.1 Using XD* to Query for RoleIn this scenario, XD* metadata would be structured to support queries of a Document Registry. The query would be performed using the XDSDocumentEntry.authorRole, and this value would be constrained to LOINC PART NUMBERS as specified in the LOINC Clinical Document Ontology – Role value set.
5.3.4 Querying using the Care SettingIn this scenario, XD* metadata would be structured to support queries of a Document Registry using the XDSDocumentEntry.practiceSettingCode as the primary metadata, and XDSDocumentEntry.specialtyCode as the secondary metadata.
5.3.4.1 Using XD* to Query for Care SettingThe Registry Stored Query transaction would specifically focus on the XDSDocumentEntry.practiceSettingCode and this value would be constrained to a specific set of codes that are mapped to the LOINC PART_NUMBERS specified in the LOINC Clinical Document Ontology – Type of Setting value set.
5.4 Querying Remote Registries or RepositoriesThe implementation scenario for using the LOINC Clinical Document Ontology to query for clinical document types that are specified at other data sources would be predicated on use of existing methods already specified as part of previous use cases.In this scenario, implementation would be focused on supporting queries to remote registries of information, such as a Document Registry or Metadata Registry which contains patient and/or administrative information
1. Requests documents by LOINC code2. Receives list of possible matches3. Receiver has documents which fit multiple document codes-->creates copy of
document with each code that document fulfills
There could be multple implementation approaches that could support this type of implementation
5.4.1 Query using IHE XCA
5.5 Vocabulary Considerations for SNOMED-CTThis section covers ideas that have been previously considered for alternative implementations of the LOINC Clinical Document Ontology, mainly through representatives of SNOMED-CT. This section provides initial thoughts on how approaches using other terminologies, such as SNOMED-CT, could support implementation of the LOINC Clinical Document Ontology.
5.5.1 Populate value sets for individual dimensionsValue sets are mapped to SNOMED-CT and other usual and customary terminology systems to facilitate interoperability, deployment, query, completeness, and reuse.
5.5.2 Generate full (combinatorial) ontology The possibility of using the LOINC Clinical Document Ontology in combination with SNOMED-CT and its definition of clinical documents could also be a consideration for
some organizations interested in implementing an ontology of clinical document types.
5.5.3 Map legacy LOINC codes into SNOMED-CT OntologyFor the SNOMED-CT ontology to work as planned it will require mapping from SNOMED-CT to those codes specified in the current LOINC Clinical Document Ontology
5.6 Long Term Implementation ConsiderationsThe proposed implementation approach within this implementation guide would begin by reusing the existing components of LOINC and its LOINC Clinical Document Ontology. The intent of this implementation guide approach is to establish an initial document taxonomy using the current structure of LOINC. Expansion of the LOINC terminology to support additional attributes is not precluded by this implementation guide.
6 VALUE SET MAPPING TO ONTOLOGYWhile the document types themselves all have codes in LOINC, the value sets corresponding to the dimensions of the ontology do not.
The expected intention for this implementation guide is to both:
1. Clearly identify the value set that corresponds with each of the axes within the ontology
2. Map all values in those value sets to corresponding SNOMED CT codes
To support the implementation guide value set mapping to the LOINC Clinical Document Ontology, this implementation guide will reference the work already performed as part of HITSP C80.
7 REFERENCESSeveral references, both formal and informal, were used to create this implementation guide. Each of these references were used in support of development and the usage of the specific reference is also detailed below.
Name of Reference Proposed Usage in this Implementation Guide
LOINC Clinical Document Ontology The primary source for the values populated in this implementation guide is the LOINC Clinical Document Ontology and its representation within RELMA
HITSP C80 HITSP C80 and specifically the Document Type value set defined in HITSP C80 are used as references to support specification of the referenced clinical document types
LOINC® Document Ontology Proposed Extension and RevisionCoonan, 2011
This white paper and supporting slide deck were used as part of research for the implementation guide and to provide additional material for support of certain sections in the implementation guide.
Document Ontology Proposed Changes for Harmonization
This spreadsheet documented specific harmonization proposals that were included in the initial version of the LOINC Clinical Document Ontology. This spreadsheet was referenced to ensure no duplication of existing work efforts.
Logical Observation Identifiers Names and Codes (LOINC) Users' Guide
Chapter 7 is the primary reference resource for defining and maintaining the document ontology
Huff SM, chair. Document Ontology Task Force. Proposal for an Ontology for Exchange of Clinical Documents. [monograph on the Internet] Ann Arbor: Health Level Seven, Inc. c1997–2005
The initial proposal for the LOINC Clinical Document Ontology was used as a major source for initial information on how to structure the implementation guide and define potential uses for implementation
Huff SM, Rocha RA, McDonald CJ, et al. Development of the Logical Observations Identifiers, Names, and Codes (LOINC) vocabulary. J Am Med Inform Assoc. 1998;5:276–92
Additional research sources for the implementation guide
Huff SM, Frazier P, Dolin RH. HL7 LOINC Document Type Vocabulary Domain Paper. [monograph on the Internet] Indianapolis: Regenstrief Institute, Inc. c2004
Additional research sources for the implementation guide
ABMS American Board of Medical SpecialtiesAMA American Medical AssociationCCD Continuity of Care DocumentCDA Clinical Document ArchitectureCDC Centers for Disease Control and
PreventionDAM Domain Analysis ModelDICOM Digital Imaging and Communications in
MedicineEHR Electronic Health RecordDSTU Draft Standard for Trial UseH&P History and PhysicalHIT healthcare information technologyHITECH Health Information Technology for
Economic and Clinical HealthHITSP Health Information Technology Standards
PanelHL7 Health Level SevenHHS U.S. Department of Health and Human
ServicesHTML Hypertext Markup LanguageIG Implementation GuideIHE Integrating the Healthcare EnterpriseIHTSDO International Health Terminology
Standard Development OrganisationLOINC Logical Observation Identifiers Names
and CodesMIME Multipurpose Internet Mail ExtensionsNUCC Healthcare Provider Taxonomy CodeONC Office of National CoordinatorPCP Primary Care ProviderPDF Portable Document Format
RELMA Regenstrief LOINC Mapping AssistantRIM Reference Information ModelSDWG Structured Documents Working GroupSDO Standards Development OrganizationSNOMED CT Systemized Nomenclature for Medicine –
Clinical TermsUCUM Unified Code for Units of MeasureUML Unified Modeling LanguageURL Uniform Resource LocatorXPath XML Path Language
New and Updated Clinical Document Types will be populated in this appendix as the implementation guide follows the HL7 balloting process. This will allow for tracking of any proposed changes
Clinical Document Type Short Name LOINC IDNew clinical document types
The next table represents a matrix of the conformance verbs used across the standards reviewed for the consolidation guide. Cells with a dash (-) did not have an equivalent conformance convention.
This table is drawn from the HL7 Consolidated CDA Conformance Verb matrix.
RFC 2119 HL7 IHE HITSP Workgroup Consensus
SHALLAbsolute requirement of the specification
SHALLRequired/Mandatory
R (Required)Element must be present but can be NULL
R (Required)Data elements must always be sent. A NULL can be sent.
SHALLElement must be present but can be NULL
Where necessary to explicitly preclude nullFlavor (e.g. where you want to preclude nullFlavor on observation/value), can include something like "SHALL NOT include nullFlavor".
Where SHALL is applied to an attribute, it must be present and cannot be a NULL
SHALL NOTAbsolute prohibition of the specification
SHALL NOTNot Required/Mandatory
- - SHALL NOTAbsolute prohibition against inclusion
SHOULDRecommendedThere may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
SHOULDBest Practice or Recommendation
R2 (Required if known)The sending application must be able to demonstrate that it can send all required if known elements, unless it does not in fact gather that data. If the information cannot be transmitted, the data element shall contain a value indicating the reason for omission of the data.
R2 (Required if known) If the sending application has data for the data element, it is REQUIRED to populate the data element. If the value is not known, the data element need not be sent
SHOULDBest Practice or RecommendationThere may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course
SHOULD NOTNot Recommended
SHOULD NOTNot Recommended
- - SHOULD NOTNot Recommended
MAYOptional
MAYAccepted/Permitted
O (Optional) O (Optional) MAYOptional
- - C (Conditional)A conditional data element is one that is required, required if known or optional depending upon other conditions.
C (Conditional)Required to be sent when the conditions specified in the HITSP additional specifications column are true
APPENDIX D - EXTENSIONS TO LOINC DOCUMENT ONTOLOGY
If a specific representation of a document type cannot be found within the LOINC Document Ontology, extensions to the ontology will be supported. These extensions will be developed . This section serves to summarize the process for submitting extensions and implementation guidance on how to do so. Extensions created for this guide would follow several rules that would be subject to HL7 and LOINC review
Proposed extensions should not replicate existing document types to provide new metadata
To resolve issues that need to be addressed by extension of an ontology, the developers of this guide chose to approach extensions as follows:
An extension should include element or attribute declarations and rules for the specific document type proposed for addition
All extensions would initially be considered as optional. An extension may be used, but need not be required for use as defined by this guide
The HL7 Structured Documents Working Group shall be the initial body charged with reviewing extensions
This ontology shall be used as the primary source for any extension elements or attributes that are defined for new clinical document types
Each extension element shall use the same conventions for order and naming as is used within this ontology