Understanding the landscape and stakeholders

Each country/region implements various health interventions, and with the current SDG focus on people/beneficiary-centric approach, understanding of the landscape in which 'health-related data will circulate, cleaned or modified, utilized for single (screening/diagnosis/treatment/another service) or diverse reasons(Monitoring/Evaluating/Mentoring/Policy Making/Policy Modification/Public Opinion, etc.'.

Avoiding duplication and errors

Collect and Document Requirements 

System development demands that expectations and product match. It is essential and one of the first steps to understand and note the requirements.

How to Elicit Requirements 

  1. Introductory meeting: One of the most common methods for eliciting requirements is to conduct interviews or seeking concept note mentioning the purpose for which the digital health intervention is being opted for.
  2. Stakeholder Consultation: Taking on board all those (including community representative/patients) and engaging them for providing insight into what system should look like and be utilized for. National and State Program Manager at times misses the integrities of the system and that can backfire at later stage. Collect as much details as possible and foresee the challenges or enablers within the system or support that would be needed from higher level.
  3. Provider Perspective: The level of digital literacy, data entry tools, pros and cons of current system and value addition of digitization should be studied in depth. Who will be affected by the system change and how to gain maximum control over system without compromising the data ailments, quality and security, are essential features.
  4. Few other methods include
    1. Creating user stories (Healthcare worker/Patient/Doctor/Lab or pharmacy personnel/Other department personnel with access to health records)
    2. Scenarios about how the system will be used (Field based/Hospital Based/Other setting)
    3. Possible cases where the system may not work or work with low output (eg. No internet in hilly regions)

Regardless of the method(s) selected, an iterative approach generally works well.  Get input document it and then refine the documentation with more input.  

It is also suggested that potential risk, time required and support needed is noted down for a healthy and realistic planning for a successful outcome.

Resources and Templates 

Functional Specification Template (with examples).docx - This template can be used to document the expected behavior of the system.  It encompasses not only the requirements, but the design of what they system will look like and how it will behave.   

System Requirements Template (with examples)

Gherkin is also a "language" or a formatted process that is being used to define some feature specifications and requirements.  The DHIS2 team is capturing their feature files in GitHub.  Example feature file