HDR Version 7 HL7 Version 3 Messaging Conformance Specification

2 HDR Conformant Vocabulary

Introduction

The contemporary healthcare domain requires the use of a variety of code systems for functions such as billing, epidemiological reporting, and ordering or documenting clinical services. Healthcare providers and administrators are under increasing pressure to evaluate the quality, effectiveness, and cost of clinical care. The data necessary for this analysis contained in clinical records, includes a wide array of conceptually redundant terms and phrases, typically in the same clinical record. This makes computer processing to support quality of care review, utilization review, and other aggregate analyses problematic.

The terminology problem is one of the greatest obstacles to the automated use of computer-based clinical information for administrative purposes, health outcomes analysis, and clinical care.

The solution to the terminology problem lies in the use of concept representation systems, controlled sets of codes and terms that represent concepts. Concept representation systems provide the symbolic representations that enable computer processing while also providing appropriate natural language display for human users.

Healthcare applications utilizing a core set of concepts enable semantic interoperability, support the use of decision support, and facilitate the delivery of contextually appropriate information at the point of care, a key requirement for improving both clinical care and resource utilization.

Accepted best terminology practices in healthcare informatics include immutable concepts (concepts that do not change over time), context-free concept identifiers (the code used to identify a concept does not indicate a position in a taxonomy), allowed synonymy, and ontological support (concept-to-concept relationship information). Due to the development and maintenance costs of terminology systems, it is unlikely that a single, monolithic concept representation system will emerge with broad coverage of medicine. It is more likely that specialized terminology systems and code sets will continue to be developed, each covering a particular medical concept space.

This demands an application solution implementing access to various terminological or code systems using a standard interface. This is the goal of Oracle's Enterprise Terminology Services (ETS). The ETS component of Oracle Healthcare Data Repository (HDR) implements access to terminology systems that form the basis for a common concept space.

This section contains the following topics:

Top

2.1 HL7 Vocabulary Domains

Each coded attribute in the RIM is associated with a vocabulary domain. Within HL7, a vocabulary domain is the set of all concepts that can be taken as valid values in an instance of a coded field or attribute. For several of these vocabulary domains, HL7 provides vocabulary content in the form of HL7 code systems and concepts. These HL7 code systems are distributed with HDR as part of the seeded vocabulary content in ETS.

For some other vocabulary domains, HL7 references an external code system but does not specify the contents. In such cases, HDR has included the code system if it can be distributed without a license. There are three such code systems: NUBC-UB92, IETF RFC 1766 (ISO 639-1), and ISO 3166-1. Note that new versions of these code systems are not included in each HDR release. This content is available to customers from HDR's content management partner.

Top

2.2 HDR Concept List

Since the HDR repository is based on the RIM, there is a one to one correspondence between RIM coded attributes and HDR coded attributes. Each HDR coded attribute is bound to a unique seeded concept list that represents the vocabulary domain of the corresponding RIM attribute. For example, the disabilityCode attribute in the Person class is bound to the CL_PSN_DISABILITY_CODE concept list.

If a coded attribute has a vocabulary domain with HL7 specified content, the corresponding concept list is seeded with that content. For example, the RIM specifies PersonDisabilityType as the vocabulary domain for Person.disabilityCode. HL7 provides a code system with disability concepts to populate this domain. All these concepts have been seeded in the CL_PSN_DISABILITY_CODE concept list.

When RIM based objects are submitted by HDR APIs for persistence, the contents of most coded attributes undergo two forms of validation:

• The code must be part of a code system that is present in ETS.
• The code must belong to the concept list that is bound to the coded attribute Exceptions are Act.code, Role.code, Entity.code, and LanguageCommunication.languageCode.

If either validation fails, the submission is rejected.

The inbound message processing service also uses these RIM based objects and APIs to persist information from received messages. Therefore, inbound messages are subject to the same validation. If the value in a coded attribute of a received message does not appear in the corresponding HDR concept list (with the exceptions noted above), the message will be rejected.

Top

2.3 Extensibility

The vocabulary domain specification for a coded attribute in the RIM is accompanied by an Extensibility Qualifier. The Extensibility Qualifier has two possible values:

• CNE (coded no extensions)
• CWE (coded with extensions)

The CWE value for the Extensibility Qualifier means that the code set can be expanded to meet local implementation needs. In HDR, the concept lists corresponding to such attributes are defined as extensible concept lists. This means that while HL7 concepts that are already seeded may not be removed, additional concepts from any ETS code system may be added to suit the list to local needs.

HL7 terminology has been supplemented with three external code systems referenced by HL7 -- NUBC-UB92, IETF RFC 1766 (ISO 639-1), and ISO 3166-1. In addition, an Oracle-maintained code system, HDR Supplemental, provides additional coded terms that are required to support HDR solution areas, but are presently unavailable from standard HL7 code systems.

The CNE value for the Extensibility Qualifier means that the code set is fixed and cannot be extended. A concept from the specified domain must be sent as the value of the coded field in a message. In HDR, concept lists corresponding to such attributes are defined as system concept lists. This means that concepts can not be added or removed from these lists. These concept lists will always contain the finite content specified by HL7 and seeded by Oracle.

