Architectural Requirements and Assumptions for Serbian EHR

Transcription

1 Hospital Health Information System EU HIS Contract No. IPA/2012/ Architectural Requirements and Assumptions for Serbian EHR Final version July 2015 Visibility: Public Target Audience: EU-IHIS Stakeholders EHR System Architects EHR Developers EPR Systems Developers This document has been produced with the financial assistance of the European Union. The views expressed herein can in no way be taken to reflect the official opinion of the European Union. This project is funded by Republic of Serbia Implemented by the the European Union Ministry of Health WHO and UNOPS

2 Abbreviation List CDA CIS EPR EHR HIS HITT HIU HL7 HTTP IF IHIS IS JMBG LBO MoH NHIF NIPH PC PCC UNOPS WHO Clinical Document Architecture Central Information Service Electronic Patient Record Electronic Health Record Hospital Information System Health Information Think Tank Health Information Unit Health Level Seven International (healthcare informatics interoperability standards) Hypertext Transfer Protocol Interoperability Framework Integrated Health Information System Information System Jedinstveni matični broj građana (Serbian Unique Citizen Number) Insuree number Ministry of Health of the Republic of Serbia National Health Insurance Fund National Institute of Public Health (Institute of Public Health of Serbia Dr Milan Jovanovic-Batut ) Primary Care Primary Care Centre United Nations Office for Project Services World Health Organization EU-IHIS Šumatovačka 78-80, Beograd, Serbia /19

3 Table of Contents Introduction... 3 EHR Architecture Overview... 5 EHR Data, Usage and Management... 6 Populating and Updating of EHR Database... 9 User Authentication and Identity Management Usage of Patient Data within Healthcare Organizations Quality Analysis of EHR Data Patient Access to Their Personal EHR Data Integration with Additional Data Sources EU-IHIS Šumatovačka 78-80, Beograd, Serbia /19

4 Introduction The main goal of the Integrated Health Information System (EU-IHIS) Project is to implement and integrate hospital information system (HIS) in 19 beneficiary hospitals and link these systems with the unique Electronic Health Record (EHR) system, which would lead to increased efficiency and improved quality of patient centred healthcare. EU-IHIS Project is being carried out under the leadership of the Ministry of Health of the Republic of Serbia and financed by the Delegation of the European Union to the Republic of Serbia. World Health Organization (WHO) for Europe is in charge of the project implementation through the WHO Country office in Serbia with administrative support of the UN Office for Project Services (UNOPS). This document describes architectural requirements and assumptions for Serbian EHR. Data collections and rules are defined according to EHR data set, defined by the health information unit (HIU) and Health Information Think Thank (HITT). Electronic Health Record in the context of healthcare system in Serbia was defined by HITT as: The electronic health record (EHR) of an individual beneficiary/patient constitutes a set of longitudinal data (on a continuous, life-long basis) of key importance to health, collected and integrated from the electronic medical record, i.e., electronic patient record from various health institutions, which can then be shared with relevant health institutions and/or health professionals, for the needs of health promotion, disease prevention, diagnostics, treatment and rehabilitation of those patients. Data being collected is health and care data recorded during individual contacts between patients and healthcare professionals and over the courses of out-patient and in-patient treatments. These data include descriptors of health status, diagnoses, diagnostic results, treatments and medications etc. There are additional scenarios that may be associated with EHR but are related to actual managing of health services, such as support of e-prescription or online scheduling of appointments. They may be the subject of future EHR development and integration, but are not elaborated in this document. It should be also noted that not all described components, requirements, or user cases are necessary for the initial introduction of the EHR. The basic usage of EHR is possible with a subset of these features. The set of available features will be gradually expanded with a growing experience in EHR operation and usage. Besides the 19 hospitals defined by this project, it is expected that other external systems will be connected in the future: HIS and PCC IS in about 80 hospitals and 160 PCC and other healthcare organizations within the Serbian public healthcare system. These are the primary sources of information, all providing the data in a common standard format. Institutions that will be initially connected are EU-IHIS beneficiary hospitals. After inclusion of all state hospitals and PCCs, the system should also collect data from stand-alone laboratories, diagnostic centres, private clinics, military and other healthcare systems. NHIF Database of public health insurance beneficiaries, covering more than 90% of the population that uses the healthcare services in Serbia. CIS database at the NIPH registries of healthcare institutions and professionals. EU-IHIS Šumatovačka 78-80, Beograd, Serbia /19

