Open

Business Process Modelling

For each main business process it is useful to document the process using a standard business process modelling technique. This can assist with identifying issues and gaps in the current process to assess where a digitised solution can add the most value.

• Use a business process modelling tool and the Business Process Modelling Guide to develop a visual model of your processes flow

• (free business process modelling tools are available to download e.g. Bizagi https://www.bizagi.com/).

• For each of the business processes modelled, document additional information for each step as shown in the Business Process Modelling Guide.

Requirements Gathering Guidelines & Templates

There are a number of tools and techniques that can be used to gather and document this information. Remember that these artifacts are a means of communicating to different stakeholders i.e. end users, project sponsors, system architects, developers, testers, monitoring and evaluation experts, etc.

• Keep them simple

• Keep them consistent

• Make sure terminology is defined, simple and consistently used throughout; for example: Provider, Practitioner, HCW, Clinician may all refer to the same type of user - choose one and stick to it

Correct notation, such as Business Process Modelling Notation (BPMN) is important if you are communicating with peers who already understand it but for general audiences the aim is a clear and unambiguous shared understanding of what you are trying to build, and the format is less important.

Gathering Requirements

The most important factor is to have access to the right people. Be sure to include the people who will be working with the system on a day to day basis, not just the senior management team or decision-makers. They should include data capturers, claims processing clerks, system administrators, etc.

There are various ways to elicit and define the requirements, including:

• Brainstorming

• JAD (Joint Application Design) workshops

• Small focus groups

• One on one interviews

• Questionnaires

• Observations

• Document analysis

Be aware of the power dynamics in the room during large group discussions. Ideally you need to be able to speak to the actual end users of the proposed solution, preferably one on one or in small groups without supervisors/manager present.

Don’t over-promise : make it clear you are there to understand what is needed and that many other factors influence the final scope

Ensure you have participants’ consent to record sessions or to take photographs

Try to have one or more scribes to assist with taking notes

The Requirements Template can be used as a simple tool to define high-level functional requirements and non-functional requirements.

User Personas

A user persona is a representative for each type of user that may interact with the system, such as a beneficiary, a claims processor or a manager.

The User Personas Template­ can be used to identify key characteristics of the user and describing them in such a way allows a better understanding of their wants, needs and common frustrations so that these can be addressed effectively. Using input from user research at the focal point of design decisions ensures that the system works in such a way that fulfils user needs.

Open

Template link: https://docs.google.com/document/d/1QDmdUpl1-WmBLxuuphXI7y8hz1-GDFB2SkVFuAqxvZw/edit

Types of Requirements

Functional i.e. what must the system do

Example of a HIGH-LEVEL functional requirement:

A good practice would be to document the functional requirements in a user story.

User Stories

For User Stories, it is useful to follow a Behaviour Driven Design approach eg:

AS A <specific user/persona/role>

I WANT <desired feature/issue that needs to be solved>

SO THAT <benefit from implementing feature>

The story should include, where appropriate:

AS AN Enrolment Officer

I WANT to be able to create a family/group for a patient/member

SO THAT All relevant information pertaining to the family can be captured, such as;

• Region

• District

• Municipality

• Village

• Poverty Status

• Confirmation Type

• Family/Group Type

• Permanent Address Type

• Insurance Number

• Other Names

• Last Name

• Birth Date

• Gender etc…

Define the Information Requirements

Before being able to define what digital systems are required to support the health insurance business need, it is necessary to understand what information requirements exist i.e. what data is collected, stored and put to use within the existing system.

The type of questions to consider are:

• What type of information is required, at the operational , management and reporting levels?

• Who owns the data?

• Where will master data be stored?

• How and where will each type of data be created, stored, transported and reported?

• What data transformation is required to support the information exchange between solution components?

Informational requirements refers to reports, data visualisation, dashboards. These requirements are often gathered from stakeholders rather than users. It is also more demanding and difficult for the analyst to obtain these requirements accurately, because it invariably requires much more in depth business knowledge. Reports may include, but not limited to:

1. Operational reports e.g. Primary Operational Indicators-claims

2. Management reports or dashboards e.g. Product Sales

3. Exception reports e.g. Rejected Photos

4. Control reports e.g. Matching Funds

5. System Monitoring e.g. User activity Reports, Status of Registers

Define the Non-Functional Requirements

Define the full list of non-functional requirements considering required operational standards and non-functional standards provided below. Defining a comprehensive list of non-functional requirements mitigates the risk of the system not performing as expected, allowing you to define performance standards.These may include:-

• Reliability

• Availability

• Usability

• Security

• Scalability

• Adaptability

• Maintainability

• Extensibility

Define data migration requirements

What data will need to be migrated to the new system?

What level of data cleaning and transformation is required to ensure that the data meets the requirements and constraints of the new system?

Example of Transitional Requirements for Data Migration:

Define Integration and Interoperability requirements

• What existing systems does the new system need to integrate with?

• What data needs to be exchanged?

Example Integration / Interoperability requirements:

Develop a Data Dictionary

The Data Dictionary is a centralised repository of information about data such as meaning, relationships to other data, origin, usage, and format. A Data Dictionary is a set of information describing the contents, format and structure of a database and the relationship between its elements used to control access to and manipulation of the database.

Example of a data dictionary using the template

Finding the right system for you

Evaluating potential solutions

1. First decide what type of criteria you are going to use to evaluate possible solutions. For example, some common criteria are:

   1. Financial sustainability - consider both initial and long-term costs

   2. Ease of implementation

   3. Ease of maintenance and support

   4. Accuracy of data

   5. Timeliness and relevance of data

   6. System reliability

   7. System performance

   8. System security

   9. System recoverability

1. Prioritise or weight these criteria as it is very unlikely that any solution will meet all criteria fully and choices will need to be made according to which are more important.

2. Investigate the possible solutions and rate them according to how well they meet your criteria

3. Consider whether you want to develop and maintain the system internally or whether you should procure the system from an external vendor. These are the type of options you could consider: