An Interoperable Electronic Health Record System for Clinical Cardiology

Abstract

Currently in hospitals, there are several separate information systems that manage, very often autonomously, the patient’s personal, clinical and diagnostic data. An electronic health record system has been specifically developed for a cardiology ward and it has been designed “ab initio” to be fully integrated into the hospital information system and to exchange data with the regional health information infrastructure. All documents have been given as Health Level 7 (HL7) clinical document architecture and messages are sent as HL7-Version 2 (V2) and/or HL7 Fast Healthcare Interoperability Resources (FHIR). Specific decision support sections for specific aspects have also been included. The system has been used for more than three years with a good level of satisfaction by the users. In the future, the system can be the basis for secondary use for clinical studies, further decision support systems and clinical trials.

1. Introduction

Healthcare is currently changing, focusing on prevention and early diagnosis, primary care, home care and continuity of care. This requires the availability of a wide range of knowledge and tools to improve various aspects of the professional activity of doctors; among these, they also contribute to the achievement of an optimal diagnosis and therapeutic decisions. One such tool is the electronic health record (EHR), which represents an essential technology for healthcare [1].

The use of information and communication technologies for health is being increasingly adopted globally. In 2005, the World Health Assembly invited member states to consider setting up long term strategic plans for the development and implementation of e-Health services and to develop suitable infrastructures. Since then, more than 120 member states have developed strategies and polices in this respect [2].

In 2013, a resolution on e-Health standardization and interoperability was adopted, which invited member states to develop policies and legislative mechanisms for national e-Health strategies, and in 2020, the global strategy on digital health 2020–2025 was endorsed, which set up a framework to advance digital health globally and within countries [2].

Electronic medical records (EMR) were the first electronic sources that were used to digitize patient information, and became popular because of their additional benefits that are not present in paper charts, such as the ability to easily collate and track information, monitor changes in patients after the implementation of new procedures and determine which patients should receive physical exams and procedures [3].

EMRs have been found to significantly improve the quality of care and to have significant economic advantages. EHRs have been found to further increase the quality of patients’ care [3].

While traditional patient records have been illness focused, healthcare is now encouraged to focus on the continuum of health and healthcare from wellness to illness and recovery, and EHRs will increasingly carry a greater portion of a person health-related information, including images electrophysiologic monitoring and genomic information [4]. EHRs have the advantage of availability of information, entry controls and capability, increase in data quality by validity checks and conditional data entry, depending on the value of the other data [5]. Relevant benefits of care quality have been found, and, in addition to clinical care outcomes, EHR systems have been found to affect the costs and efficiency of healthcare systems [6].

The adoption of EHR systems automates data management, simplifies the clinician’s workflow and supports care related activities, integrating data for different purposes, such as treatment effectiveness analysis, adverse condition reporting, research and administrative aspects. The foreseeable widespread adoption of EHRs can improve quality, safety and efficiency in healthcare, even though several challenges still need to be overcome. Moreover, EHR systems, which have been increasingly implemented everywhere, represent a vast data resource for biomedical research and clinical care [7,8]. The secondary use of EHRs has been carried out for many areas, such as in cardiology [9,10,11,12], oncology [13,14,15,16], ophthalmology [17,18,19], rheumatology [20,21], and others.

Enhanced standardization can bring about significant improvements in healthcare [22].

