Healthbase ->
workflow ->
monographs ->
HL7RIM
Workflow in Healthcare - Monograph: on HL7 RIM.
by: Eric Browne, May 2002
HL7 Version 3 Reference Information Model (RIM) is quite orthorgonal to
traditional Workflow approaches to activities. This monograph looks at
the implications to Information Systems architecture arising from adopting
the RIM philosophy with respect to "Acts" or "Services".
Traditional Workflow provides for the facilitation/management/monitoring/
auditing of business processes. A business process consists of a set
of activities, a subset of which need to be carried out in a specific
order for a given case. The aim of most activities is to change the
state of one or more entities. In healthcare, the aim of most
activities is to improve the state of health of a patient. There are
also many activities which are purely diagnostic - i.e. rather than
changing state in the conventional sense, they obtain information ( e.g.
take blood pressure, obtain CT scan, undertake colonoscopy etc.). They
do not, in and of themselves, improve the health of the patient (
except perhaps by some placebo effect ). They are undertaken in the
expectation that some other downstream activity will make use of the
information to improve the patient's state of health. But such diagnostic
activities CAN be thought of as changing state, since they either
introduce new, or change the value of existing, state variables.
The picture is complicated even further when some "diagnostic" activities
transform into interventions. Colonoscopists frequently take the opportunity
to remove polyps whilst "inspecting" the patient, rather than invoke a
separate task to do this at a later date.
However, traditional WfMSs (Workflow Management Systems) decouple
facilitation/management/monitoring/auditing from the behaviour and
state of the activities and the entities upon which the activities
operate. Traditional WfMSs do not need to know, and usually do not
know, that "Taking Blood Pressure" is a measurement, resulting in some
value, or that performing an "appendectomy" might result in the
patient's state becoming "sans-appendix". The only attribute information
carried by the WfMS is that related to the flow, or to identification
of entities that are involved in the flow. Such attributes might
comprise such things as:-
- Patient ID
- Admission date
- Patient's GP
- Surgeon
Contrast this with the HL7v3RIM, which associates ALL state information
with specific "Acts". The full documentation for RIM_0114 can be found
at
http://www.hl7.org/library/data-model/RIM/C30114\rim.htm, but a
relevant extract of the rationale can be read at
http://workflow.healthbase.info/monographs/RIM_rationale.html.
Since HL7 is a message-oriented architecture, one can understand the
reason for this philosophy. However, from an information architecture
perspective, state information needs to persist beyond and independent
of Messages or Acts (activities). Activities often need access to state
information that has not been provided by an input message. Consider
a workflow activity "Obtain post-colonoscopy CT scan". A workflow
system might pass this task to a radiologist, together with some metadata
about the patient, such as name and contact details. Let's further assume
that there is no workflow subprocess to deal with the subtasks associated
with the "CT Scan" activity - i.e. from the WfMS's perspective it is
atomic. The workflow system should not need to know that the patient
might need a barium contrast, nor that the patient might be allergic to the
peanut cookies that the clinic provides in the recuperation room.
During, or at completion of the activity, the radiologist should be
able to update state information about the patient, without burdening
the WfMS.
Furthermore, HL7 messages were formulated for passing clinical information.
WfMSs need metadata (process attributes) to be passed to/from activities.
In many cases these metadata may not be clinical in nature. It is true
that there are classes and class attributes in the RIM which provide most
of the framework for workflow. In fact, most of the functionality provided by
V3, beyond that of V2, is an object-oriented framework for building
aggregated systems of tasks to effectively construct a Workflow Management or
Decision Support System. Of the 6 core classes in the RIM, 5 ( Act, Role,
Act_Relationship, Role_link, Participation ) seem intended for this purpose.
This represents a substantial progress in the development of a "Unified
Service-Action Model" for healthcare. But is the model the best foundation
for building health information systems?
The downside of adding this level of functionality to HL7 is firstly, a
substantial increase in the level of complexity of HL7 parsers and systems,
and secondly, an encouragement for the construction of large monolithic
systems. Should such systems ( and HL7 ) be expanded to also incorporate
knowledge representation models - i.e. clinical guidelines, care plans,
terminologies and ontologies? The author's opinion is that where components
of systems are substantially uncoupled, their models and implementations
should also remain so.
To some extent, the above analysis depends on the level of granularity
or abstraction. From a clinical perspective, the benefit of carrying out
a set of related activities augmented by software that provides relevant
clinical information when and where it is needed, such as in acute emergency
hospital care, might lead one to favour the HL7 approach. Viewing from
the perspective of managing chronically ill patients over an extended period
of years, might lead one to a different approach. Traditional workflow
systems have tended to support the latter sort of business processes (albeit
not in the health domain).
Finally, an analogy from a different domain:-
Consider a system to organise, administer, monitor and audit a chess
tournament consisting of a number of contestants and matches. A workflow
system would need to ensure that the contestants were informed about
changes to the venue or times of matches. It would need to ensure that
the schedule of matches was implementable, and the matches were carried
out in accordance with both the rules of the tournament and the rules
of chess. However, it would not have to know the rules of chess! Referees
would be brought in to adjudicate. The workflow system would need to
coordinate the referees.
20 years from now we might well be able to throw away the referees and
replace them with
e-refs. Should we then reengineer our WfMS to incorporate
the
e-refs? Should our workflow systems have classes to model the chess
rules? The author thinks not.
****
Healthbase ->
workflow ->
monographs ->
HL7RIM
This site is currently hosted and kindly sponsored by
Montage Systems Pty. Ltd.
