Model driven software engineering (MDSE) is an emerging methodology for software development, targeting productivity, exibility and reliability of systems; metamodelling is at the core of most MDSE approaches. Due to their complexity and plethora of requirements placed upon them, healthcare systems so far have not been adequately modeled; as a result the software developed for them su ers from high development costs and lack of exibility, and its reliability is at risk. Here we propose a metamodelling approach that captures the complexity of these systems by using a metamodelling hierarchy, built from ve metamodels, one each for user access modelling, health process modelling, process monitoring, user interface modelling and modelling of the data sources. These metamodels are coordinated with morphisms. Such a hierarchy allows us to adequately re ect the behavior and complexities of systems and how they interact with di erent stakeholders. We give details of some of the metamodels and present some suggestions for some di erent interfaces intended for two di erent users: the clinicians and the patients.
Rising costs, ageing populations and increased expectations are making the
current healthcare systems in the developed world unsustainable. Numerous studies
support this claim, for instance in the US, if the trends of the last 20 years
continue, health care spending will eat up the entire GDP within the next
generation, and health care spending will eat up the federal government's budget even
sooner [
Model driven software engineering (MDSE) is an emerging and promising methodology for software development, targeting challenges in software engineering relating to productivity, exibility and reliability of systems. The construction of various kinds of models (e.g., blueprints, mockups etc.) is a wellknown approach in the more traditional engineering elds; these models are used as artifacts to enable engineers to describe designs and validate whether a proposed design has desired qualitative and quantitative properties. Metamodelling is at the core of MDSE approaches. Here we propose that a multi metamodelling approach is the appropriate methodology for designing healthcare systems. The use of multiple metamodels for designing di erent aspects of a system facilitates abstraction and require less coupling among the models; this gives us exibility as it permits the independent remodelling of parts of the system. This paper is a preliminary look at 5 aspects of healthcare systems, and the necessary coordinations among them. Due to lack of space we focus our discussion on the access control, monitoring, user access and usability aspects.
Many di erent MDSE technologies automatically generate code from models
[
A collaborative group of researchers in Norway and Canada have been
working on various issues relating to these problems. We proposed a formal
approach to work ow modelling in [
Clinicians generally follow clinical guidelines to manage speci c diseases. A
clinical guideline is a description of processes, treatment procedures, appropriate
medications, etc., to manage a particular disease. Interested readers may refer to
the guideline for Hypertension Management [
For modeling healthcare processes, we have used the DERF work ow
language [
Remark, there are some composite tasks such as `Visit1', `CBPM' (Clinical Blood Pressure Measurement) in the work ow model; those are abstractions of subwork ows. The subwork ow for `Visit1' composite task is shown in Fig. 1(b).
Initially a patient's blood pressure (BP) is measured at the `Initial BP' Task, which may cue the clinical hypertension management procedures if the BP is greater than or equal to 140=90. If the initial BP is normal (<= 140=90), the work ow terminates. In Fig. 1 the patient's Hypertension is managed through investigation and treatment. The clinical procedure (i.e., `Visit1', and other subsequent tasks in Fig. 1) starts at the doctor's o ce. Patients with high BP have risk of organ failures and/or other chronic illness. During the rst visit at the doctor's o ce (`Visit1') BP is measured twice, an initial assessment is done, and an investigation is started with diagnostic tests. After `Visit1' the work ow executes `Ambulatory Blood Pressure Monitoring' (`ABPM') or `Self Home Blood Pressure Monitoring (`SHBPM') if they are available and a \Clinical Blood Pressure Measurement" (CBPM) is performed. Note the overall work ow model in Fig. 1 uses the abbreviations CBPM, ABPM and SHBPM for these tasks. Overall
Safe
Many healthcare processes involve numerous stakeholders with di erent requirements. Frequently the user becomes a critical part of the healthcare workow process whether it be the physician, a specialist or a lab technician, or the patient, in situations where management of lifestyle parameters is a critical component of the process. We are now researching a metamodelling approach to work ows which incorporates the concepts of stakeholders and process monitoring and provides userfriendly interfaces for a variety of users.
The PhD thesis of [
We extend the model Baarah presented in [
Given the complexity of the information requirements in healthcare systems, we propose that separate metamodels, i.e., multi metamodels is the appropriate approach to modelling healthcare systems. In this paper we discuss metamodelling of ve aspects of healthcare systems: user access modelling, health process modelling, modelling of process monitoring, user interface modelling, and modelling of the data sources. Links (directed arcs) between the metamodels are used to coordinate them (see Fig. 2), i.e., directed arcs from one metamodel to another in Fig. 2 represent the bindings between metamodels. Using separate metamodels for modeling di erent aspects of a system gives us the exibility for remodelling and also makes models more readable. A user of a system may have access to some tasks, views, and data; this requirement is modeled in Fig. 2 by means of 3 morphisms called `Task-acc', `View-acc', and `Data-acc'. A Task may trigger some alerts (`Trigger' arc), may be displayed by a view (`Task-UI' arc), and may read/write some data from/to the datasources (`Data-acc' arc). An alert is sent to some users (`Send' arc) and is displayed by a view (`Alert-UI' arc). The user interface of a system consist of some views; the user interface views access the datasources and displays data (`Displays' arc) in di erent formats.
Note that the work ow model in Fig. 1 is typed by the `Process metamodel'; moreover, there are some predicate constraints specifying the routing of the work ow. The user access to a DERF work ow model (in Fig. 1) is de ned by Predicate
Visualization [and_split] X
Y [and_split]
Z u2 M2 M1
Copy-acc the morphism called `Task-acc'. Here we discuss the metamodelling hierarchy for the user model. The left hand side of Fig. 3 shows two modelling levels M2 and M1 of a user model where Su2 and Su1 are the speci cations (respectively). The `Copy-acc' morphism is used to copy access from one user to another. One instance of the `Copy-acc' morphism from `Doctor' to `Nurse' in Fig. 3 gives Doctors all the access that Nurses have. The `Inrelation-with' morphism is used to associate caregivers with patients. In this case, only doctors or nurses who are treating a patient can access that patient's information. This access control aspect is modeled using the `Inrelation-with' association. The right hand side of Fig. 3 shows two modelling levels of a DERF work ow model with speci cations Sw2 and Sw1 . At level M1 the predicate [and split] is used to model concurrency.
To visualize the user access for a work ow model we propose a user interface in Fig. 4 where the user nodes (e.g., Doctor, Nurse, Patient) are displayed at the bottom of a work ow model. Selection of a user node from the bottom window highlights all the accessible tasks from the work ow model. In the gure, the user Patient has only access to the `SHBPM' that has been shown in gray. If a doctor and a patient instance are both selected from the drop-down, the system highlights all the tasks that this doctor can execute for this patient.
While executing the `SHBPM' task the patient registers his lifestyle information; in this work ow the patient is responsible for registering his lifestyle information and doctors and nurses are responsible for the rest of the work ow. Both the doctor and the patient should have access to the lifestyle information. Doctors have a user interface similar to the one the patient uses, but it has many more features (e.g., sending an e-mail to the lab for a lab test).
Fig. 5 shows a model of work ow monitor having its own metamodelling hierarchy and its association with a process metamodelling hierarchy and a user access metamodelling hierarchy. Tasks from a DERF work ow model can trigger alerts. We have two types of alerts: `Critical Alert', and one less urgent, called `Reminder'. The `SHBPM' task from Fig. 1 triggers a `Data Entry' alert if the patient forgets to enter data on some day. It also triggers a 'Excessive Weight Overall
Safe
Gain' alert if the patient's weight gain exceeds 10 pounds in less than 5 days. This
ring condition is encoded in the predicate [Cond 2] found on the co-ordinating
link between the `SHBPM' task and the `Data Entry' alert. Di erent users can
receive di erent alerts. In this gure, only the doctors are alerted about the
`Excessive Weight Gain' to indicate that the patient is retaining excessive uids
and the doctor should consult that patient immediately. The `Data Entry' alert
is sent to the patient to inform the patient that he or she has forgotten to enter
information. In a DERF work ow a task may have time constraints [
Successful of technology depends a great deal on usability or user-friendliness of
its user interface (also called \UI" or simply \interface"). A UI is the means by
which a person controls a software application or hardware device. A good user
interface provides a \userfriendly" experience (where userfriendly with respect
to software is de ned by the Merriam Webster dictionary as \easy to learn, use,
understand, or deal with") allowing the user to interact with the software or
hardware in a natural and intuitive way. In this section, we discuss the
development of two kinds of user interfaces needed for the Management of Hypertension.
(Some preliminary discussion of these interfaces may be found in [
First, consider the interfaces which allow clinicians to interact with the system. Fig. 6 shows 4 windows named `Work ow Viewer', `Task Execution Viewer', `Lookup Viewer', and `NOVA Browser'. The right hand side of the `Work ow Viewer' lists all tasks currently enabled by a work ow (e.g., Fig. 1) running underneath the hood; and therefore are available to be done. Whenever a task is executed, the task name is put on a calendar. Dates of scheduled appointments are also presented on the calendar. By default the calendar shows the 'month view' but di erent levels of granularity may be con gured (e.g., weekly view, hourly view, etc.). A task being executed is shown in the `Task Execution Viewer'. Inputs required from the end user are shown in branches and the end user must select a branch and assign a value to it through the `Lookup Viewer'. The `Lookup Viewer' helps the end user to input information either by showing relevant values from an ontology or by allowing the end user to enter information. Once a task is executed, the information are hierarchically displayed in the `NOVA Browser'. Fig. 6 shows that the user is executing the `Measure BP' task. Inside the `Task Execution Viewer' window, the user provides input to execute the task. This is an alternative way of taking user input rather than using Forms. This view can also be con gured to include a traditional `Form view' where the user provides input in `Form elds' (e.g., text boxes, drop down boxes, etc.). While executing tasks the user has access to historical information for this work ow instance; the intent here was to provide the user with a more userfriendly environment to concentrate on care, avoiding the need to go back through forms, either in a paper based or in an electronic format, to get information they need.
The `Lookup Viewer' at the bottom left of Fig. 6 provides options allowing the user to select or enter data. This window is connected to a database and shows only relavent data from the database. This view can also be con gured to connect to an ontology and show relevant terminology from an ontology to help the user input information while executing a task. Data inserted or selected by the user in the `Lookup Viewer' is re ected in the `Task Execution Viewer' window. When the user is nished entering all input for a task, the task is executed and this updates `NOVA Browser' nodes. For this system we developed di erent user interfaces for di erent user types. These are built depending on the needs and expertise of the user.
We now discuss the Personal health monitor smart phone application that gives the patient a userfriendly interface for self management of lifestyle attributes which cause the patient to be at risk. The patient can input data for lifestyle attributes such as, exercise, smoking, intake of fruits and vegetables and record such attributes as weight and blood pressure. The purpose of the application is to assist patients keeping their health record such as blood pressure record, body mass index, hours of exercise, dietary, etc. and monitor their performance with their lifestyle target that was set by the physician from `Hypertension management work ow'. The web-based tool allows both the patient and the clinician to view summary data on lifestyle parameters between visits and provide calendar views of past activities, future appointments, etc. In (Fig. 7) we see that using the smart phone application, the patient can monitor their exercise and eating behavior.
The smart phone application allows the patient to execute the `SHBPM' task (see `Overall' work ow from Fig. 1) from home. The `Personal health monitor' application interacts with the `Hypertension management work ow'. The integration is accomplished by the task `SHBPM' (see Fig. 1) from the `Hypertension management work ow'. We have developed several interfaces that give summary data to the patient and doctor by projecting patient's data into graphs and charts. Fig. 8 shows two screenshots from the smart phone application that takes blood pressure input from the patient and displays a graph of recent blood pressure measurements. Projecting di erent data on the same timeline may provide analytical ability to the user. The smart phone application can also fetch an appointment date from the work ow and reminds a patient about the date of the next visit.
Demos of the system were made to several people including a local GP who deals with many patients with chronic diseases, a nurse who is the VP of Community Services for GASHA, our local health authority, and a physiotherapist, who is the manager of the local Seniors' Wellness Program. The feedback on the interfaces for the Personal health monitor was excellent { indeed the GP is considering using some apps of this nature developed by our students in his practice. The clinician views as shown in Fig. 6 were less enthusiastically received. In general, it was felt that the clinicians would nd this tool too hard to use; we plan to work with some clinicians and designers to see what can be done to develop intuitive interfaces for clinical practice guidelines for chronic diseases suitable for use by clinicians.
Modelling the ow of tasks outlined in a clinical guideline, even a complex one, is
not too di cult if done in consultation with a domain expert (clinician familiar
with the procedure). Our modelling tools allow us to deal with the overview rst
and `zoom in' to re ne tasks into sub work ows. One challenge is to recognize
that guidelines are not rigidly de ned processes. They involve many exceptional
situations, and the sequence of tasks described by a guideline may need to be
altered, during the enactment of a work ow for a particular patient, in order
to meet user needs, while maintaining guideline intentions as much as possible
[
In previous work, we looked simply at modelling the ow of tasks in a healthcare process; however, conceptualizing a healthcare system as being comprised of ve metamodels allows us to more realistically model these complex systems. While incorporating stakeholders and monitors in the MDSE paradigm is highly innovative, these features are essential if software systems are to automatically perform the kinds of tasks users are increasingly demanding. We believe that the metamodelling together with MDSE principles in general can be used as the main methodology in the development process of software for care processes. By separating di erent concerns of a system into several metamodels we get more exibility allowing us to modify one aspect of a system described by a particular metamodel without a ecting other metamodels. We remark that this is early work in our attempt to model a systems as complex as the healthcare system; we need more e ort to capture the complexities of real-life systems. We have a prototype implementation for part of the system using the DPF framework, and we are working to extend it.
MacCaull would like to thank Natural Sciences and Engineering Research Council of Canada, and Lamo acknowledges support from the St. Francis Xavier Heaps Chair in Computer Science. We are greatful to the StFX undergraduate student, Miao Huang for his contributions to the Hypertension Work ow Model and to Jane Newlands, Manager of the Seniors Health Wellness Program for GASHA, a health authority in Nova Scotia for providing valuable feedback to us.