A Modular Multipurpose, Parameter Centered Electronic Health Record Architecture

Health Information Technology is playing a key role in healthcare. Specifically, the use of electronic health records has been found to bring about most significant improvements in healthcare quality, mainly as relates to patient management, healthcare delivery and research support. Health record systems adoption has been promoted in many countries to support efficient, high quality integrated healthcare. The objective of this work is the implementation of an Electronic Health Record system based on a relational database. The system architecture is modular and based on the concentration of specific pathology related parameters in one module, therefore the system can be easily applied to different pathologies. Several examples of its application are described. It is intended to extend the system integrating genomic data.


Introduction
This paper is an extension of work originally presented in IEEE 4th International Forum on Research and Technology for Society and Industry [1] The collection of health information for patient data management including patient characteristics, treatments and outcomes has been over the years a most important aspect of health care [2,3]. EHRs, which replace paper medical records to collect people's health information, integrate different and heterogeneous data and are one of the most widely used Health Information Technology (HIT) tools. HIT contributes to the improvement of quality of care, to patient's safety and to the reduction of health care costs by making available accurate documentation and rapid information retrieval and management. The adoption of EHRs has been promoted in many countries, both at government level an in the private sector, even though their adoption is still rather limited, mostly because of standardization, certification, security and privacy aspects and concerns. The adoption of standard based EHR systems has been found to be able to reduce spending for healthcare to a great extent [4]. EHRs can improve patient care and safe practice, however potential risks related to medical error, systems failure, and security and legal responsibility aspects should be considered, identifying barriers for EHRs adoption and ways to address them [5][6][7][8][9]. Moreover, organizational and human factors can promote or hamper the adoption of a EHR [10]. Further relevant aspects of EHRs are interfaces with other information systems, that should be based on standard formats, such as Health Level 7 Clinical Document Architecture (HL7 CDA), HL7 Version 3, openEHR and on controlled vocabularies such as Logical Observation Identifiers Names and Codes (LOINC), "International Classification of Diseases (ICD), Systematized Nomenclature of Medicine (SNOMED) and others [11]. The need for generic and interoperable EHRs has been recognized, specially as relates to interoperability, for the preservation of clinical information across heterogeneous systems [12]. Standards are needed to implement interoperability between systems.
An EHR system contains quantitative data (clinical data), qualitative data (text documents), and medication records. The related amount of data is rapidly expanding, and big data technology is going to play a key role in this respect, specially as relates to natural language processing, clinical decision support, integration of genomics and system biology with EHR data, knowledge dissemination and interaction with patients [13].
The set of requirements that must be met by EHR systems is defined by ISO 18308:2011. According to this standard the scope of the EHR is regarded as broader than documentation, prevention and treatment of illnesses. ISO 18308 relates to shared EHR information and to the EHR system aspects that may be used for the support and coordination of patient-centred continuity of care. An EHR system includes data repositories, directory services, ASTESJ ISSN: 2415-6698 knowledge services containing terminological system, care pathways and workflows, user applications and other modules and services. An EHR architecture can be classified according to a data approach, a concepts approach and a process/service approach. These approaches are present in existing systems and in specific domain languages and modelling languages [14]. A medical record system has been developed, adopting the three approaches above. The medical record system that has been developed is based on Health Level 7 (HL7) standard and can be easily tailored to the needs of different clinical wards. The use of this standard allows the system to support interoperability between the main components of the Hospital Information System (HIS), such as the Laboratory Information System (LIS) and the Pharmaceutical Information System (PIS), and can be easily extended for example to the radiology information system (RIS) and to the picture archiving and communication system (PACS). A Service Oriented Architecture (SOA) has been adopted, that can be defined as an open extensible, composable architecture based on autonomous, interoperable and reusable services, implemented as a Web services [15]. SOA has been employed in healthcare after adoption in other sectors, such as banking, transport and industrial automation [16]. SOA is widely used for real time implementation in large distributed systems, mostly because it supports the easy integration of new software within the existing one, reducing the impact on service users and cost [17][18][19][20]. Moreover, the SOA paradigm has been successfully implemented in the design of several distributed healthcare systems [21][22][23].

