Resolving discrepancies between inactivations in external editions vs the International Edition
Hi everyone
Another conundrum for you :-)
We have found some examples, in this case in the US edition, of concepts that were promoted to the International Edition, but remain in the US maintained module in the US branch.
There are 5 concepts found to be in this situation ie concept table updated in the US module after the concept has been promoted to core:
id core_effectiveTime core_activeFlag us_effectiveTime us_activeFlag term
11000119105 20150131 0 20150301 0 History of peanut allergy (situation)
1111000119100 20120731 0 20130301 0 Sebaceous nevus (disorder)
1561000119105 20160731 0 20160901 0 Diabetic peripheral neuropathy associated with type I diabetes mellitus (disorder)
441000119109 20150131 0 20150301 0 History of cow's milk protein sensitivity (situation)
601000119109 20150131 0 20150301 0 History of bee sting allergy (situation)
There's no way in the tool currently to switch these modules back to the core without producing a row in the international edition. However, this may be acceptable - it would look like a redundant repeated inactivation in the core, and we have validation in the RVF to stop that, but still, it could be done.
In addition, there are 65 cases where the US has added an inactive language refset entry AFTER the international edition has added an active entry. This results in the FSN not being displayed.
(The exception here is 321000119108 History of malignant melanoma of the skin (situation) where the international entry came 2nd, so that case should be fine.)
Unfortunately, as with the concept inactivations, there is no way to legally resolve this situation without creating a duplicate activation in the core edition.
If you can please provide your thoughts asap as to whether or not creating duplicate activation record in the International Edition is an acceptable way to resolve both these situations, and would have no known negative impact to anyone, that would be great?
Thanks very much!
Andrew
Comments
Hi Andrew,
Yikes! Airing out our dirty US Edition laundry are we?
So the 5 examples in the first issue were originally from the Kaiser extension. These were originally submitted to the International (CMT project), rejected for some reason or another, and put into the US Extension. Then they were accepted into the Interntional release. But I think these (other than one of the examples) were inactivated in the subsequent US release following the creation in the INT. I'm going through right now and it looks like they have all been retired in the US Ext.
Adding Jim Case
Just spoke with Jim - we think the issue arose when we inactivated the concepts in the US Extension authoring environment rather than allowing the RF2 process to handle the inactivation after these were included in the International release.
So now that I look at it I see what Andrew and Matt were implying - in the INT release (and anyone using this release) it will look like these inactivated concepts belong to the core. For anyone using the US Edition - it will look like US Extension owns the inactivated concepts. So I think this will only be a problem for Extensions based on US Edition, and possibly any vendor (or other) who tries to combine multiple extensions.
Sorry... not offering any solutions. Just re-stating what's already been said.
As for the other issue with the language refset - this was actually an issue due to the limitations of our WB authoring tool. We're actually open to any solutions (anyone has) to correct the problem....
This doesn't seem to be a problem for the International release.
All extensions (except for US) are going to see this inactivation on the core module.
Only US edition (and any extensions dependent on it) will see the inactivation of a different (US module). But the status (inactive) is still the same, so I can't see a problem.*
Or is the problem, that US content has been promoted again - and the international tooling can't handle the redundancy?
Similarly for the descriptions. This sounds like a "problem" for the US edition, not core? If they've (effectively) retired the core FSN, I'd expect they'd have created some replacement?
And the replacement would have come through as part of the promotion, otherwise, the (invalid) inactivation should be rejected for promotion...
Apologies if there's a context here that I'm missing. But seems fine to me.
* One potential problem here though, is when an extension does something to a component they've promoted at the same effective time as core... Though this currently only a risk for extensions published in January and July...