Child pages
  • OpenMRS Bulk Data Import
Skip to end of metadata
Go to start of metadata

2014 Internship Project

This project is being considered as a potential project for 2014 Internships. If you are a potential intern and are interested in working on this project, please discuss it in detail with the mentor(s) listed here before submitting your internship proposal.

Primary mentor

Pascal Brandt

Backup mentor

TBA

Assigned to

TBA

BlogTBA

Abstract

It is a well known problem that it is difficult to migrate to OpenMRS from other systems and it is also difficult to do an initial bulk import of patient data. This is an important problem, but has no widely accepted solution yet. This project aims to make the process of migrating to OpenMRS easier by simplifying the process of bulk retrospective data entry.

The result of this project will be an OpenMRS module that will enable users to upload spreadsheets via the user interface and select which columns map to which elements in the OpenMRS data model.

Objectives

  1. At the very least, there should be a user friendly way to import patient data from an Excel spreadsheet or CSV file that uses the Java or REST API.
  2. Produce some community validated best practices for migration and data import.
  3. TBA

Extra Credit

  1. It should be possible to connect to different data sources and map data elements to the OpenMRS data model via the UI.
  2. TBA

Timeline

April 21 – May 19 (Community Bonding Period): 

  • Get to know my fellow peers and co-workers
  • Throughout this period, I will as always be available on IRC to further discuss the proposal with members of the OpenMRS community so that I will be able to adjust or add things that I may have not thought of before.
  • I will be actively engaged in discussions with my mentor to further understand and agree on the scope and requirements of the project.

May 19 – August 18:

  • Development phase (to be broken down into detailed steps)

Resources

  1. Migrating Data to OpenMRS
  2. https://answers.openmrs.org/questions/210/importing-large-amounts-of-patient-data
  3. Spreadsheet Import Module Version 2
  4. Data Migration
  5. CDA-based Clinical Patient Summary Import and Export
  • No labels

13 Comments

  1. Hello Pascal Brandt. I am interested in this project and would like to discuss it with you. May I know which is the most convenient mode to communicate with you. Thank you.

    1. Hi,

      The most convenient way is to ask your questions right here.

      Regards,
      Pascal 

  2. Thank you for the quick response! (smile)

    I went through the resources provided, what I am wondering is that, how is this project going to be different from Spreadsheet Import Module Version 2. Is our aim to overcome the shortcomings which Spreadsheet Import Module Version 2 Module faces?

     

    1. Hi,

      Yes, part of the idea is certainly to improve the current spreadsheet import module. As you can see, the project isn't very well defined yet, so we have the opportunity develop the specification ourselves based on requirements from the community. Did you see the additional idea in the Extra Credit section? Also, I know we might be able to source some requirements from Mozambique. Jan Flowers, is there someone we can chat to about this?

      Ciao,
      Pascal 

  3. Great!

    Yes I went through the Extra Credit section. (Hopefully we will be able to realise this option as well during this summer!)

    Until we get some more idea/guidelines, as to how we would want this module to be, I will start by gathering some specifications/requirements which can help make this project a widely accepted solution for data import.

    Thanks.

    1. Sounds good. Also make sure you work through the Getting Started as a Developer guide and if you like, try creating a module..

  4. Hi Pascal Brandt

    I am interested in the project, I have gone through the links and I have even explored the spreadsheet module. I would like to know if this project is targeting a specific data model or a generic one. I have gone through all the modules available in the data import/Integration type such as DHIS-SDMX-HD module,DHIS integration module, CDA based clinical patient summary import and export.And even in the Rwanda and Tanzania implementations specified in the Data migration link. These all have been very user friendly as they were targeting a specific model and reduced the number of user interactions. But, if we choose spreadsheet style generic style we would be needing all the mappings.

    So what I can think of are improvements such as abstracting the user's view to the data tables and allowing them to view only object attributes.Spreadsheet module would need us to modify the names of columns and such data. And instead of making the user change and modify we might be allowing the users to map their respective column names to attributes. 

    And for the extra credit is it regarding multiple spreadsheet scenario or is it multiple data format scenario where we might be converting them to a generic format?

    Am I on the right track?

    I have been going through some community accepted data exchange formats and I would like to find out if there is any preference for any format? 

     

    1. Hi,

      This module is not yet fully defined, so we have the opportunity to work with the community to develop the specification. I think a good approach will be to make the module as generic as we can within the given time frame.

      Something to consider might be the creation on new patients on a data import. Do the current modules create patients if they don't exist? What if a patient with the same name or ID already exists?

      I think the primary format we should focus on is Excel/CSV and we should give the user the ability to map columns to the OpenMRS data model using our UI.

      For extra credit, I think the best thing we could implement is a developer API that makes things easy for developers working on migrating data from other systems. Perhaps a set of interfaces with an implemented example. We'll have to think about this if there's time.

      It's important to remember that the specifications should come from the community. The above suggestions are just a possible starting point.

      Cheers
      Pascal 

      1. Hi Pascal Brandt, Thanks for comment

        In existing  spreadsheet module we can insert new data but  we cannot modify/alter existing data i.e if person with same ID exists then it pops out an error about duplicate entry.

        I will work towards a generic model.

  5. hello,Pascal Brandt .

    I am also interested in your idea. I am also thinking of making openMRS java independent.So can we work on making module with html,css,javascript,php and mysql?

    Is it good choice to add appointment handling module and module which can add sonography and xrays?

    Is it made with html,css,javascript,php and mysql or openmrs sdk?

    1. Hi Sky Player,

      If you're interested in extending the functionality of OpenMRS without using Java, you might be interested in the Add Support for Open Web Apps project.

      If you want to build a PHP application that interacts with OpenMRS via the API, I'm not sure that makes sense as and OpenMRS GSoC project. You say in your proposal that you want OpenMRS to be "accessible from any devices", but as web application, it already is. It also has a web API that makes it accessible from any application. Could you provide some more detail about exactly what you are hoping to achieve?

      Also, you mention two additional modules in your proposal. Each of these their own (detailed) proposals.

      If you want to have a reasonable chance of getting accepted into the GSoC program with OpenMRS, my recommendation is that you select a project from the official list and spend time engaging with the community and contributing to the OpenMRS core codebase.

      Regards,
      Pascal