Materials and Methods
The system has been implemented taking into account the specific needs of different departments of the San Martino hospital in Genoa (Italy).
The workflow relating to a visit includes the identification of the patient through the information already present in the HIS obtained by a pseudo-anonym code according to the specifications of UE General Data Protection Regulation, (GDPR) [24]. The information on laboratory analyses is obtained by query of the hospital LIS and the information on therapies is obtained by query of the PIS of the hospital. The data are stored on different platforms which do not interact with each other, therefore its direct use is cumbersome and with possible misunderstandings. In order to address this problem, a system based on a relational database developed with Microsoft SQL Server 2017 has been set up, which has made it possible to create a consistent and logical representation of the information. It is worth noting that, in order to achieve GDPR compliance, the data in the database are stored by pseudo-anonymization techniques. A pseudo-anonymous code is used to query the database, in a secure fashion. The information relating to the identity of the patient is present only at the physician interface level, after authentication [23].
The database has been designed developing a conceptual model of the data, abstracting relevant aspects of the activities and processes relating to patient management. A conceptual model is a set of rules and conventions that allows to move from a reality of interest to a conceptual scheme of the data. The model has been divided into three levels that represent respectively the protagonists of the project (level 0), the clinical event (level 1), and the format of the parameters and results (level 2).
In level 0 the main actors and features of the project have been considered, defining the fundamental entities and the relationships among them. The Entity-Relation (E-R) diagram shows the general logistical aspects of the platform ( Figure 1). Patients are followed up and subsequently entered into the database by the operators. Both patients and operators are linked to the centres involved in each clinical study. Each operator may be authorised to access more than one clinical study, and each patient can be involved in more than one study. Moreover, the clinical events relating to each patient may take place in different centres (the latter aspect being of fundamental importance, since different centres may use different units of measurement and ranges of normality). Each study may consider more than one clinical event, some of which may be common to those of other studies, while others may be specific to certain studies only.  Figure 2) shows the metadescriptive approach that has been adopted to manage clinical events and make the database structure as simple and general as possible. The main element is the definition of different Event Types. Within the conceptual definition of systems implemented with E-R diagrams [25], attributes are the elements that describe in detail the characteristics of entities and relationships. By transforming E-R diagrams with relational logic schemes, these attributes become columns of tables in databases. This approach, if applied to our case, binds the set of elements considered in a medical record (which happens in many third-party applications), blocking it in the data base (DB) construction. When developing the system, it has been chosen to store the names of the elements that are regarded as rows of the table (called "parameters"). Another table (called "categories") has been categorized, and related with the clinical reality through the links in the table that derive from the relation shown in in figure 2 (diamond "considered aspect divided by"). This choice allows to use the same DB and the same software for several tables and to easily characterize the individual parameters in a strong semantic way (using international codes such as -LOINC -ICD -... ). This greatly helps interoperability.
The most important aspects have been divided into different "Categories". These are "containers" of parameters, homogeneous from the conceptual point of view, but not necessarily homogeneous from a data format point of view (for example, a clinical event of the "Therapy" type has a "Therapy information" category, including parameters such as "Adherence" and "Therapy start date"). Each clinical event has Results, which are the values of the parameters of that particular event.
Events are grouped into types. Parameters are also grouped into types, which are translated and mapped in LOINC using standardized dictionaries, in order to support data reuse.  (Figure 3) takes into account the fact that all parameters stored in the database have their own units of measurement and range of normality, but these units and ranges are different for each centre that may be involved in the network. This is of fundamental importance for the work carried out by the physician. In the transition from the conceptual scheme to the logical scheme, great attention has been paid to this aspect, in order to allow each user to work with the tools that are most familiar to him/her. Moreover, the differences between the units of measurement have been taken into account in the data extraction algorithm. All records relating to a single parameter are converted into a standard unit of measurement, defined by the users as the ones which are most widely used. The implementation, including the creation of a web client and a web service, has been carried out in Visual Basic .NET using Microsoft Visual Studio 2015 software.
The system architecture has been designed with special reference to interoperability, according to HL7 in the HSSP (Healthcare Services Specification Project). The HSSP, started in 2005 by HL7, focuses on standard software services for healthcare, enabling the use of SOA, which has been recognised as extremely useful for interoperability, code reuse and new needs response [26]. Standards service interfaces for infrastructure reuse capability and specific health facility were considered providing a methodology for the implementation of relevant services [27].
Specifically, the HL7 Clinical Document Architecture (CDA) has been used for the encapsulation of clinical data that can be easily exchanged between applications, retaining their semantic significance [28].
Clinical parameters are associated differently with specific names and internal codes in different hospital and/or health centres. In order to allow the communication among different centres, the codes used by different hospitals/centres have been translated into LOINC language with regard to clinical trials [29], international Anatomical Therapeutic Chemical Classification System (ATC), national Marketing Authorisation (AIC) for drugs, International Classification of Diseases 9 th version (ICD9) for diagnosis and ISO Country 3166-1 for the classification of the country of origin of patients.
The "San Martino" hospital in Genoa is equipped with a network infrastructure made of two Local Area Networks (LANs) that are not connected to each other (the hospital LAN and the university LAN). Specifically, the parts of the HIS are placed in the hospital LAN, which is not accessible from external networks for security reasons, because of the hospital firewall. The access to data and to the required information is granted by a virtual private network (VPN), capable to securely connect the two LANs, allowing access for clients belonging to the university network.
The original data are sent through the VPN and, by tunnelling protocols and advanced encryption, are secured by a protective barrier before they are shipped over a potentially dangerous infrastructure such as the Internet. Tunnelling is a multi-protocol (IPsec) data encapsulation process within another IP packet that is shipped over the network. In order to transmit the data to authorized end recipients only, the data are packaged twice by a specific authentication system in which access levels depend on user role.
The strong modularity of the system allows to use the general structure described above for different diseases. The system has so far been used for the implementation of the EHR for the Ligurian HIV network [30][31][32], for ophthalmology [33,34] and for infectious diseases [35]. For each of these cases, different clinical events, parameter categories and parameters have been implemented in order to provide a tool which is very suited to the specific needs of physicians and caregivers. Table 1 and table 2 show, respectively, the clinical events and the categories of parameters for the three scenarios.

