Improve terminology support

,

It is now a bit hard for me to ‘mediate’ this issue at this point. I think you should agree on what is the best solution for the problem.

In my opinion, this is for AQL Release 1.1.0, as it is an addition to previous AQL specs. If you could agree on current support (as now is described), we could have further debate and experiments in real world/tooling, and perhaps than come back on a later release with a recommendation (whether or not to use service_api as an URI or only as an URL). Is that an acceptable a way forward?

Otherwise I’m looking forward for concrete suggestions on how this spec part should be changed in order to accommodate all parties.

Yeah, they are URIs (UR Identifiers) that look just like URLs (UR Locators). But I don’t think we invented them, right, they’re kind of standard?

I must admit I needed to point out this distinction to one of our developers (and not a junior one at that) that was prototyping implementation of this new terminology function. And it’s not that he didn’t know about the difference, but seeing something that looks like URL really takes some mental gymnastics to “unthink” it being a “locator”.

Nevertheless, I’m voting to keep things as they are.

“ that is not an endpoint, it is just an identifier of the FHIR API we are using”

I know it is not an endpoint and you know it is not an endpoint but it is really confusing for people coming to it new. In this case it is not even a proxy for a real endpoint - it is just a name of a type of TS ‘driver’ . I know it is not 'wrong' to use a uri in that way but it does make the string really confusing for newbies, especially when it is in the content of a terminlogy://string not a function , as we need t ouse at least for now. If we use something like

terminology://r4.hl7.fhir.org/Valueset, it is very much easier to parse out the driver name from the driver-specific syntax, which starts at the /

I’m not much bothered about terminology: for the future but we have to live with it for a bit as it exists within existing systems and templates.

The consensus between myself, Sebastian and Fabio for the design-time terminlogy syntax is below- other input welcome, of course.

in .oet - vendor-specific syntax
<termQueryId terminologyID="SnomedCT " queryName="AllBloodTypes" />

means this is vendor-specifc TS syntax- all bets are off, including the meaning of terminologyId

and for .opt

terminologyId:SnomedCt?subset="AllBloodTypes"

whereas new standard terminolgy:// syntax
<termQueryId terminologyID="//r4.fhir.hl7.org" queryName="$expand?url=http://hl7.org/fhir/vs/snomed-example-v" />

<referenceSetUri>terminology://r4.fhir.hl7.org/ValueSet/$expand?url=http://hl7.org/fhir/vs/snomed-example-vs</referenceSetUri>

None of use are very keen on the r4 but ultimately that is really a question back to Grahame for advice.

This arrangement keeps us very close to the Terminology() function but is backwardly compatible with any existing terminology: constraints in existing archetypes and templates.

We are pretty sure that the operation will always be 'subsumes', so no need to carry that in the string.

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

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