ISO13582-part1

History of Titles

• ISO/TC 215/WG 3 NWI Proposal 680, TS "Health Informatics - Communication model and XMLInterface Specification for OID Registries (ComoXOID)", 2008.
• ISO 13582 - Health informatics - Communication and metadata model and XML-interface specification for OID registries in healthcare - Technical Specification. 2010
• ISO 13582 - Health informatics - Sharing of OID registry information - Technical Specification. 2010

Stage

20 preparatory, approved for registration as DIS

Legenda

In this specification the follwing symbols are used.

Scope

This International Standard specifies the mandatory and optional information to be recorded in any registry of OIDs, using an information model.

It specifies what parts of that information shall be regarded as public, and what parts shall be subject to security and privacy requirements.

In detail, this International Standard:

• specifies an information model and a corresponding XML format for the export of the contents of an OID registry, suitable e.g. for import to a different OID registry
• references common uses cases for OID registries/repositories
• references an Object Identifier Resolution System (ORS) which provides a look-up mechanism for information related to an object identifier, with guidance on the use of that facility.

Normative References

The following normative documents contain provisions which, through reference in this text, constitute provisions of this ISO 13582. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. However, parties to agreements based on this ISO 13582 are encouraged to investigate the possibility of applying the most recent editions of the normative documents indicated below. For undated references, the latest edition of the normative document referred to applies. Members of ISO and IEC maintain registers of currently valid International Standards.

ISO/IEC 8601:2004, Data elements and interchange formats -- Information interchange -- Representation of dates and times

ISO/IEC 8824:1990(E), Information technology -- Abstract Syntax Notation One (ASN.1): Specification of basic notation

ISO/IEC 21090:2011, Health Informatics — Harmonizied datatypes for information interchange

ISO/IEC 22220, Health informatics — Identification of subjects of health care

IETF RFC 1738 - Uniform Resource Locators (URL)

IETF RFC 2396 - Uniform Resource Identifiers (URI): Generic Syntax

IETF RFC 2806 - URLs for Telephone Calls

IETF RFC 2978 - IANA Charset Registration Procedures

IETF RFC 3066 - Tags for the Identification of Languages

HL7 V3- Data Types - Abstract Specification (R2)

Terms, definitions and abbreviated terms

Terms and definitions

OID registry and OID repository

An OID registry maintains a list of OIDs.

Typically additional information (metadata, such as responsible organizations, a human readable name, a description of the object, and other information that is needed for any meaningful use of the object identified) associated with the OID is stored also. With that, a registry is then a repository at the same time.

Maintaining the list (and associated metadata) happens regardless whether it is an official register for allocations of new OIDs under a given OID arc, or just a copy of information from other registries.

Official OID registries/repositories responsible for allocations of new OIDs under a given OID arc are Registration Authorities.

Registration Authority (RA)

A Registration Authority (RA) is responsible for allocating child arcs to the OID that it manages (issuing authority).

It ensures that an integer is used once among the subsequent arcs (child OIDs). As much as possible, it avoids the same identifier (beginning with a lowercase letter) being used for multiple sub-arcs.

Such information is typically stored in the OID registry/repository but it is important to understand that an OID first need to be officially allocated by an RA before it can be described in an OID repository.

For each child OID, the RA also keeps a record of additional information (like name of a contact person, postal address, telephone and fax numbers, email address, etc.) about the Responsible Authority for that child OID.

A responsible authority for a child OID is formally becoming a RA for that child OID, as it may allocate sub-arcs.

Responsible (Managing) Authority (MA)

A Responsible (Managing) Authority (MA) is used to indicate the person (if known) and organization who is currently in charge of managing the OID.

Once a responsible authority is allocating sub-arcs and registering information on these sub-arcs, it also becomes the Registration Authority for these sub-arcs.

Submitting Authority (SA)

This information is optional and reflects the person or organization that submitted the original OID allocation request.

Relationship to and discussion of definitions from other sources

Current Registrant

In some OID registries, Current Registrants are stored. The definitions from other sources say that the Current Registrant is used to indicate the person (if known) who is currently in charge of managing the OID, allocating sub-arcs and registering information on these sub-arcs.

Discussion: simply managing an OID (for example for a code system) is a Responsible Authority MA. Potentially, a responsible authority may become a Registration Authority RA for a sub-arc if it allocates sub-arcs.

First Registrant

