Journal Entry 1

Design, Implementation and Evaluation of an Architecture based on the CDA R2 Document Repository to Provide Support to the Contingency Plan Fernando Campos a,c, Daniel Luna a, Dean F. Sittig b, Fernán González Bernaldo de Quirós a a Health Information Department, Hospital Italiano de Buenos Aires, Argentina bSchool of Biomedical Informatics, University of Texas Health Sciences Center at Houston, Houston, TX, USA cHL7 Argentina Abstract The pervasive use of electronic records in healthcare increases the dependency on technology due to the lack of physical backup for the records. Downtime in the Electronic Health Record system is unavoidable, due to software, infrastructure and power failures as well as natural disasters, so there is a need to develop a contingency plan ensuring patient care continuity and minimizing risks for health care delivery. To mitigate these risks, two applications were developed allowing healthcare delivery providers to retrieve clinical information using the Clinical Document Architecture Release 2 (CDA R2) document repository as the information source. In this paper we describe the strategy, implementation and results; and provide an evaluation of effectiveness.

Keywords: Electronic Health Record; CDA repository; Contingency plan.

Introduction There is an increasing use of electronic health record, specifically the replacement of paper-based health record with Electronic Health Records (EHR) [1]. Therefore, every healthcare delivery process relies on information systems to ensure patient care. This brings up the threat of a lack of information for decision making in case of system downtime.

One of the biggest risks in this scenario is inaccessibility of information needed to administer medication [2, 3].

Unexpected information technology (IT) downtime occurs more and more often with widespread adoption of electronic systems in healthcare [4]. Although the reliability of computing hardware has improved significantly, the complexity of software has escalated, especially in healthcare [4]. Risk identification and risk assessments are essential steps for developing preventive measures. Equally important is institutionalization of contingency plans as our data show that not all failures of health IT can be predicted and thus effectively prevented [5]. Most institutions had only partially implemented comprehensive contingency plans to maintain safe and effective healthcare during unexpected EHR downtimes [6].

Preparing for these unexpected downtimes should be a part of every EHR-enabled healthcare organization’s overall patient safety strategy. As most experts state, an effective contingency plan should address the causes and consequences of EHR unavailability, triggering processes and preparations that can minimize the frequency and impact of such events, ensuring continuity of care [7-9]. The objective of this paper is to describe the design, implementation, and evaluation of the IT component of a contingency plan that uses the Clinical Document Architecture (CDA) Release 2 (R2) document repository to support continuity of care during system downtime. Methods Settings The Hospital Italiano of Buenos Aires (HIBA) is a nonprofit academic medical center founded in 1853. HIBA has a network of two hospitals with 750 beds (250 for intensive care), 800 home care patients under care, 25 outpatient care centers, and 41 operating rooms. There are more than 2,800 physicians, an equal number of medical team members and 1,900 administrative and support staff. During 2013-2014 there were 45,000 admissions, 3 million outpatient visits and 45,000 surgeries (half of them ambulatory).

In 1998 HIBA began the gradual implementation of a Healthcare Information System (HIS) developed in-house, from data capture to analysis. It includes a web based, modular, problem-oriented and patient-centered EHR. This EHR is known as Italica and allows inpatient, outpatient, home care, and emergency care records. Italica also allows users to order ancillary tests, prescribe medications and view results including imaging through an integrated picture archiving and communications system (PACS).

The EHR has a relational database record and also a CDA R2 document-based repository, which is digitally signed by professionals participating in healthcare delivery. This repository is used to interoperate with payers and other EHRs, and to make information portable for patients or other external healthcare providers. The system architecture for sharing medical information is based on HL7 CDA and a repository/registry XDS (Cross Enterprise Document Sharing) model defined by IHE ( Integrating the Healthcare Enterprise). The document repository currently contains 36.4 million CDAs [10].

This repository allows the organization to operate without need for paper records, because information exchange between actors or systems is facilitated by these documents.

For instance, for ancillary systems like imaging or laboratory, order is no longer paper-based but a digitally signed CDA R2.

Likewise, result reports are not printed, but reviewed directly in the EHR through a CDA R2 sent by the ancillary service.

Since 2012, and based on this implementation, all procedures and communications for healthcare continuity while systems recover from a meaningful interruption have been redesigned, mainly for the inpatient setting. Two levels of contingency were identified: MEDINFO 2015: eHealth-enabled Health I.N. Sarkar et al. (Eds.) © 2015 IMIA and IOS Press.

This article is published online with Open Access by IOS Press and distr\ ibuted under the terms of the Creative Commons Attribution Non-Commercial License.