5 National and international classifiers are managed by the NIPH and NHIF, but are currently only available on portals of these institutions as static, periodically updated content. EU-IHIS Šumatovačka 78-80, Beograd, Serbia /19

6 EHR Architecture Overview EHR architecture will be multilayered and that is the key element of system infrastructure. Access to EHR data will be organized through front end layer where data will be collected and processed inside back end layer. Users will access through secure communication over the Internet. Access components will be logically separated inside front end layer. This organization enables gradual introduction of components used by different data sources/users and their interaction with EHR. The system modularity will also enable the change of individual subsystems without affecting the data flow between other subsystems and users. In the same manner, the deployment of new features and functions can be done without affecting the existing functionalities of other parts of the system. Components identified as parts of the system back end are: EHR database Contains all data collected from the source systems. EHR monitoring tools enables control of data quality, functional validation, system performance and operation monitoring. Management tools enables system maintenance, setup, adjustments, security control etc. Components identified as parts of the system front end are: ID & coding systems synchronization enables synchronization of codes and classifiers used in EHR and its sources as defined through corresponding standards or rulebooks or maintained by responsible institutions, as well as personal identity and administrative data synchronization with NHIF and NIPH. Clinical systems interface Enables data exchange between EHR and systems in medical institutions. EHR reporting facility enables accessing to defined set of reports as well as reports on demand, only available to specially authorised users. May be integrated with health professional portal or provided through other suitable interface. Interfaces to other systems enable data exchange with other civil institutions concerning the additional health related data that needs to be integrated into the EHR. These sources may include NHIF databases related to healthcare delivery and civil registry data about deaths but also various public institutions such as police about traffic accidents, social institutions about domestic violence, organ donor register etc. Health professional portal enables healthcare professionals to directly view or enter data into EHR (for later development). Patient portal enables patient to see his/her own EHR record (for later development). Graphical schema of the system with the users accessing to EHR is shown in Figure 1. EU-IHIS Šumatovačka 78-80, Beograd, Serbia /19

7 EHR BACK END FRONT END ACCESS COMPONENTS USERS PUBLIC SERVICES ELECTRONIC CONSULTATION MANAGEMENT EHR DATA MANAGEMENT TOOLS INTEROPERABILITY FRAMEWORK INTERFACES TO OTHER SYSTEMS ID & CODING SYSTEMS SYNCHRONISATION EHR REPORTING PORTAL CLINICAL SYSTEMS INTERFACE HEALTH PROFESSIONAL PORTAL PATIENT PORTAL SECURE COMMUNICATION OVER THE INTERNET CIVIL REGISTRY SERVICES NHIF CIS / NIPH MoH HIS PC EPR HEALTH PROFESSIONALS PATIENTS Figure 1 - System architecture overview EHR Data, Usage and Management The EHR system is primarily patient-oriented data centric system, without extensive workflow over data collected within its primary database. Its primary usage consists in aggregation of standardized information on patient healthcare from various originating resources and later retrieval of patient related data by authorized systems. The EHR database will be used in several ways: 1. The content of the EHR database is available to the authorized users and patient and health professional portals to display and, when permitted, edit personally identifiable relevant data. Read access may be optimised by using replica(s) of the master database. 2. The EHR should support periodic and on-demand creation of standard EHR reports, including calculation of health indicators which may be directly extracted from information collected in the EHR. Again, additional replicas of the master database may be used. 3. The data excerpts from the EHR, usually anonymised or tagged with pseudo identifiers could be exported to various additional reporting databases, data warehouses or analytical tools. These tools should support ad-hoc reporting. EU-IHIS Šumatovačka 78-80, Beograd, Serbia /19

