ISO TC 215 - ISO TS 13581

ISO/TC 215 / SC WG3 NWI Proposal 679, ISO/NWIP/TS Health Informatics - Guidance for maintenance of Object Identifiers OID, 2008.

--Ted 15:19, 20. Okt. 2010 (UTC)Note that this is the approved project ISO 13582 which is a Technical Specification. Just to focus the mind: the draft for ballot is due January 2011.

Scope

This NWIP is a proposal for a new document. It specifies principles and processes that should be exhibited by developers and data administrators of OID (Object-Identifiers)-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 organisations. This Technical Report

• specifies procedures which are generally applicable to registration in the context of OID
• provides guidelines for the establishment and operation of Registration Authorities
• provides guidelines for additional Recommendations.

Introduction

The precise designation of objects and concepts is a prerequisite for the standardised exchange of information. Unique names, clear descriptions and responsible organisations for objects, concepts and messages are the basis for electronic data exchange. This helps to ensure international exchangeability of Objects within different applications (e.g. healthcare information systems).Versioning of OIDs and the rules of assignment are controversial issues, too. In worst case this requires re-writing of software products to reflect changes. There is a significant potential for errors to occur.

The development and maintenance of an OID Registry requires sustainable processes so that safe and consistent representation and interpretation of data and information can be supported over time. This document specifies the principles and procedures and the rules of assignment of OIDs that should be exhibited by an organization that maintain OIDs. In order to standardize these activities for at least health telematics and to ensure further interoperability it is essential to have central registers in each country and international rules for maintenance for the OID-Systems. These central registries secure the uniqueness of the OID for each concept and thereby avoid duplicates. The assignment of new OIDs is effected by following the rules of „Good practice for the assignment and usage of OIDs“ covered in this document.

OID-Registries require organisations that can accommodate the complex harmonisation of objects while maintaining longitudinal consistency and utility. Furthermore, OIDs form the foundation of many dependent systems, applications, and operations.

Terms and definitions

• object (of interest): Anything in some world, generally the world of telecommunications and information processing or some part thereof,
  • which is identifiable (can be named); and
  • which may be registered.
• object identifier tree: A specific form of tree whose root corresponds to this Technical Report and whose nodes correspond to registration authorities responsible for allocating arcs from a parent node.
• registration: The assignment of an unambiguous name and other parameters to an object in a way which makes the assignment available to interested parties.
• registration authority: An entity such as an organization, a standard or an automated facility that performs registration of one or more types of objects.

Business requirements for the maintenance of OID-Registers in health care system

300px

Good practice for the assignment and usage of OID

The assignment of new OID is effected by following the rules of "Good practice for the assignment and usage of OID".

• The structure of the OID does not represent a hierarchy or classification. It is solely used as a reference to a description. No other relationships should be inferred from any similarities, and no internal structure of an OID should ever be relied upon within an application.
• Once an OID is assigned it will never be taken back and stays a valid identifier for this concept.
• The assigning authority, being responsible for the uniqueness of the OID, checks the content of the OID-application. (Quality check)
• If an organisation becomes registration authority within the tree of OID they can assign OID self dependently by preserving the uniqueness.
• An authority should not assign an OID for concepts or objects being used not solely within its organization. These OID should be assigned by the central registry (…for each country).
• International OID should be assigned by a central international OID-Registry.
• The description of the OID is in the English language in order to ensure interoperability with other OID registers.
• The symbolic name of an arc is required to commence with a lowercase letter, and to contain only letters, digits, and hyphens. The last character shall not be a hyphen, nor shall there be two consecutive hyphens in the name (see ITU-T Rec. X.680 | ISO/IEC 8824-1).
• The limit of the amount of characters of the OID should be 64 characters. The practical limit for an internal arc is 2^31-1.
• OID for organizations can be applied for by all organizations within the Health Care System. One organization may apply for a generally valid OID, e.g. for code systems, if it already has an organization OID registered in an OID Registry.
• Generally, the organization responsible for the OID should register the OID (e.g. WHO: ICD-10). If responsibilities are not clearly allocated, the registration centre will decide.
• Only those persons mentioned in the application may change existing OID information.
• Beneath an organization-OID the organization has the possibility of allocating new object identifiers within the scope of ISO, CEN, DIN and HL7 specifications. However, should the registered OID become generally valid, they must be reported to the national and / or International Registration Authority.
• OIDs used for code systems (CD) and Instance identifier (II) SHOULD NOT be the parent for any other OID as code systems can’t really be an assigning authority for other concepts.

Recommendations for Implementers (HL7)

There are several assumptions made in this section with regard to the way that OIDs are managed.

• The organization uses the same identifier to uniquely identify a patient across different encounters and locations. This can either be the medical record number or master patient identifier used by the organization to identify a patient.
• The organization makes use of a single electronic medical record system (EMR) across its various locations of care.
• The organization uses the same identifier to uniquely identify personnel regardless of location.
• There is a manageable number of locations, and a way to uniquely identify each of these within the scope of the organization.
• There is a manageable number of entities that the organization places orders with, and a way to uniquely identify each of these within the scope of the organization.

Content of application

The specification of the content of register entries is including at least:

1. the name assigned to the object;
2. details of the organization, applicant and contact person that proposed the entry;
3. details of the responsible organization
4. the dates of submission/registration;
5. the definition of the object in English;

