In openEHR, we’ve neatly sidestepped the issue of ‘workflow’ by using the term task planning, which I think better corresponds to the scope we think we can manage. If we were to say we were writing a specification for workflow, it’s like someone in the construction industry saying, hey, we’re writing a spec for architecture, it’s going to be great … because workflow is sort of everything, or at least everything that moves.
Along with colleagues at Marand (Slovenia), DIPS (Norway) and Lanit (one of the Moscow mega-EHR implementer companies), I’ve been working fairly constantly on the new specification. The others all bring knowledge of use cases, current challenges and of course many great ideas on how to specify a Task Planning framework, while I bring some of what I have learned with the Activity-Based Design (ABD) team at Intermountain Healthcare, where I also work, as well as about a year’s worth of background literature research. The guys at DIPS in particular have a lot of knowledge on concrete scenarios because of the close relationship DIPS has with the clinical sector in Norway, and their long-term experience in full EMR implementation, which is proving to be extremely useful.
The work is still in its early stages, and we aim to get anyone with experience and ideas involved. Nevertheless, our teamwork so far has helped knock out some errors from my original design, and show up limitations that have required further modelling.
We are starting to build formal Task Plans based on the specification, for particular use cases, including parts of Stroke management, R-CHOP (5 drugs x 5 days) chemo, routine in-patient drug admin, surgery follow-up and various other scenarios – this can be done as archetypes based on the new model, UML object diagrams, JSON text or by various other means. At some point we may think of a dedicated tool…
Some of the things we’ve added include:
- new Task types like Sub_plan, Handoff, External_request;
- form / data-set references for Tasks, to enable an engine to display forms that are required for Tasks;
- context-switching semantics, for handling Handoffs and External_requests;
- decision tree semantics.
The following is a sketch of part of a Task plan that deals with the seemingly trivial generic problem of when a clinical variable is needed (e.g. BMI CHADVASC) for making a decision, but the variable’s input parameters (e.g. weight) are not up to date.
This kind of thing is conceptually simple, but hard to express clearly in workflow languages like BPMN (YAWL does better, but still not ideal). There’s no guarantee we’ll get this or other challenges right either, but we’re looking very carefully at everything that has gone before, and trying to think outside the box. Similarly to the ABD group at Intermountain, we are relying on incremental implementation experience to prove the models properly as we go.
There is of course much more, which can be found in the specifications, or on the wiki pages (latest workshop notes, main page), if you really have no other life.
Feel free to join us by following these pages and the openEHR mailing lists.
I just returned from Heidelberg, where another very successful ‘openEHR day’ was held, this time by the HiGHmed research consortium, with 100 attendees. HiGHmed is funded with 20m€ by the German Federal Ministry of Education and Research (BMBF) under the “Medical Informatics” funding scheme, and has as its goal (my bolding):
wolandscat