8 Evolving set of data is to be collected and maintained. Some other important data related requirements include the following: Some data will be strictly defined in terms of content, format and access rules (e.g. patient demographic data). Other information may be tied to specific classifications, sometimes also including amounts and units of measure. Types of information collected by the EHR were defined by the EU-IHIS HITT as the initial EHR data set. This data is further elaborated through Data Dictionary. As decided by the HITT, it focuses on information currently collected in Serbian healthcare institutions on a regular basis and entered into EPR systems, with emphasis on coded data. At this point, clinical documents, lab test results, and diagnostic images are not the subject of aggregation by the EHR, as they are commonly not fully integrated into the source systems, especially in PCCs. In addition, collection of information at this level of detail would require higher ICT communication capabilities than currently available to EU- IHIS beneficiary hospitals and other healthcare providers. Only patient records with a unique identification number (JMBG personal number, NHIF insuree number, identification document number) from source EPR systems can be collected by the EHR. All pre-existing patient s data should be sent to the EHR after the identification number is provided within the source system. Rules about relationship of data with pre-existing, but also emerging classifications should be defined and maintained. The primary source of EHR data are EPRs managed by connected instances of HIS and PCC IS of healthcare institutions. Data on a single patient collected from various sources should be made available to authorised users of HIS and PC EPR within healthcare institutions. The direct access of patients and healthcare professionals to EHR is needed, but it should be allowed only after EHR usability is proven in a more traditional setting and a robust large-scale identity management and access managing infrastructure is made available. Legislative rules and regulations and practice may define the sensitivity of EHR data by classifying information items into groups. Possible groups of sensitive data include HIV and viral hepatitis, mental health conditions, substance abuse and sexual and domestic violence (corresponding to HL7 sensitive data groups). Assignment of sensitivity is to be done upon classification of circumstances related to diagnoses (such as alternative lifestyle, sexual and domestic violence or substance abuse), as well as at the level of classifiers used for diagnoses, treatments, medications and health institutions/units (in case of HIV and viral hepatitis and mental health conditions). In future, if so regulated, access to particularly sensitive data groups may be restricted depending on user roles. Some items could become irrelevant after some predefined or explicitly specified period of time, so presentation of data may be constrained by default or explicit time intervals. Each data item (or inseparable group of items) must be associated with corresponding health institution, health worker (possibly only in terms of responsibility for validity, while the EPR systems may also track other persons performing data entry) and versioned, so that changes of data could be tracked. EU-IHIS Šumatovačka 78-80, Beograd, Serbia /19

9 Data creation, update, logical deletion and access must be logged. All logged records must contain information about significant timestamps (date and time of change, date and time of record creation) and source systems reporting changes. Creation of a patient record in the EHR is allowed if the patient is not already registered in the EHR, i.e., no previous record exists is the EHR system based on the patient's unique identification numbers. At the initial phase of the project (when HIS are to be connected to the EHR, not PC EPRs), only the HIS of the healthcare institution that firstly recorded a patient in the EHR has right to add/modify the administrative data of the patient. Once PC EPRs are connected to the EHR system, only chosen doctor and certified state institutions (NHIF, civil registry etc.) will be authorized to change personal and administrative data based on official valid documents. However, the source system which initially created the patient s administrative data could update such data until it has been updated by the chosen doctor or certified institution. Source systems will send data in the form of structured or non-structured documents based on standard formats for data exchange (for example HL7 CDA). Documents received from source institutions will be stored in its original form inside the Document Repository, which is a component of the Interoperability Framework. Data from the document will be extracted and saved in EHR database, being available for healthcare professionals accessing to patient s EHR. Documents sent by source institutions can be queried in Document Registry and retrieved later directly from the Document Repository in their original state. Documents saved in registry can later be used for data exchange between different sources, processing by the tools specialized for specific medical documents or for non-repudiation of data about the patient. Data saved in EHR database can be used by the healthcare professionals for retrieving Patient Summary that includes the most important clinical facts that can ensure safe and secure healthcare for the patient. Also, the data can be used for data analysis and reporting. EHR will accept data created only from the healthcare professionals who are registered in EHR. When a new source institution is to be connected to EHR, it initiates registration of all healthcare professionals. Later registrations can be done on demand. Deletion of data from the database must be logical, not physical, except in the case of purging obsolete historical data. Those records will stay in database, but will be marked as deleted. Every insertion, update or deletion of data in the EHR database has to include matching audit trail record. The range of information collected by the EHR will be gradually extended. This extension will be matched with requirements on health institutions regarding data collection, providing health professionals with related instructions, increase of technical capabilities of EPR systems, and development of communication infrastructure between the source systems and EHR. In later phases, with large number of healthcare institutions connected and providing data to EHR, collected data could be used by authorized users such as researchers or external consultants for scientific or statistical purposes. However, this use should be precisely regulated in order to prevent incrimination of EHR for disclosures or data leaks caused by third parties. A formal constraining is necessary, since even stripping of patients identity data may not prevent positive identification of an EU-IHIS Šumatovačka 78-80, Beograd, Serbia /19

