The Problem. Many healthcare applications deal with data entry, and the methods through which data is validated are important software development considerations. In short, treatment cannot be withheld because of the requirements of a software application.
For Example. A data entry form, such as a form that records patient demographics, typically has a set of required fields. Normally, the patient identifier, first name, last name, gender, phone number, address line 1, province, city, and postal code are required. It is possible, however, that a patient arrives by ambulance at the emergency department alone and is unable to speak. How can the patient be entered into the system if the software stubbornly requires fields that are not immediately necessary?
In practice, false information is usually entered and corrected once is the true identity of the patient is known. The solution is sloppy, but it gets the job done. In other situations, however, information cannot be corrected at a later date.
Consider worksheets in which questions are dependent on each other with rules such as “if Question 2 is answered, then Question 3 must be answered too.” If the situation arises in which the user answers Question 2, but is unable to answer Question 3, the application and the user can be indefinitely blocked. In the case where Question 3 is a radio button list or a drop down list, any false answer provided will conflict with legitimate answers. Once data like this enters the database, analysis becomes difficult since the two types of answers – the false and the legitimate – will be indistinguishable.
Solution. Good healthcare applications keep the number of required fields to a minimum, ensure that only the most important information is required, or give users the option to skip the input field. When a patient is undergoing a test or is sitting in a consultation room, information may not be known and the delivery of care must be allowed to proceed.
In other cases, a patient may prefer to not provide certain information when they do not feel comfortable proceeding with a test or measurement. Since a patient can conceivably reject any portion of a test, every field should be optional in this case. Even if the patient does not stay for a test, the technician or physician must still record the fact that the patient arrived and refused to do the test.
Since other parts of an application or form may depend on fields that are left blank, software developers must ensure that the application can still function without error or alert the user that the data is missing. There must also be provisions in place to manage the incomplete data so that it can be entered once it is known. In the case of the patient who cannot speak upon emergency room admission, the information can be obtained from the patient’s family or from the patient himself once he can speak. If the patient refuses a portion of a test, any automated statistics or reports generated from the data collected from the visit must either indicate the refusal to participate or be adjusted so that the application can still function properly.
To summarize, effective input validation in a healthcare environment should follow these input validation best practices:
- Input validation should not block users from submitting a form.
- Keep the number of required fields to a minimum. A field should only be required if its absence obviates the form in its entirety.
- Provide defaults or other mechanisms to handle when data cannot be provided instead of requiring the data to be entered.
- Users should be able to skip questions and complete them later, however dependence between questions should be functional in that there is no way for one to be answered without the other being answered first.
- Data quality checks should account for incomplete or ‘fake’ placeholder data and advise users to complete the data entry once the values are known.
- Downstream data consumers must continue to function and raise alerts in case they are fed with incomplete data.
By understanding the range of possible validation errors and the risks associated with them, your team can ensure that medical care is never delayed because of a software requirement.
The Problem. Developers often think that application crashes are the most serious problem a healthcare program can exhibit. While a crash is obviously not an ideal outcome, hospital processes are well established to deal with software crashes. Of far greater inconvenience is an application that makes a clinical worker’s job more difficult while behaving as designed.
Due to the emphasis on application stability, software teams with little healthcare experience often put too much emphasis on verification and not enough on software validation. Software can always be made to do what you want it to do (verification), but it is noticeably harder to be sure that you are building the right software for the job (validation). In the healthcare arena, software validation is critically important and while it is easy to simply allocate time for software validation, the actual validation process requires experience with a thorough validation process as well as strong domain expertise.
For Example. Many healthcare applications can be fully tested and agree with requirements yet be rejected in practice. Such problems are worse than crashes because their root cause is a miscommunication between the client and the development team. Sometimes these issues can be quickly fixed but more often than not, they require a substantial change or complete re-think of the problem.
Some validation errors are basic in nature, such as an input box not accepting the value being entered because of a misunderstanding of bounds. A developer, for example, might assume that all blood pressures are numerical and that all blood pressures have both a systolic and diastolic component. In practice however, it is sometimes difficult for a physician to measure the diastolic blood pressure component. In these cases, the practitioner would normally want to enter non-numerical values such as “125/?” or “125/P” for “125 over pulse.”
In more serious examples, we’ve seen software rejected because it lengthened the amount of time a doctor had to spend per patient as a result of it poorly mapping to the organization’s business processes, or because the development team had overlooked the fact that their software had to integrate with a major external system, like an external billing system.
Solution. Problems like those described above can be avoided if they are identified through a rigorous software validation process. This validation period must also be used to test all exceptional and rare (from a healthcare viewpoint) cases so that the application can be sure to integrate into the environment in even the most unusual circumstances.
A good software validation process will catch these problems before too much development work has been completed. Moreover, an agile software development process can be appropriate for certain types of healthcare application development, such as patient management and EMR software development. With an agile process, the application can be tested and deployed at various milestones of the development cycle. An agile process allows for more opportunities to perform software validation and ensures that it is conducted early in the project lifecycle.
Software validation allows users to report on any problems they have seen and gives users confidence that the application will fit into their workflow and do everything it is needed to do.
While a crash in any application is a serious error, a program that crashes from time to time can still be used if it solves the business need it was built to solve. In practice, these applications are simply restarted or corrected by some kind of workaround.
Software developers need to remember that a program won’t crash if no one uses it. Development teams should therefore ensure that they have the required healthcare software validation process and expertise on hand whenever they tackle a healthcare project.