On Sun, 8 Dec 2002, Eric Browne wrote:
...
> There is a huge leap in functionality in moving from a "passive"
> recording system to an "active" workflow management system.

Eric,
  I don't understand what you mean by a "passive" recording system. All
information systems describe information processing workflows. In this
way, all "recording systems" are "active".
  As I mentioned in the "future-proof" presentation at OSHCA 2002
(http://www.txoutcome.org), there are pre-defined workflows that are
hard-coded into the application. Then, there are user-definable workflows
that can be subsequently re-defined. For monolithic systems (using Thomas
Beale's language), changing a system's information schema (including
workflows) is rather hard.  However, a "future-proof" system provides the
infrastructure tools to facilitate adaptation/change in data schema (GEHR
archetypes / OIO forms) and workflows.
  All applications enact workflows - a workflow engine merely modularizes
the workflow enactment functionalities so that alternative workflow
specifications can add to or replace existing ones. I was not sure whether
Thomas thought of this as part of his "future-proof" design. I know this
aspect of "future-proof" is quite important since we have encountered
several use-cases that require workflow re-design. Some of these use cases
are contributed by users of the OIO system and available through the
open-outcomes-general list archives.

> Traditionally, WfMs deal with highly repeatable processes, utilising
> pre-defined static process schemas.

Traditional workflows can be quite complex - with many splits, alternative
paths, conditional branching and checks. The process schema is pre-defined
- but modifiable through run-time conditional steps, and over time as
needs change.

> They depend on a rich organisational model, incorporate sophisticated
> notification mechanisms, and possess the ability to relate and alter
> participant workload across cases.

Sounds good - these attributes are also quite useful for health-related
applications.

> Their routing primitives are usually simple and their schemas are
> applied to deterministic processes.

I am sure the "deterministic process" bit cannot be a strict requirement.
:-) Unexpected things can always happen.

> The object of a case is normally only subject to one Wf schema (
> contrast with comorbidity in health ), in one organisational setting.

I am not sure how this is relevant. Nothing in this world happens in
isolation. I am sure it is not uncommon for multiple workflows or workflow
steps acting in parallel to achieve a given target state. I fail to see
how healthcare related workflows are any different.

> Whilst it might be possible to store per-patient dynamically changing
> Wf schemas in a health record,

How did you arrive at the conclusion that health-related workflows require
"per-patient dynamically changing workflow schemas"? Perhaps the enactment
of pre-defined _fixed_ workflow schema for similar patients could also be
useful? (e.g. an appendectomy workflow for those with acute appendicitis).

> the ability to make use of such schemas via sophisticated Wf engines
> is a problem orders of magnitude more difficult. But it is interesting
> to see openEHR approach the challenge for a simple recall system.
>
> I have a web site devoted to Workflow in Healthcare. In particular
> I refer you to :-
>
>   http://workflow.healthbase.info/wf_in_healthcare.html

Thanks for the very useful reference. You listed 5 healthcare
"domain-specific" hurdles in your writing. While I don't agree that they
are truly domain-specific, they do serve as a highly useful "features
list" to guide our implementation plan! As we continue to implement OIO's
workflows module, I will reference our progress with regards to your list.
:-)

>     and
>   http://workflow.healthbase.info/monographs/index.html

There are two papers here. The first one is about patients, environment,
and workflow states. My own musing about states and workflows is that it
is up to the workflows to specify the state descriptions that are
required, at each step during enactment. Do you think that would work?

Best regards,

Andrew
---
Andrew P. Ho, M.D.
Assistant Clinical Professor, Department of Psychiatry
Harbor-UCLA Medical Center
University of California, Los Angeles
OIO: Open Infrastructure for Outcomes
www.TxOutcome.Org

Reply via email to