ISO/TS 13582:2013

TECHNICAL ISO/TS
SPECIFICATION 13582
First edition
2013-03-15
Health informatics — Sharing of OID
registry information
Informatique de santé — Partage des informations de registre des
identifiants d’objets (OID)
Reference number
©
ISO 2013
© ISO 2013
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2013 – All rights reserved

Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms, definitions and abbreviated terms . 1
3.1 Terms and definitions . 1
3.2 Abbreviations . 2
4 Explanation of terms . 2
4.1 OID registry and OID repository . 2
4.2 Registration Authority (RA) . 2
4.3 Responsible (Managing) Authority (MA) . 2
4.4 Submitting Authority (SA) . 3
4.5 Current Registrant . 3
4.6 First Registrant . 3
4.7 First Registration Authority. 3
4.8 Rec. ITU-T X.660/ ISO/IEC 9834-1. 3
5 Object identifiers in healthcare . 3
5.1 General . 3
5.2 Additional descriptions . 5
5.3 Related work . 5
6 Approach . 5
6.1 Requirements analysis . 5
6.2 Preparatory work . 5
7 Information model . 6
7.1 General . 6
7.2 Agenda of tables and symbols . 7
7.3 XML exchange format . 8
7.4 Registry. 8
7.5 Oid . 9
7.6 RegistrationAuthority .12
7.7 ResponsibleAuthority .13
7.8 SubmittingAuthority .14
7.9 HistoryAnnotation .14
7.10 Reference .15
7.11 AdditionalProperty .16
7.12 Person .16
7.13 Organization .17
8 List of Codes and Enumerations .18
8.1 CountryCodes .18
8.2 LanguageCodes .18
8.3 OIDcategories .18
8.4 OIDstatusCodes .18
8.5 ReferenceType .19
8.6 RoleCodes .19
8.7 RoleStatus .19
9 Datatypes .19
9.1 Address AD .19
9.2 Coded Simple Value CS .20
9.3 Encapsulated Data ED .20
9.4 Entity Name for a person EN.PN .20
9.5 Entity Name for an organization EN.ON.20
9.6 Instance identifier II .20
9.7 Interval of time stamp IVL_TS .21
9.8 String ST .21
9.9 String ST.NT .21
9.10 Object Identifier (dot notation) ST.OID .21
9.11 Object Identifier (asn1 notation) ST.ASN1 .21
9.12 Object Identifier (iri notation) ST.IRI .21
9.13 Symbolic name ST.SYMB .21
9.14 Telecommunication TEL .21
9.15 Locatable Resource TEL.URL .21
9.16 Time stamp TS .22
Annex A (informative) OID types and sub trees .23
Annex B (informative) Use Cases and Object Identifier Resolution System (ORS) .24
Annex C (informative) W3C Schema for XML representation and information model .27
Bibliography .28
iv © ISO 2013 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International
Standards adopted by the technical committees are circulated to the member bodies for voting.
Publication as an International Standard requires approval by at least 75 % of the member bodies
casting a vote.
In other circumstances, particularly when there is an urgent market requirement for such documents, a
technical committee may decide to publish other types of normative document:
— an ISO Publicly Available Specification (ISO/PAS) represents an agreement between technical
experts in an ISO working group and is accepted for publication if it is approved by more than 50 %
of the members of the parent committee casting a vote;
— an ISO Technical Specification (ISO/TS) represents an agreement between the members of a
technical committee and is accepted for publication if it is approved by 2/3 of the members of the
committee casting a vote.
An ISO/PAS or ISO/TS is reviewed after three years in order to decide whether it will be confirmed for
a further three years, revised to become an International Standard, or withdrawn. If the ISO/PAS or
ISO/TS is confirmed, it is reviewed again after a further three years, at which time it must either be
transformed into an International Standard or be withdrawn.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO/TS 13582 was prepared by Technical Committee ISO/TC 215, Health informatics.
Introduction
OID (Object Identifiers) are unique identifiers for any kind of objects. 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).
In the exchange of healthcare information additional information about the object being identified is
generally very beneficial but typically not contained in a transaction of data between systems. Such
information (Responsible Organizations, a human readable name, a description of the object, etc.) is
referred to as the OID metadata and is 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.
vi © ISO 2013 – All rights reserved

