Implement HDR Object Identifiers

HDR generates a unique identifier for each Act, Entity, and Role persisted through RIMServices. Each identifier is an Instance Identifier data type, consisting of a root that uniquely identifies the HDR instance and an extension that is unique within the HDR instance. Together, they uniquely identify the HDR act, entity, or role. The value used for the root is configured during the setup of HDR and needs to be unique to a given HDR instance to support the sending of HL7 messages between different HDR instances and other systems. If an organization has multiple HDR instances, each instance must have a separate OID. The root is considered the namespace for the HDR instance's identifiers and guarantees the uniqueness of the identifier among all HL7 compliant systems. That is, two objects created in two different systems may have the same extension but can be uniquely identified due to different roots.

Note:

User-defined or externally-supplied instance identifiers may also be persisted for an object. These are in addition to the system generated identifier. The system generated identifier guarantees that each object has at least one unique identifier.

This section describes how to configure the root object identifiers (OIDs) used for the various identifiers created by HDR.

A set of root OIDs must be configured during implementation to enable HDR to generate identifiers. Use the HDR Object Identifiers window to configure the root OID values for various identifier types. The various root OIDs defined using this window are used by HDR as a default root for the identifier, for the object being persisted.

Root OID values are not seeded because they are unique to each HDR installation. They are owned by the organization implementing HDR; they are not Oracle registered OIDs. Accordingly, the organization must obtain the OIDs from an appropriate issuing authority, such as HL7 or the standards authority relevant to their country. Alternatively, if the organization already owns an OID, they can use it or define a sub-OID to represent the instance of HDR. In order to enable interoperability with external systems, the root OID values must uniquely identify the HDR instance. Oracle will not supply the OIDs.

See also:

  • HL7 Web site: http://www.hl7.org/. Refer to the current version 3 ballot documentation for details on the OID and II data types.
  • ISO/IEC 8824 standard: http://www.iso.org/iso/en/ISOOnline.frontpage. Refer to the ISO standard for further details on OIDs.

The set of root OIDs requiring configuration at implementation apply to specific HDR features and need not be configured if the associated features are not required. However, all parts of HDR make use of the RIM Services feature and therefore, the INTERNAL_ROOT must be configured in order to persist HDR objects. It is the root for any HDR internal identifier, which is essentially the primary key of an object. The other root OIDs must be configured if certain EMPI, TCA, Messaging, Financials, Identification, or Migration features are to be used. See the table Optional Root Object Identifiers for further information about how each OID is used.

The user-defined or externally-supplied instance identifiers are not pre-configured in HDR. The root and extension for these external OIDs are sent from external systems or created via an application built on HDR.

Prerequisites

Obtain the relevant OIDs from the appropriate issuing authority, such as HL7 or the relevant standards authority. Alternatively, if the organization already owns an appropriate root OID (that represents the organization), they can use this OID or issue a sub-OID to represent the instance of HDR.

Procedures

The following chart provides an overview of the implementation process for HDR Object Identifiers:

Figure 2-7 Implementation process for HDR Object Identifiers

Implementation process for HDR Object Identifiers

Use the OIDService.registerOID API to register new OIDs in HDR.