- Email: [email protected]
A framework for understanding process interoperability and health information technology
Health Policy and Technology (]]]]) ], ]]]–]]]
Available online at www.sciencedirect.com
journal homepage: www.elsevier.com/locate/hlpt
A framework for understanding process interoperability and health information technology Craig E. Kuziemskya,n, Liam Peytonb a
Telfer School of Management, University of Ottawa, 55 Laurier Avenue East, Ottawa ON, K1N 6N5, Canada b School of Electrical Engineering and Computer Science, University of Ottawa, Canada
KEYWORDS Health information technology; Interoperability; Process; Evaluation
Abstract Objective: While health information technology (HIT) offers great potential for supporting healthcare delivery, interoperability issues can be a barrier to effective use of HIT. While technical and semantic interoperability issues have been well studied there is a shortage of research that addresses process interoperability. Methods: This paper uses a two year case study of a Palliative Care Information System (PALIS) to study process interoperability and health information technology (HIT). We describe the design of PAL-IS and develop and describe three types of process interoperability issues that arose from its implementation. Results: The implementation of PAL-IS caused care delivery, clinical practice and administrative process interoperability issues. Further, many of these issues emerged over time and a solution to address one type of process interoperability issue often led to a different type of issue. We used our evaluation of PAL-IS to develop a general framework for understanding process interoperability and HIT. Conclusion: Designing HIT to support care delivery is a complex sociotechnical endeavor that can result in different types of process interoperability issues. Evaluating process interoperability takes time and longitudinal studies are necessary to understand the overall ecosystem where technology, processes, and people interact. The framework developed in this paper provides a starting point for the evaluation of process interoperability and HIT. & 2016 Fellowship of Postgraduate Medicine. Published by Elsevier Ltd. All rights reserved.
Introduction n
Corresponding author. Tel.: +1 613 562 5800x4792; fax: +1 613 562 5164. E-mail address: [email protected] (C.E. Kuziemsky).
The design and implementation of heath information technology (HIT) has not yet lived up to its potential to
http://dx.doi.org/10.1016/j.hlpt.2016.02.007 2211-8837/& 2016 Fellowship of Postgraduate Medicine. Published by Elsevier Ltd. All rights reserved.
Please cite this article as: Kuziemsky CE, Peyton L. A framework for understanding process interoperability and health information technology. Health Policy and Technology (2016), http://dx.doi.org/10.1016/j.hlpt.2016.02.007
2
C.E. Kuziemsky, L. Peyton
impact the delivery of healthcare services. In 2012 the Institute of Medicine published a report stating the present healthcare trajectory has become too complex and costly and that digital technology will be a key driver of improved healthcare delivery [1]. HIT has been advocated as a solution to assist health care authorities to better provide service delivery in the context of shrinking workforces and increased need for services [2–4]. However, to-date the evidence base on the use and impact of HIT is limited and inconsistent. While studies have advocated positive outcomes from HIT [5], there is also a substantial body of research reporting on negative outcomes including workflow, communication, and safety issues [6–8]. HIT implementation frequently cause unintended consequences including communication issues, creation of new or more work, and even adverse events such as medical errors [6,7]. Unintended consequences occur for several reasons including poor fit with clinical workflow, differences in needs between different user groups (i.e. clinicians and administrators) or the co-existence of manual and automated processes [9,10–12]. To reduce unintended consequences we need to understand the interactions between the users of a system and the different facets of the environment in which the system is used [13]. HIT is more likely to introduce unintended consequences if it is designed to support specific tasks while ignoring other tasks or routines that interact with it [14]. Interoperability is an essential requirement for HIT because of the need to integrate patient care across a variety of settings and providers [15,16]. Interoperability can be divided into technical, semantic and process [17]. Technical interoperability moves data from system to system independent of domain or the meaning of what is exchanged [17]. Semantic interoperability gets at the meaning of the data and allows computers to share, understand, interpret, and use data without ambiguity [17]. Interoperability has been well studied from both technical and semantic perspectives such as the development of clinical interoperability models that describe compliance with standards and formalisms metrics for evaluating clinical models [18,19]. While these various models describe how to develop interoperable HIT at the semantic and technical levels, they do not provide insight on people and process interoperability with HIT. Process interoperability is defined as people having common understanding across a network, business systems being interoperable, and work processes being coordinated [17]. While there has been some work at developing process models for how to schedule and monitor the activity of users [20], process interoperability issues remain a frequent cause of implementation issues, regardless of how technically or semantically interoperable a HIT may be. For example, Smith and Koppel identified 45 HIT interaction issues across five general categories that adversely impacted clinical tasks including granularity of data and poor fit of HIT with clinical workflow [21]. Process interoperability also has a temporal component-Berg suggests HIT needs to be grown iteratively and organically, rather than delivered as a ‘fait accompli’, in order to achieve synergy between technical systems and primary (e.g., clinical care) and secondary work processes (e.g., audit, management) [22].
While various aspects of process interoperability have been described and/or studied there is no overarching framework that formalizes different types of processes interoperability and how it evolves over time [15,23,24]. This paper addresses the above shortcoming and uses a two year case study of a Palliative Care Information System (PALIS) [25] to develop a framework for process interoperability of HIT. The paper has three sections. First, we describe the case study of PAL-IS and present the three categories of process requirements PAL-IS needed to achieve. Second, we present our analysis of the PAL-IS implementation to identify process interoperability issues according to the three categories of requirements. We then formalize our interoperability issues as a general framework for process interoperability of HIT. Third, we discuss our research, limitations and next steps.
Materials and methods Methods In February 2010 we began the engineering and deployment of a Palliative Care Information System (PAL-IS), to support community care of palliative patients. Our method was a combination of participatory design and iterative designoriented research [26,27]. Participatory design (PD) ensures we not only design a product but also address the usability and utility of the product by engaging end users in the design process while design science is based on an iterative cycle of design, build, and evaluation of outcomes. The hybrid method enabled us to achieve a systematic design, implementation and evaluation of PAL-IS while also incorporating user context and needs.
Data sources As per the PD method we actively engaged members of the palliative pain and symptom management consultation service (PPSMCS) including nursing staff, administers, physicians, IT staff, and data entry clerks to understand the workflow and data requirements for how patients were registered, assessed and reassessed during clinical encounters. To make the system design feasible we focused on a specific care program involving palliative care patients of a family health team (FHT), which included a family physician, a family medicine resident, and a palliative care nurse. The goal of the FHT project was to increase awareness and adoption of palliative care amongst family physicians in order to increase the capacity to deliver palliative care services in the community. Using the iterative nature of design science research we conducted ongoing meetings with different combinations of the above listed participants. Meetings were a mix of requirements gathering and prototype evaluation. Initial meetings were more focused on requirements elicitation from which prototypes or mockups would be designed and feedback sought in subsequent meetings. Detailed notes were taken and transcribed after each meeting and included insight on requirements (e.g. data entry/retrieval needs workflows) and feedback on models and prototypes.
Please cite this article as: Kuziemsky CE, Peyton L. A framework for understanding process interoperability and health information technology. Health Policy and Technology (2016), http://dx.doi.org/10.1016/j.hlpt.2016.02.007
A framework for understanding process interoperability and health information technology After PAL-IS was implemented we used an online issue tracking system (Assembla) to document issues with PAL-IS and to track progress on resolving issues. Feedback from prototype evaluation meetings with users would be ticketed with a category, task for resolving the issue, and urgency of the issue. Assembla was our project data and outcome repository.
Implementation
Patient Care Requirements 1. Support continuity of care to allow monitoring of patients over time by connecting multiple consultation forms and carrying forward past consult details. 2. Ability to monitor patient care in the community across multiple settings and providers. 3. Facilitate patient centered care by allowing patientcustomized symptom monitoring and reporting. Clinical Process Requirements 1. Support data entry/retrieval during Patient Encounters/ Assessments. 2. Integrate with various clinical workflows (e.g. office, homecare). 3. Support team-based care delivery by enabling people to see what others team members have done (assessments, treatments etc.) as well as the ability to track completed and in-progress tasks. Administrative requirements
Patient data management
Interface Palliative care team members access via computer or smartphone
Patient Database
PAL-IS was implemented in July 2010 as a complete palliative care electronic health record system that was accessible from any web browser and PC. To ease acceptance of the system, it was decided to duplicate the look and feel of the existing paper based system (i.e. forms and reports) wherever possible so PAL-IS would be consistent with existing work routines. Additional design features were then added as they were identified in the system design meetings. After all the design meetings we established nine final design requirements for PAL-IS that were classified into three main categories:
3
Team Portal Patient
Alert & reminder
management
management
EMR
Pain and
Team
interface
symptom
management
Reporting
management
Figure 1
Interoperability architecture for PAL-IS.
Interoperability architecture of PAL-IS The interoperability architecture of PAL-IS has three components to it as shown in Figure 1. The first part is the interface where team members access the portal through PC's or smartphones. The second component is the PAL-IS team portal that contains a set of modules that provide the functionality to support the three PAL-IS requirements described above (i.e. patient care, clinical team communication, and administrative reporting). The modules drive the functionality of PAL-IS. The third component is the PALIS database that store and provides access to patient, team member and other data sources. A user would access modules through the interface and enter or retrieve data accordingly via the database schema. The FHT project was 2 years in duration and PAL-IS was used from July 2010 until June 2012. Approximately 100 patients were entered and tracked in the system during the study period.
Results We present our results in two parts. First, we describe process interoperability issues that arose from the implementation of PAL-IS according to the three categories of process requirements from the Implementation section. Second, we use the issues to develop a general framework for understanding process interoperability and HIT.
Process interoperability evaluation of PAL-IS
1. Support education by tracking educational activities including resident training. 2. Capture real time critical events for audit such as whether a patient's pain was assessed every 24 h 3. Provide data to support analytics and decision making on palliative care delivery including numbers of cancer/noncancer patients and referral sources as well as data to support accreditation reporting.
Overall PAL-IS achieved the three types of requirements detailed in the implementation section. However, during the 24 months PAL-IS was used several interoperability issues were identified by the system users and administrators in the context of using PAL-IS in day-to-day activities. We describe each type of process interoperability issue below.
The data that was collected electronically in PAL-IS to meet the above requirements included patient consult data (e.g. symptoms, medications, and demographics), collaborative care team data (e.g. task reminders or and administrative data on services provided (e.g. was an interdisciplinary care plan developed) and administrative data on educational services and referrals and patient types.
Patient care interoperability issues These are interoperability issues specific to the domain of medicine that the HIT is being designed for. In our palliative care study these included the need for real-time symptom monitoring and continuity of care across multiple settings (the patient care requirements from the implementation section).
Please cite this article as: Kuziemsky CE, Peyton L. A framework for understanding process interoperability and health information technology. Health Policy and Technology (2016), http://dx.doi.org/10.1016/j.hlpt.2016.02.007
4
C.E. Kuziemsky, L. Peyton To support patient centered symptom monitoring we developed an alerting mechanism that would trigger an alert when a patient's symptom assessment changed over a set threshold. For example, if a patient's pain score increased by two or more points it would trigger an alert via e-mail to the nurse monitoring PAL-IS. However, because data was entered into PAL-IS in various ways and times (direct entry during consult, copy and paste from EMR, and retrospective entry after consult), it did not support real time alerting. The symptom alerting feature also caused security issues as it would trigger an alert that was sent via e-mail to a nurse if a patient's symptom score increased over a set threshold. The alert was to ensure timely response to the issue. Initially the e-mail provided the details of the change including the patient name and assessment score change. However, it was pointed out that e-mail is an unsecure channel and therefore we could not disseminate confidential patient information in it. The alerts had to be changed to have a link that would take the provider to the interface for PAL-IS and only provide them details on the alert and patient data after they securely logged into the system. Table 1 lists the patient care process interoperability requirements and our evaluation of PAL-IS.
The patient management module of the team portal (Figure 1) was designed to integrate data on patient encounters over time to enable continuity of care. However, a challenge with palliative care patients is they have a number of care providers including a family physician, palliative care physician, and often a specialist physician such as an oncologist. Therefore, data could be in several electronic health (EHR) or medical record (EMR) systems. PAL-IS had no direct integration with these EMR or EHR systems. As part of systems design we investigated the potential for developing interfaces for the different systems but that task was not technically viable as the sheer number of EMR systems used by community physicians made interfacing impractical. More importantly, there was no standard interoperability engine for import/export and a custom engine would have to be built specific to PAL-IS for each EMR. Hospital EHRs presented yet another problem. There were two main EHRs we needed to interface with (acute care hospital and regional/specialized hospital) and both would have required significant costs and long waits for even a basic import/export interface to be provided by the EHR vendors. The time estimate from one vendor was 3 years. To overcome the EMR/EHR interoperability issue two main data interface workarounds were established. One was that we scanned documents and/or back entered data from other systems (e.g. lab, DI) or physician offices into PAL-IS if it had a field for the data. While this workaround addressed the interoperability issue it was extremely time consuming. Further, scanned documents meant the data could not be exported for search or used for reports or graphing of patient trends. Second, we developed a template to enable a clinician to transfer data from the EMR system into PAL-IS. When a clinician (e.g. RN) would see a patient in a family health clinic they could transfer data from the clinic EMR into PAL-IS by copying and pasting the data into a template and then attaching the template into PAL-IS. Again, while it addressed the interoperability issue, it added time and complexity to the patient consult process. Table 1
Clinical process interoperability issues Clinical process interoperability refers how HIT fits with tasks done in routine day-to-day care delivery. It differs from patient care interoperability in that it is not necessarily specific to any domain of medicine. Two main types of clinical process interoperability issues were identified. The first type was workflow interoperability issues. These issues were first encountered during the requirements engineering of PAL-IS in establishing the patient care and clinical requirements prior to any discussion of technology. The palliative care team had a set workflow for how forms were to be filled out as particular forms were designated for certain consult types. PAL-IS was designed to enforce this
Patient care process interoperability requirements and PAL-IS evaluation.
Patient care process interoperability (from the implementation section)
requirements PAL-IS evaluation
Support continuity of care
Patient management portal has potential to provide longitudinal
Remotely monitor patient in the community through ability to access data from hospital EHR (hospital visits) or EMR (family physician visits)
Support patient centered pain and symptom management
data to support continuity of care but its impact was minimized due to data entry challenges. Patient encounter history from hospital or community systems are accessible via PAL-IS portal, once they are entered in the system. Entering records often involved double entry in PAL-IS plus printing, scanning and attaching, or copy and paste into template, and double entry or attachment into PAL-IS. Provided consistent monitoring and reporting of assessment scores through e-mail alerts but lack of protocol for responding to alerts and inability to have real time data entry prevented full implementation of patient centered symptom management. E-mail is not secure and cannot be used to transit confidential patient information. Patient alerts required a link to be sent where users could then login to the secure PAL-IS site to acquire patient information.
Please cite this article as: Kuziemsky CE, Peyton L. A framework for understanding process interoperability and health information technology. Health Policy and Technology (2016), http://dx.doi.org/10.1016/j.hlpt.2016.02.007
A framework for understanding process interoperability and health information technology
Table 2
5
Clinical process interoperability requirements and PAL-IS evaluation.
Clinical process interoperability requirements (from the Implementation section)
PAL-IS evaluation
Support patient encounters/assessments
Usability issues due to multiple applications and excessive amount of data entry, on average about 50 fields per form.
Standardization of fields such as medication was challenging due to number of field combinations.
Integration with clinical workflow
Excessive data entry was a poor fit with patient consult workflow and added time to nursing visits.
Workarounds needed to be identified to support contextual tasks such as home care visits.
Support team based care delivery
Individual workflows for form completion caused design challenges. Common team based workflow needed to be reconciled pre-implementation.
Team management module Offered potential for collaborative tasks. Team members could see what others had done but impact was minimized due to challenges in getting real time data entry.
workflow meaning that forms had to be filled out in a certain order and a user could not proceed to certain forms without completing the precursor forms. In the pre-PAL-IS paperbased system, it was difficult to enforce the order of form completion, which led to individual workflows for form completion. These differences caused issues in an early prototype as we discovered that some providers had different workflows regarding what forms were used for what tasks. The first step in achieving process interoperability was to establish common ground across all providers to ensure that were following the same process for form completion. Studying various workflows also helped us to understand clinical interoperability issues outside the care unit. In the pre PAL-IS paper-based system, a nurse could be doing home care visits and get a call from a physician's office to create a chart for a new patient and all the data the nurse would get was a first and last name. The nurse would create a chart with the patient name as a placeholder. and follow up later to obtain more detailed patient information. To maintain data quality, PAL-IS was initially designed to require a patient chart to have three requisite data fields (i.e. name, healthcare #, and date of birth (DOB)) and thus the ‘placeholder’ process no longer worked. To support the home care nurse's workflow we redesigned data entry to allow a patient to be entered with only a name and a default date of birth would be appended if an actual DOB was not available. However, we did not want patients to have incorrect DOBs so we put a safeguard in place in the form of a daily report that would identify all patients with the default date of birth to remind the staff to update the default DOB with the patient's real DOB. The second clinical interoperability issue was the difference between design usability and clinical setting usability. The PD approach we used was meant to ensure that clinicians liked the design of PAL-IS. In fact, one of the front line nurses was an active participant in identifying the fields and forms that were needed in PAL-IS. However, the resulting design was impractical in clinical settings. Nurses do much of the front line data entry and are often pressed for time during patient encounters. In PAL-IS, each form had an average of 50 fields and many of the fields were complex and involved drop-down menus or check boxes. The data
entry burden was substantial enough that a data entry clerk was hired to fill in forms based on transcripts of dictated notes and to do some of the scanning and attaching of documents that was needed for data interoperability as described in the Patient care interoperability issues section. A ripple effect of the data entry issues was that it impacted the patient symptom alerting feature as alerts to an increased pain score are only helpful if entered in real time. Further, a feature of the team management module (Figure 1) was to track completed and pending tasks by team members (care team delivery requirement from the Implementation section). However, because real time data collection was not plausible due to conflicts with clinical workflow it reduced the usefulness of the team task feature. Another usability problem was standardization of fields. In a paper based system data entry usually occurs freeform without standards. A goal of PAL-IS was to standardize data entry to provide consistent and quality data to enable reporting. Standardizing fields with multiple options such as medication proved challenging as the variation in drugs, doses and routes that a palliative care patient may have is enormous and therefore a standard list was not practical because of the number of possible combinations of medication data. Rather than providing a pre-defined list, users could type free text in the drug name and dose, and the data would be added to the list options for future entry. Our thought was over time that the list would contain the more common medications and reduce the free text entry. However, over time the list expanded and eventually was so long it became problematic from a usability perspective. The main issue was that without data quality checks the list quickly became unruly, largely because there would be several spelling variations of the same drug or dose. Table 2 lists the clinical process interoperability requirements and our evaluation of PAL-IS. Administrative process interoperability Administrative process interoperability is the need to collect data to support monitoring of clinical and nonclinical activities, often by people outside the core palliative care team including education specialists, community case managers, and healthcare accreditation bodies. For
Please cite this article as: Kuziemsky CE, Peyton L. A framework for understanding process interoperability and health information technology. Health Policy and Technology (2016), http://dx.doi.org/10.1016/j.hlpt.2016.02.007
6
C.E. Kuziemsky, L. Peyton
the most part the reporting module of the PAL-IS portal (Figure 1) was able to provide the necessary data. However, a process issue that emerged was that these administrative needs were often identified ‘downstream’ in the system design process as our initial PD requirements engineering meetings focused mainly on clinical and patient care process needs. Once the first version of PAL-IS was designed some of the administrators and senior physicians saw the value that electronic data or reporting could provide for administrative decision making. For example, several months into the implementation of PAL-IS a physician administrator wanted to track palliative educational activities to community physicians such as whether a resident was present during consults, and whether the consult was an emergency visit? Another administrative request was to enable auditing of certain events such as whether a patient's pain was assessed within 24 h of an alert or if an interdisciplinary care plan was developed. Because these administrative requirements were not identified until after the initial implementation, the forms and the database needed to be redesigned to accommodate the new requests. Over time other external processes crept into the PAL-IS requirements including the need to support data for reporting on accreditation standards and service delivery to the provincial government as part of funding accountability. For the most part we were able to incorporate these administrative requirements in PAL-IS. In particular, less time sensitive requirements such as accreditation data, which is only needed periodically, could be provided as needed. Time sensitive data, such as real time auditing of symptom assessments, was more challenging due to the aforementioned data entry issues. Table 3 describes the administrate process interoperability requirements and the PAL-IS evaluation of those requirements.
Framework for evaluation of process interoperability We summarize our process interoperability evaluation of PAL-IS from the previous three sections as a framework for evaluation of process interoperability shown in Table 4. The framework identifies requirements and considerations for process interoperability at the patient care, clinical and administrative levels. Table 4 can be used a framework for studying and evaluating process interoperability and HIT. Table 3
Discussion While process interoperability issues have been studied, few papers have studied how these issues evolve over time, or identified approaches for evaluating different types of sociotechnical interoperability. This paper addressed these issues and used a two-year case study to develop a framework to understand process interoperability. For the most part we were successful at implementing the necessary requirements for PAL-IS from the Implementation section. However, studying the process interoperability issues, and developing a framework to understand them, helped us realize that our system design strategy was missing an overall plan for integrating all the different components of PAL-IS. Below we emphasize the systems design and temporal considerations of our research. We also highlight how this paper extends existing research.
System design for process Interoperability We realized that there is a significant difference between data engineering and requirements engineering in that the latter requires an understanding of how processes and data interrelate longitudinally across different user groups and processes. Implications from our findings is that designing solutions to support process interoperability may require multiple approaches (e.g. for data entry or record reconciliation) as perfect interoperability may not be achievable. Further, issues in one category of interoperability can influence or be at odds with other categories. In our study patient care and clinical process interoperability were hard to achieve simultaneously as alerts to an increased pain score are only helpful if entered in real time. However, it was not possible to achieve that requirement because workflow related clinical interoperability issues prevented real time data entry. We also had examples of how clinical and administrative interoperability may be at odds with each other. Administrators are under increasing pressure to provide accountability and performance management data, and meeting those needs often puts increased workload on front line clinicians to collect the necessary data to support administrative interoperability. Managing the different categories of process interoperability requires solutions that will provide the necessary quality and quantity of data while not over burdening clinicians. To reduce the data entry impact on front line clinicians we will need to look to innovative
Administrative process interoperability requirements and PAL-IS evaluation.
Administrative process interoperability requirement (from the Implementation section)
PAL-IS evaluation
Access and monitoring of family physician and residents education activities Capture real time critical events for audit (e.g. was interdisciplinary team consulted, ESAS symptom assessment within 24 h) Provide data for reports to monitor performance metrics for referrals, cancer and non-cancer patients as well as for mandatory reporting to healthcare accreditation organizations
Educational forms and reports accessible anywhere via web as part of PAL-IS portal and can be exported to PDF.
Demonstrated potential, but often not available in realtime due to data entry delays.
Many requests came after initial design requiring interface or database redesign.
Required data was provided through printed official documents and export to excel of performance reports.
Please cite this article as: Kuziemsky CE, Peyton L. A framework for understanding process interoperability and health information technology. Health Policy and Technology (2016), http://dx.doi.org/10.1016/j.hlpt.2016.02.007
A framework for understanding process interoperability and health information technology
Table 4
7
Framework for evaluation of process interoperability and HIT.
Interoperability type
Interoperability requirements/considerations
Patient care process interoperability
Monitoring of patient activities, transitions, or care delivery processes, which may span
Clinical process interoperability
Administrative process interoperability
multiple providers or settings, and require integration of multiple data sources needing different approaches. Support for domain specific care delivery needs (e.g. symptom management) which requires attention to be paid to data collection to support such needs. Monitor communication channels to ensure patient data is not transmitted through unsecured channels. Enable data entry and retrieval for patient encounters while considering practical usability to ensure that tasks do not impeded clinical workflow. Team based workflow compatibility including common ground on task completion (e.g. order of form completion). Supporting team based alerting or task assignment as needed. Data for quality monitoring of non-clinical activities (e.g. education) and performance monitoring for mandated reporting such as referrals or categories of patients (e.g. cancer/non-cancer). Need to engage administrators upstream in the design process to prevent need for downstream re-design. Balance is needed between administrative data and front line clinicians who are tasked with collecting the data.
solutions for data entry such as dictation that transcribes directly into text. In many ways HIT is a disruptive technology as many different stakeholders saw great value in how HIT could enhance clinical processes like patient management and symptom monitoring and administrative processes like monitoring and reporting. In particular, administrators liked the ability to collect patient data to track metrics for education, accreditation and funding. However, many of these requests came after initial design and while we revised the database and data entry forms to respond to these needs, our approach was very much a bricolage approach in that we created numerous ‘tinkering’ solutions rather than developing a well-engineered solution. The system design implications of that approach was that as new data requests were added to PAL-IS it swelled the database schema and caused further workflow burden on front line users.
Process interoperability over time Several of the interoperability issues we identified emerged over time and it was only through using PAL-IS in real clinical settings that certain issues were brought to light. Examples of these emerging issues included security issues caused by transmitting confidential patient data through unsecure channels (e.g. e-mail, and messaging apps) and the growing drop down list of medications. While solutions for drop down lists such as data standards can be used for short defined lists like location of care, or provider names, they were not practical for palliative care medications where the combination of drug, doses and routes is enormous. Another temporal issue was process immaturity and the need for organizational transformation such as new protocols to govern HIT mediated collaborative care delivery. While PAL-IS had sophisticated alerting and reminder features
(described in Patient care interoperability issues section), they were not used to capacity because of coordination issues at the organizational level. Responding to alerts via email or SMS texting is a great opportunity to provide real time patient centered care but it puts the onus on care providers to monitor and respond to alerts in a timely manner. The lesson is we cannot implement automated processes to support care delivery without ensuring the processes themselves have sufficient maturity to benefit from the automation.
Relationship with existing work This research is complementary to existing work on clinical and data models for interoperability such as [18,19] as well as frameworks such as AIDA [20]. While robust data models are the backbone of interoperable systems, this study illustrated that data issues are often superseded by people and process issues. Integrating existing research on data models with the framework and process interoperability considerations (Table 4) from this paper would provide a more robust perspective on the relationship between technical and process interoperability. Our framework is meant to be used proactively to mitigate process interoperability issues prior to HIT implementation. We acknowledge that we have not ranked the process interoperability considerations as we believe that the significance or degree of urgency for a consideration will be context specific. A limitation of our research is that our findings and recommendations are based on a study of one system in one city in a very specific domain of medicine (palliative care). Different process interoperability issues could emerge in other settings or domains of medicine. Future research will evaluate our framework in different domains and settings.
Please cite this article as: Kuziemsky CE, Peyton L. A framework for understanding process interoperability and health information technology. Health Policy and Technology (2016), http://dx.doi.org/10.1016/j.hlpt.2016.02.007
8
C.E. Kuziemsky, L. Peyton
Ethical approval Ethics approval the study.
was
obtained prior
to
commencing
Funding Funding sources are NSERC, a MITACS. They had no involvement in the study.
Conflict of interest None declared.
Acknowledgments We acknowledge funding support from a Discovery Grant from the Natural Sciences and Engineering Research Council of Canada (RGPIN-2014-05443) and a MITACS internship grant (#IT02427). We also thank the Palliative Pain and Symptom Management Consultation team for their participation and support in conducting this research.
References [1] IOM (Institute of Medicine). Health IT and Patient Safety: Building Safer Systems For Better Care. Washington, DC: The National Academies Press; 2012. [2] Bates DW, Gawande AA. Improving safety with information technology. N Engl. J Med. 2003;348:2526–34. [3] Kuperman GJ, Bobb A, Payne TH, et al. Medication-related clinical decision support in computerized provider order entry systems: a Review. J Am. Med. Inform. Assoc. 2007;14:29–40. [4] Coiera E. Building a national health IT system from the middle out. J Am. Med. Inform. Assoc. 2009;16(3):271–3. [5] McKibbon A, Lokker C, Handler S, et al. The effectiveness of integrated health information technologies across the phases of medication management: a systematic review. J Am. Med. Inform. Assoc. 2012;19:22–30. [6] Ash JS, Berg M, Coiera E. Some unintended consequences of information technology in health care: the nature of patient care information system-related errors. J Am. Med. Inform. Assoc. 2004;11:104–12. [7] Harrison MI, Koppel R, Bar-Lev S. Unintended consequences of information technologies in health care: an interactive sociotechnical analysis. J Am. Med. Inform. Assoc. 2007;14:542–9. [8] Kaplan B, Harris-Salamone KD. Health IT success and failure. J. Am. Med. Inform. Assoc. 2009;16(3):291–9. [9] Coiera E, Aarts J, Kulkowski C. The dangerous decade. J. Am. Med. Inform. Assoc. 2012;19:2–5.
[10] Greenhalgh T, Potts H, Wong G, Bark P, Swinglehurst D. Tensions and paradoxes in electronic patient record research: a systematic literature review using the meta-narrative method. Milbank Q. 2009;87(4):729–88. [11] Novak L, Brooks J, Gadd C, Anders S, Lorenzi N. Mediating the intersections of organizational routines during the introduction of a health IT system. Eur. J. Inf. Syst. 2012;21(5):552–69. [12] Rodriguez-Gonzalez CG, Herranz-Alonso A, Martin-Barbero ML, et al. Prevalence of medication administration errors in two medical units with automated prescription and dispensing. J. Am. Med. Inform. Assoc. 2012;19:72–8. [13] Coiera E. Interaction design theory. Int. J. Med. Inform. 2003;69(2–3):205–22. [14] Howard-Grenville JA. The persistence of flexible organizational routines: the role of agency and organizational context. Organ. Sci. 2005;16(6):618–36. [15] Ellingsen G, Monteiro E, Røed K. Integration as interdependent workaround. Int. J. Med. Inform. 2013;82(5):e161–9. [16] Mouttham A, Kuziemsky C, Langayan D, Ling Y, Peyton L, Pereira J. Interoperable support for collaborative, mobile, and accessible health care. Inf. Syst. Front. 2012;14(1):73–85. [17] Benson T. Chapter 2: why interoperability is hard principles of health interoperability HL7 and SNOMED. London: SpringerVerlag London Limited; 25–34. [18] Ahn S, Huff SM, Kim Y, Kalra. Quality metrics for detailed clinical models. Int. J. Med. Inform. 2013;82(5):408–17. [19] Gaynor M, Yu F, Andrus CH, Bradner S, Rawn J. A general framework for interoperability with applications to healthcare. Health Policy Technol. 2014;3(1):3–12. [20] Cardosa L, Marins F, Portela F, Abelha A, Machado J. Healthcare Interoperability through Intelligent Agent Technology. Procedia Technol. 2014;16:1334–41. [21] Smith SW, Koppel R. Healthcare information technology's reality problem: a typology of how patient's physical reality, clinicians’ mental models, and health information technology differ. J. Am. Med. Inform. Assoc. 2014;21:117–31. [22] Berg M. The search for synergy: interrelating medical work and patient care information systems. Methods Inf. Med. 2003;42:337–44. [23] Maquire M. Socio-technical systems and user interaction design: 21st century Relevance. Appl. Ergon. 2014;45:162–70. [24] Balka E, Whitehouse S, Coates ST, Andrusiek D. Ski hill injuries and ghost charts: Socio-technical issues in achieving e-Health interoperability across jurisdictions. Inf. Syst. Front. 2012;14 (1):19–42. [25] Peyton L, Kuziemsky C, Langayan D. A Case Study in Interoperable Support for Collaborative Community Healthcare. Software Engineering in Healthcare. 4th International Workshop on Software Engineering in Health Care, SEHC 2012Proceedings, art. no. 6227001. pp. 8–14. [26] Spinuzzi C. The methodology of participatory design. Tech. Commun. 2005;52(2):163–74. [27] Hevner AR, March ST, Park J, Ram S. Design science in information systems research. MIS Q. 2004;28(1):75–105.
Please cite this article as: Kuziemsky CE, Peyton L. A framework for understanding process interoperability and health information technology. Health Policy and Technology (2016), http://dx.doi.org/10.1016/j.hlpt.2016.02.007
Available online at www.sciencedirect.com
journal homepage: www.elsevier.com/locate/hlpt
A framework for understanding process interoperability and health information technology Craig E. Kuziemskya,n, Liam Peytonb a
Telfer School of Management, University of Ottawa, 55 Laurier Avenue East, Ottawa ON, K1N 6N5, Canada b School of Electrical Engineering and Computer Science, University of Ottawa, Canada
KEYWORDS Health information technology; Interoperability; Process; Evaluation
Abstract Objective: While health information technology (HIT) offers great potential for supporting healthcare delivery, interoperability issues can be a barrier to effective use of HIT. While technical and semantic interoperability issues have been well studied there is a shortage of research that addresses process interoperability. Methods: This paper uses a two year case study of a Palliative Care Information System (PALIS) to study process interoperability and health information technology (HIT). We describe the design of PAL-IS and develop and describe three types of process interoperability issues that arose from its implementation. Results: The implementation of PAL-IS caused care delivery, clinical practice and administrative process interoperability issues. Further, many of these issues emerged over time and a solution to address one type of process interoperability issue often led to a different type of issue. We used our evaluation of PAL-IS to develop a general framework for understanding process interoperability and HIT. Conclusion: Designing HIT to support care delivery is a complex sociotechnical endeavor that can result in different types of process interoperability issues. Evaluating process interoperability takes time and longitudinal studies are necessary to understand the overall ecosystem where technology, processes, and people interact. The framework developed in this paper provides a starting point for the evaluation of process interoperability and HIT. & 2016 Fellowship of Postgraduate Medicine. Published by Elsevier Ltd. All rights reserved.
Introduction n
Corresponding author. Tel.: +1 613 562 5800x4792; fax: +1 613 562 5164. E-mail address: [email protected] (C.E. Kuziemsky).
The design and implementation of heath information technology (HIT) has not yet lived up to its potential to
http://dx.doi.org/10.1016/j.hlpt.2016.02.007 2211-8837/& 2016 Fellowship of Postgraduate Medicine. Published by Elsevier Ltd. All rights reserved.
Please cite this article as: Kuziemsky CE, Peyton L. A framework for understanding process interoperability and health information technology. Health Policy and Technology (2016), http://dx.doi.org/10.1016/j.hlpt.2016.02.007
2
C.E. Kuziemsky, L. Peyton
impact the delivery of healthcare services. In 2012 the Institute of Medicine published a report stating the present healthcare trajectory has become too complex and costly and that digital technology will be a key driver of improved healthcare delivery [1]. HIT has been advocated as a solution to assist health care authorities to better provide service delivery in the context of shrinking workforces and increased need for services [2–4]. However, to-date the evidence base on the use and impact of HIT is limited and inconsistent. While studies have advocated positive outcomes from HIT [5], there is also a substantial body of research reporting on negative outcomes including workflow, communication, and safety issues [6–8]. HIT implementation frequently cause unintended consequences including communication issues, creation of new or more work, and even adverse events such as medical errors [6,7]. Unintended consequences occur for several reasons including poor fit with clinical workflow, differences in needs between different user groups (i.e. clinicians and administrators) or the co-existence of manual and automated processes [9,10–12]. To reduce unintended consequences we need to understand the interactions between the users of a system and the different facets of the environment in which the system is used [13]. HIT is more likely to introduce unintended consequences if it is designed to support specific tasks while ignoring other tasks or routines that interact with it [14]. Interoperability is an essential requirement for HIT because of the need to integrate patient care across a variety of settings and providers [15,16]. Interoperability can be divided into technical, semantic and process [17]. Technical interoperability moves data from system to system independent of domain or the meaning of what is exchanged [17]. Semantic interoperability gets at the meaning of the data and allows computers to share, understand, interpret, and use data without ambiguity [17]. Interoperability has been well studied from both technical and semantic perspectives such as the development of clinical interoperability models that describe compliance with standards and formalisms metrics for evaluating clinical models [18,19]. While these various models describe how to develop interoperable HIT at the semantic and technical levels, they do not provide insight on people and process interoperability with HIT. Process interoperability is defined as people having common understanding across a network, business systems being interoperable, and work processes being coordinated [17]. While there has been some work at developing process models for how to schedule and monitor the activity of users [20], process interoperability issues remain a frequent cause of implementation issues, regardless of how technically or semantically interoperable a HIT may be. For example, Smith and Koppel identified 45 HIT interaction issues across five general categories that adversely impacted clinical tasks including granularity of data and poor fit of HIT with clinical workflow [21]. Process interoperability also has a temporal component-Berg suggests HIT needs to be grown iteratively and organically, rather than delivered as a ‘fait accompli’, in order to achieve synergy between technical systems and primary (e.g., clinical care) and secondary work processes (e.g., audit, management) [22].
While various aspects of process interoperability have been described and/or studied there is no overarching framework that formalizes different types of processes interoperability and how it evolves over time [15,23,24]. This paper addresses the above shortcoming and uses a two year case study of a Palliative Care Information System (PALIS) [25] to develop a framework for process interoperability of HIT. The paper has three sections. First, we describe the case study of PAL-IS and present the three categories of process requirements PAL-IS needed to achieve. Second, we present our analysis of the PAL-IS implementation to identify process interoperability issues according to the three categories of requirements. We then formalize our interoperability issues as a general framework for process interoperability of HIT. Third, we discuss our research, limitations and next steps.
Materials and methods Methods In February 2010 we began the engineering and deployment of a Palliative Care Information System (PAL-IS), to support community care of palliative patients. Our method was a combination of participatory design and iterative designoriented research [26,27]. Participatory design (PD) ensures we not only design a product but also address the usability and utility of the product by engaging end users in the design process while design science is based on an iterative cycle of design, build, and evaluation of outcomes. The hybrid method enabled us to achieve a systematic design, implementation and evaluation of PAL-IS while also incorporating user context and needs.
Data sources As per the PD method we actively engaged members of the palliative pain and symptom management consultation service (PPSMCS) including nursing staff, administers, physicians, IT staff, and data entry clerks to understand the workflow and data requirements for how patients were registered, assessed and reassessed during clinical encounters. To make the system design feasible we focused on a specific care program involving palliative care patients of a family health team (FHT), which included a family physician, a family medicine resident, and a palliative care nurse. The goal of the FHT project was to increase awareness and adoption of palliative care amongst family physicians in order to increase the capacity to deliver palliative care services in the community. Using the iterative nature of design science research we conducted ongoing meetings with different combinations of the above listed participants. Meetings were a mix of requirements gathering and prototype evaluation. Initial meetings were more focused on requirements elicitation from which prototypes or mockups would be designed and feedback sought in subsequent meetings. Detailed notes were taken and transcribed after each meeting and included insight on requirements (e.g. data entry/retrieval needs workflows) and feedback on models and prototypes.
Please cite this article as: Kuziemsky CE, Peyton L. A framework for understanding process interoperability and health information technology. Health Policy and Technology (2016), http://dx.doi.org/10.1016/j.hlpt.2016.02.007
A framework for understanding process interoperability and health information technology After PAL-IS was implemented we used an online issue tracking system (Assembla) to document issues with PAL-IS and to track progress on resolving issues. Feedback from prototype evaluation meetings with users would be ticketed with a category, task for resolving the issue, and urgency of the issue. Assembla was our project data and outcome repository.
Implementation
Patient Care Requirements 1. Support continuity of care to allow monitoring of patients over time by connecting multiple consultation forms and carrying forward past consult details. 2. Ability to monitor patient care in the community across multiple settings and providers. 3. Facilitate patient centered care by allowing patientcustomized symptom monitoring and reporting. Clinical Process Requirements 1. Support data entry/retrieval during Patient Encounters/ Assessments. 2. Integrate with various clinical workflows (e.g. office, homecare). 3. Support team-based care delivery by enabling people to see what others team members have done (assessments, treatments etc.) as well as the ability to track completed and in-progress tasks. Administrative requirements
Patient data management
Interface Palliative care team members access via computer or smartphone
Patient Database
PAL-IS was implemented in July 2010 as a complete palliative care electronic health record system that was accessible from any web browser and PC. To ease acceptance of the system, it was decided to duplicate the look and feel of the existing paper based system (i.e. forms and reports) wherever possible so PAL-IS would be consistent with existing work routines. Additional design features were then added as they were identified in the system design meetings. After all the design meetings we established nine final design requirements for PAL-IS that were classified into three main categories:
3
Team Portal Patient
Alert & reminder
management
management
EMR
Pain and
Team
interface
symptom
management
Reporting
management
Figure 1
Interoperability architecture for PAL-IS.
Interoperability architecture of PAL-IS The interoperability architecture of PAL-IS has three components to it as shown in Figure 1. The first part is the interface where team members access the portal through PC's or smartphones. The second component is the PAL-IS team portal that contains a set of modules that provide the functionality to support the three PAL-IS requirements described above (i.e. patient care, clinical team communication, and administrative reporting). The modules drive the functionality of PAL-IS. The third component is the PALIS database that store and provides access to patient, team member and other data sources. A user would access modules through the interface and enter or retrieve data accordingly via the database schema. The FHT project was 2 years in duration and PAL-IS was used from July 2010 until June 2012. Approximately 100 patients were entered and tracked in the system during the study period.
Results We present our results in two parts. First, we describe process interoperability issues that arose from the implementation of PAL-IS according to the three categories of process requirements from the Implementation section. Second, we use the issues to develop a general framework for understanding process interoperability and HIT.
Process interoperability evaluation of PAL-IS
1. Support education by tracking educational activities including resident training. 2. Capture real time critical events for audit such as whether a patient's pain was assessed every 24 h 3. Provide data to support analytics and decision making on palliative care delivery including numbers of cancer/noncancer patients and referral sources as well as data to support accreditation reporting.
Overall PAL-IS achieved the three types of requirements detailed in the implementation section. However, during the 24 months PAL-IS was used several interoperability issues were identified by the system users and administrators in the context of using PAL-IS in day-to-day activities. We describe each type of process interoperability issue below.
The data that was collected electronically in PAL-IS to meet the above requirements included patient consult data (e.g. symptoms, medications, and demographics), collaborative care team data (e.g. task reminders or and administrative data on services provided (e.g. was an interdisciplinary care plan developed) and administrative data on educational services and referrals and patient types.
Patient care interoperability issues These are interoperability issues specific to the domain of medicine that the HIT is being designed for. In our palliative care study these included the need for real-time symptom monitoring and continuity of care across multiple settings (the patient care requirements from the implementation section).
Please cite this article as: Kuziemsky CE, Peyton L. A framework for understanding process interoperability and health information technology. Health Policy and Technology (2016), http://dx.doi.org/10.1016/j.hlpt.2016.02.007
4
C.E. Kuziemsky, L. Peyton To support patient centered symptom monitoring we developed an alerting mechanism that would trigger an alert when a patient's symptom assessment changed over a set threshold. For example, if a patient's pain score increased by two or more points it would trigger an alert via e-mail to the nurse monitoring PAL-IS. However, because data was entered into PAL-IS in various ways and times (direct entry during consult, copy and paste from EMR, and retrospective entry after consult), it did not support real time alerting. The symptom alerting feature also caused security issues as it would trigger an alert that was sent via e-mail to a nurse if a patient's symptom score increased over a set threshold. The alert was to ensure timely response to the issue. Initially the e-mail provided the details of the change including the patient name and assessment score change. However, it was pointed out that e-mail is an unsecure channel and therefore we could not disseminate confidential patient information in it. The alerts had to be changed to have a link that would take the provider to the interface for PAL-IS and only provide them details on the alert and patient data after they securely logged into the system. Table 1 lists the patient care process interoperability requirements and our evaluation of PAL-IS.
The patient management module of the team portal (Figure 1) was designed to integrate data on patient encounters over time to enable continuity of care. However, a challenge with palliative care patients is they have a number of care providers including a family physician, palliative care physician, and often a specialist physician such as an oncologist. Therefore, data could be in several electronic health (EHR) or medical record (EMR) systems. PAL-IS had no direct integration with these EMR or EHR systems. As part of systems design we investigated the potential for developing interfaces for the different systems but that task was not technically viable as the sheer number of EMR systems used by community physicians made interfacing impractical. More importantly, there was no standard interoperability engine for import/export and a custom engine would have to be built specific to PAL-IS for each EMR. Hospital EHRs presented yet another problem. There were two main EHRs we needed to interface with (acute care hospital and regional/specialized hospital) and both would have required significant costs and long waits for even a basic import/export interface to be provided by the EHR vendors. The time estimate from one vendor was 3 years. To overcome the EMR/EHR interoperability issue two main data interface workarounds were established. One was that we scanned documents and/or back entered data from other systems (e.g. lab, DI) or physician offices into PAL-IS if it had a field for the data. While this workaround addressed the interoperability issue it was extremely time consuming. Further, scanned documents meant the data could not be exported for search or used for reports or graphing of patient trends. Second, we developed a template to enable a clinician to transfer data from the EMR system into PAL-IS. When a clinician (e.g. RN) would see a patient in a family health clinic they could transfer data from the clinic EMR into PAL-IS by copying and pasting the data into a template and then attaching the template into PAL-IS. Again, while it addressed the interoperability issue, it added time and complexity to the patient consult process. Table 1
Clinical process interoperability issues Clinical process interoperability refers how HIT fits with tasks done in routine day-to-day care delivery. It differs from patient care interoperability in that it is not necessarily specific to any domain of medicine. Two main types of clinical process interoperability issues were identified. The first type was workflow interoperability issues. These issues were first encountered during the requirements engineering of PAL-IS in establishing the patient care and clinical requirements prior to any discussion of technology. The palliative care team had a set workflow for how forms were to be filled out as particular forms were designated for certain consult types. PAL-IS was designed to enforce this
Patient care process interoperability requirements and PAL-IS evaluation.
Patient care process interoperability (from the implementation section)
requirements PAL-IS evaluation
Support continuity of care
Patient management portal has potential to provide longitudinal
Remotely monitor patient in the community through ability to access data from hospital EHR (hospital visits) or EMR (family physician visits)
Support patient centered pain and symptom management
data to support continuity of care but its impact was minimized due to data entry challenges. Patient encounter history from hospital or community systems are accessible via PAL-IS portal, once they are entered in the system. Entering records often involved double entry in PAL-IS plus printing, scanning and attaching, or copy and paste into template, and double entry or attachment into PAL-IS. Provided consistent monitoring and reporting of assessment scores through e-mail alerts but lack of protocol for responding to alerts and inability to have real time data entry prevented full implementation of patient centered symptom management. E-mail is not secure and cannot be used to transit confidential patient information. Patient alerts required a link to be sent where users could then login to the secure PAL-IS site to acquire patient information.
Please cite this article as: Kuziemsky CE, Peyton L. A framework for understanding process interoperability and health information technology. Health Policy and Technology (2016), http://dx.doi.org/10.1016/j.hlpt.2016.02.007
A framework for understanding process interoperability and health information technology
Table 2
5
Clinical process interoperability requirements and PAL-IS evaluation.
Clinical process interoperability requirements (from the Implementation section)
PAL-IS evaluation
Support patient encounters/assessments
Usability issues due to multiple applications and excessive amount of data entry, on average about 50 fields per form.
Standardization of fields such as medication was challenging due to number of field combinations.
Integration with clinical workflow
Excessive data entry was a poor fit with patient consult workflow and added time to nursing visits.
Workarounds needed to be identified to support contextual tasks such as home care visits.
Support team based care delivery
Individual workflows for form completion caused design challenges. Common team based workflow needed to be reconciled pre-implementation.
Team management module Offered potential for collaborative tasks. Team members could see what others had done but impact was minimized due to challenges in getting real time data entry.
workflow meaning that forms had to be filled out in a certain order and a user could not proceed to certain forms without completing the precursor forms. In the pre-PAL-IS paperbased system, it was difficult to enforce the order of form completion, which led to individual workflows for form completion. These differences caused issues in an early prototype as we discovered that some providers had different workflows regarding what forms were used for what tasks. The first step in achieving process interoperability was to establish common ground across all providers to ensure that were following the same process for form completion. Studying various workflows also helped us to understand clinical interoperability issues outside the care unit. In the pre PAL-IS paper-based system, a nurse could be doing home care visits and get a call from a physician's office to create a chart for a new patient and all the data the nurse would get was a first and last name. The nurse would create a chart with the patient name as a placeholder. and follow up later to obtain more detailed patient information. To maintain data quality, PAL-IS was initially designed to require a patient chart to have three requisite data fields (i.e. name, healthcare #, and date of birth (DOB)) and thus the ‘placeholder’ process no longer worked. To support the home care nurse's workflow we redesigned data entry to allow a patient to be entered with only a name and a default date of birth would be appended if an actual DOB was not available. However, we did not want patients to have incorrect DOBs so we put a safeguard in place in the form of a daily report that would identify all patients with the default date of birth to remind the staff to update the default DOB with the patient's real DOB. The second clinical interoperability issue was the difference between design usability and clinical setting usability. The PD approach we used was meant to ensure that clinicians liked the design of PAL-IS. In fact, one of the front line nurses was an active participant in identifying the fields and forms that were needed in PAL-IS. However, the resulting design was impractical in clinical settings. Nurses do much of the front line data entry and are often pressed for time during patient encounters. In PAL-IS, each form had an average of 50 fields and many of the fields were complex and involved drop-down menus or check boxes. The data
entry burden was substantial enough that a data entry clerk was hired to fill in forms based on transcripts of dictated notes and to do some of the scanning and attaching of documents that was needed for data interoperability as described in the Patient care interoperability issues section. A ripple effect of the data entry issues was that it impacted the patient symptom alerting feature as alerts to an increased pain score are only helpful if entered in real time. Further, a feature of the team management module (Figure 1) was to track completed and pending tasks by team members (care team delivery requirement from the Implementation section). However, because real time data collection was not plausible due to conflicts with clinical workflow it reduced the usefulness of the team task feature. Another usability problem was standardization of fields. In a paper based system data entry usually occurs freeform without standards. A goal of PAL-IS was to standardize data entry to provide consistent and quality data to enable reporting. Standardizing fields with multiple options such as medication proved challenging as the variation in drugs, doses and routes that a palliative care patient may have is enormous and therefore a standard list was not practical because of the number of possible combinations of medication data. Rather than providing a pre-defined list, users could type free text in the drug name and dose, and the data would be added to the list options for future entry. Our thought was over time that the list would contain the more common medications and reduce the free text entry. However, over time the list expanded and eventually was so long it became problematic from a usability perspective. The main issue was that without data quality checks the list quickly became unruly, largely because there would be several spelling variations of the same drug or dose. Table 2 lists the clinical process interoperability requirements and our evaluation of PAL-IS. Administrative process interoperability Administrative process interoperability is the need to collect data to support monitoring of clinical and nonclinical activities, often by people outside the core palliative care team including education specialists, community case managers, and healthcare accreditation bodies. For
Please cite this article as: Kuziemsky CE, Peyton L. A framework for understanding process interoperability and health information technology. Health Policy and Technology (2016), http://dx.doi.org/10.1016/j.hlpt.2016.02.007
6
C.E. Kuziemsky, L. Peyton
the most part the reporting module of the PAL-IS portal (Figure 1) was able to provide the necessary data. However, a process issue that emerged was that these administrative needs were often identified ‘downstream’ in the system design process as our initial PD requirements engineering meetings focused mainly on clinical and patient care process needs. Once the first version of PAL-IS was designed some of the administrators and senior physicians saw the value that electronic data or reporting could provide for administrative decision making. For example, several months into the implementation of PAL-IS a physician administrator wanted to track palliative educational activities to community physicians such as whether a resident was present during consults, and whether the consult was an emergency visit? Another administrative request was to enable auditing of certain events such as whether a patient's pain was assessed within 24 h of an alert or if an interdisciplinary care plan was developed. Because these administrative requirements were not identified until after the initial implementation, the forms and the database needed to be redesigned to accommodate the new requests. Over time other external processes crept into the PAL-IS requirements including the need to support data for reporting on accreditation standards and service delivery to the provincial government as part of funding accountability. For the most part we were able to incorporate these administrative requirements in PAL-IS. In particular, less time sensitive requirements such as accreditation data, which is only needed periodically, could be provided as needed. Time sensitive data, such as real time auditing of symptom assessments, was more challenging due to the aforementioned data entry issues. Table 3 describes the administrate process interoperability requirements and the PAL-IS evaluation of those requirements.
Framework for evaluation of process interoperability We summarize our process interoperability evaluation of PAL-IS from the previous three sections as a framework for evaluation of process interoperability shown in Table 4. The framework identifies requirements and considerations for process interoperability at the patient care, clinical and administrative levels. Table 4 can be used a framework for studying and evaluating process interoperability and HIT. Table 3
Discussion While process interoperability issues have been studied, few papers have studied how these issues evolve over time, or identified approaches for evaluating different types of sociotechnical interoperability. This paper addressed these issues and used a two-year case study to develop a framework to understand process interoperability. For the most part we were successful at implementing the necessary requirements for PAL-IS from the Implementation section. However, studying the process interoperability issues, and developing a framework to understand them, helped us realize that our system design strategy was missing an overall plan for integrating all the different components of PAL-IS. Below we emphasize the systems design and temporal considerations of our research. We also highlight how this paper extends existing research.
System design for process Interoperability We realized that there is a significant difference between data engineering and requirements engineering in that the latter requires an understanding of how processes and data interrelate longitudinally across different user groups and processes. Implications from our findings is that designing solutions to support process interoperability may require multiple approaches (e.g. for data entry or record reconciliation) as perfect interoperability may not be achievable. Further, issues in one category of interoperability can influence or be at odds with other categories. In our study patient care and clinical process interoperability were hard to achieve simultaneously as alerts to an increased pain score are only helpful if entered in real time. However, it was not possible to achieve that requirement because workflow related clinical interoperability issues prevented real time data entry. We also had examples of how clinical and administrative interoperability may be at odds with each other. Administrators are under increasing pressure to provide accountability and performance management data, and meeting those needs often puts increased workload on front line clinicians to collect the necessary data to support administrative interoperability. Managing the different categories of process interoperability requires solutions that will provide the necessary quality and quantity of data while not over burdening clinicians. To reduce the data entry impact on front line clinicians we will need to look to innovative
Administrative process interoperability requirements and PAL-IS evaluation.
Administrative process interoperability requirement (from the Implementation section)
PAL-IS evaluation
Access and monitoring of family physician and residents education activities Capture real time critical events for audit (e.g. was interdisciplinary team consulted, ESAS symptom assessment within 24 h) Provide data for reports to monitor performance metrics for referrals, cancer and non-cancer patients as well as for mandatory reporting to healthcare accreditation organizations
Educational forms and reports accessible anywhere via web as part of PAL-IS portal and can be exported to PDF.
Demonstrated potential, but often not available in realtime due to data entry delays.
Many requests came after initial design requiring interface or database redesign.
Required data was provided through printed official documents and export to excel of performance reports.
Please cite this article as: Kuziemsky CE, Peyton L. A framework for understanding process interoperability and health information technology. Health Policy and Technology (2016), http://dx.doi.org/10.1016/j.hlpt.2016.02.007
A framework for understanding process interoperability and health information technology
Table 4
7
Framework for evaluation of process interoperability and HIT.
Interoperability type
Interoperability requirements/considerations
Patient care process interoperability
Monitoring of patient activities, transitions, or care delivery processes, which may span
Clinical process interoperability
Administrative process interoperability
multiple providers or settings, and require integration of multiple data sources needing different approaches. Support for domain specific care delivery needs (e.g. symptom management) which requires attention to be paid to data collection to support such needs. Monitor communication channels to ensure patient data is not transmitted through unsecured channels. Enable data entry and retrieval for patient encounters while considering practical usability to ensure that tasks do not impeded clinical workflow. Team based workflow compatibility including common ground on task completion (e.g. order of form completion). Supporting team based alerting or task assignment as needed. Data for quality monitoring of non-clinical activities (e.g. education) and performance monitoring for mandated reporting such as referrals or categories of patients (e.g. cancer/non-cancer). Need to engage administrators upstream in the design process to prevent need for downstream re-design. Balance is needed between administrative data and front line clinicians who are tasked with collecting the data.
solutions for data entry such as dictation that transcribes directly into text. In many ways HIT is a disruptive technology as many different stakeholders saw great value in how HIT could enhance clinical processes like patient management and symptom monitoring and administrative processes like monitoring and reporting. In particular, administrators liked the ability to collect patient data to track metrics for education, accreditation and funding. However, many of these requests came after initial design and while we revised the database and data entry forms to respond to these needs, our approach was very much a bricolage approach in that we created numerous ‘tinkering’ solutions rather than developing a well-engineered solution. The system design implications of that approach was that as new data requests were added to PAL-IS it swelled the database schema and caused further workflow burden on front line users.
Process interoperability over time Several of the interoperability issues we identified emerged over time and it was only through using PAL-IS in real clinical settings that certain issues were brought to light. Examples of these emerging issues included security issues caused by transmitting confidential patient data through unsecure channels (e.g. e-mail, and messaging apps) and the growing drop down list of medications. While solutions for drop down lists such as data standards can be used for short defined lists like location of care, or provider names, they were not practical for palliative care medications where the combination of drug, doses and routes is enormous. Another temporal issue was process immaturity and the need for organizational transformation such as new protocols to govern HIT mediated collaborative care delivery. While PAL-IS had sophisticated alerting and reminder features
(described in Patient care interoperability issues section), they were not used to capacity because of coordination issues at the organizational level. Responding to alerts via email or SMS texting is a great opportunity to provide real time patient centered care but it puts the onus on care providers to monitor and respond to alerts in a timely manner. The lesson is we cannot implement automated processes to support care delivery without ensuring the processes themselves have sufficient maturity to benefit from the automation.
Relationship with existing work This research is complementary to existing work on clinical and data models for interoperability such as [18,19] as well as frameworks such as AIDA [20]. While robust data models are the backbone of interoperable systems, this study illustrated that data issues are often superseded by people and process issues. Integrating existing research on data models with the framework and process interoperability considerations (Table 4) from this paper would provide a more robust perspective on the relationship between technical and process interoperability. Our framework is meant to be used proactively to mitigate process interoperability issues prior to HIT implementation. We acknowledge that we have not ranked the process interoperability considerations as we believe that the significance or degree of urgency for a consideration will be context specific. A limitation of our research is that our findings and recommendations are based on a study of one system in one city in a very specific domain of medicine (palliative care). Different process interoperability issues could emerge in other settings or domains of medicine. Future research will evaluate our framework in different domains and settings.
Please cite this article as: Kuziemsky CE, Peyton L. A framework for understanding process interoperability and health information technology. Health Policy and Technology (2016), http://dx.doi.org/10.1016/j.hlpt.2016.02.007
8
C.E. Kuziemsky, L. Peyton
Ethical approval Ethics approval the study.
was
obtained prior
to
commencing
Funding Funding sources are NSERC, a MITACS. They had no involvement in the study.
Conflict of interest None declared.
Acknowledgments We acknowledge funding support from a Discovery Grant from the Natural Sciences and Engineering Research Council of Canada (RGPIN-2014-05443) and a MITACS internship grant (#IT02427). We also thank the Palliative Pain and Symptom Management Consultation team for their participation and support in conducting this research.
References [1] IOM (Institute of Medicine). Health IT and Patient Safety: Building Safer Systems For Better Care. Washington, DC: The National Academies Press; 2012. [2] Bates DW, Gawande AA. Improving safety with information technology. N Engl. J Med. 2003;348:2526–34. [3] Kuperman GJ, Bobb A, Payne TH, et al. Medication-related clinical decision support in computerized provider order entry systems: a Review. J Am. Med. Inform. Assoc. 2007;14:29–40. [4] Coiera E. Building a national health IT system from the middle out. J Am. Med. Inform. Assoc. 2009;16(3):271–3. [5] McKibbon A, Lokker C, Handler S, et al. The effectiveness of integrated health information technologies across the phases of medication management: a systematic review. J Am. Med. Inform. Assoc. 2012;19:22–30. [6] Ash JS, Berg M, Coiera E. Some unintended consequences of information technology in health care: the nature of patient care information system-related errors. J Am. Med. Inform. Assoc. 2004;11:104–12. [7] Harrison MI, Koppel R, Bar-Lev S. Unintended consequences of information technologies in health care: an interactive sociotechnical analysis. J Am. Med. Inform. Assoc. 2007;14:542–9. [8] Kaplan B, Harris-Salamone KD. Health IT success and failure. J. Am. Med. Inform. Assoc. 2009;16(3):291–9. [9] Coiera E, Aarts J, Kulkowski C. The dangerous decade. J. Am. Med. Inform. Assoc. 2012;19:2–5.
[10] Greenhalgh T, Potts H, Wong G, Bark P, Swinglehurst D. Tensions and paradoxes in electronic patient record research: a systematic literature review using the meta-narrative method. Milbank Q. 2009;87(4):729–88. [11] Novak L, Brooks J, Gadd C, Anders S, Lorenzi N. Mediating the intersections of organizational routines during the introduction of a health IT system. Eur. J. Inf. Syst. 2012;21(5):552–69. [12] Rodriguez-Gonzalez CG, Herranz-Alonso A, Martin-Barbero ML, et al. Prevalence of medication administration errors in two medical units with automated prescription and dispensing. J. Am. Med. Inform. Assoc. 2012;19:72–8. [13] Coiera E. Interaction design theory. Int. J. Med. Inform. 2003;69(2–3):205–22. [14] Howard-Grenville JA. The persistence of flexible organizational routines: the role of agency and organizational context. Organ. Sci. 2005;16(6):618–36. [15] Ellingsen G, Monteiro E, Røed K. Integration as interdependent workaround. Int. J. Med. Inform. 2013;82(5):e161–9. [16] Mouttham A, Kuziemsky C, Langayan D, Ling Y, Peyton L, Pereira J. Interoperable support for collaborative, mobile, and accessible health care. Inf. Syst. Front. 2012;14(1):73–85. [17] Benson T. Chapter 2: why interoperability is hard principles of health interoperability HL7 and SNOMED. London: SpringerVerlag London Limited; 25–34. [18] Ahn S, Huff SM, Kim Y, Kalra. Quality metrics for detailed clinical models. Int. J. Med. Inform. 2013;82(5):408–17. [19] Gaynor M, Yu F, Andrus CH, Bradner S, Rawn J. A general framework for interoperability with applications to healthcare. Health Policy Technol. 2014;3(1):3–12. [20] Cardosa L, Marins F, Portela F, Abelha A, Machado J. Healthcare Interoperability through Intelligent Agent Technology. Procedia Technol. 2014;16:1334–41. [21] Smith SW, Koppel R. Healthcare information technology's reality problem: a typology of how patient's physical reality, clinicians’ mental models, and health information technology differ. J. Am. Med. Inform. Assoc. 2014;21:117–31. [22] Berg M. The search for synergy: interrelating medical work and patient care information systems. Methods Inf. Med. 2003;42:337–44. [23] Maquire M. Socio-technical systems and user interaction design: 21st century Relevance. Appl. Ergon. 2014;45:162–70. [24] Balka E, Whitehouse S, Coates ST, Andrusiek D. Ski hill injuries and ghost charts: Socio-technical issues in achieving e-Health interoperability across jurisdictions. Inf. Syst. Front. 2012;14 (1):19–42. [25] Peyton L, Kuziemsky C, Langayan D. A Case Study in Interoperable Support for Collaborative Community Healthcare. Software Engineering in Healthcare. 4th International Workshop on Software Engineering in Health Care, SEHC 2012Proceedings, art. no. 6227001. pp. 8–14. [26] Spinuzzi C. The methodology of participatory design. Tech. Commun. 2005;52(2):163–74. [27] Hevner AR, March ST, Park J, Ram S. Design science in information systems research. MIS Q. 2004;28(1):75–105.
Please cite this article as: Kuziemsky CE, Peyton L. A framework for understanding process interoperability and health information technology. Health Policy and Technology (2016), http://dx.doi.org/10.1016/j.hlpt.2016.02.007