ISO13582-part1: Unterschied zwischen den Versionen
(Die Seite wurde neu angelegt: „=History of Titles= * ISO/TC 215/WG 3 NWI Proposal 680, TS "Health Informatics - Communication model and XMLInterface Specification for OID Registries (ComoXOID)"…“) |
(kein Unterschied)
|
Aktuelle Version vom 17. Februar 2012, 18:30 Uhr
Inhaltsverzeichnis
- 1 History of Titles
- 2 Stage
- 3 Legenda
- 4 Scope
- 5 Normative References
- 6 Terms, definitions and abbreviated terms
- 6.1 Terms and definitions
- 7 Object Identifiers in healthcare
- 8 Approach
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.
A note. |
A point of discussion. |
A constraint/conformance statement. |
Something that still needs to be worked out. |
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.
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.
- ↑ ITU-T X.660 | ISO/IEC 9834-1
- ↑ 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
- ↑ ISO/NWIP/TR Health Informatics – Guidance for maintenance of Object Identifiers OID
- ↑ HL7 International
- ↑ OID repository (France Telecom-Orange)
- ↑ OID registry (DIMDI, Germany)