Software-related challenges in Swedish healthcare through the lens of incident reports: A desktop study

Missing patient information

Of software functionality-related issues, four incidents were grouped under this theme (IR_9,12,19,21). Certain software functions caused patient information to be missing from the system. For example, a planned change to the drug module was made to the current version, preventing the text, i.e., ‘terms of benefit’ for elderly patients, from being displayed.

Two of these incidents fell under the HIT-CS category of ‘an incident with a noticeable consequence but no patient harm’ (IR_9,12), and the other two under ‘a hazardous event or circumstance’ (IR_19,21). The actions taken to solve these issues were correcting the program script and upgrading the software code with the bug fix.

Patient information not being saved

A couple of incidents (IR_4,10) were identified, which did not allow the ‘save’ function to save the information entered by the care staff. For instance, an error manifested itself after upgrading to a new version of the system, permitting an error message to pop up, namely ‘not possible to save’ for the waiting list item with an attached document.

These incidents were classified as ‘an incident with a noticeable consequence but no patient harm’ using the HIT-CS. In both cases, the error in the software was corrected, including the bug fix.

Software malfunction

Two incidents were determined within this theme (IR_28,31), causing the system not to work properly. For example, a computer in radiology stopped functioning due to software problems.

One of these incidents resulted in a noticeable consequence, i.e., delay in care delivery, and another with no apparent consequence. One of the problems was solved by correcting the software, and the other did not require any rectification as the risk was considered acceptable.

Additional information being created

Only one theme was generated under this theme (IR₈). The software functionality issue led to the production of additional templates; for example, a decision-support system automatically began to create a new treatment template from the previous ones.

The incident had no noticeable consequence; however, the issue was solved by developing a ‘hotfix’ for updating the program.

Sign-in problem

One incident was found to be incorporated with a ‘sign-in issue’ (IR₁₃). For example, a software error allowed the staff to sign into the system verifying the user's permission to sign against the current process, but not the required competence.

The incident could potentially lead to adverse events or near misses: however, the system error was corrected by changing the system.

Two patients being active in the system simultaneously

Six incidents were identified under this theme (IR_{2,5,6,17,18,22}). A common concern was noticed when two different patients were active simultaneously in two different components or modules of the same system.

One of the examples of such software interface-related problems was regarding context management when navigating from the occupancy list menu option ‘distribution check’ to ‘distribution list’. The error occurred in the flow when the user double-clicked on two patients belonging to different value units. The error meant two tabs with care documentation were displayed, one from each care unit. In one care documentation, the patient had not been activated, but there was an incorrect previous patient with a risk of confusion regarding patients.

These incidents resulted in ‘an arrested or interrupted sequence or a near miss’, according to the HIT-CS. These incidents did not reach the patients; however, there were risks of staff confusion, and medical decisions could have been made on incorrect grounds. Actions taken to solve the problems were based on the presence of software errors, for example, fixing the program code.

Transfer of patient information

Four incidents were grouped under this theme (IR_1,11,16,20). Of these, two incidents comprised ‘no transfer’ (IR_16,20), one consisted of ‘incorrect transfer’ (IR₁), and another was caused by ‘delayed transfer’ (IR₁₁) of patient information.

For instance, an interface issue occurred between an HIT system used in primary, child and school healthcare, responsible for communicating different types of care documents such as prescriptions, referrals and certificates, and a system incorporated into the National Vaccination Register. Communication software stopped the traffic due to an error in the conversion program, which was supposed to convert the vaccination data into a required format supported by the National Vaccination Register. This means that some other traffic was turned upside down and queued up, causing files not to be transferred.

Three of these incidents comprising ‘no’ and ‘delayed’ transfer of patient information resulted in ‘an incident with a noticeable consequence but no patient harm’, and the other in ‘an arrested or interrupted sequence or a near miss’. Several measures were taken to resolve the issues, for example, reconfiguring the system, restarting the service and correcting the program algorithm.

System designed to meet the data protection legislation

Of the system configuration-related issues, four incidents were categorised under this theme (IR_14,15,25,27). These incidents were reported based on the reporters’ perceptions regarding certain system functions intended to protect individual information based on data protection legislation.

