On Sat, 7 Dec 2002, Andrew Ho wrote: > 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".
When talking about workflow schemas there is usually a principal object to which the schema applies. It may be the production of a car, the processing of an insurance claim, the management of a person's healthcare. A WfMS can launch tasks, even assemble a car without any human intervention. An EHR is a sink for information. It may also be a source for a subset of the information it stores, but only in response to an external request for that information. In this sense it is passive. > 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. That's a bit like saying that a Berkeley dbm file is a database. But it is a long way from a RDBMS like Oracle, with support for users, roles, profiles, rollback, rollforward, transactions, triggers, stored procedures, adminstration interfaces, table locking, record locking, distribution, replication, etc. etc. > > > 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. > Usually, the over time refers to instantiation of new cases based upon new business rules. There is usually a major issue with the migration of running instances to a new schema. > > 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. > But not normally part of an EHR subsystem. > > 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. > In traditional WfMSs support for ad hoc changes is very limited, and the requirement is rare. In healthcare, unexpected things don't always happen, but they do often 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. Not when there are dependencies/conflicts between the workflows. How often in healthcare do we see service providers duplicating tests, prescribing conflicting medications etc.? > > > 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). I meant "health-related workflows require the ability to support per-patient, dynamically changing workflow schemas", not that such an ability would be called upon for all cases. And certainly, the enactment of pre-defined _fixed_ workflow schemas for similar patients would be useful. Not only useful, but something to aim for in designing clinical guidelines to cater for a wide range of patient variability. > > > 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. > :-) If not domain-specific, then domain-limited. > > > 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? > I think this is impossible and impractical. That is the reason for identifying 3 classes of state. A workflow engine should not need to know what state information is required for a given task. It should, for example hand over a patient to the anaesthetist for an appendectomy without knowing the weight of the patient, nor that the patient is allergic to a particular anaesthetic, nor the patient's age or sex, nor any other specific piece of patient state information pertaining to that task. One would need to educate the workflow engine about every clinical task in its schema, and reeducate it for every change in every clinical task. However, it would be nice if such information were available from a global repository such as an EHR :-) A workflow engine should provide workflow state such as patientID, reason for operation, previous workflow tasks in this schema, the next downstream task to be undertaken, etc. I hope this does not discourage you from pursuing workflow integration into OIO. I think WfMS have much to offer healthcare, but believe the engine(s) should _definitely_ be decoupled from the EHR system. regards, eric
