2:3.78.4.2.4 - CapabilityStatement rqmts in ITI-78

[lynnfel]

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:

1. Now that we have an IG, we can point to Appx Z.4, but also add a pointer to https://profiles.ihe.net/ITI/PDQm/artifacts.html#behavior-capability-statements
2. It's not just Suppliers who Shall provide a Capability Stmt. We should require this of Consumers, too (to document which query parameters their client has implemented.
3. Where should this requirement to have a capability statement exist? PDQm has only one transaction, but what about profiles like PIXm that have two. Do we put the rqmt to have a CapabilityStmt in each transaction? In the actor rqmts in Vol 2? Other suggestions?

Priority:

• Medium: Significant issue or clarification. Requires discussion, but should not lead to long debate.

[JohnMoehrke]

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?

[lynnfel]

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).

[slagesse-epic]

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.

[lynnfel]

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

[JohnMoehrke]

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

• is this clear to our reader?

I think that what we say in PDQm [ITI-78] conveys the server responsibility.

• does it need to say the client has no responsibility?

I think that our Appendix Z seems clear? How could it be improved?

• https://profiles.ihe.net/ITI/TF/Volume2/ch-Z.html#z.3-capabilitystatement-resource

[JohnMoehrke]

1. Define in the Actor definition section, for Server based actors, remind them of the Appendix Z requirement for CapabiltyStatement metadata publication.
2. query parameters would be indicated. Those defined in PDQm must be declared, additional parameters supported should be declared.