Andrew, There is a huge leap in functionality in moving from a "passive" recording system to an "active" workflow management system. Traditionally, WfMs deal with highly repeatable processes, utilising pre-defined static process schemas. They depend on a rich organisational model, incorporate sophisticated notification mechanisms, and possess the ability to relate and alter participant workload across cases. Their routing primitives are usually simple and their schemas are applied to deterministic processes. The object of a case is normally only subject to one Wf schema ( contrast with comorbidity in health ), in one organisational setting.
Whilst it might be possible to store per-patient dynamically changing Wf schemas in a health record, 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 and http://workflow.healthbase.info/monographs/index.html regards, eric -------------------------------------------------------------------- Eric Browne Montage Systems [EMAIL PROTECTED] Norwood, SA 5067 Australia. -------------------------------------------------------------------- On Sat, 7 Dec 2002, Andrew Ho wrote: > On Sat, 7 Dec 2002, Thomas Beale wrote: > ... > > Transactions are just an abstraction in the reference model. To get a > > feel for how we see the general model of an EHR, see the EHR Reference > > Model spec, and also the Common Reference Model spec. They describe the > > semantics of "change control". > > Thomas, > If I understand you correctly, openEHR "transactions" describe how > medical record instances (=archetype instances) are changed? For example, > a "family history transaction" may make use of multiple archetypes to > create a "family history instance" in the medical record. Is this correct? > If this is the case, "openEHR transactions" is functioning partly as a > "workflow" in as far as what people generally mean by "workflows". Do you > disagree? > Of course, I realize that you may not intend to give "openEHR > transactions" the full capabilies of a typical workflow (split, join, > etc). However, I don't understand why not. Why have a pared down > "workflow"? Wouldn't you need full-blown workflow capabilies down > the road anyways? > > > >I do not see mention of "transactions" in your newest presentation. > > >Where do you see "transactions" fitting into the new "knowledge" > > >landscape? > > > > > there will be archetypes for transactions, for example, if you want to > > say that there are transactions for "family history" or "vaccination > > history" you build archetypes to do that. > > Are you planning to call every object class an archetype? :-) > Would you also have "archetypes for workflows"? > > > Workflow will have its own model, not yet developed yet. The basic > > semantics of workflows are different from those of "recording" which are > > captured in the EHR model. > > I think the basic semantics of workflows nicely describe the process of > creating information according to any EHR model. The "records" for each > patient, of course, will consist of multiple workflow instances, > "forms", etc. > > ... > > > If you are in a hurry, you can jump directly to the slide on the new > > >user-definale workflows, here: > > >>http://www.txoutcome.org/scripts/zope/readings/OIO_talk/slides/oshca2002workshop/definable%20workflow > > > > > yes, I would agree with this slide. This is the basis of a model which > > includs the idea of "step", "delay", sequencing, parallellisim, > > asynchrony, and splitting and joining. The work of Samson Tu (Stanford) > > and others on decision maps and action maps is useful in this area. > > Thanks! I found Samson's presentations and papers here: > http://smi-web.stanford.edu/people/tu/ > > In particular, the "Comparing Computer-Interpretable Guideline Models: A > Case-Study Approach" papers are the most useful. > [part 1, http://smi-web.stanford.edu/pubs/SMI_Abstracts/SMI-2002-0922.html > and > part 2, http://smi-web.stanford.edu/pubs/SMI_Abstracts/SMI-2002-0935.html] > > The developers of Asbru, EON, GLIF, GUIDE, PRODIGY, and PROforma > participated in an informative comparison of their approaches. > > > I think there is a way to go on figuring out how workflow will > > integrate in the EHR environment. > > Do you know why "generic" workflow modeling tools would not work for > healthcare workflows/guidelines? I have not seen anything that truly sets > health-related workflows/decision support apart from other > application domains. I am probably missing something important. > > > Some of our early ideas are in the openEHR EHR RM spec (there is an > > example of how to manage a PAP recall, and what is needed inthe EHR to > > support this). > > Could you give an URL that points to this "PAP recall" example? It seems > that the various guideline modeling efforts are trying to harmonize their > models under HL7. > > > Eventually we will get the bandwidth to look properly at OIO, but it's > > not going to be tomorrow unfortunately... however, I do look forward to > > working with it one day. > > Great! I really appreciate your willingness to help me understand > openEHR/GEHR. We have been talking about implementing workflows in OIO for > more than a year now. I am in the middle of trying to figure out a good > way to implement conditional branching. I hope with your help and Samson > Tu et al's prior experience, we will not make too many fatal mistakes :-). > > Best regards, > > Andrew > --- > Andrew P. Ho, M.D. > OIO: Open Infrastructure for Outcomes > www.TxOutcome.Org >
