Sibling RM class that can represent terminology information are indistinguishable

Description

In bot ADL2 and ADL, when using a reference model that allows to define codes in different classes it is not possible to know which class the constraint was originally applied to, which makes impossible to correctly generate and validate data. As an example, this happens in ISO13606, CDA, FHIR... in fact, it will happen in any standard that uses ISO21090. As an example, see this excerpt where it is impossible to parse ADL back (even if we know the RM we are working with):

ELEMENT[id11] matches {
value matches {[ac1]}
}

Suggested approach: allow putting RM type before the [acxxxx] code.
Solves the problem and requires no modifications to AOM, as rmtypename comes already from C_Object class by inheritance. This also makes ADL clearer as uses the 'same' syntax as every other C_object constraint (Complex object, slot, or proxy) in the form of CLASSNAME[code]

Environment

None

Activity

Show:
Thomas Beale
May 10, 2016, 12:53 PM
Edited

I think I half understand this... is it because ISO21090 has CS, CD, CV etc? So does it mean you would want to put something like:

ELEMENT[id11] matches {
value matches {CD[ac1]}
}

This works (without the CD), if you have set something in the AOM profile to match classes like CD with the native TERMINOLOGY_CODEin AOM2. See http://www.openehr.org/releases/AM/latest/docs/AOM2/AOM2.html#_aom_profile_configuration

I don't think this is needed, because you can remove that configuration, and put:

ELEMENT[id11] matches {
value matches {
CD[id12] matches {
codeValue matches {[ac1]}
}
}
}

Diego Bosca
May 10, 2016, 3:27 PM

but in the second example if you want to also define the subset of displayName you must repeat the binding, and also put something extra to state that codes and display names correspondences must be correct.

Main problem comes when validating and such, as even if you can create a profile to match CD, CV, etc. to TERMINOLOGY_CODE you cannot validate if the data type is the one you chose in the archetype

I will make the example a little more complicated. Imagine that the archetype provides alternatives to different bindings to different terminologies.
ELEMENT[id11] matches {
value matches {
[ac1] --CD
[ac2] --CV
[ac3] --CE

}
}

When you look at the instance, it won't be possible to validate that ac1 is indeed a CD

Thomas Beale
May 10, 2016, 4:38 PM

Normally you would just do this:

ELEMENT[id11] matches {
value matches {
CD[id12] matches {
codeValue matches {[ac1]}
}
CV[id13] matches {
codeValue matches {[ac2]}
}
CE[id14] matches {
codeValue matches {[ac3]}
}
}
}

I don't remember the definition of displayName in 21090 - isn't it fixed once you know the codeValue?

Diego Bosca
May 11, 2016, 8:52 AM

Probably not "fixed" but one of the valid synonyms for the specified code. Being able to define constraint bindings into classes allows the simplification of archetype constraints, as multiple bindings and rules must be defined if you specify it attribute per attribute.

CD[id12] matches {
codeValue matches {[ac1]} --original subset codes
displayName matches {[ac2]} --same subset, but only the description part, also needs a rule to enforce that the description is one for the code
codingSchemeName matches {"SNOMED-CT"} – if you put the binding into the CD, this comes for free and doesn't need to be specified
}

Thomas Beale
May 11, 2016, 9:53 AM

Hm. The usual assumption is that the chosen code (and scheme name) will be used as a key in a query to a terminology service to obtain the full definition. There is no assumption that the code provides all the data required to populate the terminology object at runtime.

If ac1 is bound to say http://snomedct.info/id/9000012345678 (in a 'snomedct' binding group) then this can be an intentional ref set definition, which will contain some expression that allows (or not) specific synonyms. Let's assume that ref set is evaluated against SNOMED CT; the result is some set of concept ids. Now, depending on the API of the service, it should normally be possible to return the set of full terminology entities, as instances of some TerminologyConcept class as defined in CTS2 or another API - i.e. it won't be 'CD' but something similar.

So at runtime in the app, the user can now choose the code, normally done by navigating through the human readable code texts; this will result in instantiating an object of the type prescribed by the archetype at that point in the form (let's assume a screen form). So I would expect some sort of operation like:

CD myCD = new CD.fromTerminologyConcept (aTerminologyConcept)

I don't remember the inheritance relationships between CD, CV etc, but if there are some, then somehow the application has to decide which descendant type it needs to create.

Not sure if I answering the original question, but I'd like to know if we agree on the execution model or not. A a basic point, I would not expect to be able to go from a terminology subset associated with an ac-code and know specifically how to instantiate it in the archetype; normally you would expect to have to look at the archetype structure (and even then, if a supertype was stated, maybe you still don't know).

Or else I may not be understanding the problem correctly!

Reporter

Diego Bosca

Labels

None

Components

Priority

Major
Configure