doi:10.3233/978-1-61499-564-7-173 173 The d e docu m Desi gn A la b effecti differ e from downt i This i n differ e each p the c u the lis t down comp a Resu In or d navig a eleme n Doc Doc Ser v Pat i Pat i Firs Las Using based patien t After docu m This a EHR, Level 1 is t h not availab l deploymen t of the com p networking , Level 2 is t o contingenc y or halted d u data center p storage, net w ecision was t o ment repositor y n boratory fun c veness and 2 ent days and the last exe c ime.

nvolved simu l ent times of d patient had at urrent list of p t had been g e at 12:16 am, p ared for additi lts der to mitiga t ator was de v nts in the CD A cument date cument type vice ient id ient root st name st name this index, a on patient t), timeline f o selecting a s p ments for the v application is and with a d i he applicatio n le. Causes mi g t of a new ver s puting infrastr u , electricity, e t otal impact. U y occurs whe n uring upgrade s problems aff e work outages o leverage the y to support c o ction study w 20 Level 2 c o at varying t i cution to th e lating system day and com p the time of t prescriptions i enerated at 1 2 prescriptions d ons or modifi te the first l e veloped, havi n A header (me t Tabl e /ClinicalD o ow /ClinicalD o /ClinicalD o r/assigned E tion/id/@e x /ClinicalD o r/assigned E tion/id/@a s /ClinicalD o entRole/id/ @ /ClinicalD o entRole/id/ @ /ClinicalD o /recordTar g /name/@gi v /ClinicalD o /recordTar g /patient/na m tree is gener a information. or inpatient ( d pecific date, visit grouped b deployed o n ifferent and r n level, when o ght be a probl e sion or server ucture is avai l tc.

Usually this le v n the database s or maintena n ecting the ser v or natural di s redundancy g ontingency p r was perfor m ontingency te s imes. Time w e start of si m downtime o n paring each p the simulated in real time. 2:00 am and t during those 1 cations.

evel of conti n ng as index e tadata).

e 1 ocument/effec ocument/code / ocument/legal A Entity/represe n xtension and ocument/legal A Entity/represe n ssigningAuth o ocument/reco r @extension ocument/reco r @root ocument get/patientRolven [1] ocument get/patientRolme/@family ated, and this From the t r day by day) c a the caregive r by document t n a different edundant dat a only the EHR em with the issues. The r e lable: databas vel of server is do w nce, or durin g ver farm or sasters.

generated by t rocesses.

