Glossary:
HL7 Nederland OID Registratie procedure.
Dit document bevat een beschrijving van de OID registratie procedure zoals deze van toepassing is op de door HL7 Nederland uit te geven OIDs. Het grootste deel van dit document is gebasseerd op een internationaal afgestemd document en is om deze reden in het Engels gesteld.
Het aanvraagformulier voor het registreren/aanvragen van een OID is opgenomen in bijlage B, deze bijlage bevat tevens een Nederlandstalige toelichting op de diverse elementen van het OID registratieformulier.
Bijlage C beschrijft de interne afhandeling en registratie procedure binnen HL7 Nederland.
Vragen of opmerkingen over dit document kunt u sturen naar de auteur: Rene.Spronk@Ringholm.nl
1.Introduction
HL7 Version 3 messages (and CDA documents) use OIDs (unique Object Identifiers) to identify coding schemes and identifier namespaces. OIDs can be allocated by any organisation using a unique OID root. A single message can use OIDs from various sources and a single scheme can be identified by more than one OID (e.g. by an OID from more than one organisation). Once issued an OID is never withdrawn and always identifies the same scheme or object.
This document describes how the HL7 community can find the appropriate OID related to a scheme and how to request/assign a new OID if a scheme doesn’t have an OID assigned to it.
The process of assigning an OID by HL7 is the process of checking if the scheme in question doesn’t already have an OID assigned to it within the HL7 OID hierarchy, and if not, to assign an OID within the appropriate OID branch of the HL7 OID root.
The process of registering an OID with HL7 is just that: the addition to a central registry of an OID and its descriptive data. The OID doesn’t have to be within the HL7 root OID or any specific other root or branch OID. Once a scheme has been registered, no other OIDs that identify the same scheme can be registered.
You are referred to the glossary (Appendix A) for a further explanation of terms like UID, OID, Assigning Authority, Assigning an OID, Registering an OID, OID root and OID Branch Root.
2.The HL7 OID registration/assignment process
To assist projects using HL7 messages that require OIDs for coding and schemes and namespaces, HL7 has a registered ISO OID and will allocate OIDs under that root. Individual HL7 Affiliate organizations have been assigned a Branch OID under this HL7 root OID. HL7 member organizations may request the registration of a Branch OID under the HL7 root ID or the HL7 Affiliate Branch OID. OIDS for use with HL7 Messages (except for OIDs used within HL7 Member’s Branch OIDs) have to be registered by one of these authorities: HL7 International, an HL7 Affiliate, or HL7 Member.
HL7 and its affiliate organizations shall establish an OID registry and assign OIDs for HL7 users and vendors upon their request. HL7 and its affiliate organizations shall also register (or assign) OIDs to public identifier-assigning authorities (e.g., the U.S. State driver license bureaus, U.S. Social Security Administration, HIPAA Provider ID registry, other countries Social Security Administrations, Citizen ID registries, etc.) The HL7 or affiliate organization’s registered OIDs must be used for these organizations within the context of HL7 messages, regardless whether these organizations have other OIDs assigned from other sources.
When assigning OIDs to third parties or entities, HL7 shall investigate whether an OID is already assigned for such entities through other sources. If this is the case, HL7 shall record such OID in its OID registry, but HL7 shall not assign a duplicate OID in the HL7 branch. If possible, HL7 shall notify a third party when an OID is being assigned for that party in the HL7 branch.
Though HL7 shall exercise diligence before assigning an OID in the HL7 branch to third parties, given the lack of a global OID registry mechanism, one cannot make certain that there is no pre-existing OID assignment for such third-party entity. Also, a duplicate assignment can happen in the future through another source. If such cases of supplicate assignment become known to HL7, HL7 shall make efforts to resolve this situation. For continued interoperability in the meantime, the HL7 assigned OID shall be the preferred OID used.
While some owners of an OIDWhile HL7 like some OID owners mayhas "designed" their namespace sub-treehierarchy in asome meaningful way, this has only been done to aid the registration and maintenance processes for OIDs and is in no way intended to convey any meaning. HL7 will make no guarantee of the validity of this hierarchy and so the rules that outline it, meaning that any information that is inferred from an OID about the object associated with it may be incorrect.
there is no way to generally infer any meaning on the parts of an OID. HL7 does not provide or require that a standardized or require any namespace sub-structure be used by those members to whom it assigns OID branches, in their future OID assignments. It is however advised that a defined hierarchy be used to aid the practice of uniqueness between OIDs and also to aid maintenance of them. If a member does not already have a structure in place to deal with OID assignment, it is recommended that the one currently adopted by HL7 be used..
An OID owner, or anyone having knowledge about the logical structure of part of an OID, may still use that knowledge to infer information about the associated object; however, the techniques cannot be generalized. HL7 will make no guarantee of the validity of any such analysis algorithms.
HL7 International Affiliates will establish their own procedures to define and maintain realm-specific variations for vocabulary domains.
OIDs can be registered by HL7 (International) where:
• There is a known existing OID (which may have been assigned by HL7 (International) as a direct result of this registration/assignment request, or may have been assigned by some other assigning authority).
• There is no known existing OID within the HL7 (International) registry that identifies the same scheme as identified by the OID in the registration request.
• There is a requirement for the OID to be used in HL7 messages that transcends any of the geopolitical areas covered by any of the HL7 Affiliates.
• The requester is a member of HL7 or the requester is an HL7 Affiliate.
OIDs can be registered by an HL7 Affiliate where:
• There is a known existing OID (which may have been assigned by the HL7 Affiliate as a direct result of this registration/assignment request, or may have been assigned by some other assigning authority).
• There is no known existing OID within the HL7 (International) or HL7 Affiliate OID registry that identifies the same scheme as identified by the OID in the registration request.
• There is a requirement for the OID to be used in HL7 messages within the geopolitical area covered by the Affiliate, i.e. the scheme identified by the OID is specific to the geopolitical area covered by the Affiliate.
• The requester is a member of the OID-assigning HL7 Affiliate or a member of HL7 residing in the geopolitical area covered by the Affiliate.
OIDs may be assigned by HL7 Members within their own HL7 Branch OIDs where:
• They have been assigned a registered HL7 branch for their use as a root.
• There is a requirement for an OID that will be used in an HL7 message within the HL7 Member organisation, i.e. the requirement is specific to the organization, its systems or its applications.
• It is strongly recommended that HL7 Members assigning OIDs within their own Branch follow the practice of uniqueness and persistence of the OIDs so assigned.
• OID so assigned may be registered for use outside of the single member organization, but may encounter resistance if the OID to be registered is not well formed.
Examples:
• Coding schemes created by professional bodies that are intended to be used widely (e.g. SNOMED, LOINC, ICD) need to be registered by HL7 International.
• ISO or CEN coding schemes need to be registered by HL7 International.
• NEN, DIN or ANSI coding schemes (if used in just one country) need to be registered by the appropriate HL7 Affiliate.
• Civil namespaces (identification schemes) such as Drivers License, Social Security Numbers need to be registered by the appropriate HL7 Affiliate.
• Coding schemes created by professional bodies that are intended to be used within a specific profession in a specific country (e.g. A national coding scheme used by Dutch midwifes) need to be registered by the appropriate HL7 Affiliate.
3.Good OID usage practices
The following recommendations and guidelines should be considered if an organization uses OIDs in HL7 messages:
• An organization should use existing OIDs if they are registered. A local OID (within the organizations OID Branch) should not be used for something that has a registered OID.
• The organization will not use an OID registered elsewhere and use it to identify a different object/scheme than was originally specified.
• When an organization has submitted an OID registration request, and the responsible assigning authority denies the creation of a new standard OID (e.g. because of the fact that an OID for the namespace already exists), and the denial provides an alternative method to meet the need (i.e. an OID that was previously registered), the organization will adopt the alternative method.
• An organization will not assign an OID to a scheme that may also be used outside of the organization. These need to be registered by the HL7 (International) or the HL7 Affiliate registry. Locally assigned OIDs for namespaces or coding schemes used by a cooperating group of interoperating partners are generally assigned under the branch of one of the partners, and then may be registered with the appropriate HL7 body.
• Where the organization finds the necessity to use local OIDs, it may submit them to HL7 or the HL7 Affiliate for review and registration. This should only be done in case of doubt whether or not a scheme is used outside of the organization.
4.Registration process for the HL7 Netherlands Branch OID
OID registration and assignment requests may be directed to the secretariat of HL7 Netherlands if the requester is a member of HL7 the Netherlands or a member of HL7 (International) residing in the Netherlands.
All OID requests (for registration with HL7 Netherlands or HL7 International) should use the OID request form as contained in Appendix B.
The process of registration/assignment of a scheme and the corresponding OID does not constitute an endorsement by HL7 Netherlands for the registered scheme. The process is therefore not subject to a vote of the HL7 Netherlands membership. The process (which is out-of-scope of this document) of determining what schemes should be used in HL7 messages in the Netherlands is subject to a vote of the HL7 Netherlands membership.
4.1.The HL7 Netherlands Branch OID
The structure of the Dutch HL7 Branch OID is as follows:
|The HL7 Netherlands Branch OID is |2.16.840.1.113883.2.4 |
|The following HL7 Netherlands sub-branches will be used: |
|OID roots assigned to HL7 Members by HL7 Netherlands |2.16.840.1.113883.2.4.3 |
|External Identification schemes registered with HL7 Netherlands |2.16.840.1.113883.2.4.4 |
|Dutch Realm-specific extensions to HL7-maintained v3 Coding schemes |2.16.840.1.113883.2.4.5 |
|Dutch Realm-specific extensions to HL7-maintained v2 Coding schemes. |2.16.840.1.113883.2.4.12 |
|HL7 Netherlands maintained coding schemes |2.16.840.1.113883.2.4.15 |
|External Coding schemes registered with HL7 Netherlands |2.16.840.1.113883.2.4.6 |
|Non-permanent OIDs used for testing and debugging purposes. OIDs under this root won’t be |2.16.840.1.113883.2.4.99 |
|registered by HL7 Netherlands. | |
All OIDs registered under this Branch OID will be subject to the registration process as set out in this document.
4.1.1.External coding schemes (hl7nl.6)
The OIDs registered in this OID Branch will be used to uniquely identify coding schemes used within the Netherlands.
Examples:
• The G-standaard (medication) maintained by Z-Index
• The WCIA Table 25 (drug administration) maintained by NHG.
4.1.2.Extensions to HL7-Maintained coding schemes
The OIDs registered in the hl7nl.5 and hl7nl.12 OID Branches will be used to uniquely identify concepts used within the Netherlands that are not available in a HL7(International)-maintained coding scheme. This applies mainly to suggested values for User Defined tables in HL7 version 2, and CWE attributes in version 3.
The concepts in these Realm-specific code tables have to be “semantically disjunct” from the concepts in the Universal realm table (i.e. the table as defined by HL7 International). Values in the Realm-specific table may also be refinements of a broad concept that was defined in the Universal realm table.
The ‘Value Set’ used for a Dutch Realm Vocabulary will consist of a subset of the concept codes defined in the Universal Realm table combined with (a subset of) the concept codes defined in the Dutch realm table. HL7 Vocabularies have a direct relationship with Value Sets, not with a specific coding system or code table. The contents of a vocabulary (i.e. the contents of the applicable value set) have to be determined by the HL7 Affiliate. The process of deciding on an applicable Vocabulary is out of scope of this document.
4.1.2.1.Extensions to HL7-Maintained v3 coding schemes (hl7nl.5)
HL7 International uses the OID 2.16.840.1.113883.5.n as a unique identifier of HL7 version 3 vocabulary tables. These tables apply to the Universal Realm. The Dutch OID 2.16.840.1.113883.2.4.5.n shall refer to a table that contains the Dutch Realm Extensions (and only the extensions) to the Universal realm table.
The concepts in this extended table have to be “semantically disjunct” from the concepts in the Universal realm table.
4.1.2.2.Extensions to HL7-Maintained v2 coding schemes (hl7nl.12)
HL7 International uses the OID 2.16.840.1.113883.12.n as a unique identifier of HL7 version 2 vocabulary tables. These tables apply to the Universal Realm. The Dutch OID 2.16.840.1.113883.2.4.12.n shall refer to a table that contains the Dutch Realm Extensions (and only the extensions) to the Universal realm table.
The concepts in this extended table have to be “semantically disjunct” from the concepts in the Universal realm table.
Example: HL7 version 2 table 0004 – Patient Class. The HL7 (International) Table contains the value ‘I’ for inpatient. Table 0004 in the Dutch Implementation guide contains the value ‘D” for Daycare patient. The concept of ‘Daycare Patient’ is not included in the HL7 (International) table.
(2.16.840.1.113883.12.4) User-defined Table 0004 - Patient class
|Value |Description |
|E |Emergency |
|I |Inpatient |
|O |Outpatient |
|P |Preadmit |
|R |Recurring patient |
|B |Obstetrics (poliklinische bevalling) |
|C |Commercial Account |
|N |Not Applicable |
|U |Unknown |
(2.16.840.1.113883.2.4.12.4) HL7 Netherlands Table 0004 - Patient class
|Value |Description |
|D |Dagbehandeling |
|K |Keuring |
In HL7 messages, the concept ‘Inpatient’ is identified by (OID of table 0004=2.16.840.1.113883.12.4, extension=I). The concept ‘Daycare Patient’ is identified by (OID of Dutch extended table 0004=2.16.840.1.113883.2.4.12.4, extension=D)
4.1.3.HL7-Netherlands Maintained coding schemes (hl7nl.15)
The OIDs registered in this OID Branch will be used to uniquely identify Tables (and indirectly: concepts) used in new Vocabularies introduced by new HL7 artefacts. These artefacts may be the result of the HL7 localization process or of pilot projects related to domains that aren’t covered by the HL7 standard.
All OIDs used in connection with Artefacts that result from the HL7 version 3 localization process have to be registered with HL7 (International) for tooling purposes.
Examples:
• HL7-Netherlands maintained coding schemes used for new vocabularies in the perinatology pilot project.
• HL7-Netherlands maintained coding schemes used for new vocabularies introduced by the extending (i.e. localization) of a CMET.
4.1.4.External Identification Schemes (hl7nl.4)
The OIDs registered in this OID Branch will be used to uniquely identify identification schemes used within the Netherlands. All identification schemes related to public-identifier assigning authorities shall be registered by HL7 Netherlands.
HL7 Netherlands shall register (and assign) OIDs to public identifier-assigning authorities (e.g., the ZIN, UZOVI, GBA, SOFI, Passport numbers, Vektis, Insurance Company Ids, etc.) The HL7 Netherlands registered OIDs must be used for these organizations, regardless whether these organizations have other OIDs assigned from other sources.
4.1.5.Branch OIDs assigned to HL7 Members (hl7nl.3)
Organizations that are members of HL7 Netherlands may register an OID within this branch. The organization is the assigning authority and may use the OID as it sees fit, subject to the ‘good OID registration practices’ as described in this document. While most owners of an OID will "design" their namespace sub-tree in some meaningful way, there is no way to generally infer any meaning on the parts of an OID. HL7 does not standardize or require any namespace sub-structure. An OID owner, or anyone having knowledge about the logical structure of part of an OID, may still use that knowledge to infer information about the associated object; however, the techniques cannot be generalized.
If an organization is not a member of HL7 it may elect to register an OID with the Nederlands Normalisatie Instituut (NEN) organization. OIDs registered with NEN (starting with 1.2.528 or 2.16.528) can be found at:
.
At the moment of writing (Feb.2003) NEN charges an initial registration fee of € 300 for a period of 2 years, and € 200 for every 2 years thereafter.
5.Acknowledgements
Parts of the introduction in this document have been derived from the HL7 version 3 ballot material, the UK GP2GP project documentation and Harold Solbrig’s ‘HL7 Vocabulary Maintenance Language’ document.
We’d also like to thank Fred Behlen, Harry Solomon, Kai Heitmann, Ted Klein, and Tom de Jong for their review of this document.
Appendix A: Glossary
UID: A unique identifier string is a character string which identifies an object in a globally unique and persistent manner. The allowable formats and values and procedures of this data type are strictly controlled by HL7. The sole purpose of the UID is to be a globally and persistently unique identifier. The form of the UID, whether it is an OID, an UUID or any other form is entirely irrelevant. As far as HL7 is concerned, the only purpose of an UID is to identify the object for which it stands. Comparison of UIDs is literal, i.e. if two UIDs are literally identical, they are assumed to identify the same object. If two UIDs are not literally identical they may identify the same object (and in general are assumed to identify different objects.)
OID Scheme: A globally unique string representing an ISO Object Identifier (OID) in a form that consists only of numbers and dots (e.g., "2.16.840.1.113883.3.1"). According to ISO, OIDs are paths in a tree structure, with the left-most number representing the root and the right-most number representing a leaf.
Each branch under the root corresponds to a namespace (which is under the control of an assigning authority). Each of these namespaces may, in turn, designate its own set of namespaces, and so on down the line. Note that each object assigned an OID in a namespace by an Assigning Authority must uniquely identify that object, whether it is another namespace or some other object. Eventually, one of these authorities assigns a unique (to it as an assigning authority) number that corresponds to a leaf node on the tree. The leaf may represent an assigning authority (in which case the OID identifies the authority), or an instance of an object. An assigning authority owns a namespace, consisting of all of the OIDs immediately under its node in the tree structure. The assigning authority may own more than this single level in the tree structure, or may delegate ownership of any branch that it owns.
OIDs are the preferred scheme for defining the namespace of unique identifiers. OIDs should always be used except if one of the inclusion criteria for other schemes apply. Note that the OID is the root of an identifier, and a suffix must be unique within the namespace of that root. The complete identifier is the OID root concatenated with a dot (“.”) and the suffix, thereby guaranteeing global uniqueness for the entire identifier.
ISO/IEC 8824:1990(E) clause 28 defines the Object Identifier as:
28.9 The semantics of an object identifier value are defined by reference to an object identifier tree. An object identifier tree is a tree whose root corresponds to [the ISO/IEC 8824 standard] and whose vertices [i.e. nodes] correspond to administrative authorities responsible for allocating arcs [i.e. branches] from that vertex. Each arc from that tree is labelled by an object identifier component, which is [an integer number]. Each information object to be identified is allocated precisely one vertex (normally a leaf) and no other information object (of the same or a different type) is allocated to that same vertex. Thus an information object is uniquely and unambiguously identified by the sequence of [integer numbers] (object identifier components) labeling the arcs in a path from the root to the vertex allocated to the information object.
See Harald Alvestrand's website () for additional information about Object Identifiers. Large parts of the OID tree can be browsed online via the French ASN.1 website, (). For the formal definition of OIDs, see RFC 3001 - A URN Namespace of Object Identifiers: ()
Requesting/assigning an OID: The process of assigning an OID by HL7 is the process of checking if the scheme in question doesn’t already have an OID assigned to it within the HL7 heirarchy, and if not, to assign an OID within the OID branch of the assigning authority.
Registering an OID: The process of registering an OID with HL7 is just that: the addition to a central registry of an OID and its descriptive data. The OID doesn’t have to be within the HL7 root OID or any specific other root or branch OID. Once a scheme has been registered, no other OIDs that identify the same scheme can be registered. Registration of an OID does not imply any statement of quality about the scheme registered. The OID merely identifies the scheme. Inclusion of an OID in a HL7 registry does not imply a right to access the associated coding scheme data which in many cases is associated with copyright and/or privacy/licensing restrictions.
Assigning Authority: An organization that registers and/or assigns OIDs.
Root OID: Any OID that is used as a namespace for other OIDs, and has arcs (vertices, nodes) beneath it. Any OID has a succession of Root OIDs above it that may be walked all to way to the top of the global OID hierarchy (all of which begin with the integers 0, 1, or 2)
Branch OID: Any OID beneath a Root OID that serves as a namespace identifier for objects or OIDs beneath it.
Leaf OID: Any OID which directly identifies a single information object and has no other Branch OIDs beneath it.
Realm: A geopolitical area (e.g. country, province, group of countries). HL7 Vocabularies may have a different value-set (i.e. a list of coded values, concepts) depending on the realm where the HL7 message is used.
Code System: A code system contains a set of unique concept codes. Each concept code serves as a token to represent a useful category or class as viewed from a particular perspective. The definition and organization of the tokens within a code system represents assertions about the organization of the corresponding categories and classes within a real world. A code system may also carry information about the various ways that the categories or classes are identified in different situations and languages, as well as additional defining and identifying information that serves to clarify the intended meaning of the tokens
Value Set: A value set represents a list of concept codes. Value sets are used to specify a set of possible values for one or more RIM-derived coded attributes.
Vocabulary Domain: A vocabulary domain represents an abstract conceptual space that can be associated with RIM-derived coded attributes. A vocabulary domain can be represented by one or more value sets, where each associated value set applies in a given context.
App.B: HL7 Netherlands Member Request Form for an OID
This form can be used to request the registration of an OID for an existing coding or identification scheme, or to request a Branch OID under the HL7 Netherlands root for your own use. This OID will be registered in the HL7 Netherlands OID registry or in the HL7 International OID registry.
Please fill out information in all appropriate cells in right-hand column. See next page for an explanation of the various items (in Dutch).
|Description |Value |
|1. Submitter Name: |Name: |
| |Email: |
|2. Submitter Organization: |Name: |
| |URL: |
|3. Contact Person: |Name: |
| |Address: |
| |Phone: |
| |Email: |
|4. Are you (or your organization) |a member of a HL7 Netherlands |
| |a member of HL7 (International) residing in the Netherlands |
| |other: please specify your relationship with HL7 |
|All OID registration requests: | |
|9. For OID assignments to Identifier Systems (coding- or ID | |
|schemes), the responsible body and its OID (if it has one) | |
|10. Desired Symbolic Name: | |
|11. Description of the Object identified by the OID (be as | |
|comprehensive as you wish) | |
|External OIDs: | |
|7. The OID value if you are registering an external OID | |
|8. If it is an external OID, the Assigning Authority and its | |
|OID (if it has one): | |
|HL7 assigned OIDS: | |
|12. Relationship, if any, to other HL7 items (vocabulary | |
|domains, RIM objects, etc): | |
|13. The type of OID. (Select one of: HL7 body; HL7 Member | |
|Organization, External coding system, Message Profile, | |
|Template, Other) | |
|14. Other comments or requests: | |
Nederlandse toelichting op het OID registratie (aanvraag) formulier.
Het formulier is zowel bedoeld om OIDs aan te vragen (d.w.z. dat HL7 Nederland of HL7 Internationaal er een uitdeelt) of om bestaande OIDs (die door een andere organisatie, bijvoorbeeld NEN, ISO zijn uitgegeven) te registreren.
Een toelichting op de diverse items op het aanvraagformulier:
1/2/3: Naam, adres en contacpersoon van de organisatie/persoon die de OID registratie (cq aanvraag) doet;
4: Gegevens over uw lidmaadschap van HL7. Indien u lid bent van HL7 Internationaal en in Nederland woonachtig bent / kantoor houdt of als u lid bent van HL7 Nederland dan kunt u de OID registratie (cq aanvraag) richten aan HL7 Nederland. In de overige gevallen wordt u verzocht uw relatie tot de HL7 organisatie aan te geven.
6: Betreft het de registratie van een reeds eerder (extern, door een andere organisatie dan HL7) uitgegeven OID, of de aanvraag tot het uitdelen van een nieuwe (intern binnen HL7 toe te wijzen) OID.
7/8: In het geval van registratie van een bestaande OID: de OID, en de identificatie van de organisatie die deze OID heeft uitgegeven.
9: De organisatie die de code tabel beheert of de identificatie methode heeft vastgelegd. Dit kan dezelfde organisatie als de aanvrager zijn. Voorbeelden: LMR, de Nederlandse Overheid, KPMG, HL7 Nederland, Vektis, etc.
10: Een label (een ‘korte omschrijving’) voor datgene wat de OID identificeert. Voorbeelden: “ICD-9”, “SNOMED”, “Vektis Zorgverlenertabel”, “Nederlands Paspoort Nummer”.
11: Een (mogelijk zeer uitgebreide) beschrijving van datgene wat de OID identificeert. Deze beschrijving kan tevens referen aan externe documenten of websites.
12: Indien van toepasing: waar in HL7 versie 3 zal deze OID (of eigenlijk: datgene wat het identificeert) worden toegepast ?
13: In welke categorie valt deze OID ? Binnen welke OID Branch binnen HL7 International of HL7 Nederland (zie de structuurindeling in dit document) valt naar uw mening de te registreren OID ? Identificatie mechanisme / Externe (door een organisatie buiten HL7 vastgestelde) Vocabulaire / HL7 Interne vocabulaire / Aanvraag voor het toekennen van een Branch OID oor uw eigen organisatie.
App.C: OID Registratieprocedure HL7 Nederland
De OID registratieformulieren (zoals opgenomen in appendix B) worden verzonden aan het Secretariaat van HL7. Deze stuurt de aanvraag door naar de voorzitter van de IM-werkgroep (voorheen bekend als Control/Query). Indien de aanvraag via een web-formulier op de website van HL7 Nederland gedaan wordt kan deze direct worden verzonden aan de werkgroep voorzitter.
De voorzitter van de IM-werkgroep handelt het verzoek af, eventueel in e-mail samenspraak met andere TC-leden. In ieder geval zal het regsiter van HL7 (internationaal) worden geraadpleegd, zoals te vinden op onder het kopje ‘OID Registry’.
HL7 the Netherlands shall only assign OIDs under its own Branch OID. OIDs will be registered by HL7 Netherlands where:
1. There is a known existing OID (which may have been assigned by HL7 Netherlands as a direct result of the registration/assignment request, or may have been assigned by some other assigning authority).
2. There is no known existing OID within the HL7 (International) or HL7 Netherlands OID registry that identifies the same scheme as identified by the OID in the registration request.
3. There is a requirement for the OID to be used in HL7 messages within the Netherlands, i.e. the coding/identification scheme identified by the OID is specific to the Netherlands.
OID requests will be forwarded to HL7 (International) for registration should, in the opinion of HL7 Netherlands, the scheme be useful outside of the Netherlands.
Indien er om wat voor reden dan ook geen nieuwe OID door HL7 Nederland wordt aangemaakt of geregistreerd dan brengt de voorzitter van de IM-werkgroep de aanvrager daarvan op de hoogte.
Het Nederlandse register dient publiekelijk ter beschikking te zijn. Om deze reden wordt het register in de vorm van een document gepubliceerd op de website van HL7 Nederland.
Het register wordt beheerd door de voorzitter van de IM-werkgroep en bestaat voorlopig uit een excel-spreadsheet. Na iedere wijziging van de spreadsheet wordt een PDF versie (via het secretariaat) op de website gepubliceert.
It is the intent of HL7 Netherlands to add functionality to its website that will allow for the viewing of the registry as well as the on-line registration of an OID.
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related download
- oceanwide bridge user guide reference and administration
- configuration management plan draft
- cancore guidelines version 1
- bridge user guide reference and administration
- records and information management toolkit volume 1
- managing current records a procedures manual
- appendix 3 48 materiel release document dd form 1348 1a
Related searches
- dod fmr glossary volume 2a
- glossary synonym
- glossary of philosophical terms
- glossary of philosophy terms
- glossary of philosophical terms pdf
- philosophy glossary pdf file
- glossary of terms examples
- medical glossary of terms
- glossary terms and definitions
- insurance glossary pdf
- history glossary terms
- economics glossary pdf