10 individual based on specific medical data and information about geographical region or healthcare institution. After implementation of the basic scenario of patient data aggregation and usage between healthcare institutions and EHR, the patients should become empowered with online access to their own personal health information through a health portal. Some portions of personal information could also become available for cross-border exchange in a form of patient summaries, but only after completion of all necessary legal and organizational procedures. Certainly, pertinent to systems of this nature, archiving and/or purging of some obsolete and irrelevant historic data may come into consideration after a period of time. However, data retention policy is yet to be determined. Populating and Updating of EHR Database Following the integration with an existing HIS, the process of existing local data migration should meet these requirements: Source system is associated with a single health institution. Source system is typically a HIS or PC EPR that provides information to the EHR. Some institutions may have several source systems hosting separate EPRs. In addition, if an institution hosts domain specific subsystems such as LIS or PACS, these systems communicate with the EHR through the source system. Since the existing EPR systems in Serbia perform electronic reporting using XML based formats, gather personal data of NHIF insurees and carry out some other exchanges, these data formats will be also used for exchange with EHR. In case that some specific standard for EHR exchange is proscribed by regulatory bodies, the systems will have to adapt accordingly. Data exchange will be done through invocations of HTTP based RESTful web services. In order to standardize data exchange, documents exchanged between EHR and source institution will be in HL7 XML format. The submission of data from the source systems to the EHR is managed following a synchronous exchange pattern i.e., when a source system has data that should be stored in the EHR database (e.g. an encounter is closed), submission is initiated immediately. The EHR processes the data in real-time and sends back the acknowledgment of processing it to the source system. Patient EPR System EHR Healthcare Professional Clinical Documents When the EHR receives a document from a source system in an interaction, it performs the syntactic and sematic validation of the received data. Once the validation is performed, the EHR either accepts or rejects the content of the received interaction. In case of data rejection, source system will resend EU-IHIS Šumatovačka 78-80, Beograd, Serbia /19

11 the rejected document after the necessary corrections. The error messages are to be audited and recorded. In case of successful validation, the document is forwarded to the Document Repository and Registry. Unique ID for the document will be assigned and it will be saved in its original form. Source system will be notified about the assigned ID for the document. Besides the document, there is also set of additional information about it such as: format, version, size and calculated hash code. These data ensure reliability of the information inside the document in the Document Registry. The received document is registered in the Document Registry which contains the location of the saved document as well as a set of metadata that enable the search based criteria, i.e. patient ID, healthcare professional ID, source institution ID, document creation time, version of the document, etc. Once the document is stored and registered, related data are extracted and saved in EHR database. In order to enable update of received information, all documents and data are versioned inside EHR. When a document or information from a document is searched, only the last version is presented to the viewer. There is interaction which enables search of complete history of the document. Document can be deleted from the EHR. There is no physical deletion of the document, but the logical, where the data is only marked as deleted. Once a document is deleted, it cannot be reactivated. In case of wrong deletion, a document should be resent to EHR and it will be treated as a new document. Considering the sensitivity of the data being transferred, exceptional security measures are required. There should be mutual authentication of endpoints with ensured encryption and integrity of transferred data. Upon connection of a new HIS or PC EPR system with EHR, initial data loading can be provided through corresponding interaction with the EHR or the original packages are too large for a normal transfer, it may be transferred in some other secure ways, including physical media. Replication of collected EHR data will be probably necessary in order to provide the adequate performance. As mentioned earlier, separate usages that are candidates for replication include data insertion, access to individual patients data and reporting. Integration of the EHR system in an enterprise service bus for the national health system is an option for future integration. Access to EHR Health Data Patient medical data (diagnoses, risk factors, family history, hospitalizations, interventions/procedures, etc.) in EHR are separated in six groups: medical data with standard sensitivity level and five groups of particularly sensitive data (HIV and viral hepatitis, mental health, substance abuse, domestic and sexual violence, alternative lifestyles). Medical data are available to all healthcare professionals by default and without any kind of restrictions. However, access to particularly sensitive data will require additional user action and will be marked in audit log. EU-IHIS Šumatovačka 78-80, Beograd, Serbia /19