TECHNICAL SPECIFICATION ISO/TS 13582:2013(E)
Health informatics — Sharing of OID registry information
1 Scope
This Technical Specification specifies the mandatory and optional information to be recorded in any
registry of OIDs, using an information model.
It specifies which parts of that information are to be regarded as public, and which parts are to be
subject to security and privacy requirements.
All registries support the recording of mandatory information, but the recording of any specific
object identifier in one or more repositories is always optional. In some cases, security and privacy
requirements are more stringent for e-health applications.
In detail, this Technical Specification:
— 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 Use 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.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
ISO 639-1, Codes for the representation of names of languages — Part 1: Alpha-2 code
ISO 3166, Codes for the representation of names of countries — The International Organization for
Standardization, 3rd edition, part 1 ISO 3166‑1
ISO 21090, Health informatics — Harmonized data types for information interchange
ISO/HL7 21731 Health informatics – HL7 version 3 – Reference information model – Release 1
ITU-T X.660 | ISO/IEC 9834-1, Information technology — Open Systems Interconnection — Procedures for the
operation of OSI Registration Authorities: General procedures and top arcs of the ASN.1 Object Identifier tree
IETF RFC 3066, Tags for the Identification of Languages
3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 21090 and the following apply.
3.1.1
property
inherent state- or process-descriptive feature of a system including any pertinent to a component
being determined or set of data elements (systems, component, kind-of-property) common to a set of
particular properties
3.2 Abbreviations
The following abbreviations are used for the terms defined in this Technical Specification 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
ITU International Telecommunication Union
IEC International Electrotechnical Commission
4 Explanation of terms
4.1 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 an OID 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.
4.2 Registration Authority (RA)
An 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 needs
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 the 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 must formally become a RA for the child OID in
order to allocate sub-arcs under it.
4.3 Responsible (Managing) Authority (MA)
An 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.
Discussion: simply managing an OID (for example for a code system) is the task of a Responsible
Authority MA. Potentially, a responsible authority may become a Registration Authority RA for a sub-
arc if it allocates sub-arcs.
2 © ISO 2013 – All rights reserved

4.4 Submitting Authority (SA)
This information is optional and reflects the person or organization that submitted the original OID
allocation request.
4.5 Current Registrant
In some OID registries, Current Registrants are stored. 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.
4.6 First Registrant
In some OID registries, First Registrants are stored. The First Registrant is used to indicate the very first
person (if known) who was responsible for managing the OID and who created it in the first instance.
This Technical Specification strongly suggests distinguishing 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.
4.7 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
cannot 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.
4.8 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 Specification does not use administrative or technical roles.
5 Object identifiers in healthcare
5.1 General
OID (Object Identifiers) are unique identifiers for any kind of objects. They are defined in Rec. ITU-T
X.660 | ISO/IEC 9834-1. This identification system for objects and concepts makes reliable electronic
information exchange possible. Administration and Registration is regulated by a set of rules.
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 accessible 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.
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 among different registries should be achieved for
supporting eHealth applications. In addition, the failure to have a standard for the operations needed to
coordinate 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 synchronize 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 standard
bodies/facilities. The burden of administrative tasks is such that multiple individuals, often in different
geographical locations, need to 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 Specification 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 Technical Specification are those establishing OID
registries and those (industry, government bodies) using the services maintained by such organizations.
4 © ISO 2013 – All rights reserved

