Next week’s developer forum topic is “Crazy new technology ideas!”.
The idea is that we should take a step back, think outside the box, and envision novel technology approaches we could take to OpenMRS.
So…I’m asking you all to start brainstorming!
You can post your ideas on this thread, or save them for next week’s developer forum.
An idea of mine: (note: yours should be crazier)
We could invest in some Event-driven thinking (which we’ve never really done in the core OpenMRS world) to let people build richer client behaviors, more effectively populate/update analytics DBs, and more.
I was at BIDMC yesterday and they showed me their analytics system. Basically, when they save their EHR data to the database, they also send a FHIR packet to elastic search. With all their (nicely structured) data in elastic search, they use Kibana to do some really cool (and fast) reporting/analytics.
Starting up the Platform becomes: docker-compose up. Eventually, different services or even modules might be served up via separate, linked containers. This could also open the door for parts of our web services to be served using alternate technologies (e.g., nodejs, NoSQL, etc.).
SQL
What if Platform 3.0 was written in Nodejs + ElasticSearch or SOLR and we only used SQL when/where it outperformed a NoSQL solution? What would be the pros/cons? What might be the migration path for existing implementations?
*nix-ify the Platform
What if each service was like its own *nix service – i.e., apt-get install omrs-person omrs-patient?
Instead of multiple JSP, JS, Controllers etc. let’s have a single view and controller for all the admin CRUD (or any simple entity even if not metadata).
Therefore, adding a new one will be just a few entries in the dictionary, as the layout will be generated dinamically from the dictionary. When a new UI framework (Angular 3 ) appears the migration will be trivial.
The engine should be able to generate different layouts (form and grid as a minimum).
I am very new in OpenMRS, however i think that we could integrate it with some open statistic frameworks, like R. Today, there are integration between R and SQL platforms (MySQL for example). There is a possibility of apply data science concepts over all data already existent in several OpenMRS databases and through them, produce statistical inferences and predictions. We could forecast some demands associated with a specific type of disease, to the next year, for example.
Infrastructure to build Disease/environment specific distros - say HIV Distro, TB Distro, Small Clinic Distro etc. Maybe later it can become select options and the necessary modules are bundled together into a single WAR file
How can encounters, concepts and forms be deployed as part of core meta-data for a new installation without having to run SQL scripts - drop a well formed XML file and voila (almost like what liquibase does)
If we intend to stay in the sql world, a less crazy idea is supercharging our dao layer with QueryDSL and Object Specifications? It would help boost our REST API performance for sure.
It would be nice to integrate with Weka. It is a java based machine learning library. I already have some code that can learn from data pulled from OpenMRS if anyone is interested.
Something like OpenCPU would allow you to return R data as a JSON object, which you could then utilize however you wanted. Or at least it appears that way. https://www.opencpu.org/
i would love to have any other volunteer lead the forum, however just in-case none shows up i will be glad to take the lead as we shall have a few minutes to discuss our upcoming #omrs15-hackathon planning
There seems to be a lot of interest in CDS. Chica is now fully electronic and no longer depends on Teleform. For those interested in implementing clinical decision support in Openmrs, it might be worth taking a look at what CHICA has done. CHICA provides some powerful CDS that OpenMRS could leverage.
Kibana dashboards (based on ElasticSearch) are awesome. We should definitely add them to OpenMRS (even maintaining core model in SQL). A nightly batch process could copy data from SQL to Lucene.
) appears the migration will be trivial.