concept reference source and mrrt radiology templates

Tags: #<Tag:0x00007fceb0b9f510> #<Tag:0x00007fceb0b9f448> #<Tag:0x00007fceb0b9f380>

Dear @akanter,

we have implemented Management of Radiology Report Templates (MRRT) http://www.ihe.net/Technical_Frameworks/#radiology in the radiology module.

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.

An example looks like so:

<coding_schemes>
 <coding_scheme name="RadLex" designator="2.16.840.1.113883.6.256" />
</coding_schemes>
<term>
 <code meaning="brain" value="RID6434" scheme="RadLex"/>
</term>

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.

  1. 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?

  2. the concept_reference_source.hl7_code

In MRRT they use the OID/UID as the designator. like shown here https://www.hl7.org/fhir/terminologies-systems.html

which I am able to insert in this column, and which would enable me to uniquely get the concept_reference_source matching the coding_scheme.

However, I see that in the CIEL dictionary SNOMED CT has for example hl7_code=SCT

which I can find at Coding Scheme Designator http://dicom.nema.org/dicom/2013/output/chtml/part16/chapter_8.html

Which for radlex would be hl7_code=RADLEX but this wouldnt help me in uniquely finding the concept_reference_source

I would be very grateful for your input! Thanks a lot!

(@judy I put you in “cc” here)

@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.

I can see now that I need to define hl7_code=“RADLEX” all upper case http://dicom.nema.org/medical/dicom/current/output/html/part16.html#chapter_8

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.

Seems reasonable to me!

1 Like

Dear @burke,

I would like to add an (optional) column concept_reference_source.source_uid + ConceptService.getConceptSourceBySourceUid(String)

as described in

@akanter and @judy are both pro.

Would be great if you could have a look if this also makes sense to you.

dear @jthomas

I would like to discuss

on a design forum

both of these dates work for me:

21 Sep - OPEN 26 Sep - OPEN

Thank you :slight_smile:

@teleivo, who should be at this design call? Particularly, do we need @akanter?

(I can do 21 sep, but not 26 sep, but I should not be a required participant for this.)

-Darius

@akanter would definitely be welcome but I laid out everything here and he agreed to my requested changes. Other than that no special requirements :slight_smile:

@teleivo tomorrow sounds good. I’ll put it on the calendar.

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:

  1. 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

  2. We don’t know whether to require this to be unique or not. I was thinking it should be unique (so that getConceptSourceByExternalId(String) returns 0 or 1 values, but @teleivo has found an example on http://dicom.nema.org/medical/dicom/current/output/html/part16.html#chapter_8 that shows two different codes using the same UID:

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.)

2 Likes

dear @burke and @akanter could I please get your input on the two points of @darius post so I can start working on the issue.

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.

Is the proposed external_id essentially the same thing as FHIR’s unique_id?

it is the Coding Scheme UID here: http://dicom.nema.org/medical/dicom/current/output/html/part16.html#chapter_8 which can be seen as the HL7 OID http://www.hl7.org/oid/index.cfm

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.

seems like the FHIR model defines an own type for the NamingSystem.uniqueId

Am ok with calling it unique_id

by that you mean adding

List<ConceptSource> ConceptService.getConceptSourcesByUniqueId(String)

to the API?

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).

fine by me (radlex only has one external id, as far as Ive seen).

But this means we would not allow the case I presented:

two sources with same unique_id

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

just want to make sure :slight_smile:

if so, can

be worked on by me?

Correct. Having a unique ID pointing to two things is an error.

Of course!

PR is ready :white_check_mark: https://github.com/openmrs/openmrs-core/pull/1846