med to evalusts were run was randomi z mulated syst e n 20 occasion s prescription t h downtime w For example , the system w e 16 minutes w e ngency, a C D es some of t tiveTime/@l /@code AuthenticatontedOrganiza AuthenticatontedOrganizaorityName rdTarget/pati rdTarget/pati e/patient e tree is acces s ree root (tar g an be navigat e r can access type and servi server from t abase. If by a is est e, wn g the ate on zed em s at hat with , if ent ere DA the sed get ed.

all ce.

the any c hle T hdane In(acrev Inprfo Baaclatin Easploin Thsyapstrcoanso Indacahe Craneawbe hance the EH R ast can be ret r he second l e atabase suppoetwork conne c n this extreme average 720 b e ritical for hea l valuated on a c n this regard, t rescrip tions ( m or laboratory s ased on this r ccessed the d test medicatinpatient.

ach compute r pace to a fol d ocation and c nformation fo r his temporal ystem alternatpplication r u rategically s e ontingency si t nd co nnectio n ource (UPS) a n n the event o f atabase down t an be used t o ealthcare deli v Figure 2 reating this b nd generates a ach patient. W ould be need e e turned into H R is not availrieved.

Figure 1 – evel of conti n rt, applicatio n ctions.

case and onl y eds), the que s lthcare delive r consensus bas two elements medications, d samples.

requirement, document rep o on and sam p r running th e der tree orga n containing evr each locatio n repository i s es storage of uns redunda n elected locat i tuations. The s n to backup p nd supplies o f fnatural disas t time, or any oo print prescr i very can cont i 2 – File Explo r backup requir e an average of With an aver a ed every 30 m HTML for on able, the doc u CDA Naviga t ngency assu m n server supp o y for inpatien t stion of whic h ry to minimiz e sis.

were key: a c dosages, etc.) an applicatio ository every pling label i n e application nized by dep ar ery prescript i n.

s composed o the documen t ntly on se v ions, and ca n se computers power, with un f printer pape r ters, applicati ther continge n iptions and l a inue uninterr u rer for Level 2 es querying t 18 queries in v age of 720 b minutes, whic h screen rende r ument- based E tor mes a total l ort, and elect r t and emerge n h information e risk to patie n ccess to the p and proper l n was desig n 30 minutes nformation f o devotes locrtment and i n ion CDA an d of two folde r t between the m veral compu t n only be u have a local ninterruptibl e r. on server do w ncy, these co m abels so that upted.

2 Contingenc y the relational volving 44 ta b beds, 12,960 h then would n ring. EHR at lack of ricity or ncy care is most nts was atient’s abeling ned that for the or each al disk npatient d label rs. The m. This ters in used in printer e power wntime, mputers critical y system bles for queries need to F. Campos et al. / Design, Implementation and Evaluation of an Architecture Based on the CDA R2 Document Repository 174 Using the CDA repository, only 1 query is needed, involving a snapshot of the current active inpatients or emergency care episodes, and the query to the document repository for the URL for the patient’s last prescription CDA. Rendering the information only requires transformation of the XML using an XSLT stylesheet.

The downtime record between March 2012 and June 2014 is presented in Table 2. This table shows dates and times when the EHR was not available, and for how long. The column ‘Type’ indicates if the lack of EHR was programmed or not, and then the cause. The column “Level” indicates the severity level assigned to the cause and for each event, the quantity of pages printed.

Table 2 – Downtime Record and Pages Printed Date Begin Time Duration (Hrs.) Type * Motive Level Pages 08/03/12 09:15 05:55 U EHR bug 1 365 05/04/12 23:10 02:00 U DB issue 2 301 07/04/12 20:00 02:00 P DB mainte- nance 2 10 27/04/12 09:50 06:15 U EHR bug 1 303 12/05/12 22:40 07:50 P Upgrade DB 2 1254 09/06/12 22:00 07:00 P Upgrade Server memory 2 867 29/12/12 05:30 04:30 U EHR bug 1 425 23/04/13 05:30 25:01 U Shut- down power 2 1450 26/04/13 12:30 01:00 U Router down. 2 23 27/04/13 18:00 03:00 P Server mainte- nance 2 150 25/05/13 16:00 05:05 P Server mainte- nance 2 1050 15/06/13 17:00 07:38 P Server mainte- nance 2 1080 26/07/13 20:00 13:30 P New DB cluster 2 1250 14/09/13 18:00 02:00 P Update switches firmware 2 306 11/01/14 02:00 04:30 P Update switches firmware 2 309 24/06/14 12:10 01:10 U DB issue 2 124 *Type: U: Unplanned - P: Planned As an example, a change of servers’ operating system produced downtime of 13:30 hours. In this contingency, all prescriptions were printed, and 1,250 sheets of paper were used to print 759 prescriptions in 1 hour 15 minutes.

In the contingency Level 1 case, even though the CDA browser was used, the critical care units and emergency care areas preferred to print out the prescriptions in order to be able to make written notes of instructions and any other changes.

Details of each test simulation are presented in Table 3, including the time elapsed since last generation (mins), the number of inpatients at that moment, records that matched at the simulated downtime and the differences found. Table 3 - Evaluation Cases Case # Minutes elapsed since last generation Inpatients at down- time Matches Diffe- rences 1 2 654 650 4 2 10 695 667 34 3 18 712 668 44 4 25 730 666 64 5 5 759 723 36 6 12 759 707 52 7 26 762 686 76 8 5 771 759 12 9 5 721 697 24 10 15 678 630 48 11 14 699 643 56 12 10 712 680 32 13 17 734 686 48 14 5 723 707 16 15 15 745 709 36 16 13 711 671 40 17 22 733 657 76 18 5 732 712 20 19 1 722 722 0 20 25 745 673 72 14,497 13,713 784 The differences were evaluated in each case: how many were caused by a patient being admitted or discharged, how many were caused by a change in medications. Medications for newly admitted patients and missing updates were deemed errors. New inpatients with no medications and discharged patients still in the contingency system were not deemed errors. For example, for the second case, 34 differences were found, 22 of them due to patients admitted during the 10 minutes from the listing generation but with no prescription, 6 patients with their prescriptions updated, 13 patients discharged and 3 patients had new prescriptions. The evaluation result is presented in Table 4.

Table 4 – Evaluation Results for Contingency Listing Case # Diff.: New Admissi on (1) Diff.

Medicat ion Change Diff.:

Dischar ged patient (2) New patient with prescripti ons Errors (1) + (2) 1 1 1 2 0 1 2 12 10 6 6 16 3 22 6 13 3 9 4 34 10 17 3 13 5 18 3 15 0 3 6 26 4 20 2 6 7 8 10 55 3 13 F. Campos etal. /Design, Implementation andEvaluation of an Arc hitectur eBased onthe CD A R2 Document Repository 175 8 6 3 3 0 3 9 12 3 9 0 3 10 22 2 20 4 6 11 29 6 19 2 8 12 16 5 11 0 5 13 23 10 6 9 19 14 8 2 6 0 2 15 17 5 12 2 7 16 20 7 13 0 7 17 39 17 16 4 21 18 10 3 7 0 3 19 0 0 0 0 0 20 36 9 23 4 13 359 116 273 42 158 The results show that printed prescriptions concur in 98.91% (14,339/14,497) of those registered in the EHR. The relationship between the time elapsed since the last generation and the differences found after downtime are presented in Figure 3. Figure 3 – Differences (Time) Discussion This architecture allows information to be available from all delivery care locations, and allows every actor requiring the information to access it.

The printing process has a predefined sequence for the various locations, prioritizing critical care units, emergency care, pediatric care, and then other services.

The more time elapses between the generation of the latest list and the EHR unavailability, the greater the difference in the prescription record. Although the medical staffs understand that any changes made in less than 30 minutes could be re- prescribed, they are aware that the nurse work based on the lists received and these should be corrected manually after the EHR disruption.

In the real scenario, other times should be evaluated because doctors do not make decisions on every patient immediately after the system goes down. Other changes could have been made during the downtime and will not be represented in the print version (prescriptions, bed changes, etc.). So we have two mechanisms that generate gaps between the information documented and the reality: gaps between the last local backup and the down time and gaps between the down time and the moment at which the caregiver uses the print version.

This study evaluated the differences between Point 1 and Point 2. The effectiveness of this architecture at Point 3 is pending evaluation and will be the subject of a future study. The alternating folder strategy was required because in one of the tests if network connectivity or power was interrupted just when the folder was being generated, its structure could be corrupted. If this happens, the other folder can be accessed.

Prescription printed forms are used mainly by the nurses to ensure care continuity for patients. They continue recording their actions there in order to update the EHR when the system comes back, or scanned as part of the care record.

One limitation, as shown by the evaluation of the results, is that not all the information is available because there can be changes between the executions of the refresh process: patient transfers, new prescriptions, admissions or discharges.

No other experience in creating this kind of repository was found in the literature, either as a redundant repository or for use on a contingency basis. Conclusion Downtime in information systems, both planned and unplanned, is inevitable, even in the healthcare environment, where systems need to be available 24-7-365. Implementing tools such as the one presented in this paper provides contingency plan support and helps mitigate many risks that threaten information availability at the point of care.

References [1] Wright A, Henkin S, Feblowitz J, McCoy AB, Bates DW, Sittig DF. Early results of the meaningful use program for electronic health records, N. Engl. J. Med. 2013;368:779– 780. http://dx.d oi.org/10.1056/NEJMc1213481 .

[2] Hanuscak TL, Szeinbach SL, Seoane-Vazquez E, Reichert BJ, McCluskey CF. Evaluation of causes and frequency of medication errors during information technology downtime. Am J Health Syst Pharm.

2009;66(12):1119-1124.

[3] Koppel R, Metlay JP, Cohen A, Abaluck B, Localio AR, Kimmel SE, Strom BL. Role of computerized physician order entry systems in facilitating medication errors .

JAMA. 2005;293:1197-1203.

[4] Lei J, Guan P, Gao K, Lu X, Chen Y, Li Y, Meng Q, Zhang J, Sittig DF, Zheng K. Characteristics of health IT outage and suggested risk management strategies: an analysis of historical incident reports in China. Int. J.

Med. Inform. 2014;83(2):122-130.

[5] Sittig DF, Singh H. Electronic health records and national patient-safety goals. N. Engl. J. Med. 2012;367(19):1854– 1860.

[6] Sittig DF, Gonzalez D, Singh H. Contingency planning for electronic health record-based care continuity: a survey of recommended practices. Int J Med Inform.

2014;83(11):797-804. doi:

10.1016/j.ijmedinf.2014.07.007. Epub 2014 Aug 7.

[7] Kilbridge P. Computer crash – lessons from a system failure. N. Engl. J. Med. 2003;348:881–882.

[8] Merrick J. ‘Serious’ computer crash hits hospital trusts.

Daily Mail (July 31, 2006) 3984, Available at: http://www.dailymail.co.uk/news/article-77/Serious- crash-hits-hospital-trusts.html .

[9] Sittig DF, Ash JS, Singh H. The SAFER guides:

empowering organizations to improve the safety and effectiveness of electronic health records. Am J Managed Care. 2014;20(5):418-423. F. Campos et al. / Design, Implementation and Evaluation of an Architecture Based on the CDA R2 Document Repository 176 [10] Campos F, Plazzotta F, Luna D, Baum A, de Quirós FG.

Developing and implementing an interoperable document-based electronic health record. Stud Health Technol Inform. 2013;192:1169. PubMed PMID:

23920943. Address for correspondence MSc. Fernando Campos Chief of Software Engineering Health Informatics Department Hospital Italiano de Buenos Aires HL7 Argentina Chairman [email protected] F . Campos etal. /Design, Implementation andEvaluation of an Arc hitectur eBased onthe CD A R2 Document Repository 177 Copyright ofStudies inHealth Technology &Informatics isthe property ofIOS Press andits content maynotbecopied oremailed tomultiple sitesorposted toalistserv without the copyright holder'sexpresswrittenpermission. However,usersmayprint, download, oremail articles forindividual use.