Tuesday, April 20, 2010

Disaster recovery planning

Disaster recovery planning

Introduction: DRP encompasses all measures taken to ensure organizational survival in the enet of a natural or manmade calamity and to minize the impact of such an event on the originzation’s staff, patients, and the community

- The objective of disaster recoevery plans is to safeguard patient care.

-

The goal of the planning process is to minimize the distrubtion of operations and ensure a measure of organizational stability and orderly recovery after a disaster.

In all organization or facilities, a formal planning method is needed to ensure quality, consistency and comprehensiveness of disaster recovery contingency plans.

DR is not a one-time, finished produce but a proce that must plans as elemements in the orginzation change


Planning process:

Risk identification: which problems might occur?

Risk analysis: what would e their impact?

Risk prioritization: which problems are the most citrical?

Risk reduction: how can I reduce the impact of the problems?

Risk management planning: how will I apply this to the project?

Risk monitoring and testing: how effective is our risk control?

Disaster Recovery Planning
DRP encompasses all measures taken to ensure organization survival in the event of a natural or manmade calamity and to minimize the impact of such an event on the organization's staff, patients, and the community.
The objective of disaster recovery plans is to safeguard patient care.
The disaster recovery plan is an extensive, inclusive statement of actions to be taken before, during and after a disaster.
The plan must be regularly tested and updated to ensure the continuity of operations and the availability of critical data and processes in the event of a disaster.

Goal of planning process is to minimize the disruption of operations and ensure a measure of organizational stability and orderly recovery after a disaster.

In all organizations or facilities, a formal planning method is needed to ensure quality, contingency and comprehensiveness of disaster recovery contingency plans.

DRP is not a one-time, finished product but a process that must continually be used to update the contingency plans as elements in the organization change.

Planning Process:
Risk identification
Human threats;
1. is unauthorized access possible to either the physical site or information systems?
2. What safeguards are in place related to bomb threats, extortion, burglary, work stoppage, termination or resignation, or computer crime?
3. Sabotage is the major threat to any systems.

Risk Analysis
Records: consider the value of the records, both paper and electronic, that needs to be protected.
How much did it cost to create that record in the first place? What would it cost to recreate it now?
Does the information protect the rights of individuals, research, or the business interests of three agencies?
Is the information complete, or would other documents be necessary if action had to be taken.
How available is it? If the information could be obtained from another course without too much delay, its value is reduced.


Risk analysis
recreating the information:
calculate the cost of gathering the information from scratch, and then the cost of producing and reproducing it.
Reproducing only:
calculate the cost of duplicating your essential records now for off-site storage, or the cost of reproducing your off-side records for use after a disaster. The most visible from of information is paper, closely followed by magnetic and file records.

It would cost much less to duplicate now then to recreate later after the information has been destoryed.

Risk Prioritizing
Risk prioritization is all about determining "risk exposure".
The components of 'unsatisfactory outcome' may be cost, schedule, performance, and support.
Determining risk exposure provides the disaster planning project manager with a prioritized list of risks.

Risk reduction:
procedural presentation:
The goal of procedural prevention is to define acidifies necessary to prevent various disasters and ensure that these activities are performed as required.
Includes activities relating to security and recovery, performed on a day-to-day, month-to-month, or annual basis.
Examples include maintaining up-to-date backup copies of all computer files; annual verification of User IDs and passwords, maintaining a system for storing backup copies in place discrete from the course computer; and scheduling inspections and testing of smoke detectors, sprinkler systems, and fire extinguishers.

Disaster recovery plan
security: will the room/ vault/ cabinet be closed in an emergency? how can we secure documents if they have been retrieved?
Access: how can we arrange access to a cordoned off building? Who would be assigned to retrieve the materials?
Identification: if you were allowed to retrieve only one box of material, how would you identify the most urgent or critical one?
Restoration: if your documents are charred or soaked, do you know how to restore them?

