4 Must-Do’s

1. Problem Description: Have you clearly defined the user problem(s) you intend to solve, and what value this creates? Write down a story, user insight, or quote about this problem (this is important because (1) this will motivate your team, and (2) without this your problem might not actually be a big problem for the users themselves).

2. User Stories: Have you clearly written at least 3 user stories and use cases?

3. Market Analysis: Have you surveyed what the market is doing here (e.g. comparison to other EMRs, or paper approaches; and don’t forget about learning from historic/existing OMRS instances)? Have you written down any possible gaps in your understanding of your users or their workflows? Have you reviewed the topic in FHIR to see what requirements or fields the global community references? (Eg if working on insurance, should look here)

4. Technical Considerations & Dependencies: Have you outlined what you need from cross-functional areas for success of the feature? E.g. do you need the platform to support a new API call? Have you explained how you’ve addressed dev concerns, such as designs that may not be feasible, or will be extra time-intensive to implement?

Optional/Encouraged

Sketches: Have you added a drawing or description of how the feature could work to solve the problem at hand? (Pictures of sketches are ok!)

Project Management: Have you created the Epic and JIRA tasks so you can share work clearly? Roll-out plan: Do you have an idea whether this will be an experiment, gradual roll out, and when? Have you added this to the timeline view? Have you planned how you will promote and/or work with communications folks in order to help this feature reach the widest audience and have the biggest impact it can?

Later but should do

QA Plan: Have you mentioned the plan for QA, such as how you will discover and address edge cases? Does your team/squad have a plan for automated tests to be added to new components (unit tests) or workflows (e2e tests)?

Safety & Tech Risks: Is there any reason you could regret rolling out this feature? (e.g. possible patient harm, heavy tech debt like introducing an unsupported library) Have you thought through the risks for this particular solution? And, how to reduce/address those?

This checklist was inspired by this article. Additional Business Analyst Resources here.

Project Status

Orgs Interested / Working on This: Madiro and ICRC
Timeline: Q4 2025
Status: Active In Progress
Complexity: Hard

Summary:

When migrating data from an old system, or when a system goes down, or when mass-casualty events happen, many staff use spreadsheets to record basic patient information.
Enabling both a UI and Flow for simple patient data to be imported from a spreadsheet helps in all these use cases.

Picture showing what this project is about (e.g. a key mockup, drawing; anything visual)

1. Problem

Support Offline data collection in Excel/Spreadsheets (where users demand to use Excel instead of Android application) (Priority for ICRC - ICRC’s MHPSS (mental health) program)
System goes down for 1-2 days: Due to internet or power or destruction. E.g. Large ICRC site: has internet 80% of time; admitting pts; work is going on. They may know several days ahead of time “we will not have internet due to scheduled blackouts on Mon/Tues”. While connected can do their work; when down, they need to be able to enter data somewhere. So trying to have simplified version; put that somewhere in a file, then import that. Settings that have a LAN/server box sometimes see that box get destroyed (e.g. war, floods). Not easy to replace because for many NGOs or disaster situations, cannot simply send a new server because can’t get to the site. So someone with data could upload the spreadsheet to the unaffected central server. (ICRC’s PRC (physical rehab centre) program)
Mass-casualty events happen: e.g. 100 ppl driven to hospital - don’t have time to type in q. Pt’s name; faster to type in excel and register pts from a file. (e.g. ICRC’s hospitals)
Possibly: Migrating data from an old system (if that old system supports exporting to spreadsheets)

2. User Stories

3. Market Analysis

4. Technical Considerations & Dependencies

5. Sketches

Draft

Main Objectives

As a OpenMRS User, I should be able to create / update Patients by importing an Excel File
As a OpenMRS User, I should be able to create encounters by importing an Excel File

Not possible to modify encounters as maybe too complex for now

ICRC Specific concerns

A patient/encounter must be linked to a location because as soon as we create a patient they must be assigned to a location so that only users with access to that location can see them. Don’t want a situation where anyone at any location can see the new patient(s) data.

Global process

Spreadsheet Template Generation
1. Context: For downtime and mass casualty, handy to have this template on-hand; ready for backup activities.
2. the OpenMRS User create an "Import Actions" ( new OpenMRS Page)
3. This action will generate a template excel file containing all informations needed for the editing and for the import.
4. The "Template Excel file" will contain required information for the import (location, maybe we need import type (e.g. create vs edit patients? For editing or duplicate creation, would we need to handle merging; or would we require patient UID?))
5. Translation: Template would ideally have list in their language
OpenMRS users fill the Excel File
Template Import
1. For the import ( new OpenMRS page), the process will check:
  1. the hidden info the excel file to process the file (what does this mean? like code behind name of a lcoation?)
  2. check for duplication of patients/info (avoid several updated of the same data).
Logging: A complete log of the import should be created ( and cleaned after xx days)

Tells you “success”; tell you “this particular code caused an error”; or “warning: you’re trying to import a data element that doesn’t exist”

Type of "Import Actions"

Create patient

The user choose the location ( only ICRC ?) and the language ( for column names, drop down list) (eg at ICRC: English, French, Spanish)
The excel file will contain required columns ( First, last, birthdate or approx age,...) and hidden data for dropdown list. The dropdown list will be populated by hidden cells/tabs ( mapping between uuid and name)

Another approach: the user select multiples locations and a new dropdown is proposed for each patient

Why selecting a location at "Import Action" creation:

For ICRC we can have a big list of location ( 10k) and can't be manageable in the excel file. With this approach the location will be chosen on "Import Action" task. (But if you’re a mental health person, you’re only covering like 10 locations, and on user perspective, good to have list of locations that you’re covering - so depends on use case.)

Modify patient

(Ljubo’s note: More of a need to create than edit; though in offline (mental health) follow up, you know most people because you have appointments planned.)

The user choose a patient list and the language
The excel file will contain the patients of this list with an hidden column for the paitent uuid to modify
Should have more details than just patient name so can differentiate patients with the same name
Should be able to “find” patients easily somehow

Create forms

The user choose a patient list, the language and forms (language should be defaulted to whatever locale you’re currently using)
1. Would forms be pared down?
2. Need way to handle multiple forms being added in template, without having HUGE horizontal scroll - vertical questions, where new tab per patient? Columns are patients?
3. How to handle child questions
The excel file will contain the patients of this list, a tab per forms

Create patient and a form ( several possible ?)

The user choose a the language and a form

Opened Questions

what about custom patient attributes

Patient Data Import with Spreadsheets