# Performance of API Design for Interoperability of Medical Information Systems
## 3 Design of the API Proposal  
In the proposed API, the architecture was designed to exchange medical information from patients during their initial clinical contact, i.e., information recorded in the general medicine area. The API was based on HL7 standards for clinical documentation, and DICOM standards [27] for documentation from imaging studies were integrated into the API layers. As shown in the use case diagram in Figure 1, four main views were determined: healthcare professionals, healthcare institutions, patients, and governmental organizations. (1) _Healthcare Professionals View:_  
In this view, doctors, paramedics, nurses, and general healthcare staff in health centers or hospitals will have the ability to access medical information and update patient data. This includes medical orders, laboratory results, and electronic medical records. This view will have the primary involvement concerning the patient, where they are able to communicate with the imaging area and exchange patient results using unique identifiersfor each study, activity, and message, following the DICOM imaging studies standard and its official CONF-DIR specifications. The physician will record the gathered information using a form provided through the API based on the CDA clinical document architecture of the HL7 standard. This form will consist of the header, which will contain the patient's general personal information. The body will be divided into sections, the number of which will depend on the studies needed and collected for the healthcare professional to reach an appropriate diagnosis. The document's body will also contain additional details that the physician deems necessary for the complete patient record. The physician is free to add as many sections as needed but must assign a unique identifier to each one. _Patient View:_  
The patient will have a minority role in managing the API. They will not have a say in the manipulation of their medical information and can only access the system for inquiries and to download certificates added by the general practitioner, as well as to update personal data when necessary. _Healthcare Institutions View:_  
This view will be responsible for admitting the personnel of the health center or hospital, allowing them to interact with the medical information system. This will facilitate the transfer of clinical information between different healthcare institutions, which is crucial for coordinated healthcare and the continuity of healthcare. _Governmental Organizations View:_  
This contributes to collecting standardized data for public health and epidemiological research. Additionally, it will facilitate the implementation of health policies and healthcare quality monitoring at a national and international level. Concerning functional requirements, Table 1 is presented, which describes the specifications following the views. Figure 1: Interoperability API’s use case. API's Architectural Design  
A clonable and distributable architecture has been proposed for the medical interoperability API, whose instances establish connections with medical centers or hospitals to obtain patient medical history information. In Figure 2, the proposed architecture is shown and was designed using abstract factory and wrapper design patterns. When a patient arrives and their medical record is required, the API can clone itself through an abstract factory (_Factory_HCE_) that generates objects of type HCE at runtime according to the number and characteristics of medical centers or hospitals it needs to contact to obtain the patient's medical information.