Migrating OIDs to FHIR
Purpose
This page collects input from people looking into implementing FHIR and have vested interest in OIDs. The input will lead to 'best practice' guidance and 'things to consider' in order to help people make informed decisions.
Background
FHIR just like V2 and V3 before that has a way to identify objects. It normally uses a system/value or a system/code pair where the system determines the context for value or code. A system could be viewed as a namespace and is expressed using a uri. A URI could be a URN and a URL [1]. In FHIR the preferred system URI is a URL for readability reasons and the potential for resolving, i.e. a URL could 'lead somewhere'.
In V3 the only option for identifying instances, and code systems has always been an OID. Realms/countries that have ever been involved V3 will have a given number of OIDs for various things they need to identify, some of which would need to be exposed in FHIR as well.
(Best) Practices
First of all a check list:
- Has the OID already been assigned a URI -- check: [2] for a nice checklist
- Does the OID or object(s) it represents have to be used in FHIR?
- if not: consider not assigning anything
- Create a strategy for assigning URLs for what the OIDs represent. Valid strategies include:
- Use symbolicNames from the branches and leaves leading to the OID: [base]/identifiers/ssn where [base] could be http://www.hl7.br
- Use a number of branches for types of identifiers and add any sensible name as a leaf under that:
- [base]/id/ssn
- [base]/vs/AdministrativeGender
- [base]/cs/AdministrativeGender
- If you work from an OID Registry that contains OIDs that have been assigned elsewhere, but that you reregistered for convenience, work with the originator for assigning URLs if you need to.
- Under ISO 13582 you may register additional information like a URL under Reference. Unfortunately the mandatory ReferenceType has a closed list that doesn't seem to fit. The other place to connect the URL in your OID Registry is in AdditionalProperty, but then a type (in attribute/@value) would need to be agreed on. A tiny detail: both type and value support @validTimeLow/High. It seems reasonable to put it on the value to capture when the URL came into being/was deprecated.
<additionalProperty>
<attribute value="systemuri"/>
<value value="http://www.sil.org/iso639-3/codes.asp" validTimeLow="20150513000000"/>
</additionalProperty>
<reference>
Cite error: Invalid <ref> tag;
invalid names, e.g. too many
<type code="LINK"/>
</reference>