Plan testing and maintain:
the contingency plan must be audited and tested on a regular basis to know that proposed processes serve the purpose of protecting the data and processes of the organization should a real disaster occur.
Most disaster recovery plans require a complete review of all procedures every 5 years tat focuses on refining the requirements, exploiting new technology, and using a fresh approach to consider new solutions to old problems.
With regular testing and an annual audit, the plan should be effective in processing critical data after a catastrophe occurs.


Infrastructure

Infrastructure

What is the Infrastructure?

- A conceptual level how the IT infrastructure supports an effective HER.

- Includes:supporting h/w, s/w and management systems required to run a particular apps or suite of apps

- Includes: data network, workstations, servers and telecommunications equipment and services

- IN most case, it also included the controlled environment in which many of these components operate.

- Backup and recovery plan

Network:

- use TCP/IP over LAN

- Network must be sized properly

Backup and recovery: how much security is enough>

No matter how carefully a system is design,tested and implemented, there will be tims when the system is unavavilble, either by plan or by accident

Planning for downtime is an important part of the overall implementation of any IT system but is particularly important when implementing an HER

- develop and test policies, procedures and technologies that will let u continue to function when the HER is unavailable.

- Amount of time, effort and money you decide to invest should be proportional to your level of risk, and the time, effort and money you llose when the sys is unavavilable.

Phased Implementation

Phased Implementation

Introduction: Phased implementation is the stepwise introduction of HER functionality though a series of phases, each with its own analysis, training, and go-live schedule

- phased approach spreads the users’ learning over time, producing several manageable peaks in cognitive load.

- The big-bang method vs. Modified implementation plan.

3 phases on implementation:

- Phase 1: Access to test results and transcribed docuemtns.

+ Cart abstraction methods: doctor, nurses, give back to clinician to verify

+ scanning: large volume of clinical relevant docs that would not incorporated electronically (like AE note)

- Phase 2: Electronic results distribution, transacription Authentication and E-Messaging.

+ Test results and transacribed documents are sent to providers’ inbasket’ for review and electronic signature

- Phase 3: Order Entry and Patient-care documentation

+ order entry: one of the first tasks is the creation of customized pick list of Dx, Px, Test and drugs

+ one of the kket to creating effective lists is translating the sometimes consing standard lists into language that is familiar to clinicians

+ documentation: in this phas, user begin to enter the clinical assessements and plan directly into the HER

+ the HER makes it easy to build note templates and importable boilerplate that allow a skilled user to document a typeical office visit by hitting minimal keystrokes and typingseveral sentences

+ developing a tool by collecting samples of the most commonly dictatred or the hardwritten documents from the paper medical records, prioritize note templates and to identify their contexts.


System Integration

System Integration

Introduction: integrating the HER, i.e., enabling the HER and oter software applications to exhchange data with each other without loss of meaning or accuracy, is one the critical tasks of the HER implementation and of ongoing production support

- integrate the HER begins with defining the components to be integrated.

- The HER system is a suite of applications that share a common DB. It may include scheduling, registration, OP HER, IP HER, A&E EHR, ADT, Phamarcy, Lab billingm and other apps.

- Ancillary applications are external to the HER system, but send infomrationto the suite’s DB (eg laboratory and pathology results) and may receive information from it (e.g. patient demographics)

- HER integration has a dual focus:

n First, on establishing interfaces with ancillary apps.

n Second on integrating data definitions and shared S/W function within the HER system

- Ancillary Apps.

n Integration of ancillary apps is essential to the success of the EHR’s usabilibty and reliability

n Interfaces with laboratory results, ancillary patient registeration, radiology results etc.

- Back-end work – interfaces results from ancillary apps.

n Textual reports should display the most pertinent information first

n Formatted information displays from ancillary apps should be as readable in the HER as they are in the originating applications

Technical interface considerations:

- Decide what data should be stored in the HER databases and what should remain in ancillary apps.

- Document the specifications for each interface

n This documentation should identify each data item and aggregate data flow. Data needs of various stakeholders is best to interface every data field and then use the interface engine to control which fields actually enter the HER

- Active, continuing management of error logs in necessary to assure the integrity of the data in EHR.

n Analyzes the logs, designs a process for handling the errors, monitor the logs and resolve the erros

