Hi Ian, 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. Regards Heath From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of Ian McNicoll Sent: Monday, 30 November 2015 3:22 AM To: For openEHR technical discussions <openehr-technical@lists.openehr.org> Subject: Re: Missing support for ISM_TRANSITION/transition in Archetype Editor and Template Designer I wonder if this might be work that might be worth doing in the new open-source Web tools, developed by Marand at https://github.com/openEHR/adl-designer? 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. Ian Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)1536 414994 skype: ianmcnicoll email: i...@freshehr.com<mailto:i...@freshehr.com> twitter: @ianmcnicoll [https://docs.google.com/uc?id=0BzLo3mNUvbAjT2R5Sm1DdFZYTU0&export=download] Co-Chair, openEHR Foundation ian.mcnic...@openehr.org<mailto:ian.mcnic...@openehr.org> Director, freshEHR Clinical Informatics Ltd. Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On 27 November 2015 at 23:10, Peter Gummer <peter.gum...@oceaninformatics.com<mailto:peter.gum...@oceaninformatics.com>> wrote: On 28 Nov 2015, at 00:36, Ivar Yrke <i...@dips.no<mailto:i...@dips.no>> wrote: > > Are there any plans to include transition support in these tools? Is there > anything we are overlooking in our approach? Hi Ivar, 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. Pablo Pazos raised a problem report that alerted us to the fact that it wasn’t working: https://openehr.atlassian.net/browse/AEPR-6 Pablo’s discussion about it on CKM is here (log in, click on the Discussion button, and expand the replies): http://ckm.openehr.org/ckm/#showArchetype_1013.1.123 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. Peter _______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org<mailto:openEHR-technical@lists.openehr.org> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
