A major problem facing today’s health care is the increasing diversity and differentiation. New medical specialities are constantly created, there exists a large number of roles in patient care, and many organisations – public as well as private – may be involved in the care of a single patient. This differentiation creates a need for the interoperability of organisations as well as their supporting systems and applications. A key instrument for achieving such interoperability is a health care ontology. At KTH, the Royal Institute of Technology, we have for several years worked with process oriented methods and ontologies for health care, [2]. Experiences from this work indicates that a process oriented way of thinking is natural and fruitful for health care suppliers as well as patients. In this paper, we report on work in progress that proposes a process oriented ontology for health care with a focus on the patient rather than on the health care organisations. The paper also discusses how this ontology can be used for structuring and visualising patient care histories. A patient centred process ontology for health care should focus on the activities that occur around a patient. Such ontologies have been proposed in several projects, e.g. CONTSYS [4], SAMBA [3], and SAMS [5]. The ontology outlined here is based on the results from these projects, but it also extends them by adding concepts that are closer to the viewpoints of a person without expertise in the medical domain. A starting point for the ontology is that a patient care process can be layered intro three subprocesses: a clinical process, a decision process, and a communicative process, [SAMBA]. The clinical process consists of activities that directly affect or investigate the health state of a patient, e.g. surgeries, medications, x-rays, consultations, and physiotherapy. The decision process consists of activities that govern the clinical activities, i.e. decide and motivate which clinical activities to carry out. Typical decision activities are diagnoses, prescriptions, and evaluations. Finally, the communicative process consists of messages from and to the patient, e.g. a patient demanding care, a hospital accepting a demand for care, a hospital sending a notice to attend, and a patient recording symptoms. An advantage of this three-layered process model approach is that it facilitates structuring of patient related activities, thereby making it easier to explain to a patient what activities are carried out and the motivation for these. This also provides a basis for visualising the patient care process and history, as outlined in the next section.
PatientCon
tact Clinical
HealthCareActitivty
Decision
Programme OfCare
Communi cative Investigation
X-ray
Treatment
Diagnosis Surgery
Exercise
Evaluation Medication
DecideOnProgra mmeOfCare
DemandFor
Care AcceptingDem andForCare
Notice StatusReport The class diagram in [Error! Reference source not found.] shows the basic concepts of this three-layered approach. It also shows the form of communication between the three process types. An activity in the clinical process can communicate directly only with an activity in the decision process, not with an activity in the communicative process. A decision activity may motivate a clinical activity, e.g. a prescription may motivate a certain medicine being taken. In the other direction, a clinical activity may form the basis for a decision activity, e.g. an investigation may give a basis for a certain diagnosis. A communicative activity may also be based on a decision activity, e.g. a hospital sending a notice to attend a surgery may base this on a prescription. Furthermore, the class diagram introduces two aggregations, which facilitates the structuring of large patient care histories. A patient contact is a session, e.g. a patient visiting a doctor at a hospital or a nurse visiting a patient at home, where one or more health care staff interact with a patient. At one such patient contact, several clinical activities may be carried out. Analogously, a programme of care consists of a set of health activities specifying how to address some health issue. As an example, a program of care may include one heart surgery, two medical cures, two weeks of physiotherapy after the surgery, and a final evaluation of the outcome of the surgery.
Due to space reasons, we present only the activity part of the ontology. In addition to activities, the ontology needs to contain concepts for health issues, health care agents, health goals, etc, [4]. Note also that more subtypes to the activities can be introduced as needed.
The three-layered approach introduced above provides a basis for visualising complex patient care histories. Graphically, the patient care history will be displayed in three lanes representing the clinical process, the decision process, and the communicative process. A patient may choose one of these lanes and navigate through it to see what activities that have been carried out. The patient may also view the reasons for carrying out a specific activity and investigate that in more detail by moving to another lane. In this way, the interface combines an overview of the patient care history with easy access to the context of specific activities and the possibility to browse the activities graphically. One of the main challenges of the interface is how to aggregate activities in such a way that a patient can quickly get an overview of her care history and then successively drill down to individual activities. In the present prototype, we have addressed this problem by grouping activities in temporal periods so that a patient will first view a number of years and then drill down into months and possibly weeks before individual activities are shown. Another possibility, which might be equally useful, is to aggregate on types of health issues, e.g. letting the patient first choose one among the diseases she has been treated for and then go into the specific activities for that disease. Furthermore, we make heavy use of the possibility to aggregate clinical activities into patient contacts and decision activities into programs of care. 3.1
Patient’s Heart-Care Case For the prototype, a hypothetic and simple patient’s heart care case has been introduced here. The case consists of three communicative, three decision and two clinical activities see [Fig. 2]. The Communicative process consists of demand for heart-care, accept demand for heart-care and status report. The Decision process consists of diagnose heart-case, decide on programme of care, and a post evaluation. The two treatment activities in Clinical process are order x-ray and treatments for the case. The treatment activity consists of a surgery followed by prescribing medication and exercises. For the prototype, we have used the Metis tool [1], which provides advanced modelling browsing facilities and capabilities for meta modelling, which are essential requirements for building an interface as the one described above.
The activities of communicative, decision and clinical processes in a Metis modeling window are shown in [Fig. 2]. Inclusion of different activities from the Metis metamodel based on health-care ontology, prompts relevant properties to be filled in by the user. For an example, the window to the right of [Fig. 2] has been popped up when including “accept demand for heart care” activity to the communicative process. These properties and other features can be viewed in many different ways in the Metis environment to adjust varying user perspectives in diverge domains like healthcare. The treatment activity of a clinical process can be zoomed in as [Fig. 3] which brings up its sub activities and relationships to others. Due to space restrictions we have not included all relevant screen layouts of each step for the case discussed here. However with our experiences in metamodeling on Metis, we can claim, development of process centric ontology for health care in an environment like Metis has several benefits. Among them, patient-friendly organisation, navigation, and tackling with complex and diverse information to achieve interoperability are prominent. 4