Difference between revisions of "Design, Implementation and Evaluation of an Architecture based on the CDA R2 Document Repository to Provide Support to the Contingency Plan"

From Clinfowiki
Jump to: navigation, search
(Related Articles)
 
(10 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 
== Introduction ==
 
== Introduction ==
[[Contingency planning for electronic health record-based care continuity: a survey of recommended practices|Contingency plan]] is necessary to ensure a safe and smooth workflow of [[EMR|EHRs]] during downtimes. The authors point out that an effective contingency plan should be able to address the causes and consequences of EHR unavailability, triggering process and preparations that can minimize the frequency and impact of such events while ensuring care continuity. To this end, the authors design, implement and evaluate a contingency plan at the lab scale that uses the [[Clinical Document Architecture (CDA)|Clinical Document Architecture (CDA)]] Release 2 (R2) document repository to support continuity of care during downtime. <ref name="2015 Campos">Campos, 2015. Design, Implementation and Evaluation of an Architecture based on the CDA R2 Document Repository to Provide Support to the Contingency Plan. http://www.ncbi.nlm.nih.gov/pubmed/26262033 </ref>
+
[[Contingency planning for electronic health record-based care continuity: a survey of recommended practices|Contingency plan]] is necessary to ensure safe and smooth workflow of [[EMR|EHRs]] during downtimes. An effective contingency plan should be part of the health care organization and able to address the causes and [[Characteristics of health IT outage and suggested risk management strategies: an analysis of historical incident reports in China|consequences of EHR unavailability]], triggering process and preparations that can minimize the frequency and impact of such events while ensuring care continuity. The authors of this study illustrate the design, implementation and evaluate a contingency plan at the lab scale that uses the [[Clinical Document Architecture (CDA)|Clinical Document Architecture (CDA)]] Release 2 (R2) document repository to support continuity of care during downtime. <ref name="2015 Campos">Campos, 2015. Design, Implementation and Evaluation of an Architecture based on the CDA R2 Document Repository to Provide Support to the Contingency Plan. http://www.ncbi.nlm.nih.gov/pubmed/26262033 </ref>
  
 
== Methods ==
 
== Methods ==
Line 6: Line 6:
 
1) Level 1 is the application downtime, which refers only to problems such as deployment of new version or server issues that is related to EHRs, otherwise the rest of the computing infrastructure operation is normal.  
 
1) Level 1 is the application downtime, which refers only to problems such as deployment of new version or server issues that is related to EHRs, otherwise the rest of the computing infrastructure operation is normal.  
 
2) Level 2 is the total impact, which refers to situations when database server is affected. For example, natural disasters, database upgrade or maintenance, network outages and data center problems affecting the server farm or storage.  
 
2) Level 2 is the total impact, which refers to situations when database server is affected. For example, natural disasters, database upgrade or maintenance, network outages and data center problems affecting the server farm or storage.  
Planned contingency tests (about 20 level 2) were run on different days at randomized times.  
+
Planned contingency tests (about 20 level 2) were run on different days at randomized times.
  
 
== Results ==
 
== Results ==
 
In order to tackle level 1 contingency, the authors developed a CDA navigator, which has some of the elements of CDS as its indexes, which is used to generate a tree that can be accessed based on patient information. From the tree root (any patient of interest), time line for inpatient can be navigated and the caregiver can access all the data from the specified date. This application is deployed on a different server from the EHR, and with a different and redundant database. During EHR contingency the document based EHR can be retrieved.  
 
In order to tackle level 1 contingency, the authors developed a CDA navigator, which has some of the elements of CDS as its indexes, which is used to generate a tree that can be accessed based on patient information. From the tree root (any patient of interest), time line for inpatient can be navigated and the caregiver can access all the data from the specified date. This application is deployed on a different server from the EHR, and with a different and redundant database. During EHR contingency the document based EHR can be retrieved.  
In designing a plan to overcome level 2 contingency, two pieces of information, present medication list and proper labeling for laboratory samples, were identified as a necessity to provide continued care. Based on this, an application was developed to access the document repository every 30 minutes. The computers running this application were dedicated only for downtime use and connected to a local printer and uninterrupted power supply. These computers have a specific local disk space to a folder tree organized by department and inpatient location. Several computers run this application redundantly at specific locations.
+
 
During this study, there were both planned and unplanned downtimes from a minimum of one hour to a maximum of 25.01 hours, during which the facility was able to access patient medications and print prescriptions, in some occasions more than thousand times and these printed prescriptions were erroneous in only < 2% of cases.  
+
In designing a plan to overcome level 2 contingency two pieces of information, present medication list and proper labeling for laboratory samples, were identified as necessities to provide continued care. Based on this, an application was developed to access the document repository every 30 minutes. The computers running this application were dedicated only for downtime use and connected to a local printer and uninterrupted power supply. These computers have a specific local disk space to a folder tree organized by department and inpatient location. Several computers run this application redundantly at specific locations.
 +
 
 +
