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:
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?
Suggestion from last year::isA(<code>)
return all Xs containing any kind of cancer
is /x/y/z/value a kind of cancer
Some design discussions here:
in the example-doc there is this:
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.
Yes, that’s what I had in mind, somehow I missed it the first time I looked at them
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
I would far prefer a namespace typ of lable to make it very clear that this is not intended as an actual endpoint.
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’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
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')
About resource stability, ValueSet is normative, and ConceptMap is level 3, which is not the best but it’s good enough
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