The standardization of medical information is receiving increasing attention, due to the need of sharing, exchanging, storying and querying of patient data among hospitals, health departments, health centres, physician’s offices, laboratories and the patients. In order to support the development of interoperable and reliable medical systems, several medical standards are used, mainly developed by Health Level 7 (HL7), such as Clinical Document Architecture (CDA) [23], Fast Healthcare Interoperability Resources (FHIR) [24] and others. HL7 has introduced different medical standards in the healthcare industry since 1987, and mainly focuses on patient management (admission, discharge and transfer of patients, taking into account finance management, medical documentation, record maintenance, medication and treatment, scheduling and resource management [25]. In 2011, HL7 introduced FHIR, which extends the previous HL7 specifications by modern web technologies. The basic building blocks of FHIR are generic definitions of common healthcare concepts (such as patient, practitioner, observation etc.), which can be exchanged in eXtensible Markup Language (XML) or JavaScript Object Notation (JSON) format and are intended to cover typical use cases [26]. Since its introduction, FHIR is being increasingly adopted and it is regarded as an emerging standard for health data exchange in many domains, including EHRs.

Currently in hospitals, there are several separate information systems that manage, very often autonomously, the patient’s personal, clinical and diagnostic data. The main ones are the management of one booking centre, the hospitalization management, the picture archiving and communication system (PACS) and the radiological information system (RIS). Sharing information among these systems and interoperability are needed.

An EHR system has been specifically developed for a cardiology ward and has been designed “ab initio” to be fully integrated into the hospital information system (HIS) and to exchange data with the regional health information infrastructure (RHII).

The main aim of the project is to design, produce, deploy and test a new modular electronic health record system (EHRS) to be used in the cardiological wards of some local hospitals. The main objective has been to replace the paper-based system, which was previously used for a long time in the two hospitals with an EHRS, while retaining staff reliance. Further aims relate to the following aspects:

• Therapy: the hospital’s expressed requirements were related to ensuring the identity of the prescribing doctor, the prescribed drug, the administering nurse and to confirm the occurred administration with a high certainty level;
• Referrals: the expressed requirements of the hospital were related to the availability on the same platform of results of examinations and diagnostics carried out on other platforms;
• Discharge letter: the hospital required that the main data stored during hospitalization were easily transferable to the discharge letter, which must be produced according to the standards indicated by the Italian Government.

A description of the system architecture and of the standards is given in the Material and Methods section. A description of the cardiology EHR system (CEHRS) modules, of the interoperability tools, of the decision support tools, of the emergency system and of practical implications of the system is given in the Results section. A comparison of the features of CEHRS with features of other systems described in the literature is given in the Discussion section. A comparison between the objectives and results and future research directions are provided in the Conclusion section.

2. Materials and Methods

The chosen architecture of the EHRS is based on central/federated databases (one per hospital) and an interactive web-based platform. The database has been developed using Microsoft SQL Server as the data base management system, implemented with Visual Studio, through.NET framework and deployed on the internet information system.

One of the main requirements for the whole project is to be integrated with both the HIS and with the RHII.

A corporate/regional/national health information infrastructure (HII) is intended to provide timely health information and to facilitate communication between people involved in the health sector. Healthcare professionals and public health professionals are the primary users of HII, and applications that meet their needs are important components of the infrastructure. To ensure interoperability, HII uses standards, and integrates systems, applications and technologies that support personalized health services through the effective integration of information from information sources on the web.

Due to historical and cultural reasons, it was decided that healthcare in Italy is directly managed by regions and the National/Governmental level has only a weak coordination role. In this complex scenario, each Italian region developed its own HII, but they agreed on an institutional centred approach for its architecture, such as the one presented in Figure 1.

As the records are not centrally stored, at least one central index is needed, from which the information for a particular patient can be extracted. When the patient data are requested, the index is used to query the repository where the stored information is located. The answers to these questions are then assembled (in real time) to produce the complete patient record data. After examining the patient, the new data are entered into the physician’s EHR system.

This paper presents an architecture that has been developed to integrate a routinely used cardiological EHR system into the RHII system present in the Liguria region. According to the rules by the Italian Government [27], all documents of the RHII should be given as HL7 CDA and messages should be sent as HL7-Version 2 (V2) and/or HL7 Fast Healthcare Interoperability Resources (FHIR). Therefore, all external interfaces of the CEHRS have been designed and developed according to a service oriented approach (SOA) based on Healthcare Services Specification Project (HSSP) that use CDA, V2 and FHIR as the semantic signifier [8]. In order to obtain a fully interoperable system at all levels defined by the Clinical Data Interchange Standards Consortium (CDISC), the CEHRS can be interfaced also with a terminology service [28].

This CEHRS has been adopted and is currently used in two hospitals (Villa Scassi (VS) since December 2018 and Padre Antero Micone (PAM) since May 2021) in Genoa and they are part of the Liguria region healthcare system.

3. Results

Both VS and PAM hospital cardiology wards have three main sections, which are as follows: the intensive coronary care unit (ICCU), in which vital functions are supported and constantly monitored, the post-intensive care unit, for patients who survive critical illness and intensive care, and the day hospital, which patients attend for daily assessment, treatment or rehabilitation.

3.1. Description of the CEHRS Modules

A global scheme of the presented CEHRS is shown in Figure 2. In the following, we report a short explanation for each module in the picture that can be accessed from each of the sections described above.

Clinical history. This section has the following four subsections: anamnesis, risk factors, allergies, admission reason. The anamnesis subsection is composed of the past anamnesis, the recent anamnesis and the previous therapy, which are free text fields. The risk factors subsection considers dyslipidaemia, hypertension, familiarity, diabetes, smoke, renal failure and liver failure. A list of possible values is provided for each of these parameters. The allergies subsection relates to drug allergies and to other allergies and intolerances. A predefined list is provided and further information can be included in a free text field. The admission reason subsection summarizes the pathologies that caused the patient’s admission, which is very important information for clinical, legal and administrative purposes. This information is included in a free text field. Considering the frequent re-hospitalizations of patients in this type of wards, the system automatically presents the previous content of these sub-sections if available. These contents are modifiable if necessary. For previous admissions, it is possible to inherit fields that are not usually changed. This section can be modified by physicians. Nurses have read-only access rights.

Physical examination. This section contains the diagnostic manoeuvres that are carried out in order to ascertain the presence or absence of deviations from the physiological normality condition of the patient. It is divided into categories according to the body district (general, abdomen, cardiovascular system etc.). Each category contains a list of parameters with predefined values, and it is possible to add free text to describe cases apart from the list of parameters. A multiple choice and binary choice question structure has been adopted. This choice supports standardization, but it requires a compromise between completeness and effective visualization. This section can be modified by physicians. Nurses have read-only access rights.

Therapy management. This section has the following five subsections: the hourly therapy, the oxygen therapy, the infusion therapy, the unscheduled therapy and the therapy administration. The hourly therapy scheme requires in the first place the identification of the prescribed drug by its commercial name, weight, active ingredient and pharmaceutical form. The insertion of the name of the drug is supported by a completion tool that draws from the list of drugs provided by the Liguria region. The identification is based on the Italian pharmaceutical identification system (AIC), according to the RHII rules. The therapy administration class diagram is shown in Figure 3.

The oxygen therapy subsection allows the physician to choose the operating modes and the related parameters. A prescription support procedure has been set up with a set of predefined prescription set-ups parametrized to patient data (such as weight and body mass index). The infusion therapy subsection shows the combinations of suitable drugs. When the combination is chosen, the physician can choose some parameters. The other parameters are calculated according to the guidelines. In the three subsections above, some tools are available to support fast prescription repetition, with explicit confirmation for each day. In the unscheduled therapy subsection, a fast drag search tool is available for one-time prescriptions. In all these prescription subsections, nurses have read-only access rights. The last subsection is devoted to drug administration. This subsection contains tools for fast and safe therapy identification and for the annotation of drug administration related events. In this section, physicians have read-only access rights.

Clinical diary. In this section, physicians and nurses can describe significant events by free text. When questioned, this section shows the author of each annotation, the changes and the compilation timing. Nurses have read-only access rights.

Nursing diary. This section is similar to the clinical diary section, but it relates to the nursing treatment. Physicians have read-only access rights.

Requests for exams. This section contains an order entry tool for physical examinations and a communication tool to exchange physical examination related information among staff. This section can be modified by physicians. Nurses have read-only access rights.

Medical deliveries. This section is similar to the clinical diary section, but it is less structured and contains information for physicians that take over in hospital shifts. The information is recorded as free text.

Hospital discharge letter. This section allows the physician to write the discharge letter as a collection of required and optional fields. These fields are free text, but specific algorithms described in the following sections have been implemented to support hospital discharge letter drafting.

Closed hospital admissions. This section allows the user to perform searches within the admission lists in which the patients have been discharged or are dead. The physician can view all the data related to the required hospitalization. This option is useful for new hospitalizations of the same patient or other similar cases.

3.2. Interoperability TOOLS

As mentioned in the Materials and Methods section, one of the main aims of the hospital management was to obtain interoperability of CHRS with the other tools in the HIS. All main interfaces of the CEHRS are shown in Figure 4.

3.2.1. Authentication and Authorization Procedure

The CEHRS has been designed according to the role base access control (RBAC) principles. The access and role attribution are controlled by an external authorization system (EAS), developed according to the Lightweight Directory Access Protocol (LDAP). The CEHRS exchanges credentials and authorization certificates with EAS with strict temporary limits to avoid unauthorized access.

3.2.2. Admission management system

Both hospitals share a general-purpose software for the management of patient admissions discharge and transfer (ADT) events. This software points out the occurrence of each ADT event by an HL7 V2 ADT Message. The CEHRS includes a web service that receives such messages, interprets them and, if the event involves the cardiologic ward, changes the internal patient list according to the ADT message (Figure 5 and Figure 6).

3.2.3. Report Management System

Both hospitals and other health care facilities in Genoa share a PACS/RIS to store images, signals and diagnostic reports. The CEHRS has to interface with this PACS/RIS to ensure this information is available on the ward. This interface has been developed within this project according to the retrieve, locate and update service (RLUS) specifications [29].

Two temporal interface sequences are described in the following section.

The first sequence is organized as follows (Figure 7).

−

The user chooses the patient whose reports he/she wants to visualize. This is the “trigger event”, which is used by the HL7 environment to start the process that retrieves the requested information.

−

The fiscal code (FC) of the patient is transmitted to the RLUS service by a FHIR message (FC is used in Italy as a unique identifier of Italian citizens; in this context, only communications protected by the HIS firewall are allowed to use FCs). The RIS provides the list of all available reports for each patient to the RLUS service by a FHIR message and the RLUS sends the list of exams to the CEHRS.

The HL7 message for the retrieval of the FC through RLUS is shown in Figure 8. The interface looks for the diagnostic report list using a “search by criteria” procedure that is set to a filter where the Boolean expression is the comparison of all available FCs with the selected FC.

The second temporal sequence is organized as follows (Figure 9).

−

The user chooses the report he/she requires.

−

The metadata of the report are transferred to the RIS by the RLUS service, and subsequently by the CDA service, which finds the report and sends it to the CEHRS.

CDA is formatted according to the Italian Implementation Guide for diagnostic reports.

3.2.4. HDL Management System

When a patient is discharged, the hospital must produce an HDL, that is, the mail document, summarizing the events during the hospitalization and providing indications for the treatment of the patient in the follow-up. The HDL must be stored in the HIS and also sent to the REHRS as the CDA.

The CEHRS enables physicians to write the HDLs starting from all the relevant information, collected in a semi-automatic way. When the HDL is completed, CEHRS implements the CDA (according to the Italian Implementation Guide for HDL), communicates with the digital signature system to produce a HDL signed CDA and sends it the RLUS, which splits it into fields that are included in the HIS. The signed CDA is also sent to the REHRS to ensure it is available for the patient’s follow up (Figure 10).

3.3. Description of the Decision Support Tools

During the routine use of the EHRS, the physicians requested support for some procedures that could be improved using specific artificial intelligence algorithms.

The knowledge required for these algorithms has been obtained from direct interaction with physicians of the wards and from cardiology guidelines [28,29,30,31,32,33,34]. For the management of these guidelines, we used the Guideline Interchange Format (GLIF), which is a language for the structured representation of clinical guidelines. The GLIF editor, developed by Medical Objects, has been used to draw the logical flux used in these decision support tools with the contributions by the physicians of the ward. Patients’ states, decisions, actions, and the related links have been also described in a computer interpretable way using the GLIF editor. To embed automatic decision steps, scripts in the GELLO language [30] have been used. Moreover, generalized data, extracted by grouping procedures within the real CEHRS database, have been used to set up a virtual medical record (VMR) for each patient.

The main decision support tools that have been developed are described in the following.

3.3.1. Therapy administration

The oxygen and infusion therapy administration are supported by a rule-based algorithm. Specifically, for the oxygen therapy, when a complex mask is needed (for example, the VentuMask [31]), the physician has to define a minimum set of fundamental parameters (for example, the fraction of oxygen in the inspired gas mixture and the positive end-expiratory pressure) and all other parameters are calculated from the patient parameters according to clinical guidelines. Similarly, for the infusion therapy, the physician has to select the drug, to define its amount and the delivery rate and all other parameters (concentration, velocity, end of treatment time, etc.) are calculated starting from the patients’ features extracted from the personalized VMR interpreted according to GELLO structured guidelines.

3.3.2. HDL Drafting

The HDL is a key document for the follow-up of the patient after hospitalization, but in many cases, it suffers due to the limited time that can be devoted to it. The highly detailed analytical structure of the data stored in the CEHRS allows for an in-depth analysis of the data collected during hospitalization. The results of this analysis are transmitted to a rule-based algorithm, which precompiles some free text areas of the HLD using an ensemble of pre-defined sentences that are suitable for the features of the patients. The physician has to read, modify if necessary and confirm acceptance. Acceptance by the physician implies his/her taking on responsibility, confirmed by his/her digital signature. The HDL management process continues as described in Section 3.2.

3.4. Emergency System

An emergency system has been developed to overcome the servers’ failures. The system’s architecture is shown in Figure 11.

The Windows Server 1, which is the main server in which the CEHRS is located, is connected with the data server, the clients and with another server.

During the normal operation, Server 1 stores the state of the clinical record of each patient as a PDF file in a directory that is shared by a web interface, which is managed by Server 2. The files are updated every four hours. If a Server 1 malfunction occurs, users can use the shared files in the directory, which resides in Server 2.

This architecture has been chosen in order to duplicate the hardware and, therefore, halve the probability to have both servers out of service at the same time. Moreover, Server 2 includes all the necessary resources and, therefore, does not need any connection in order to properly function. This makes it more robust than Server 1.

3.5. Practical Implications of the System

An informal survey that has been conducted in the two hospitals shows that using EHRs has improved patient management according to 75% of physicians and 60% of nurses in VS hospital, and according to 65% of physicians and 45% of nurses in PAM hospital. It is thought that the difference between the two hospitals is probably due to the fact that in PAM hospital, the use of the EHR is more recent; therefore, the lower satisfaction is a consequence of the fact that familiarity with EHR is still rather low. For both hospitals, the tool that was mostly appreciated by physicians was the software supporting the HDL preparation (90% in VS hospital, 75% in PAM hospital). Further surveys will be proposed in the future to check the satisfaction trend.

A further aspect that has been regarded as very useful by physicians is sharing data between the two hospitals, which significantly reduces anamnesis time when the same patient is admitted at different times in the two hospitals (90% in VS hospital, 75% in PAM hospital).

Nurses especially appreciated the possibility of quickly recording missed therapy administrations and its causes (75% in VS hospital, 60% in PAM hospital).

4. Discussion

At the start of the setting up of the HEHRS, the record system of the cardiology wards was completely paper based, but, in connection with the adoption of the REHRS, the staff reckoned that it was necessary to set up an EHR that could be integrated into it, in order to avoid setting up procedures on a paper record first and subsequently converting them to a digital format for the REHRS.

This work has taken into account the specific needs of the cardiology staff with regard to storage stability and responsibility attribution, while retaining the confidence of the staff in the paper-based system, which had been used for many years. The system that has been set up satisfies these needs using the data base systems and the authentication systems of both hospitals. The design features of the EHR guarantee both the storage stability and responsibility attribution and for any stored information, the staff member who stored or modified or cancelled it can be known. These features have been obtained by an architecture that closely resembles the one in [5] and that is commonly adopted in many EHRs (also commercial) that are being used in many hospitals. An additional need was interoperability with other hospitals and local medical informatics applications, a feature that is present only to a small extent in commercial EHRs [32]. For this reason, it was decided that a EHR would be set up from scratch rather than using already available material. The system modules relating to interoperability are based on HL7 and FHIR standards, as described in the previous sections. With regard to the objectives described in the Introduction section (therapy, referrals and discharge letters), all the commercial systems are already adapted to the first point. For the second and third point, the use of standards has been crucial. Our system is highly efficient compared to other commercial systems.

Information security aspects have not been described in detail because, in accordance with the Italian national and regional legislative constraints, the security management has been completely delegated to the systems that have been set up by the two hospitals and by the regional infrastructure to which they belong (see Appendix A).

Access to personal, sensitive and ultra-sensitive data, which are present in the administration software, is strictly compliant with national and European Union regulations (such as the General Data Protection Regulation on privacy, n. EU 2016/679 and the European Medical Device Regulation, n. EU 2017/745) for software such as the EHR.

This approach is rather traditional. Relevant innovative work has been recently carried out [33,34,35,36,37,38,39,40]; however, in order to apply such approaches, a legislative adjustment would be necessary. This is particularly evident in relation to blockchain systems, in which distributed data storage—a typical feature of this approach—is currently strongly countered by public administration data managers in many countries.

5. Conclusions

The development of the CEHRS started at the beginning of 2018, with a very close interaction between software developers and physicians, adopting the main criteria of the agile development methodology, which allows for quick prototyping and constant testing of the system by the users. In December 2018, the CEHRS was adopted formally on an experimental basis, but in essence, it immediately became the only software support of the ward. In October 2020, the experimental phase was completed, the CEHRS was adopted and became the only official health record of the cardiology ward. In May 2021, the CEHRS was also adopted in the cardiology ward of PAM.

In VS, 4093 admissions have been managed so far, among which 3395 patients have been hospitalized (2295 males with average age 70 and 1103 females with average age 76). In PAM, 628 admissions have been managed so far, among which 556 patients have been hospitalized (330 males with average age 73 and 226 females with average age 76).

The CEHRS also supported the cardiology ward in in VS in 2020, when it was devoted to the treatment of patients with SARS-Cov2 for several months. A total of 139 admissions and 139 hospitalized patients have been managed. This has made evident its versatility and flexibility, which enables its use in wards different from cardiology.

The use of CEHRS has enabled the cardiology wards of VS and of PAM to be included in the REHRS. It can, therefore, be concluded that, after a few years of use of CEHRS, the objectives described in the Introduction have been met.

In the future, the high analytical capacity of the CEHRS database will enable the secondary use of EHR, both for further clinical studies and for the development of further clinical decision support systems.

Another important contribution of the REHRS to the research domain is improving the efficiency of clinical trials. At present, most clinical trials require the creation of a unique information infrastructure to ensure protocol compliance and to collect essential research data. With the REHRS, every practitioner would have access to a fully functional electronic health record (EHR), so clinical trials could routinely be implemented through the dissemination of guidelines that specify the research protocol. Data collection would occur automatically while administering the protocol, reducing time and costs. In addition, there would be substantial value in analysing, de-identifying and aggregating data from routine patient care to assess the outcomes of various treatments and monitor the health of individuals or groups.

The availability of strongly structured data in connection with natural language information will, on one side, support patient management throughout the diagnostic and therapeutic process also after discharge and for any rehospitalizations, independently of the specific hospital, while on the other side, it enables its secondary use in anonymous and aggregate formats to support clinical studies.

This will also be favoured by the presence of standardized systems for the management of clinical terminology, which are spreading in Italian regions, and by the continuous adaptation to innovations related to security and interoperability, considering the evolution of legislative constraints.

Specifically, the ability to use all EHR parts based on natural language (anamnesis, clinical diary and hospital discharge letter) for research is very promising. In this respect, the interoperability features of the EHR can interface effectively with terminology management systems [41,42,43,44,45,46] and with natural language processing systems.