Improve terminology support

Description

There is a need is to improve terminology support matching codes against external terminology services. The services often require an (remote) operation to be performed and provide the results back to the matches operator to be used by AQL engine.

The final design for this proposal is documented here: . The main change is to add a new TEMINOLOGY function to AQL specifications.

 

 


original input below:

See https://openehr.atlassian.net/wiki/spaces/spec/pages/287309832/AQL+Evolution+Notes

Ian: We have made a start on some low-level openEHRText/Coded_text <> FHIR equivalents - see https://github.com/inidus/openehr-care-connect-adaptor/blob/master/docs/mapping_guidance/openEHR-AdverseReactionRisk-to-FHIR-AllergyIntolerance-STU3-mappings.adoc

Bjorn: Expand in AQL - like suggested here?
https://openehrspecs.slack.com/archives/C2CD84RUL/p1504168030000398?thread_ts=1474025119.000021&cid=C2CD84RUL

Bjørn Næss
Suggestion from last year::isA(<code>)
isChildOf(<code>)
isInSet(<codeset>)
isSameAs(<code>)

Use cases:

  • return all Xs containing any kind of cancer

  • is /x/y/z/value a kind of cancer

  • etc

 

Some design discussions here:

Activity

Show:
Sebastian Iancu
4 days ago
Edited

in the example-doc there is this:

see https://specifications.openehr.org/releases/QUERY/latest/AQL_examples.html#_terminology

However those might not be correct - I just invented them in absence of real example how this would work. We need implementers looking into them and with their feedback we should correct these examples.

Diego Bosca
4 days ago

Yes, that’s what I had in mind, somehow I missed it the first time I looked at them

Ian McNicoll
4 days ago

can you comment?

I think the vast majority of AQL uses would be ‘expand’ or possibly ‘subsume’ but I think there was an attempt to define the CDR -Terminology service interface a little more widely

The only part I don't like in the example is the 'service name as full uri

TERMINOLOGY('subsumes', 'http://hl7.org/fhir/r4',

I would far prefer a namespace typ of lable to make it very clear that this is not intended as an actual endpoint.

TERMINOLOGY('subsumes', 'hl7.org.fhir.r4',

it also gets very messy if we apply the same pattern to the ADL space we need this to work with a terminology::// uri

terminology://hl7.org.fhir.r4/Valueset/

I’d also prefer to leave the original service syntax intact - if only because outsiders are going to be familiar with e.g. the FHIR Valueset syntax.

We don't have to absolutely align the way we do terminlogy:// and TERMINOLOGY() but it would help to minmise the differences where we can

The other issue (possibly the final one!!) is whether we really need the Version suffix on FHIR services
or is
TERMINOLOGY('subsumes', 'hl7.org.fhir',

suffficient?

Do we need some feedback from the FHIR TS community on stability of the FHIR resources?

TERMINOLOGY('expand', 'http://hl7.org/fhir/4.0', 'http://snomed.info/sct?fhir_vs=isa/50697003')






Diego Bosca
4 days ago

About resource stability, ValueSet is normative, and ConceptMap is level 3, which is not the best but it’s good enough

Luis Marco-Ruiz
2 days ago

Hi , here are my answers to your comments

 

*“I would far prefer a namespace type of lable to make it very clear that this is not intended as an actual endpoint.” -> that is not an endpoint, it is just an identifier of the FHIR API we are using. IMO there is no danger in using a URI to identify something in the Internet. It is actually a good practice. That specific one was actually recommended by Graham grieve to identify the FHIR TS version.

*“it also gets very messy if we apply the same pattern to the ADL space we need this to work with a terminology::// uri” -> I think the reason here is that, as Heath pointed somewhere, “terminology:” is not actually a URI scheme. I would allow its use for legacy reasons but I do not think we should keep our syntax (in the future) based on it. In my humble opinion, backward compatibility using terminology: is very good, but taking it as a fixed requirement and depending on it for future implementations is not.

*“We don't have to absolutely align the way we do terminlogy:// and TERMINOLOGY() but it would help to minmise the differences where we can:” -> totally agree, we should support both but recommend TERMINOLOGY() for future implementations.

*“I’d also prefer to leave the original service syntax intact - if only because outsiders are going to be familiar with e.g. the FHIR Valueset syntax.” -> the syntax is as similar to FHIR as it can be without totally depending on it. For example, if we fully commit to FHIR (as it was one of my previous proposal) then the backend processing the TERMINOLOGY function may not be able to adapt to other type of terminology service API because.

 I do not know if I answer all your comments, if not just ping me and I will be happy to clarify

Reporter

Thomas Beale

Raised By

Thomas Beale

Components

Affects versions