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: [email protected] twitter: @ianmcnicoll Co-Chair, openEHR Foundation [email protected] Director, freshEHR Clinical Informatics Ltd. Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On 27 November 2015 at 23:10, Peter Gummer < [email protected]> wrote: > On 28 Nov 2015, at 00:36, Ivar Yrke <[email protected]> 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 > [email protected] > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
