/
2016-10-13 Developers Forum

2016-10-13 Developers Forum

Oct 31, 2016

How to Join

By Browser

By telephone

  • US telephone number: +1 201.479.2627

 

Agenda

  • Quickly review previous meeting minutes (5 min)

  • Review next meeting agenda

Minutes

Agenda

  • Review Interesting Features from Distributions

Attendees

  • Jan

  • Darius

  • Bharat

  • Wyclif

  • Ada

  • Rafal

  • Marok

  • Mike

  • Willa

  • Jonathan T

  • Daniel K

  • Pascal

  • Stephen Musoke

  • Carina

  • Valerio

Review last week

We discussed the radiology module.

Still to-do: Bahmni to schedule a time to present its PACS integration on a dev forum, and determine if these efforts can be merged.

Homework for Distributions

1. Share something that make your distribution unique.

2. What are some things in your distribution that should be pulled into the OpenMRS Platform or Reference Application?

3. What are some upcoming plans for your distribution that would be good to coordinate with openers-core and/or other distributions (e.g. features that belong in openmrs-core or a core-supported module)?

OpenMRS Distributions: https://om.rs/distributions

Bahmni

1. We have integrated multiple open-source products, including OpenMRS

2. Features delivered

  • have done a quick implementation of this for a TB project (to divide the record into multiple treatments, e.g. assigning visits to episodes of TB care)

  • "huge rush because of delivery pressure"

  • We welcome contribution to this +/- moving this under the OpenMRS organization in github

  • Data Integrity Module updates

  • existing data integrity module was pretty good, but we needed more ability to write rules in code (e.g. calling the OpenMRS Java API)

  • This has been merged into the OpenMRS data integrity module (as a new major version), but for now there is only a Bahmni UI for this

  • We intend to merge this into openmrs-core for Platform 2.1

  • Domain object for Bacteriology (under the hood saved as Obs, similarly to how the EMR API module handles diagnoses and dispositiosn)

  • This could be integrated into OpenMRS "now" (it is already generic and doesn't depend on Bahmni)

  • It's a BDD test framework on top of webdriver/selenium, but it makes things more readable and reusable

  • Innovation is to have a suite of Gauge tests per implementation (sharing some common templates)

  • Patient Monitoring Tool

  • shows a flowsheet of expected treatment (in this case for a TB research study), and color coding of whether expected milestones are reached or not

  • Currently this code is specific to a TB project (though we're making it a bit more generic)

  • We're not sure how widespread the need is for something like this

  • ssmusoke: if this also showed values across time, it would be very useful

  • bharat: we do have a trends feature

  • jteich: this first version was designed for a specific presence/absence-of-data use case, but the concept lends itself to showing values as well

  • Bahmni Admin app

What should OpenMRS prioritize of this?

  • ssmusoke: the Patient Monitoring Tool

  • mseaton: less about specific UI components, more about common middleware tools:

  • ability to import metadata

  • communication mechanisms via atom feeds (common event mechanism)

  • pascal: data integrity module is something we'll take a look at

  • jan: episodes of care (and care plans)

3.Features planned in roadmap

  • Flowsheet

  • UI Re-architecture

  • Exposing APIs which can allow people to write/integrate their own apps to Bahmni / OpenMRS. 

  • OCL / Terminology Repository / Form Repository / Starter Kits

  • Patient de-duplication (or detecting possible duplicates during registration)

  • Improving the Ability of Users to manage their own credentials.

  • FHIR / HL-7 Integration for Satellite Bahmni (which can also act as integration to other "Master" systems)

  • Patient Data Anonymisation for sharing in research or with external health care providers for consultation

  • Supporting Mixed Results for Microbiology/Histopathology kind of usecases (may/may not be OpenMRS related.. but calling it out)

eSaude

  • Planning to roll out and upgrade as a set of docker containers

  • predates support for this in SDK

  • not in production yet, but should get there soon

  • repos:

  • !!! We are currently rate limited by Bintray so the following three bullet points will not work !!!

  • Some kind of pharmacy tool (both dispensing and stock management)

  • have taken a look at the pharmacy stuff in Bahmni; looks cool; is there an API back-end for this

  • planning to build a pharmacy API module (kind of like the EMR API module) that can be used by more implementations to do specific pharmacy applications

  • Suggest looking at OpenHMIS

  • Making sure some OpenMRS modules are accessible via REST Web Services, so they can be used in a point-of-care angular app

  • example: Patient Flags module

  • Form autogeneration component

  • existing forms (from a preexisting national retrospective entry system) are HTML Form Entry backed with an OpenMRS form schema

  • ensure that retrospective data entry and point of care can work in parallel

  • It would be nice to have a shared way of defining forms, e.g. via JSON. (There were conversations between AMPATH, eSaude, and Bahmni; where did these go?)

  • Planning to work on Episodes of Care and Care Plan

What should OpenMRS prioritize?

  • Darius: Episodes of Care and Care Plan, and getting these into the core platform

  • Bharat: interested in patient flags, is there a (shareable) UI for this?

  • Link to code: (tbd)

  • Share a screenshot please to show the workflow! Interesting to share the visual design

  • Bharat: can you share how you've done the docker containers?

KenyaEMR

UgandaEMR

  • Basically providing data entry (mostly retrospective) and reporting, for HIV care.

  • Initial phase is to replicate paper forms, and pull them out into standard reports/exports

  • Have ~ 400 installations now, then another 1000 per year

  • Building on top of the Reference Application, so there is no custom code per se

  • Own forms, own configurations

  • Looking to share patient records between facilities (e.g. as patients move or are referred) *even if it happens retrospectively*

  • Focus areas to work with OpenMRS

  • Metadata-based deployments

  • Improvements to HTML Forms

  • Export and Import data

  • Sharing data between installations and systems via sneakernet

  • Integrating with other systems (specifically a lab system, and a dispensing system; maybe an inpatient system; and more and more)

  • Should think about an "offline mode" for everything (a lot of installations have no internet *at all*)

What should OpenMRS prioritize?

  • Darius: possible collaboration around a dispensing API with eSaude

  • Darius: metadata-based deployment is something that Mike called out earlier, and Stephen mentioned here

  • Stephen: we have 6-7 different hacks to deploy different pieces of metadata via code; want a unified path for packaging content and delivering it to implementations so low-tech users can easily import it.

  • Bahmni will focus on using OCL as a terminology registry; maybe some overlap here

--- Call officially over, but people didn't hang up, so...

Stephen: often I see something in Bahmni that is exactly what I want, but I have no way to use those widgets. :-(

Darius:

  • in the long run, Bahmni will do a UI Rearchitecture to be more based on reusable components; OpenMRS RefApp wants to do the same thing; if we can coordinate, it would be great

Stephen: what about Bahmni imports

Bharat: we have a lot of CSV import scripts



 

TODOs

Transcripts

  • Audio recording of the call: Listen online or download (available after the meeting)