Healthcare Software

Doctors Have No Patience for Software that Doesn’t Save Them Time

The Problem. Software developers often create systems without considering the time restrictions that healthcare practitioners face. In today’s hospitals, healthcare workers are dealing with growing patient waiting lists and need to be able to get their jobs done as efficiently as possible. They cannot afford to wait for software and will be unwilling to do so.

In an example of the Cedars Sinai Medical Center, physicians found that it took much, much longer to use the new computer system than it did to do the same ordering with pen and paper. With physicians already working 80 hours per week, there just wasn’t the extra time available.

In some cases, users can knowingly (or unknowingly) shortcut the slow aspects of an application to reduce the time they must wait. This behavior, however, can exacerbate design flaws and lead to even bigger problems.

For Example. Doctors order diagnostic tests every day. These tests produce reports that are then sent back to the referring doctor. The tests themselves, however, generate data that can be needed by other downstream systems within the hospital, such as billing and inventory management systems.

In a real-life example we have seen, the diagnostic test was a nuclear imaging scan. When the doctor marked the case status as “completed and closed,” a report was generated. The data was then passed to the billing system so that the case would be billed for, and to the hospital management system so that inventory counts would be adjusted.

To reduce the load on the diagnostic system that collects the data, the data was transferred to the reporting system, which then acted as the resource for the other dependent systems.

A doctor could order the test, walk out of the room and complete the report based on the information he remembered from the case. When he completed the report, he would close the case.

The problem was that data transfer from the data collection system to the reporting system stopped as soon as a case was closed, so in this case, the doctor’s actions would accidentally cause all downstream systems to only have access to partial data, resulting in inaccurate billing and inventory management.

Solution. To avoid the example scenario, designers of a new system would have needed to be aware of the doctor’s desire to get clinical paperwork out of the way as quickly as possible. The system should not have halted the data transfer when the clinical case was closed.

More generally, software systems in healthcare domains need to be very responsive and inform the user about what the application is doing. In a system with long-running tasks or data transfers, make sure to ask yourself the following questions:

• Are blocking operations as short as possible? Short blocking times will make sure that users are not kept waiting.
• Are progress indicators provided and are they accurate? If users do need to wait, progress indicators will allow them to know how long it will be until they can regain control.
• Are network data transfers atomic and able to recover from failure? When large amounts of data have to be transferred, they should be atomic – in other words, they should either happen in their entirety or not happen at all. When dealing with a patient case or a hospital visit, a non-atomic transfer could leave partial data in a remote database. If there is a network error or the receiving application stops the transmission, it should be possible to resume the transfer without duplicating or overwriting data.
• Are users aware of impacting operations that run in the background? When an application features jobs that run in the background, these activities can slow down the normal speed of the program. The user should be made aware that such jobs are running so that they do not attribute a lag in the application’s performance to an unknown or unresolved problem.
• Are there any alternate designs to speed up operations? Sometimes a design may work but not be the most optimal configuration available. In many cases, a simple “rethink” in how things are done can improve operations significantly. Caching interface components, for example, can offer performance gains by eliminating the need to access databases or other networked resources.

By thinking about each of these questions, your team will be able to properly address delays or dependencies in your application and provide the user with clear indications of when he needs to wait and when he can proceed with his tasks.

Model Hospital Processes before You Write a Line of Code

The Problem. Healthcare software needs to map properly to the existing business processes in place and must not negatively affect nor significantly change these processes. Hospital processes are organic in nature and if software places additional demands on the existing process, users will choose to revert to the “old way” of doing things. As a result, it is vital that all processes be understood and documented.

For Example. Think of hospital processes as a set of conveyor belts. In a very simple example, a patient could go through the admission process, the diagnosis process, the treatment process and the discharge process on the same visit or on multiple visits. The patient will be on one of these process-conveyor belts at any moment in time. Within a hospital there are many such processes – each with its own intricacies.

Solution. Each hospital process must be fully understood before any software can be designed to support it. A tried and true method for understanding processes is to do the following:

1. Model your understanding of the existing process
2. Repeat (as many times as possible):
   1. Present the model to all the actors involved in the process
   2. Update the model according to the feedback received
3. Pass the model back to the software designers

In software engineering, these steps are taken during the early requirements phase and different tools can be used to do the modeling. One that is easy to use is called jUCMNav. It models processes by way of use case maps. You can see an example of this for a patient registration process in the figure below. These maps are translated into requirements which are then used to design the software.