12 Initially, the access to the EHR system will be provided to doctors with patient care responsibilities. In a further stage of the project the EHR system will have the capacity to accommodate other kind of healthcare professionals like nurses, pharmacists, etc. When requesting access to personal EHR, the health professionals may also specify a time period and whether they want to see only the actual data, including the last six months, or all data related to some specific period. Set of data which to be shown upon the initial request include: Basic administrative data Personal data about a patient including name, surname, gender, date and time of birth. If applicable, it will include date and time of death as well as contact data of the patient's legal custodian and contact person authorized by the patient. Alerts Listed and described any allergies, significant adverse reactions, and possibly other medical alerts that are pertinent to the patient's current medical condition. Previous diagnoses All previous patient's diagnoses for which there is no contact in EHR and have been inserted in the EHR due to their relevancy (e.g., (for example, patient earlier life diagnoses) as well as those diagnoses older than the reporting time period but that have been highlighted by the doctor based on its importance. Active diagnoses All diagnoses that are currently active or were present during the specified period of time. In order to prevent duplicates of same diagnosis, a predefined period of time can be used to group together multiple instances of same diagnosis reported during this period. Medications Patient dispensed and prescribed medications included in the reporting time period. Hospitalizations Listed and briefly described hospitalizations during the reporting period. The description includes healthcare institution, final diagnosis and treatment outcome. This list does not include hospitalizations at departments and institutions that are related to particularly sensitive medical conditions. Medical devices, implants, reception of organ transplants. Interventions/procedures List of all interventional, surgical, diagnostic, or therapeutic procedures or treatments pertinent to the patient included in the reporting time period regardless their statuses. Previous interventions/procedures - List of all procedures which were not performed during specific encounter, but they are entered during encounter by the health care professional as a pertinent patient data (e.g., a surgical procedure performed abroad) as well as those procedures older than such period but that have been highlighted by the doctor based on its importance. Blood type. Primary cause of death. Health care professional can request to get more details regarding the patient s health condition. These include sets of data related to: Family history Data defining the patient s genetic relatives in terms of possible or relevant health risk factors that have a potential impact on the patient s health. Encounters List of all encounters, hospitalizations and ambulatory, during the reporting time period, including healthcare institution, final diagnosis and treatment outcome. EU-IHIS Šumatovačka 78-80, Beograd, Serbia /19

