Stream: terminology
Topic: Accessing the server terminology capability statement
Rob Hausam (Feb 16 2018 at 00:10):
We have GF#14539 on the agenda for a vote on the next Vocab Main call next Thursday (2/22). We agreed on the last call (2/8) on the principle that CodeSystem documents the capabilities of the code system itself and that the declaration of the server implementation and capabilities for a code system in regard to the terminology service operations will be documented and accessed in a designated instance of the TerminologyCapabilities resource (see CodeSystem definition in GF#14726). The situation with TerminologyCapabilities is analogous to the general server capability statement that is documented in a CapabilityStatement resource and accessed through the /metadata endpoint. But for TerminologyCapabilities we haven't yet defined what the endpoint should be, and we need to decide that so we can move forward with it. Here are some possibilities that I've heard or considered:
-
We could define a new endpoint specifically for this (name to be determined)
If we take this approach and end up defining multiple types of services we will also end up with a multiplicity of capabilities endpoints. -
Link to the more detailed terminology capabilities from somewhere in the required general server capability statement
With this approach we would be able to access all capabilities from the single /metadata endpoint, but there would be a level of indirection to get to the detailed service-specific capabilities. Flavors of this might include:- Create a new element that provides a reference to the designated TerminologyCapabilities resource.
- Attempt to use the existing CapabilityStatement.instantiates element (uri data type) to reference the designated TerminologyCapabilities resource.
But Grahame has indicated that this kind of use is not the intent for 'instantiates'.
Let's have some discussion on this and see if we can come to a conclusion by next week.
Grahame Grieve (Feb 16 2018 at 00:26):
I certainly expected this "Create a new element that provides a reference to the designated TerminologyCapabilities resource.". I think that we should stick to having a single entry point (/metadata) to the capabilities of the server
Rob Hausam (Feb 16 2018 at 00:38):
That sounds good to me.
Rob Hausam (Feb 16 2018 at 00:41):
I got the list indenting fixed. Sorry if that was a little confusing before.
Michael Lawley (Feb 17 2018 at 09:11):
I am quite wary of the second option that would always require two round-trips to get at terminology server capabilities.
I have several clients that rely on querying the general /metadata endpoint and for some servers this is very slow.
If there are lots more service types, I expect they'll all get their own [Service]Capabilities resource type, so I don't think it would be too much of a burden to settle on a pattern like /[Service]Capabilities/metadata.
Rob Hausam (Feb 17 2018 at 14:07):
I can see the value in that approach, and it seems reasonable. I like the fact that it retains the 'metadata' endpoint, but applies it in a more specialized context.
Lloyd McKenzie (Feb 17 2018 at 15:19):
The TerminologyCapabilities hasn't been approved as a resource yet. And I can't imagine it getting approval until we figure out a solution that won't mean the creation of a separate resource for every type of service we might come up with.
Grahame Grieve (Feb 17 2018 at 20:10):
well, we could define some kind of generic name value pair thing. or we could use basic. Or you could start being serious
Michael Lawley (Feb 18 2018 at 02:27):
Is there a list of other hypothetical services? I wasn't expecting that there would be a long list.
Lloyd McKenzie (Feb 18 2018 at 04:08):
I'm quite serious when I say I'd prefer a name-value pair thing to a separate resource per service. We're talking 20+ services. Maybe considerably more. Having a resource for each is not sustainable.
Grahame Grieve (Feb 18 2018 at 04:08):
we've talked about
- terminology service
- conformance service
- testing service
- booking service
- many many variants of decision support services
- patient identification service
- personal health record services
- EHR services
Grahame Grieve (Feb 18 2018 at 04:09):
only the first has got into anything written, and the second has some draft ideas
Grahame Grieve (Feb 18 2018 at 04:09):
why is it not sustainable? It's too hard to come to agreement? or there's some other problem that not having a resource will actually solve?
Lloyd McKenzie (Feb 18 2018 at 04:11):
The problem is every single service gets its own resource. That allows no consistency of implementation approach. It also means we end up with a whole bunch of resources that are essentially doing the same thing. The number of resources we have is already getting borderline too high. Doing something like this (and setting the precedent of something like this) is going to lead to unsustainable numbers.
Lloyd McKenzie (Feb 18 2018 at 04:12):
Whether the others have something written doesn't really matter. We know they'll exist at some point.
Grahame Grieve (Feb 18 2018 at 04:14):
there's some magic number of resources beyond which a problem gets harder to solve? As for consistency... there's multiple ways to ensure that. but each service has a different set of problems. Abstracting that into a tree of name value pairs just moves the problem around. As for all doing the same thing.... if they are doing the same thing, they should be the same. But if you look at terminology capabilities as it is now, it's quite terminology engine specific
Last updated: Apr 12 2022 at 19:14 UTC
