# Performance of API Design for Interoperability of Medical Information Systems
## 3 Design of the API Proposal
Once contact is established with the medical centers, the _Wrapper Medical History_ class retrieves patient information by encapsulating details such as personal data controlled by the _Patient Identification Data_ class, references to clinical document records, and details of events related to the ailment that triggered the search, as controlled by the _CDA_ class, where medical records are concentrated according to the HL7 CDA protocol format in the contacting medical centers or hospitals. Methods were established to obtain information about a list of previous illnesses or conditions, records of performed medical procedures, reports from imaging studies (X-rays, MRIs, etc. ), vaccination history, vaccines received with corresponding dates, clinical notes, records of medical visits and consultations, observations and comments from medical staff, prescriptions, treatments, prescribed medications, details of specific treatments, insurance information and billing, details about the patient's health insurance, billing and financial records, emergency contact information, and details of individuals to contact in case of emergency. Finally, the Laboratory Results and Studies class is part of the encapsulation of references to download information related to imaging studies. According to the use case diagram, the healthcare professional view can request to initialize the API operation. Figure 3 depicts the state diagram of the HCE class corresponding to the medical history. In this figure, it is possible to observe three states in the API operation: data validation, data processed, and record updated. The method get_Patient_Identification_Data establishes the validation data to reach the validation state. The method get_List_Of_Previous_Illnesses_Or_Conditions locates the information related to the validated user in the medical system. Once the patient's data are located, the wrapper updates and encapsulates the records according to the HL7 format using the get_Record_Of_Performed_Medical_Procedures methods, getter, and setter. For studies containing images, only the links' addresses from the imaging area are taken into account. Once this process is complete, the complete record is sent as text. In this way, each instance is generated through the abstract factory according to the medical centers or hospitals where the patient has information. \begin{table}
\begin{tabular}{c p{284.5 pt}} \hline \hline
**Id** & **Description** \\ \hline FR1 & The system allows access to authorized users through authentication with their username and password \\ FR2 & The system is required to consider profiles based on roles and organizational structure. The system includes four views: healthcare professionals, healthcare institutions, patients, and governmental organizations. \\ FR3 & Healthcare professionals: healthcare staff in health centers or hospitals will have the ability to access medical information and update patient data, such as updating electronic health records (EHRs), reviewing studies, checking EHRs, and requesting studies. \\ FR4 & Patient: this user will only be able to perform query operations and download certificates and studies, such as checking EHRs and reviewing studies. \\ FR5 & Healthcare institutions: this user will be able to update information about the personnel of the health center or medical unit in charge, such as registering medical professionals, modifying personnel, and reviewing studies. \\ \hline \hline \end{tabular}
\end{table} 
Table 1: API’s functional requirements descriptions. As shown in the interoperability operation in Figure 4, the information obtained through the instances at each medical center returns to the requesting medical center and consolidates the information for the requisition.