I know Address Hierarchy module has such a capability, but I am thinking is it possible to provide this as a generic OWA functionality, with a user being able to define a handler to transform the uploaded CSV data into the necessary OpenMRS data entities
Should you go that route, I hope you would consider the OpenMRS Initializer module as your backend. This is exactly what it does: transforming CSV rows into OpenMRS entities. Happy to discuss what would be needed to make it RESTful… etc.
I really would suggest you to go through its (exhaustive) README to understand how it works with the various data model domains that are currently supported.
@mksd How would the module work with an uploaded file? This sounds interesting
It would just process it as it already does, it would turn each row into a saved/updated entity. Look in here for a sample (test) configuration for each of the supported data model domains. Best is to do that while looking at the ad-hoc README in parallel, there’s one for each domain.
Initializer is currently a Java API-only module, basically its services are only invoked through its activator. But of course it is possible to adapt the Java API for your use case and bring a REST layer on top for the UI that you are envisioning.
@mksd I am back on this and wondering, how would the module support creation of visit -> encounter -> observations hierarchy as this is what we are looking to do?
Initializer is in general (at least until now) used to create single entities at a time. So, the dumb way to do this would be to
- Create the patients.
- Create the visits (referring to those patients).
- Create the encounters (referring to those visits).
- Create the obs (referring to those encounters).
I think we should probably support the above dumb approach anyway. But surely we will want to brainstorm about a custom parser that eases the above process?
@mksd Question is it possible for the initializer module to load configurations in a module directory - say api/resources/config ?
We are looking to support Ugandan implementors to build on top of UgandaEMR, and in some cases may be easier for them to add csv files to a directory - I am still trying to figure out how it will all tie together
While it is certainly technically doable, it defeats the primary purpose of the module.
Initializer’s main goal is to help avoid the reliance on custom modules. Configuration files are dropped in the app data directory and the module processes them upon starting. This helps the implementer focus on maintaining configurations, not binaries. This is an example of such backend configuration.
I’ve been trying this method countless times but the visits will never show up on the patient information page. The patients are uploaded and searchable in OpenMRS but they come sans visits even though all visit data is in the visit table complete with patient_id and location_id.
@kizomanizo does your remark relate to Initializer? I’m asking because Initializer has nothing to do with visits or patients since it only loads metadata.
Not at all, I just tried inserting patients using SQL but could not see the visits that I added in the same mechanism. Turns out I needed to set the creator column to an ID that is actually in the table instead of inheriting that from the EMR that I am migrating from.