Info | ||
---|---|---|
| ||
For more information about the meeting, see the main page. |
About this page
Please use this page to list out ideas and proposals for potential unconference sessions during the 2011 Implementers Meeting. If you want to lead the session, or want to suggest someone, feel free to add their name to the "leader" column. If you have no idea who could lead the session, that's OK too! Just leave it blank.
...
Session Idea Title | Description | Proposed Session Leader(s) | |
---|---|---|---|
Collaboration Tools and Tricks | Let's share some ideas about how we can better collaborate with our friends in the OpenMRS community around the globe. Are there good tools or technology that can help us? More "low tech" solutions? Bring your ideas and experiences to share! (Suggested by ~michael Michael Downey) ~michael | ||
Household Module | How can we store household-level data within OpenMRS? What can be done today, what is needed next, and what's the long-term vision? | ||
Medicine for Programmers: Ideas and Concepts | Let's step away from the keyboard. As a programmer and a patient, I know a little bit about things like Drugs, Regimens, and Orders. I'd like to hear more about the domain behind the data models. Examples: What's a drug formulation? Why is that important when you design the Drug class? When you look at a patient record, where does this appear? When a patient is taking a drug, what do you need to know? (Dosage, frequency, ..., ..... ) ? What's a regimen, and how is that different from an order? (Suggested by Janet Riley) |
| |
Medicine for Programmers: Roles and Goals | There are many different roles in health care: field worker, registration clerk, clinician, hospital administrator, public health official, researcher. What's a typical day for them? What do they need to get done? What information do they need to do their job? (Suggested by Janet Riley) |
| |
Use of OpenMRS in hospital settings | Who's done what, What additional features are needed (Suggested by Roger Friedman) |
| |
PACS systems used in OpenMRS | AMPATH uses a custom one, Radiology Module, PACS+DICOM. (Suggested by James Arbaugh) |
| |
Use of OpenMRS with indicator systems | Extraction of indicators, Communication of indicators. (Suggested by Roger Friedman) |
| |
Task/calendar/scheduler/appointment feature in OpenMRS? | (Suggested by Marcos Alfredo Núñez) |
| |
Connections with other systems | e.g., ODK (Suggested by Joaquin Blaya) |
| |
OpenMRS service providers (for fun and profit) | (Suggested by Joaquin Blaya) |
| |
Out of hours hackathon room | (Suggested by Roger Friedman) |
| |
Signal Processing | e.g., EEG signals, standards: EDF – european EEG standard (Suggested by Marcos Alfredo Núñez) |
| |
Use of OpenMRS in the central/satellite environment | How's it working now, What features are needed to make it work (Suggested by Roger Friedman) |
| |
Roles and permissions | How to limit access by roles and encounter types. Would be nice to come up with solution. (Suggested by Ellen Ball & James Arbaugh) |
| |
How to maintain privacy around sensitive information | What's possible and not possible within the system, e.g. HIV status. Limit by organizational unit, Specific interfaces for different users. (Suggested by Janet Riley) |
| |
Writing modules and starting development | (Suggested by Ben Wolfe) |
| |
OCC and Concept Management | (Suggested by Ellen Ball and Marcos Alfredo Núñez) |
| |
Concept Labs | (This might be wrapped into the OCC/Concept Mgmt discussion above) Discussion of the use and development of standard concept libraries for specific clinical domains. Topics might include the (1) structure of concept libraries, (2) priorities for mapping existing tools/data collection instruments/clinical protocols into the dictionary, (3) collaborative model for design/management of concept libraries (who decides what goes in and how concepts are modeled?), (4) relationship with the OCC, (5) priorities for dictionary development. For background, the Maternal Concept Lab (www.maternalconceptlab.com) was created last year to facilitate reuse of maternal-child e-Health tools, beginning with development of a shared dictionary based on the MVP/CIEL dictionary. Work started with a powerful, openmrs-independent concept search tool (see example at []) and mapping in a number of existing antenatal and postpartum protocols, resulting in adding 100+ new concepts. (Suggested by Jonathan Payne) | Andy Kanter, Jonathan Payne, Ben Wolfe | |
Using OpenMRS for research studies | (Suggested by Ellen Ball and Marcos Alfredo Núñez) |
| |
Module Lifecycle | Their lifecycle, how to identify modules that should be maintained when the initial developer is gone, testing with new releases, etc. (Suggested by Roger Friedman) |
| |
Customizing OpenMRS | How to customize 1.8 or the current UI (Suggested by Marcos Alfredo Núñez) |
| |
OpenMRS for specific programs | Cancer, primary care, pediatrics, non-communicable diseases, etc. (Suggested by Ellen Ball) |
| |
Reports Reports Reports | Getting the data out of the system (Suggested by John Hanley) |
| |
Remote clinics | The how-to and best practices of syncing data current, planned, and wish-list of mobile data entry where there is no electricity. |
| |
Google Documentation Sprint Planning | The week after this meeting we'll be at Google HQ for a documentation sprint. We would love to have implementers help us with what should go into an "implementers guide" document. (Suggested during 29-Sep Developer Forum) | ||
GSOC work - 2011 | It may be interesting to discuss what was done during GSOC this year, what we're continuing with, our experiences etc. etc. | Suranga Kasthurirathne | |
Migrating to Git | How/when can OpenMRS migrate to distributed development? | ||
Making 2.x a Real EMR: Modules as Apps | Multiple groups want OpenMRS to have a different workflow and webapp. I believe that with (1) the 2.x UI Framework, (2) new conventions around extension points, (3) thinking of modules as "apps", and (4) teamwork, we can quickly build something awesome. | ||
OpenMRS for small clinics | Issues implementing OpenMRS in tech-resource-poor clinics, especially those transitioning from registers to their first EMR. Ideas for specific topics: 1) How could standalone distribution be pre-configured to be more turn-key (modules, concept dictionary preload)? 2) Package software with example paper-forms / reports that correlate with included concept dictionary? 3) Site examples with complete workflow explanation (video or written)? 4) YouTube videos explaining OpenMRS concepts, software-walk-throughs? 5) What additional documentation is needed? (Suggested by Tobin Greensweig) | Tobin Greensweig | |
Scaling OpenMRS implementation | How/When can OpenMRS support clustering of the database to support ever increasing need for using EMR real-time even in remote locations. |
| |
Customizing the Reg process: options and common needs | Every clinic has a different registration process. Sometimes this leads to new modules. What are there common patterns and requirements? Could these be turned into more general solution so there were less need for custom solutions? (Suggested by Janet Riley and 10/6 dev forum call) |
| |
|
|
| |
|
|
| |
| Performance and Load Testing | We experimented with performance testing for our 1.8 release. Was it the best way to do things? What did we learn? What can we do different? Should we build a testing team? Come to this session and let's figure it out. (Suggested by Michael Downey) |
|
"The OpenMRS EMR" | OpenMRS core is designed as a platform to build EMR systems on. Many organizations want to build more customized EMR systems with tools for patient summaries, data display, reports, forms and functions for point of care use for example. What are the most important functions people want in a typical EMR built with OpenMRS and what tools and modules already exist? What are the gaps and top priority improvements that should be considered for the road map? | Hamish Fraser, Evan Waters | |
Lessons to learn | What lessons can we learn from commercial software development teams ? what can we adopt, and how can we improve ourselves ? (Suggested by Suranga Kasthurirathne) |
|