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.
I still wonder about what the correct way is to enter radlex as concept_reference_source into the DB. And how to properly retrieve it.
the concept_reference_source.name is not unique so I guess we have to be ready for the event of two rows with “RADLEX” as their name. Why is the name not unique? What would be a use case?
@akanter@judy would you be in favor of adding a column (constraint unique, but not-null to keep backwards compatibility) to concept_reference_source for its Coding Scheme UID ?
This would make it easy to reliably find a concept source based on its unique and registered OID.
but as MRRT is concerned it doesnt stick to this rule in its name attribute. So the designator OID is the best way to find the concept source as this one has strict rules about its formatting.
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
SCT | 2.16.840.1.113883.6.96 | SNOMED-CT, using the CT code values
SRT | 2.16.840.1.113883.6.96 | SNOMED-CT using the “SNOMED-RT style” code values
But this seems like a suspicious use case to me. Do you have any thoughts about whether we’d ever want to allow two rows in the concept_source table to have the same external_id?
(Of course we should allow multiple rows with a null external_id.)
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.
But if we do it this way, can we also add NamingSystem.uniqueId.preferred ? Otherwise in case of same source, multiple unique_id’s its again bit of a mystery which one should be used.
Seems bit similar to PatientIdentifier, maybe at a later stage we should extract uniqueId into its own domain object with ConceptSource.uniqueIds
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).
