Stream: workflow
Topic: Participant / Actor formal definition?
Jose Costa Teixeira (Mar 20 2019 at 06:06):
Both PlanDefinition and ExampleScenario refer to a participant in an action. If we want to have a governed set of actors / participants, shouldn't we have a way to define them?
Practitioner is too limited.
Jose Costa Teixeira (Mar 20 2019 at 06:07):
I am thinking of IHE actors (e.g. a Prescription Placer). Not sure there are other examples where this would make sense.
Lloyd McKenzie (Mar 20 2019 at 13:59):
Prescription Place would generally be a CapabilityStatement. Not sure about having that pointed to by a PlanDefinition though...
Jose Costa Teixeira (Mar 20 2019 at 21:06):
A prescription placer has a definition, a set of transactions it can accept, a set of transactions it can initiate...
Jose Costa Teixeira (Mar 20 2019 at 21:07):
CapabilityStatement reads more "what the system is supposed to do", not "what the system is about".
Jose Costa Teixeira (Mar 20 2019 at 21:07):
I am trying to use PlanDefinition to express a workflow conformance.
Jose Costa Teixeira (Mar 20 2019 at 21:10):
for example, a workflow conformance that would say "Order Placer(A1) sends a prescription(R1) to Treatment Planner(A2). Then treatment planner "decodes" that and issues instance orders(R2) and sends it to nursing app(A3)"
Jose Costa Teixeira (Mar 20 2019 at 21:10):
A1 to A3 are actors
Jose Costa Teixeira (Mar 20 2019 at 21:11):
And there is a place to define them in the PlanDefinition and in ExampleScenario
Jose Costa Teixeira (Mar 20 2019 at 21:12):
when publishing a profile like in IHE, i would not want to define the actor in each scenario. I would like to point to a definition of an actor.
Jose Costa Teixeira (Mar 20 2019 at 21:18):
the need to put then in a planDefinition is because we want to constrain the content in a given context. In this case, R1 and R2 are both medicationRequests, but they have different fixed values for intent (R1.intent="order", R2.intent="instance-order"), and R2.basedOn must point to R1.
Lloyd McKenzie (Mar 21 2019 at 00:20):
I'm not totally clear on what the difference is between "what the system is supposed to do" and "what the system is about" from a specification perspective. When I'm writing an IG, I only care about the actors from a perspective of "what are they supposed to do". If they meet the capabilities requirements and they interact as required, I don't really care "what they're about". So "Order Placer", "Treatment Planner", etc. all get represented as CapabilityStatements in an IG. And those represent 'definitions'. They are statements of what a system should do, they don't correspond to specific system instances.
Jose Costa Teixeira (Mar 21 2019 at 04:09):
i can experiment with that. This means that for workflow conformance, I should be able to point from an PlanDefinition to a CapabilityStatement, right?
Lloyd McKenzie (Mar 21 2019 at 04:24):
Not right now you can't.
Lloyd McKenzie (Mar 21 2019 at 04:24):
You could experiment with a custom extension.
Jose Costa Teixeira (Mar 21 2019 at 04:34):
i will see if capabilityStatement could support all we need to define an IHE actor, and then see if an extension or change request for plandefinition would be adequate.
Jose Costa Teixeira (Mar 21 2019 at 04:36):
planDefinition needs some changes anyway if we want that resource to be the way to express workflow conformance
Jose Costa Teixeira (Mar 21 2019 at 04:38):
i am wondering whether the findings would be best discussed in the workflow calls or decision support calls.. Ideas?
Jose Costa Teixeira (Mar 21 2019 at 04:45):
(not sure if CapabilityStatement would be adequate for IHE actors, especially those that support non-FHIR transactions)
Lloyd McKenzie (Mar 21 2019 at 04:52):
We can start with workflow and if we have consensus we can then approach CDS
Jose Costa Teixeira (Mar 21 2019 at 05:44):
ok i'll prepare an example and bring this to a call. Likely April 1 or after
John Moehrke (Mar 21 2019 at 22:08):
@Jose Costa Teixeira an IHE actor within a specified Profile is minimally defined by one CapabilityStatement, but sometimes is multiple. It could be multiple when that IHE actor has IHE defined Options. Not all options will need a new CapabilityStatement.
There is an unusual situation where one IHE actor must be represented as many CapabilityStatements, when that actor is engaging in multiple Transactions and multiple Messages within a Transaction. The answer is very much dependent on how detailed you want your CapabilityStatement to be.
Lastly recall that the above statements is about an "IHE actor within a specified Profile". the abstraction of an IHE actor can apper in many profiles, and each new profile that it appears in may add different behaviours that cause new CapabilityStatements to be needed.
I have outlined this all on the IHE wiki page for when IHE is profiling FHIR, a specification you are aware of. The above assessment holds true regardless of if IHE publishes profiles the old way, or using the HL7 IG publisher.
Jose Costa Teixeira (Mar 22 2019 at 08:09):
i am starting from the requirements, my requirement is "a governed list of actors"
Jose Costa Teixeira (Mar 22 2019 at 08:13):
If we need to define an actor, with a name, with 1..N (?) CapabilityStatements, i want to see which resource to use for that.
The proposals in the wiki are about how to do things in one given set of constraints. I want to look at (governance) requirements beforehand.
Last updated: Apr 12 2022 at 19:14 UTC