A jUCMNav example of patient registration

To understand all of the existing processes, it is important to involve a range of end users as well as someone who understands the processes from a high level, such as a departmental manager. These people can comment on the accuracy of your business process model and critique it.

Many of these users may never have visualized the processes before, and you may even be able to suggest certain optimizations or predict how the processes might change in the future. This can help you gain user trust and become viewed as a valuable partner in the organization’s operations.

Typically the business processes manifest themselves within the software as user workflows in which each user must complete a set of tasks before passing the case over to the next user. It is therefore important to fully map out user workflows and understand who is doing what – and when.

In our experience, the success or failure of a healthcare application is often tied to the accuracy of the business process models and on how well the software is able to adapt as processes change. When mapping out healthcare processes, be sure to have a usability expert on hand that is adept at gaining end-user involvement. This expert can help you ensure that your team gains a solid understanding of the processes that will be touched by your software.

Privacy restrictions and usability requirements must be balanced

The Problem. The development of electronic health records has made patient privacy a top concern of end-users, healthcare organizations and governments alike. Governments have created laws (HIPAA, PHIPA) that impose penalties on organizations that fail to protect their electronic data from misuse. These laws are, in turn, applied to other organizations involved the electronic exchange of health information. In 2009, for example, the HITECH act mandated compliance with HIPAA for all covered entities.

From a software developer’s point of view, these laws essentially require the implementation of two systems: access control and an audit trail. While these systems are simple in principle, it is important to ensure that they are developed in a structured fashion that addresses privacy laws while maintaining user flexibility.

For Example. Privacy laws are needed because people have a desire to keep most medical aspects of their lives private. Hospital workers, however, have been known to access and distribute patient records inappropriately. Healthcare organizations require the means to determine whether a privacy violation occurred – and to determine who is to blame.

In recent years, a number of high-profile privacy breaches have come to light and have increased awareness of the need for stricter privacy protections. These breaches include:

• Octomom's hospital records accessed, 15 workers fired
• Britney Spears: Hospital Workers Fired For Looking At Singer's Medical Records
• Sixteen Houston Hospital Workers Fired for HIPAA Violation
• 20 Hospital Workers Fired for Viewing Collier's Medical Records

Solution. When developing clinical software, be sure to balance access control and audit trail mechanisms carefully. The software must respect privacy laws, but should not prevent users from accomplishing their tasks efficiently.

In the healthcare industry, a good audit trail allows for a relaxed access control mechanism. The best access control policies are those that are not overly restrictive – they should simply offer an override mechanism to prevent inappropriate access. Emergencies arise, and the law allows access to personal data in a life and death situation. In a practical environment such as a hospital, a healthcare professional may have a very good reason to access a record without justifying so beforehand.

Implementing access control is relatively straight forward. Access control restricts actions such as viewing, editing or deleting data elements. Typically, access control is implemented by user role so that all users of a particular role all have the same privileges.

There are two basic design approaches for role-based access control:

1. Access control policies are loaded per page or screen
2. Access control policies are loaded once per user session

The first approach requires more frequent database access but results in more dynamic access control behavior. Here, although user privileges can be revoked or granted instantly, the need for loading the access control policies can slow down the server – especially when there are many concurrent users. The second approach suffers from a lack of control over access policies, since a user can have his privileges revoked but still be allowed to continue until the end of his session. Either of these policies, however, would be sufficient to address the access control requirements of HIPAA law and even CCHIT certification in the case of electronic medical records.

A third, more advanced method of access control requires the people involved to be defined on a case-by-case basis. A hospital may decide, for example, that only medical staff involved in the care of a particular patient should be allowed to access that patient’s file. In this case, only staff meeting that defined criterion would be allowed to perform any actions on the patient’s data. If someone new required access, this user could authenticate himself (the action would subsequently be audited) or have an administrator add him to the system. This method of access control is more precise, but it also uses more overhead than the two basic approaches detailed above.

Access control systems should always allow users to override system restrictions in emergency situations. In these cases, the system should force the user to confirm that he is overriding the controls in place. To ensure that this sort of emergency behavior is tracked, a solid audit trail is required.

An audit trail serves as a record of all events that can occur through the normal use of the application. The audit trail records events such as “user x viewed the record for patient y.” Having an audit trail in place is also of value because it alerts users to be careful when accessing data since they know their actions are being recorded.

There are three standard ways to implement an audit trail:

1. Save to a log file. This is normally referred to as an “audit log” as opposed to an audit trail. In this case, actions are recorded in a pre-defined format in a file rather than a database. File system privileges for the file must be restricted so that only a trusted administrator has access. This log file should also reside on storage with redundancy in place.
2. Save to a database. This implementation is more in line with accepted best practices, namely audit trail and node authentication. All actions are stored in a separate database instance used only for audit records. The physical machine should be on a protected network such that only an administrator has access. The format of the audit record can take any form as long as it records the user, the patient, the date and time and the data that was modified (if applicable).
3. Record every database action. It is possible to implement an application such that every SQL command along with the parameters and the user associated with the session that invoked the command is saved. This method provides very fine-grained detail, but the low-level nature of the data collected can make it very difficult to trace access breaches.

A good audit trail should also provide an interface through which activities can be monitored, and this interface should generate alerts when data is accessed inappropriately.

Working hand in hand, a reasonable access control approach and a solid audit trail mechanism will ensure that privacy laws are respected. Since privacy is a top concern within today’s healthcare organizations, these laws – and the steps needed to conform to them – must be taken into account during the software development process. Working with a software development partner with healthcare sector expertise can help you ensure that the software includes proper access controls and audit trail mechanisms that do not negatively impact the product’s usability.

Requirements Must be Tailored to a Practitioner’s Specialty

The Problem. Software teams do not always realize the extent to which requirements depend on the specialization or generality of the clinical users. A general practitioner, for example, will not have the same requirements as a physician specializing in cardiology.

When we walked the exhibit floor at HIMSS10 and investigated the 100+ electronic medical record products, we noticed an overwhelming number of "general practitioner" and "one size fits all" software. These solutions will inevitably frustrate any clinical specialist who was sold on the idea that the product was designed for him.

Even if your software is designed for a particular specialty, obtaining accurate requirements in the healthcare domain can be very challenging. Often, those tasked with collecting requirements will be tempted to cut corners in order to avoid taking more time away from healthcare professionals whose main priority is to treat patients.

In cutting corners, assumptions are often made based on past experiences with other projects. This leads to software that does not meet the user’s needs.

For Example. Consider the different types of software that could be used by typical doctors. In a drop-in medical clinic, software records the nature of consultations that take place between doctor and patient. The software must also handle daily patient queues, but precise scheduling is not necessarily required.

On the other hand, a specialist at a teaching hospital requires software that records data from consultations and makes it available to be searched through at a later date. These doctors are not only interested in treating patients – they are also interested in evaluating the outcomes for patients with a particular disease and in detecting trends among the population.

In the drop-in clinic, the software designer can simply write software that provides human readable data. In the second case, the software must be designed to give access to the fine-grained data stored in the back end.

Solution. During the requirements gathering phase, the software team needs to keep in regular contact with healthcare professionals who are specialists in the domain for which the software is being built. If your team feels that it is taking up too much of a professional’s time, spend more time synthesizing the requirements so that they can be easily and quickly understood.

Presenting healthcare professionals with use cases (not in UML, but in scenario form) with figures will help you confirm your understanding of their needs.

Ideally, the people interfacing with the clinical staff should be usability experts with deep healthcare knowledge so that domain terminology can be used. These experts are often the best people for the job since they are trained to ask the right questions and analyze user behavior. Ultimately, they can help to ensure that a complete and accurate set of requirements are gathered in a short amount of time.

What Does the FDA Check when it Audits your Source Code?

Code compilation

• Make sure that the strictest options for error checking are used.
• Verify the existence and correctness of the documentation of the compilation process.
• The absence of warnings or other alerting messages during the compile.

Coding guidelines

• Check for a document specifying your coding guidelines.
• The guidelines should provide details about clarity, style, complexity management and commenting.
• The code is checked to make sure it adheres to the coding guidelines.

Comments

• Comments need to be useful and descriptive for a module, should list the expected inputs and outputs, variables referenced, expected data types and operations performed.

Design specification

• Check that the source code agrees with the specified detailed design specification.
• Check that everything in the detailed design specification is in reflected in the code.
• Modules should be documented for their compliance to coding standards and other stated quality policies and procedures.

Test cases

• Check that the tests for modules and functions can be traced to the code for the same modules and functions.
• Test cases for modules and functions can be traced to the correct modules and functions in the detailed design specification.
• Verify test coverage for modules, integration, system and acceptance.

Process documentation

• Documentation for procedures used and the results of the source code evaluation should be maintained as part of design verification.