6 - Document Ontology

This section last updated: 2024-08-06 (5 months ago)

This section describes our approach to creating a set of document type codes. This work began as a collaboration between the LOINC committee and the HL7® document ontology task force, with initial contributions from Stan Huff, Pavla Frazier, Bob Dolin, and Clem McDonald. The background and initial development of the ontology was described by Frazier et al.¹ Over time, we have continued to make many refinements to this ontology. In particular, we have received exceptional contributions from colleagues at Columbia University and the U.S. Department of Veterans Affairs.

6.1 Introduction to the use of LOINC document type codes

In creating and maintaining document type codes, it is important to distinguish between the purpose of local document names and the names represented by the document type code. Document type codes are created to provide consistent semantics for the names of documents when they are shared or exchanged between independent facilities or enterprises. The names and codes that are used locally within an enterprise are entirely under the control of the local enterprise, and these names are valuable to the workflow and access of information within the enterprise. It is assumed that the exact local name for the document will be retained in the system that created the document, and that the local name can be sent along with the document type code when the document is sent to an external organization. The document type code should only express the meaning in a document name that can be shared between independent organizations.

For example, it is appropriate to have local document names like “Dr. Smith’s Tuesday Pain Clinic Note” or “Albuquerque VA General Medicine Consult Note” for use within an enterprise. However, some parts of these very specific local names are not meaningful outside of the originating enterprise. Thus, proper document type codes would have names like “Outpatient Pain Clinic Note,” or “General Internal Medicine Consult Note.”

The naming rules in this Document Ontology apply primarily to “clinical notes.” For purpose of this Users’ Guide, a clinical note is a clinical document (as defined by the HL7 CDA Standard), where clinical professionals and trainees produced the document either spontaneously (e.g., I write my admitting note) or in response to a request for consultation. “Clinical Notes” provides a better description of the process.

“Clinical Notes” are to be distinguished from patient reports such as radiology reports, pathology reports, laboratory reports, cardiac catheterization reports, etc., that are generated in response to an order for a specific procedure. Names for most of these later concepts are accommodated well by the clinical LOINC naming structure, and many such codes already exist within the LOINC database.

We must also emphasize that the names constructed in LOINC are based on the expected information content of the document, rather than the document format. This is to say that the same LOINC code would be used to represent a given document type regardless of whether it was in PDF, text document, JPG, XML, or HTML formats – if the information content contained by those documents were the same.

6.2 Relationship to other standards

6.2.1 HL7

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.

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). Our approach to manage this overlap is:

• Create a mapping from LOINC codes to HL7 V2.x document codes.
• Continue to develop LOINC codes to meet the needs of the HL7 V3 domain that are not present in the V2.x tables.

Many of the document terms (Document Ontology and Radiology) should have one or more AssociatedObservations values that represent the related HL7 C-CDA "recommended sections" panel term, as well as the appropriate values in the HL7_ATTACHMENT_STRUCTURE and ValidHL7AttachmentRequest fields. These fields are needed for information exchange between payers/providers and were developed in conjunction with the HL7 Payer/Provider Information Exchange (PIE) Work Group.

6.3 Elements of document type codes

In the following, synonymy or equivalent terms are designated by parenthesis. Document codes are defined by their component parts. The first list of axis values was published in 2003, and served as the basis for an initial set of LOINC codes.

Through both empiric analysis and expert review, we have continued evaluating and refining this list. The following listing contains the current set of axis values for the elements of document type codes that have been vetted by the LOINC Committee. We are in the process of carefully harmonizing our existing Document terms with these new values.

6.3.1 Kind of Document

Description: Characterizes the general structure of the document at a macro level. Document types are differentiated based on the need to define distinct document headers.

Allowed Values:

Further explanation of LOINC’s use of "Note" (i.e., a Clinical Note, also known as "Clinical Document") versus "Report": In LOINC, a Note is a document generated by a clinician as part of patient care and includes notes written at the initiative of “individual clinic and consulting clinicians.” In contrast, a Report is usually generated in response to an order, e.g., radiology, pathology, and cardiac catheterization reports. In general, we will not make two distinct LOINC codes for concepts that have all of the same attributes except that one is a Note and one is a Report. Requests for such pairs of codes (or a request for a note when a report term exists or vice versa) will be reviewed on a case by case basis.

Clinical documents meet five criteria, as defined in CDA 1.0: wholeness, stewardship, authentication, persistence, and human readability.

6.3.2 Type of Service

Description: Characterizes the kind of service or activity provided to/for the patient (or other subject of the service) as described in the note. Common subclasses of service would be evaluations, consultations, and summaries. The notion of time sequence, e.g., at the beginning (admission) or at the end (discharge), is subsumed in this axis.

Allowed Values:

6.3.3 Setting

Description: Setting is a modest extension of CMS’s coarse definition of settings, which have well-defined meanings. Setting is not equivalent to location, which typically has more locally defined meanings and is reported in other parts of the message. Setting would be limited to one of the following categories (with some future extensions possible).

Most clinical report names would include a setting (at least at the top level) to avoid confusion between important classes of reports. For example, The Admission H&P is usually taken to be the Hospital Admission H&P, but it could be confused with the nursing home H&P if not distinguished by the setting. Setting is not a required component of the name.

Allowed Values:

6.3.4 Subject Matter Domain (SMD)