Mandatory content:

1. Version
2. Desired classification (organization, code scheme, document, identification mechanism)
3. Description on the internet
4. Description by file
5. Relation to other OID
6. Comments and Questions

Recommendation for top level arcs

The recommendation is that there are six arcs specified from the node (within the healthcare system):

--Ted 15:28, 20. Okt. 2010 (UTC)I disagree significantly with these arc recommendations. Although this follows relatively closely the HL7 International registry, the problems I have run into over thousands of registrations have led me to believe that this taxonomy is flawed.

• 3 instance-identifier
  • 3.1 organizations
  • 3.2 persons
• 4 identification mechanism
• 5 code schemes
• 7 documents
• 99 experimental

Once an organization receives a root OID of their own, it is recommended that they create arcs below that OID using the values in the table below.

--Ted 15:28, 20. Okt. 2010 (UTC)The use of the OIDs in the HL7 and ISO datatypes, both R1 and R2, primarily use the OID in the II.root to define a namespace for an identifier, or in the CD.codeSystem, which also defines the namespace for the concept codes. The way this is written, it implies that an OID should be assigned to individual patients, or individual providers, etc. This has caused, and continues to cause, havoc in the field, as nearly every single one of these objects already has an identifier, often one that is public and assigned/enforced through jurisdictional statute or regulation. I strongly believe that we should focus on the nature of OIDs as defining namespaces within which objects have their own identifiers; the OID makes these identifiers globally unique. Better yet - the taxonomy of OIDs is really only useful in enabling easy search and browse functions for registries, and to ease the administrative burden of maintaining a registry. For organizations and countries standing up their own registries, I think we should have a meta-description and map layout whereby folks can represent their own custom taxonomy, needed for their own purposes, and provide a means of translating it into the taxonomy used by others when sharing the OIDs.

Arc	Description
.1	Documents
.2	Patients
.3	Non-licensed Personnel
.4	Locations
.5	Non-licensed Organizations
.6	Devices
.7	Encounters
.8	Orders
.9	Sections
.10	Entries
.11	Templates

--Ted 09:58, 11. Okt. 2010 (UTC)This does not have a number of types of objects that are recommended in the C80 recommendations in the US (HL7 and US Government emerging regulations) such as Local Code Systems, Code Lists, Value Sets, instances of physical entities in documentation such as samples and containers, etc. In addition, some folks are using OIDs types to help administer other kinds of things, such as departments. DICOM assigns OIDs to films and other physical objects that are derived. Some are decentralizing registries themselves, and thus are defining OID nodes whose meaning is "everything under this node is handled by this other registry", where there is delegation of registry functions, rather than delegation of registration authority necessarily.

Business Requirements for an international and national Registration Authority

The need for an International Registration Authority for the healthcare system is there while more and more internationally accepted code systems are in use within medical communication (for e.g. SNOMED CT or MedDRA).

A Sponsoring (National) Authority is a national body, or a liaison organization.

The responsibilities of a Sponsoring Authority shall be as follows:

• to receive proposals concerning objects from within their respective countries or organization;
• to effect any necessary rationalizations or coordination of these proposals and to forward them to the International Registration Authority; and
• to make known within their respective countries or organizations the decisions taken on their proposals as transmitted to them by the International Registration Authority.

An International Registration Authority shall maintain a register of the names assigned to objects and the associated definitions and other relevant parameters of the objects. The form of name to be used and the form of register entry are defined in a TR - ISO/NWIP/TR Health Informatics - Communication model and XML-Interface Specification for OID Registries (ComoXOID).

With regard to the initial assignment of names and definitions to objects and of subsequent additions to the register, the responsibilities of an International Registration Authority shall be as follows:

• to receive from Sponsoring (national) Authorities proposals for register entries;
• to process proposals for entries according to the procedures specified in this Technical Report
• to record names for each register entry that is accepted, in accordance with the procedures specified this Technical Report;
• to promulgate the register entries
• to convey the results in a specified form to the appropriate Sponsoring (national) Authority when the processing of a proposal has been completed.

With regard to deletions from the register, the responsibilities of an international Registration Authority shall be as follows:

• to receive proposals from Sponsoring Authorities
• to process the proposals for deletion,
• to promulgate the register deletions
• to convey the results in a specified form to the appropriate Sponsoring (national) Authority when the processing of a proposal has been completed.

Bibliography

• [1] ITU-T Recommendation X.660, ISO/IEC 9834-1: 1993, Information Technology – Open Systems Interconnection – Systems Management Overview – Procedures for the Operation of OSI Registration Authorities: General Procedures, 1992
• [2] ITU-T Recommendation X.680, ISO/IEC 8824-1: 1998, Information Technology – Abstract Syntax Notation One (ASN.1), Specification of Basic Notation, 1997
• [3] DIN, Verfahrensgrundlage Informationstechnik Kommunikation Offener Systeme; Vergabe der Registrierungskennzahl (REG) für Informationsobjekte nach DIN 66334, 1996 [retired]
• [4] http://asn1.elibel.tm.fr/en/oid/index.htm
• [5] http://www.dimdi.de/static/de/ehealth/oid/index.htm
• [6] HL7 Version 3, Health Level Seven, Inc., http://www.hl7.org
• [7] HL7 Implementation Guidance for Unique Object Identifiers (OIDs), Release 1, 2008