Tim, I am so glad that you raised this very important issue. I agree that it is
critical that we clarify the relationships between these entities (workflow, data
definition, terminology). I will try to do that below. Please let me know if I am
getting it wrong.
---
On Thu, 21 Dec 2000 18:57:28 Tim Benson wrote:
>You are right in identifying that workflow as the critical issue, but it is
>a different dimension to data definition.
I agree. Workflow does not equal data definition. However, data definition must
adequately support the modeling of the workflow. Therefore, there will be different
data definition requirements depending on the workflow. How does that sound to you?
>Far too many people think about
>EMR in terms of data definition alone. One of the main reason why systems
>are not transferrable from one domain to another is not, as is so often
>claimed, that the data definitions and terminology are different, but just
>that the workflow is different.
Are you saying that it is not possible for two systems that model two different
workflows to interchange data? I don't think that is true.
For example, a clinic and a pharmacy can interchange prescription data but their
respective workflows are obviously different.
Of course, differences in workflow can lead to differences in data definition that
complicates data interchange. For example, the clinic may use a clinic record number
to uniquely identify patients while the pharmacy uses the patient's name and phone
number to identify the patient. This difference in workflow translates into different
data definition and difficulty interchanging prescription data. However, the solution
does not require that the clinic and the pharmacy change how they uniquely identify
patients (workflow). Instead, data interchange will work if there is a way to map
clinic number to name and date of birth (mediator).
>Terminology can usually be modified quite
>easily, data definitions are harder, but workflow assumptions are often
>implicit in the architecture at a deep level.
The relationship between terminology and and data definition is quite interesting. I
presume that if the terminology is changed (because it is more easily modified) while
the underlying data definition remains the same (because it is less accessible to the
users), then the new and old data are not "inter-operable".
An example may help. Let's say the pharmacy workflow requires that the information
system keeps track of whether a prescription is a new prescription or a renewal of an
existing prescription. The data definition used is new_prescription={no,yes}. The
initial terminology is new_prescription: yes=if the patient had received the same
medication before from this pharmacy. Now, let's say this particular pharmacy is
purchased by a pharmacy chain/network and the new workflow requires a different
terminology where new_prescription: yes=if the patient had received the same
medication from any pharmacy within the network of pharmacies. In this case, it is
easier to change the terminology than the data definition. However, the old and new
data do have different meanings.
Your observation that workflow assumptions are implicitly in the architecture at the
deepest level is correct. However, this fact does not preclude the design and
implementation of highly flexible systems that are capable of modeling a wide range of
useful information processing systems (i.e. equivalent in power to the Turing machine).
>Consider, for example, what different specialists (in the same specialty) do
>between receiving a referral and first seeing the patient. Some do little
>or nothing, but others will triage for urgency and re-arrange appointments,
>identify who is to see the patient, check previous notes, arrange for tests
>to be done in advance, make transport arrangements etc. How many systems
>can support all of these basic workflow requirements?
Paper records! ...and the OIO :-) ...and in the future, other OIO compatible systems
like FreePM.
and GEHR too, when it is adequately implemented!
>Failure to
>accommodate variation in working practice is the nub of many difficulties.
I agree 100%. The challenge is to actually design and implement a system that is
sufficiently flexible and yet capable of mediating between different but related data
definitions.
Andrew
---
Andrew P. Ho, M.D.
OIO: Open Infrastructure for Outcomes
www.TxOutcome.Org
Assistant Clinical Professor
Department of Psychiatry, Harbor-UCLA Medical Center
University of California, Los Angeles
Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at
http://www.eudoramail.com
