On 16/04/2019 00:16, Heath Frankel wrote:

Hi Tom,

I agree with Grahame, in over 20 years of implementing real systems, I don’t think I recall having seen one value-set that hasn’t been extended at some point when locally implemented. Even HL7 defined tables in V2 that were supposed to not be extended have been extended.

well we need to be precise about what 'extended' means. If you add first level siblings to the previous version of your value set, it means your value set was incomplete when published. If you want to add children (by far the most common case in hierarchical terminologies like SNOMED and ICDx) there's no problem, you are just adding more specific choices of a more general category you already had.

There is a big difference between best-practice and reality and we don’t want to be putting any more barriers to adoption.

To be honest, I am not sure that using required at an archetype level would be wise, it may be something that can be used at a template level.

probably true; any 'required' or other setting should probably only be applied at template level.

You could argue that preferred covers extensible and I agree that example may not be useful in models, but has proven to be useful as a guide for FHIR readers.

Therefore, I think we still have Boolean option, either required or preferred/extensible/example.

Having said that, using a Boolean doesn’t allow for us to support a valid use case in the future and I see some value in aligning with the FHIR options (if HL7 allow us to do that) even if we only support a subset.

well I am looking for computability. If we go the FHIR way, people are going to be writing code like:

if (x.required) {
    // make sure value is from code set
elseif (x.preferred) {
    // hm... anything goes
elseif (x.extensible) {
    if (x.value == some code not in the value set) {
        // hm... how to determine if there was a code
        // in the vs that should have been used?
elseif (x.example) {
    // ?ignore / don't care ?

And probably all doing it differently.

- thomas

openEHR-technical mailing list

Reply via email to