13 Immunizations Patient s immunization history Risk factors Smoking, obesity, abuse of substances, etc. Plan of care Listed all planned, scheduled or appointed interventions, procedures, hospitalizations, encounters and immunizations for the patient. Also, system will allow users to request details about specific encounter or hospitalization. Details about hospitalizations and encounters are retrieved from health care institutions in a form of HL7 CDA documents. Received documents are stored in Document Repository component of the Interoperability Framework. A Document Repository is responsible for storing documents in a transparent, secure, reliable and persistent manner and responding to document retrieval requests. In the future development of the system, Document Repository will be responsible for storing all other types of documents which can be interchange between health care institutions and EHR (for example images, PDF files, diagnostic summaries or mandatory reports with standardised, structured and coded clinical information etc.). When specific encounter or hospitalization is requested, original document from Document Repository will be retrieved. Access to particularly sensitive medical data by healthcare professional should be explicitly demanded in queries posted to the EHR. Each request for patient medical data should be strictly tracked in order to monitor the necessity of accessing such data and to provide mechanisms to avoid unauthorized use and allow later audits. The requests for sensitive medical data must be clearly noted in access history. If the health professional requests some sensitive data (s)he is not allowed to access, an authorisation error is produced. In such a case, even other information the user could get by using a common request would not be presented. Whether some information (individual items or some sensitive segments) could be hidden from healthcare professionals on explicit patient request is yet unclear, because this must be determined by forthcoming legislation. Hiding some medical data can influence future treatments of the patient, and the regulation must ensure proper balance between privacy and right to adequate healthcare. If requested data that would be otherwise available to the health professional is hidden by the patient, the healthcare professional should be informed that corresponding data, if any, is hidden upon patient request, but there should be no indication whether any data from that group actually exits in patient s medical data or not. Since treatments as some healthcare institutions and units are associated with some sensitive conditions, lists of patient s diagnoses, medications and treatments should not include information about institutions/units and health workers. This allows for non-sensitive diagnoses, medications etc. to be presented, even if originating from such specific institutions or units. On the other hand, if the institution/unit information is presented in data about hospitalizations and encounters, it is likely that such events at institutions or units associated with sensitive data should not be presented to non-authorised users. User Authentication and Identity Management Complete data exchange between EHR system and client applications (HIS, PCC IS, portals etc.) has to be secured which means that only authenticated and authorized users should be able to interact with the EHR. EU-IHIS Šumatovačka 78-80, Beograd, Serbia /19

14 Initially, data exchange between EHR and HIS applications can be based on mutual trust. Secured connection between systems is established using digital certificates. HIS are responsible for user authentication. Every interaction with EHR contains information about the user which is requesting data exchange. In that way EHR will be able to track which healthcare professional is manipulating data at any moment. Likewise, user information provided by HIS can be used for authorization purposes in the context of EHR. Healthcare professionals access to EHR should be managed through a role-based permission management. In future, if so regulated, access to particularly sensitive data groups may be restricted depending on user roles as well. In next phases of the EHR development, with the growing number of HIS and PCC IS systems connected to EHR, and also with connecting other client systems to EHR (i.e. patient portal, health professional portal, EHR reporting portal etc.) authentication and authorization could be organized in a more centralized way. There is a central facility which is responsible for user authentication by determining his identity and also for authorization of client systems to use certain services. Overview of such organization can be seen in the picture bellow. This facility can also be used for identification and authorization in HIS and PCC IS, what would enable users to seamlessly access to data provided through various applications and services, through the client system or, by using pass through authentication, directly from their front ends. This approach would enable higher level of access control and data security. All this should be implemented following existing international standards and protocols (i.e. OAuth 2.0, OpenID connect etc.). User Identity Provider Request User Identity Patient or Healthcare professional User Request Client system Request Authorization Request Data ehealth Authentication and Authorization EHR or other ehealth service Usage of Patient Data within Healthcare Organizations Each local HIS or PCC IS must provide identification of healthcare professionals. Each user must have an assigned role with restricted access to data and functionalities in strict compliance with the legislative rules and regulations that concern particularly sensitive medical data (HIV and viral hepatitis, mental health, substance abuse, domestic and sexual violence, alternative lifestyles). That EU-IHIS Šumatovačka 78-80, Beograd, Serbia /19

