emr implementation plan template

7/30/2019 Emr Implementation Plan Template

1/114

Developing an EMR System Implementation Plan (DRAFT) Guidelines | 1


2/114

Developing an EMR System Implementation Plan (DRAFT) Acknowledgments

ACKNOWLEDGMENTS

The workshop organizers, CDC Zambia, and the President's Emergency Plan for AIDS Relief

(PEPFAR) Health Management Information Systems Technical Working Group would like to

thank all of the participants and cooperating partners who were involved in planning and

carrying out the Strategies for Building National-Scale Longitudinal Patient Monitoring Systems

for HIV Treatment and Care in PEPFAR Countries Workshop from October 2 to 5, 2007, in

Lusaka, Zambia. The workshop organizers would especially like to thank the Zambia Ministry of

Health and the National AIDS Council of Zambia for their support.

The knowledge and experience shared by the representatives from the 15 countries who

attended the workshoptogether with U.S Government in-country mission staff members,

PEPFAR implementing partners, host country government staff members, and experts from

industry, academia, and multilateral organizationshave helped to greatly improve this

document from the working draft that was provided to workshop participants and used in small

group discussions and exercises.

This document has benefited from previous work in the field of electronic medical record

systems, particularly the World Health Organization documents Electronic Health Records: A

Manual for Developing Countries and Developing Health Management Information Systems: A

Practical Guide for Developing Countries, and the Joint United Nations Programme onHIV/AIDS document, Guidelines on Protecting the Confidentiality and Security of HIV

Information: Proceedings From a Workshop. In addition, the authors would like to gratefully

acknowledge the workshop participants who generously shared protocols, reports, and tools

from the development, piloting, and rollout of the SmartCare system in Zambia, the National

Electronic Data System for Antiretroviral Therapy Monitoring and Evaluation in Malawi, and the

Botswana HIV/AIDS Response Information Management System District Informatics

Assessment.


3/114

Developing an EMR System Implementation Plan (DRAFT) Table of Contents | i

TABLE OF CONTENTS

INTRODUCTION ............................................................................ 1

How to Use This Document ...................................................................... 1

DEVELOPING AN EMRSYSTEM IMPLEMENTATION PLAN:GUIDELINES ... 3

A. Budgeting and Governance .............................................................. 3

1.0 Budgeting ........................................................................................................ 31.1 Building or Buying a System ................................................................ 41.2 Open Source or Proprietary Software .................................................. 4

2.0 Policy and Governance ................................................................................... 52.1 Executive and Steering Committees .................................................... 62.2 Barriers to Success .............................................................................. 82.3 Type of Implementation: Full vs. Phased ............................................. 92.4 Stakeholder Analysis and Consultation ............................................... 92.5 Integration and Retention of Existing Data ........................................ 102.6 Coexistence of Paper and Electronic Record Systems ..................... 102.7 Establishment of Project Teams/Working Groups ............................. 11

B. Pre-Implementation: Analysis, Requirements/ Specification,Design, and Testing ......................................................................... 16

3.0 Existing Systems Assessment ....................................................................... 183.1 Inventory of Existing Health Information Systems ............................. 183.2 Determining the Maturity of the Data Management Process ............. 193.3 Data Standards .................................................................................. 213.4 Unique IDs ......................................................................................... 233.5 Documenting Health Data Policies .................................................... 23

4.0 Health Management Information System (HMIS) User Assessment ............. 244.1 Engaging Users ................................................................................. 244.2 Determining User Needs ................................................................... 244.3 Follow-Up Assessments of Users ...................................................... 24

5.0 Risk Assessment/Management Strategy ....................................................... 255.1 Safeguards ........................................................................................ 26

6.0 Infrastructure Assessment ............................................................................. 286.1 Software Requirements ..................................................................... 29

7.0 Confidentiality and Security ........................................................................... 308.0 Requirements/Use of Data Assessment ........................................................ 33

8.1 Reporting on EMR System Implementation ....................................... 338.2 Other Data Use Requirements .......................................................... 35

9.0 Data Entry ...................................................................................................... 35


4/114

Developing an EMR System Implementation Plan (DRAFT) Table of Contents | ii

TABLE OF CONTENTS (CONT.)

10.0 Design ........................................................................................................... 36

10.1 Database Design ............................................................................... 3610.2 Interface Design ................................................................................. 3610.3 Functional Design .............................................................................. 37

11.0 Testing ........................................................................................................... 3811.1 Systems Testing ................................................................................ 3811.2 Test Scripts ........................................................................................ 3911.3 End-to-End System Testing ............................................................... 4011.4 User Acceptance Testing ................................................................... 4011.5 Data Requirements ............................................................................ 40

C. Implementation ................................................................................ 41

12.0 Roll-Out and Scale-Up ................................................................................... 41

12.1 Roll-Out and Scale-Up Timeframes ................................................... 4112.2 Site Selection ..................................................................................... 4212.3 Assessing Site Readiness ................................................................. 4312.4 Operations Analysis ........................................................................... 4312.5 Baseline Assessment ........................................................................ 4512.6 Training .............................................................................................. 4512.7 Security and Confidentiality ............................................................... 4812.8 Backlog Data Entry ............................................................................ 4912.9 Post Implementation Review ............................................................. 4912.10 Maintenance and Support .................................................................. 50

13.0 Monitoring and Evaluation (M&E) .................................................................. 5113.1 M&E of EMR System Implementation ............................................... 51

13.2 The Role of EMR Systems in National M&E ...................................... 60

APPENDICES

Appendix AGlossaryAppendix BBibliography of EMR System ImplementationAppendix CDeveloping an EMR System Implementation Plan: Template


5/114

DEVELOPING AN EMRSYSTEM IMPLEMENTATION

PLAN:GUIDELINES


6/114


INTRODUCTION

The Strategies for Building National-Scale Longitudinal Patient Monitoring Systems for HIV

Treatment and Care in PEPFAR Countries Workshop was held October 25, 2007 in Lusaka,Zambia. The purpose of the workshop was to enable participants to learn from each other, from

country case studies, and from academic and industry experts about best practices in developing

strategies for building national-scale, longitudinal, and patient-level patient monitoring systems for

HIV treatment and care in the President's Emergency Plan for AIDS Relief (PEPFAR) countries. A

working draft of this document was provided to workshop participants and used in small group

discussions and exercises. The draft served to guide discussions and to provide a framework that

participants could use to develop and document electronic medical record (EMR) system

implementation strategies tailored to suit their particular countrys circumstances and technical

infrastructure.

How to Use This Document

The purpose of this document is to guide the reader through the process of developing an EMR

system implementation plan. A template is provided in Appendix C that will allow readers to begin

developing an EMR implementation plan for their own country or program. This document is not

intended to be a set of definitive rules applicable in every situation, as each country or program

will have different needs and requirements, but a resource to help ensure that key activities and

issues are considered and addressed before proceeding with the task of developing andimplementing an EMR system. This document is intended to be used in conjunction with the

hyperlinked Bibliography of EMR System Implementation (Appendix B) which was also initially

developed for the Lusaka workshop, with the presentations from the workshop and other

reference materials, all of which are posted to the Lusaka workshop Web site

