Closed lynnfel closed 3 years ago
I was expecting the publication of CapabilityStatement was an Actor requirement that would be found in Volume 1. I expected this was inherited by the reference to Z.4 It is much harder to require clients to publish one. publish it where? Even if we just said, 'make it available', make it available where/how/when? Thus I am not sure we can identify any normative requirements on clients. We can certainly encourage it informatively?
As you know, DICOM products publish Conformance Statements all of the time, often as part of product documentation, even if it's not machine processable..
If it has to be electronically accessible to be valuable for FHIR, then we leave clients off the hook? I won't fight it if that's what the community says.
(We ask for them at Connectathon, and clients produce them).
I spoke with a few others at Epic and the general consensus was that FHIR capability statements for clients are really only useful when paired with a test suite that can consume that capability statement and use it to enhance and/or automate a testing process.
Client capability statements will generally not be useful operationally because the server will usually have no way to discover the client's capability statement, and even if it did ideally the server wouldn't care.
From a documentation perspective, FHIR capability statements are designed to be machine readable. If the audience is a human, it is likely that a FHIR capability statement is not the most efficient way to communicate conformance information vs a less formal method.
So, absent a testing tool that uses capability statements, asking clients to produce them is likely not a super valuable use of time. But if we wanted to leave the door open to have such a tool at Connectathon, it might still be a good idea to leave the requirement in the spec.
We should make it a requirement if we think it helps with interoperability, or if we think customers would want an IHE-compliant product to have one.
I put more weight on Spencer's input than on mine because he is speaking from a product perspective. I would like another vendor or two to provide their input.
Even if, someday, we have tooling that makes use of a client CapabilityStatement to drive a test suite, it still doesn't mean that IHE has to make producing one a profile requirement
There was no strong reactions on the call. Generally it is clear there is not much for clients to do, and clear what the servers metadata endpoint responsibility is.
Note that there is a different reason for a CapabilityStatement to be in an Implementation Guide, from a CapabilityStatement published by a product. Those in the IG are "Requirements", where as a product would publish "Instance" or "Capability" kind. See FHIR http://hl7.org/fhir/capabilitystatement.html#scope
I think that what we say in PDQm [ITI-78] conveys the server responsibility.
I think that our Appendix Z seems clear? How could it be improved?
Section Number 2:3.78.4.2.4 - https://profiles.ihe.net/ITI/PDQm/ITI-78.html#2378424-capabilitystatement-resource
Issue consider changing the way we
Proposed Change we have this: 2:3.78.4.2.4 CapabilityStatement Resource Patient Demographics Suppliers implementing [ITI-78] shall provide a CapabilityStatement Resource as described in ITI TF-2:Appendix Z.4 indicating the query interaction for the Patient Resource has been implemented and shall include all query parameters implemented for the Patient Resource.
Issues/questions:
Priority: