Local Value-set Replacement

Created by Thomas Beale
Last updated: 29-Jan-2020

Original discussion

(See email from SBL, BF, IM etc)

Summary (TB)

I have created https://openehr.atlassian.net/browse/SPECPR-302 for this. Please check if the description reflects the need.

Having thought about it a bit more, what we are really doing here is formalising value externally defined sets/vocabularies that do not happen to yet be formally expressed or maintained anywhere. But the replacement vocabulary isn't something that is being created or maintained by the archetype modeller as such, but in fact by some other authority, e.g. MoH Norway / IKT, or some physicians college, or a researcher, or whatever.

What we/someone should really be doing is formalising those vocabularies properly, even in a simple way like we already do with the openEHR terminology, and treating them as external terminologies, and using binding as I proposed. As far as I can see, semantically that reflects what is happening.

So I am not really in favour of going down this path where these vocabularies are hidden inside specific archetypes or templates, because then there is no single authoritative instance of them - as soon as someone decides to add another term, they create another disconnected expression of these terms, and the template of course only sees the old set that is hard-wired inside. Archetypes are not really a vehicle for representing and maintaining vocabularies, other than those only used within the archetype and nowhere else.

I'd like therefore to get a better idea of who maintains this Norwegian vocabulary, who can decide changes, etc, and how those changes are supposed to flow through to all users of it, including copies inside private templates. For example, why isn't it Nasjonal IKT's job to formalise and maintain this vocabulary, if noone else has?

I know this is not what you want to hear, but hacking has consequences, and they always come back to bite, worse than the original problem...

Candidate Solution

Result;

add the following to C_TERMINOLOGY_CODE

  • required: Boolean ;
  • recommendation: required | preferred | example

+ describe mapping from FHIR settings

+ describe behaviour through archetype specialisation

+ describe 3 strategies

  • DV_CODED_TEXT + DV_TEXT
  • subsumption code + reduction redefinitions
  • new required markers