Today, most healthcare systems are built for the convenience of healthcare providers. Since the 1990s there has been a growing interest on involving the patient more in his or her own treatment, and in that way improve the quality of care. One of the means of doing that is to develop software that puts the patient in the centre while allowing the providers to carry on with their normal work habits. The electronic personal health record is one possible solution to this challenge. In this paper we present an implementation of the personal health record and describe how we adapted it to Norwegian standards.
The concept “Personal Health Record” (PHR) has traditionally been used to encompass systems that focus on the patients, by making it easier for them to exercise their legal rights concerning their patient records. This right includes access to the content in the record and determining who should be able to read and write in it. Additionally, the PHR offers functions that enable patients to contribute to their records and ensure better communication with healthcare providers. These functions are meant to stimulate patients’ awareness and reflection, and finally give a better quality of care. In Norway, there has recently been an increased focus on patient centred care. Several actors have come up with solutions that are either similar to, or a step towards a full-scale implementation of the PHR. The focus in this paper is on a solution from the USA called Indivo.
The rest of the paper is structured as follows: Some background information on ongoing work related to the PHR in Norway is given in Section 2; Section 3 describes the guardian angel manifest; This is followed by Section 4, which introduces an implementation of the PHR founded on the guardian angle manifesto called Indivo. In Section 5 some information about Norwegian healthcare informatics is given and we describe how Indivo is adapted to allow for the Norwegian standards. We present our conclusion and further work in Section 6.
In Norway, some work has recently focused on allowing patients access to their
health records. “MyRec” [
“WebChoice” is a project connected to “MyRec”, which focuses on cancer
patients [
In addition, the “Kjernejournal” project [
Currently, the Norwegian Research Centre of Electronic Health Records is
investigating the applicability of a PHR as a supplement to the Kjernejournal
[
The guardian angel manifest [
To improve the situation it is proposed to shift the focus away from information systems built for the convenience of the healthcare providers, and instead build systems that focus on the patients. Such a new system, called “Guardian Angel”, is meant to integrate the patient’s health related information over a lifetime. Hence, it is at a minimum supposed to contain a complete medical record of the patient, something, which is very difficult to reconstruct as the patient moves through life. Other functionalities include being able to collect patient data, check, interpret and explain medically relevant plans and facts, adapt advice based on the patients previous experiences and preferences, and monitor progress and help educate, encourage and inform the patient.
The believed advantages are: improved medical decision making, a reduction in healthcare errors, allowing persons to make better personal decisions, and improvements in effectiveness and efficiency of healthcare. Also, the healthcare providers will have access to accurate and up-to-date data, a better opportunity to discover changes in the patient’s health, and be able to communicate better with the patients.
When building a guardian angle, flexibility is an important keyword. The software has to be easy to adapt to new standards that will evolve in the future. Also, over time the understanding of requirements might change, or new functionality has to be added. Hence it is important to develop an open architecture consisting of components provided by generic and preferably standards-based facilities. 4
Indivo, which is a project at Harvard Medical School, MIT, and Children’s
Hospital Boston, is based on the guardian angel manifest [
One of the main ideas with the PHR is to enable better communication between the primary physician and patient. Indivo supports this by including support for messages. It also supports lots of other document types and new ones can easily be added due to Indivo’s flexible structure. New information can be sent to the patient from any client (e.g. an EHR system) as long as the information is sent using Indivo’s communication protocol.
Indivo can be divided into three layers: client, server and store. Each layer can be located at different physical locations, and both the client and the store are designed in a pluggable fashion such that a number of different types can be used. As most of the data processing happens in the server, this can be regarded as “heart and soul” of the architecture. Indivo implements a model-view-controller architectural pattern.
Indivo uses a communication protocol called IndivoTalk to communicate between the client and the server. This protocol is based on XML messages and request-response interaction. Adding new XML schemas and performing small modifications to the server source code can quite easily extend it.
The following subsections describe each layer of the Indivo architecture in more detail. A complementary illustration is given in Figure 1.
Client The client is the layer used to communicate with the Indivo server. As long as it uses the IndivoTalk protocol the client can be any software process regardless of the platform and implementation language.
The Indivo actor is a registered user of the system. Each user has his own record and some attributes, e.g. roles and group memberships. Each role has some privileges. For an example, a user logging in with a patient role might be allowed to update, read and add documents to his/her own record, while a user logging in with a provider role must be given privileges by the patient in order to do the same to the patient’s record.
Server The server is a Java 2 Enterprise Edition (J2EE) compliant servlet. Using the servlet technology has several advantages. The Secure Hyper Text Transfer Protocol (HTTPS) can be used for encryption of IndivoTalk messages between the client and the server. Also the manipulation of requests is simplified by using the Java Servlet Application Programming Interface (API).
The server consists of the three different main parts: The communication layer, the action response layer and the authorization module.
The communication layer is responsible for accepting XML IndivoTalk messages and converting them into program objects, which are then sent on to the action response layer. When a response arrives from the action response layer it
Fig. 1. Indivo architecture (adapted from [
The action response layer processes the actions received from the communication layer and maintains information about the different sessions. There is one action responder for each type of action, and each one of these has its own processing and authorization procedure. The layer reads several XML configuration files in order to create the different responders, and these files contain among other things information about the data store and authorization engines. It is the responsibility of the action response layer to delegate authorization to the authorization module before the request may be executed.
The authorization module is an implementation of the Extensible Access Control Markup Language (XACML). Depending on the action responder (and type of action) there are either one or two authorization steps. The first one decides whether the user is allowed to perform the type of action requested, and the second finds out whether there are any record policies that prohibit the user from performing the action. In the first case the authorization policies are read from a configuration file, while the record based policies are read from the data store. The advantage of using XACML is that it is very flexible. Store The data store contains the different records. Each record consists of several documents and each document consists of several versions. The different document types are defined with XML schema at the server, and adding new document types are easy.
Technically speaking the default store is a Berkeley Database consisting of several encrypted XML files. They are accessible to the action response layer using Java Remote Method Invocation (RMI). Encryption can occur before the data is sent from the server or at the store. One advantage of encrypting the data at the server is that the encryption key is kept separate from the encrypted data.
Other store types can replace the default store, as long as they adhere to the Indivo API, which consists of method calls that the server uses when it communicates with the store. 5
Healthcare informatics in Norway have the last few years been driven by a series of government strategic plans where the latest, Te@mwork 2007, is scheduled to end in 2007. The plans have led to large initiatives in the IT- and healthcare sector. The development of “Norsk Helsenett”, a closed network for electronic communication and cooperation in the healthcare sector, is one of the outcomes from the initiative. Another important area for the strategic plans has been standardization work. For this purpose the government formed Norwegian Centre for Informatics in Health and Social Care (KITH) in 1990. KITH contributes with coordination of the IT development in the sector. A large part of this work is development and maintenance of codes and standards. KITH also takes part in international standardization. Contemporary with the development of electronic solutions in the healthcare sector an evolving interest and concern in patient security also increases. The Data Inspectorate does evaluation of systems fulfilment for patient security and Norwegian law. A possible implementation of a personal health record could very well be problematic for the Data Inspectorate, but this is outside the scope of this article.
Implementing KITH standards within Indivo is an important step towards adapting Indivo to the Norwegian structure. This implies the employment of the content and EHR standards defined by KITH. An important part of these standards is the ability to send and receive standardized information to and from other healthcare systems, a prerequisite for a personal health record system. A key element in this information sharing is the “Hodemelding” [7] , which is based on XML. The Hodemelding is supposed to create a common message header with basic information about sender and receiver that wraps the health information documents. This therefore leads to a common interface for communication easy to implement.
Thus making Indivo able to receive a Hodemelding is an important step towards a Norwegian implementation of a PHR. Our intention was to implement support for Hodemelding without making too many modifications to the original code. Indivo uses XML for communication between the server and the client, this is done by altering the module that handles requests and responses. An illustration of the original module is given in Figure 2 and the altered module in Figure 3.
By adding a new Hodemelding JAXB context to the original IndivoTalk context the system is able to receive and unmarshall incoming XML that is based on the Hodemelding XML-scheme. Next the system does a simple instance check of the object that has been unmarshalled to find out whether it is a request from the IndivoTalk protocol or a Hodemelding. To handle the specific content of a Hodemelding and the different documents it can contain we created a new module. Functionality in this module is only used to interpret the Hodemelding, so for standard tasks like authentication and adding documents the module still utilize the native Indivo functions.
Besides handling Hodemelding the Indivo server should also be able to handle specific documents as defined by KITH. The various document content standards are defined in XML-schemas from KITH. Because Indivo also utilize XMLschemas to define its content documents, only small modifications have to be done to add new document types to the server. As an example of this we added the discharge summary [8] messages to Indivo. In addition to this we added a document called application receipt [9] used for confirmation of received messages with or without errors. This receipt is sent like any other document inside a Hodemelding, but only if the original sender requests one. In our implementation of the new module used to handle the Hodemelding the receipt is automatically generated and sent if needed.
In this we have not only added functionality to receive document, but also made changes to the kind of documents that are available in the PHR. With these rather small changes we have made the Indivo system one step closer to use in a Norwegian setting. 6
Indivo is a promising open source program that aims at creating a web-based personal health record. The fact that Indivo uses XML both in communication and configuration makes it a highly adaptable and modifiable system. At the time of writing the current version, 3.0 beta, has a PHP based user interface that will help the patient control his record. Although there currently is some difficulties installing and running Indivo, we look forward to promising future releases.
In our work with Indivo we have managed to prove its suitability as a personal health record system within a Norwegian structure. With some changes to configuration XML files and rather small changes to the implementation itself, we have made Indivo able to receive a Hodemelding, handle its content, and if needed send an application receipt in a new Hodemelding back to the sender. As a practical example we have used the Norwegian standard for a discharge summary as content for the Hodemelding and the PHR. This ability to use the Hodemelding for communication is paramount for any healthcare system used in Norway. In addition, the fact that Indivo utilize a model-view-controller architectural pattern makes it easier to add or change any logic layer.
There is still much work to be done before Indivo fully can be deployed in Norwegian healthcare. Disregarding the problems concerning legislation there are still technical challenges. Researchers at NSEP and students at the NTNU are currently involved in different aspects of the personal health record and Indivo. This consists of adopting a Norwegian document structure based on case, document and fragment, into Indivo, handling and presentation of prescriptions, and research into how to enable patients to select roles for access. 7
The authors would like to thank Hallgeir Stueness for his assistance. 7. KITH: Standard for hodemelding - informasjonsmodell og xml meldingsbeskrivelse. (http://www.kith.no/upload/3037/R01-06-Hodemelding-v12.pdf) Last visited: 27/10-2006. 8. KITH: Elektronisk utveksling av epikrise. (http://www.kith.no/upload/1075/R2602EpikriseMelding-v1.pdf) Last visited: 27/10-2006. 9. KITH: Applikasjonskvittering - informasjonsmodell og meldingsbeskrivelse. (http://www.kith.no/upload/1187/R15-04AppRec-v1.pdf) Last visited: 27/102006.