I think this idea is probably right, in some form. You can see the
current formal definitions for the terminology structures here (ADL2
<http://www.openehr.org/releases/AM/latest/docs/ADL2/ADL2.html#_term_bindings_sub_section>,
AOM2
<http://www.openehr.org/releases/AM/latest/docs/AOM2/AOM2.html#_terminology_package>).
Terminology bindings are currently assumed to be a Hash <String,
Hash<String, URI>>, where the outer key is terminology namespace id
(e.g. 'snomed-ct', 'icd10' etc) and the inner is an archetype code or path.
So the bindings are currently of the form:
|term_bindings = < ["snomed_ct"] = <
["/data[id3]/events[id4]/data[id2]/items[id26]"] =
<http://snomedct.info/id/169895004> -- Apgar score at 1 minute ["id26"]
= <http://snomedct.info/id/249228009> -- Total Apgar score (observable
entity) > ["loinc"] = < ["/data[id3]/events[id4]"] =
<http://loinc.org/id/48334-7> -- 1-minute Apgar panel
["/data[id3]/events[id4]/data[id2]/items[id6]"] =
<http://loinc.org/id/32407-9> -- 1 minute Apgar Heart rate ["at7"] =
<http://loinc.org/id/LA6716-0> -- No heart rate ... > ["umls"] = <
["id1"] = <http://umls.nlm.edu/id/C124305> -- apgar result ["id6"] =
<http://umls.nlm.edu/id/C234305> -- cardiac score > >|
but maybe we want something like this:
|term_bindings = < ["snomed_ct"] = <
["/data[id3]/events[id4]/data[id2]/items[id26]"] = (SIMPLE_BINDING) <
target = <http://snomedct.info/id/169895004> -- Apgar score at 1 minute
notes = <"some notes"> min_version = <"2017-02-01"> etc = <"etc"> >
["id26"]|||= (CONSTRAINT_BINDING) <| |||target |= <||" 71388002|Procedure|: 405815000|Procedure device| = 122456005|Laser
device|, 260686004|Method| =
129304002|Excision - action|,
405813007|Procedure site - direct| = 1549700l6|Ovarian structure|"> -- xyz||||||||min_version = <"2017-04-01">| notes = <"some notes"> etc = <"etc"> |> > >|
you get the idea - I just hacked this together to show possible syntax
and structure. The semantics make no sense. In the second binding, you
see that target is a String that can be interpreted as a SNOMED
expression, due to the fact that it is inside a structure of type
CONSTRAINT_BINDING (this doesn't exist today - we would need to add it
to the AOM).
I don't claim to know what the proper design of these types are -
presumably, things like min_version, notes, etc can make sense.
this is just my first thought, but I think it is clear that the right
hand side of a binding can be a few diferent things:
* a single concept code
* a single code referring to an external value set known in SNOMED
* a composition expression that refers to a more refined concept
* a constraint expression that locally determines a value set
intensionally, to be resolved by application to the Terminology service.
So we would need AOM types to accommodate all of that, and other
meta-data we think we need as well.
- thomas
On 04/05/2017 03:06, Bert Verhees wrote:
Regarding the readability of the URI's containing SNOMED expressions,
one can always consider adding a comment line containing the long
(textual) expression format without URI encodings.
Maybe it is also possible to formalize that comment/description in a
special ODIN tag. Also other terminology-codings do not explain
themselves very well and an explanation/description can be very useful
for the reader of plain text ADL
I think that SNOMED constraints and post coordinated expressions will
soon become unavoidable in an EHR application, and that it is urgent
to find a solution for this.
Best regards
Bert Verhees
Op 3 mei 2017 16:45 schreef "Diego Boscá" <[email protected]
<mailto:[email protected]>>:
well, nothing stops you for not encoding the query in definition
time, most services are ok with that
e.g.
http://diebosto2.pc.upv.es:8888/SnomedQuery/ws/JSONQuery?query=
<http://diebosto2.pc.upv.es:8888/SnomedQuery/ws/JSONQuery?query=><404684003:363698007=39057004
2017-05-03 16:31 GMT+02:00 Thomas Beale <[email protected]
<mailto:[email protected]>>:
On 03/05/2017 13:31, Diego Boscá wrote:
Or just use the "Long syntax" as described in point 5.2
from Expression Constraint Language, which keeps things
readable enough
http://snomed.info/ecl/descendantOrSelfOf
<http://snomed.info/ecl/descendantOrSelfOf> 73211009
|Diabetes mellitus|
at the very least, a %20 is needed for the spaces, and %7C for
the pipes, i.e.
http://snomed.info/ecl/descendantOrSelfOf%2073211009%20%7CDiabetes%20mellitus%7C
<http://snomed.info/ecl/descendantOrSelfOf%2073211009%20%7CDiabetes%20mellitus%7C>
i.e. ... not readable...
- thomas
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
--
Thomas Beale
Principal, Ars Semantica <http://www.arssemantica.com>
Consultant, ABD Team, Intermountain Healthcare
<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR Foundation
<http://www.openehr.org>
Chartered IT Professional Fellow, BCS, British Computer Society
<http://www.bcs.org/category/6044>
Health IT blog <http://wolandscat.net/> | Culture blog
<http://wolandsothercat.net/>
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
