Stream: implementers
Topic: CapabilityStatement and profiles
Richard Kavanagh (Nov 14 2017 at 08:49):
When creating a capability statement what goes in CapabilityStatement.profile ?
Is it just the StructureDefinitions for the resources? or does it include the extensions and any data type profiles as well?
Grahame Grieve (Nov 14 2017 at 10:08):
preferably as much as you can say for each kind of use case.
Grahame Grieve (Nov 14 2017 at 10:08):
CapabilityStatement may be retired in favor of ExampleScenario (? I am watching that develop)
Michael van der Zel (Nov 14 2017 at 10:29):
Can I check out ExampleScenario somewhere? I could not find it on build.fhir.org
Jose Costa Teixeira (Nov 14 2017 at 10:30):
it is there
http://build.fhir.org/examplescenario
Jose Costa Teixeira (Nov 14 2017 at 10:32):
i have a few questions there but I could not put them in Forge because i could not find exampleScenario in the resource list. :)
Lloyd McKenzie (Nov 14 2017 at 15:12):
I see those as very different resources Grahame. One is defining what you can do, the other is giving an example of how a particular flow could work
Grahame Grieve (Nov 14 2017 at 15:26):
not CapabilityStatement.rest.resource.profile - I think that's what you're referring to. CapabilityStatement.profile is something different. And it's not quite the same as ExampleScenario, but maybe that's what it should be
Eric Haas (Nov 14 2017 at 15:46):
Differentiating those two has been a challenge for many of us. ON FHIR-I we chatted briefly about an outstanding Gforge tracker that has morphed into a proposal to move CS.profile under .rest since it doesn't seem to apply to messaging ( but that may be a red herring here). GG can you clarify why an example would replace an profile - I don't follow that at all?
Eric Haas (Nov 14 2017 at 15:49):
And examplescenario would benefit greatly if it had an introduction and scope and usage section ... Am assuming is an interaction diagram in fhir.
Grahame Grieve (Nov 14 2017 at 15:50):
what you list in CS.profile is saying 'this is one kind of profile that the system supports'. There's a few specific obligations shown here: http://hl7.org/fhir/profiling.html#profile-uses
Jose Costa Teixeira (Nov 14 2017 at 15:51):
exampleScenario can be shown as an interaction diagram (actually a sequenceDiagram)
Grahame Grieve (Nov 14 2017 at 15:52):
as for moving it to .rest... I think that would be wrong. The underlying capabilities apply irrespective of channel
Grahame Grieve (Nov 14 2017 at 15:52):
the key sentence is the start one: "These profiles describe the information handled/produced by the system on a per use case basis" - but it doesn't say anything about the use case. Seems to me that ExampleScenario is close to describing the use case. So I'm watching to see how that plays out
Eric Haas (Nov 14 2017 at 15:52):
My point was that it is not obvious what go where on first blush. Maybe changing the element names might help that a bit.
Eric Haas (Nov 14 2017 at 15:53):
My second point was that ExampleScenario need an Introduction and Scope and Usage Section....:-)
Grahame Grieve (Nov 14 2017 at 15:54):
well, it's certainly caused a lot of confusion. it seems clear to me, except for the missing information
Jose Costa Teixeira (Nov 14 2017 at 15:55):
in exampleScenario there is an xslt that allows a sequence diagram to be generated.
exampleScenario has description, pre- and post-conditions.
Jose Costa Teixeira (Nov 14 2017 at 16:02):
since exampleScenario already supports "instance" resources, i think it would be neat if it supported "conformance" resources. As in "
in step 1, this structureDefinition needs to be respected.
In step 2, the following constraints apply:
2a: if this happens, structure definition 2a
2b: if this other thing happens, structureDefintition 2b
Jose Costa Teixeira (Nov 14 2017 at 16:07):
This is overlapping with PlanDefinition, so i may be tunnelling to a solution
Lloyd McKenzie (Nov 14 2017 at 16:39):
ExampleScenario refers to example instances. I don't see how it could be useful for Conformance.
Grahame Grieve (Nov 14 2017 at 16:44):
hmm. I assumed that you'd be able to talk the scenario indendepently of providing instances
Lloyd McKenzie (Nov 14 2017 at 16:52):
The purpose was to provide a scenario instance example of exactly who did what when. It doesn't talk about who can do what.
Lloyd McKenzie (Nov 14 2017 at 16:52):
The expectation was the latter would be handled by PlanDefinition
Jose Costa Teixeira (Nov 14 2017 at 18:23):
The requirements i was thinking of - not even sure if they fit in this discussion, and regardless of which resource - are thus:
Jose Costa Teixeira (Nov 14 2017 at 18:33):
- If a single medication administration is requested, this is a medicationRequest (instance-order)
- if it is an infusion, there SHALL be a medicationRequest containing the overall infusion
- If the infusion is planned to have different phases, each phase MAY be represented by a medicationRequest, in which case it SHALL point to the request for the overall infusion.
- if the actual administration is a result of an administration (instance) request, then it SHALL be a medicationAdministration, BasedOn this request.
... - If it's an infusion, then there is an overall medicationAdministration
- If there are phases or changes, then they MAY be captured with additional medicationAdministrations. If so, they SHALL point to the overall medicationAdministration, and MAY be BasedOn on a medicationRequest.
Jose Costa Teixeira (Nov 14 2017 at 18:36):
in short, requirements of type
"If this is the scenario, these are the constraints" - (use this resource type / apply these constraints on the resources)
"If this happens, what happens next has these constraints" (the resources on step have to link to the previous step)
Michael van der Zel (Nov 14 2017 at 18:58):
I feel ExampleScenario is more functional and CapabilityStatement more technical. [base]/metadata will respond with a ONE CapabilityStatement, so that a client "knows" what the server can do. How will ExampleScenario fit in there?
Grahame Grieve (Nov 15 2017 at 04:37):
I think of plan definition as a sequence of user actions, not an API use case thing
Lloyd McKenzie (Nov 15 2017 at 09:19):
It allows you to define order of events, pre-conditions, triggers, timing relationships, etc. All potentially relevant when defining technical workflows.
Jose Costa Teixeira (Nov 15 2017 at 10:40):
@Michael van der Zel on your question on how an exampleScenario/PlanDefinition fits when getting ONE capabilityStatement, I have been thinking that CapabilityStatements could/should nest other stuff.
So i can get from a system "here is my capabilityStatement. I support these general constraints on resource content, and also I also support the following workflow conformance aspects which themselves entail additional constraints."
Jose Costa Teixeira (Nov 15 2017 at 10:45):
so 2 general requirements, 1= supporting content and workflow conformance, 2= nesting (conformance inheriting or containing more conformance).
Jose Costa Teixeira (Nov 15 2017 at 10:46):
i can try to make a strawman for the workflow conformance bit using PlanDefinition and ExampleScenario, so that i am not anchored to any specific implementation option
Simon Knee (Jan 09 2018 at 16:20):
Agree with @Eric Haas we have had difficulty differentiating between CapabilityStatement.profile and CapabilityStatement.rest.resource.profile elements. We may have to support amalgamated capability statements so will be watching developments here. Are there any good examples that demonstrate multiple system use cases?
Last updated: Apr 12 2022 at 19:14 UTC