5.2 Additional descriptions
In this Technical Specification, informative Annex A gives a description of possible sub trees reflecting
OID categories for e-health related OIDs is given.
Informative Annex B specifies the Use Cases of an OID registry/repository and 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.
5.3 Related work
This work is related to discussions about OID in the work programme of ISO/TC 215, HL7 International,
ISO/IEC JTC 1/SC 6, ITU-T SG 17 and other organizations dealing with OIDs and OID registries.
6 Approach
6.1 Requirements analysis
Following an extensive analysis of the currently available international OID registry for health care
systems, a basic data set and a corresponding XML representation as an exchange format needed to be
created for registering and exchanging OID-related data. To collect the very basic requirements for such
a format an analysis of several registries, e.g. HL7 International registry at hl7.org and several European
OID repositories (France Telecom-Orange, see http://www.oid-info.com, German OID registry at DIMDI,
see http://www.dimdi.de) 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 HL7 International
repository
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 registries specified an (XML-) exchange format. Due to lack of a common understanding
of OID registry requirements, data fields needed to be mapped (manually) when OID information needed
to be exchanged.
6.2 Preparatory work
This Technical Specification 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.
7 Information model
7.1 General
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 into consideration (see also Recommendation
ITU-T X.667 | ISO/IEC 9834-8, http://www.itu.int/rec/T-REC-X.667/en, and FAQs at oid-info, http://
www.oid-info.com/faq.htm#iri):
— 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 for a common understanding
of the requirements of an OID registry/repository has been created (Figure 1).
Additional remarks:
— The colours are taken from ISO/HL7 21731, the light green classes “Person” and “Organization” are
exact copies of the definitions of the green classes “Person” and “Organization” to avoid repeating
the class attributes. Boldface associations names reflect mandatory associations (see also 7.2.1).
— A coded attribute may have a vocabulary binding denoted by the symbol “<=”, e.g. in the registration
authority class RegistrationAuthority the code is bound to use the vocabulary defined in value
set/enumeration “RoleCodes”.
6 © ISO 2013 – All rights reserved

Figure 1 — Information model for OID registries and repositories
7.2 Agenda of tables and symbols
7.2.1 Class Attribute and Associated Tables
The Class Attribute Tables (information model) make use of the following table headline:
Class Attribute Description DT Card Conf Length
Class Attribute = class attribute name
Description = description (meaning) of the attribute
DT = datatype (or datatype flavor) conformant to the ISO 21090 datatypes,
Card = cardinality, e.g. 0.1 or 1.*
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 database string lengths).
In addition, the Association Tables (information model) make use of the following table headline:
Association Description Class Card Conf
Association = the association name to the associated class
Class = the associated class name
7.2.2 Conformance statements
Some class attributes or associations may have additional constraints, denoted by a paragraph
starting with “CONF” with an abbreviated identifier of that rule as a suffix (e.g. “rg-vt”) followed by the
conformance statement.
EXAMPLE
CONF rg-vt: A validTime element SHALL be present and of datatype IVL_TS with at least the low child
element populated.
7.3 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 among different registries and other healthcare
applications is dependent upon the availability of reliable information about OIDs.
The following subclauses summarize and explain classes and their attributes.
7.4 Registry
This is the basic information about the OID registry/repository hosting the OIDs (Figure 2).
Figure 2 — Registry
7.4.1 Attributes
Class Attribute Description DT Card Conf Length
validTime validity time interval IVL_TS 1.* manda- -
tory
scopedOIDs List of scoped root OIDs ST.OID 0.* optional 64
name Official name of the OID ST 1.1 manda- 64
registry tory
description Description of the OID reg- ST 0.* optional -
istry, possible in multiple
languages
lastModifiedDate date of last modification TS 0.1 optional -
7.4.1.1 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.
CONF rg-vt: A validTime element shall be present and of datatype IVL_TS with at least the low child
element populated.
8 © ISO 2013 – All rights reserved

7.4.1.2 scopedOIDs
List of scoped root OIDs, i.e. the OIDs for which this OID registry is responsible for registration. OIDs
listed here should be those under which this registry creates child OIDs, but this entry is only the top
OID of the tree; more than one entry may be here if this registry creates OIDs under more than one
disjoint root.
CONF rg-so: If the OID registry is responsible for issuing/registering a root OID, this OID should be listed
in scopedOIDs.
7.4.1.3 name
Official name of the OID registry.
7.4.1.4 description
A description of the OID registry, possible in multiple languages.
CONF rg-ds: If at least one description element is present one of the description’s language codes shall be
English (“en”, “en-US” etc.).
7.4.1.5 lastModifiedDate
The lastModifiedDate is used to describe when information in the OID registry was last modified.
7.4.2 Associations
Association Description Class Card Conf
person Contact person(s) Person 1.* required
hostingOrganization Hosting organization(s) Organization 1.* mandatory
oid List of OIDs Oid 0.* required
7.4.3 Example







.
.
.

7.5 Oid
This class contains the registered OID and the associated meta data (Figure 3).
Figure 3 — Oid
7.5.1 Attributes
Class Attribute Description DT Card Conf Length
dotNotation registered OID, dot nota- ST.OID 1.1 mandatory 128
tion
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 -
lastModifiedDate date of last modification TS 0.1 optional -
realm Countries CS 0.* optional -
description textual description ED 1.* mandatory -
7.5.1.1 dotNotation
The OID in dot notation of SNMP or ASN.1/XER.
EXAMPLE 2.16.528
7.5.1.2 asn1Notation
The OID in ASN.1 notation with (optional) identifiers and numbers.
EXAMPLE {joint-iso-itu-t(2) country(16) nl(528)} {itu-t(0) recommendation(0) a(1)}
NOTE 1 The surrounding curly brackets can be omitted.
NOTE 2 This information is not necessarily entered by a human; this item maybe populated algorithmically.
7.5.1.3 iriNotation
The OID in Internationalized Resource Identifier (IRI) notation.
EXAMPLE oid:/Country/528
NOTE This information is not necessarily entered by a human; this item maybe populated algorithmically.
10 © ISO 2013 – All rights reserved

7.5.1.4 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, 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
7.5.1.5 category
The type/category of the OID; enumeration, values see enumeration 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 an organization),
— namespace identifiers (for example code systems, value sets).
NOTE In addition there are properties of OIDs that 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.
7.5.1.6 status
Status of the OID. This is an enumeration, for values see enumeration OIDstatusCodes.
7.5.1.7 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.
7.5.1.8 lastModifiedDate
The lastModifiedDate is used to describe when information about the OID was last modified.
7.5.1.9 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.
7.5.1.10 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



NOTE datatype ED also reflects the aspect of language of the description (language code).
CONF oi-ds: There SHALL be one description instance with language code English (“en”, “en-US” etc.).
7.5.2 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
7.6 RegistrationAuthority
This class represents the Registration Authority (RA) (Figure 4).
Figure 4 — Registration Authority
7.6.1 Attributes
Class Attribute Description DT Card Conf Length
code Registration Authority r
...