For example, a medical record system, among other things, was used primarily in primary care and school health care—different types of care documents, such as prescriptions, referrals and certificates. Students’ personal information and information about class affiliation were regularly loaded into the medical record system from various student administrative systems. The student's guardian was also entered as a relative with contact information. A function in the system, i.e., ‘clear guardian before student import’, was set up to ensure that no marking for a person who was no longer a guardian remained and no disclosure of information to any unauthorised persons took place. However, the perception of the function ‘clear guardian before student import’ by the user or care provider was that all information about relatives marked as guardians should have been deleted. This was not the case; rather, it was only the tick for guardians for those who were removed. In practice, deleting the entire record would mean that all personal information about the parent who ceased to be a guardian would have disappeared from the system. This would then mean that personal data was processed without legal support, which was inappropriate and incompatible with data protection legislation and the ‘Patient Data Act'.

All of these incidents resulted in ‘an incident with no noticeable consequence’ in accordance with the HIT-CS. These incidents were not considered reportable cases because of the reporters’ misunderstanding and lack of awareness about the intended function of the system. Among several actions taken to reduce the risks was the assessment of the risks of unauthorised access to patient data and the sending of a formal incident notification to the Data Inspectorate.

System not designed to support the decision

Of these configuration issues, two incidents were reported as being associated with the system, which was not designed to support the decision of the care delivery (IR_3,23). As an illustration, there was an error in the product, which did not allow a given care intervention to be performed on the day it was supposed to. The care delivery was added for performance at a later date because the system's validation of entered dates and times forced the user to complete the performance on a date later than the present day.

These incidents posed severe risks to patient safety and were categorised as ‘harm to a patient or an adverse event’. Impact assessment and appropriate measures were recommended, including the software update to meet the required system criteria.

System not designed to give any warning/alert

One incident was identified for which the system needed to be designed to give a warning in case of exceeding the number of beds in the county-wide server (IR₂₄). Consequently, the system alarm did not mediate through the staff's alarm for the care event.

The incident posed the highest risks of causing ‘harm to a patient or an adverse event’, according to the HIT-CS. The error was recreated by several other customers and vendors and escalated with maximum severity and priority in both local administration and at the level of vendors.

Establish clear patient context in an interfaced healthcare environment

No matter how comprehensive a single product's features are, there will always be new HIT functionality and stand-alone software developed that need to be interfaced with the current system. A poor interface among them could confuse patient context management, such as two patients being active simultaneously.^32,33 A measure that can be taken to ensure that patient context is followed is adding a code for the ‘patient change’ function while handling mouse events that allow selecting a patient without triggering a patient change. Adding a ‘mouse handling event’ can also be another local HIT solution that allows selecting a patient without triggering a patient change when two patients are active simultaneously.

Other solutions may include entering a ‘delay’ in the program code so that two quick double-clicks on different lines in the Occupancy List cannot cause two patients to be active simultaneously on two tabs with care documentation. Additionally, a ‘risk-reducing measure’ may be adopted in the form of extra checks in the program code to ensure that the patient identities in both the tabs of Care Documentation are the same.

Ensure decisive information is displayed for decision-support interventions

This study outlined the software issues that supportive information was not provided in the form of an alert, which led to the neglecting of decisive information, such as the number of beds in the regional server exceeded, ending up with no warning. A potential solution to these issues could be adding an ‘alert’ in the program code so that decisive information cannot be neglected. Besides, it would be ideal that the alert has a clear call to action, concise text and a severity tier.^18,34 Using standardised terminology and colour schemes could further increase users’ sensitivity to decisive information.

Perform ‘robust testing/regression protocol’ in system design prior to deployment

Whilst software problems can be progressively ‘designed out’, it would seem that in the meantime, the dire need for appropriate testing to avoid or mitigate the occurrence of these errors in the field, which may have a more significant impact on the patient, providers and the healthcare in general. With considerable thought and ingenuity, some of the software errors can be phased out by identifying them in advance during robust testing or regression protocol in the development phase prior to the deployment of the system. For example, the software issues associated with software functionality and system configuration identified in our study could have been avoided if regression protocol had been conducted beforehand. ³⁵

