Patient Portal to access Electronic Health Record (PEHR)

Patient Portal: Electronic Health Record (PEHR) Information

Today, patients are treated by different healthcare professionals and medical specialists in varying healthcare facilities, especially when they are chronically ill. Particularly for these patients it is essential to improve inter-sectoral and cross-sectoral patient treatment. One challenge is bringing together all relevant data for medical care. The communication of healthcare facilities by using physician moderated electronic health records (EHRs) has the advantage to directly connect the primary systems of the healthcare facilities and hence makes it possible to transmit documents automatically into the HER without manual interaction. But usually the patients have no access to these records. In contrast, personal health records (PHRs) are focused on the patient, empower the patient as the owner and manager of his medical data. However, PHRs usually don’t have standardised interfaces and therefore are difficult to integrate into the environment of a clinic or regional platform.

Over the last years we stepwise implemented our vision of a personal cross- enterprise electronic health record (PEHR) in the Rhine-Neckar-Region in Germany. The PEHR architecture combines the benefits of EHRs and PHRs in one concept [1]. Therefore, a project called INFOPAT “INFOrmation technology for PATient-centred healthcare”, funded by the German Federal Ministry of Education and Research (funding code 01KQ1003B), has been initiated in the Metropolitan Rhine-Neckar-Region in Germany [2]. The project aims to improve healthcare focused on the patient in different care settings and especially for chronically ill patients.

The patient portal is the UI component for patients in the PEHR architecture, which is described in detail in [3]. Figure 1 gives a conceptual view of the underlying architecture of the PEHR. The PEHR is seen as a central communication platform between different healthcare providers and the patient himself. One of the axioms is that the patient is in control of his medical data and decides who can send data towards his medical record and who gets access to his medical data by giving his consent. The sources of data are different healthcare providers’ information systems like electronic medical records (EMR) of e.g. hospitals, general practitioners, pharmacies or other healthcare facilities. The healthcare professionals get access to the permitted medical data via the professional portal. To give patients a view of the PEHR with standardised, IHE-based interfaces to the backend “PEHR core” [4, 5], a patient portal has been developed.

The patient portal is connected to the cross-enterprise health record core with the aim to collect all relevant medical data of one patient in a regional record, to give patients the possibility to access their medical data, to manage their medical data and to provide additional data. In this article we want to give an overview of the functionalities of the patient portal as a part of the PEHR in the Rhine-Neckar-Region.

Patient Portal: Electronic Health Record (PEHR) Methods

After evaluating different technologies for the implementation of the patient portal, we decided to base on Liferay as technology platform [6, 7]. Requirements analyses with regards to the functional and non-functional requirements for a PEHR and particularly to the patient portal have been conducted [3]. Furthermore, our project partners worked out a requirements catalogue within the INFOPAT project with focus on patients suffering from colorectal cancer [8].

Currently, feasibility tests of the patient portal with patients are performed in two phases. The first phase was a pre-implementation study to get feedback for the development regarding usability and bug fixing, with given scenarios of use in laboratory conditions, participatory observation during the test with think-aloud-protocol and semi- structured interviews after the test [9]. Next, a pilot implementation in a given setting is planned to test the patient portal in productive environment with patients having gastro- intestinal cancer.

Patient Portal: Electronic Health Record (PEHR) Results

The patient portal is divided into different functional sections. Figure 2 shows the architecture of the patient portal with the modules: login, registration, consent management, medication, documents, surveys, audit and emergency contact. The connectivity of the patient portal is designed to fit into any IHE-based system architecture [5, 10].

We distinguish different user groups with different roles. Besides a mandatory administrator there are two main groups of users: the patient and the study assistant. The study assistant registers the patient in the study context of the INFOPAT project and explains to the patient the functionalities of the patient portal. Patients log in with username and password. After successful authentication the patient is led to the dashboard of the patient portal (see figure 3). This page gives an overview with information about the person logged in: name, date of birth and the last login. Furthermore, one can see whether new documents were sent to the PEHR since the last login. There is also a link to the medication platform and to the last medication plan if available. To give the patient the possibility to get more information to specific diseases, we integrated links to more information collected by our project partner within the INFOPAT project [11]. From the dashboard the patient can navigate to all other modules of the patient portal by choosing the respective tab.
The documents page shows all documents within the PEHR of the patient with the IHE document metadata. For displaying the document an in place viewer is opened. By using a filter the document list can be limited according to the selected criteria, e.g. when the document was created or added to the PEHR, the type of document or the specialty where the document was created.

Within the consent management module which is based on a model for consent based privilege management (see [12]) the patient is able to control the access to his record by giving rights to physicians to read his medical record and/or to add data to his medical record. For this purpose he first selects his healthcare provider (e.g. a department in a hospital or a general practitioner) and afterwards document classes or types (e.g. discharge letters) and puts them into a personal healthcare team. Afterwards professionals related to this team are able to access the documents within the selected document classes or types, in some cases limited to a given validity period.

As an additional application, the patient is able to manage his medication in the PEHR. Therefore we adapted and included an existing medication platform [13]. With this tool it is also possible to save a medication plan in the patients’ PEHR. The patient can get more information about his drugs and gets warnings about possible adverse drug events. For research questions (e.g. patient-reported outcomes) it is possible to generate questionnaires within the patient portal and send them to a patient or a specific study group of patients. Thus, patients can fill in the questionnaires online. Finally there is more functionality in the patient portal like adding emergency contact information. Last, to give the patient a transparent overview of which healthcare provider accessed his record or added data a UI to the IHE ATNA repository was implemented and provided to the patient.

NDIS or Aged Care Portal Information

Patient Portal: Electronic Health Record (PEHR) Discussion

The PEHR of the Rhine-Neckar-Region combines two different architectures of health- related records, EHRs and PHRs, in a unique way. Thus, the patient portal is a major instrument for managing the PEHR by the patients and to enable them carrying out their informational self-determination.

When implementing the functionalities of the patient portal it was not easy to match the requirements and interests from patients and physicians. E.g. on the one hand patients may want to delete documents with stigmatising data from their medical record. On the other hand physicians want an entire medical record to be able to treat the patient at best and don’t want information, on which they based their decision for a medical therapy, to get lost. This is why physicians may rather download a copy of important documents in their local systems as a proof in forensic issues.

Regarding the usability it is apparent that the consent management is not easy to realise. According to the so far received patient feedback, giving the patient an understanding of what he can manage and what consequences this might have is a complex endeavour. For this, an application study is currently performed and a research project is assigned to revise the functionalities and the usability of the consent management. Furthermore, the processing of the ATNA repository for the patient was difficult due to the volume of entries and the technical content. This has to be improved by representing the technical contents in a more comprehensible way.

Finally, there are additional requirements to develop. Patients for example would like to have a schedule in which they can obtain appointments from their healthcare providers automatically and functionalities for a proxy who is able to give assistance in managing his medical record. As a security requirement integrating a two-factor authentication for log in is necessary in a productive environment, but in this field a broad infrastructure is still missing. This features will be developed in future releases.

References:

Please call a Datanova Digital Business Solution Architect on 1300 552 166 and book your complimentary Webinar or alternatively send an email to Datanova. You can book a webinar straight from our booking form here and we will get back to you shortly.