The healthcare sector has been facing numerous challenges in managing and leveraging the vast amount of data generated by various medical information systems (MISes). MISes play vital roles in healthcare institutions (HCIs). Nowadays, it is nearly impossible to provide medical care without the support of an MIS, which is essential in all HCIs. In the Republic of Serbia, MISes are organized at the institution level by various vendors. This means that accessing a patient's data from other HCIs is impossible. However, for comprehensive healthcare, there are cases when doctors need access to all previous patients' medical records, regardless of where they were created. This highlights the necessity of collaboration among HCIs' MISes. In 2019, a project aimed at solving this problem, known as Vertical Manageability in Healthcare, was initiated. Our research group's previous conference paper [1] outlines this project's introduction ideas and implementation. This paper discusses how the collaboration of different information systems, the so-called distributed centralized medical information system, has evolved over the years, highlighting new requirements and changes made during the project's lifecycle. This serves as a guideline for what can be expected during the cooperation of different information systems.
MISes play a crucial role in modern healthcare provision [
Many countries face the challenge of providing complete information technology (IT) support to
all health facilities. The organization of the health system greatly influences this. Ideally, all HCIs
would use the same MIS that supports internal processes and inter-institutional collaboration.
However, HCIs often use their own autonomous MIS, leading to a lack of collaboration [
The healthcare system in the Republic of Serbia (RS) is organized into three levels of state HCIs (primary, secondary, and tertiary), as well as numerous private practices and clinics, with state HCIs being the dominant providers. At the primary level in the RS, state HCIs have implemented MISes certified by the Ministry of Health of the RS. MISes are also used in secondary and tertiary HCIs in the RS. Each MIS operates within the HCI that supports it, and prior to the VMH project, there was no data exchange between MISes. Each MIS facilitated communication with the Ministry of Health of the RS and the Republic Health Insurance Fund (RHIF), but not with other MISes in the country. The lack of communication between MISes was not a problem when patients were treated in only one HCI, typical at the primary health care level, where each patient has a primary care doctor. However, when a patient moved from one HCI to another at the same level, it became impossible to track their previous treatments due to the lack of communication between MISes.
In some cases, patients receive treatment at multiple HCIs, patient starts treatment at the primary level and then continues at the secondary or tertiary level. Each HCI where the patient is treated creates medical data and stores it in their local MIS. However, these HCIs cannot access the medical data from previous treatments at other institutions. Recognizing these limitations in our healthcare system, the Ministry of Health has initiated a project to facilitate collaboration among all MISes to provide each patient with comprehensive information about all their relevant previous treatments, regardless of where the treatment was received.
MISes collaboration occurs when it is necessary, at the request of an authorized healthcare worker for a specific patient who has received treatment outside the current HCI. Without a request, there is no sharing of patient data, and each HCI only has the medical data related to treatments performed within it. This indirectly creates a distributed centralized medical information system (DCMIS), effectively achieving the consolidation of data from all MISes in the RS. It is important to note that existing MISes are separate, independent systems. Additionally, the collaboration of these diverse MISes is complex due to the use of different databases, technologies, and software architectures.
Our previous paper [
MISes collaboration in the RS was achieved by establishing DCMIS. The initial challenge in creating
DCMIS was the centralization of diverse MISes. This section explains the concept of DCMIS and
outlines the challenges encountered during its creation, as described in [
The DCMIS is a collection of individual MISes collaborating to provide comprehensive patient information, regardless of where the patient received treatment. Instead of creating a single centralized MIS, DCMIS consolidates data from various MISes in a distributed manner, preserving the autonomy of each MIS. This allows healthcare providers to access all relevant patient information, even if the patient was treated at multiple HCIs.
The MISes in different HCIs are similar in concept and data content but vary in structure and databases due to being created and maintained by different vendors. This makes it challenging to collaborate and unite heterogeneous data from various sources. It is essential to identify common data across all MISes and create a standardized way to present it to overcome this challenge.
The initial step towards data exchange involved sharing radiological data [11], which paved the
way for collaboration between heterogeneous MISes. The focus of data exchange in VMH lies in
essential patient data such as visit information, referrals, and reports. While MISes also contain other
data like treatments, laboratory tests, prescriptions, sick leave, and vaccinations, initial collaboration
is emphasized on the fundamental patient data across all health facilities. To ensure the best patient
care and long-term usability of information, it is crucial to establish a uniform national structure for
the data [
Establishing a centralized MIS at the state level could yield numerous benefits. Centralizing data would create a large repository that can be utilized for various analyses and disease predictions, which would be highly beneficial for many patients [12]. There should be a particular emphasis on employing deep learning algorithms, which can be a powerful tool for addressing issues across various medical fields [13].
In the RS, state health care centres at the primary level got MIS implemented by one of the vendors, with the DILS (Decentralization of services at the local level - 2010) project financed by the World Bank [14]. Due to the use of different vendors for implementation, centralizing MISes is challenging. However, it is feasible to create a DCMIS. DCMIS allows all data at the state level to be distributed across different MISes, while still enabling access to the data regardless of the institution in which it is located. Access to all data is provided through a centralized repository (CR) at the RS level. For each patient, the CR records the ID of the HCIs where the patient's medical data is stored. When a data request is submitted, the patient's ID is first sent to the CR. The CR then locates all HCIs associated with the patient and sends a request for data only to the relevant HCIs. The MIS of the specific HCI receives the request for patient data, gathers all the relevant data, formats it into the agreed-upon JSON format, and sends it as a response to the initial request.
The details of the MISes collaboration were previously described in [
In order to know which HCI should receive a request for patient data, it is necessary to identify where the patient data is located. At the start of the collaboration between different MISes, the initial CR was created by each MIS sending a list of patients who have visited their HCI at least once. In the CR, each admitted unique identifiers identify the patient: Social Security Number (SSN) and National Provider Identifier (NPI). The HCI that sends the data is linked to the patient's information, as it will be the institution from which the patient's data are requested. After the CR is initialized, the MIS sends a POST method to inform the CR about the new patient data. The POST method includes the patient's unique identifiers and the institutional code of the HCI sending the data.
This CR system makes all patient data in connected HCIs accessible in one place, enabling communication and data exchange between the connected MISes.
The process of obtaining patient data involves sending a GET request with one of the two patient IDs (NPI or SSN) specified as a parameter, along with an optional starting date for the requested data. It is essential to include a valid institution token for authorization.
The authorization token is obtained by sending a GET request with the HCI's credentials creating the request. The HCI does not receive the requested data if the token is invalid.
When an HCI's MIS receives a GET request for patient data, the first step is to validate the received token. Token validation is checked through a new GET request in which the MIS sends the received token as a request parameter. If the token is valid, the MIS can collect and send the requested patient data in response to the received GET request. If not, the MIS responds with an error or null (Figure 1).
The MIS service processes a GET request with token for patient data. A unique JSON response specific to DCMIS is sent if the token is valid. The JSON response includes patient information and a collection of patient visits to the HCI.
Each patient visit, labeled as PatientCaseRecord, contains data about the visit, including the HCI, visit date and time, visit ID, visit number, and visit status. Additionally, each PatientCaseRecord contains a collection of referrals made during the visit.
Referrals, marked as PatientCaseRecordRequest, include information about the admission cabinet, admission date, attending doctor, referral ID, admission ID, referral type, and referral status, and may include a URL for a diagnostic referral picture. Each referral also contains a collection of reports associated with that referral.
Reports, labeled as PatientCaseRecordResponse, include details such as type, status, creation date, and findings verification. PatientCaseRecordResponse also includes an address for obtaining the entire report in PDF format. The creation of the address and PDF report is explained in the next section.
Each vendor has organized their MIS databases and program functionalities differently, making it challenging to establish a uniform data format for all MISes in the RS. As previously mentioned, every MIS contains information about the patient and maintains a record of each patient visit. A visit may include requests, and each request may have corresponding responses, with each response having its PDF representation.
In the initial implementation, when an MIS service receives a request for patient data, it collects basic patient information and data about every visit the patient had at that institution. As mentioned earlier, the dateFrom parameter is optional, and if set, the service should return all data from that date onwards. The concept behind this is that the CR has a cache memory for patients, which saves received patient data and the date. When the request for patient data is made, a request is sent to all institutions where the patient has data, with the dateFrom parameter set to the previously received and memorized data.
Despite the initial good design, changes were necessary once the system was implemented. The first change was that the transmission of patient information was omitted. Any institution that needs patient medical data should already know patient's basic personal information. The only personal, non-medical, data sent through requests is the patient's unique ID, SSN or NPI.
Patients could have numerous visits for various reasons, such as minor health issues, sick leave, or regular check-ups. The initial design would have sent many visits, leading to longer waiting times, larger data transmissions through services, and lower system performance. Requests are frequently timed out.
To address these issues, the initial approach was revised to limit the amount of data transmitted in each request. The critical question was whether all the recorded visits were essential and valuable enough to be requested by other institutions. Routine check-ups, visits for sick leave, or visits solely for collecting medication may not be essential for external doctors. Moreover, sending all these visits could lead to an overwhelming number of records for a doctor, resulting in an influx of unnecessary information and potentially missing essential details. To address this, adjustments were made to the process of sending visits in practice. Not all existing visits are now sent as initially planned. It is now recognized that visits deemed worthy of being sent to other institutions are those that involve requests and have received at least one response. Visits without any response are considered to lack sufficient important information for external institutions and are therefore not sent during VMH work, following one of the changes made.
In addition to the previously described approach of using the dateFrom parameter to retrieve the latest data, some requests still timed out. A new optional parameter, dateTo, has been added as a solution. When a request for data is received, the service returns all patient visits in that institution with a request and at least one response if none of the date parameters is set. If the dateFrom parameter is set, all visits with at least one response from that date until now are returned. If the dateTo parameter is set, all visits with a response until that date are returned. If both date parameters are set, the service returns visits with responses between the specified date range.
The request timeout problem has been addressed by sending the original request to the service from the institution. If the request times out, new requests are created with the dateFrom and dateTo parameters instead of the original one, splitting the original collection of visits into smaller collections. This approach reduces the search period, shortens the request time, and avoids the timeout problem.
Every HCI is required to have a server to run the service. The service must be available 24/7 and respond to received requests by gathering and formatting appropriate data. Most HCIs that use MIS Medis.NET are located in the less affluent southern and eastern parts of RS, resulting in less advanced hardware equipment for the institutions [15]. As a result, the server dedicated to the service also serves other purposes. However, frequent requests may overload the server and affect its ability to function regularly for all other tasks.
At one point, the CR initially sent requests to all services for all registered patients to collect data for the CR cache. Subsequently, for each next request, the CR would send a query with the optional parameter dateFrom set to the date when the cache was fulfilled. Unfortunately, servers became overloaded and caused functionality problems, resulting in the immediate shutdown of services. To prevent such problems, a flag for service availability has been added to a database. If frequent requests cannot be addressed or the server is being used for other purposes at total capacity, the flag can be set to false, and the service is turned off.
Another incident occurred when a bug in CR led to an enormous number of purposeless requests, blocking other functionalities. Although the service checks the validity of the request token and collects and sends data only if the token is valid, resources are still required to process the received request and token. Servers indicated that the VMH service was causing issues, but the service did not create any log files even with token analysis, making it impossible to identify the source of the problem. As a result of this event, log files are now created for every received request with all its data, including token information. Analyzing the log files can help identify problems in case of incidents or frequent requests.
In the initial version, there was no mention of the request's answer status code. Only the request body was considered necessary, and the status code was set to default. However, due to various events, including some mentioned in the previous paragraph, different standard status HTTP codes can occur. Here are the updated status codes: • • • • • •
Code 200 -is set if the request was successful and at least one visit with requests and responses is found.
Code 204 - the request was successful, but no matching visit was found.
Status 400- is set if the request parameters are not correct.
Code 401- indicates an invalid token.
Status 500- is set when a server error occurs.
Status 501- indicates that the administrator turns off a service.
After all services in all HCIs were created, and the CR started working, it was time to develop a client application for requesting and displaying data to the doctors. The client application should be integrated into the existing MIS and easily accessible for MIS users.
In Medis.NET, the VMH client form is accessed from the visit form. When a patient visits a doctor, the doctor opens a visit form and enters all the necessary information for the visit. Inside that form, there is a button to access the VMH form.
Both the institution token and user data must be included when requesting patient data from the CR system. All requests sent to CR are stored and can be accessed by patients through a web form. Each request should include patient information, visit time, institution code, and doctor's ID.
The CR system does not have all the patient data, so when a client application requests patient data, it takes time for the CR to gather all the information from different locations and services, and then send it back to the client. To address this issue, the RefreshCache method was created. When this method is called, the CR proactively collects and caches patient data from all relevant institutions, making it readily available when the client requests patient visits. It is essential to call the RefreshCache method before requesting external patient visits, but early enough to allow the CR sufficient time to prepare the data. In Medis.NET, the RefreshCache method is called when a patient enters the waiting room, ensuring enough time for the CR to gather all patient visits before the examination begins in the doctor's cabinet.
Various filters can be applied when requesting patient data. The client form is depicted in Figure 2. Towards the top of the form, users can input different parameters to filter the retrieved data. Administrator can set other parameters. The CR sends filtered data with these parameters from all institutions where the patient has visited, except for the institution making the request. The parameters are: • • • • •
SortBy: If set to ASC, CR returns all visits sorted by time from the most recent to the oldest. If nothing is set, the sort is based on the oldest visit.
PageNumber: The default value is 0. If this parameter value differs from 0, the number of visits is divided into collections with 10 cases per collection. If PageNumber is set to N, CR returns the Nth collection.
CaseLimit: If the PageNumber parameter is set, CaseLimit defines the number of cases per collection that CR returns. The default value is 10.
CaseDate: If set, CR returns only cases that occurred after this date.
InstitutionCode: If set, CR returns only the cases from this institution.
Patient data are confidential and should not be easily accessed without the patient's agreement or a legitimate need. Additional access restrictions have been implemented. In the RS, patients select their primary care physicians, gynecologists, and pediatricians, and always visit their chosen physician. To facilitate this, primary care physicians, gynecologists, and pediatricians have access to the VMH form and can obtain previous patient data from other institutions.
Other specialists can access the VMH form only with the patient's consent. When a doctor requests patient data and is a radiologist, the request parameter "IsRadiology" is set to true. In this scenario, CR only provides existing radiology cases.
For all other medical specialties, the doctor is required to request access. This is done through a special POST request, where the MIS sends the doctor's NPI, title, first and last name, institution name, and patient's NPI. Upon receiving this request, CR sends a notification to the patient. If the patient has an account on the health web portal, they receive a notification that a specific doctor from specific HCI attends to access their health records. The patient can then choose whether to approve or deny the request. If the patient approves, the doctor should send another request to collect the patient's data, and the VMH form is displayed. If the patient does not approve or does not have a profile on the web health portal, the doctor is not authorized to access the patient's data.
The DCMIS described in this work offers several key advantages that enable more connected and resource-aware healthcare practices. Firstly, by integrating medical data from various institutions, clinicians can access a more comprehensive patient history, leading to better-informed diagnoses and treatment decisions [16]. This can optimize resource utilization by reducing redundant tests, procedures, and unnecessary treatments [17][18]. Secondly, the system's ability to filter and prioritize data based on the clinician's specialty and the patient's consent helps ensure that only the most relevant information is accessed. This targeted access promotes patient privacy and autonomy while still empowering clinicians to provide high-quality, personalized care. Finally, the proactive caching mechanism employed by the system reduces the time and computational resources required to retrieve patient information on demand.
DCMIS provides access to crucial patient data through the state's MISes. However, there are still numerous inaccessible and decentralized datasets, which leaves room for expansion and improvement. Addressing the described issues and implementing changes outlined would be beneficial for further system enhancement and predicting potential shortcomings. Complete data exchange would benefit both patients, by providing personalized care, and healthcare workers, by giving them comprehensive patient information. Furthermore, expanding and completing DCMIS would be valuable for researchers, as gathering medical data at the state level could provide a robust dataset for analyzing different diseases and predicting outcomes.
The quality assurance process for DCMIS involved the integrator and all vendors. The integrator designs service interfaces for all MISes and controls data quality and communication with MISes. Vendors were responsible for creating compatible services according to specifications. Comprehensive testing was conducted, which involved collaboration between the integrator and the vendor. One of the frequent issues encountered was changes in the CR service. Even minor changes, like altering a property type, could result in service non-compatibility, leading to the automatic cutoff of all MISes using services that did not include the latest change. One of the most important lessons for future DCIS development is that all new change requirements should be communicated to all vendors as early as possible, preferably before the change occurs, to ensure uninterrupted system functionality.
In our previous work, the initial system design underwent several modifications and extensions. Initially, only the service side was designed to provide data. Patient locations were sent to the CR, and the CR was notified of every new patient in the institution. As the system progressed, various disadvantages were discovered, including request timeouts, unnecessary patient cases, date limitations, and hardware limitations. These weaknesses were resolved in later system versions by introducing new parameters, conditions, and code statuses.
Once the service side of the application was completed, a client part was developed. In order to increase time performance and decrease users' waiting time, a RefreshCache method was proposed and implemented to prepare all data in advance. This method is called when a patient enters the physician's waiting room, and after that patient data is ready in the system cache when the physician requests it. Users (physicians) can apply different filter parameters to obtain the most valuable data. Access restrictions based on the clinician's specialty and the patient's consent have been implemented to protect patient data confidentiality.
Our previous paper described the initial VHM design. However, as the system has been operating, we have encountered shortcomings that necessitated changes. Problems identified in the functioning of DCMIS are likely to be found in other domains with DCISes, not just in medicine. Given the importance of collaboration between different information systems in expanding existing systems, the challenges and changes described in this work could help in faster detection and problem-solving across various DCIS domains.
This work was supported by the Ministry of Science, Technological Development and Innovation of the Republic of Serbia [grant number 451-03-65/2024-03/200102]. [9] P. Rajkovic, D. Jankovic, A. Milenkovic, Developing and deploying medical information systems for Serbian public healthcare: Challenges, lessons learned and guidelines, Comput. Sci. Inf. Syst. 10.3 (2013) 1429–1454. doi:10.2298/csis120523056r. [10] A. Milenković, D. Janković, A. Đorđević, A. Spasić, P. Rajković, REALIZATION OF DISTRIBUTED MEDICAL DATA REPOSITORY IN AN ENVIRONMENT WITH HETEROGENOUS MIS, Facta Univ., Ser. 20.3 (2021) 135. doi:10.22190/fuacr210930011m. [11] A. Milenković, A. Đorđević, D. Janković, A. Spasić, Collaboration of the MEDIS.NET with the State Radiological Information System, in: XV International SAUM Conference on Systems, Automatic Control and Measurements Niš, Serbia, September 09th-10th, 2021, pp. 33-36, ISBN 978-86-6125-243-3. [12] S. Dash, S. K. Shakyawar, M. Sharma, S. Kaushik, Big data in healthcare: management, analysis and future prospects, J. Big Data 6.1 (2019). doi:10.1186/s40537-019-0217-0. [13] H.-J. Jang, K.-O. Cho, Applications of deep learning for the analysis of medical data, Arch.
Pharmacal Res. 42.6 (2019) 492–504. doi:10.1007/s12272-019-01162-9. [14] V. Bjegovic-Mikanovic, M. Vasic, D. Vukovic, J. Jankovic, A. Jovic-Vranes, M. Santric-Milicevic, et al., Serbia: health system review, in: World Health Organization, Regional Office for Europe, European Observatory on Health Systems and Policies, https://apps.who.int/iris/handle/10665/331644, 2019. [15] P. Rajkovic, A. Djordjevic, A. Milenkovic, D. Jankovic, The Role of Resource Awareness in
Medical Information System Life Cycle, in: arXiv preprint arXiv:2205.07778, 2022. [16] E. Zaghloul, T. Li, M. Mutka, J. Ren, d-MABE: Distributed Multilevel Attribute-Based EMR
Management and Applications, IEEE Trans. Serv. Comput. (2020) 1. doi:10.1109/tsc.2020.3003321. [17] D. Craig, An EHR interface for viewing and accessing patient health events from collaborative sources, in: 2011 International Conference on Collaboration Technologies and Systems (CTS), IEEE, 2011. doi:10.1109/cts.2011.5928704. [18] M. A. Alyami, M. Almotairi, L. Aikins, A. R. Yataco, Y.-T. Song, Managing personal health records using meta-data and cloud storage, in: 2017 IEEE/ACIS 16th International Conference on Computer and Information Science (ICIS), IEEE, 2017. doi:10.1109/icis.2017.7960004.