Resolving HIT-related issues can be expensive in most cases, but the need for more adoption of these systems makes it worse in terms of time and resources. Bardhan and Thouin ³⁵ demonstrated in their study significant implications on the cost-quality trade-off related to using the HIT system. This implies that the application of HIT systems may result in cost inflation and be counterproductive if the healthcare workflow process ¹⁸ and different treatments ³⁵ (that work and those that do not) need to be properly understood.

Plan carefully for immediate local fixes and system transition

Risks associated with system issues, including system updates or upgrades, always exist in complex healthcare despite taking constant preventive measures.^18,36 In case of issues in upgrading a system, before investigating a problem, a check should always be made of whether similar errors had occurred before the upgrade took place. This should be done by identifying modules or components relevant to the problem and reviewing previous cases. It is possible that a module or component might have been gripped with a software error, for example, an external bug. Therefore, an upgrade with the ‘bug fix’ should be performed to restore any relevant module or component of the systems.

Ensure configuration and communication between HIT systems

Configuration of different HIT systems or the components of these systems are essential so that they are adequately interoperable. These systems should communicate with each other to ensure access to prior medical examinations.^37,38 For example, it is only sometimes possible that incorrect patient information from another care unit is sent from one patient information system to another due to human factors. The ‘processing step error’ may emerge when the message is translated from format A to format B, specifically in a program module that encodes text. The error may also occur due to multiple message threading problems, i.e., several message threads may be used against the Enterprise System platform. In this case, the current part of the system should be re-configured to use only one thread (in practice) to prevent collisions in the program module from occurring again. Deleting incorrect information manually from the patient record is also necessary in such cases.

Another example may involve the service on the communication platform, causing a delay in transferring messages. There may be a potential ‘memory leak’ in the service code or a shortage of memory on the communication platform, resulting in message traffic being stopped. In such a case, it is necessary to ‘restart’ the service on a regular basis. A routine for ‘automatic restart’ of the service (with manual monitoring) may be introduced/set up if not already in place to clear the queues in the message transfer that fall out as errors. This measure should be taken for all similarly affected installations by identifying similar software modules or components.

Additionally, the system can also be configured to operate the high volume of patient data transactions by setting the limit ‘high’ in the program code. This setting should be supplemented by supplying and adding the information of the maximum limit for ‘medical record transaction’ to the system protocol. This will eventually help healthcare professionals in understanding the system limitation in the transaction of patient records and mitigate the risks of unexpected events.

Provide training on general data protection regulation and information security awareness

Healthcare staff need to receive adequate paid time for professional training jointly organised by the healthcare organisation and HIT vendors.^26,39,40 When users misunderstood and were unaware of the software's intended purpose, they did not regard some incidents as reportable cases, and thus certain issues remained. When providing ongoing training for HIT end users, the importance of compliant incident reports should be highlighted. In addition, healthcare should receive guidance about data protection legislation and security awareness of the HIT applications. Such training can eventually mitigate the software-related incidents that are contributed by users. ²⁴

Suppose certain information, such as data on a patient's relatives, is missing in the patient record. Instead of assuming that the data has manually been deleted or not sent by the operator, one should look for the possibility that the information is designed for privacy as a default to meet the requirements of data protection legislation. It is also possible that the information about the relative has been removed because the person is no longer a relative; therefore, disclosing information to unauthorised persons may violate current data protection legislation. Sometimes, the patient may also refuse to transfer all or part of his/her medical record; however, this information must be noted in the medical records content assessments. Under the above circumstances, the care provider should not be under the impression that all information about the relatives should be deleted. Instead, information about the relative's data, such as address and contact details, must therefore be changed manually.

The privacy concern for the ‘data legislation act’ can also be solved by introducing a two-factor authentication function into the system when disclosing a person with a protected identity is necessary. The required information can be extracted using the technique of authorisation and access control, where access can only be made through authorised personnel after two-factor authentication. This will prevent the risk of unauthorised disclosure of personal data.