ISO TC 215 - ISO TS 13582: Unterschied zwischen den Versionen

Aus Hl7wiki
Wechseln zu: Navigation, Suche
(Relationship to definitions from other sources)
 
 
(292 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
 
<!--{{WorkInProgress}}-->
 
<!--{{WorkInProgress}}-->
 
+
<div class="print-document-information">
=History of Titles=
+
    
* ISO/TC 215/WG 3 NWI Proposal 680, TS "Health Informatics - Communication model and XMLInterface Specification for OID Registries (ComoXOID)", 2008.
+
{| border="0" cellpadding="15" class="print-document-logohead"
* ISO 13582 - Health informatics - Communication and metadata model and XML-interface specification for OID registries in healthcare - Technical Specification. 2010
+
|- valign="top"
* ISO 13582 - Health informatics - Sharing of OID registry information - Technical Specification. 2010
+
| [[Datei:Logo-ISO.jpg|200px]]
 
+
| International Organization for Standardization<br/>TC 215 Health Informatics
=Scope=
 
 
 
This International Standard specifies the mandatory and optional information to be recorded in any repository 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.
 
{{BeginEMBox}}
 
All repositories shall support the recording of mandatory information, but the recording of an actual object identifier in one or more repositories is always optional.
 
 
 
In some cases, security and privacy requirements are more stringent for e-health applications. See Annex A for e-health requirements.
 
{{EndEMBox}}
 
In detail, this International Standard:
 
* specifies an XML format for the export of the contents of an OID repository, suitable for import to a different OID repository;
 
* specifies security procedures related to that export/import;
 
* references the 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.
 
{{BeginOIBox}}
 
Need to discuss whether this standard should specify security procedures and if so, how...
 
{{EndOIBox}}
 
 
 
=Introduction=
 
 
 
OID (Object Identifiers) are unique identifiers for any kind of objects. They are defined in Rec. ITU-T X.660 | ISO/IEC 9834-1<ref>[http://www.itu.int/ITU-T/studygroups/com17/oid/X.660-E.pdf|Rec. ITU-T X.660 | ISO/IEC 9834-1]</ref>. 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"<ref>[[ISO_TC_215-NWIP_679|ISO/NWIP/TR Health Informatics – Guidance for maintenance of Object Identifiers OID]]</ref>).
 
 
 
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 NWIP is a proposal for a new document and 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'''.
 
 
 
'''Annex A''' is a specific description for the registration procedures for e-health related OIDs, and includes a specification of those parts of the OID tree that are known to be used for national and for international e-health applications.
 
 
 
==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=
 
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<ref>[http://www.hl7.org HL7 International]</ref> register and several European registers<ref>[http://www.oid-info.com OID repository (France Telecom-Orange)]</ref><ref>[http://www.dimdi.de/static/de/ehealth/oid/index.htm OID registry (DIMDI, Germany)]</ref>
 
was performed so far (see Table 1). The analysis included the contents, attributes and even the rules of the assignment of OID.
 
 
 
{| class= wikitable
 
|+Table 1: Analysis of some data elements of different OID registries and repositories
 
! 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.
 
 
 
=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 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 subarcs and registering information on these subarcs, it also becomes the ''Registration Authority'' for these subarcs.
 
 
 
== Submitting Authority (SA)==
 
This information is optional and reflects the person or organization that submitted the original OID allocation request.
 
 
 
==Relationship to 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 subarcs and registering information on these subarcs.
 
{{BeginOIBox}}
 
Discussion: simply managing an OID (for example for a code system) is a ''ResponsibleAuthority''. Potentially, a responsible authority may become a RA for a subarc if it allocates subarcs.
 
{{EndOIBox}}
 
 
 
===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.
 
{{BeginOIBox}}
 
Discussion: What does "manage the OID" imply? What does "first" instance of an OID mean? Allocation? Once instantiated the OID exist forever.
 
 
 
Suggestion is to distinguish between an ''RegistrationAuthority'' (person if known, and organization) who issued (= allocated the instance of) an OID. Due to a comment from Canada the name even could change to ''IssuingAuthority''.
 
{{EndOIBox}}
 
Other sources: 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).
 
{{BeginOIBox}}
 
Discussion: This is the ''RegistrationAuthority'' that allocated the OID, the issuing authority.
 
{{EndOIBox}}
 
 
 
===Rec. ITU-T X.660 | ISO/IEC 9834-1===
 
In ITU-T Recommendation X.660 the following defintions 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.
 
 
 
=Abbreviations and acronyms=
 
TBD
 
 
 
=Use Cases=
 
A list of OID Registry Use Cases has been defined in order to drive metadata model requirements, and functional requirements for Registry interoperability.
 
 
 
==U1: OID Creation where the registry owner is the RA==
 
===Creation of a new OID in the standard ontological structure===
 
===Creation of a new OID in a sub-structure===
 
 
 
==U2: OID Registration==
 
===Registration where the registry owner created the OID===
 
===Registration of an OID created elsewhere===
 
 
 
==U3: OID Withdrawal/Replacement==
 
===Withdraw an OID created in error with no replacement===
 
===Withdraw an OID created in error with specified replacement===
 
===Withdraw an OID registered in error with no replacement===
 
===Withdraw an OID registered in error with specified replacement===
 
===Withdraw an OID that is found to be a duplicate, with original specified===
 
 
 
==U4: OID Metadata Update/Editing==
 
===Permissions model===
 
===Distributed effort model===
 
===Proxies for Editors===
 
 
 
==U5: OID Information Publication==
 
===Web presence===
 
===Internet-accessible API (Web service presence)===
 
===Full registry output to machine-readable form===
 
===Full registry output to human-readable form===
 
===Partial registry output to machine-readable form===
 
===Partial registry output to human-readable form===
 
 
 
==U6: OID Information Request==
 
===Search for the OID of an object===
 
===Search for the object identified by an OID===
 
===Search for a list of kinds of OIDs===
 
===Search for a list of OID based on various sub-criteria, with and without wildcards===
 
* Those registered by a particular entity
 
* Those associated with a type of information object
 
* Those associated with implementation guides
 
* Those registered during some time period
 
* etc.
 
 
 
=Communication model=
 
 
 
In order to exchange OID and their metadata between different registers and applications the following additional data items beyond the OID itself need to be taken under consideration (see also
 
<ref>[http://www.itu.int/rec/T-REC-X.680/en Recommendation ITU-T X.680 (2008) | ISO/IEC 8824-1: 2008, Information Technology – Abstract Syntax Notation One (ASN.1), Specification of Basic Notation, 1997]</ref>
 
<ref>[http://www.itu.int/rec/T-REC-X.667/en Recommendation ITU-T X.667 | ISO/IEC 9834-8: Information technology – Open Systems Interconnection – Procedures for the operation of OSI Registration Authorities: Generation and registration of Universally Unique Identifiers (UUIDs) and their use as ASN.1 object identifier components]</ref>):
 
* descriptions
 
* status information
 
* categorization
 
* time information
 
* comments
 
* versions
 
* links
 
* relationships to other OIDs and external sources
 
* registering and responsible organizations
 
* associated persons.
 
 
 
A communication model with all classes, attributes and their properties aiming on a common understanding of the requirements of an OID registry has been created.
 
 
 
[[Datei:Oidmodel.jpg| 500px |Communication Model (Draft)]]
 
 
 
=XML exchange format=
 
Data exchange can be facilitated by a standardized representation of the complete set of information as XML structure together with the associated checks of underlying constraints and business rules. This XML structure for importing and exporting OID amongst different registries and other healthcare applications is aiming on the availability of reliable information about OIDs.
 
 
 
The following sections summarise and explain classes and their attributes.
 
 
 
==ThisOIDregistry==
 
 
 
[[Datei:Oid-ThisOIDregistry.jpg | 200px]]
 
 
 
This is the basic information about the OID-Registry hosting the OIDs.
 
 
 
===Attributes===
 
 
 
{|class="hl7table"
 
! Attribute !! Description !! Datatype !! Cardinality !! Conformance || Recommended Length
 
|-
 
| validTime || validity time interval || IVL_TS || 1..* || mandatory || -
 
|-
 
| scopedOIDs || List of scoped root OIDs || OID || 1..* || mandatory || 64
 
|-
 
| name || Official name of the OID registry || ST || 1..1 || mandatory || 64
 
|-
 
| desc || Description of the OID registry || ST || 0..1 || optional || 2048
 
|-
 
|}
 
 
 
====validTime====
 
 
 
This is the validity time interval, i.e. the begin (and end) time when this registry is/was responsible for registering OIDs. This can be a list of intervals.
 
{{BeginConstraintBox}}
 
A validTime element must be present with at least the low child element populated.
 
{{EndConstraintBox}}
 
 
 
====scopedOIDs====
 
 
 
List of scoped OIDs, i.e. the OIDs for which this OID-Registry is responsible for registration
 
{{BeginConstraintBox}}
 
If the OID-Registry is responsible for issuing/registering a root OID, this OID should be listed in scopedOIDs.
 
{{EndConstraintBox}}
 
 
 
====name====
 
 
 
Official name of the OID registry
 
 
 
====desc====
 
 
 
A description of the OID registry
 
 
 
===Associations===
 
{|class="hl7table"
 
! Association !! Description !! Associated class !! Cardinality !! Conformance
 
|-
 
| hostingOrganization || Hosting organization || [[#Organization|Organization]] || 1..* || mandatory
 
|-
 
| person || Contact person(s) || [[#Person|Person]] || 1..* || mandatory
 
|-
 
| oid || List of OIDs || [[#OID|OID]] || 0..* || required
 
|-
 
|}
 
 
 
===Example===
 
 
 
{{HL7XML
 
| code =
 
<ThisOIDregistry>
 
  <validTime>
 
    <low value="20040507"/>
 
  </validTime >
 
  <scopedOIDs>1.2.276.0.76</scopedOIDs>
 
  <name>Some OID registry</name>
 
  <desc>The best OID registry ever</desc>
 
  <hostingOrganization> ... </hostingOrganization>
 
  <person> ... </person>
 
  <oid> ... <oid>
 
  <oid> ... <oid>
 
  ...
 
<ThisOIDregistry>
 
}}
 
 
 
==OID==
 
 
 
[[Datei:Oid-OID.jpg | 200px]]
 
 
 
This class contains the registered OID and the associated meta data.
 
 
 
===Attributes===
 
 
 
{|class="hl7table"
 
! Attribute !! Description !! Datatype !! Cardinality !! Conformance || Recommended Length
 
|-
 
| dotNotation || registered OID, dot notation || OID || 1..1 || mandatory || 64
 
|-
 
| asn1Notation || ASN.1 notation || ST || 0..1 || optional || 128
 
|-
 
| iriNotation || IRI notation || ST || 0..1 || optional || 128
 
|-
 
| symbolicName || symbolic name || ST || 0..1 || optional || 128
 
|-
 
| category || OID category || CS || 1..1 || required || -
 
|-
 
| status || OID status || CS || 1..1 || mandatory || -
 
|-
 
| creationDate || date of creation || TS || 0..1 || optional || -
 
|-
 
| realm || countries || CS || 0..* || mandatory || -
 
|-
 
|}
 
 
 
====dotNotation====
 
 
 
The OID in dot notation of SNMP or ASN.1/XER
 
 
 
Example:
 
2.16.528
 
 
 
====asn1Notation====
 
 
 
The OID in ASN.1 notation with (optional) identifiers and numbers.
 
 
 
The pattern is:
 
\{?\s*(([a-z][a-zA-Z0-9\-]*\s*((\s*(0|[1-9][0-9]*)\s*\))?|(0|[1-9][0-9]*))\s*){2,}\s*\}?
 
 
 
Examples:
 
{joint-iso-itu-t(2) country(16) nl(528)}
 
 
 
{itu-t(0) recommendation(0) a(1)}.
 
{{BeginEMBox}}
 
Note that the surrounding curly brackets can be omitted.
 
{{EndEMBox}}
 
{{BeginEMBox}}
 
Note that this information is not necessarily entered by a human, this item maybe populated algorithmically.
 
{{EndEMBox}}
 
 
 
====iriNotation====
 
 
 
The OID in Internationalized Resource Identifier<ref>http://www.oid-info.com/faq.htm#iri</ref> (IRI) notation.
 
 
 
Example:
 
oid:/Country/528
 
{{BeginEMBox}}
 
Note that this information is not necessarily entered by a human, this item maybe populated algorithmically.
 
{{EndEMBox}}
 
 
 
====symbolicName / Secondary Arc Identifier ====
 
 
 
A symbolic short name, unique among the siblings of the arc of the OID.
 
 
 
The ISO rules on Secondary Arc Identifiers, as laid out in Rec. ITU-T | ISO/IEC 9834-1 ''Procedures for Registration Authorities'', section 6.2.2, apply:
 
* identifiers of an arc are required to commence with a lowercase letter, and to contain only letters, digits, and hyphens.
 
* the last characters shall not be a hyphen
 
* there shall be no two consecutive hyphens in the name
 
 
 
The pattern is
 
^[a-z]([a-z]|[A-Z]|[0-9]|[\-][^-])*([^-])?$
 
 
 
Example
 
nl
 
 
 
====category====
 
 
 
Type/category of OID, enumeration, values: [[#OIDcategory|OIDCategory]]
 
 
 
There are actually two main types of OIDs: ''leafs'' (id of an object), and ''nodes'' representing an ontological branch.
 
 
 
The types of ''node'' OID may be
 
* a registration authority (RA) or
 
* a structure for the management of OIDs.
 
 
 
The proposal for sub categories of ''leaf'' OIDs are
 
* identifiers of an instance of an object (for example a person)
 
* namespace identifiers (for example code systems, value sets)
 
{{BeginEMBox}}
 
In addition there are properties of OID which can reflect other business needs.
 
These can be
 
* tags (simple text)
 
* other categorizations of the OID, coded or as text
 
* "sub-types" of the OID
 
For further information see ''[[#AdditionalProperty|AdditionalProperty]]''.
 
{{EndEMBox}}
 
 
 
====status====
 
 
 
Status of the OID. This is an enumeration, for values see: [[#OIDstatus|OIDstatus]]
 
 
 
====creationDate====
 
 
 
The creationDate is used to describe when the OID was first registered. It is not the date when the OID description is submitted to the OID repository.
 
The creationDate, once set, never changes.
 
 
 
====realm====
 
 
 
Code of country or "UV" for universal. This is an enumeration, for values see: [[#CountryCodes| CountryCodes]].
 
 
 
===Associations===
 
{|class="hl7table"
 
! Association !! Description !! Associated class !! Cardinality !! Conformance
 
|-
 
| registrationAuthority || Registration Authority || [[#RegistrationAuthority|RegistrationAuthority]] || 1..1 || mandatory
 
|-
 
| responsibleAuthority || Responsible Authority || [[#ResponsibleAuthority | ResponsibleAuthority]] || 1..* || mandatory
 
|-
 
| submittingAuthority || Submitting Authority || [[#SubmittingAuthority | SubmittingAuthority]] || 0..1 || optional
 
|-
 
| description || Description || [[#Description | Description]] || 1..* || mandatory
 
|-
 
| additionalProperty || Additional Properties || [[#AdditionalProperty | AdditionalProperty]] || 0..* || optional
 
|-
 
| historyAnnotation || History Annotations || [[#HistoryAnnotation | HistoryAnnotation]] || 0..* || optional
 
|-
 
| reference || References || [[#Reference | Reference]] || 0..* || optional
 
|-
 
 
|}
 
|}
 +
<div style="height:300px; clear:both"></div>
  
==RegistrationAuthority==
+
    <div class="doc-title"> ISO 13582 - Health informatics<br/> Sharing of OID registry information in healthcare </div>
  
[[Datei:Oid-RegistrationAuthority.jpg | 200px]]
+
    <div class="doc-type">  Technical Specification </div>
  
This class represents the RegistrationAuthority (RA)
+
    <div class="doc-submitted"> Author: Dr. Kai U. Heitmann, Germany </div>
  
===Attributes===
+
    <div class="doc-status"> Draft TS, not yet in ISO publication format<br/>Extracted from<br/>http://wiki.hl7.de/index.php/ISO_TC_215_-_ISO_TS_13582</div>
  
{|class="hl7table"
+
    <div class="doc-vbox">
! Attribute !! Description !! Datatype !! Cardinality !! Conformance || Recommended Length
+
{| cellpadding="3"
|-
 
| statusCode || RA status || CS || 1..1 || mandatory || -
 
 
|-
 
|-
 +
|Version:||  as of 2011-05-15
 
|}
 
|}
 +
</div>
 +
</div>
  
====statusCode====
+
{{:ISO13582-part1}}
The statusCode holds information about the role status of the RA. Valid codes are listed in [[#RoleStatus|RoleStatus]].
+
{{:ISO13582-part2}}
 
+
{{:ISO13582-part3}}
===Associations===
 
{|class="hl7table"
 
! Association !! Description !! Associated class !! Cardinality !! Conformance
 
|-
 
| scopingOrganization || Scoping organization || [[#Organization|Organization]] || 1..* || mandatory
 
|-
 
| person || Contact person(s) || [[#Person|Person]] || 1..* || mandatory
 
|-
 
|}
 
 
 
==ResponsibleAuthority==
 
 
 
[[Datei:Oid-ResponsibleAuthority.jpg | 200px]]
 
 
 
This is a class representing the (managing) authority that is responsible for the object that is identified by the OID (not for the OID itself).
 
 
 
===Attributes===
 
 
 
{|class="hl7table"
 
! Attribute !! Description !! Datatype !! Cardinality !! Conformance || Recommended Length
 
|-
 
| statusCode || status || CS || 1..1 || mandatory || -
 
|-
 
| validTime || validity time || IVL_TS || 1..* || mandatory || -
 
|-
 
|}
 
 
 
====statusCode====
 
The statusCode holds information about the role status of the ResponsibleAuthority. Valid codes are listed in [[#RoleStatus|RoleStatus]].
 
 
 
====validTime====
 
This is an interval of time, representing the period when the ResponsibleAuthority is/was responsible for the object that is identified by the OID. If the ResponsibleAuthority is still responsible, only the <low> element is populated.
 
 
 
===Associations===
 
{|class="hl7table"
 
! Association !! Description !! Associated class !! Cardinality !! Conformance
 
|-
 
| scopingOrganization || Scoping organization || [[#Organization|Organization]] || 1..* || mandatory
 
|-
 
| person || Contact person(s) || [[#Person|Person]] || 1..* || mandatory
 
|-
 
|}
 
 
 
==SubmittingAuthority==
 
 
 
[[Datei:Oid-SubmittingAuthority.jpg | 200px]]
 
 
 
===Attributes===
 
{|class="hl7table"
 
! Attribute !! Description !! Datatype !! Cardinality !! Conformance || Recommended Length
 
|-
 
| statusCode || status || CS || 1..1 || mandatory || -
 
|-
 
| applicationDate || date of application || TS || 0..1 || optional || -
 
|-
 
|}
 
 
 
====statusCode====
 
The statusCode holds information about the role status of the submitting authority. Valid codes are listed in [[#RoleStatus|RoleStatus]].
 
 
 
====applicationDate====
 
 
 
Date of application (submission or certified submission) of the requested OID.
 
 
 
===Associations===
 
{|class="hl7table"
 
! Association !! Description !! Associated class !! Cardinality !! Conformance
 
|-
 
| scopingOrganization || Scoping organization || [[#Organization|Organization]] || 1..* || mandatory
 
|-
 
| person || Contact person(s) || [[#Person|Person]] || 1..* || mandatory
 
|-
 
|}
 
 
 
==Description==
 
 
 
[[Datei:Oid-Description.jpg | 200px]]
 
 
 
This class contains a free text description of the OID ("what is the OID?"). The text typically contains an explaination but also can contain:
 
* explicit versioning aspects
 
* licensing information
 
* Intellectual Property rights information
 
* trademarks.
 
===Attributes===
 
{|class="hl7table"
 
! Attribute !! Description !! Datatype !! Cardinality !! Conformance || Recommended Length
 
|-
 
| text || textual description || ED || 1..1 || mandatory || -
 
|-
 
|}
 
{{BeginEMBox}}
 
Note that data type ED also reflects the aspect of language of the description (language code).
 
{{EndEMBox}}
 
 
 
{{BeginConstraintBox}}
 
There SHALL be one description instance with lanuguage code "en" (english).
 
{{EndConstraintBox}}
 
 
 
==AdditionalProperty==
 
 
 
[[Datei:Oid-AdditionalProperty.jpg | 200px]]
 
 
 
This class reflects additional properties of an OID that might be used to fit business rules that cannot (or should not) be standardized. This includes:
 
* additional categories
 
* additional status information
 
* tags, simple text
 
* coded properties
 
 
 
It is made of an
 
* attribute
 
* value
 
 
 
{|class="hl7table"
 
! Attribute !! Description !! Datatype !! Cardinality !! Conformance || Recommended Length
 
|-
 
| attribute || Additional property type || ST || 1..1 || mandatory || -
 
|-
 
| value || Additional property value || ST || 1..1 || mandatory || -
 
|-
 
|}
 
 
 
==HistoryAnnotation==
 
 
 
[[Datei:Oid-HistoryAnnotation.jpg | 200px]]
 
 
 
This class reflects historical annotations of the OID and records the changes of any data over time.
 
 
 
===Attributes===
 
{|class="hl7table"
 
! Attribute !! Description !! Datatype !! Cardinality !! Conformance || Recommended Length
 
|-
 
| creationDate || date annotation was created || TS || 0..1 || optional || -
 
|-
 
| text || annotation || ED || 1..1 || mandatory || -
 
|-
 
|}
 
{{BeginEMBox}}
 
Note that data type ED also reflects the aspect of language of the description (language code).
 
{{EndEMBox}}
 
 
 
==Reference==
 
 
 
[[Datei:Oid-Reference.jpg | 200px]]
 
 
 
This class provides a link to
 
* other data sources, code tables, value sets, descriptions etc; typically this is a URL and always points to an object with different semantics than the OID itself.
 
* other OIDs (within or outside this OID registry) in order to be able to express that an OID has been superseded/replaced or that there is a preferred OID.
 
 
 
The nature of the reference is coded in the type attribute, vocabulary is ''[[#ReferenceType|ReferenceType]]''.
 
 
 
===Attributes===
 
{|class="hl7table"
 
! Attribute !! Description !! Datatype !! Cardinality !! Conformance || Recommended Length
 
|-
 
| ref || reference URI || URI || 1..1 || mandatory || -
 
|-
 
| type || type of reference || CS || 1..1 || mandatory || -
 
|-
 
| lastVisitedDate || date URI last visited || TS || 0..1 || optional || -
 
|-
 
|}
 
 
 
==Person==
 
 
 
[[Datei:Oid-Person.jpg | 200px]]
 
 
 
===Attributes===
 
{|class="hl7table"
 
! Attribute !! Description !! Datatype !! Cardinality !! Conformance || Recommended Length
 
|-
 
| name || person's name || EN.PN || 1..* || mandatory || -
 
|-
 
| addr || person's address || AD || 0..* || optional || -
 
|-
 
| telecom || person's telecommunication contact || TEL || 0..* || optional || -
 
|-
 
|}
 
 
 
==Organization==
 
 
 
[[Datei:Oid-Organization.jpg | 200px]]
 
 
 
===Attributes===
 
{|class="hl7table"
 
! Attribute !! Description !! Datatype !! Cardinality !! Conformance || Recommended Length
 
|-
 
| id || id (OID) of the organization || OID || 0..* || optional || -
 
|-
 
| name || name of the organization || ST || 1..* || mandatory || -
 
|-
 
| addr || address of the organization || AD || 0..* || optional || -
 
|-
 
| telecom || telecommunication contact of the organization || TEL || 0..* || optional || -
 
|-
 
|}
 
 
 
=List of code systems=
 
 
 
==CountryCodes==
 
 
 
ISO 3166-1 alpha two letter country codes are used<ref>[http://www.iso.org/iso/english_country_names_and_code_elements ISO 3166-1-alpha-2 country codes]</ref><ref>ISO 3166 - Codes for the representation of names of countries - The International Organization for Standardization, 3rd edition.</ref>. This list states the country names as given in ISO 3166-1 and the corresponding ISO 3166-1-alpha-2 code elements.
 
 
 
Example:
 
NL
 
 
 
==LanguageCodes==
 
 
 
Reflects the Human Language. Language is specified conformant to RFC 3066 (Tags for the Identification of Languages). The format is
 
ss[-CC]
 
where '''ss''' is the language code drawn from ISO-639-1<ref>[http://www.loc.gov/standards/iso639-2/php/English_list.php ISO 639-2 Codes for the Representation of Names of Languages]</ref>, and '''CC''' is the country code, conformant to ISO-3166 alpha-2.
 
 
 
Example:
 
en-US
 
 
 
==OIDcategory==
 
 
 
{|class="hl7table"
 
! Code !! Description
 
|-
 
| N || node
 
|-
 
| NRA || registration authority (RA)
 
|-
 
| NMN || structure for the management of OIDs (it is not good practice but we know that some of these nodes in some registries also identify objects, which should not be)
 
|-
 
| L || leaf
 
|-
 
| LIO || an instance of an object
 
|-
 
| LNS || a namespace identifier
 
|}
 
 
 
==ObjectType==
 
Type of object identified by the OID.
 
 
 
In HL7 this is
 
* Bodies (persons, organization)
 
* Identifier systems (to be used in an II data type)
 
* Public coding systems
 
* Internal coding systems (HL7 as a terminology authority)
 
* Documentation products / documents  (normative edition, implementation guides etc.)
 
* Registered conformance profiles
 
* Templates
 
* V2 tables (really???)
 
* Value sets (created at the HL7 harmonization proces)
 
* Value sets (created and maintained by other authorities)
 
* Examples (published)
 
 
 
==OIDstatus==
 
This code reflects the status of the OID. Valid values are:
 
 
 
{|class="hl7table"
 
! Code !! Description
 
|-
 
| pending || OID assignment pending
 
|-
 
| complete || assignment complete
 
|-
 
| retired || OID retired/withdrawn
 
|-
 
| unknown || status of the OID unknown
 
|}
 
 
 
==ReferenceType==
 
The type of reference covers the following values:
 
 
 
{|class="hl7table"
 
! Code !! Description
 
|-
 
| RPLC || replaced by OID
 
|-
 
| PREF || preferred OID
 
|-
 
| LINK || link access (to code and value set tables)
 
|-
 
| IDSD || identification scheme documentation
 
|}
 
 
 
==RoleStatus==
 
This covers the kind of role:  
 
 
 
{|class="hl7table"
 
! Code !! Description
 
|-
 
| PRI || primary
 
|-
 
| SEC || secondary
 
|-
 
| OBO || on behalf of
 
|-
 
| CON || contact person
 
|}
 
 
 
=Data types=
 
 
 
ISO data types<ref>ISO 21090 Healthcare Datatypes (ISO/FDIS 21090:2009(E))</ref> are used for the XML representation of data.
 
 
 
The following section gives examples and describes the restrictions / contraints on the generic specification.
 
 
 
==Address AD==
 
Example:
 
{{HL7XML
 
| code =
 
<addr use="HP">
 
<part type="STR" value="Windsteiner Weg"/>
 
<part type="BNR" value="54a"/>
 
<part type="CNT" code="DEU" codeSystem=" 1.0.3166.1.2" value="D"/>
 
<part type="ZIP" value="14165"/>
 
<part type="CTY" value="Berlin"/>
 
</addr>
 
}}
 
 
 
==Coded Simple CS==
 
Example:
 
{{HL7XML
 
| code =
 
<statusCode code="OBO"/>
 
}}
 
 
 
==Encapsulated Data ED==
 
(for mime: Text and HTML only (flavor id ED:TEXT, with language code)
 
Example:
 
{{HL7XML
 
| code =
 
<text value="this is plain text" language="en" mediaType="text/plain"/>
 
<text value="dieses ist normaler Text" language="de" mediaType="text/plain"/>
 
}}
 
 
 
==Entity Name EN==
 
Example:
 
{{HL7XML
 
| code =
 
<name use="OR C">
 
<part type="GIV" value="Selby"/>
 
<part type="FAM" qualifier="SP" value="Butt"/>
 
<part type="FAM" value="Hadrian"/>
 
</name>
 
}}
 
 
 
==Interval of time stamp IVL_TS==
 
Example:
 
{{HL7XML
 
| code =
 
<validTime>
 
  <low value="20101201" />
 
  <high value="20101224" />
 
</validTime>
 
}}
 
 
 
==Object Identifier OID==
 
This is actually a character string with a certain pattern.
 
 
 
The pattern is:
 
\{?\s*(0|[1-9][0-9]*)(\.(0|[1-9][0-9]*))*\s*\}?
 
 
 
Example:
 
{{HL7XML
 
| code =
 
<oid value="1.2.3.4.5.0.6.7.8.9"/>
 
}}
 
 
 
==String ST==
 
Example:
 
{{HL7XML
 
| code =
 
  <description value="I am a piece of text"/>
 
}}
 
 
 
==Telecommunication TEL==
 
Example:
 
{{HL7XML
 
| code =
 
<telecom value="tel:+491234567890" use="H WP" capabilities="voice fax"/>
 
}}
 
 
 
==Time stamp TS==
 
Example:
 
{{HL7XML
 
| code =
 
  <lastVisitedDate value="20101205"/>
 
}}
 
 
 
==Uniform Resource Identification URI==
 
This is actually a character string with a certain pattern.
 
 
 
Example:
 
{{HL7XML
 
| code =
 
<uri value="http://x.y.org"/>
 
}}
 
 
 
See also: <ref>IETF RFC 1738 - Uniform Resource Locators (URL)</ref><ref>IETF RFC 2396 - Uniform Resource Identifiers (URI): Generic Syntax</ref>.
 
 
 
=Basic interactions between OID registries=
 
A set of basic interactions is developed and documented in order to facilitate the exchange of OID-related information between registries. This will include at least the following transactions:
 
*Share OID list
 
*Retrieve OID list
 
 
 
= Annex A =
 
Annex A is a specific description for the registration procedures for e-health related OIDs, and includes a specification of those parts of the OID tree that are known to be used for national and for international e-health applications.
 
  
=References=
+
=Bibliography=
 
<references/>
 
<references/>

Aktuelle Version vom 17. Februar 2012, 18:33 Uhr

Inhaltsverzeichnis

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[1] [2]. 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"[3]).

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[4] register and several European registers[5][6] 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.

Information model

In order to exchange OID and their metadata between different registries and applications the following additional data items beyond the OID itself need to be taken under consideration (see also [7] [8]):

  • descriptions
  • status information
  • categorization
  • time information
  • comments
  • versions
  • links
  • relationships to other OIDs and external sources
  • registering and responsible organizations
  • associated persons.

An information model with all classes, attributes and their properties aiming on a common understanding of the requirements of an OID registry has been created (Figure 1).

OID Registry Model (Draft)

XML exchange format

Data exchange can be facilitated by a standardized representation of the complete set of information as an XML structure together with the associated checks of underlying constraints and business rules. This XML structure for importing and exporting OID amongst different registries and other healthcare applications is aiming on the availability of reliable information about OIDs.

The following sections summarise and explain classes and their attributes.

Registry

This is the basic information about the OID-Registry hosting the OIDs.

Oid-registry.jpg

Attributes

Attribute Description DT Card Conf Length
validTime validity time interval IVL_TS 1..* mandatory -
scopedOIDs List of scoped root OIDs ST.OID 0..* optional 64
name Official name of the OID registry ST 1..1 mandatory 64
description Description of the OID registry, possible in multiple languages ED 0..* optional -

validTime

This is the validity time interval, i.e. the begin (and end) time when this registry is/was responsible for registering OIDs. This can be a list of intervals.

scopedOIDs

List of scoped root OIDs, i.e. the OIDs for which this OID registry is responsible for registration.

name

Official name of the OID registry

description

A description of the OID registry, possible in multiple languages

Associations

Association Description Class Card Conf
person Contact person(s) Person 1..* mandatory
hostingOrganization Hosting organization Organization 1..* mandatory
oid List of OIDs Oid 0..* required

Example

<registry>

    <validTime>
        <low value="20100501"/>
    </validTime>

    <scopedOID value="1.2.3.4.5"/>

    <name value="The best OID registry ever"/>
    <description language="en-US" value="This is a test OID registry, although the best"/>

    <person> ... </person>
    <hostingOrganization> ... </hostingOrganization>

    <oid> ... </oid>

</registry>

Oid

This class contains the registered OID and the associated meta data.

Oid-OID.jpg

Attributes

Attribute Description DT Card Conf Length
dotNotation registered OID, dot notation ST.OID 1..1 mandatory 64
asn1Notation ASN.1 notation ST.ASN1 0..1 optional 128
iriNotation IRI notation ST.IRI 0..1 optional 128
symbolicName symbolic name ST.SYMB 0..1 optional 128
category OID category CS 1..1 required -
status OID status CS 1..1 mandatory -
creationDate date of creation TS 0..1 optional -
realm countries CS 0..* optional -
description textual description ED 1..* mandatory -

dotNotation

The OID in dot notation of SNMP or ASN.1/XER.

Example:

2.16.528

asn1Notation

The OID in ASN.1 notation with (optional) identifiers and numbers.

Examples:

{joint-iso-itu-t(2) country(16) nl(528)}
{itu-t(0) recommendation(0) a(1)}

iriNotation

The OID in Internationalized Resource Identifier[9] (IRI) notation.

Example:

oid:/Country/528

symbolicName / Secondary Arc Identifier

A symbolic short name, unique among the siblings of the arc of the OID.

The ISO rules on Secondary Arc Identifiers, as laid out in Rec. ITU-T | ISO/IEC 9834-1 Procedures for Registration Authorities, section 6.2.2, apply:

  • identifiers of an arc are required to commence with a lowercase letter, and to contain only letters, digits, and hyphens.
  • the last characters shall not be a hyphen
  • there shall be no two consecutive hyphens in the name

Example

nl

category

The type/category of the OID; enumeration, values see value set OIDcategories.

There are actually two main types of OIDs: leafs (id of an object), and nodes representing an ontological branch.

The types of node OID may be

  • a registration authority (RA) or
  • a structure for the management of OIDs.

The proposal for sub categories of leaf OIDs are

  • identifiers of an instance of an object (for example a person)
  • namespace identifiers (for example code systems, value sets)

status

Status of the OID. This is an enumeration, for values see value set OIDstatusCodes

creationDate

The creationDate is used to describe when the OID was first registered. It is not the date when the OID description is submitted to the OID repository. The creationDate, once set, never changes.

realm

In some cases OIDs may apply to a specific county/realm only, e.g. the namespace identifiers for the US Social Security Number (SSN) or the Dutch Citizen Service Number (BSN) or the codes system representing ICD-10 International Classification of Diseases 10th Revision for the use in Germany only (ICD10gm). This can be indicated by realm which is either the code of country or "UV" for universal. For values see code system CountryCodes.

description

This element contains a free text description of the OID ("what is the OID?"). The text typically contains an explanation but also can contain:

  • explicit versioning aspects
  • licensing information
  • Intellectual Property rights information
  • trademarks.

This element is repeatable for each language.

The datatype ED allows for a thumbnail child element. A thumbnail may be populated describing a short description of the OID (sometimes referred to as identifier name).

Example:

<description language="en-US" value="this is plain text as a long description">
   <thumbnail value="short text"/>
</description>

Associations

Association Description Class Card Conf
registrationAuthority Registration Authority RegistrationAuthority 1..1 required
responsibleAuthority Responsible Authority ResponsibleAuthority 1..* required
submittingAuthority Submitting Authority SubmittingAuthority 0..1 optional
additionalProperty Additional Properties AdditionalProperty 0..* optional
historyAnnotation History Annotations HistoryAnnotation 0..* optional
reference References Reference 0..* optional

RegistrationAuthority

Oid-RegistrationAuthority.jpg

This class represents the Registration Authority (RA).

Attributes

Attribute Description DT Card Conf Length
code RA role code CS 1..1 mandatory -

code

The code holds information about the role type of the RA. Valid codes are listed in RoleCodes.

Associations

Association Description Class Card Conf
scopingOrganization Scoping organization Organization 1..1 mandatory
person Contact person(s) Person 0..1 optional

ResponsibleAuthority

This is a class representing the (managing) authority that is responsible for the object that is identified by the OID (not for the OID itself).

Oid-ResponsibleAuthority.jpg

Attributes

Attribute Description DT Card Conf Length
code role code CS 1..1 mandatory -
statusCode status code CS 1..1 mandatory -
validTime validity time IVL_TS 1..* mandatory -

code

The code holds information about the role type of the ResponsibleAuthority. Valid codes are listed in RoleCodes.

statusCode

The statusCode holds information about the status of the ResponsibleAuthority. Valid codes are listed in RoleStatus.

validTime

This is an interval of time, representing the period when the ResponsibleAuthority is/was responsible for the object that is identified by the OID. If the ResponsibleAuthority is still responsible, only validTime.low is populated.

Associations

Association Description Class Card Conf
scopingOrganization Scoping organization Organization 1..1 mandatory
person Contact person(s) Person 0..1 optional

SubmittingAuthority

This is a class representing the submitting authority that originally asked for a new OID.

Oid-SubmittingAuthority.jpg

(Please note: to avoid redundancy, the classes Organization and Peron are shown with attributes here, at all other places only a "shadow" class of these two classes is shown)

Attributes

Attribute Description DT Card Conf Length
code role code CS 1..1 mandatory -
applicationDate date of application TS 0..1 optional -

code

The code holds information about the role type of the submitting authority. Valid codes are listed in RoleCodes.

applicationDate

Date of application (submission or certified submission) of the requested OID.

Associations

Association Description Class Card Conf
scopingOrganization Scoping organization Organization 1..1 mandatory
person Contact person(s) Person 1..1 mandatory

HistoryAnnotation

This class reflects historical annotations of the OID and records the changes of any data over time.

Oid-HistoryAnnotation.jpg

Attributes

Attribute Description Datatype Cardinality Conformance Recommended Length
annotationDate date annotation was created TS 0..1 required -
text annotation ED 1..1 mandatory -

Reference

Oid-Reference.jpg

This class provides a link to

  • other data sources, code tables, value sets, descriptions etc; typically this is a URL and always points to an object with different semantics than the OID itself.
  • other OIDs (within or outside this OID registry) in order to be able to express that an OID has been superseded/replaced or that there is a preferred OID.

Attributes

Attribute Description DT Card Conf Length
ref reference URI URI 1..1 mandatory -
type type of reference CS 1..1 mandatory -
lastVisitedDate date URI last visited TS 0..1 optional -

ref

The referenced URI.

type

The nature of the reference is coded in the type attribute, for vocabulary see ReferenceType.

lastVisitedDate

Specifies the date the UIR was last visited.

AdditionalProperty

Oid-AdditionalProperty.jpg

This class reflects additional properties of an OID that might be used to fit business rules that cannot (or should not) be standardized. This includes:

  • additional categories
  • additional status information
  • tags, simple text
  • coded properties

It is made of

  • attribute, describing the type of the additional property
  • value, the value of the additional property.
Attribute Description DT Card Conf Length
attribute Additional property type ST.NT 1..1 mandatory -
value Additional property value ST.NT 1..1 mandatory -

Person

A class to hold the properties of a person.

Oid-Person.jpg

Attributes

Attribute Description DT Card Conf Length
name person's name EN.PN 1..* mandatory -
addr person's address AD 0..* optional -
telecom person's telecommunication contact TEL 0..* optional -

Organization

A class to hold the properties of an organization.

Oid-Organization.jpg

Attributes

Attribute Description DT Card Conf Length
id id (OID) of the organization ST.OID 0..* optional -
name name of the organization EN.ON 1..* mandatory -
addr address of the organization AD 0..* optional -
telecom telecommunication contact of the organization TEL 0..* optional -

List of Codes and Enumerations

CountryCodes

ISO 3166-1 alpha two letter country codes are used[10][11]. This list states the country names as given in ISO 3166-1 and the corresponding ISO 3166-1-alpha-2 code elements.

LanguageCodes

Reflects the Human Language. Language is specified conformant to RFC 3066 (Tags for the Identification of Languages). The format is

ss[-CC]

where ss is the language code drawn from ISO-639-1[12], and CC is the country code, conformant to ISO-3166 alpha-2.

Example:

en-US

OIDcategories

This enumeration reflects the category of the OID (node, leaf) and possible sub categories.

Level Code Description
0 N node
1 NRA registration authority (RA)
1 NMN structure for the management of OIDs (it is not good practice but we know that some of these nodes in some registries also identify objects, which should not be)
0 L leaf
1 LIO an instance of an object
1 LNS a namespace identifier

OIDstatusCodes

This code reflects the status of the OID. Valid values are:

Level Code Description
0 pending OID assignment pending
0 complete assignment complete
0 retired OID retired/withdrawn
0 unknown status of the OID unknown

ReferenceType

The type of reference covers the following values:

Level Code Description
0 RPLC replaced by OID
0 PREF preferred OID
0 LINK link access (to code and value set tables)
0 IDSD identification scheme documentation

RoleCodes

This covers the kind of role of an authority. Valid values are:

Level Code Description
0 PRI primary
0 SEC secondary
0 OBO on behalf of
0 CON contact person

RoleStatus

This covers the status of role:

Level Code Description
0 active active
0 terminated terminated

Data types

A subset of the ISO 21090 data types[13] is used for the XML representation of data. In some cases additional flavors or constraints are defined.

The following section gives examples and describes the restrictions / constraints on the generic specification.

Address AD

Example:

<addr use="HP">
 <part type="STR" value="Windsteiner Weg"/>
 <part type="BNR" value="54a"/>
 <part type="CNT" code="DEU" codeSystem=" 1.0.3166.1.2" value="D"/>
 <part type="ZIP" value="14165"/>
 <part type="CTY" value="Berlin"/>
</addr>

Coded Simple Value CS

A coded attribute with a simple value. The attribute is always bound to a specific code system mentioned in the section about lists of code systems and enumerations .

Example:

<statusCode code="active"/>

Encapsulated Data ED

In this specification this is either plain text (media type "text/plain") and HTML (media type "text/html") only. A language code is required.

Examples:

<text value="this is plain text" language="en-US" mediaType="text/plain"/>

<text value="dieses ist normaler Text" language="de-DE" mediaType="text/plain"/>

Entity Name for a person EN.PN

Example:

<name use="OR C">
 <part type="GIV" value="Selby"/>
 <part type="FAM" qualifier="SP" value="Butt"/>
 <part type="FAM" value="Hadrian"/>
</name>

Entity Name for an organization EN.ON

Example:

<name use="LS">
  <part value="Healthy Hospital"/>
  <part qualifier="SFX">LLC</part>
</name>

Interval of time stamp IVL_TS

Example:

<validTime>
  <low value="20101201"/>
  <high value="20101224"/>
</validTime>

String ST

A character string, with possible translations.

Example:

<name value="I am a name"/>

String ST.NT

A character string, with no translations allowed.

Object Identifier (dot notation) ST.OID

This is actually a character string without translation (ST.NT) with a certain pattern. The pattern can be found in the Schema for XML representation (see Annex C).

Example:

<oid value="1.2.3.4.5.0.6.7.8.9"/>

Object Identifier (asn1 notation) ST.ASN1

This is actually a character string without translation (ST.NT) with a certain pattern. The pattern can be found in the Schema for XML representation (see Annex C).

Object Identifier (iri notation) ST.IRI

This is actually a character string without translation (ST.NT) with a certain pattern. The pattern can be found in the Schema for XML representation (see Annex C).

Symbolic name ST.SYMB

This is actually a character string without translation (ST.NT) with a certain pattern. The pattern can be found in the Schema for XML representation (see Annex C).

Telecommunication TEL

Example:

<telecom value="tel:+491234567890" use="H WP" capabilities="voice fax"/>

Locatable Resource TEL.URL

This points to a locatable resource, e.g. an internet address (see also: [14][15]).

Example:

<ref value="http://x.y.org"/>

Time stamp TS

Example:

<applicationDate value="20101205"/>

Annex A (informative)

This informative annex includes a specification of those parts of the OID tree that are known to be used for national and for international e-health applications. A description of possible of sub trees reflecting OID types is given.

OID types

In many OID registries the type of an OID is used to improve for example the administrative process around assigning new OIDs or improve search capabilities of registry users etc.. The OID type has nothing to do with ISO standards, or any intrinsic meaning or form of the OID itself, it is only a convenience for the users of an OID registry.

In order to store OID types along with OID metadata described in this technical standard, class AdditionalProperty is used. It seemed from international experience with OID registries that this can be a recommendation only. OID types vary from registry to registry.

Therefore OID types may be used as additional properties; if OID type is used it is recommended that AdditionalProperty.attribute should be “OIDType” and AdditionalProperty.value shall be an enumeration or code string representing the OID type.

HL7 Viewpoint

HL7 International has created a type ontology for the OIDs in the HL7 registry to make it easier for the user community to search for OIDs they may be looking for.

The following types have been defined for use in the HL7 OID Registry [7]:

Arc Type Description
.1  HL7 registered internal objects (other than organizational bodies) Type 1 OIDs are used for certain internal administrative functions, and to identify released and published Standards. This includes Version 3 International Releases, Normative Editions, V2.x Standards releases, CDA releases, etc. This is almost never used at this time.
.2 HL7 organizational bodies and groups Type 2 OIDs are only used to identify an HL7 Group, such as a Working Group, or an International Council Member of HL7, such as HL7 Australia. These are created only when a new organizational body is recognized by HL7 International Headquarters.
.3 External (not HL7) group functioning as a Registration Authority Type 3 OIDs are used for organizations that wish to create their own trees of OIDs for their use. If you will be assigning OIDs yourself under the OID that you are applying for, then you should select Type 3. This effectively delegates Registration Authority to your organization for all OIDs under this new Type 3 OID. No one else anywhere will create OIDs under your new root. Every OID created ‘under’ this new root will be considered by HL7 to be an ‘external’ OID, since you will have created it external to the HL7 OID Registry OID assignment software. These may be requested or registered by anyone.

Note that a Type 3 OID identifies an organizational entity, not a particular piece of hardware machinery. It does not have to be a corporation, it could be as small as a single development group building interface software for an NHIN Connect project, for instance. Type 3 OIDs should not be used to identify objects in addition to the organizational entity responsible for creating new OIDs under it.

.4 Registered externally maintained identifier systems and namespaces Type 4 OIDs are used for namespaces for identifiers that are public, and used widely, such as health card numbers, ID numbers assigned by jurisdictional authorities, etc. This is also used for any namespaces you may manage with your own defined OIDs under your own root, such as Medical Record Numbers or Accession Numbers, for example. This type of OID is typically used in the root of the version 3 datatype Instance Identifier.
.5 HL7 Internal Code Systems Type 5 OIDs are used only for HL7 created and maintained Coding Systems, that have been approved through the HL7 V3 Harmonization process. This type is assigned only by the group that applies decisions from the harmonization processes to the HL7 databases. These OIDs are typically used in the codSystem property of an HL7 Version 3 coded datatype.
.6 Registered external coding systems Type 6 is assigned to those OIDs that identify a Coding System or terminology that is created, published, and maintained by any organization outside of HL7. At this time, only an HL7 cochair or OID administrator can assign Type 6 to any OID. This type of OID is typically used in the codeSystem property of an HL7 Version 3 coded datatype.
.7 HL7 published document artifacts Type 7 OIDs are used solely for HL7 published artifacts (not releases of Standards), and are assigned only by members of the HL7 publishing group. This includes tutorial slides, implementation guides, databases, published RIM graphic billboards, Wiki pages, etc.
.8 (deprecated) Type 8 is currently not used.
.9 HL7 Registered conformance profiles Type 9 is used to indicate HL7 Conformance Profiles, published in the HL7 Profile Registry.
.10 HL7 Registered Templates Type 10 OIDs identify published Templates. These are created and registered by the Templates Workgroup, or by HL7 Workgroups that define and publish templates as part of their balloted standards.
.11 HL7 defined and registered Value Sets Type 11 OIDs identify Value Sets that have been created and published by HL7, and have been approved through the HL7 Harmonization processes only. These are used in HL7 Version 3 Model Binding and Context Binding mechanisms, and can only be assigned by members of the group that applies the HL7 Harmonization process approvals to the HL7 databases.
.12 HL7 Version 2.x tables Type 12 indicates that an OID identifies explicitly an HL7 Version 2.x Table, as published in the HL7 Version 2 series of standards. These exist to help facilitate development of translation capabilities between Version 2.x and Version 3/CDA interfaces.
.13 Externally authored and curated Value Sets Type 13 OIDs identify Value Sets that have been created, published, and are maintained by organizations outside of HL7. They may be registered by anyone, and are generally used in Hl7 Version 3 Model Binding and Context Binding mechanisms.
.14 Assignment Ontology node Type 14 OIDs may be used by any Registration Authority to indicate a structural ‘branch’ in the tree that they create under their own root, where the node is not any particular type of OID, the types will be below this node. Normally any node that is not a leaf is a registration authority, but some find that adding levels in the structure of the OIDs they create as Registration Authorities make the administration of the tree a bit easier. Each of the nodes in the HL7 tree that is the root of each of the Types is actually a Type 14 OID.
.15 Small code sets externally defined Type 15 OIDs are used to identify small code lists or sets that are defined and maintained by organizations outside of HL7. Where Value Sets are built upon underlying coding systems, short code lists are often ad-hoc values that are used in various applications, that are not components of a particular terminology or coding system. This type of OID may be used in the codeSystem property of a version 3 coded datatype.
.17 Non-specified type Type 17 OIDs are for any other type of object that does not fall into one of the other Type categories.
.18 HL7 Version 2.8 Coding Systems Type 18 OIDs are specifically for those coding systems that are defined as such in the HL7 Version 2.8 standard. These may only be created by HL7 cochairs.
.19 HL7 Examples Type 19 OIDs are used for published examples; it is a truly meaningless identifier, as it is not to be used for any actual entities. This is the only kind of OID that may not be a unique identifier, i.e. it may refer to more than one object if it appears in different publications or slides. Type 19 OIDs are used ONLY in published examples in documents and slide presentations, and should NEVER appear in any implementation or any HL7 model instance.

Recommendations for OID types

From a policy perspective it is common practice in several healthcare related OID registries [16] [17] [18] to distinguish at least between the following types of OIDs:

Arc Type
.3  organizational bodies and groups
.4  identifier systems and namespaces
.5  code systems
.7  document artifacts
.9  conformance profiles
.10  templates
.11  value sets
.19  examples
.99  experimental

Annex B (informative)

Informative Annex B specifies the list of use cases of an OID registry/repository and an Object Identifier Resolution System (ORS) for e-health related OIDs based on RESTful Web Services.

Use Cases

A list of OID Registry Use Cases has been defined in order to drive metadata model requirements, and functional requirements for Registry interoperability.

U1: OID Creation where the registry owner is the RA

  • Creation of a new OID in the standard ontological structure
  • Creation of a new OID in a sub-structure

U2: OID Registration

  • Registration where the registry owner created the OID
  • Registration of an OID created elsewhere

U3: OID Withdrawal/Replacement

  • Withdraw an OID created in error with no replacement
  • Withdraw an OID created in error with specified replacement
  • Withdraw an OID registered in error with no replacement
  • Withdraw an OID registered in error with specified replacement
  • Withdraw an OID that is found to be a duplicate, with original specified

U4: OID Metadata Update/Editing

  • Permissions model
  • Distributed effort model
  • Proxies for Editors

U5: OID Information Publication

  • Web presence
  • Internet-accessible API (Web service presence)
  • Full registry output to machine-readable form
  • Full registry output to human-readable form
  • Partial registry output to machine-readable form
  • Partial registry output to human-readable form

U6: OID Information Request

  • Search for the OID of an object
  • Search for the object identified by an OID
  • Search for a list of kinds of OIDs
  • Search for a list of OID based on various sub-criteria, with and without wildcards
    • Those registered by a particular entity
    • Those associated with a type of information object
    • Those associated with implementation guides
    • Those registered during some time period
    • etc.

RESTful Web Servcies for an Object Identifier Resolution System

Representational state transfer (REST) is a style of software architecture for distributed hypermedia systems such as the World Wide Web. The term representational state transfer was introduced and defined in 2000 by Roy Fielding in his doctoral dissertation.

A RESTful web service is implemented using HTTP and the principles of REST. It is a collection of resources, with four defined aspects:

  • the base URI for the web service, such as
    http://oid.server.org/
    
  • the Internet media type of the data supported by the web service, in this case either XML or HTML only.
  • the set of operations supported by the web service using HTTP methods, in this case GET only.

This part of annex B recommends a simple mechanism to be provided in order to retrieve lists of OIDs from a registry, details of a particular OID or an extract of the entire OID registry. Various formats should be supported like HTML and the original XML format.

The suggested calls should be implemented as RESTful Web Services and their parameters are stated as follows.

REST ressource specification

Resource Description GET Parameters
OIDIndex retrieves an index of all OIDs in the OID registry in HTML format

id (optional): an OID

language (optional): language

format (default, fixed): html

http://oid.server.org/OIDIndex

gets an HTML table of all OIDs in the registry with links to the details for each OID

http://oid.server.org/OIDIndex?id=1.0.3166.1.2.2

gets an HTML table of OID 1.0.3166.1.2.2 with links to the details for this OID

http://oid.server.org/OIDIndex?id=1.0.3166.1.2.2&language=de-DE

gets an HTML table of OID 1.0.3166.1.2.2 with links to the details for this OID in the German language

RetrieveOID retrieves a particular OID in the OID registry

id (required): an OID

format (optional): html or xml

language (optional): language

http://oid.server.org/RetrieveOID?id=1.0.3166.1.2.2&format=html

gets details of OID 1.0.3166.1.2.2 in HTML format

http://oid.server.org/RetrieveOID?id=1.0.3166.1.2.2&format=html&language=de-DE

gets details of OID 1.0.3166.1.2.2 in HTML format in the German language

http://oid.server.org/RetrieveOID?id=1.0.3166.1.2.2&format=xml

gets details of OID 1.0.3166.1.2.2 in XML format

GetOIDRegistry gets the entire content of the OID registry in XML format

format (default, fixed): xml

http://oid.server.org/GetOIDRegistry

gets the entire content of the OID registry in XML format

Annex C (informative): W3C schema for the XML representation

Annex C (informative) refers a W3C Schema with embedded ISO schematron (ISO/IEC 19757-3) for the XML representation of the structures described in this technical standard.

The W3C schema can (temporarily) be found at http://oidregistry.info/schema.

Bibliography

  1. ITU-T X.660 | ISO/IEC 9834-1
  2. ISO/IEC DIS 9834-1 Information technology -- Open Systems Interconnection -- Procedures for the operation of OSI Registration Authorities: General procedures and top arcs of the International Object Identifier tree
  3. ISO/NWIP/TR Health Informatics – Guidance for maintenance of Object Identifiers OID
  4. HL7 International
  5. OID repository (France Telecom-Orange)
  6. OID registry (DIMDI, Germany)
  7. Recommendation ITU-T X.680 (2008) | ISO/IEC 8824-1: 2008, Information Technology – Abstract Syntax Notation One (ASN.1), Specification of Basic Notation, 1997
  8. Recommendation ITU-T X.667 | ISO/IEC 9834-8: Information technology – Open Systems Interconnection – Procedures for the operation of OSI Registration Authorities: Generation and registration of Universally Unique Identifiers (UUIDs) and their use as ASN.1 object identifier components
  9. http://www.oid-info.com/faq.htm#iri
  10. ISO 3166-1-alpha-2 country codes
  11. ISO 3166 - Codes for the representation of names of countries - The International Organization for Standardization, 3rd edition.
  12. ISO 639-2 Codes for the Representation of Names of Languages
  13. ISO/FDIS 21090:2010 Health Informatics - Harmonized data types for information interchange
  14. IETF RFC 1738 - Uniform Resource Locators (URL)
  15. IETF RFC 2396 - Uniform Resource Identifiers (URI): Generic Syntax
  16. http://www.dimdi.de/dynamic/de/ehealth/oid/verzeichnis.html OID registry Germany
  17. http://oid.refdata.ch/ OID registry Switzerland
  18. https://www.gesundheit.gv.at/OID_Frontend/ OID registry Austria