Stream: ihe
Topic: capabilityStatements
Jose Costa Teixeira (Nov 10 2017 at 15:58):
Should our capabilityStatements be
a) one for each profile
b) one for each actor
c) one for each transaction
?
Jose Costa Teixeira (Nov 10 2017 at 15:58):
i am leaning to b) one for each actor
Grahame Grieve (Nov 10 2017 at 21:26):
should not be per transaction unless there is one server per transaction
Michael van der Zel (Nov 10 2017 at 21:33):
+1 for b)
Elliot Silver (Nov 10 2017 at 22:06):
Although I lean towards b), we do have actors and transactions with optional behavior. There may be a need for multiple statements per actor or a statement per actor/transaction. My preference is probably a base capability statement for each actor, and additional capability statements that can be layered on top for the options.
Jose Costa Teixeira (Nov 11 2017 at 08:38):
So, one for each actor and one per each option for that actor?
Elliot Silver (Nov 12 2017 at 05:41):
I'd start with that approach and see how far that gets you.
John Moehrke (Nov 12 2017 at 16:34):
Yes, at least a CapabilityStatement for each Actor.. but you might also need one for each interaction, and options might also affect it. Hence why CapabilityStatement does not equate to Actor.
Grahame Grieve (Nov 12 2017 at 20:06):
I don't see why you need one for each interaction
Michael van der Zel (Nov 12 2017 at 20:25):
If the Actor is a client I don't see the need for a CapabilityStatement. It is mainly something for a server, right?
Jose Costa Teixeira (Nov 13 2017 at 07:18):
I think the client should also declare its conformance.
Jose Costa Teixeira (Nov 13 2017 at 07:18):
so, what I am thinking so far:
Jose Costa Teixeira (Nov 13 2017 at 07:18):
1 CapabilityStatement per profile per actor per option.
Jose Costa Teixeira (Nov 13 2017 at 07:19):
1 ExampleScenario per profile per transaction
Jose Costa Teixeira (Nov 13 2017 at 07:20):
and one of these - not sure yet:
1 CapabilityStatement per profile per transaction
1 CapabilityStatement per profile per actor per transaction
1 StructureDefinition per profile per actor per transaction
Jose Costa Teixeira (Nov 13 2017 at 07:21):
bonus - and one GlossaryEntry per definition in the document - if GlossaryEntry ever exists :)
René Spronk (Nov 13 2017 at 08:19):
It all depends on the number of endpoints one will require. One per actor would probably be the most akin to the IHE way of doing things. The CapabilityStatement includes all of the transactions, as well as any options those actors may support. If a software application supports 2 actors one could use 1 single endpoint, but given that the actor could be played by a different application at some future point in time I'd personally still use 2 endpoints.
Jose Costa Teixeira (Nov 13 2017 at 09:16):
How does CapabilityStatement support options?
Jose Costa Teixeira (Nov 13 2017 at 09:16):
or how would it?
Jose Costa Teixeira (Nov 13 2017 at 09:17):
can we have a capabilityStatement refer to other capabilityStatements?
Jose Costa Teixeira (Nov 13 2017 at 09:18):
(and would that be a good idea?)
Michael van der Zel (Nov 13 2017 at 09:29):
About the client CapabilityStatement.. How would a client serve this? I think there is as yet no example were the client also has a server. Or do you imagine a handshake were the client sends his CapabilityStatements to a server?
Jose Costa Teixeira (Nov 13 2017 at 09:41):
I'm not sure for REST. I am thinking of a capabilityStatement about an actor, which does not mean it has to be inside the actor
Jose Costa Teixeira (Nov 13 2017 at 09:45):
but for "automated assessment", I like the idea of sending capabilityStatement to server.
Jose Costa Teixeira (Nov 13 2017 at 09:47):
actually it takes me back to ieee and usb which do something like that - when you are plugged in, the first thing you do is say what you can do.
René Spronk (Nov 13 2017 at 10:38):
A CapabilityStatement describes what a server supports. So if its supports an IHE-actor-option the CapabilityStatement should include that functionality. If it doesn't support it, then it doesn't describe the corresponding functionality.
Jose Costa Teixeira (Nov 13 2017 at 10:55):
the CapabilityStatement can represent a capability or a transaction, right? that is how i read the description (if i am not mistaken)
Jose Costa Teixeira (Nov 13 2017 at 10:57):
hence my question - if capabilityStatements can be nested/linked, the answer would be simple
John Moehrke (Nov 13 2017 at 14:24):
Jose, I don;t think there is a hard-and-fast rule on linkage between number of Actors to number of CapabilityStatements. Some options that we create in IHE have nothing to do with the things that would be expressed in a CapabilityStatement. I think the nesting of CapabilityStatements is interesting, but is optimizing the job of the author, and not necessarily optimizing the implementors job. Ultimately we really want a operational server to publish ONE CapabilityStatement... having realtime systems need to navigate through nested CapabilityStatements is not friendly.
Jose Costa Teixeira (Nov 13 2017 at 14:25):
I am thinking on automated capability recognition, inheritance of conformanceStatements.
Jose Costa Teixeira (Nov 13 2017 at 14:26):
I agree, we would want one capabilityStatement per server.
So if the server is supporting many IHE profiles, and many options, the granularity we have to define is at that level, no?
Jose Costa Teixeira (Nov 13 2017 at 14:27):
I think this is the same as @Simone Heckmann 's comment in conformance about validating against multiple profiles
John Moehrke (Nov 13 2017 at 14:27):
Yes we need to create the right level of documentation to enable success. Sometimes that is few, sometimes that is many... That is why I say there is no hard-and-fast rule.
Jose Costa Teixeira (Nov 13 2017 at 14:30):
@Michael van der Zel how would you see it for non-REST ? messaging, documents...
Jose Costa Teixeira (Nov 13 2017 at 14:43):
@John Moehrke I agree there is no hard rule, just looking at a framework - what is the level of granularity. I do not think the capabilityStatements should be per actor or per profile (unless they support nesting). If IHE wants to publish reusable capabilityStatements, then we must have those per actor (and perhaps per option), right?
John Moehrke (Nov 13 2017 at 14:49):
the capailityStatements that IHE publishes are a "Desired Solution" http://build.fhir.org/capabilitystatement.html#5.2.1.3 . So it is expected that they are fragments of what one would develop into a "Software Solution", or deploy in an "Actual Implementation".
Jose Costa Teixeira (Nov 13 2017 at 14:50):
I was seeing it differently, actually. We should be describing software capabilities.
Jose Costa Teixeira (Nov 13 2017 at 14:50):
but i may have it wrong
Jose Costa Teixeira (Nov 13 2017 at 14:51):
but i think i have it right.
Jose Costa Teixeira (Nov 13 2017 at 14:52):
2 questions i am asking yself: how does IHE say "this profile requires this and that AND requires compliance with profile X"
John Moehrke (Nov 13 2017 at 14:52):
nope. IHE is defining Actors, not Software.
Jose Costa Teixeira (Nov 13 2017 at 14:53):
and how does a vendor / Buyer say "this software complies with IHE Pharm XXX, and IHE ITI YYY"
Jose Costa Teixeira (Nov 13 2017 at 14:55):
i can imagine this being done with bundling or nesting.
Jose Costa Teixeira (Nov 13 2017 at 14:56):
ok i read the definitions differently. I will request clarification or examples in the page.
John Moehrke (Nov 13 2017 at 14:56):
so IHE has an IntegrationStatement that is used for that purpose, but I suspect you are asking at the technical level.. And for that, yes the curret CapabilityStatement is missing the ability to declare conformance to CapabilityStatements, like it has for declaring StructureDefinitions.
Jose Costa Teixeira (Nov 13 2017 at 14:56):
"It can also be used as the basis for conformance testing of software solutions independent of a particular installation." - I think this is what we want
Jose Costa Teixeira (Nov 13 2017 at 14:58):
So we go back to nesting.
And if nesting is there, then the problem to me is resolved thus: our capabilityStatements are at the level of Actor(-Option), and the vendors can declare conformity to any grouping of these.
Jose Costa Teixeira (Nov 13 2017 at 14:59):
i hope the context is clear - in my question, the goal is "what we should have in a later future"?
Jose Costa Teixeira (Nov 13 2017 at 15:00):
i don't want to rock the boat on the short-term implementation. I am looking at what is our target use of IGs, Statements, etc.
John Moehrke (Nov 13 2017 at 15:01):
I would still want the ONE CapabilityStatement published by a server or client to be the flat capabilities supported. Yes, it would be good for those capabilities should be able to be declared at the 'standard CapabilityStatement identifier', but I would still want only ONE, and for all the combined REST capabilities to be declared as a flat list.
Jose Costa Teixeira (Nov 13 2017 at 15:02):
as an application developer, sure.
Jose Costa Teixeira (Nov 13 2017 at 15:02):
you just pick up the IHE conformance statements and instead of a tree, you make a flat list.
Jose Costa Teixeira (Nov 13 2017 at 15:03):
i think that is a good point - the conformance statement of a vendor should not have to bother with how IHE is structured
Jose Costa Teixeira (Nov 13 2017 at 15:04):
but ihe does not need to work on a flat list.
John Moehrke (Nov 13 2017 at 15:04):
the current model seems to focus more on the fact that a server as deployed would have some set of REST capabilites. Expecting that a client would look for the query parameters it wants to use. Rather than a client looking for an "Actor" declaration.... So it is focused on low level grandularity, rather than an abstract higher grandularity like IHE has in Actor.
Jose Costa Teixeira (Nov 13 2017 at 15:07):
so, as stated before, i am going on with "one statemetn per actor per option". The "per option" bit is optional - in some cases it is not needed.
Jose Costa Teixeira (Nov 13 2017 at 15:07):
as an output the user needs a flat list - sure, that can be done.
Jose Costa Teixeira (Nov 13 2017 at 15:07):
is there any reason why our conformance statement should not be written in the above granularity?
John Moehrke (Nov 13 2017 at 15:07):
yes, One per actor... possibly per option...
John Moehrke (Nov 13 2017 at 15:15):
I had already given the advice to publish one CapabilityStatement per Actor... so I did just add a statement about Options. http://wiki.ihe.net/index.php/Guidance_on_writing_Profiles_of_FHIR#CapabilityStatement-_content_recommendation
Jose Costa Teixeira (Nov 13 2017 at 15:25):
Perfect. Should we start a wiki page on the "future state" ?
Michael van der Zel (Nov 13 2017 at 20:05):
the capailityStatements that IHE publishes are a "Desired Solution" http://build.fhir.org/capabilitystatement.html#5.2.1.3 . So it is expected that they are fragments of what one would develop into a "Software Solution", or deploy in an "Actual Implementation".
I don't think it are fragments. The IHE Implementable Artifacts contain THE CapabilityStatements of the associated IHE Profile!
Jose Costa Teixeira (Nov 13 2017 at 20:53):
an IHE profile is usually not meant for one single system - it typically declares at least two.
Jose Costa Teixeira (Nov 13 2017 at 20:54):
so, without nesting, do you mean we have one statement for one profile?
John Moehrke (Nov 13 2017 at 20:57):
I say a fragment, which I mean the same thing as "Desired Solution". I say this because it is very likely that even if I implemented a micro-service intending to implement exactly one IHE defined Actor, I would need to add more elements to the CapabilityStatement. The relationship to the IHE published CapabilityStatement is that what I publish must be at MINIMUM that which is found in the IHE CapabilityStatement.
Elliot Silver (Nov 14 2017 at 05:40):
There are (at least) two uses for CapabilityStatement here. One is a statement of what an actual implementation can do. I think this should be a "flat" CS, no nesting.
The other use is for an IHE profile to specify minimum capabilities that an implementation must have. Generally, I think there should be one of these per actor, and with additional ones for each option the actor supports.
This should cover most of our situations. The exceptions would be when multiple systems implement a single actor, or one actor implements different transactions on different endpoints. To deal with this we would need per actor per transaction CapabilityStatements, and I doubt the extra complexity would be worth it in the general case.
Jose Costa Teixeira (Nov 14 2017 at 06:01):
i am moving on with that in mind
Jose Costa Teixeira (Nov 14 2017 at 06:02):
as for the flat/nesting, if we need some inheritance or bundling, i think the best is to come up with a scenario and check the Conformance folks
Michael van der Zel (Nov 14 2017 at 07:51):
Ok. So a server will return 1 CapabilityStatement as per http://hl7.org/fhir/http.html#capabilities. Mind that: "A Capability Statement documents a set of capabilities (behaviors) of a FHIR Server that may be used as a statement of actual server functionality or a statement of required or desired server implementation." This means that yes, the capabilitystatment of each IHE profile is a fragment of a servers complete capabilitystatement. I see it now.
Last updated: Apr 12 2022 at 19:14 UTC
