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
