FHIR Identifiers Revisited

I want to revisit the HL7 FHIR identifier as I have discovered a few new things.  The Identifier is a complex object that consists of several properties all of which are optional:

<[name] xmlns="http://hl7.org/fhir"> 
 <!-- from Element: extension -->
 <use value="[code]"/><!-- 0..1 usual | official | temp | secondary (If known) -->
 <label value="[string]"/><!-- 0..1 Description of identifier -->
 <system value="[uri]"/><!-- 0..1 The namespace for the identifier -->
 <value value="[string]"/><!-- 0..1 The value that is unique -->
 <period><!-- 0..1 Period Time period when id is/was valid for use --></period>
 <assigner><!-- 0..1 Resource(Organization) Organization that issued id (may be just text) --></assigner>
</[name]>

Here is its definition:
"

A numeric or alphanumeric string that is associated with a single object or entity within a given system. Typically, identifiers are used to connect content in resources to external content available in other frameworks or protocols. Typically, identifiers are used to connect content in resources to external content available in other frameworks or protocols. Identifiers are associated with objects, and may be changed or retired due to human or system process and errors.

"

Here are some of the key identifiers used in Radiology informatics:

Name	Description
MRN or PatientID	Identifies a specific patient
Accession # or Filler Order Number	Identifies a specific radiology procedure or exam
Procedure Code	Identifies a type of procedure or exam (e.g. CT CHEST W/WO)
DICOM Study Instance UID	Identifies a group of related DICOM SOP Instance (or images) - usually for a single radiology procedure
DICOM SOP Instance UID	Identifies a single DICOM SOP Instance (or image)

The most important property of the identifier is value which actually holds the identifier itself.

The next more important property is the system which provides a scope or namespace for the identifier.  Given the different types of identifiers and systems that generate them - conflicts are sure to exist and the system provides a way of describing the context or scope of the identifier.  For example, you could have two RIS systems - RIS A and RIS B.  Both RIS systems were implemented independently of each other and started generating accession numbers starting at 1000.  Given that both systems are using the same accession numbers to identify different radiology procedures - the system must be used to make them unique when used together.  The documentation for system is

"

The namespace for the identifier

"

Here is more information about system from the documentation on identifier:
"

The system referred to by means of a URI defines how the identifier is defined (i.e. how the value is made unique). It might be a specific application or a recognized standard/specification for a set or identifiers or a way of making identifiers unique. The valueSHALL be unique within the defined system and have a consistent meaning wherever it appears. Both system and value are always case sensitive.

FHIR defines some useful URIs directly. OIDs (urn:oid:) and UUIDs (urn:uuid:) may be registered in the HL7 OID registry and should be if the content is shared or exchanged across institutional boundaries. If the identifier itself is naturally globally unique (e.g. an OID, a UUID, or a URI with no trailing local part), then the system SHALL be "urn:ietf:rfc:3986", and the URI is in the value.

"

The documentation refers to some useful URIs for various standardized codes (e.g. SNOMED, LOINC, Radlex, HL7 v2, HL7 v3).  Given the identifiers listed above, it seems that using standardized codes for the procedure code makes a lot of sense.  This is not the case for the other types though which would be generated by information systems such as the EMR, HIS, RIS, Modality or PACS.

It is interesting to note that the concept of unique identities is not new to DICOM.  DICOM adopted the ISO UID scheme for identifying types of DICOM Instances (i.e. SOP Class UID) as well as instance data (Study, Series, Instance, etc).  Equipment that generates DICOM SOP Instances (e.g. Modality, PACS, etc) is responsible for making sure the generated UID's are unique.  This is typically done by registering a unique root UID along with an algorithm to generate the numbers following the root.  The algorithm is not standardized and I have seen many systems incorrectly implement this or installations incorrectly configured which resulting in UID's that are not globally unique.

The DICOM UID root is 1.2.840.10008, the numbers following that are used to identify specific things within that root.  For example, the "CT Image Storage" SOP Class UID is 1.2.840.10008.5.1.4.1.1.2 and the UID used for Implicit Little Endian Transfer syntax is 1.2.840.10008.1.2.

You will notice the term "OID" used in the above documentation.  This is the same concept as UID's used it DICOM with a different name and perhaps issuing authority.  OID's seem to be the direction forward for HL7 FHIR and each system that generates identifies will need to register it with HL7 for $100.

The next property of interest is use which can have any of the following values

Definition
usual		the identifier recommended for display and use in real-world interactions.
official		the identifier considered to be most trusted for the identification of this item.
temp		A temporary identifier.
secondary		An identifier that was assigned in secondary use - it serves to identify the object in a relative context, but cannot be consistently assigned to the same object again in a different context.

I can imagine temp being used to identify unknown patients (e.g. unconscious patient from motor vehicle accident in the ER without any ID).  I suppose secondary could be used for alternative identifiers (e.g. RIS specific patient identifier which is different than patient identifier in the enterprise master patient index).  Official could be used for identifiers that are standardized and therefore the same for all systems in the world.  Some examples include codes (LOINC, HL7 Codes, DICOM SOP Class UIDs, etc).  Usual could be used for identifiers for specific things (patients, visits, exams, studies, images).  Given the list of radiology identifiers above, all of them should probably be "usual" uses except for the procedure code.

The label property might be useful to provide a human readable string for standardized codes.  Standardized codes are usually intended for understanding by computers and not humans.  For example, the DICOM SOP Class UID for storing CT Images is "1.2.840.10008.5.1.4.1.1.2".  Very few people in the world would automatically recognize that number as a CT Image.  For everyone else, it is far more useful to display "CT Image" to the user instead of the number.  This is where the label comes in.  For the radiology identifiers listed above, the best candidate for including a label property is the procedure code.

The last two properties are period and assigner.  The idea behind period is that you can further constrain an identifier through a time period.  I don't have any real world use cases for period so am not sure when it might show up.  The assigner is just a URI to an Organization resource that assigns/generates the identifiers.  This is basically a REST version of the system concept.  

Moving forward with the radiology report repository spike will require that I create identifiers and I should be OK with simply populating the "value" property - although a real implementation should have system populated with a valid OID.