1 of 24

OpenMRS Academy

LEVEL 1: OpenMRS Fundamentals

Module 2: Best practices for developing and implementing EMRs such as OpenMRS with Ministries of Health in low resource settings

2 of 24

Describe the process of developing and implementing an EMR, specifically looking at the country specifications;
Explain how to better collect and document basic functional requirements for an EMR;
Explain the importance of engaging the Ministry of Health in EMR implementation and other relevant national stakeholders
Discuss the roles and responsibilities of different stakeholders in EMR implementation

Learning Objectives

3 of 24

What are the necessary steps for the development of an electronic health system?

4 of 24

Jembi SDLC - software delivery lifecycle

5 of 24

The complete development process of an EMR system includes

Planning
Design
Development
Implementation
Maintenance

There are common requirements that shall be considered and clearly discussed with the MoH, specially in countries such as Mozambique, that still faces major challenges in M&E and reporting field.
All phases must be carried out hand in hand with the MoH in a fully participatory manner as they are the beneficiaries of the system and ultimately the end user.
The deliverables produced throughout the project require approval from the donor and the MOH.

Introduction

6 of 24

The development and implementation of any type of system with the NHS must be preceded by formal agreements between all the relevant entities such as donor, government and the implementing partner.
MoUs, Project Charter or any other legal instrument must be signed by all stakeholders at the highest level.

Agreements with the MoH and other involved parties

7 of 24

Why is it so important to formalize the EMR project between all stakeholders?

Establish the roles and responsibilities of the entities involved in the project;
Define the objectives, needs, scope, target group, justification and resource commitment for the project;
Clearly delineate the expected results, deliverables, timeline and key milestones for the project;
Demonstrate assumptions, constraints, risks and change management needs;
Correct Budget estimation for the project.

Agreements with the MoH and other involved parties

8 of 24

Given that there are many people involved on the project development process with different skills it is important to split and create working groups and teams, commonly there are three types of working groups, such as:

The steering committee;
Project management and technical working group and
Technical teams.

Creation of working Groups and Teams

9 of 24

The Steering committee consists of high level staff such as program directors, donors and high level MOH officials who:

Make the project strategic decisions;
Approve work plans, strategies, deliverables and budgets;
Formalize the partnership between the different stakeholders of the project;
Provide high level oversight of the project;
Convene periodically to monitor the status of the work plan and redefine the direction of plan if required.

Creation of working Groups and Teams – Steering committee

10 of 24

Project management and TWG consists of project managers, product owners, Business visionaries an business analysts and technical coordinators who:

Design the high level and detailed work plans;
Create the requirements list/documents and user stories
Create the technical teams and assign roles and responsibilities;
Provide advisory support and recommendations to the steering committee members for decision making;
Convene to monitor and review the work plans on a weekly basis;
Discuss all technical matters related to the project and do estimations;
Provide oversight of all technical activities of the project;
Make time estimations for the achievement of project deliverables;
Manage expectations between technical teams and the steering committee;
Report progress of the project to all stakeholders.

Creation of working Groups and Teams – Project Management and Technical Working Group

Business Visionary providing high-level direction and a view of the future.
Management interests, roles representing the management/leadership view
Facilitating the management/leadership aspects of the project, e.g. Project Manager and Team Leader using Agile leadership competencies.
Business Sponsor, Business Visionary, Technical Coordinator, Project Manager and Business Analyst) are the directors, managers and coordinators of the work for the project, where necessary. They may be part of a project board or steering committee for the project and, collectively, have authority to direct the project.
They are responsible for the governance of the project, liaising with governance authorities outside of the project. The Business Visionary and the Technical Coordinator hold the business and technical visions, respectively, for the project.
The Project Manager ensures that project funds are used effectively to create the envisaged solution within the agreed timescale.
The Business Analyst is intentionally positioned as part of the project level as well as part of the Solution Development Team. This allows the Business Analyst to, for example, help the business to formulate the Business Case, and also to be involved in assisting the business in defining their requirements during the project different phases. The role then continues in supporting the Solution Development Team alongside the project-level roles, as the more detailed requirements emerge.
All roles at the project level need to adopt the facilitative, empowering leadership style which allows Agile teams to learn as they go and reflect, adapt and enhance process.

11 of 24

Technical teams or Solution Development Team consist of the technical experts such as BAs, developers, implementers, solutions architects, quality assurance technicians, UI/UX designers who are responsible for the execution of all technical tasks, such as:

Translate requirements and client needs into user stories;
Documenting the hardware specifications;
Defining workflows;
Designing the architecture;
Developing the system;
Designing the user interface;
Testing the system;
Installing the system;
Training system users and administrators;
Providing maintenance and support of the hardware and software;

Creation of working Groups and Teams – Technical Team

12 of 24

Program Director: Responsible for high level oversight and decision making.
Project manager: Lead and manage the project and the accomplishment of the activities within the defined time frame. The project manager also is responsible for the communication with the MOH.
Business Analyst: Responsible for gathering and documenting the requirements for the development of the app.
Developer: Responsible for the development of the solution.
QA technician: Responsible for testing the solution.
UI/UX designer: Responsible for designing and implementing a user-friendly interface that meets the needs of the Ministry of Health.
Solutions Architect: Design the architecture of the system and produce the proof of concept.
Implementer: Responsible for installing the hardware and software, training users to manage the software and hardware and providing maintenance and support.

Job Description

While putting a tema togheter it is importante to keep in mine what type of profiles is needed to complemente the team, the above job descriptions are the most common needs of a developement team but not limited to. For instances, depending on the project we might need to have or not diferente levels of developers with differnt skills, team leads to manage the solution developement team, a technical writter to translate the needs of the clientes on to requirements documentation, user stories and all project documentations, workshop and training facilitators who develop the ToR of the workshops to collect requirements, and all training materials,