In some OID registries, First Registrants are stored. The definitions from other sources say that the First Registrant is used to indicate the very first person (if known) who was responsible to manage the OID and who created it in the first instance.

Discussion: Suggestion is to distinguish between a Registration Authority RA (person if known, and organization) who issued (= allocated the instance of) an OID and a Submitting Authority SA who submitted the OID allocation request (which may be the same instance). In this sense the First Registrant is the Registration Authority RA.

Note: Due to a comment from the Canadian ISO representatives Registration Authority even could be renamed to Issuing Authority.

First Registration Authority

The first Registration Authority of an OID is the very first person or company to whom the OID was allocated by the RA of the superior OID. According to Rec. ITU-T X.660 | ISO/IEC 9834-1, the first RA can't be changed (if the responsibility is transferred to someone else, the information is recorded in the "Current Registration Authority" section, without changing the "First Registration Authority" section).

Discussion: This is the Registration Authority RA that allocated the OID.

Rec. ITU-T X.660 | ISO/IEC 9834-1

In ITU-T Recommendation X.660 the following definitions are given.

3.6.8 registration authority: An entity such as an organization, a standard or an automated facility that performs registration of one or more types of objects (see also International Registration Authority).

3.6.2 administrative role (of a registration authority): Assigning and making available unambiguous names according to the Recommendation | International Standard defining the procedures for the authority.

3.6.14 technical role (of a registration authority): Recording definitions of the objects to which names are assigned and verifying that these definitions are in accordance with the Recommendation | International Standard defining the form of the definition.

This Technical Standard does not use administrative or technical roles.

Abbreviations

The following abbreviations are used for the terms defined in this International Standard and its annexes.

HL7 Health Level Seven Inc

IETF Internet Engineering Task Force

OID Object Identifier

OMG Object Management Group

W3C World Wide Web Consortium

XML Extensible Markup Language

Legenda of Tables and Symbols

Class Attribute and Association Tables

The Class Attribute Tables (information model) make use of the following table headline:

Attribute	Description	DT	Card	Conf	Length

where

DT = datatype conformant to the ISO 21090 datatypes,

Card = cardinality, e.g. 0..1 or 1..* etc.

Conf = conformance, either

• mandatory which means that the information SHALL be present in every instance of an extract of an OID registry/repository, or
• required which means that the information SHOULD be provided if there are no privacy reasons for masking that information, or
• optional when information is optional.

Length = recommended length (as an implementation hint e.g. for data base string lengths etc).

In addition, the Association Tables (information model) make use of the following table headline:

Association	Description	Class	Card	Conf

where

Association = the association name to the associated class

Class = the associated class name

Object Identifiers in healthcare

OID (Object Identifiers) are unique identifiers for any kind of objects. They are defined in Rec. ITU-T X.660 | ISO/IEC 9834-1 . This identification system for objects and concepts makes reliable electronic information exchange possible. Administration and Registration is regulated by a set of rules (see also ISO/NWIP/TR "Health Informatics – Guidance for maintenance of Object Identifiers OID").

The precise designation of objects and concepts is a pre-requisite for the standardized exchange of information. A globally unique identifier for each of these concepts will help to ensure international exchangeability of objects within different applications (e.g. healthcare information systems). For example, OIDs are often used within HL7 messages and documents, and Rec. ITU-T X.509 certificates to provide this unique identification.

In the exchange of healthcare information, especially between loosely coupled systems, additional information about the object being identified is generally very beneficial; this is information that is typically not contained in a transaction of data between systems but is reference information about the objects contained in the transaction. There is a minimal set of such information, such as Responsible Organizations, a human readable name, a description of the object, and other such information that is needed for any meaningful use of the objects identified. Since such information may not be locally available to a system examining the communicated objects, it makes sense to have such information available in a standardized form, and accessed by using the OID to identify this information. Such information, referred to as the OID metadata, is the bulk of the information housed in an OID Registry.

Today, due to lack of standardization of the set of metadata (both content and structure), existing OID registries are not compatible. Contents, attributes and rules of the assignment of OIDs of existing registries are incompatible and often dissimilar. Many registries still distribute OIDs in a form only suitable for direct text processing (like spreadsheets) that is error prone and hard to automate. There is a need to store and transfer collections of OIDs and also to keep some registries completely in sync, maintaining the contents and the structure of metadata of each of the registered OIDs e.g. descriptions, comments, versions, links, relations, responsible organizations and persons, etc.