(http://globalhivevaluation.org/zambia-epms2007.aspx) and, where relevant, hyperlinked to this

document. The content and links to additional resources will be valuable to reference during all

stages of EMR system planning and implementation.

NOTE: Throughout this document, the bullet () is used to indicate a relevant document orpresentation that readers may find useful in preparing their own EMR implementation plans. If you

are using this document in an electronic form, a hyperlink is provided that will allow you to

download the materials. If you are using this document as a hard copy, the Web address where

you can find the materials is also provided. If you have any difficulty in accessing the links


7/114


provided, please go to the Lusaka workshop Web site (http://globalhivevaluation.org/zambia-

epms2007.aspx) where you will be able to find the materials.


8/114


DEVELOPING AN EMRSYSTEM IMPLEMENTATION PLAN:

GUIDELINES

A. Budgeting and Governance

1.0 Budget ing

Implementation of EMR systems is a complex and challenging task. One obstacle to successful

implementation can be the cost of converting to an electronic system when insufficient health care

funding has been budgeted. It is essential that stakeholders and personnel involved in planning

for EMR implementation understand what funding is available and develop a timeframe for

funding in conjunction with timetables for implementation.

The high cost of computers and computer systems means that the initial costs associated with the

introduction of an EMR are significant, both in terms of time and finance. However, the ongoing

costs of running an EMR as well as longer-term issues of maintenance and support are significant

as well. As discussed below in the Maintenance and

Support Section (Section 12.10), once an EMR system

has been implemented, both the hardware and the

software will undergo changes after delivery in order to

fix bugs, add new functionality, port the software to new

platforms, or adapt the software to new technologies.

Although it may seem that the system will be finished

after delivery, this is far from true. Maintaining and

enhancing software to cope with newly discovered

problems or new requirements can take more time than

the initial development of the software, and so must be budgeted for accordingly.

Table 1 lists some of the costs that should be considered when budgeting for EMR system

implementation. Note that many costs (whether for hardware, software, training, etc.) may have to

be budgeted for the national level as well as for district, regional, and facility levels.

Recommendations

Ensure adequate funding isavailable to provide systemsoftware, hardwareinfrastructure, and

implementation resources.

Ensure that a financialmanagement plan is in place toincorporate initial costs, ongoingneeds, and long-termmaintenance and support.


9/114


Table 1: Costs to Consider in EMR System Implementation

Initial Costs Hardware

Software (development, debugging, testing, etc.)

Training

Consultants

Pilot testing

Ongoing Costs Enhancements

Coordination/collaboration with other sectors (integration of HIV/antiretroviral

therapy [ART] EMR systems with non-HIV Health Information Systems, with

financial data, etc.)

Technical assistance

Outward migration/training of replacement staff members

Evaluations

Maintenance

and Support

Costs

Equipment maintenance: Care of equipment (computers, touch screens,

keyboards, card readers, etc.)

Corrective maintenance: Fixing bugs in code Adaptive maintenance: Adapting the software to new environments

Perfective maintenance: Updating the software according to changes in user

requirements

Preventive maintenance: Updating documentation and making the software more

maintainable.

1.1 Building or Buying a System

It is not always necessary for countries or institutions to develop their own EMR systems. If

possible, an estimate should be obtained as to the possible cost of conversion from a manual

system that incorporates different options, including having a system designed specifically for a

country or purchasing a system already developed and implemented elsewhere. These options

have different costs, advantages, and disadvantages associated with them which should be

considered when making decisions. Ideally, a thorough cost-benefit analysis should be conducted

to compare the options and the costs of proposed systems against the perceived benefits, so as

to determine the value of the systems to an institution/government.

1.2 Open Source or Proprietary Software

Countries and institutions will also have to decide whether to budget for the purchase ofproprietary software or to use open source software. There are advantages and disadvantages to

each option. It should be noted that open source software is not truly free as it will still be

necessary to budget for programmers, training, adaptation, upgrades, etc. In some cases where

human and technical capacity are limited, there can be reasons to use proprietary software that

come with access to support. If countries do decide to use proprietary software, it is advisable to


10/114


seek outside advice from experts to review contracts before signing, in order to ensure that the

contract will provide all the services that are needed. It is important to note that open source and

proprietary systems can be used in the same health system, as long as they are mutually

compatible. This issue is discussed further in Section 3.3.

Further Reading

Issues relating to the use of open source software for an EMR system were discussed in the

presentation Integrated System for HIV/AIDS and TB Data Management in South Africa

(http://www.globalhivevaluation.org/meetings/zambia2007/PresentationMaterials.aspx?id=1_1440

_1530).

2.0 Pol icy and Governan ce

The responsibility for all stages of the development, implementation, and maintenance of an EMR

system must be agreed upon in advance. All major partners and stakeholders should be in

agreement as to who will assume responsibility for funding and carrying out tasks, and who will

have the authority to make decisions if differences of opinion should arise. Establishing roles and

responsibilities is an important part of planning for EMR implementation, and can be carried out in

conjunction with the process for identifying and engaging stakeholders. Some important elements

of preparation for an EMR system implementation which should be agreed on by all stakeholders

include the following:

Who will be responsible for managing and carrying out the EMR implementation process?

Are resources, a budget, and authority available to carry out these tasks?

Who will take part in the executive and steering committees and working groups (i.e.,

composition and areas of expertise)? (See Section 2.1)

It is equally important to determine whether existing policies will support the development of a

new EMR system. Policies relating to medical record practice should be reviewed to identify areas

which will require updating to cover electronic medical records. Consider the following:

Does the country have a record retention policy? If so, is it being applied? Will it require

revision?

Does the country have a policy on the release of information from personal health records?

Does it need revision?


11/114


What is the policy on patient access to their health care information? If there is no policy, is it

envisaged that patients will have access to their health information in the future?

If policies need to be developed or changed, who has the authority to make and enforce these

changes?

Does the government system facilitate the process for acquiring needed technologies?

Example

An analysis of health information systems (HIS) implemented in Tanzania and Mozambique

concluded that one of the key reasons that the systems were ultimately unsustainable was, in

both cases, the unbalanced relationship between the Ministry of Health and donors. Additionally,

weak institutional and technical capacity within the ministries, along with contracts that gave them

insufficient control over consultants, also contributed to unsustainable systems. These examples

highlight the importance of governance in EMR implementation.

Analyzing the Problem of Unsustainable Health Information Systems in Less Developed

Economies: Case Studies From Tanzania and Mozambique, by Kimaro and Nhampossa

(http://media.shs.net/globalaids/pdf/Article%202g%20-

%20Kimaro_Analyzing%20the%20Problem%20of%20Unsustainable%20HIS.pdf).

2.1 Executive and Steering Committees

It is suggested that an executive committee charged with

introducing the EMR be formed. The purpose of the

committee is to provide high-level oversight and provide a

conduit between the project team, government health

officials, and other stakeholders. The executive

committee will be comprised of a champion or visionary

for the initiative, sponsors, and other stakeholders. The

executive committee should be supported by a steering

committee that will be responsible for undertaking the planning and development of the proposedEMR system. This committee should consist of members of the administration, health information

management staff members, potential users from the medical and nursing services,

representatives from financial and information technology (IT) services, and any other individuals

identified as important to include. The steering committee should seek to ensure that there is early

input from medical and nursing

Recommendations

Establish an executivecommittee to oversee thedevelopment of the EMRsystem.

Establish a steering committeeto coordinate the implementationof the EMR system.


12/114


staff members, and other key personnel within the institution. This involvement will help garner

support from the anticipated users of the system who need to be involved from the onset of

discussions.

The degree of formality of the executive and the steering committee will depend on the size of theEMR system being implemented. For example, if a system is only being implemented at a single

facility, a steering committee may not be necessary. For implementing a national system, a more

formal committee structure may be preferable.

Once the extent to which automation may be achieved has been determined, the executive and

steering committees need to develop outcome goals for the EMR system that will encompass the

perceived benefits and meet the needs of both users and consumers. They should be clearly

stated, realistic, and achievable.

If the executive or steering committee members feel that they do not have an adequate technical

background to make decisions, they should consider employing a consultant. The consultant

should have a strong background in health information management, health informatics, and EMR

implementation in the developing world. HMIS experts at the Centers for Disease Control and

Sample Outcome Goals for an EMR System

Ensure that all health care data is comprehensive, timely, accurate, and readilyavailable at all times for patient care

Improve communication between health care providers at both data entry level anddata retrieval level

Provide better access to an individuals health care information and improve healthcare delivery by sharing their data between attending practitioners

Enable individuals to access their personal health information

Provide timely and accurate information for medico-legal purposes

Provide timely and accurate information for the collection of morbidity and mortalitystatistics, for clinical research, and teaching

Support the administration in their policy decision-making and public health reporting

Provide a better link between primary care centers, between primary care andsecondary care (hospitals), and between hospitals

Source: World Health Organization (2006). Electronic Health RecordsManual for Developing

Countries.


13/114


Prevention (CDC) and the U.S. Agency for International Development (USAID) can help the

executive committee identify appropriate consultants.

Some of the action items that the committee(s) will need to discuss include:

Project driverbusiness-related forces. For example, the purpose of a system is a project

driver, as are all of the stakeholders, each for different reasons.

Project constraintsidentify how the eventual system must integrate into a countrys IT

environment. For example, the system might have to interface with or use some existing

hardware, software, or business practice, or it might have to fit within a defined budget or due

date.

Functional requirementsthe fundamental subject matter of the system. These can be

measured by concrete means like data values, decision-making logic, and algorithms.

Non-functional requirementsthe behavioral properties that the specified functions must

have, such as performance, usability, etc. Non-functional requirements can be assigned a

specific measurement.

Mechanisms for managing project issuesthe conditions under which implementation of a

national-scale EMR system will be conducted.

2.2 Barriers to Success

An initial assessment will identify barriers that might hinder successful implementation. Forexample, countries may have no existing health information systems or infrastructure that can be

leveraged. Staff members with limited or no computer skills may be resistant to changes

introduced by an EMR system. Even if an initial assessment finds that the technical environment

will support an EMR system, resistance to its adoption by doctors and caregivers could prove a

major hurdle. Identified barriers should be documented and strategies to breach these barriers

and/or address resistance should be developed. Identified barriers will also inform the risk

assessment task described later in this document (Section 5.0).


14/114


2.3 Type of Implementation: Full vs. Phased

It is recommended that countries opt for a phased

implementation rather than a big bang approach of

attempting to implement a national system throughout an

entire country all at once. A big bang approach would

likely be overwhelming to the health system and would

allow very little latitude to react to unforeseen challenges

that may be encountered. A phased approach would limit any complications of implementing a

new system to just the institution(s) participating in a given phase. An evaluation of each phase

will allow lessons learned to be applied to subsequent phases. As the implementation proceeds,

the plan will be continually fine tuned to inform the later stages of the implementation plan.

2.4 Stakeholder Analysis and ConsultationBecause the success of the EMR system depends upon access to records and data collected in

multiple clinics throughout the country, a high level of cooperation and buy-in are required from

multiple institutions and from stakeholders. The introduction of an EMR system is most successful

when stakeholders are involved in all phases of development and implementation. Stakeholders

can be included in the process through an initial consensus-building meeting to identify the priority

needs regarding the EMR system, through the establishment of a regularly meeting taskforce, and

through ad hoc consultation.

A rigorous multidisciplinary process involving a range of

stakeholders is required to select the most appropriate EMR

system. Regular meetings of stakeholders should be scheduled

in order to secure and maintain buy-in and support for the EMR

implementation. Negotiations may include discussion of different

stakeholders needs that the EMR will attempt to satisfy and the

value of satisfying those needs.

In summary, an essential requirement for the successful

implementation of an EMR system is the cooperation and

commitment of all stakeholders, including administration, medical and nursing staff members,

other health care professionals, and computer and clerical staff members.

Recommendation

Countries should adopt a phased

implementation approach andevaluate each phase beforeadvancing to the next phase ofimplementation.

Stakeholder

A stakeholder is any personor organization who has avested interest in theresponse to the HIV/AIDSepidemic, the roll-out of ARTand EMR systems, themonitoring of patients thatare initiating ART, thedirection of the study, and

the use of data.


15/114


2.5 Integration and Retention of Existing Data

It is extremely important to make plans for how data from the existing system will be integrated

and retained in the new EMR system. Consider the following:

Will all old records be entered into the electronic record when the patient arrives for care afterthe new system is introduced?

Will old records be entered, kept in a secondary storage device, and brought into the new

system when needed?

Will summary information about a patient, rather than old records, be entered into the EMR

when the patient accesses care for the first time after the new system is in place?

Will old records that have been entered remain in manual storage for a prescribed time before

being destroyed?

Each option for integrating and retaining past data involves different levels of resources that must

be budgeted and planned for.

2.6 Coexistence of Paper and Electronic Record Systems

An EMR is not a simple replacement of the paper record. In almost every case, there will be a

long, perhaps indefinite, period of time when paper and electronic medical records will coexist. In

many systems, patient monitoring data will eventually be entered, analyzed, and transmitted

electronically. Systems vary as to when the paper to electronic transition occurs. It may occurduring initial ART scale-up, with an evolution toward earlier electronic entry over time. There may

also be differences between what can be done routinely at all sites and supported as a national

system, and what can be supported at facilities with special funding or research projects.

EMR systems are currently being developed to interface with paper-based systems at different

levels of data collection and analysis. Regardless of the data collection method, it is important that

the definitions of essential data elements be standardized so that each system, whether paper or

electronic, reports these data in a uniform way. Definitions of many data elements will already

exist (e.g., UNGASS indicators)1. There are also data definitions of national-level indicators in

countries M&E plans (e.g., PEPFAR indicators). Countries are encouraged to integrate the

1The UNGASS document, Monitoring the Declaration of Commitment on HIV/AIDS Guidelines on

Construction of Core Indicators [July 2005], contains detailed specifications of global indicators for nationalHIV/AIDS programs, the information required to measure them, and guidance on their interpretation(http://data.unaids.org/publications/irc-pub06/jc1126-constrcoreindic-ungass_en.pdf).


16/114


existing data definitions into their EMR systems. These indicators are designed to help countries

assess the current state of their national response while simultaneously contributing to a better

understanding of the global response to the HIV/AIDS pandemic. The use of shared indicator

definitions, data, and reports in a nonconnected environment helps provide a more unified

monitoring system in the absence of a high level of connectivity. Staff members involved in the

design and implementation of EMR systems should interact with their national M&E team

counterparts throughout the process of designing and rolling out the EMR system. This is

discussed further in Section 13.2.

Table 2 shows the range of ways a paper-based system can link with district-level electronic

reporting, from a minimal system of electronic entry of reports by the district or regional

coordinator to a fully electronic system using an EMR.

Table 2. Paper-Based and Electronic Patient Monitoring Systems

System Type PatientCard orRecord

Register(s) QuarterlyCross-Sectional

and CohortReports

District orRegional

Coordinatorand Up

Paper-based system withelectronic entry of reports

Paper Paper Paper Paperelectronic

Paper-based systemwith electronic entry of registers

Paper Paperelectronic

Electronic Electronic

Electronic medical record (EMR)

with electronic entry of paperrecords

Paper

electronic

Electronic or

may beprinted fromelectronicdatabase


EMR with direct electronic entrywithout paper when managingpatients

Electronic Electronic orN/A


Source: WHO - Patient Monitoring Guidelines for HIV Care and Antiretroviral Therapy (ART)(http://www.who.int/3by5/capacity/ptmonguidelinesfinalv1.PDF)

2.7 Establishment of Project Teams/Working Groups

Given the scope of implementing national-scale EMR

systems, it is important to designate teams with

responsibility for discrete facets of the project, including

time parameters and resources needed. If countries have

not already done so, they are encouraged to establish a national EMR working group comprised

of representatives of all major stakeholders in the National AIDS Program (NAP). Analyses should

Recommendation

Establish a national EMR workinggroup.


17/114


be carried out to identify all major stakeholders and their needs and roles in EMR system

implementation. The national EMR working group may include:

All members of the NAP who are assigned responsibility for EMR system development and

coordination

Ministry of Health (MOH) technical staff members responsible for disease surveillance,

reporting, and HMIS oversight

Technical staff members who have access to population demographic and life expectancy

data

Leaders of all major nongovernmental organizations and faith-based organizations that

operate HIV/AIDS programs and/or services

Researchers from universities and research groups involved in (or who will become involvedin) various special studies and targeted evaluations

Major donors that support the NAP

People living with HIV/AIDS

Representatives of UN agencies (Joint United Nations Programme on HIV/AIDS [UNAIDS],

the World Health Organization [WHO], United Nations Childrens Fund [UNICEF])

Consultants working with NAP, as appropriate

Further Reading

The composition and role of a national EMR working group, the Electronic Data System Task

Force in Malawi, was described in the presentation, Overview of the Development, Piloting, and

Evaluation of a National Electronic Data System for ART M&E in Malawi

(http://www.globalhivevaluation.org/meetings/zambia2007/PresentationMaterials.aspx?id=1_1630_1710).

Other working groups might include:

Information Security Group

The steering committee should appoint a team to deal with medico-legal aspects, including

privacy and confidentiality issues. This group should develop and maintain a medico-legal

checklist, incorporating government regulations, to guide the implementation and ongoing use of

the EMR. Measures should be taken to ensure appropriate security and storage of information to

prevent improper disclosure.


18/114


Education and Training Group

A training team needs to be in place to develop education and training programs. As previously

discussed, onsite training must be planned and budgeted for in order to develop a group of

competent users who are confident in their knowledge of the proposed system and ready to

accept the change. The steering committee may identify the need to have more trainers than staff

members onsite during early preparation for the introduction of an EMR system.

The education and training group should:

Prepare a training program with clearly stated learning objectives. The program should aim at

not only educating staff members in using the new system, but also ensuring that the value of

the EMR system in health care delivery is understood.

Start training sessions with a training of trainers program to enable the development of atraining workforce.

Present the programs clearly and enthusiastically and enable hands-on experience.

Encourage members of the health services to commit to reviewing work practices and

endorse the changes required to implement the EMR system for maximum efficiency gains.

Prepare staff members to participate in defining the new work practices and developing

policies and guidelines to promote user-ownership and increase compliance.

Quality Assurance Group

A quality assurance coordinator and team should be established to ensure that the data collected

and processed are accurate, reliable, and organized in such a way that they are both readily

understood and available when needed by health care providers. To ensure that documentation

meets the required standards, quality assessments must be undertaken beforehand and

continued on an ongoing basis. Poor data quality is a major hindrance to planning and making

decisions and is an important concern for health care institutions and governments, regardless of

how data are recorded and processed.


19/114


More groups may be required. The steering committee, in conjunction with the implementation

coordinator and team, should identify any additional areas needing special attention, including:

Design and development

System testing Pilot testing

Implementation

Monitoring and evaluation

Team leaders are responsible for coordinating the activities of their respective teams with those of

the other project teams. Team leaders report activity and progress to the steering committee who

in turn report to the executive committee.

Figure 1. Sample Structure of an EMR Oversight Team

EMR Executive Committee

Provide high-level oversight and bridge the

project team with government health officials

Steering Committee

Coordinate the planning and

development of the EMR system

National EMR Working Group

Insert function of the national

EMR working group

Information

Security Group

Quality

Assurance Group

Education and

Training Group


20/114


Individual Roles

Individuals will have different roles within the different working groups depending on their position.

Some suggested roles for key members of the working groups are presented in Table 3.

Table 3. Suggested Roles and Responsibilities for Members of the EMR Working Groups

Individual/ Position Suggested Roles and Responsibilities

MOH Representat ive Serves on the national EMR working group

Plans and arranges system-provider visits

Prepares and disseminates requests for proposals

Develops evaluation criteria for selecting provider and system

Chooses provider and system

Provides input on budget and high-level needs

Provides input on desired schedules and standards development, length

of pilot project, etc.Chief of Party or

Designee

Serves on an EMR working group

Provides input on budget and high-level needs

Program Manager Serves on an EMR working group

Provides input on high-level and detailed requirements

Project Manager Serves on an EMR working group

Leads project team

Establishes and manages project plan

Ensures that development or customization of EMR is on time and within

budget

IT Projec t Lead May serve on project team

Provides detailed requirement input

Establishes installation plan (software project plan)

Ensures that development or customization of software meets high-level

and detailed requirements

Ensures that corrections and changes are made

IT Implementer Builds or adapts software to meet requirements

Provides training to customers/users

IT Staff Serve as end users of EMR system

Representatives may serve on project team

May test EMR before release

Attend training in order to use EMR efficiently


21/114


B. Pre-Implementation: Analysis, Requirements/

Specification, Design, and Testing

As has been noted, implementing a national-scale EMR system is a complex undertaking. To

ensure that stakeholder and user needs are addressed, a structured approach that provides aframework within which several critical phases can be completed is needed.

This framework is commonly referred to as a Software Development Life Cycle (SDLC). Adhering

to a formal SDLC is the best approach for creating an EMR system that meets requirements from

the outset and within project budget and schedule. Figure 2 illustrates a typical SDLC.

Critical Phases of an SDLC

Analysis of existing capacity Development of detailed functional and technical requirements

Design of a solution that addresses requirements

Development of the designed solution

Testing

Implementation


22/114


Figure 2: Typical Software Development Life Cycle

The following sections provide more detail on the various stages of implementation, from initial

assessments, to the analysis phase, and to implementation of the system.

Further Reading

A Modified Capability Framework for Improving Software Production Processes in Jamaican

Organisations by Chevers and Duggan

(http://media.shs.net/globalaids/pdf/Article%2015a%20-

%20Chevers_A%20Modified%20Capability%20Framework.pdf)

A Simple and Low-Cost Internet-Based Teleconsultation System that Could Effectively Solve

the Health Care Access Problems in Underserved Areas of Developing Countries by Kuntalp

and Akar. (http://media.shs.net/globalaids/pdf/Article%2015b%20-

%20Kuntalp_Simple%20Low-Cost%20System.pdf)


23/114


3.0 Exist ing Systems Assessm ent

3.1 Inventory of Existing Health Information Systems

Existing medical record system(s) should be reviewed to assess the quality of current records andmedical record services, to identify problems, and to prepare a formal report summarizing results.

The first step in developing an inventory of existing systems is to gather system information from

regions and districts within a country that describes their current technical capacity. This can be

achieved through the distribution of a standardized questionnaire that asks system managers at

medical facilities to document each system used to manage patient data.

Table 4. Suggested Data Points for Assessment Questionnaires

System Overview Type of software (EMR, Data Management)

Whether the system can be easily modified

Whether the system uses free, open source software

Single user, local area network (LAN), and wide area network (WAN) systems

Scope of ClinicalServices

Prevention of mother-to-child transmission (PMTCT)

ART

Tuberculosis (TB)

General clinical care

ART disease management (guidelines, patient advice)

Reporting/OutputCapability

Patient-level reporting

Clinic-level reporting Custom reporting

Exportable data/standard format

Links to external systems

Hardware andSoftwareRequirements

Client computer requirements (e.g., 500 megahertz [MHz] processor or higher,

1 gigabyte [GB] of random access memory [RAM], 1.5 GB of available hard

drive space for software installation)

Server computer requirements (e.g., Pentium III 700 MHz central processing

unit [CPU] or equivalent, 1 GB RAM, network adapter)

Operating system

Database

HR Requirements Country-level development, support, maintenance

Security andQuality Checks

Security level (e.g., minimal or none, password, or multilevel access control)

Data validation level (e.g., minimal or none, some field level, or extensive [rules

based])


24/114


The questionnaire ensures that the same data are collected from each facility in a standard

fashion. Data reported on questionnaires should be stored electronically in a simple database to

facilitate analysis of results and report writing. Data collected will be used to develop an

understanding of current systems, including areas of strong and weak technology capacity,

systems common to multiple facilities, systems unique to an individual facility, and systems that

exchange data. The analysis will help identify potential pilot sites during the later implementation

phase. It might also identify systems that offer the potential to serve as the foundation for a

national-scale patient monitoring system.

Further Reading

The Botswana HIV/AIDS Response Information Management System (BHRIMS) District

Informatics Assessment describes instruments used to assess IT capacity and IT use and a

report on national IT capacity in Botswana. (Section 6, items A-F,http://globalhivevaluation.org/meetings/zambia2007/Bibliography.aspx)

The presentation, Zambia Case Study: SmartCare Implementation, discusses results of an

assessment of health information systems in Zambia.

(http://media.shs.net/globalaids/ppt/DJM%2035127-

01%20Zambia%20Workshop%20Presentation%20Template%20DJM.ppt)

An additional resource that may be useful is the ART Software Inventory which can be found

at the Routine Health Information Network Web site. (http://www.rhinonet.org).

3.2 Determining the Maturity of the Data Management Process

One of the first steps in developing a project strategy is to conduct an initial assessment to

determine the state of readiness to implement an EMR system. Countries should, at a minimum,

do the following:

Take inventory of existing health information systems

Determine the maturity of data management processes

Document data standards

Review the technical competence of staff members expected to use EMR system; this will

provide input into the development of training strategies and the selection of sites to

participate in the EMR system roll out


25/114


Evaluate the strength of the technical infrastructure, its coverage, and so forth

Evaluate facilities within the health enterprise to determine whether they are physically

capable of supporting an EMR system.

Key Questions to Ask When Reviewing Existing Medical Record Systems

Are medical records currently kept on all

patientsinpatients, outpatients, and accident

and emergency (A&E) patients?

What type of medical record is kept?

How is information released for medical or legal

purposes?

Are there problems with duplicate medical

records?

Is the medical record system centralized using a

unit numbering system? Are all admissions,

outpatient notes, and A&E records filed under one

number in a single medical record?

If the patients medical record cannot be

found, and the patient has visited the hospital

previously, do staff members prepare a new

or duplicate medical record? How are patients identified?

Do all persons have a national identificationnumber?

Is this used to uniquely identify the patient? If a national identification number is not issued,

what information is used to identify eachpatient?

How are medical records filed?

Are medical records filed by the medicalrecord/hospital number?

What system of filing is used?

Are medical records well documented?

What is the quality of the medical records? Is allessential information recorded? Are all entriessigned and dated?

Are quality checks performed on current paper-based or electronic records? If so, have anydocumentation problems been identified?

Are medical records returned to the medical

record department upon discharge of the

patient?

If they are returned promptly, have theybeen completed or are they usuallyincomplete and without a dischargesummary?

How do staff members handle incompletemedical records?

Are daily admissions and discharge lists

produced?

Are inpatient morbidity statistics collected and

compiled by medical record staff members?

Are they responsible for the submission ofmonthly returns and the annual report ofhospital activity? What about outpatient

statistics?Are there any problems with the collection of

morbidity statistics and are they completedwithin the anticipated time?

When the medical record has been completed

by the doctor, do medical record staff

members code the main condition using a

classification system such as International

Classification of Diseases (ICD)-10?

Are procedures coded?Are coders trained in coding using ICD-10?Are the codes currently indexed to enable

the retrieval of medical records for research,health statistics, and epidemiologicalstudies?


26/114


3.3 Data Standards

Countries should document any data standards that are employed by medical facilities at national,

regional, and district levels. Data standards are agreed-upon rules that govern the way that

patient information is electronically stored and exchanged. They allow data to be exchanged

among different information systems, and they ensure that the data have consistent meaning from

system to system. In addition to creating consistent ways to classify data (e.g., using ICD-10 for

diagnostic codes and Logical Observation Identifiers Names and Codes [LOINC] for coding lab

results), messaging standards that define consistent ways to send data back and forth between

organizations are also critical. The most widely used messaging standard in public health and

health care is Health Level 7 (HL7).

Some standards will be internationally recognized like HL7 or International Classification of

Diseases (ICD). Others will be developed locally and will be considered a standard at individualfacilities. Understanding what data standards are in use will help create database models for a

national-scale EMR system that leverages existing designs, complies with standards, and

contains the linkages that will allow for the seamless transfer of data between systems at different

levels. This interoperability between health systems will be a key contributing factor to the

success of a national-scale EMR system.

Interoperability requires the creation, acceptance, and

implementation of clinical data standards to ensure that data in

one system are available and meaningful in another system.

Interoperability depends upon two important concepts: syntax

and semantics. Syntax refers to the structure of a

communicationthe equivalent to the rules for spelling and

grammar. Data exchange (or messaging) standards, such as

HL7, are examples. Semantics convey the meaning of the

communicationthe equivalent of a dictionary or thesaurus. Terminologies such as Systematized

Nomenclature of Human and Veterinary Medicine (SNOMED) and LOINC, and document

standards such as HL7 Clinical Document Architecture are examples of semantic standards.

Without semantic interoperability, data can be exchanged but there is no assurance that they can

be used or understood by the receiving system.

Standards have been created by a variety of health care organizations. Typically, the

development of a standard involves technical committees that define methods and groups

Sample InternationallyRecognized Data Standards

ICD-10

LOINC

HL7

ICD


27/114


organized around communities of interest. Setting health standards is typically a voluntary effort

and the success of a standard depends on the developing organizations credibility and ability to

gain acceptance in the industry. The standard is accredited or given a seal of approval by an

external source. Two such accrediting organizations are the American National Standards

Institute and the International Organization for Standardization.2

Further Reading

The presentation, Overview of the Development, Piloting, and Evaluation of a National

Electronic Data System for ART M&E in Malawi, provides an example of how a country has

developed and implemented two different EMR systems against national specifications for

electronic data systems, and has developed national data transfer standards (HL7) to ensure

interoperability of data. As a result, the ART M&E EMR systems can serve as a platform upon

which other electronic medical information systems can be built (e.g., TB, PMTCT).(http://globalhivevaluation.org/meetings/zambia2007/PresentationMaterials.aspx?id=1_1630_

1710)

ART Messaging: Transfer and Report of Patient Health Record Implementation Standard

Document Using HL7/XML Message with HL7 Version 2.5

(http://media.shs.net/globalaids/doc/Article%204b%20-%20Malawi_ART_HL7_v1.3_Doc.doc)

Standardization of Health Information Systems in South AfricaThe Challenge of Local

Sustainability by Jacucci, Shaw and Braa.

(http://media.shs.net/globalaids/pdf/Article%202c%20-

%20Jacucci_Standardization%20of%20HIS%20in%20South%20Africa.pdf

Developing Health Information Systems In Developing CountriesThe Flexible Standards

Strategy by Braa, et al. (http://media.shs.net/globalaids/pdf/Article%2019a%20-

%20Braa_Developing%20HIS%20in%20Developing%20Countries.pdf)

2For more information please see the document in the Annotated Bibliography of EMR Implementation: Clinical Data Standards in

Health Care: Five Case Studies by K. Kim (http://www.globalhivevaluation.org/meetings/zambia2007/Bibliography.aspx).


28/114


3.4 Unique IDs

Countries should document patient identifiers that are

employed at national, regional, district, and facility levels.

One of the major difficulties in creating a comprehensive

longitudinal patient health record (electronic or paper)

system in many countries is that health care information

may be collected at separate locations, different times,

and for different purposes and, as a result, health records usually are fragmented records at

multiple locations. The way to overcome this problem is through the development and use of

unique identifications (UIs). Some countries may have national identification systems in place that

will facilitate the process of assigning UIs. Once a UI system has been put in place, it can be

difficult to connect fragmented health records and prevent the assignment of multiple UIs to one

person. When this occurs, a process of record deduplication and reconciliation must take place to

address the problem.

Further Reading

Presentation, An Overview of Patient Matching

(http://globalhivevaluation.org/meetings/zambia2007/PresentationMaterials.aspx?id=1_1110_

1150)

Presentation, Unique Patient Identifiers


1220)

3.5 Documenting Health Data Policies

Existing policies relating to medical record practice should be reviewed to identify areas which will

require updating to cover EMRs. Questions that should be revisited include those relating to

policies for record retention, for release of information, for patient access to health care

information, and in determining who has the authority to make and enforce policy changes that

were discussed under Policy and Governance (Section 2.0).

Recommendation

Develop a unique patient

identification system that can beapplied at national, regional,district, and facility level.


29/114


4.0 Heal th Management Info rmat ion System (HMIS) User As sessm ent

4.1 Engaging Users

There are several benefits to involving individuals who will be

the ultimate users of a system during the SDLC. Their

understanding of the work that the system is designed to

support is important to the overall design, but it is the less

tangible aspects of their engagement in the process that can

have most value. For example, users involved in the design

and testing phases are more likely to be open to the introduction of a new system to complete

their work. They will develop a sense of ownership in the system and, through use of the system

during testing phases, develop a familiarity with the system before implementation. Some of these

users might even become trainers who can be part of the implementation phase.

4.2 Determining User Needs

The success of a system can depend upon the appropriate level of user involvement during the

various phases of the SDLC. When developing an understanding of a process being automated

and gathering requirements, it is important that systems architects speak to all stakeholders, not

just high-level supervisors. Perhaps the most important stakeholders are the individuals who will

use a system to complete the day-to-day functions of their jobs. These users will be responsible

for using new tools following their implementation. Knowledge of workflow and process during the

initial analysis and requirement specification phases will enable systems architects to design

systems that not only automate the existing workflow, but also introduce efficiencies and provide

benefits such as improved quality of health care delivery and improved quality of patient data by

reducing data errors.

4.3 Follow-Up Assessments of Users

Post implementation, countries can consider implementing processes that gather information on

how a system is being used, its effectiveness, training needs, and potential system

enhancements. For example, a group charged with ongoing assessment of user expectations andexperiences with the EMR system would engage users by soliciting feedback. User feedback

would inform the ongoing development of a national-scale EMR system.

Recommendation

Involve key stakeholdersinclude system users andmanagers in the SoftwareDevelopment Life Cycle (SDLC).


30/114


5.0 Risk As sessm ent/Management Strategy

A risk assessment and risk management plan is necessary to ensure the success of any technical

endeavor. The steering committee should identify a coherent risk profile that takes into account

the following:

Risk Assessment

What could go wrong?

What is the likelihood that it will go wrong?

What are the consequences if it goes wrong?

Risk Management

What can be done and what are the options?

What are the trade-offs for each option in terms of project budget, schedule, and technical

performance?

What are the impacts of current project decisions on future options?3

Project risk assessment is ongoing throughout the life of the EMR system. It is not performed

early on and then forgotten. The ability to anticipate risks and develop alternative scenarios will be

instrumental in ensuring that this project is completed on time, on budget, and exceeds

performance requirements.

3 Haimes, Y. (2004). Risk modeling, assessment, and management. Hoboken, NJ: John Wiley & Sons Inc..


31/114


Further Reading

Software Development Risk: Opportunity, Not Problem, by R. L. Van Scoy

(http://media.shs.net/globalaids/pdf/Article%2016d%20-

%20Van%20Scoy_Software%20Development%20Risk.pdf).

5.1 Safeguards

Safeguards must be in place to ensure against loss, destruction, tampering, and unauthorized use

of electronic records. Some safeguards may include plans for the following:

Data backupas in any computer system, there must be an efficient backup system

available.

Contingencyplans for disaster recovery need to be in place in the case of an electrical

breakdown or other emergency.

Examples of Areas of Risk Within a Project

Failure to understand who the project is for

Failure to identify a champion responsible for sponsoring the project

Failure to appoint a fully qualified and supported project manager

Failure to define the objectives of the project

Failure to secure commitments from people who are needed to assist with the

project

Failure to develop a process that includes contingency plans that can be readjusted

and a process to make changes as needed

Failure to estimate costs accurately

Failure to specify very precisely the end users' requirements

Failure to provide a good working environment for the project

Failure to tie in all the people involved in the project with contracts or documents of

understanding


32/114


Storagedata storage must anticipate changes to storage technology over the anticipated

lifespan of the data system. As HIV therapy is expected to be a life-long activity for infected

patients, stored data (including backups) must be periodically migrated to newer storage

media.

Securityworkstations should be secured and passwords required for all users. Passwords

should be changed regularly to maintain security.

Access controlhealth records should be available when needed for patient care and other

official purposes but not accessible by unauthorized persons.

Confidentialitywithin each country, institutions must develop guidelines to ensure

confidentiality and security of HIV-related information, covering all levels operative within that

countrys or institutions health care system, and the different types of data collected, stored,

and used.

System monitoringprocedures should be in place to monitor the use of the system where

the data are stored in order to detect potential or actual security breaches.

Record keepingall additions, deletions, and modifications to electronically stored data must

be recorded at all times in a separate file or log. Logs generated during this process must be

secured, regularly reviewed, and safely stored.

Countries should develop and maintain an IT security plan for their national-scale EMR system.

The security plan should identify systems, key roles, and controls (management, operational, andtechnical) that have been implemented to ensure a level of security that is commensurate with the

risk and magnitude of the harm that could result from the loss, misuse, disclosure, or modification

of the information gathered and stored in a national-scale EMR system.


33/114


Further Reading

Analyzing the Problem of Unsustainable Health Information Systems in Less-Developed

Economies: Case Studies from Tanzania and Mozambique by Kimaro and Nhampossa.(http://media.shs.net/globalaids/pdf/Article%202g%20-

%20Kimaro_Analyzing%20the%20Problem%20of%20Unsustainable%20HIS.pdf)

Key Factors for Small and Medium Enterprises in Taiwan to Successfully Implement

Information Systems by Wong and Lu.

Interim Guidelines on Protecting the Confidentiality and Security of HIV Information:

Proceedings From a Workshop from UNAIDS.


%20UNAIDS_Security%20and%20Confidentiality%20Guidelines.pdf)

6.0 Infrastruc ture As sessm ent

The required infrastructure components can be determined on the basis of the EMR system being

implemented and the implementation strategy. Some infrastructure components may already be

in place, others may have to be ordered via an internal department or purchased directly from

suppliers. In both cases, there are practical questions that will need to be addressed (i.e., What is

the lead time? When should these be ordered? Have the suppliers, products, and or services

been identified?).

An infrastructure assessment can reveal opportunities to use technology in innovative ways to

resolve problems. For example, in Rwanda the expanding cell phone network allowed the

introduction of data collection and transmission using cell phones.

Technical infrastructure will vary at national, regional, and district levels. An assessment would

entail meeting with technology managers at each level to review operations, procedures, and

documentation. Data can be gathered through the use of questionnaires developed to reflect the

differences among the three levels (national, regional, and district). Data collected at each level

should be analyzed and used to formulate reports. Resulting reports from districts can then be

consolidated at the regional level. Regional reports can be consolidated at the national level to


34/114


provide an overall assessment of a countrys technology capacity to support a national-scale EMR

system.

The infrastructure assessment report should be used to address the following issues regarding

communication, hardware configurations, operating system, and software requirements.

Infrastructure Issues to Assess

Communication What communication systems are currently in place?

How robust are communication links between health clinics within districts,

from a countrys health enterprise to the national level?

Are there technical and or geographic challenges that hinder the timely

exchange of patient and supplies information?

HardwareConfiguration

If hardware is going to be purchased, what hardware configuration should be

purchased? What configuration(s) are required at which phase of

implementation? Are the future implications and requirements beingconsidered?

For existing hardware, are there any configuration changes required? If so,

what are they? Who will make the changes? When are they going be done?

What impact might there be on other systems?

How will hardware and software be designed? Options include the following: Stand-alone systems Local area network (LAN) systems Wide area network (WAN) systems Internet-based systems

Operating

Systems

What operating system(s) are currently in use?

What operating system(s) will the proposed system be able to run? Will servers and desktops run different operating systems?

6.1 Software Requirements

Before a software system is developed or modified, it is important to describe the requirements of

the system to be implemented. It can be helpful to develop a use case that describes the

interactions that the users will have with the software. Be aware that some application software

may use other applications for security facilities, backup facilities, reporting facilities, and so forth.

If this is the case, these should be outlined within the system architecture.

Further Reading

BHRIMS District Informatics Assessment, and the instruments that were used to conduct the

assessment (Section 6 A-E,

http://www.globalhivevaluation.org/meetings/zambia2007/Bibliography.aspx).


35/114


7.0 Conf id ent ial ity and Securi ty

Three interrelated concepts have an impact on the

development and implementation of protections for

sensitive data: privacy, confidentiality, and security. Privacy

is both a legal and an ethical concept. The legal concept

refers to the legal protection that has been afforded to an

individual to control both access to and use of personal

information and provides the overall framework within which

both confidentiality and security are implemented.

Confidentialityrelates to the right of individuals to protection

of their data during storage, transfer, and use, in order to

prevent unauthorized disclosure of that information to third

parties. Security is a collection of technical approaches that

address issues covering physical, electronic, and

procedural aspects of protecting information collected as

part of the scale-up of HIV services.

The public health goal is to safeguard the health of communities through the collection, analysis,

dissemination, and use of health data, which must be carefully balanced with the individuals right

to privacy and confidentiality. Guidelines must allow for consideration of relevant cultural norms

which may influence these policies, while ethical principles should guide decision-makingregarding the appropriate use and dissemination of data. Overall, guiding principles should be

based on human rights principles.

The purpose of defining health information confidentiality and security principles is to ensure that

health data are available and used to serve the improvement of health, as well as the reduction of

harm, for all peoplehealthy and not healthy. Pursuing this goal involves an ongoing process of

refining the balance between the maximization of benefits, which can and should come from the

wisest and fullest use of data, and protection from harm, which can result from either malicious or

inadvertent inappropriate release of individually identifiable data. Appropriate policies, procedures,

and technical methods must be balanced to protect both individual and public rights.

The risk of harm following a breach of confidentiality varies with the national or local context

according to levels of stigma, lack of comprehensive public health safety nets, legal traditions of

respect of privacy, religious perspectives, and other local conditions.

Privacythe legal protectionof an individuals control of

access to and use of personalinformation.

Confidentialitythe ethicalprinciple or legal right that ahealth professional will holdsecret all information relatedto a patient, unless patientgives consent permittingdisclosure.

Securitythe collection oftechnical approaches that

address issues coveringphysical, electronic, andprocedural aspects ofinformation protection.


36/114


Within countries, privacy and confidentiality laws

should be in place (or developed if not already in

place) and relevant parameters of privacy or

confidentiality laws must be reviewed and known

by those involved with data at all administrative

levels.

Countries and organizations at all levels of the

health care system should have a written policy

that defines security procedures concerning the

way data are collected, stored, transferred, and

released. The policies need to be implemented

at all relevant levels, and staff members must

understand the policies and sign an agreement stating that they will implement them as part of

their work. This will also require training new staff members and updating all staff members on the

relevant procedures.

Organizations at all levels of the countrys health care system along with international

organizations must identify a confidentiality and security officer to be ultimately responsible for the

confidentiality and security of HIV information within their respective organization.

Development and review of confidentiality and security laws and procedures should include activeparticipation from relevant stakeholders, including people living with HIV, members of

communities affected by HIV, health care professionals, information technology specialists, and

legal and ethical experts.

Funding organizations should comply with these standards and have an obligation to make

adequate funding available to implement them, sufficient to ensure protection of the data collected

and used. Funding organizations must also require that maintaining these standards is a condition

for funding of any implementing partners or agencies.

Recommendations

Develop written privacy and confidentialitylaws and policy on how data are to becollected, stored, transferred, and

released. Procedures for protecting alltypes of data (paper-based andelectronic) must be explicitly described.

Ensure that all staff members are trainedin all privacy and confidentiality laws andhave signed a contract to abide by theselaws.

Engage relevant stakeholders in thedevelopment of privacy and confidentialitypolicies.


37/114


The greatest threats to electronic information systems are generally not from outside attack, but

rather from issues inherent in the system design and implementation. These threats fall into two

categories: nonavailability of data due to system failure and user errors. The different types of HIV

informationpersonal identified, pseudo-anonymized, anonymized, aggregated, and nonpersonal

datarequire protection. Procedures for protecting each different type of data must be explicitly

described.

A number of organizational procedures need to be followed to ensure safeguards for the

collection, transfer, storage, use, dissemination, and disposal of personal identified data and other

information. Policies and procedures developed must cover both paper-based and electronic

systems.

Further Reading

Presentations: Guidelines on Protecting the Confidentiality and Security of HIV Information:

Proceedings from a Workshop in Geneva, May 2006 and Applied Security and Confidentiality

Elements in the SmartCare EHR,


1000)

Negotiating Multiple Rationalities in the Process of Integrating the Information Systems of

Disease-Specific Health Programmes by Chilundo and Aanestad.

(http://media.shs.net/globalaids/pdf/Article%202l%20-

%20Chilundo_Negotiating%20Multiple%20Rationalities.pdf)

E-health Progresses in Romania by Moisil and Jitaru.

(http://media.shs.net/globalaids/pdf/Article%202f%20-%20Moisil_E-

health%20Progresses%20in%20Romania.pdf)

Standardized Exchange of Medical Data Between a Research Database, an Electronic Patient

Record and an Electronic Health Record Using CDA/SCIPHOX by Gerdsen, et al.


%20Gerdsen_Standardized%20Exchange%20of%20Medical%20Data.pdf)

Interim Guidelines on Protecting the Confidentiality and Security of HIV Information:

Proceedings From a Workshop from UNAIDS.


%20UNAIDS_Security%20and%20Confidentiality%20Guidelines.pdf)


38/114


8.0 Requirements /Use of Data Ass essment

Systems requirements will be gathered through meetings with stakeholders at various levels

throughout the health enterprise. Government ministers will provide an understanding of high-

level goals and objectives. Senior managers will describe their responsibilities and requirements

around throughput and reporting. System users will provide the granular detail that can only be

gained through actual interface between service providers and service recipients/patients.

Information from these various stakeholder groups can be gathered through the use of

questionnaires tailored for each target audience. Questionnaires can be provided before meetings

so that participants can come prepared with the data that are being requested. Requirements can

also be gathered from work manuals, documented standard operating procedures, and by

observing clinicians as they process patient data.

Documented requirements will not only inform system design, but also provide the basis for

detailed testing requirements that clearly define how the system will be tested to ensure that all

functional requirements are met. Testing starts as soon as a requirement is qualified by

determining its specified met criterion. This is an objective measure that must be accomplished

in order to evaluate whether or not a given solution meets the requirement. If a criterion to be met

cannot be adequately specified, then the requirement is ambiguous. If there is no criterion or

benchmark for success, then there is no way of knowing if a solution meets the requirement.

Further Reading

Negotiating Multiple Rationalities in the Process of Integrating the Information Systems of

Disease-Specific Health Programmes by Chilundo and Aanestad

(http://media.shs.net/globalaids/pdf/Article%202l%20-

%20Chilundo_Negotiating%20Multiple%20Rationalities.pdf).

8.1 Reporting on EMR System Implementation

Government ministers, project champions, sponsors, and stakeholders need to be regularlyinformed of progress and outcomes during the implementation. Regular reports ensure that key

individuals are kept abreast of developments as the project moves forward. Each type of system

user will have different reporting requirements. These requirements are typically associated with

an individuals role within the organization. For example, a data analyst will need access to a

different level of report detail than that of a health minister. While a health minister is looking for


39/114


summarized information, the analyst often needs access to granular transactional data. In

determining the enterprise-wide user query and reporting needs, it is important to define the user

communities, what information they need, the level of detail, and how the information should be

presented to them, as well as existing reporting mechanisms that could be leveraged for this

project.

8.1.1 Routine vs. Ad Hoc Reports

Routine reports are those that are produced on a regular frequency (e.g., weekly, monthly, or

quarterly). These types of reports are typically designed and accessed via a system interface that

allows users to create the report by simply selecting it from a menu. More sophisticated systems

may allow filters to be applied that limit the scope of content within a report. Routine reports may

also be automated so that they are generated and distributed on a regular schedule by the system

without the need for a user to initiate the process.

Ad hoc reports are created in response to unexpected calls for information or to answer questions

that cannot be resolved by analyzing routine reports. Ad hoc reports will be created to meet

requests made by data analysts for specific data variables that are not stored together within the

database. This type of report will require that a data query be developed by someone familiar with

the reporting systems database design. This knowledge will be required to understand how data

tables are linked so that information can be drawn from multiple tables within the database.

An ad hoc report may become routine if it is determined that it contains data that are usefulenough to be created on a regular basis.

8.1.2 Reporting Arrangements

Early in the process of EMR system development, a list should be made of what project-specific

reporting arrangements are in place. Identify how regularly reports will be prepared (e.g., weekly,

monthly, quarterly); the level at which reporting will be directed (e.g., health minister, sponsor,

visionary, steering committee); and the form reports will take (at a minimum, reports should detail

successes, challenges, schedule slippage, and budget issues). Identify whether progress in

implementing the EMR system could be captured by existing Government reporting systems or if

a new reporting system needs to interact and exchange information with any external reporting

systems.


40/114


8.2 Other Data Use Requirements

Beyond routine reporting requirements of system users, it will be important to consider other

potential uses of data gathered and stored by the EMR system and build in the mechanisms that

will support those requirements. Researchers and analysts will want to conduct studies to answer

epidemiological questions regarding ART treatments for HIV/AIDS. It may be a requirement to

exchange data with external data systems. When documenting these requirements, it will be

necessary to determine common data variables that allow disparate databases to interact and

identify data standards that are in use.

Further Reading

Improving Imperfect Data From Health Management Information Systems in Africa Using

Space-Time Geostatistics by Gething, et al.

(http://media.shs.net/globalaids/pdf/Article%2021a%20-%20Gething_Improving%20Imperfect%20Data.pdf)

Understanding PACS Development in ContextThe Case of China by Xue and Liang.

(http://media.shs.net/globalaids/pdf/Article%2022a%20-%20Xue%20and%20Liang%20-

%20Understanding%20PACS%20Development%20In%20China.pdf)

9.0 Data Ent ry

Once an EMR system is implemented, existing patient

data from paper-based (or electronic, if they exist)

systems will need to be entered into the new system.

This process is known as backlog data entry. Data entry

will need to be planned and a strategy developed that

ensures that data integrity is maintained within the

receiving EMR system database. An important factor in

entering the data is the question of who will be

responsible for the data entry. Another consideration is

the amount of data that should be transferred from existing paper-based systems. Depending on

volume and quality of the data, a cut-off date may be implemented. For example, should data only

from a certain point in time going forward be entered? This decision may be driven by the medium

within which data are stored. Electronic data may be easier to transfer, while paper-based records

might present difficulties depending on their condition and completeness.

Data Entry Considerations

Are data entry clerks available?

Will staff members at clinics needto enter data in addition to theirregular duties?

Will data entry training beneeded?

How much backlog data entry willbe needed?


41/114


Backlog data entry is discussed further in Section 12.8.

10.0 Design

10.1 Database Design

The key process in this step is to develop logical and physical data models that will support the

functionality detailed in the requirements specification document. Data modeling tools can be

used to develop these models. Database designs should be normalized to at least third normal

form (3NFensures each table contains unique data) to provide for efficient and effective data

storage. Data models should be checked to ensure integrity and consistency and that they adhere

to relational database modeling standards. This type of validation should be applied following

every database change and prior to implementation to ensure that the integrity of database

models has not been compromised by the proposed change4.

When developing a database design, it is important to consider reporting requirements. What

types of data outputs will health

emr implementation plan template

Documents