Performance assessment and tuning for exchange of clinical documents cross healthcare enterprises

Highlight
• We conducted performance testing to investigate the performance and limitations of this EHR/OpenXDS system.
• The performance testing was conducted for three use cases, EHR submissions, queries, and retrievals, based on the IHE XDS.b profile for EHR sharing.
• We retrieved the transaction logs and also monitored the consuming of hardware resources during the test cases execution to detect more details of the EHR/OpenXDS system's limitations.
• From the testing results, we provided tuning suggestions and future works for the following implementers/studies to keep improving the EHR/OpenXDS system.

BackgroundTo integrate electronic health records (EHRs) from diverse document sources across healthcare providers, facilities, or medical institutions, the IHE XDS.b profile can be considered as one of the solutions. In this research, we have developed an EHR/OpenXDS system which adopted the OpenXDS, an open source software that complied with the IHE XDS.b profile, and which achieved the EHR interoperability.ObjectiveWe conducted performance testing to investigate the performance and limitations of this EHR/OpenXDS system.MethodologyThe performance testing was conducted for three use cases, EHR submission, query, and retrieval, based on the IHE XDS.b profile for EHR sharing. In addition, we also monitored the depletion of hardware resources (including the CPU usage, memory usage, and network usage) during the test cases execution to detect more details of the EHR/OpenXDS system's limitations.ResultsIn this EHR/OpenXDS system, the maximum affordable workload of the EHR submissions were 400 EHR submissions per hour, the DSA CPU usage was 20%, memory usage was 1380 MB, the network usages were 0.286 KB input and 7.58 KB output per minute; the DPA CPU usage was 1%, memory usage was 1770 MB, the network usages were 7.75 KB input and 1.54 KB output per minute; the DGA CPU usage was 24%, memory usage was 2130 MB, the network usages were 1.3 KB input and 0.174 KB output per minute. The maximum affordable workload of the EHR queries were 600 EHR queries per hour, the DCA CPU usage was 66%, the memory usage was 1660 MB, the network usages were 0.230 KB input and 0.251 KB output per minute; the DGA CPU usage was 1%, the memory usage was 1890 MB, the network usages were 0.273 KB input and 0.22 KB output per minute. The maximum affordable workload of the EHR retrievals were 2000 EHR retrievals, the DCA CPU usage was 79%, the memory usage was 1730 MB, the network usages were 19.55 KB input and 1.12 KB output per minute; the DPA CPU usage was 3.75%, the memory usage was 2310 MB, and the network usages were 0.956 KB input and 19.57 KB output per minute.Discussion and conclusionFrom the research results, we suggest that future implementers who deployed the EHR/OpenXDS system should consider the following aspects. First, to ensure how many service volumes would be provided in the environment and then to adjust the hardware resources. Second, the IHE XDS.b profile is adopted by the SOAP (Simple Object Access Protocol) web service, it might then move onto the Restful (representational state transfer) web service which is more efficient than the SOAP web service. Third, the concurrency process ability should be added in the OpenXDS source code to improve the hardware usage more efficiently while processing the ITI-42, ITI-18, and ITI-43 transactions. Four, this research suggests that the work should continue on adjusting the memory usage for the modules of the OpenXDS thereby using the memory resource more efficiently, e.g., the memory configuration of the JVM (Java Virtual Machine), Apache Tomcat, and Apache Axis2. Fifth, to consider if the hardware monitoring would be required in the implementing environment. These research results provided some test figures to refer to, and it also gave some tuning suggestions and future works to continue improving the performance of the OpenXDS.