Data exchange can be facilitated by a standardized representation of a required minimum set of metadata as an XML structure together with the associated checks of underlying constraints and business rules. This XML structure for importing and exporting OIDs amongst different registries should be achieved for supporting eHealth applications. In addition, the failure to have a standard for the operations needed to coordinated and synchronize the contents of disparate OID registries leads to confusion and ambiguity for the community that uses eHealth information containing references to objects identified by OIDs.

There are currently at least hundreds of OID registries in active use throughout the world. These are sponsored and operated by disparate entities, ranging from national governments, to individual companies or standards organizations, to individuals in a specialized area or industry. In many cases, more than one of these registries address the same industry segment, and have overlapping content, i.e. specific OIDs exist in both, or worse, different OIDs identifying the same object exist in both. This distributed set of disparate registries servicing a particular industry (specifically Healthcare IT) has led to awkward and error prone searching processes. To get information about existing OIDs, a search within all existing registries is needed, for example to avoid duplicate assignment of multiple OIDs to one and the same concept. In order to standardize the activities to synchronise all existing OID registries and to ensure further interoperability it is essential to have a defined exchange format and business rules for maintenance of the OID registries that must cooperate in a particular industry.

Some OID registries are operated by essentially volunteer organizations, such as Standards Bodies. The burden of administrative tasks is such that multiple individuals, often in different geographical locations, must participate to share the workload. Thus in addition to distributed Registry instances, administrative functions need to also be distributed, both on single and potentially across multiple Registries. There is a need for the standardization of a minimum set of administrative access and operational functions such that developers of Registries can deploy standard mechanisms to streamline and increase accuracy and productivity of these maintenance operations.

This Technical Standard describes a generic exchange format that will cover the minimal set of metadata and associated rules for OIDs of existing registries. It specifies principles and processes that should be explored/implemented by developers and data administrators of OID registries and their applicant bodies. The primary target group for this document are those establishing OID registries and those (industry, government bodies) using the services maintained by such organizations.

Additional descriptions

A general description of the registration procedures for various parts of the object identifier tree, by reference to other specifications and links to other documents is given in ISO 13581 - Health informatics - Guidance for maintenance of object identifiers, OID - Technical Report.

In informative Annex A, a description possible of sub trees reflecting OID categories for e-health related OIDs is given.

Informative Annex B specifies an Object Identifier Resolution System (ORS) for e-health related OIDs based on RESTful Web Services.

Informative Annex C references a W3C schema for the XML representation.

Related work

This work is related to discussions about OID in the work programme of TC 215 WG3, HL7, ISO/IEC JTC 1/SC 6, ITU-T SG 17 and other organizations dealing with OIDs and OID registries.

Approach

Requirement analysis

Following an extensive analysis of the currently available international OID register for health care systems, a basic data set and a corresponding XML representation as an exchange format need to be created for registering and exchanging OID-related data. To collect the very basic requirements to such a format an analysis of several registers (e.g. HL7 International register and several European registers was performed so far in 2009 (see Table 1). The analysis included the contents, attributes and even the rules of the assignment of OID.

Table 1: Analysis of some data elements of different OID registries and repositories (analysis as of 2009)

DIMDI	France Telecom-Orange OID repository	HL7 INTERNATIONAL
DESCRIPTIONENGLISH	DESCRIPTION, INFORMATION	OBJECT_DESCRIPTION
DESCRIPTIONGERMAN
ASN1NOTATION	ASN1-NOTATION	COMP_OID
MODIFICATIONDATE	MODIFICATION-DATE
CREATIONDATE	CREATION-DATE	DATE_FINALIZED
APPLICATIONDATE
TYPE		OID_TYPE
FAMILY	LAST-NAME	NAME
GIVEN	FIRST-NAME	NAME

Only a few of the registers specified an (XML-) exchange format. Due to lack of a common understanding of OID registry requirements, data fields must be mapped (manually) when OID information needed to be exchanged.

Preparatory work

This technical standard has been prepared by Technical Committee ISO/TC 215 "Health informatics" in collaboration with HL7 International, ISO/IEC JTC 1/SC 6 and ITU-T SG 17.

The draft of this document has had multiple public comment phases (started in April 2010) with the submission and reconciliation of about 80 comments and has undergone a proof-of-concept phase in OID registry/repository projects in several European countries.