15 way, the presented content may be filtered according to the role of the end user and controlled access to patient s data. Individual healthcare professionals should be able to highlight some diagnoses, interventions/procedures, medications, implants and devices. This highlighting can be used to ensure more prominent display of individual items in lists. In future, highlighting may become a means for reduction of content presented to health professionals in order to allow compact display of important information. However, it is initially better to avoid filtering of information based on highlights, since it can effectively result in obscuring of some part of information. Some items may be presented or filtered out based on status and time. Item s visibility may therefore depend on its sensitivity status, execution phase/state and whether it happened or was present within the specified window of time. Initially, source system should provide the users with read-only access to the data retrieved from the EHR. More advanced rendering could link the retrieved content with corresponding locally available items. Also, data items can be provided with corresponding unique identifiers. These identifiers can be used in cases when the user or client application needs to change the record and send the update to the EHR database (a diagnosis from one contact is used as entry diagnosis in another institution and closed within that institution, the chosen doctor changes or updates data from other sources, etc.). Changing the data created in other data sources must be restricted and controlled. In case when a new patient comes in a healthcare institution, it could also be enabled to healthcare professional to query personal identity data from the EHR. However, this feature should be aligned with regulations about personal data exchange and may need to be limited to searches based on unique identifiers (personal number, insuree number or identification document number). The safe option for the beginning is to rely on information copied from presented identification document or the one made available from the NHIF database of insurees. The patient may request some kind of personal report about his/her EHR data, as well as history of accesses by various healthcare professionals. This will be particularly needed in primary care settings, as the patient is most likely to acquire this information from her/his doctor at PCC. Later on, healthcare professionals should be provided with a direct access to the EHR via web portal. Data entry and modifications through this portal would be particularly useful if a user cannot modify certain information through EPR systems they normally use. For example it may be difficult for an EPR system to allow modification of EHR information provided by health workers from other institutions. An advanced addition to portal features is to provide external health consultant with ability to inspect or enter medical data without disclosure of patient identity. This could be archived by letting referring healthcare professionals to create of time constrained consultation tasks on the web portal or even through EPR system. Similarly, user bound temporary accounts or access tokens could be introduced in order to grant limited access to patient records to health consultants who are not registered in the EHR. However, this feature may also need to be augmented with ability to present the information in several languages in order to support international consultancies. EU-IHIS Šumatovačka 78-80, Beograd, Serbia /19

16 Quality Analysis of EHR Data Besides the two HIS solutions that are implemented in EU-IHIS beneficiary hospitals, it is expected that large number of other source systems will be connected with EHR in the future, particularly systems in the PCC. None of source systems will be able to include and provide all data defined in the EHR data set from the very beginning. Some systems already have sufficient support for adding extra data items to the forms presented to healthcare professionals. If a system supports creation of data fields that are offered to end users, at configuration/metadata level, it is relatively simple to add input fields for missing items and their proper tagging and mapping as EHR related content. On the other hand, the systems without this kind of support will have to hardcode some values in order to satisfy requirements. In such cases, used values must be clearly recognizable as hardcoded, in order to exclude possibility of wrong usage of provided data. The systems will need to be tailored in order to feed the content to the EHR. Therefore, additions to HIS and PC EPR software in that regard will be inevitable, as they should provide additional data collection, coding, communication, retrieval and display of EHR data. If an EPR system is highly flexible and configurable, some IT admins, departments or examination rooms/personnel may miss to make appropriate adjustments and, consequently, miss to provide needed data, in a case of inappropriate configuration. Therefore, an additional effort on behalf of the EHR on ensuring that desired or required data items are consistently captured is necessary. It includes monitoring and quantification of actual content coming from the HIS systems, but also other systems at a later stage. There are three main reasons for this quality control: 1. quality of data captured by EPR systems 2. quality of coding 3. quality of institutional practice A comprehensive data quality assurance must be developed, and it includes monitoring, feedback and incentives leading towards improvements. These incentives could include quality control before integration with production level EHR, certification and regulatory enforcement. High data quality achievement in EHR will be an iterative process, that will include gradual extension of mandatory data set and controlled inclusion of new healthcare institutions, i.e. only after they meet the current content/quality requirements. It is expected that the EHR and the adjacent HIS and PC EPRs will have its own evolutional growth policy that will support its specific needs. These possibly divergent policies may have detrimental impact on the quality of data being exchanged between the sources and EHR if it is left without an adequate monitoring process. Each new source system, such as HIS or PC EPR, will have to apply for approval that it is fully compliant with the EHR. The approval procedure has to confirm that the new data source provides data quality satisfying the EHR requirements and constraints mentioned in paragraphs above. Another equally important aspect of data quality is its assurance. Each data source, once approved as compliant part of the integrated patient data exchange system will be also included in the permanent data quality monitoring process. The data sources and the EHR will need to respond to ever growing number of new requirements. However, the inevitable changes made to the parts of the system may EU-IHIS Šumatovačka 78-80, Beograd, Serbia /19

