which are html files used as report templates. We have an implementation that extracts this metadata (as concept reference source/reference terms using the ConceptService) and stores Set<ConceptReferenceTerm> terms into the MRRT template object into the openmrs DB.
These files are tagged with term elements which reference entries in coding schemes like radlex or maybe snomed ct.
We discussed on the Design Forum today, and the ticket is almost ready for work. We have two specific questions that we hope @akanter and @burke can help with:
We propose to call the new column “external_id” and not specifying exactly which external coding system one should use for any given Any objection to that name and approach? (Having “uuid” and “uid” would be confusing
I think the external ID makes sense as this is for the coding system and not the code. Whenever a code is used, you have to have a source (but that is not relevant for a list of sources). For the second issue, I asked my standards specialist about this re-use of the OID and haven’t heard back. Since SNOMED RT is a prior VERSION of SNOMED CT, perhaps that is the reason (and there is no overlap of codes between them since they refactored the codes). It does raise the question of whether there should be a source/code/version recording in the code recording or whether the version is irrelevant.
and you can look them up at this registry http://www.oid-info.com/
(which gives you a detailed description of this OID tree: which standards organization was it registered at/country/name & details of the organization its registered to)
Ok. So, per the description of FHIR’s uniqueId.type, OID is a type of unique ID.
I would favor, when refactoring our model, we move toward the FHIR model – i.e., use “unique_id” instead of “external_id” and, whether or not we decide to support more than one uniqueId per source in the db now, build the API methods assuming a source might have more than one unique ID.
Per FHIR’s design, a source may have more than one unique ID (e.g., OID, URI, etc). This does not mean that there should be more than one source for any given unique ID.
So, I would expect asking for the unique ID for a given source may return more than one type, but a search by unique ID would return a single source (since the ID, by definition, should be unique to one source) – i.e., ConceptSource conceptService.getConceptSourceByUniqueId(String).