There is a growing conversation in the OpenMRS community about reinvisioning our platform and building a new, more modular, framework.
The need for this is well summarized by @burke recent presentation made at Regenstrief in November. It was the subject of discussion spurred by @gschmidt at the implementers meeting in Kenya. On Talk @bistenes has started a conversation from a technical side how components may be configured.
We (@tgreensweig @gschmidt @jteich) formed a small working group to distill ideas and start the process of research and development in designing OpenMRS 3.0.
We envision a platform which will be easy to roll out and configure for smaller implementations but built on a modular framework such that larger roll-outs can deeply customize the same user interface to leverage and support the community’s efforts. We envision a platform which will easily support the global focus on chronic disease management.
We are planning to explain our ideas by describing and and mocking up an EHR which will focus on treatment of hypertension and HIV then show how, in a modular way, we could expand this platform to address diabetes, TB, malnutrition, maternal child health, and other verticals.
We aim to work openly and keep the community engaged in our process.
As a first step, does anybody have any feedback about the approach to this task ahead?
-Tobin, Greg, Jonathan
Greg’s EHR Design - OpenMRS Lightning Talk (Dec 2018) - 5 minute lightning course on EHR User Interface Design. (https://www.youtube.com/watch?v=XBuJCpIdPLI)
Burke’s GHI WIP Talk at Regenstrief (Nov 2018) - Overview of the history of OpenMRS and evolution of the Reference Application and the community’s needs
Thanks @gschmidt, so we’re talking Ref App 3.0 right?
We would like to be kept in the loop as much as possible as we’re involved in a large scale project that will bring the following features to the Ref App:
- Mobile responsiveness
- EHR syncing capability
- Data sync with third-party systems (eg. ERP, DHIS2)
- Configuration split from code
- … and more
All those are high level topics that I throw in there with not much details and that will imply a substantial amount of changes to the existing code base. There are other topics that I can think of (such as full support for internationalization of metadata) that are less relevant to the project mentioned above but that I know are being very relevant to other projects I’m involved in.
Cc @amine @lilian @janflowers
Further ref: Check out our CY19 plan for Operations and Community Outreach/Engagement!
So during our CY19 planning discussion on the Platform and Ref App, we talked about taking this up at one of our Design Forums.
Here’s how to get it on the schedule: Propose a Design Forum Topic
@mksd @gschmidt @c.antwi @ssmusoke @burke @mseaton @mogoodrich
Hi @mksd, thank you for sharing some initiatives that you and your team are working on, this is exciting because it sounds like there’s a lot of overlap here.
To directly answer your main question about whether we referring to Ref App 3.0? The answer is, it’s complicated.
There are a lot of conversations in the community about next steps for development (and this is awesome), but I think overlapping conversations are happening.
Some conversations are focused on functionality that needs to be added to Core or to Ref App now (or last month)! Very high priority issues that are required to meet deliverables that implementers have committed to, to patch bugs in the current system, or development projects that are already underway.
Other conversations are focused at additional functionality that implementers would like to see built out in the next 6-18 months. Trying to identify what are high value and high priority items across the community to solve anticipated deliverables.
And finally, other conversations are focused on developing a compelling and comprehensive vision of where OpenMRS can be in 2-5 years. This is a conversation where we allow ourselves to step back and re-imagine how we can position OpenMRS as a community of EHR thought leaders with a cutting-edge software package that demonstrates that. Something that addresses the anticipated needs of the OpenMRS community, its stakeholders, and is so wonderful to use and develop with that it places OpenMRS systems on the map as the go-to EHR.
At one point or another, each of these different conversations have been called ‘OpenMRS 3.0’ or ‘Ref App 3.0’. Which obviously is a bit confusing!
The undertaking that Tobin Jonathan and I are focused on is primarily the third category - working with the community to bring together a comprehensive vision, and strategy to get us there.
However, the future is not a distant dream. I believe there is a way we can start slowly building as a community (in the very near future) towards our larger long term goals while concurrently addressing the immediate and short term deliverables (category 1 and 2).
I’d like to propose a way we can do this in a detailed Talk post early next week.
I’m also interested to learn more about the large project your working on. Have you started to compile some documents summarizing the features you are planning to build out. It would be interesting to see where it overlaps with other groups working on similar functionality.
-Greg / Tobin
Thanks @gschmidt and @tgreensweig for this clarification.
I think our project sits somewhere across your points 2 and 3 in terms of time frames, and rather leaning towards 2. My point was to raise our hand and say “hey we’re here, please include us” whenever possible because we have a number of large deliverables that should certainly be known of by those who are leading the path through OpenMRS’ roadmap in regards to this “OpenMRS 3.0”.
Yes certainly, and a lot of that is currently in a format that is not open to the public. However in regards to my point ‘EHR syncing capability’ we will compile a concept note that we intend to share in an ad-hoc thread and that will hopefully lead to a design call. So bear with us, we hope to have this out there within a week or two (cc @lilian). Actually this will also touch to the next point: ‘Data sync with third-party systems’ as we hope to come up with a design that kills those two birds with one stone.
In regards to SSO we might do the same or simply jump onto various topics on Talk about it.
This is all very exciting
Thank you @gschmidt for the introduction. Could we schedule our first discussion session for the design forum Febuary 4th 2019?
OpenMRS 2 to OpenMRS 3 - a proposal for a way to get there
Hi, this info-graphic proposes a way how the OpenMRS community can move from OpenMRS 2 to OpenMRS 3 while continuing to meet our current obligations & deliverables.
It tries to highlight three conversations around the OpenMRS community identified in this prior post and show a way they can be integrated together into a common vision directed towards a goal of OpenMRS 3.
Link to FULL SIZE Google Docs file
How does this proposed approach look to you as a first draft?
Green - I like it, it generally looks good
Yellow - It may be ok, but after some changes
Red - I have some significant concerns about the proposal
Please leave feedback in the replies, or don’t hesitate to message
Some specific questions
Q: Do the general buckets of current state / upcoming deliverables / big vision capture the ongoing conversations? Is something missing?
Q: Is 6-18 months about the right time frame to think about when considering the community’s upcoming goals, and seeking to develop early releases of OpenMRS 3 that helps them meet their pre-existing commitments?
Q: Is 2-5 years about the right time frame to be thinking for delivering on a big OpenMRS 3 vision?
-Greg & Tobin
Stay involved & up-to-date on this thread, don’t forget to change your status (on right side of screen) to watching or tracking (or muted )
cc: @jteich @mksd @ivange94 @naveed1228 @vamsi77 @judeniroshan @tendomart @reubenv @samuel34 @mozzy @harsha89 @burke @paul @mseaton @ssmusoke @mogoodrich @bistenes @ahabib @jennifer @c.antwi @dkayiwa @darius @angshuonline @janflowers @ball @suthagar23 @wanyee @irenyak1 @jwnasambu @terry @akanter @raff @wyclif @taremwatadeo @k.joseph @ningosi @tmueller @ibewes @mksrom @r0bby @mavrk @owais.hussain @willa @ruhanga @slubwama @smuwanga @ivange94 @gayanw
Please be sure to invite anyone you think may like to be part of this conversation
I like this!
Can we factor in the quantity of resources (for instance number of developers) we are planning to use in order to achieve this? For it will determine the period we shall take to release the deliverables.
For those of us who were not at the conference this year, is there a good summary of what OpenMRS 3 is supposed to mean? And what are we thinking these shared points of vision might be?
Hi - one summary from the OpenMRS conference is on this post. (The first section is a high level summary). However, it is more of a wish list of ideas, rather than a set of design specifications.
The first phase over next few weeks will be to talk with the community and ensure we identify and have input from all stakeholders about what their vision for OpenMRS 3 is, and what they would rank highly as potential shared projects for the next 6-18 months.
We’d like this process to be as transparent and engaging as possible, so it will happen step-by-step. We’d also like to work alongside the many other planning conversations already happening on Talk.
I think within a few weeks we’ll have arrived at a much more concrete understanding of both of those points.
Honestly, i can’t wait to see the final product. Well done members
This is a very great idea, I support it +1, however like @dkayiwa said we need to put into consideration the number of developers committed to seeing this a success in the planned time otherwise we may go beyond the number of months to deliver.
On another note, do we already have the input from the implementers, in terms of what new functionality they would wish to see in OpenMRS 3 or do we hope to get this at a later date? This may affect the speed of delivering yet if done early it saves the developers from going back and forth.
Otherwise, thanks Greg & Tobin plus all.
Hi - thanks Irene and @dkayiwa. I agree, knowing how many developers we’ll have available definitely will impact the speed of being able to deliver.
We don’t know this number right now. I have a few thoughts on it.
a) for the 'baseline / essential / current state/ development - these are in theory items that ‘need to be done’, or ‘already are being done’. From this perspective, its ensuring OpenMRS community is supporting these needs. The number of developers is based on what the ‘baseline’ needs are to keep the system running smoothly
b) for the 6-18 month vision - how many developers and resources the community is able to dedicate will significantly be impacted by how much common ground we can find among the implementors. If there is a lot of overlap, and everyone is contributing because they see huge benefit in the work, then I think we’ll have lots of support and the community can be ambitious in its release cycle. If there is little overlap among implementors, it will be tough to find enough common ground to be able to be ambitious in what new functionality we can build.
c) for the 2-5 year vision - we can get there by regularly prioritizing the community’s next 6-18 month goals, and prioritizing that work to build. There is also a lot of hope that by having a clear and exciting vision (with detailed specifications and a good release plan) will help attract new developers and members into the community (and potentially additional funding) which will help accelerate these plans.
Do we already have input from the implementors? We have some. But it is just the start. We’ll need to work closely over the coming weeks with the community to help get much more detail on this. But I agree, we need a clear and shared understanding in the community of what we are building in order to make the developers work as smooth as possible.
Over the next few weeks there will be a series of posts and ways to get involved as we achieve more clarity and consensus on this
Thanks for kicking this discussion off, @gschmidt. As you say, I think that this is the start of a series of discussions and we may be a ways away from being in a position to determine what we’ll need not only in terms of developer resources, but UI/UX designers and testing.
As we look at our technical roadmap for the platform and the ref app this year, let’s consider what should be on it for the next 6-18 months as Greg suggests. Once we get further along in the discussions around what OpenMRS 3.0 means for us as a community, then we can work on laying out a roadmap for that work.
Thanks @gschmidt for taking this to here. It’s great to hear about OpenMRS 3 .
I would like to mention some highlights which may useful for the future,
Multi-Tenant Architecture - Providing multi-tenant architecture feature for Orgs/Hospitals which can be easily hosted in the Cloud and share the services over the Cloud under one domain.
OpenMRS Analytics - It should be an advanced module to produce great analytical outputs rather than the reports. We may enable some third party Analytical tools to provide better support for EMR analytics.
React Native Development - It easily helps us to adopt for Andriod/IOS Mobile responsive applications which is most wanted in the future.
Machine Learning Initiatives - Nice to have it , It could help to suggest and correct some mistakes while we using the OpenMRS for daily usages among patients. (E.g : If someone mistakenly typed a drug, It should indicate as the wrong prescription according to the added diseases history for the patient)
I fully agree - a lot of people in Community are talking about need for Multi-Tenant Architecture. This is looking pretty high priority for next 6-18 months. And yes, a more standard approach to data Analytics. (Re third party tools: AMPATH has had very good success with Elastic Stack & Kibana - we have a blogpost that will be published soon that explains our ETL process in more detail).
I’d like to comment on the Machine learning part in more detail. It is something I’m particularly interested in, because I think OpenMRS has huge potential here to advance the field in ways other EHR’s can’t.
At the moment it is very difficult to integrate these algorithms into clinical contexts. Many remain siloed outside of care. A pathway to integrate these into clinical systems & (critically) a system that can generate the necessary data (ideally of FDA quality) to evaluate their validity, and constantly monitor their safety is needed.
There are a few startups looking to try and figure out how to embed ML products into EHRs, but nothing at scale. And from what I can tell the system architecture of standard EHR’s will make this very tricky to do. And I suspect most legacy vendors are not excited to rewrite their code base.
Lets turn back to today. High priority for OpenMRS community is ‘modularity’ being able to swap components in and out. In our quest to develop a modular EHR system, we will end up disaggregating many individual operations into their functional components (some may call these micro-services). There is a priority to do this on the OpenMRS side in order to help us integrate features developed by different teams, and to allow new teams to ‘rewrite’ a service and ‘swap in’ their own.
In laying that functional EHR groundwork, I believe OpenMRS will concurrently lay the critical architecture required also make effective and regular integration of ML features into clinical system. …I’m working on a blogpost to explain the idea in more detail…
If you know anyone interested in this field, please DM and lets talk. I’m assembling core group of people specifically interested in this topic
Will machine learning integrations be part of the first iterative release for OpenMRS 3? Highly unlikely. But we certainly can start recruiting the right people to help us craft the right infrastructure to make this happen down the road.
We know where this is going in the long run. Ultimately some sort of a clinical workflow engine app store will exist where people compete based on quality and price. Its a while away but has the potential to dramatically improve care.
Few comments on multi-tenancy (esp on cloud)
- we should be clear of what mean by “Multi tenant”? Is it different entities or same entity but wanting to have multiple facilities using the same instance.
- If its for different legal entity or even same entity but operating in different countries - I think a separate installation is desired. It keeps the data segregated at the source and/or storage layer, and conforms to country specific policies and legalities. With storage and hosting getting cheaper day by day, I would rather encourage data-segregation at source.
- I can also imagine a case of cloud based service for individual consultants (e.g. Physician’s private consultation). Even there system would also have to guarantee that data segregation is followed at all levels and features (e.g. segregate reports). Imagine, someone (a physician) withdrawing from service, its imperative their data is somehow purged from the system!
- I can understand that an entity may want to leverage the same instance and limit access/operations at particular hierarchy. But thats different case then “multi-tenancy”.
Thanks @gschmidt and others. This is great stuff.
In my humble opinion, I think the primary challenge with things like this is looking at this large task, and getting it down to bite size chunks that can be meaningfully accomplished.
So, getting from the vision, down to the operations.
I’ve heard OpenMRS 3.0 be talked about as moving towards an modular EMR application. I’ve also heard it talked about as a full review and iteration of our community.
Neither of those are mutually exclusive. Maybe there’s some value in just chunking your vision into components so that community members can grab onto the parts of the overarching vision you’re all contemplating?
Thanks for all of this really intensive effort!
@c.antwi I’m not available on Feb. 4 and would like to be present. Perhaps the Wednesday Feb. 6 meeting?