17 harm the system s abilities to accomplish its primary mission the accuracy of the patient data. The compliance monitoring process will include regularly performed audit procedures at the site of each data source. Of course, such a procedure should also include scrutinising of the resources deployed on the EHR end. As a feedback, the completion of the audit procedure will include an itemized list of identified non-conformances with possible root causes and recommendations and deadlines for their elimination, as well as other opportunities for improvement. Patient Access to Their Personal EHR Data Initially, patients will be able to get insight into their personal EHR through EHR systems with physicians acting as mediators. Once the EHR is institutionally established, the patients could also request the content of their EHR from EHR personal data operators who would be in charge for providing this information. Patients online access to their EHR data will become available at a later stage of EHR implementation, after majority of healthcare facilities are integrated into the system and a simple solution for highly reliable patient authentication becomes available for most patients, for example, through personal or healthcare insurance ID smartcards with personal PKI certificates. It is not expected that patients will be able to use EHR system for access to their own personal health records by the end of the first phase of implementation. However, such access through a secured web portal should be part of overall system functionalities. The user must have access to his/her personal data within EHR system, but will not be able to make any changes to the medical records. It must be possible to see all instances of data access and changes, with provided information about persons accessing or changing the information and the time of access or change. Additional functions that should be consideration for inclusion are: Patients may be allowed to specify visibility of some sensitive medical data within their own health record. However, this should only be allowed in relation to predetermined data groups and not for individual data items. Users may request reports about their EHR data currently in the EHR, as well as data about history of accesses by health care professionals. One may receive /im/sms notification of health record being accesses by a new healthcare professional, or already known user, but after some predefined period of time. The delivery methods for these notifications should be specified by the patient. Notifications about planned or scheduled activities (planed immunization, surgery or other procedure, medication prescription renewal, etc.). Entry of patient s personal observations or measurements related to his/her health status. Such remarks must be clearly distinguishable from entries about activities that were actually performed by health professionals. Potentially, patients may have ability to submit a request for change of the incorrect data. These changes are subject to approval by authorized professionals. EU-IHIS Šumatovačka 78-80, Beograd, Serbia /19

18 Integration with Additional Data Sources HEALTH DATA REGISTRIES OTHER REGISTRIES Organ donors Insurance databases Injuries Traffic accidents Domestic violence Welfare Cancer Educations Infectious diseases Statistics Cross-Border Patient Summary Exchange ANALYTICS DATABASE (DATA WAREHOUSE) ELECTRONIC HEALTH RECORD USES OF DATA (BUSINESS INTELLIGENCE) Figure 2 Overview of analytics database (data warehouse) system Ever increasing visibility of EHR system benefits will prompt the interest for faster inclusion of all public hospitals and primary healthcare centres as well as privately owned healthcare facilities in the IHIS. This process will have its own challenges like responding to requirements for continuous increase of the EHR data set, source systems standardization or continuous training of healthcare professionals as users of EPR and EHR systems. Over the course of this process the EHR database itself will keep gaining its significance as a demographic data source for various kinds of analyses with ever increasing percentage of population having its health data collected in it. One can expect strong growth of demands for cross-sectorial analyses based on information gathered from multiple sources. Virtually each analysis concerning health and well-being of regional or national population will require aggregation of data from several independent sources from the health, public, civil sector and other services into a single health-related analytics database e.g. data warehouse. Such master repository of health-related data will provide opportunities for usage of business intelligence tools to create various indicators and extract knowledge. A graphical overview of such arrangement is shown on Figure 4. A good illustration of this concept is linking of the records about incidents of violence or traffic accidents originating from the police database with diagnoses and treatments related to resulting injuries from EPR systems and EHR database and external records about out-of hospital death within one month after the incident. EU-IHIS Šumatovačka 78-80, Beograd, Serbia /19

19 Although the concept elaborated in this section clearly goes beyond the scope of EU-IHIS, the expectation of strong demand for multi-vertical integrations and analyses is certainly justifiable. To demonstrate that implementation of such integrations is possible and to facilitate future developments towards those goals EU-IHIS should explore additional data sets used in indicators for various topic areas as well as technologies for interfacing various sources of information. Relevant NHIF and NIPH databases may provide initial data sets for that kind of integration. This opens a perspective for next phase of integrated healthcare system evolution with additional focus on creating a cross-sectorial data warehouse along with full inclusion of all healthcare institutions. EU-IHIS Šumatovačka 78-80, Beograd, Serbia /19