Results
The system that has being developed is hosted in Genoa university network. The user interface of the system is divided into several parts, each concerning a specific section of the medical visit. The EHR system is managed through a web interface that, for security reason, can only be accessed within the Genoese hospital and university LANs. The system interaction with the physician or caregiver takes place as follows. When the user logs in he/she is redirected to the page relating to the specific patient selection and the examination starts. After obtaining access permission, the caregiver can either manually enter the data of a new patient or see the data for a patient who is already present in the data base.
For a new entry, the related information is retrieved from the hospital databases and, after translation into LOINC, is stored in the EHR system database. The clinical parameters are retrieved from the LIS and the information on the laboratory tests is stored by an array of CDA which is sent to the web service which stores it in the system database.
A section of the clinical diary allows physicians to inspect the exams that are available for each patient. The physician can see all specific visits, their dates and parameters. The information for each clinical event is retrieved and updated by algorithms that taking into account the ethical committee permissions.
The creation of the web pages for user interface is also guided by the structure of the DB, i.e. a page is formed for each event, within which all parameters related to that event are presented. The type of value for each parameter (integer, real, list or free text, date) automatically inserts the selection of the most suitable input tool for that type (textbox, dropdown list, calendar, ...). The measurement units for the numerical parameters and the normal ranges also (possibly linked to the patient's personal data, age, sex, height, weight) are also automatically inserted.

Discussion and Conclusions
An EHR system has been set up in order to meet the needs of medical and clinical personnel. The main aspects that have been considered relate to the management of visits and to the setting up of a clinical diary according to the standards currently in use.
The objectives of the study have been met as shown in table 3, in which the system's application to maculopathies, HIV, and tuberculosis are described. Specifically, for the three pathologies the table shows the initial year, the numbers of patients which have been recorded, the numbers of related parameters, the number of events and the number of values that have been stored. The last column, named "session", shows the number of days in which an operator queries an EHR.
The system aims to simplify physician's, nurses' and caregiver's work for administration and management of treatment and follow-up. Moreover, it aims to support multicentric tracking for patients who are treated in several hospital facilities and the conduction of clinical trials. The system was set up focusing on parameters and parameter types, grouping them in one specific module. This facilitates the use of the system for different pathologies, because the pathology related data are in one module per pathology. The use of one single section for the management of different pathologies allows for easy use by different departments of one hospital and by different hospitals. This design choice also facilitates data reuse.
The main problems and limitation that have been encountered relate to data availability, because of data anonymity requirements for security and privacy. In the first place, this problem has been circumvented requiring the hospital to make the data pseudoanonym, while keeping the link between the pseudo anonym code and the patient identity separate from the data and managed by the hospital system only, on physically separated platform. Moreover, the data which are copied onto the EHR system platform are encrypted by up to date techniques which protect them from attacks. Therefore, even if the data were red this would not provide any useful information It is intended to evaluate the system performance by questionnaires addressing usability by physician, nurses and care giver.
Further developments mostly relate to the integration of genomic data in the system [36,37]. This aspect is becoming increasingly important and the parameter focused architecture of the system is suitable in this respect. The integration of genotype and phenotype information in the EHR and the insertion of genomic information in clinical workflows would facilitate the planning, administration and evaluation of genetically enabled care.