Case-integrated delivery network


Case Study:

An integrated delivery network (IDN) serving a large urban and rural demographic area is using separate EHR systems in its inpatient and outpatient settings. Some of the specialty departments have also purchased their own systems for documentation. Unfortunately this means that information collected in the inpatient setting is not available when patients are seen in the IDN's outpatient clinics (and vice versa). The clinicians need this information to be better informed about their patients and to provide optimal care. In addition, new Meaningful Use requirements for problems, medications, and allergies as well as new chronic disease care initiatives that the IDN is implementing for its patient population are being hindered by the separate systems. The clinicians have been given accounts on both EHRs but this is cumbersome for the users because they must be trained on multiple systems, they use valuable time logging into different systems and navigating for information, and there is a potential safety issue if the user selects different patients on the two EHRs. A coordinated decision support environment has also been difficult to implement because the two EHRs use different coding systems and do not share most of their information. This means, for example, that admission rules for congestive heart failure patients are unable to use the ambulatory medication list and recent vital signs measurements in order to run the IDN's standard care process models.

The IDN realizes that it will not be able to replace either EHR in the near future and, even if it could, there will still be issues with integrating information from the specialty care systems. It decides on a strategic plan to create a clinical data repository (CDR) that is fed with high-value data from each of the clinical systems. The outpatient EHR's master person index already was being used as the master unique identifier for most of the IDN's systems, so it can be incorporated with the new CDR. A robust interface engine is implemented to supply data from the clinical systems to the CDR. To normalize the different terminologies used on their various systems, the IDN engages a terminology services vendor to provide a central data dictionary for the CDR and map the concepts from the current systems to the central standard terminology. The interface engine uses the terminology services to normalize inbound data to the CDR from the other systems.

The second phase of the strategic plan is to build a CDS system on top of the CDR in order to develop and maintain enterprise patient care rules. As rules are fired, their results will be both sent through the interface engine to the existing EHRs and stored in the CDR; storing the decision support results in the CDR provides a link to supporting data from all clinical systems, which can help with rule triage and maintenance. Another effort in this phase is to provide clinician views into the CDR. The IDN plans to build data services that can be called by third-party EHRs in order to display longitudinal, enterprise-wide patient data from within the EHRs. Several simple web- and mobile-based viewing applications using the data services will also be developed and will be available in a stand-alone mode or as callable modules within the current EHRs. The IDN will use CCOW to provide the user and patient context from the EHR to these viewing apps so that the clinicians will not have to log in twice and find the patient.
 
Your answer must be typed, double-spaced, Times New Roman font (size 12), one-inch margins on all sides, APA format.

Solution Preview :

Prepared by a verified Expert
Other Subject: Case-integrated delivery network
Reference No:- TGS01902302

Now Priced at $30 (50% Discount)

Recommended (90%)

Rated (4.3/5)