Choreographies and Clinical Guidelines
A choreography is a contract that specifies the interactions between different participants in a medical procedure involving more than a single clinician or service provider. A choreography is shared among all the participants.
A guideline is a specific piece of clinical knowledge, and is local to a participant.
Choreographies are written in LCC: the coordination between different participants is obtained through message exchange and the behaviour of a participant is defined by constraints. The following box shows a simple choreography for coordinating the activity for the diagnosis of a sudden loss of weight in a patient. The participants are the diagnoser, the oncologist and the pharmacist. The diagnoser makes the diagnosis and forwards the result to an participant in the role of the oncologist if the diagnosis is cancer, otherwise to a participant in therole of pharmacist if the diagnosis is ulcer.
r(diagnoser, necessary, 1)
r(oncologist, necessary, 1)
r(pharmacist, necessary, 1)
a(diagnoser, D)::
null <- makeDiagnosis(PatientID, Age, Biopsy, Diagnosis)
then
(
(
null <- isDecision(Diagnosis, "cancer")
then
referral(PatientID, Age, Biopsy) => a(oncologist, O)
)
or
(
null <- isDecision(Decision, "peptic ulcer")
then
referral(PatientID) => a(pharmacist, F)
)
or
(
null <- exception("Unknown decision")
)
)
a(oncologist, O) ::
referral(PatientID, Age, Biopsy) <= a(diagnoser, D)
then
null <- treatCancer( PatientID, Age, Biopsy)
a(pharmacist, F) ::
referral(PatientID) <= a(diagnoser, D)
then
null <- prescribeMedication(PatientID)
Satisfying a constraint in a choreography (identified as choregraphyid.rolename.constraintsignature) means to satisfy a clinical goal: in some cases the goal can be to take a decision, given the available information, in other cases to perform an activity, in other to execute locally a clinical plan. For example, the goal of ''"makeDiagnosis(PatientID, Age, Biopsy, Diagnosis)"'' in this choreography is to obtain a diagnosis about the weight loss, and to obtain information about the age and a biopsy. The satisfaction of a goal is delegated to the participant in the role that contains the constraint.
A clinician subscribes to a role in a choreography because:
he/she needs to satisfy a goal (for example, diagnosing a patient illness with the help of other clinicians) or
because knows he/she can provide services for helping other participants in satisfying their goals (for example, by providing his/her expertise on a specific illness).
In order to participate, the participant needs to verify if it is able to satisfy the goals defined by the constraints. This means to verify if it has local guidelines whose goals match those of the constraints in the role he/she intends to perform. In other words, one constraint is matched by a participant to one of his/her guidelines:
choregraphyid.rolename.constraintsignature → one PROForma guideline
Matching can be:
static: a table connects a choregraphyid.rolename.constraintsignature element directly to a guideline.
dynamic: it is performed between the information describing the constraint and the information describing the guideline. The information can be the ontological types of parameters together with choreography and role description (currently available in OK), or explicit annotations of goals and requirements of constraints (extension of OK)
Implementation: bridging OpenKnowledge and Tallis
In OpenKnowledge constraints in roles are dynamically mapped, at subscription time, to methods in plug-in components called OKC. The mapping is performed by a semantic matcher that finds correspondences between the annotated signatures of the constraint and of the methods in the avaialble OKCs. The annotations specify the "ontological types" of parameters in constraints (in the LCC choreography) and methods (in the OKC class). Ontological type can be structures: for example the ''Diagnosis'' variable in the constraint ''makeDiagnosis'' can be of ontological type ''decision(diagnosed_illness, confidence)''. We say "ontological type" of a variable to distinguish it from the data type of the variable (string, int, boolean, etc).
In order to maintain the current model, guidelines need to be wrapped by methods in OKCs. For the moment, the matching can be performed using a configuration table that contains all the correspondences. A guideline is executed by a PROForma engine: the method corresponding to a constraint must instantiate a PROForma engine, load the guideline, start it and wait for its end.
Constraints have input parameters and output parameters. Input parameters are variables already instantiated: they can be contained in messages received from participants in other roles, or they can be output variables in previous constraints. Output parameters are uninstantiated variables, whose value is set by the method corresponding to the constraint. A PROForma guideline may require data and during its execution some variables may be set. The input parameters in a constraint are pushed into the guideline engine after its creation, and output parameters are pulled out from the engine when the guideline terminates. The ontological type annotation of parameters in constraints is used to find the corresponding variable in the guideline and to push the value into the engine - if it is an input parameter - or pull it out - if it is an output parameter.
The aim of pulling variables out of a guideline engine, instantiating parameters in constraints, is to introduce data into the choreography level, allowing exchange of information with other participants. Sometimes a role needs to satisfy more than a single constraint, and some of the information obtained in guideline ''i'' is needed in guideline ''i+k''. One possible solution is to extract all the information from the engine into constraint parameters, making the information needs explicit. But this, in my opinion, breaks the separation between the two layers (choreography and guidelines). The solution is that guideline engines are stored, for the length of the interaction, after their execution; when a new guideline engine - corresponding to a new constraint - is instantiated, the bridging method transfer required data from instances of engines previously executed in the interaction into the new engine.
The execution of guidelines usually requires a lot of user interaction: for example, the user needs to insert data, or needs to evaluate the arguments for and against a particular hypothesis. A user may be involved in many interactions contemporaneously, and therefore it needs to work on different guidelines. Some guidelines may take hours to be executed, or may take different steps, each possibly separated by hours. The execution of guidelines is therefore decoupled from the choreography. This is achieved by pushing the instantiated guideline engines into a separate TODO list, accessed directly by the user. The TODO list provides the user the functionalities for selecting the guideline he wants to work on and running it through an adeguate GUI. The instances in the TODO list are described by their name (or goal) and by data extracted from the engine: it is possible to annotate the bridge method with the name of the variables to extract from the engine instance as its descriptor. For example, each instance of guideline for making the diagnosis can be identified by patient name and id: the doctor accessesing his/her TODO list will see a list of activities composed by tuples "diagnosis activity, patient name".
Summary
The bridge method in the OKC:
- instantiates a PROForma engine
- loads the guideline (the guideline name is a static parameter of the class. The file is stored as a resource in the OKC jar)
- gets the list of variables that are needed
- extracts the data from the sources (input parameters for the method or instance of the previously run engines) and pushes them into the engine
- extracts from the engine the variables that are required to define the instance in the TODO list
- pushes the engine instance and its description in the TODO list (via the PeerAccess mechanism)
- waits the end of the guideline
- extract from the engine the variable that are needed for the output parameters
- store the engine instance in the interaction context
