We are currently working on an implementation of some process support. We are in general using archetypes for our modelling and we have found Instruction/Action to be well suited for our current need. Actions will tell the current state of each activity and based on this state new steps will be available. We intend to present this to our user so that only the steps currently available will be presented in the user interface. This can be inferred by our software from the generic ISM and the particular careflow steps modelled in the actual Action.
In setting this up we have come across a severe limitation in the tools we use for modelling. Neither the Archetype Editor (AE) nor the Template Designer (TD) supports the transition property of the ISM_Transition class. Without this information we are not able to infer legal actions from the current state; how can you distinguish “resume” from “active_step” when all you know is their current_state (i.e. end state), which in this case is the same? When the current state is SUSPENDED we certainly only want to present to the user “resume”, but with this limitation we are forced to present all transitions that has ACTIVE as its current_state. This introduces both hazards and poor usability.
We have tried to edit the ADL-file in a text editor, adding the missing information. When opening and saving the file from AE this will again disappear and the OPT generated by TD has no trace of the transition information, so they both seem to be completely ignorant of this essential piece of information.
Are there any plans to include transition support in these tools? Is there anything we are overlooking in our approach?
Until two years ago the Archetype Editor used to have a Transitions option from the Pathway Specification. It had never worked in any previous version of the Archetype Editor, however; and up until that time no one had ever found that the transition constraints should be limited more than the standard openEHR state diagram.
The partial implementation that was in place in the Archetype Editor until then seemed back-to-front with respect to the reference model: the RM specifies that ISM_TRANSITION.transition is the transition that occurred to arrive in the current state, whereas the user interface was constraining which states could be reached from the current state. To avoid confusion, we removed the non-functional implementation after Pablo reported it.
If people actually need to constrain transitions, then there is some work to do in the Archetype Editor. First of all, we would have to decide what the ADL and XML should look like. Pablo suggested that the ADL would be just a constraint of a DV_CODED_TEXT attribute (ISM_TRANSITION.transition), like the constraints on ISM_TRANSITION.current_state or ISM_TRANSITION.careflow_step.
Apart from the work in the Archetype Editor, it would affect downstream tools which would start to encounter constraints on ISM_TRANSITION.transition for the first time; and, as always when implementing something for the first time in archetypes, this entails a risk that those downstream tools might break. The Template Designer, OPT generation and CKM would all be likely to need fixes to support it.
Whether it makes sense to update the new tools or whether we opt to update AE and TD, as I said in the other thread about Demographics archetype support, it is vital that we work as a community on this, and not simply rely on the goodwill of one or two vendors.
The whole area of workflow support and aspects like Pathways and transitions is right at the cutting edge of openEHR implementation so it should be no surprise that the tooling has gaps and bugs in this area. Those of us who rely on these tools professionally/commercially, I believe, must be prepared to support their development in-kind. In due course, I do hope that the Foundation can underpin this vital work with some seed funding but we are not there yet, and must rely on broad community input.
Although it may be worth doing this in the new web tools, there are existing tools being used by many more existing users that need to support this functionality, at least in a lossless manner.
Each of the tooling providers need to have the opportunity to be involved in the process and agree on the implementation approach to ensure compatibility between tools. As you say, there are downstream tooling dependencies and there may be a mixture of tooling providers that provide the end to end tool chain. This doesn’t even take into account the impacts on software developers who have existing operational products.
The entire process actually needs to start with getting agreement on what the constraints look like in ADL, etc. I must say, the current ADL representation of ISM_TRANSITION constraints is not pleasant and this sounds like it may be taking this even further. Again, the impacts on how operational systems will consume this need to be considered.
I would recommend that the openEHR Software Program takes the role of coordinating this significant tooling enhancement since it has such widespread implications.
