I find that the different UML models are helpful in showing the relations
between context (use cases), data definitions (class diagrams) and data
flow - it is noteworthy that UML sees the need for three types of
interaction diagram (sequence diagrams, collaboration diagrams and activity
diagrams).
Systems with different purposes can of course interchange data, but not
naively and safely. Both sender and receiver need to have precisely the
same understanding of the data and of the context in which it originated.
Things go wrong when people make over-simplistic assumptions which are
wrong. They assume that because one urologist works in a particular way,
all do. Because urologists and heart surgeons do surgery, then a urology
system can be easily adapted to handle heart surgery. Wrong. You can
develop effective generic clinical systems, but you need to know what you
are doing. The real difference lies in the workflow, not in the data and
nor in the terminology. One of the real complexities of heart surgery is
the inter-play between the Cardiologist, the Cardiac Surgeon and the
Intensive Care Unit. The fact that people cannot agree on how many cardiac
arteries there are is of minor significance in informatics terms.
The example you give, Andrew, of pharmacy prescription status demonstrates
one of the most common safety risks of data interchange, where the same code
or term is used to mean significantly different things in different
contexts. The example given may not pose a danger but it is easy enough to
find cases which do. This is a safety issue, and to my mind, one of the
most important issues in health informatics. It is not rocket science, but
being careful seldom is.
Tim Benson
> -----Original Message-----
> From: Andrew po-jung Ho [mailto:[EMAIL PROTECTED]]
> Sent: 21 December 2000 21:12
> To: Tim Benson
> Cc: [EMAIL PROTECTED]
> Subject: Workflow, Data Definition, Terminology, was RE: EMR Data
> Definition
>
>
> 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
>
