Performance of API Design for Interoperability of Medical Information Systems
Round 1
Reviewer 1 Report
Comments and Suggestions for AuthorsUtilizing techniques aimed at enhancing software architecture performance, the paper addresses issues in developing a medical interoperability API, which can be cloned and distributed to facilitate the exchange of patient medical history data. Efficient memory management techniques, employing an object-oriented approach and leveraging design patterns like Abstract Factory and Wrapper, are implemented to address heterogeneity. The study estimates a performance level of 62.5 percent, indirectly demonstrated through operation sequence assessments, indicating a satisfactory outcome considering complexity and coupling. However, the paper requires attention to the following issues:
1. The overall structure, with sections like 2 and 4 lacking elaboration and needing subdivision based on keywords such as API Application Programming Interface and Information Medical Interoperability.
2. Figure 2's description of the Interoperability APIs Architectural Design suffers from low image quality and unclear text.
3. Figure 1 could benefit from incorporating activity or state diagrams from the UML modeling language.
4. In-depth discussion on how the paper addresses situations like the COVID-19 pandemic in services should be included in the sections on research limitations and future trends.
5. The paper's reference format doesn't align with the journal's requirements, with many references lacking essential information.
Comments on the Quality of English LanguageMinor editing of English language required.
Author Response
Dear Editor and Reviewer,
We have found the reviews to be very helpful and we would like to thank the reviewers for their valuable feedback that allowed us to improve this work.
We have seriously taken into account each comment and modified and enhanced the article accordingly. Based on your feedback, we have prepared a revised version of the article, where the changes have been highlighted with red text. All the comments (major and minor) have been addressed.
Further, in this letter, we use the following convention to identify the questions and comments from reviewers. As such, Ri.j means Question/Comment j of Reviewer i (i=1,2). In order to discuss the reviewers’ major comments, a detailed response follows, where the original text of reviewers is reported in italics and our response follows.
If you require any further clarification about this revision of the article, please, do not hesitate to contact us.
Best regards,
Review #1
R1.1 “[Review Comment]”
- The overall structure, with sections like 2 and 4 lacking elaboration and needing subdivision based on keywords such as API Application Programming Interface and Information Medical Interoperability.
Our answer: “[Authors Answer]”
We have added the subsection titles "2.1 Medical Information Interoperability", "2.2 Application Programming Interface (API) Challenges", and a new subsection "4.2 Research Limitations and Future Trends"
R1.2 “[Review Comment]”
- Figure 2's description of the Interoperability APIs Architectural Design suffers from low image quality and unclear text.
Our answer: “[Authors Answer]”
To address this situation, we ensured that Figure 2 has a resolution of 300 DPI and have kept it at its original size.
R1.3 “[Review Comment]”
- Figure 1 could benefit from incorporating activity or state diagrams from the UML modeling language.
Our answer: “[Authors Answer]”
A state diagram of the HCE class has been integrated as Figure 4, where a brief explanation (page 7) of the operating conditions for the abstract factory and the states that need to be reached in the wrapper pattern operation is included.
R1.4 “[Review Comment]”
- In-depth discussion on how the paper addresses situations like the COVID-19 pandemic in services should be included in the sections on research limitations and future trends.
Our answer: “[Authors Answer]”
We have included a discussion and introduced the subsection titled: "4.2 Research Limitations and Future Trends"
R1.5 “[Review Comment]”
- The paper's reference format doesn't align with the journal's requirements, with many references lacking essential information.
Our answer: “[Authors Answer]”
We have reviewed and corrected the references that were incomplete or incorrect.
Author Response File: 
Author Response.docx
Reviewer 2 Report
Comments and Suggestions for AuthorsThe paper explores the development of an API to enhance interoperability in medical systems, particularly in exchanging patient medical history information. The authors identify the heterogeneity of medical information systems as a significant challenge and propose an object-oriented approach utilizing design patterns like Abstract Factory and Wrapper to manage memory efficiently and address interoperability issues. They evaluate the API's performance based on complexity and coupling, indirectly achieving a satisfactory level of 62.5 percent through operation sequences assessment.
Drawbacks:
1. The evaluation primarily relies on indirect measures of performance (complexity and coupling), which may not fully capture the API's effectiveness in real-world scenarios.
2. The paper acknowledges the difficulty in quantifying abstract classes, suggesting a potential gap in the analysis framework.
3. The reliance on specific standards like HL7 CDA might limit the API's flexibility to adapt to various contexts and data needs, especially for large volumes of information.
Recommendations:
1. Conduct direct performance evaluations, including real-world testing in medical centers, to better understand the API's impact on interoperability and efficiency.
2. Develop or integrate additional analytical models that can effectively quantify the contribution of abstract classes to the overall system performance.
3. To improve flexibility and adaptability, the API should consider integrating standards like OpenEHR, which provides a richer semantic representation of clinical information, alongside HL7 CDA.
4. Increase the size of the Figure 2.
5. It is recommended that the current research analysis be expanded with an overview of web-based systems, e.g., doi: 10.3390/healthcare11070959 doi: 10.1109/STC-CSIT.2018.8526684
These recommendations aim to address the identified drawbacks and enhance the proposed API's effectiveness and applicability in achieving interoperability in medical information systems.
Author Response
Dear Editor and Reviewer,
We have found the reviews to be very helpful and we would like to thank the reviewers for their valuable feedback that allowed us to improve this work.
We have seriously taken into account each comment and modified and enhanced the article accordingly. Based on your feedback, we have prepared a revised version of the article, where the changes have been highlighted with red text. All the comments (major and minor) have been addressed.
Further, in this letter, we use the following convention to identify the questions and comments from reviewers. As such, Ri.j means Question/Comment j of Reviewer i (i=1,2). In order to discuss the reviewers’ major comments, a detailed response follows, where the original text of reviewers is reported in italics and our response follows.
If you require any further clarification about this revision of the article, please, do not hesitate to contact us.
Best regards,
Review #2
R2.1 “[Review Comment]”
- Conduct direct performance evaluations, including real-world testing in medical centers, to better understand the API's impact on interoperability and efficiency.
Our answer: “[Authors Answer]”
We have included a discussion and introduced the "4.2 Research Limitations and Future Trends" subsection. In the last paragraph, the limitation under discussion is as follows:
“ The proposal addresses the pressing need for interoperability in medical information, particularly underscored in the post-COVID-19 era, where its pivotal role in facilitating accurate diagnoses and effective treatments for patients is widely acknowledged. The primary objective is to enhance the architecture of the Medical Interoperability API software through an object-oriented approach and the seamless integration of design patterns. Emphasis is placed on refining the design to accommodate devices with limited memory capacity. Furthermore, this initiative lays down a robust framework for early evaluation and enhancement of the software architectural design, thus mitigating costs in the API development lifecycle. However, a significant challenge arises during the Design phase, stemming from the difficulty in assessing the practical effectiveness of the proposed architecture in real-world scenarios. Evaluation predominantly relies on static methods using predictive models and formal techniques. Additionally, a practical implementation may face hurdles due to resource constraints, compatibility issues with existing platforms, and the intricate nature of integration with established healthcare systems.”
R2.2 “[Review Comment]”
- Develop or integrate additional analytical models that can effectively quantify the contribution of abstract classes to the overall system performance.
Our answer: “[Authors Answer]”
In the GCA analysis, the abstract class Factory_HCE was included, assigning values of 1 and 0 to the CCM and CBO metrics, respectively. These values were established considering that the implemented methods are sequential; according to McCabe, a sequential procedure has a complexity of 1. Regarding Coupling, it was considered zero since the object does not compose any other element. In the previous study, this class was not considered because its methods are not defined and do not intervene in the treatment of information. It was very enriching to observe how, by including the abstract class Factory_HCE in the GCA design, and despite being a deterministic model, the complete evaluation scheme showed notable improvements in the API design. The scatter plot showed values closer to +1 and the number of critical paths decreased. Taking into account these new results, Table 3, Figure 5, and Figure 6 were updated.
R2.3 “[Review Comment]”
- To improve flexibility and adaptability, the API should consider integrating standards like OpenEHR, which provides a richer semantic representation of clinical information, alongside HL7 CDA.
Our answer: “[Authors Answer]”
We have addressed discussions in subsection "4.2 Research Limitations and Future Trends", as well as at the end of section 5 Conclusions.
R2.4 “[Review Comment]”
- Increase the size of the Figure 2.
Our answer: “[Authors Answer]”
To address this situation, we ensured that Figure 2 has a resolution of 300 DPI and have kept it at its original size.
R2.5 “[Review Comment]”
- It is recommended that the current research analysis be expanded with an overview of web-based systems, e.g., doi: 10.3390/healthcare11070959 doi: 10.1109/STC-CSIT.2018.8526684
Our answer: “[Authors Answer]”
We have included the reference DOI: 10.3390/healthcare11070959 as [21], referencing Banaee, H.; Ahmed, M.U.; Loutfi, A. "Data Mining for Wearable Sensors in Health Monitoring Systems: A Review of Recent Trends and Challenges." Sensors (Basel). 2013 Dec 17;13(12):17472-500. doi: 10.3390/s131217472 in the related work section.
Author Response File: Author Response.docx