The supporting roles (Business Advisors, Technical Advisors, Workshop Facilitator) provide assistance and guidance to the project on an ad hoc basis throughout the lifecycle of the project. The Advisor roles may be filled by one or more subject matter experts, as necessary. The Advisor roles are not the empowered decision-makers – that is the responsibility of the roles within the Solution Development Team – but they advise the Solution Development Team in areas where specialist expertise is needed (this might be also someone from the donor side, who needs to make sure every dollar is been well spent, technical knowledge, business-specific rules and regulations).

13 of 24

Example of a project team

*Based on the DSDM Model

Project Director

INFRAESTRUCTURE

14 of 24

The next step is to define specific work plans and obtain approval at the top management level of the project.

The high level work plan is agreed upon by the steering committee

Contains the main activities and deliverables of the project, expected results, the stakeholders responsible for the activities and the timeframe for their completion.
Monitored on a monthly or quarterly basis by the steering committee with support from project managers.

The detailed work plan - defined and monitored by technical project managers on a weekly basis.

Contains high level activities and more specific sub activities allocated to the different technical teams.
Contains activities, sub-activities, expected results, deliverables, means of verification, roles and responsibilities of each members.
Each sector extract the activities and sub activities from this work plan and design specific plans and schedules with tasks allocated to each team member. �

Planning

15 of 24

�

Example of work plans

16 of 24

Essential element:

Communication

Requirements gathering, documentation and validations.

17 of 24

The first stage of system development is requirements gathering.
BA´s generate a list of functional, non-functional, system and technical requirements.

This can be gathered form workshops and meetings with MOH at all levels (end-users, clinicians, receptionists, pharmacists, lab technicians, etc.).

The requirements allow system developers to understand:

what problems the client is trying to solve,
what is needed by the client, what to develop and how to test it.
There are mainly two types of requirements:

Functional and non functional requirements, �

Requirements gathering, documenting and validations.

In this particular case, it would be the MOH at all levels (program managers, heads of department, M&E officers, end-users such as clinicians, receptionists, pharmacists, lab technicians, etc.).
The requirements gathering process allows all involved stakeholders to define the scope, manage expectations, focus on what to develop, test effectively, drive user acceptance and handover, and manage expectations. There are mainly two types of requirements that go hand in hand when developing and implementing an EMR. These are functional and non functional requirements, which will ultimately be translated into user stories/product backlog in technical task management tools for the technical teams to design and develop the system taking into account all the requirements expressed and approved by the client and system end-users. The section describes the types of requirements, processes and techniques for requirements gathering and documenting.

18 of 24

Functional requirements - seeks to define the primary objectives of the system and the main drivers for the development of the system.

Data entry, point of care use, patient care outcomes.
Aims to establish the functions of the system; the forms and reports; the types of users and workload details and data migration requirements.

Non functional requirements - defines all the required elements for the system to be able to function appropriately, such as :

Infrastructure requirements

Power, Connectivity, Security

Hardware and system requirements

Server, Workstation, Consumables, Procurement processes

Organizational requirements

Types of Requirements

19 of 24

Requirements gathering process

Determine what information is needed;
Identify sources of information;
Plan approach and appropriate techniques;
Collect information;
Organize and collect information;
Review and validate with project owners.

�Information gathering and validation techniques

Document review;
Interviews;
Meetings and workshops to discuss and validate requirements with the client;

How to gather and Validate Requirements

20 of 24

One of the most important things is to clearly document the requirements.
This must be easy to understand for both normal users and for developers to bring the system to life.
A good requirement to be more effective needs to be:

Atomic
Complete
Consistent
Concise
Feasible
Unambiguous
Testable
Prioritized
Understandable�

Documenting Requirements Accurately

21 of 24

Documenting requirements starts from an iterative process and definition of high level requirements that are broken down to more detailed requirements as more information is gathered and validated.
Requirements documents may evolve with time prior to implementation or in a post implementation phase as the client requests changes in the system to better respond to their needs.
All requirements must be validated and approved by the client.

�

Documenting Requirements Accurately

22 of 24

Example of Requirement Template

23 of 24

Once requirements are clearly defined, they are translated into user stories/ product backlog through technical development management tools such as TRELLO or JIRA, for a team of system development technicians to bring the system to life for testing, piloting and implementation. �

Development of the solution

24 of 24

Introduction of sprints lasting 15 days (recommended)
Prioritize sprint activities
Regular and quick meetings of the development team (stand-ups, 2 minutes per technician, no more than 15 min per day)
At the end of each sprint an assessment and planning of the next
At the end of each sprint create an integral prototype, and present it to the customer
Conducting UAT

Stages of Development

The first stage of development is the transformation of system requirements into user stories/product backlog for the technical development team to be able to develop the functionalities and all other specificities of the system. Subsequently the system development manager and/or product owners allocate specific tasks to the development team based on their areas of specialization. At this stage, time estimations and functioning of the development team are defined.
�The software solutions and code architecture of software components are designed by solutions architects who also provide input into team adherence and to best practices with regards to development, testing and operations.
�The software is developed with all requested functionalities by the team of developers, which is several areas of expertise, including but not limited to: backend, frontend, web and mobile.
�The design team creates a friendly user experience and user interface in order to improve user behavior through usability, usefulness, and desirability provided in the interaction with a product.
�The quality of the system developed is assessed through manual and automated testing by quality assurance technicians.
�The system is taken for user acceptance testing with the end-user who uses the system assisted by some of the members of the development and requirements team to get feedback on possible change requests and bugs found in the system. Subsequently, changes are made and bugs solved accordingly. Finally, there must be a formal approval of the system by the MOH for implementation.