During this study, there were both planned and unplanned downtimes from a minimum of one hour to a maximum of 25.01 hours, during which the facility was able to access patient medications and print prescriptions (in some occasions more than thousand print outs were taken) and these printed prescriptions were erroneous in only < 2% of cases.
  
 
== Conclusions ==
 
== Conclusions ==
Line 17: Line 19:
 
   
 
   
 
== Comments ==
 
== Comments ==
This is the first study that proposes and tests a contingency plan for EHRs at the lab scale. However, the robustness of this method has to be further tested in other large and small organizations. Additional costs incurred for this contingency plan may make its implementation difficult, which may arise a need for more affordable alternatives.
+
This is the first study that proposes and tests a contingency plan for EHRs at the lab scale. However, the robustness of this method has to be further tested in other large and small organizations. Additional costs incurred for this contingency plan may make its implementation difficult, which may arise a need for more [[Downtime procedures for a clinical information system: a critical issue|affordable alternatives]].
  
 
== Related Articles ==
 
== Related Articles ==
  
[[Contingency planning for electronic health record-based care continuity: a survey of recommended practices|contingency plan]]
+
[[Contingency planning for electronic health record-based care continuity: a survey of recommended practices|Contingency Plan]]
 +
 
 +
[[Downtime procedures for a clinical information system: a critical issue]]
  
 
== References ==
 
== References ==
Line 29: Line 33:
 
[[Category: Reviews]]
 
[[Category: Reviews]]
 
[[Category: EMR]]
 
[[Category: EMR]]
 +
[[Category: HI5313-2015-FALL]]
 +
[[Category: EHR]]

Latest revision as of 06:53, 21 October 2015

Introduction

Contingency plan is necessary to ensure safe and smooth workflow of EHRs during downtimes. An effective contingency plan should be part of the health care organization and able to address the causes and consequences of EHR unavailability, triggering process and preparations that can minimize the frequency and impact of such events while ensuring care continuity. The authors of this study illustrate the design, implementation and evaluate a contingency plan at the lab scale that uses the Clinical Document Architecture (CDA) Release 2 (R2) document repository to support continuity of care during downtime. [1]

Methods

The contingency plan proposed in this study utilizes the redundancy generated by the document repository. The authors conduct a laboratory function study and classify the EHR downtime into two main groups: 1) Level 1 is the application downtime, which refers only to problems such as deployment of new version or server issues that is related to EHRs, otherwise the rest of the computing infrastructure operation is normal. 2) Level 2 is the total impact, which refers to situations when database server is affected. For example, natural disasters, database upgrade or maintenance, network outages and data center problems affecting the server farm or storage. Planned contingency tests (about 20 level 2) were run on different days at randomized times.

Results

In order to tackle level 1 contingency, the authors developed a CDA navigator, which has some of the elements of CDS as its indexes, which is used to generate a tree that can be accessed based on patient information. From the tree root (any patient of interest), time line for inpatient can be navigated and the caregiver can access all the data from the specified date. This application is deployed on a different server from the EHR, and with a different and redundant database. During EHR contingency the document based EHR can be retrieved.

In designing a plan to overcome level 2 contingency two pieces of information, present medication list and proper labeling for laboratory samples, were identified as necessities to provide continued care. Based on this, an application was developed to access the document repository every 30 minutes. The computers running this application were dedicated only for downtime use and connected to a local printer and uninterrupted power supply. These computers have a specific local disk space to a folder tree organized by department and inpatient location. Several computers run this application redundantly at specific locations.

During this study, there were both planned and unplanned downtimes from a minimum of one hour to a maximum of 25.01 hours, during which the facility was able to access patient medications and print prescriptions (in some occasions more than thousand print outs were taken) and these printed prescriptions were erroneous in only < 2% of cases.

Conclusions

In unexpected EHR downtime the proposed contingency plan works well at the lab scale. The limitation of this contingency plan is that the back up occurs every 30 minutes instead of continuous real time.

Comments

This is the first study that proposes and tests a contingency plan for EHRs at the lab scale. However, the robustness of this method has to be further tested in other large and small organizations. Additional costs incurred for this contingency plan may make its implementation difficult, which may arise a need for more affordable alternatives.

Related Articles

Contingency Plan

Downtime procedures for a clinical information system: a critical issue

References

  1. Campos, 2015. Design, Implementation and Evaluation of an Architecture based on the CDA R2 Document Repository to Provide Support to the Contingency Plan. http://www.ncbi.nlm.nih.gov/pubmed/26262033