n When system served only outpatient practices, monitored and the outpatient HER logs once daily, mon to fri. The IP HER, monitor the logs every 4 hours, seven days a week.

n develop a detailed testing scenario for every interface message type sent and received

- Integrating the EHR DB

n Data integration among the applications that share the single HER DB

n Detailed analysis needs to confirm that shared data fields have the same definition and use in the vaiour HER applications before the development, population and maintnenance of the data tables

- Integratd Application testing

n Ensures that new and existing S/W functions perform well together.

n 1st, tst within the app

n 2nd test the functions across the apps to the HER systems

n Test plan will help to identify testing dependencies and prerequistites

n Scenario-based testing ensures that recommended workflows are functional throughout the HER system

The Information System life cycle

The Information System life cycle

The purposes of the information system life cycle:

- The information system life cycle provides an conceptual framework for presenting and understanding the activities involved throughout the system development process.

- The system life cycle also provides a management framework for scheduling and coordinating information system development and for monitoring its process.

It is based on the use of structured methods of analysis, design and programming

- There are 8 phases in the system life cycle:

n Identify user needs

n Establish user requirement

n Determine the hardware and system software environment

n Design the system

n Develop th

n e system acceptance tests

n Construct the system

n Integrate the system with the using organization

n Operate, modify, and enhance the system.

Identify the users needs: determine the proposed system promises sufficient potential benefit to invest the additional resources necessart to establish the user requirements in greater detail

Establish user requirements: involves analyzing how things are currently being done and then describing the new system explicitly and in detail. Structured specification, a document containing the new system requirements and defining what parts of it are to be automated. – more realistic estimates of the cost and effort to compete the system design and development.

Determine the H/W and S/W: OS, DB, I/O, creating the supporting CG displays and UI; H/W selection and configurations from several vendors

Design the system: requirements presented in the structured specification are also the basis for system design.

Completed system design is also used to prepare plans, budgets and schedules for programming, testing, and debugging te system

Develop the system acceptance

- performance targets established in the structurd specification are used to develop detailed and specific tests of acceptable system performance

- tests determine whether the system as constructed by its developers satifies the users’ requirements

- the acceptance tests should e developed by people who are not involved in the design or construction of the system.

Construct the system: review, use and evaluation of the user manual is part of the acceptance test.

Integrate the system with the using organization: this requires the training of the users, the delivery and installation of any additional hardware, the conversion or creation of the files or database for the system plus, possible of the parallel operation of both old and new systems.

After the transition & integration is over, the post-implementation review should be held to evaluate whether the orginal system objectives as wel as the user’s requirements and performance targets continue to be met.

Operate, modify and enhance the system.

- if the post-implementation review find a discrepancy between the system’s performance and the specified system requirements, it will be necessary to correct the deficiencies (or relax the performance requirements)

HSS5301 EHR Needs assessment


EHR Needs assessment

definition of a Needs Assessment

- implementing an EHR requires that you conduct a needs assessment, identify and quantify measures of success, and determine the methods for maximizing ongoing benefit realization.

- needs assessment as a systematic process to develop an accurate understanding of the strengths and weaknesses of a business process in terms of efficiency and quality

- this understanding is used to set and prioritize goals, to develop a plan, and to allocate resources.


Function of needs assessment

- who needs what information, at what times, and in what locations for what purposes?

- this question is asked for existing work flows processes and then reviewed when designing optimized work-flows

- to assess current work-flows and design optimized work-flows

- then assessed software functionality that would be needed to achieve the optimized work-flows.


Important goals need to be balanced:

- patient safety

- health care quality

- process efficiency

- other organizational business plans and goals

- EHR usability


Measures of Success

- Explicit measures of success (short-term and long-term) are critical to the success of an implementation

- Provide the meas of monitoring the progress of the project and communicating that progress

-Identify new measures as the implementation progresses (or modify existing measures based on ongoing review)

- Care quality versus financial, and quantitative vs directional

+ Directional benefits are difficult to quantify

+ On the other hand, number of lines of transcription is a quantifiable measure.

+ Improved care processes can also be measured quantitatively