Healthbase Australia
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:-
Contrast this with the HL7v3RIM, which associates ALL state information with specific "Acts". The full documentation for RIM_0114 can be found at\rim.htm, but a relevant extract of the rationale can be read at

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.

Copyright © 2002 Healthbase Australia.