RIM attributes that have CNE vocabulary domains are referred to as structural attributes because their value establishes essential properties such as the class and status of an object. By tightly controlling these codes and their meanings, HL7 ensures that systems based on a particular version of the RIM share a basic degree of interoperability.

Some RIM datatypes have coded components with CNE vocabulary domains represented in HDR using system concept lists.

The following table lists the structural attributes and their system concept lists:

The following table lists coded datatype components and their system concept lists:

The following table lists non structural coded attributes and their extensible concept lists:

For details about the content seeded in each list, refer to the Oracle Healthcare Data Repository Javadoc.

Top

2.4 HDR Master Catalog

Acts, Roles, and Entities have a special subset of attributes that establish the type of action, competency or thing that they represent.

The Master Catalog is a mechanism by which one can configure the specific types of Acts, Roles and Entities that are valid for a particular HDR installation. Any Act, Role, or Entity that is part of an inbound message must be valid according to current Master Catalog configuration for the message to be successfully processed.

For focal classes, the message processor performs additional validation by verifying that it matches the Master Catalog entry configured for that specific trigger event.

For additional information about the Master Catalog, refer to the Implementing Master Catalog section of the Oracle Healthcare Data Repository Implementation Guide.

Top

2.5 RMIM Vocabulary Constraints

When RMIMs are created, one of the constraints that can be applied to a RIM coded attributes is to further restrict the vocabulary domain. This restriction can assume one of the following forms:

1. A single leaf code from the vocabulary domain is chosen as the only allowed value. When this restriction is applied to one of the attributes in Table 2.5-1, the value is represented as a default for that attribute in the XSD. The expectation is that the sending system or interface engine will default the attribute to that value if no value is available or supplied.

When the outbound message processor is requested to generate a message based on such an XSD, it will automatically populate the defaults for these attributes if they do not have any values in the repository. See Figure 2.5-2 below for an example.

Figure: 2.5-2 Example of defaults represented in XSD

   <xs:complexType name="COCT_MT030200HT03.ProviderPerson">

    <xs:attribute name="classCode" type="EntityClass" default="PSN"/>

      <xs:attribute name="determinerCode" type="EntityDeterminer" default="INSTANCE"/>

   </xs:complexType>

The HDR inbound message processor does not validate that a code sent in such an attribute matches the default specified in the schema. However, Concept List validations and Master Catalog validations are always performed.

For all other coded attributes, any leaf code restriction of the vocabulary domain is not represented in the schema. Implementers must consult the RMIMs, HMDs, and this document to determine if a restriction is important for their business process and enforce it accordingly.

2. An abstract or specialized code from the vocabulary domain is chosen as the restriction. In HL7 terms, this means that the value for that attribute must be restricted to a specialized code or leaf code that is a child of the specified code.
   
   The HDR inbound message processor does not validate that a code sent in such an attribute matches a child of the specified code. This type of restriction is not represented in the schema. Implementers must consult the respective RMIMs, and HMDs to determine if a restriction is important for their business process and enforce it accordingly.
   
3. A free text code or description is provided in the RMIM. This convention is used when the desired code is not provided by HL7 and comes from an external code system. In these cases, the implementer must consult the RMIM to determine the actual code and code system that is recommended.
   
   The HDR inbound message processor does not validate that a code sent in such an attribute matches the restriction. This type of restriction is not represented in the schema. Implementers must consult respective RMIM to determine if a restriction is important for their business process and enforce it accordingly.

Top

2.6 Coded Datatype Component

There are two pieces of information that are needed in order to resolve an HL7 coded datatype into a concept that HDR understands. These are the code system and code. A code system version may also be sent; in its absence, the default configured in ETS is adopted.

For structural attributes, the coded datatype is CS. It allows only the code component. This is adequate in these cases because the set of codes for each attribute is tightly regulated by HL7 and is implicit in every message that is based on a particular RIM version.

For other attributes that have CE or CD as the datatype, the code system and code must be sent.

There are two components of coded datatypes that can be used to reference the code system. These are:

• codeSystem: an OID style identifier Example: 2.16.840.1.113883.6.5
• codeSystemName: a human readable name Example: SNOMED

For HDR Conformance, the codeSystem should be sent. This will ensure the greatest interoperability since the human readable codeSystemNames have not been standardized. However, message processing will succeed even if the codeSystemName is sent instead. When a codeSystemName is sent, it should correspond exactly to the name assigned by the ETS Administrator at the time of loading the terminology. For example, if the ETS Administrator loaded ICD codes using the name ICD-9-CM, a message that referred to the codeSystemName as ICD9-CM would fail.

For the names and OIDs of code systems that are supported by ETS, refer to the Oracle Healthcare Data Repository Implementation Guide.

Top

2.7 First Data Bank Drug Codes in Messaging

ETS stores a modified version of codes from FirstDataBank's National Drug Data File Plus (NDDF Plus) product. To each code, a suffix is appended depending upon the type of concept. This creates a unique code for all the concepts in the ETS FDB coding scheme.

Codes from NDDF that are sent to HDR in HL7 messages must be appended with the following suffixes:

For example, an FDB MED Medication Name concept with code 00002835 must be sent to HDR with the code set to 00002835-MEDNM and the codeSystemName set to FDB. FDB NDDF Codes received from HDR also carry these suffixes.

Top