Retired concept data in OCL

Creating this as an offshoot of migrating-pih-dictionary-to-ocl:

@burke / @paynejd - there are 2 examples of voided/retired concept data that I am comparing in our pre-OCL and post-OCL OpenMRS instance that I want to confirm / discuss:

  • We have several voided concept names in our dictionary. These should really be “retired”, as names are metadata, not data. If one were to want to do so, does OCL provide any means to represent “retired” names? Is this just done by removing a name in OCL, so it would exist in the concept’s version history, but no longer in the concept itself? Is there anything we want to do on the ocl_omrs import side, or on the OCL side to support this differently?

  • We have several retired concepts in our dictionary. These seem to be represented find in OCL - I see a “retired”: true property on the export json for these. Does OCL provide a means to record the retire reason? We have several concepts with specific retire reasons (like “Use CIEL:162816”) that are intended to provide some contextual information. Is there any way to preserve these? Probably not mission critical, but I’m wondering if this is something we might want to add into “extras” and use in the openconceptlab import tool @burke / @ibacher for implementations that want it ?

@mogoodrich and @ball FYI

I’m fine with adding something like this in extras. There is also a “update_comment” field attached to each version of a concept in OCL that we could leverage to put that information (with the advantage that then it would show up in TermBrowsers history view).

However, for the specific example you suggested (i.e., where one concept has been retired and replaced by another) it seems like the right thing to do would be to have a REPLACED-BY mapping on the retired concept pointing to CIEL:162816.

Fair enough. But I’m really just thinking about the migration into OCL here, and I doubt we want to try to parse these retire reasons and make that distinction. Using the “update_comment” field makes a lot of sense to me. I’ve created a ticket for that here: Importing dictionary into OCL should store retire_reason in update_comment · Issue #1118 · OpenConceptLab/ocl_issues · GitHub

@ibacher for some reason I can’t mention you on that OpenConceptLab project. Are you a watcher on there?

Apparently I wasn’t. I’ve watched it now.

You’re correct. Names are not retired, but could be found in the history (previous versions) of a concept in OCL. From the OCL docs:
“Concept names are part of a concept, therefore deleting a concept name will generate a new version of the underlying concept”

If we wanted to retain retired/voided names during import, I can think of a few options:

Import in two steps (add all names including voided at first and then delete the voided names) Would complicate imports. Voided names wouldn’t exist in the export.
Add a “RETIRED” name type (alongside FULLY_SPECIFIED, SHORT, and INDEX_TERM) Voided names could be in the export and, thus, could be brought back into OpenMRS. Voided names would appear as valid names in OCL, would violate validation rules (unless we adapt the rules to ignore names with this name type) and we would lose the type before voiding (i.e., you couldn’t tell if a synonym, FSN, or short name was voided).
Talk to OCL team about adapting OCL’s model Could work like we want, but take more time to implement.

As @ibacher points out, OCL does include an optional update_comment when deleting (retiring) a concept; however, I think this is a property of versions of a concept and not the concept itself – i.e., while you can create a retired concept, I’m not sure you can create a concept with an update_comment property.

My hope is that we can get to a place where you aren’t trying to import update comments into OCL from OpenMRS; rather, you’re supplying a reason (update comment) when retiring the concept in OCL. :slight_smile: