Skip to end of metadata
Go to start of metadata

Background

The goal of this road map is to communicate the high level vision and priorities for our near-, mid-, and long-term goals for advancing the technical support for AMPATH. The items in this list should be un-ambiguous about the work to be done, but are not meant to get down to the level of individual tasks/tickets.

Road Map

We are in the process of putting together the road map. Check back later.

2011 Q1

Vision

AMRS is Running OpenMRS 1.8 and connectivity between sites is in progress.

Technical Milestones

2011 Q2

Vision

Most sites are connected; issues with inter-site connectivity are being worked out.

Technical Milestones
  • Infrastructure upgrade (proposal and design)
  • Double Entry Reconciliation
  • ADT Support (i.e., AMRS sending out ADT messages upon registration)
  • Clinic Registry for NASCOP
  • Oncology server ????
  • Patient Matching Module
  • Orders moved into orders tables (complete)
  • HTML Form Entry fixes (needed by AMPATH)
  • X/Forms fixes (needed by AMPATH)
  • Network upgrade implementation (install additional fiber, order new switch, router & firewall hardware)
  • Implement IPAM
  • Migrate Nagios, Centreon, FLAVIO to dedicated hardware
  • Enterprise backup

2011 Q3

Vision

...

Technical Milestones
  • Improved Error Handling (user friendly improvement of handling HL7 errors)
  • Scheduling System
  • HCT Data Integration
  • Interface Engine (e.g., Mirth) running external to AMRS
  • Network upgrade implementation (begin install new switches, routers & firewalls)
  • Implement IDS/IPS at AMPATH Center

2011 Q4

Vision

...

Technical Milestones
  •  Concept Proposal module
  • Finish network upgrade implementation
  • IDS/IPS implementation at remote sites
  • Remote network monitoring

2012 Q1

Vision

...

Technical Milestones
  •  

2012 Q2

Vision

...

Technical Milestones
  •  

2012 Q3

Vision

...

Technical Milestones
  •  

2012 Q4

Vision

...

Technical Milestones
  •  

Targets

The following is an unordered list of tasks/projects of varying levels of granularity to be used as fodder for building the road map.

  1. Concept Proposal module
    1. Description:  The concept proposal functionality allows new medical concepts to be added to the core AMPATH terminology in a way that allows for distributed workflows among multiple form and terminology developers.  
    2. Rationale:  At the heart of all health care data collection is a collection of medical concepts which need to be modeled in a way that optimizes the data for reuse by multiple constituencies.  This work is as much an art as a science, and is a product of the history and experiences of a given implementation.  As such, there is no way to formally train new individuals to AMPATH as to how to do this work "correctly".  The concept proposal module is a key technology that allows the work to be distributed in such a way that helps build experience amongst the growing Kenyan team without disrupting the existing production environments.  Currently, it is cumbersome to keep up with edits and suggestions from multiple form developers. 
    3. Notes from Paul:  I believe this work can be split into multiple phases, and not a "big bang" as it might be thought of in the current roadmap.  That being said, the more immediate tasks around concept proposals should be deliverable in a much quicker timeframe, and I believe this functionality should be given higher priority.
  2. Orders moved into orders tables
    1. Description:  Currently, a clinician order (that is, documented intention for a patient to receive some sort of intervention) is recorded as a clinical observation in AMRS, and not as an order.  This was because that part of OpenMRS wasn't developed at the time when AMRS was first deployed.  Recording orders as observations doesn't allow all of the metadata that relates to orders (ie, start and stop dates, order types and sets) to be properly recorded.  In order to correct this, existing order data needs to be transformed, the order API must be properly implemented at AMPATH, and all existing uses of order-related data currently in AMRS need to be reconsidered (including modifying rules and code) to be compliant with the more proper persistance model. 
    2. Rationale:  Correcting this legacy decision is important to support drug regimens, order entry, communication of orders with other systems, and expand on order-related decision support at AMPATH.
    3. Notes from Paul and team:  We may want to plan for this functionality after OpenMRS 1.9 release (targeted for May 2011), which will include extended support for orders at the API level
  3. HTML Form Entry fixes (needed by AMPATH)
    1. Description:   HTML Form Entry is another technology that allows for form-based data entry to occur within AMRS.  It is attractive to many because it does not require Microsoft Infopath, and works completely from the browser.  It also is based on HTML, which is familiar to many junior developers.  See here for more information on this functionality.  This code was developed by the OpenMRS community, but has yet to be broadly implemented with AMPATH.  Early evaluation of the work yields a list of code modifications that would allow this work to more easily fit the AMPATH context.
    2. Rationale:  making HTML Form Entry more readily available to AMPATH allows for a faster, easier way to prototype forms, and also collect data in technologies such as thin client computers and standard browsers.  Anyone with basic knowledge of HTML should be able to easily adapt to this style of form development.
    3. Notes from Paul:  the specific fixes need to be more detailed by Ada, Ali, and the System Engineer Team
  4. X/Forms fixes (needed by AMPATH)
    1. Description:  XForms is another technology that allows for form-based data entry within AMRS.  It is attractive to many because it does not require Microsoft Infopath, and works across multiple technologies, including browsers and mobile devices.  See here for more information on this functionality.  This code was developed by the OpenMRS community, but has yet to be broadly implemented within AMPATH.  Early evaluation of the work yields a list of code modifications that would allow this work to more easily be consumed within AMPATH.
    2. Rationale:  making XForms more readily available to AMPATH workers allows for another option for data entry.  There are various pros and cons to all three types of data entry within OpenMRS, and it's clear that XForms has strong utility in certain AMPATH contexts.  
    3. Notes from Paul:  these need to be more detailed by Ada, Ali, and the System Engineer Team.  I also think that both HTML Form Entry and XForms should be placed on the roadmap based on another deliverable's need.  For example, if a project needs to have form-based data collection across mobiles devices and web browsers, we might consider implementing XForms, working through the issues to make it more generalizable along the way.
  5. Patient Matching Module
    1. Description:   The Patient Matching Module allows multiple records for a single individual (both internal to a system and amongst multiple systems) to be automatically detected through sophisticated statistical matching algorithms developed by Shaun Grannis and his team at Regenstrief.  
    2. Rationale:  AMPATH has grown to a scale in where multiple health information systems must coexist to support the entire enterprise.  For example, LIMS supports laboratory services, and PIMS supports pharmacy services.  Given that the data from each of these systems often needs to co-mingle to create a virtual electronic health record, the patient matching module provides us with a technique that allows a single individual to be linked with the records from all of the corresponding systems within AMPATH.  It also provides the framework for AMPATH to detect internal duplicate records for a given patient within a single system.
    3. Notes from Paul:   This is fairly far along from what I understand, but likely would benefit from the 1.9 changes coming to this code.  We might want to use the technology to solve specific short term issues, but focus on more robust intergration of the module into workflow following the 1.9 release.
  6. HCT Data Integration
    1. Description:  Currently, each iteration of HCT has brought with it a new server installation and a collection of completed forms (and a corresponding instance of OpenMRS) that ultimately needs to be merged into the main repository.
    2. Rationale: HCT is an initiative that grew very rapidly, and it's scale and geographic distribution forced the technology that supports it to be distributed.  Fortunately, each server instances of HCT uses OpenMRS as it's database, so the work in merging these data was preconceived many years ago.  Now the work has to be done to complete this process.  Merging HCT data allows these data naturally to be used both in clinical and research contexts from within AMRS.
    3. Notes from Paul:  this is likely the short term deliverable to get us thinking about patient matching, but there's also the issues of doing checksums against direct integration into AMRS, so this task is more than just a patient matching module project.  There's also it's relationship to household level data collection (#17)
  7. Remote Form Entry Improvements
    1. Description: Currently, remote form entry allows for remote sites to perform basic form based data entry and collects the resultant data to be delivered in a disconnected fashion to the central site.  This module was developed with short term interests in mind, and the amount of time it's been used has encouraged development of some simple features to allow it to continue being used while connectivity between sites and data synchronization technologies are mature within AMPATH.
    2. Rationale:   We are heavily reliant currently on Remote Form Entry.  There are a few functions that are an appropriate tradeoff of effort vs. impact given that the ultimate plan is to move away from this technology long term.
    3. Notes from Paul:   need more input from Jeremy and Ben on this one.
  8. Connectivity Between Sites
    1. Paul:  I don't think I need to explain this one. :)
  9. Implementation of Data Synchronization Module
    1. Description:   In connected environments, the most popular way to share data between geographically separated instances of OpenMRS has been through the Data Synchronization Module (commonly known as Sync Module).  Given the direction AMPATH is growing, evolving to this form of data exchange for the EMR system is viable and preferred.
    2. Rationale:  The sync module simply allows all instances of OpenMRS within an implementation to have consistent information amongst them.  This allows to all function as the central site currently does, enabling all the data review, printing, and decision support functions throughout all of AMPATH.  It also functionally removes the need for Remote Form Entry.  
    3. Notes from Paul:  High priority once connectivity between sites is established.  Yet another example of existing OpenMRS functionality that hasn't been implemented at AMPATH. :)  This is low hanging fruit kind of stuff from a development perspective, just needs good project management and implementation support.
  10. Pharmacy System Integration
    1. Description: 
    2. Rationale: 
    3. Notes from Paul: 
  11. ADT Support (i.e., the registration process sending out ADT messages)
    1. Description:  There are a series of potential functions that can be automated if there's a technical trigger that allows the information systems throughout AMPATH to be alerted that an individual is actively being seen for care or is about to leave care.  This is one of the primary functions of an ADT system.
    2. Rationale:  We increasingly are seeing requests for more sophisticated clinical functions that requires awareness of the patients being actively seen in AMPATH.  A functioning ADT-like system will meet many of those goals.
    3. Notes from Paul: Needed for Oncology project?  Clearly needed to do on-demand clinical summaries.
  12. Interface Engine (e.g., Mirth) running external to AMRS
    1. Description:  Currently message-based communications in AMPATH are all brokered using AMRS.  An interface engine allows clinical system messaging to be a shared service across all of the entities in a health information environment growing as AMPATH is.  
    2. Rationale:  This is a necessary technical advance to support AMPATH's health information system long term growth trajectory.  Messages from the pharmacy, radiology, laboratory, and EMR should all pass through Mirth or a Mirth-like engine.
    3. Notes from Paul:   this is a challenging one to fit against the real world implementation needs, but certainly higher priority strategically for us.
  13. NIS
  1. Data Integrity
  2. Improved Error Handling (user friendly improvement of handling HL7 errors)
  3. Scheduling System
  4. Handling Household level data
  5. Infrastructure upgrade
  6. LIMS Support Contract Proposal
  7. Oncology Server
    1. Paul:  Isn't this done or quick to be done?
  8. Double Entry Reconciliation Module
  9. Clinic Registry (for NASCOP)/ Reporting Module
  10. Universal Identifiers
    1. This is as much or more of a process/social problem as a technical one.
    2. Requires that registration be working at sites as well as HCT (registration = assigning a universal identifier to a person AND ensuring that the identifier with the person's collected demographics makes it into AMRS)
    3. Will leadership/ownership to drive this forward.  We envision a SWAT team descending on clinics one at a time to convert the clinic to universal identifier usage.

3 Comments

  1. The following items are under-specified or ambiguous as milestones:

    • 2011 Q1
      • Remote Form Entry Improvements
      • Connectivity between sites
      • Data Integrity
      • Oncology Information system
    • 2011 Q2
      • HTML Form Entry fixes (needed by AMPATH)
      • X/Forms fixes (needed by AMPATH)

    Does "Sync module Pilot (Change from remote form entry to sync modules for AMPATH)" mean just in the AMPATH centre?

    1. Can we include Concept Proposal Module for 2011 Q1?  This should be in top priority since it will help us to clear the backlog of pending forms.  Also, Jer and I talked with Glen and Glen believes that it should require a few days of programming time to finish up the Concept Proposal Module.  

      We also need to include Reporting Module for 2011 Q1 as well since the demand of MOH reports is increasing tremendously.

      For the Data Integrity Module, it's pretty much functioning, except the ticket of email notification which Jonah/Jeremy are working on that. 

      1. We should try to avoid setting milestones like

        • Concept Proposal Module
        • Reporting Module
        • Oncology Information system

        and, rather, try to list functional milestones -- for example:

        • Concept proposals can be edited and reviewed within a shared space
        • Report X is being created using the new reporting module
        • At least 3 Oncology forms are in production use within AMRS

        The former simply name "things" and can be interpreted differently  by each reader; the latter are specific and measurable.