| | | | Next Steps from June 7 & 8, 2023 Meeting | | |
|---|
Registration |
|
| PIH Sierra Leone Gap Analysis |
|
|
|
Vitals | Fiona |
These vitals encounters are not included in active visit, if the patient has one (this is probably a bigger question about how visits work in O3, and if need to make any changes to that) | PIH O3 Vitals | | Error rendering macro 'jira' : Unable to locate Jira server for this macro. It may be due to Application Link configuration.
|
|
Programs/Program Enrollment | Fiona | Program Enrollment doesn't currently allow for subprograms, states, or enrolling in a program more than once. | PIH O3 Program Enrollment Summary | Extend the functionality of PE in O3 (states/workflow/outcome etc.) Restrict the programs that are available to enroll in Restrict forms based on the Program a patient is enrolled in PIH requirements on what information is collected at program Enrollment
| Error rendering macro 'jira' : Unable to locate Jira server for this macro. It may be due to Application Link configuration.
https://pihemr.atlassian.net/browse/UHM-7087
|
|
Visit Management | Fiona | Current PIH EMR functionality will close an outpatient visit automatically at the end of the day. How are encounters slotted in to visits? | PIH O3 Visits | | Error rendering macro 'jira' : Unable to locate Jira server for this macro. It may be due to Application Link configuration. Error rendering macro 'jira' : Unable to locate Jira server for this macro. It may be due to Application Link configuration.
|
|
Service Queues/Patient lists | Fiona | Queues: implied order, assign a severity. Sorted in order of how long they are on the queue would be seen first. Queues are intended to be tied to a location and more transitory There isn’t a queue type Could take action from a queue Queues are intended to start a visit (or they need to have an active visit) Patient can be on two queues at once
Patient Lists: Don’t autogenerate, need to add patients to them. Use Cases: 1. Someone would manually create a list (e.g. Grace’s Follow Up list); 2. Automated add someone to a list; 3. System admin creates a list that anyone can use/ (list is a cohort) Someone else can add a patient to your list Discussed List managers at some point, but not currently supported Vision: auto populate patient referred to clinic on to a list, but not currently support Can favorite a list System Admin can configure a list that everyone can add to (e.g. ANC list)
|
| Fix bugs (lists: removing, starring, system lists don’t work; queuing needs more TLC) PIH to define use cases for each of our scenarios for each system for queues/patient lists Need a design for the workflow PIH to add cohort module and queue module for testing
|
|
|
Forms | Dave | https://ampath-forms.vercel.app/docs/quickstart https://ohri-docs.globalhealthapp.net/ | PIH O3 Forms Gap Analysis | Schedule a call with Palladium to discuss use cases (e.g. Antony and Keziah?) Tech analysis of Form Builder Check in with Paul and Ciaran on designs (Extend the UX workflow that includes widgets and forms in the same container) Identify workflows for real-time vs retrospective data entry PIH to identify the forms/data in more detail (types of forms, how often they are repeated, sections etc.) Determine needs for formatting form displays (how closely to match paper)
|
|
|
Workflows |
|
|
| Determine if it make sense to design some sort of "workflow" mechanism for leading a user through multiple components, such as forms, order basket, queue etc Real time vs retro workflows? From a technical perspective, make these all feed into the same encounter Look into Tasks and what Hadijah is working on
|
|
|
Bed Management |
|
|
| |
|
|
Retrospective entry |
| There are not a lot of places where retrospective data entry is allowed in O3. Something going on in the patient chart where it files everything as happing TODAY Design issue with allowing you to choose a visit in the past and add encounters to that previous visit Form schema allows you to put an encounter date Bulk data entry
|
| Fix the Start a visit date to allow for back dating UX/Designs needed for retrospective data entry (Review designs from Paul) Analysis/workflow on back dating visits and entering encounters to be within in that visit and encounters that don't fall in that visit Any new functions need to allow retrospective entry and edit Test all features to determine if retrospective is allowed Fast Data Entry workflow/requirements around selecting visit vs automatically assigning to visiting within that data range Gap analysis/tech analysis and validation of current approach already implemented
|
|
|
User Management (including MFA) | Fiona |
|
| |
|
|
Pharmacy/Dispensing |
|
|
| Analysis of using Order Basket vs Forms Analysis of order from an encounter Analysis on order sets and templates
|
|
|
Triage |
|
|
| Need to gather MCOE triage requirements |
|
|
ED |
|
|
|
|
|
|
Inpatient/Admissions | Dave |
|
|
|
|
|
Labs | Fiona |
| PIH O3 Labs | Implement the designs for ordering Make solution more meta data driven than it is now Gap analysis on the lab results page to display panels vs tests Analysis about workflow and ordering labs/meds in the form Include references ranges (sex and age) for lab results
|
|
|
HIV |
|
|
|
|
|
|
Immunizations |
|
|
| |
|
|
Appointment Scheduling | Dave | Need to know requirements. Questions would be: Are appointments scheduled for a specific time or just a day? Is scheduling done centrally or does each provider schedule their own appointments Do they need the system to manage provider time slots or availability for a clinic/service utility of displaying volume already scheduled missed/check-id/completed? how do they want to use appointments data? display on EMR? Reporting?
|
| Fix bugs in appointments module: You can sign up a patient for an appointment, but patient doesn’t appear on the list
Technical analysis/testing of current module
PIH Requirements gathering on how MCOE (and other sites) want to track appointments
|
|
|
Patient Chart |
| Configurability of patient chart - do we need it by location? (default to the specific location)
Can specify the header label and concepts
Templet widget
Analysis and development of widgets
Analysis on service/program specific charts |
| Analysis for what patient summary and clinical summary is by program and what's by location PIH to scope out development of new widgets based on requirements Analysis to determine if the view default of patient summary - should it be program enrollment, location, etc.? PIH requirements gathering on what should be on the patient summary PIH requirements gathering on what should be on the clinical views (are these by program)
|
|
|
Performance |
| Loading the app for the first time vs daily use
Patient chart can be slow bc it's downloading the data
No UI to tell you about initial loading
Feedback from user: Already logged in and try to go to app in another tab you get a blank screen
Implications of older devices (better on newer device)
Performance degraded over course of day (backend server?) |
| Bench marks for performance/Testing Throttling Ian finishes PR Access to current implementation sites to dig in to reported slowness to understand the issues better - Grace to follow up Any slowness issues not solved by Ian's PR will be addressed in part by fixing the service worker (Or rather fixing the service worker's rogue caching mechanism, which is prone to getting worse the longer the app stays open)
|
|
|
Tablet vs Laptop UX |
| Large desktop, small desktop, tablet: defined for O3 (Documented in the style guide) |
| |
|
|
Localizations |
| This will not be MVP. MCOE will only need English |
| Some code doesn't take in to account localizations (need to find that code) Analysis on what process we want to use (transifex vs something else?) O3 needs to be translatable
|
|
|
Time Zones |
| Need to be in the same time zone
Does the time matter? (need to analyze where it does and doesn't) |
| |
|
|
Privileges |
| same privilege scheme as in O1 |
| |
|
|