EHR Testing: Specifics And Best Practices
By Andrei Mikhailau, ScienceSoft
We look at the specifics of EHR testing and share best practices that increase the quality and velocity of the testing process.
As EHR software deals with sensitive information and regulates the processes bound directly to patients’ health, it should be thoroughly tested. However, the complexity of EHR software can impede EHR testing process. In the article, we’ve highlighted the testing types EHR should undergo and shared best practices for improving the quality of EHR testing.
Testing Types EHR requires
EHR systems call for a special approach to testing and need to be validated with the emphasis on functionality, usability, interoperability, compliance, and performance.
Functionality
EHRs feature multiple workflows, from patient admissions and insurance verifications to obtaining laboratory results and issuing medication prescriptions. Also, the workflows may vary among healthcare professionals and among different healthcare facilities. During functional testing, a test engineer needs to verify that each workflow complies with the requirements specification.
To achieve optimal test coverage without compromising on testing quality, functional testing of EHR software can be performed based on the functional importance of workflows and the business risk associated with their not functioning as intended. For instance, as medication order prescription is critical in both aspects, it is classified as high-priority and tested first, with multiple test cases and across different environments. In its turn, medication order search is of less criticality, hence, the workflow is assigned a medium priority and tested once and only in the testing environment.
Interoperability
Typically, EHRs are integrated with such systems as laboratory information systems (LIS), radiology information systems (RIS), picture archiving and communication systems (PACS), department-specific systems, patient portals, and more. Among these systems, the information is exchanged in a number of formats. A test engineer should validate that data transfer in each format complies with relevant interoperability standards.
Health Level 7 (HL7) v.3 sets standards for the exchange, integration and retrieval of personal health information (PHI) in the XML format. To validate EHR’s compliance with HL7, a test engineer verifies that EHR’s communication modules exchange and process PHI without errors and validates that the data flows correctly among EHR and external software systems.
Fast Healthcare Interoperability Resources (FHIR) simplifies the mechanism for exchanging and retrieving health information by creating standard URLs for units of information called resources (administrative resource, for instance, includes the information about a patient, a healthcare organization and its location, a practitioner, and more). To check EHR for FHIR conformance, a test engineer verifies that the exchanged information is factually and structurally correct (FHIR provides a schema for XML, JSON, HTTP, Atom and OAuth).
Digital Imaging and Communications in Medicine (DICOM) is a standard for medical image exchange. A test engineer validates that EHR interprets the received DICOM messages correctly.
Usability
As usability flaws can impede healthcare professionals’ experience with EHR software and, in extreme cases, put patients’ health under threat, it is important to validate the convenience of EHR based on relevant user roles and scenarios. A test engineer should validate that each transaction completed by the clinical staff at each step of a patient’s appointment or admission (e.g., examination, diagnosing, treatment, scheduling an upcoming visit) complies with the requirements specification and HIMSS’s principles of EMR usability.
Compliance
The HIPAA Security Rule’s technical safeguards require EHRs to have the following precautionary features against data security violations:
Access control. A test engineer verifies an EHR for user identification, user authentication, and emergency access procedures.
Audit control. A test engineer validates that a system’s activity logs consistently record all user activities with the focus on the attempts to access PHI and make sure that logs provide sufficient information.
Integrity. A test engineer validates that personal health information is protected from improper altering or unauthorized deletion by verifying that EHR features data integrity mechanisms and they function as intended.
Transmission security. A test engineer needs to verify that health information is safely encrypted and decrypted when transferred, as well as delivered to the recipient without any undesired changes.
Performance
Performance testing is carried out to validate an EHR’s functionality works according to the requirements specification under normal and extreme load. For that, a test engineer validates an EHR’s readiness for traffic spikes with load testing, as well as checks its response time, stability, reliability and velocity.
Best Practices For EHR Testing
To improve the quality of EHR testing, QA engineers can employ the following best practices:
- Performing Testing In Test And Production Environments
To increase test coverage, test engineers may execute tests in the production environment. While test environments may restrict completing certain actions (e.g., the possibility to create laboratory results for a test patient), do not usually feature integrations with external systems and have much less load, carefully controlled testing in production allows a test engineer to validate EHR from the perspectives of functionality and external integrations, and obtain a true sense of EHR’s performance.
- Combining Alpha And Beta Testing
Once testing activities in the test environment are completed, a new EHR build is deployed to production, but new functionality becomes available only to the limited number of alpha testers, who validate the new functionality on test patients. As soon as alpha testing is complete, the new build can be made available to a group of beta testers made up of a healthcare facility’s staff. The beta testers validate the new functionality on test patients, and then – on real patients. With alpha and beta testing completed, the new EHR build is released to all clinical users.
- Leveraging De-Identified Patient Data For A More Realistic Test Data Set
As a rule, the accounts of test patients do not perfectly reflect the accounts of real patients as their profiles can have either significantly more or fewer details. One of the ways to address the issue of unrepresentative test data is to use de-identified real patient data in order to create a more realistic test data set.
According to HIPAA, there are two proven ways to de-identify healthcare data. A test engineer can remove from the data set all specific identifiers, which include names, dates, geographic divisions smaller than a state, emails, phone and fax numbers, social security and medical record numbers, and more. An alternative is to remove some of the identifiers so that the information is no longer individually identifiable and the risk of re-identification is low enough to meet the HIPAA Privacy Rule Requirements.
To Sum It Up
To make sure that EHR software brings value for healthcare providers, it is important that it gets validated from the perspectives of functionality, interoperability, usability, compliance, and performance. At the same time, to improve the quality of testing, test engineers can resort to such practices as combining testing in the test and the production environments, combining alpha and beta testing, and using de-identified patient data for obtaining the more realistic test data sets.