/
Checklists for requirements/testing

Checklists for requirements/testing

Data Collection forms

  • Who should see the form? (roles/privileges? locations?)

  • What questions/answers should be on the form?

  • Order/grouping of questions?

  • display of historical data

  • After submission actions (e.g. program enrollment)

  • Field validations

  • Required fields

  • Precise labels for questions/answers/headings

  • Translations for labels

Lists/Tables in the EMR

  • Structure of the list (row-per-patient, per-order, per-referral etc…)

  • Criteria for inclusion on the list

  • Columns of the table

  • Filters

  • Sorting

  • Page defaults (sorting, filtering)

  • Pagination

  • actions from any rows (delete, cancel etc…)

  • Precise labels for all columns, buttons etc…

  • Any translations for labels, text etc…

  • Navigation to the page (how do users get to the page?)

  • Navigation from the page (should there be any links that navigate to other pages? patients? encounters? etc…)

Patient Program

  • Patient Workflows?

  • States within those workflows?

  • Patient outcomes?

  • labels/names for those

  • translations

  • Any automated enrollment?

  • Program-specific dashboard needed?

Data Warehouse “domain”

(considerations when designing new tables for a set of EMR data ) 

  • What is the nature of the data that needs to be reported?  (E.g. NCD Data, Patient demographics etc...) 

  • What tables/data structures would make it easy to report on this data?  

    • Patient-level tables (row-per-patient)

    • Encounter-level tables (row-per-form/encounter) 

    • Program-state-level tables (row-per-patient state change) 

    • Order-level tables (row-per-order tables) 

    • Combination of above 

  • Does this data exist already in the database? (e.g patient demographic data may already exist)  Would it be easier to duplicate this data in these new structures?  Is this logical? 

  • What data is better to be derived in the ETL and represented in the data vs derived in the downstream report?

    • How often is this derived data needed in reports?

    • Does this data always need to be derived in the same way or does the data vary? 

Data Warehouse Table

  • What do the rows represent?  (e.g. row-per-patient? row-per-encounter?  row-per-patient-state?  row-per-order etc...) 

  • What are the criteria for the rows?  (e.g. every patient enrolled in a certain program?  every encounter of a certain type? etc...) 

  • What are the columns? 

  • What are the columns named?  The name should be meaningful and also consistent with other tables in the database (e.g. there shouldn’t be both columns called “patient_birth_date” and “date_of_birth”) 

  • What are the allowable values for these columns?  Again, make sure they are consistent with other same-named columns.  (e.g. is_LTFU shouldn’t be yes/no on one table 1/0 on another and 1/null on a third...) 

  • What is the data definition of the columns? 

  • For columns with a direct source in the EMR, what is the precise source? 

    • From a certain form, set of forms, program attribute etc..? 

    • Is it from the latest version of the form?  The last time this question was answered?  On a specific form, set of forms or on any form?  

  • For derived columns what is the formula? 



Related content

Project Workflow
Project Workflow
Read with this
Usability Study Tools
Usability Study Tools
More like this
User Stories and Use Cases
User Stories and Use Cases
Read with this
Technical Workshop 11 15-16 2006 Agenda
Technical Workshop 11 15-16 2006 Agenda
More like this
User Interviews
User Interviews
Read with this
OpenMRS from Scratch
OpenMRS from Scratch
More like this