Background To 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. Objective We conducted performance testing to investigate the performance and limitations of this EHR/OpenXDS system. Methodology The 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. Results In 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 1380MB, the network usages were 0.286KB input and 7.58KB output per minute; the DPA CPU usage was 1%, memory usage was 1770MB, the network usages were 7.75KB input and 1.54KB output per minute; the DGA CPU usage was 24%, memory usage was 2130MB, the network usages were 1.3KB input and 0.174KB 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 1660MB, the network usages were 0.230KB input and 0.251KB output per minute; the DGA CPU usage was 1%, the memory usage was 1890MB, the network usages were 0.273KB input and 0.22KB 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 1730MB, the network usages were 19.55KB input and 1.12KB output per minute; the DPA CPU usage was 3.75%, the memory usage was 2310MB, and the network usages were 0.956KB input and 19.57KB output per minute. Discussion and conclusion From 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. 
Performance assessment and tuning for exchange of clinical documents cross healthcare enterprises