Proposal: Medication Dispense OpenMRS module

Development
, , ,
41

This does vary quite a bit depending on where the code system is used. Certainly FHIR uses canonical URLs, but these are not used in all domains, e.g., in DICOM concept sources are still identified by OID. (DICOM compatibility was what was behind adding the unique_id field–this is actually why I didn’t use the unique_id field to provide this information for FHIR2). And, of course, for HL7 v2, we do still need to capture the HL7 v2 spec-defined code for the code system (or it’s OID as a fallback).

I don’t think we’re really getting to a world where DNS controls things. Even FHIR uses URIs that are not valid URLs and have no obvious recourse to the DNS system. For example, FHIR still uses OIDs as its preferred identifier for terminology systems not explicitly defined in the FHIR spec. If I had strictly followed FHIR’s guidance, CIEL codes should really be reported with a system of urn:oid:2.16.840.1.113883.3.7201 (IIRC, this was briefly the case). There are likewise few other “well-known” code systems where FHIR similarly uses URNs rather than URLs, e.g. for ISO-defined code systems like ISO 3166 (urn:iso:std:iso:3166). IETF BCP values similarly use a urn scheme like urn:ieft:bcp:47. However, I don’t know how widely-used these identifiers are outside of a FHIR context.

The point here is that I do think adding canonical URLs (or URIs) directly to concept sources is a net-win for FHIR support and probably useful, it’s not clear to me that there is any single system for uniquely identifying concept sources that can be used in any context.

I might suggest the following changes make some kind of sense:

  1. Rename unique_id to oid or object_identifier (unique_id was a poorly chosen name).
  2. Add a fhir_uri field (or something similar) to the concept_source.
  3. Drop the fhir_concept_source table altogether.