Description: Characterizes the subject matter domain of a note.

Allowed Values:

6.3.5 Role

Description: Characterizes the training or professional level of the author or the party responsible for the content in the document. The role category is a high-level classification that does not get as detailed as specialty or subspecialty so as to avoid potential overlap with the subject matter domain axis.

Allowed Values:

6.4 Rules for creating clinical notes from multiple attributes

Names for required clinical notes would be constructed by picking entries from the Kind of Document axis and at least one of the other four axes (see exceptions in Section 7.4.1). The LOINC committee will create LOINC codes for all required combinations (not all possible combinations).

The original Document Ontology terms were created only for the document type of “note” and with the general naming pattern:

<Subject Matter Domain> : <Training / Professional Level>: <Setting>: <Type> : Note

As we have revised and refined the elemental axes in the Document Ontology, simple names would be constructed and ordered as follows:

In general, combinations from within an axis are allowed in a term name where they make sense (typically, SMD and Service), but are disallowed where they do not (typically, Role and Setting). Combinations will be represented with a plus (+), so as to distinguish from elements containing “and” or “&”. Where a particular element is not defined for a given term and leaves a LOINC axis blank, the LOINC name will include the {} naming convention. For example, if a Setting is not designated, the System will be {Setting}. Where neither the SMD nor Role is specified, {Role} is used in the Method (as of LOINC version 2.54).

LOINC codes for clinical notes designed according to this model and are assigned a Class of DOC.ONTOLOGY. The Class name was changed in LOINC version 2.50 from DOC.CLINRPT to DOC.ONTOLOGY, a more representative name for all types of documents (not just clinical reports) included in the LOINC Document Ontology.

Example LOINC codes in the Document Ontology include:

For every clinical note term we create with a designated Setting, SMD, and/or Role, we will also create a general “roll-up” term where the Setting, SMD and Role are not specified, i.e. they are defined as {Setting} and {Role}. The LOINC Committee has agreed not to create a general document code in some cases, including:

1. The Component contains only one axis value, either a Type of Service or Kind of Document. Such a generic code (absent the other attributes) would violate the current policy to include the Kind of Document plus at least one other axis value.
2. The general type of clinical document is not likely to ever exist.

Example LOINC codes that do not have a general clinical note term include:

6.4.1 Exceptions to rules for creating clinical notes

As noted above, the current policy for creating clinical notes is to include the Kind of Document plus at least one other axis value. The LOINC Committee has agreed to make exceptions to the Document Ontology rules for cases where only Kind of Document is commonly designated (e.g. Driver license).

Example LOINC codes that are approved exceptions containing only a Kind of Document:

The LOINC Committee also recognizes the need for terms with only a general Kind of Document (e.g. Letter, Note, Report) designated. We have agreed to create such terms, however, they will have a status of “discouraged” to caution users. If these general terms are used, we strongly recommend that they are used in a post-coordinated manner in conjunction with one of the LOINC terms included in the LOINC Document Ontology associated observations panel (LOINC: 80582-0) to carry the relevant attribute specifications.

6.5 Document Ontology content in the LOINC distribution

Beginning with LOINC version 2.44 (June 2013), a delimited text file containing the relationships between clinical document terms (i.e. those within the Class of DOC.ONTOLOGY) and their associated ontology axis values is available as part of the LOINC download from http://loinc.org. The document ontology axis values have been assigned LOINC Part identifiers and classified according to their document ontology axis. This file defines the relationships between a given LOINC term and its ontology axis values through these fields: LoincNumber, PartNumber, PartTypeName, PartSequenceOrder, PartName. These fields are largely self-explanatory, but of note is that the PartTypeName corresponds to the Document Ontology axis, and the PartSequenceOrder is relevant for terms that combine axis values from within an axis (see Section 7.4).

Beginning with LOINC version 2.68, a computable format of the LOINC document ontology hierarchies and the relationships of all ontology parts to LOINC terms has been available in a Web Ontology Language (OWL) format. Since OWL is a standard format for representing ontological information, it is possible to query that knowledge, build visual representations, and make inferences if you have the right tools. The OWL file along with further information can be downloaded at https://loinc.org/document-ontology/owl/.

6.6 Future work

We continue active development and refinement of the Kind of Document axis. As we continue this work, we intend to develop equally specific definitive documents for other kinds of health care associated documents.

6.7 Proposing new LOINC document terms

New LOINC document type codes can be proposed using the process described in Appendix D. In general, new term proposals that contain allowed combinations of existing axis values will be made expeditiously by Regenstrief staff. Requests for document titles containing new axis values to be added to the ontology will be reviewed by the LOINC committee, and thus their final modeling may take a bit longer.

In LOINC, a Note is a document generated by a clinician as part of patient care and includes notes written at the initiative of “individual clinic and consulting clinicians.” In contrast, a Report is usually generated in response to an order, e.g., radiology, pathology, and cardiac catheterization reports. In general, we will not make two distinct LOINC codes for concepts that have all of the same attributes except that one is a Note and one is a Report. Requests for such pairs of codes (or a request for a note when a report term exists or vice versa) will be reviewed on a case by case basis.

---

1. Frazier P, Rossi-Mori A, Dolin RH, Alschuler L, Huff SM. The creation of an ontology of clinical document names. Stud Health Technol Inform. 2001;84(Pt1):94-8. PubMed: 11604713.↩