## 2 The TASIPPS Conceptual Framework
### Case Study of the TASIPPS Framework  
The TASIPPS framework was implemented in a system consisting of a central (interoperability) platform and two different EMR prototypes. A specific case study simulation, demonstrating the utilization of the TASIPPS framework, was successfully conducted during the testing. In this scenario, two simulated healthcare institutions with different EHR prototypes were integrated using the TASIPPS framework. The framework enabled seamless data exchange, ensuring that the medical records from one hospital were accurately interpreted and accessible to the other hospital in real-time. The semantic interoperability module played a crucial role in translating healthcare terminologies between the systems, avoiding any misinterpretation of patient data. The necessary steps in accessing a patient's medical history using the TASIPPS framework are as follows (see also Figure 8):  
1. A doctor initiates query for patient history: During a consultation, if the doctor at Hospital A needs to review a patient's medical history, stored by Hospital B, they initiate a query request to the central platform. The doctor's role-based access control (RBAC) permissions are verified within Hospital A's system to confirm they are authorized to make this request. 2. Request sent to central platform: The request (from Hospital A) is securely transmitted to the central platform, which acts as a mediator between the two connected prototype (hospital) systems. The central platform identifies the patient's unique ID and prepares to fetch the patient's medical records from both Hospital A (current) and Hospital B (connected). 3. Verification of doctor's role: The central platform checks the RBAC policies of both systems to ensure that a user who is a doctor is making the request, adhering to the security protocols of each institution. This RBAC verification helps maintain the data access restrictions, allowing only qualified healthcare practitioners to access patient information. 4. Display of patient's medical history: The central platform retrieves a list of the patient's previous visitations from both Hospital A and Hospital B. The list includes details such as the visit date, hospital name, attending doctor's name, and any relevant clinical notes. This information is presented in a consolidated view on the doctor's interface, allowing for a quick overview of the patient's history across institutions. * Patient consent request via OTP: Once the doctor selects a specific medical record to view, the central platform triggers a consent request to the patient's registered phone number. An OTP (one-time password) is sent to the patient, along with a secure link that allows them to approve or decline the data view request. * Patient consent approval/denial: The patient receives the OTP and link, allowing them to verify the access request. By entering the OTP and selecting \"Approve\" or \"Decline,\" the patient controls the sharing of their medical information, in compliance with privacy regulations. * At this stage, the central platform ensures semantic interoperability by aligning the medical terminology and data structures across Hospital A and Hospital B. This alignment allows for data from disparate EMR systems to be accurately interpreted and presented in a consistent format on the doctor's interface. By standardizing terminologies and data models (see Section 2.1.2), the central platform ensures that the medical information from both hospitals is meaningful and accessible, providing the doctor with a unified view of the patient's medical history. * Access granted to the doctor (upon approval): If the patient approves the request, the central platform grants the doctor access to view the selected medical record. The doctor can then review the patient's full details, which may contain critical information for the ongoing treatment.