Technical Challenges in using OpenEMR

As part of the ARPA-H Digiheals project, we have been studying the interoperability and usability of various open-source electronic health record systems, including OpenEMR. These modern systems support some combination of the Consolidated Clinical Document Architecture (C-CDA) and Fast Health Interoperability Resource (FHIR) standards to export patient data. In our first study, we asked how a synthetically generated XML file (using Synthea) is consumed by OpenEMR and whether OpenEMR can re-import an XML file it previously exported.

OpenEMR cannot import CCDA XML files it exported

OpenEMR implements a FHIR REST API and a native REST API. The FHIR REST API, however, does not implement functionality to import FHIR data. Instead, OpenEMR imports and exports C-CDA Continuity of Care Documents (CCDs). These files can be uploaded and exported from the web interface, and the FHIR REST API supports exporting these CCD XML files. We followed these steps: (1) Import a Synthea-generated XML file, (2) Export the CCD file from OpenEMR, and (3) Import the exported file again. However, we observed that OpenEMR would not import these files. OpenEMR would respond with an HTTP 500 error message (Internal Server Error). Upon inspecting the OpenEMR code, we noticed that they use two XML libraries (SimpleXML and xmljson), creating more possibilities for parser differentials.

The OpenEMR team fixed these bugs promptly after our three bug reports on May 1st 2024, April 27th 2024, and April 13th 2024.

Data Integrity not entirely maintained while parsing EHR in OpenEMR

Maintaining the integrity of patient medical health records is especially important while handling them. Subtle differences were observed between the imported patient files stored in OpenEMR, identified when importing the Synthea C-CDA XML file to OpenEMR, then exporting the same data. Firstly, time and timezone information was stripped from the timestamps. The DateTime format was simplified to just displaying the date, which could pose an issue for events where the exact time is critical. Next, we observed changes in the vaccine descriptions; for instance, short names of vaccines were used in the original file, and these were transformed to their full names on export. Such transformations could affect the consistency and reliability of patient health records handled within OpenEMR.

Limitations to file uploads in OpenEMR

OpenEMR’s php.ini configuration file manages the system’s memory configurations. The recommended PHP settings are mentioned on their wiki page. The challenge we faced was when we tried to import large CCDA XML files (~14MB and above), which caused node import service crashes and stack overflow errors seen in the Apache logs. We could temporarily resolve these errors by increasing the memory limit beyond the recommended setting (512MB). However, we believe that a reasonably large file would still crash the node import service.

Disclaimer: This work was performed as part of the ARPA-H DIGIHEALS program under Contract No. SP4701-23-C-0089. The views, opinions, and/or findings expressed are those of the author(s) and should not be interpreted as representing the official views or policies of ARPA-H or the U.S. Government.