ISO TC 215 - ISO TS 13582: Unterschied zwischen den Versionen
(→Organization) |
|||
Zeile 656: | Zeile 656: | ||
! Attribute !! Description !! Datatype !! Cardinality !! Conformance || Recommended Length | ! Attribute !! Description !! Datatype !! Cardinality !! Conformance || Recommended Length | ||
|- | |- | ||
− | | id || id (OID) of the organization || OID || 0..* || optional || - | + | | id || id (OID) of the organization || ST.OID || 0..* || optional || - |
|- | |- | ||
| name || name of the organization || ST || 1..* || mandatory || - | | name || name of the organization || ST || 1..* || mandatory || - |
Version vom 15. Mai 2011, 17:11 Uhr
International Organization for Standardization TC 215 Health Informatics |
Sharing of OID registry information
Version: | as of 2011-05-15 |
Inhaltsverzeichnis
- 1 History of Titles
- 2 Scope
- 3 Introduction
- 4 Approach
- 5 Definitions
- 6 Abbreviations and acronyms
- 7 Use Cases
- 7.1 U1: OID Creation where the registry owner is the RA
- 7.2 U2: OID Registration
- 7.3 U3: OID Withdrawal/Replacement
- 7.3.1 Withdraw an OID created in error with no replacement
- 7.3.2 Withdraw an OID created in error with specified replacement
- 7.3.3 Withdraw an OID registered in error with no replacement
- 7.3.4 Withdraw an OID registered in error with specified replacement
- 7.3.5 Withdraw an OID that is found to be a duplicate, with original specified
- 7.4 U4: OID Metadata Update/Editing
- 7.5 U5: OID Information Publication
- 7.6 U6: OID Information Request
- 8 Communication model
- 9 XML exchange format
- 10 List of code systems
- 11 Data types
- 11.1 Address AD
- 11.2 Coded Simple CS
- 11.3 Encapsulated Data ED
- 11.4 Entity Name for a person EN.PN
- 11.5 Interval of time stamp IVL_TS
- 11.6 String ST
- 11.7 Object Identifier (dot notation) ST.OID
- 11.8 Object Identifier (asn1 notation) ST.ASN1
- 11.9 Object Identifier (iri notation) ST.IRI
- 11.10 Symbolic name ST.SYMB
- 11.11 Telecommunication TEL
- 11.12 Time stamp TS
- 11.13 Uniform Resource Identification URI
- 12 Basic interactions between OID registries
- 13 Annex A
- 14 References
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
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.
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 requirement. |
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.
Need to discuss whether this standard should specify security procedures and if so, how... |
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[1]. This identification system for objects and concepts makes reliable electronic information exchange possible. Administration and Registration is regulated by a set of rules (see also ISO/NWIP/TR "Health Informatics – Guidance for maintenance of Object Identifiers OID"[2]).
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[3] register and several European registers[4][5] was performed so far (see Table 1). The analysis included the contents, attributes and even the rules of the assignment of OID.
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.
Need to discuss whether we need to destinguish between registries and repositories at all here. |
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.
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. |
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.
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).
Discussion: This is the RegistrationAuthority that allocated the OID, the issuing authority. |
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.
Need to discuss how this refers to the definitions gievn above. Do we need additional roles? |
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 [6] [7]):
- 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.
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
This is the basic information about the OID-Registry hosting the OIDs.
Attributes
Attribute | Description | Datatype | Cardinality | Conformance | Recommended 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 |
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.
A validTime element must be present with at least the low child element populated. |
scopedOIDs
List of scoped OIDs, i.e. the OIDs for which this OID-Registry is responsible for registration
If the OID-Registry is responsible for issuing/registering a root OID, this OID should be listed in scopedOIDs. |
name
Official name of the OID registry
desc
A description of the OID registry
Associations
Association | Description | Associated class | Cardinality | Conformance |
---|---|---|---|---|
hostingOrganization | Hosting organization | Organization | 1..* | mandatory |
person | Contact person(s) | Person | 1..* | mandatory |
oid | List of OIDs | OID | 0..* | required |
Example
<ThisOIDRegistry>
<validTime>
<low value="20100501"/>
</validTime>
<scopedOID value="1.2.3.4.5"/>
<name value="The best OID registry ever"/>
<desc value="This is a test OID registry, although the best"/>
<person> ... </person>
<organization> ... </organization>
<OID> ... </OID>
</ThisOIDRegistry>
OID
This class contains the registered OID and the associated meta data.
Attributes
Attribute | Description | Datatype | Cardinality | Conformance | Recommended 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 | - |
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)}.
Note that the surrounding curly brackets can be omitted. |
Note that this information is not necessarily entered by a human, this item maybe populated algorithmically. |
iriNotation
The OID in Internationalized Resource Identifier[8] (IRI) notation.
Example:
oid:/Country/528
Note that this information is not necessarily entered by a human, this item maybe populated algorithmically. |
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
Type/category of OID, enumeration, values: 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)
In addition there are properties of OID which can reflect other business needs.
These can be
|
status
Status of the OID. This is an enumeration, for values see: 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.
Associations
Association | Description | Associated class | Cardinality | Conformance |
---|---|---|---|---|
registrationAuthority | Registration Authority | RegistrationAuthority | 1..1 | mandatory |
responsibleAuthority | Responsible Authority | ResponsibleAuthority | 1..* | mandatory |
submittingAuthority | Submitting Authority | SubmittingAuthority | 0..1 | optional |
description | Description | Description | 1..* | mandatory |
additionalProperty | Additional Properties | AdditionalProperty | 0..* | optional |
historyAnnotation | History Annotations | HistoryAnnotation | 0..* | optional |
reference | References | Reference | 0..* | optional |
RegistrationAuthority
This class represents the RegistrationAuthority (RA)
Attributes
Attribute | Description | Datatype | Cardinality | Conformance | Recommended 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 | Associated class | Cardinality | Conformance |
---|---|---|---|---|
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).
Attributes
Attribute | Description | Datatype | Cardinality | Conformance | Recommended 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 the <low> element is populated.
Associations
Association | Description | Associated class | Cardinality | Conformance |
---|---|---|---|---|
scopingOrganization | Scoping organization | Organization | 1..1 | mandatory |
person | Contact person(s) | Person | 0..1 | optional |
SubmittingAuthority
(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 | Datatype | Cardinality | Conformance | Recommended 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 | Associated class | Cardinality | Conformance |
---|---|---|---|---|
scopingOrganization | Scoping organization | Organization | 1..1 | mandatory |
person | Contact person(s) | Person | 1..1 | mandatory |
Description
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
Attribute | Description | Datatype | Cardinality | Conformance | Recommended Length |
---|---|---|---|---|---|
text | textual description | ED | 1..* | mandatory | - |
Note that data type ED also reflects the aspect of language of the description (language code). |
There SHALL be one description instance with lanuguage code "en" (english). |
AdditionalProperty
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
Attribute | Description | Datatype | Cardinality | Conformance | Recommended Length |
---|---|---|---|---|---|
attribute | Additional property type | ST | 1..1 | mandatory | - |
value | Additional property value | ST | 1..1 | mandatory | - |
HistoryAnnotation
This class reflects historical annotations of the OID and records the changes of any data over time.
Attributes
Attribute | Description | Datatype | Cardinality | Conformance | Recommended Length |
---|---|---|---|---|---|
annotationDate | date annotation was created | TS | 0..1 | optional | - |
text | annotation | ED | 1..1 | mandatory | - |
Note that data type ED also reflects the aspect of language of the description (language code). |
Reference
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.
Attributes
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
Attributes
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
Attributes
Attribute | Description | Datatype | Cardinality | Conformance | Recommended Length |
---|---|---|---|---|---|
id | id (OID) of the organization | ST.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[9][10]. 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[11], and CC is the country code, conformant to ISO-3166 alpha-2.
Example:
en-US
OIDcategory
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 |
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)
Are there other types of objects? How far should this recommendation go? |
OIDstatus
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:
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
ISO data types[12] are 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 / contraints 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 CS
Example:
<statusCode code="OBO"/>
Encapsulated Data ED
(for mime: Text and HTML only (flavor id ED:TEXT, with language code) Example:
<text value="this is plain text" language="en" mediaType="text/plain"/>
<text value="dieses ist normaler Text" language="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>
Interval of time stamp IVL_TS
Example:
<validTime>
<low value="20101201" />
<high value="20101224" />
</validTime>
String ST
A character string
Example:
<description value="I am a piece of text"/>
Object Identifier (dot notation) ST.OID
This is actually a character string (ST) with a certain pattern.
The pattern is:
\{?\s*(0|[1-9][0-9]*)(\.(0|[1-9][0-9]*))*\s*\}?
Example:
<oid value="1.2.3.4.5.0.6.7.8.9"/>
The string pattern needs to be checked. |
Object Identifier (asn1 notation) ST.ASN1
This is actually a character string (ST) with a certain pattern.
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*\}?
The string pattern needs to be checked. |
Object Identifier (iri notation) ST.IRI
This is actually a character string (ST) with a certain pattern.
The pattern is:
/^[a-z](?:[-a-z0-9\+\.])*:(?:\/\/(?:(?:%[0-9a-f][0-9a-f]|[-a-z0-9\._~\x{A0}-\x{D7FF}\x{F900}-\x{FDCF}\x{FDF0}-\x{FFEF}\x{10000}-\x{1FFFD}\x{20000}-\x{2FFFD}\x{30000}-\x{3FFFD}\x{40000}-\x{4FFFD}\x{50000}-\x{5FFFD}\x{60000}-\x{6FFFD}\x{70000}-\x{7FFFD}\x{80000}-\x{8FFFD}\x{90000}-\x{9FFFD}\x{A0000}-\x{AFFFD}\x{B0000}-\x{BFFFD}\x{C0000}-\x{CFFFD}\x{D0000}-\x{DFFFD}\x{E1000}-\x{EFFFD}!\$&'\(\)\*\+,;=:])*@)?(?:\[(?:(?:(?:[0-9a-f]{1,4}:){6}(?:[0-9a-f]{1,4}:[0-9a-f]{1,4}|(?:[0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])(?:\.(?:[0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])){3})|::(?:[0-9a-f]{1,4}:){5}(?:[0-9a-f]{1,4}:[0-9a-f]{1,4}|(?:[0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])(?:\.(?:[0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])){3})|(?:[0-9a-f]{1,4})?::(?:[0-9a-f]{1,4}:){4}(?:[0-9a-f]{1,4}:[0-9a-f]{1,4}|(?:[0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])(?:\.(?:[0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])){3})|(?:[0-9a-f]{1,4}:[0-9a-f]{1,4})?::(?:[0-9a-f]{1,4}:){3}(?:[0-9a-f]{1,4}:[0-9a-f]{1,4}|(?:[0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])(?:\.(?:[0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])){3})|(?:(?:[0-9a-f]{1,4}:){0,2}[0-9a-f]{1,4})?::(?:[0-9a-f]{1,4}:){2}(?:[0-9a-f]{1,4}:[0-9a-f]{1,4}|(?:[0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])(?:\.(?:[0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])){3})|(?:(?:[0-9a-f]{1,4}:){0,3}[0-9a-f]{1,4})?::[0-9a-f]{1,4}:(?:[0-9a-f]{1,4}:[0-9a-f]{1,4}|(?:[0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])(?:\.(?:[0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])){3})|(?:(?:[0-9a-f]{1,4}:){0,4}[0-9a-f]{1,4})?::(?:[0-9a-f]{1,4}:[0-9a-f]{1,4}|(?:[0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])(?:\.(?:[0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])){3})|(?:(?:[0-9a-f]{1,4}:){0,5}[0-9a-f]{1,4})?::[0-9a-f]{1,4}|(?:(?:[0-9a-f]{1,4}:){0,6}[0-9a-f]{1,4})?::)|v[0-9a-f]+[-a-z0-9\._~!\$&'\(\)\*\+,;=:]+)\]|(?:[0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])(?:\.(?:[0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])){3}|(?:%[0-9a-f][0-9a-f]|[-a-z0-9\._~\x{A0}-\x{D7FF}\x{F900}-\x{FDCF}\x{FDF0}-\x{FFEF}\x{10000}-\x{1FFFD}\x{20000}-\x{2FFFD}\x{30000}-\x{3FFFD}\x{40000}-\x{4FFFD}\x{50000}-\x{5FFFD}\x{60000}-\x{6FFFD}\x{70000}-\x{7FFFD}\x{80000}-\x{8FFFD}\x{90000}-\x{9FFFD}\x{A0000}-\x{AFFFD}\x{B0000}-\x{BFFFD}\x{C0000}-\x{CFFFD}\x{D0000}-\x{DFFFD}\x{E1000}-\x{EFFFD}!\$&'\(\)\*\+,;=@])*)(?::[0-9]*)?(?:\/(?:(?:%[0-9a-f][0-9a-f]|[-a-z0-9\._~\x{A0}-\x{D7FF}\x{F900}-\x{FDCF}\x{FDF0}-\x{FFEF}\x{10000}-\x{1FFFD}\x{20000}-\x{2FFFD}\x{30000}-\x{3FFFD}\x{40000}-\x{4FFFD}\x{50000}-\x{5FFFD}\x{60000}-\x{6FFFD}\x{70000}-\x{7FFFD}\x{80000}-\x{8FFFD}\x{90000}-\x{9FFFD}\x{A0000}-\x{AFFFD}\x{B0000}-\x{BFFFD}\x{C0000}-\x{CFFFD}\x{D0000}-\x{DFFFD}\x{E1000}-\x{EFFFD}!\$&'\(\)\*\+,;=:@]))*)*|\/(?:(?:(?:(?:%[0-9a-f][0-9a-f]|[-a-z0-9\._~\x{A0}-\x{D7FF}\x{F900}-\x{FDCF}\x{FDF0}-\x{FFEF}\x{10000}-\x{1FFFD}\x{20000}-\x{2FFFD}\x{30000}-\x{3FFFD}\x{40000}-\x{4FFFD}\x{50000}-\x{5FFFD}\x{60000}-\x{6FFFD}\x{70000}-\x{7FFFD}\x{80000}-\x{8FFFD}\x{90000}-\x{9FFFD}\x{A0000}-\x{AFFFD}\x{B0000}-\x{BFFFD}\x{C0000}-\x{CFFFD}\x{D0000}-\x{DFFFD}\x{E1000}-\x{EFFFD}!\$&'\(\)\*\+,;=:@]))+)(?:\/(?:(?:%[0-9a-f][0-9a-f]|[-a-z0-9\._~\x{A0}-\x{D7FF}\x{F900}-\x{FDCF}\x{FDF0}-\x{FFEF}\x{10000}-\x{1FFFD}\x{20000}-\x{2FFFD}\x{30000}-\x{3FFFD}\x{40000}-\x{4FFFD}\x{50000}-\x{5FFFD}\x{60000}-\x{6FFFD}\x{70000}-\x{7FFFD}\x{80000}-\x{8FFFD}\x{90000}-\x{9FFFD}\x{A0000}-\x{AFFFD}\x{B0000}-\x{BFFFD}\x{C0000}-\x{CFFFD}\x{D0000}-\x{DFFFD}\x{E1000}-\x{EFFFD}!\$&'\(\)\*\+,;=:@]))*)*)?|(?:(?:(?:%[0-9a-f][0-9a-f]|[-a-z0-9\._~\x{A0}-\x{D7FF}\x{F900}-\x{FDCF}\x{FDF0}-\x{FFEF}\x{10000}-\x{1FFFD}\x{20000}-\x{2FFFD}\x{30000}-\x{3FFFD}\x{40000}-\x{4FFFD}\x{50000}-\x{5FFFD}\x{60000}-\x{6FFFD}\x{70000}-\x{7FFFD}\x{80000}-\x{8FFFD}\x{90000}-\x{9FFFD}\x{A0000}-\x{AFFFD}\x{B0000}-\x{BFFFD}\x{C0000}-\x{CFFFD}\x{D0000}-\x{DFFFD}\x{E1000}-\x{EFFFD}!\$&'\(\)\*\+,;=:@]))+)(?:\/(?:(?:%[0-9a-f][0-9a-f]|[-a-z0-9\._~\x{A0}-\x{D7FF}\x{F900}-\x{FDCF}\x{FDF0}-\x{FFEF}\x{10000}-\x{1FFFD}\x{20000}-\x{2FFFD}\x{30000}-\x{3FFFD}\x{40000}-\x{4FFFD}\x{50000}-\x{5FFFD}\x{60000}-\x{6FFFD}\x{70000}-\x{7FFFD}\x{80000}-\x{8FFFD}\x{90000}-\x{9FFFD}\x{A0000}-\x{AFFFD}\x{B0000}-\x{BFFFD}\x{C0000}-\x{CFFFD}\x{D0000}-\x{DFFFD}\x{E1000}-\x{EFFFD}!\$&'\(\)\*\+,;=:@]))*)*|(?!(?:%[0-9a-f][0-9a-f]|[-a-z0-9\._~\x{A0}-\x{D7FF}\x{F900}-\x{FDCF}\x{FDF0}-\x{FFEF}\x{10000}-\x{1FFFD}\x{20000}-\x{2FFFD}\x{30000}-\x{3FFFD}\x{40000}-\x{4FFFD}\x{50000}-\x{5FFFD}\x{60000}-\x{6FFFD}\x{70000}-\x{7FFFD}\x{80000}-\x{8FFFD}\x{90000}-\x{9FFFD}\x{A0000}-\x{AFFFD}\x{B0000}-\x{BFFFD}\x{C0000}-\x{CFFFD}\x{D0000}-\x{DFFFD}\x{E1000}-\x{EFFFD}!\$&'\(\)\*\+,;=:@])))(?:\?(?:(?:%[0-9a-f][0-9a-f]|[-a-z0-9\._~\x{A0}-\x{D7FF}\x{F900}-\x{FDCF}\x{FDF0}-\x{FFEF}\x{10000}-\x{1FFFD}\x{20000}-\x{2FFFD}\x{30000}-\x{3FFFD}\x{40000}-\x{4FFFD}\x{50000}-\x{5FFFD}\x{60000}-\x{6FFFD}\x{70000}-\x{7FFFD}\x{80000}-\x{8FFFD}\x{90000}-\x{9FFFD}\x{A0000}-\x{AFFFD}\x{B0000}-\x{BFFFD}\x{C0000}-\x{CFFFD}\x{D0000}-\x{DFFFD}\x{E1000}-\x{EFFFD}!\$&'\(\)\*\+,;=:@])|[\x{E000}-\x{F8FF}\x{F0000}-\x{FFFFD}|\x{100000}-\x{10FFFD}\/\?])*)?(?:\#(?:(?:%[0-9a-f][0-9a-f]|[-a-z0-9\._~\x{A0}-\x{D7FF}\x{F900}-\x{FDCF}\x{FDF0}-\x{FFEF}\x{10000}-\x{1FFFD}\x{20000}-\x{2FFFD}\x{30000}-\x{3FFFD}\x{40000}-\x{4FFFD}\x{50000}-\x{5FFFD}\x{60000}-\x{6FFFD}\x{70000}-\x{7FFFD}\x{80000}-\x{8FFFD}\x{90000}-\x{9FFFD}\x{A0000}-\x{AFFFD}\x{B0000}-\x{BFFFD}\x{C0000}-\x{CFFFD}\x{D0000}-\x{DFFFD}\x{E1000}-\x{EFFFD}!\$&'\(\)\*\+,;=:@])|[\/\?])*)?$/i
The string pattern needs to be checked. |
Symbolic name ST.SYMB
This is actually a character string (ST) with a certain pattern.
The pattern is:
^[a-z]([a-z]|[A-Z]|[0-9]|[\-][^-])*([^-])?$
The string pattern needs to be checked. |
Telecommunication TEL
Example:
<telecom value="tel:+491234567890" use="H WP" capabilities="voice fax"/>
Time stamp TS
Example:
<applicationDate value="20101205"/>
Uniform Resource Identification URI
This is actually a character string with a certain pattern.
Example:
<uri value="http://x.y.org"/>
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
- ↑ ITU-T X.660 | ISO/IEC 9834-1
- ↑ ISO/NWIP/TR Health Informatics – Guidance for maintenance of Object Identifiers OID
- ↑ HL7 International
- ↑ OID repository (France Telecom-Orange)
- ↑ OID registry (DIMDI, Germany)
- ↑ Recommendation ITU-T X.680 (2008) | ISO/IEC 8824-1: 2008, Information Technology – Abstract Syntax Notation One (ASN.1), Specification of Basic Notation, 1997
- ↑ 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
- ↑ http://www.oid-info.com/faq.htm#iri
- ↑ ISO 3166-1-alpha-2 country codes
- ↑ ISO 3166 - Codes for the representation of names of countries - The International Organization for Standardization, 3rd edition.
- ↑ ISO 639-2 Codes for the Representation of Names of Languages
- ↑ ISO 21090 Healthcare Datatypes (ISO/FDIS 21090:2009(E))
- ↑ IETF RFC 1738 - Uniform Resource Locators (URL)
- ↑ IETF RFC 2396 - Uniform Resource Identifiers (URI): Generic Syntax