Develop and evolve the foundational technical products of our community (OpenMRS Platform):
OpenMRS Core: minimal Java and RESTful backend for person-centric record systems
OpenMRS Web Application Framework: modular user interface framework for building clinical applications with OpenMRS Core
Develop and evolve the OpenMRS Community Distribution, a pre-configured electronic medical record system meant to be used directly in health delivery settings.
It’s possible to split 1 into two separate goals, of course. Fire away!
I thought we were moving toward a model where we would create many community distributions now? This name seems too exclusive to support such a model.
Finally I will, once again, reiterate my strong view that we should no longer be using literal product names. Abstraction would allow us to evolve the scope of these products over time, without having to rename and create confusion amongst our community of contributors & our customers, while keeping our brand strong and maintaining a sense of reliability for our customers. I realize I have been in the minority within OpenMRS, but my belief is based on the experiences of those who have gone before us.
Ultimately, whatever it takes to get us out of the planning process and starting to move the plans forward, is what I’ll support.
We must stop recycling terms we have used for years, and giving them different meanings. It’s not okay for us to use “OpenMRS Core” to refer to something different from what’s in the openmrs-core github repository, and we shouldn’t change “OpenMRS Platform” to mean something other than what we’ve invested the last 2 years making it mean.
How about:
Develop and evolve the foundational technical products of our community (Shared Building Blocks):
OpenMRS Platform: minimal Java and RESTful backend for person-centric record systems
OpenMRS Web Application Framework: modular user interface framework for building clinical applications with OpenMRS Core
Naming doesn’t have to be exactly this, but “web application framework” doesn’t do justice to a reusable, best-practice library of things like “Order Lab Tests” and “Display Allergies”.
And I could see us not explicitly calling out both Platform and Web Application Framework in the Objective (for brevity) but it helps (me) to think about this technical split precisely.
Somehow I missed this while replying. But yes, I agree that in the objective it would be nice to talk about the fact that we want (a) platform and framework-y things, and (b) actual reusable components, and that these activities are cross-cutting and long-lasting, regardless of today’s particular technology instantiation.
So perhaps something like:
Develop and evolve the foundational technical products of our community:
common platforms and frameworks to simplify development of any person-centric record system
reusable best-practice components to speed up development of high quality implementations for common scenarios
However, when I wrote that I was actually thinking about the idea of calling our products literally the thing that they do at the moment, such as “EMR” or “Reference Application” or “Calendar”. (Parallel examples in other worlds: “Mozilla Browser”, “Apple Laptop”, “Ford Automobile”.) Doing such boxes us in and prevents us from evolving the products in ways like are being explored here.
Totally understand the value in making the strategic objectives more generic in their wording. I don’t have a bias one way or the other on that.
@michael When we release a software distribution, what are you suggesting we call them? Something that is more a code-name than an explicit declaration of what they do?
So instead of OpenMRS Core / Platform, call it Schnogenlocker?
Also @darius’s further delineation of components makes sense.
I just want to point out that the word “platform” could be used to describe all three of these things. If we are determined on using that phrase to only describe the “minimal Java and RESTful backend”, then so be it from m perspective. I just want to hold out that it’s confusing at least to my eyes.
“Platform” should be the shared platform – i.e., that thing which every implementation is running, regardless of what technologies/pieces it comprises. Let’s not ignore the significance of every single implementation to date (from Bahmni to PHR to NCD) are running the same platform. We can and will experiment with expanding & extending the platform as well as better understanding its users (that’s in our 2016 objectives), but we will be very careful to ensure that it continues to meet everyone’s needs.
Yes. Michael is referring to branding our products with non-descriptive names. So, you would use OpenMRS Douala® and, perhaps, integrate it with OpenMRS Kumbo®. That way, if Douala® stops being a reference application, the name doesn’t need to change.
More or less … an attempt at future-proofing us to some extent. (I wouldn’t recommend pushing a wholesale change of what software XYZ is, though, as that as well might be too confusing.)
I just want to add that I strongly support use of non-descriptive names. At one point we had great suggestions like OpenMRS Samsara, but these seem to be trademarked, and so never made it to the poll.
My opinion on the topic of the Platform, is that it should include a web framework (thin enough that its reusable). I say this because we want to simplify people’s lives and make this an electronic medical records platform. Not any person-centered record system (like a library system or course system). We do know common use-cases that were part of the platform for long. We shouldn’t lose that common-ness just to go the micro-kernel route.
The Reference application should be tying the set of platform components (plus its own components) to create a workflow/particular use-case EMR. I think we should stick with the HIV or TB program workflow. We know that well and there is still a strong need for that use-case. Other community distributions can be what they want and still contribute to building components. Some common components, like an image capture one from camera developed by say. Bahmni could be brought into the platform, if many people think its shareable.
I would suggest that for this discussion we avoid getting bogged down with (a) specific names of the software components we release, and (b) whether we want descriptive vs nondescriptive names.
Also, I will reiterate this proposal:
The key point is that these two bullet points are strategic goals that we should be carrying out for their own sake, and they (intentionally) don’t map to exactly two specific software products.
Examples:
creating a “common AngularJS REST library”, that’s clearly an activity touching the first bullet point, regardless of whether it is in “Platform that everyone uses” or in a higher layer used by only some implementations/distributions.
the core platform could include a well-vetted-but-East-Africa-specific name phonetics algorithm, and this in the spirit of the second bullet point about best-practice components…
I’m not suggesting we need separate names for everything above, but I wanted to show the pieces that are in my head as we’re discussing it. And here are the definitions/scopes of each piece:
Community Distribution: The “complete” app with enough of the basic, out-of-the-box EMR functionality that ~80% of sites could begin with it. In the image, the big purple block implies that most of the community distribution may start out as a specific package that, while configurable, is not as modular & extensible as we’d like it to be in the future. People looking for a downloadable open-source EMR would be directed to the Community Distribution alongside all the other distributions of OpenMRS.
Used in both Community Distribution and Reference Application: Some of the features of the reference application may be useful (and bundled) within the community distribution.
Reference Application: A suite of modules/apps/content that serves as the foundation for our Community Distribution, the context in which people picture designing community-shared modules and the context in which our Community Distribution evolves, what runs at demo.openmrs.org, and the sandbox in which we can demonstrate new capabilities & best practices. When the Community Distribution matures, the need for the Reference Application may disappear. But until we have a Community Distribution, the Reference Application is the context in which community modules would be developed & shared.
Web Application Framework: A skinnable, modular web application foundation, including templates, CSS conventions, style guide, re-usable components & portlets, “apps” page, default clinician-facing patient dashboard, and any other UI elements/pages we expect to be widely shared. This is the piece for which we have to choose a direction: continue GSPs like Mierbalais/OpenMRS 2.0 UI (meh), Angular against REST (more likely), roll our own vs. start with Bahmni and refactor, or some other technology (Sunny’s latest favorite web component library), etc. Whatever we choose, not everyone will be using this layer and the layers above.
Web Framework: Thin web layer providing login page, module & OWA admin, admin functions, and system info page(s). Provides lightweight administration of the platform. Everyone runs it, some may not use it or would keep it hidden like the Legacy UI is often used now. This is the light weight framework that, in our 2016 objectives, we assumed could be subsumed into the Platform.
Platform: Database + API + Web Services + Platform Modules (a growing list of modules that have minimal UI assumptions and used by everyone, starting with serialization, expanding to include idgen & reporting engine, and eventually things like our CDS engine).
+1. Much of this could be incorporated in the Platform (as it subsumes a lightweight web framework). Another example:
The openmrs.js library @pascal has mentioned building (e.g., bower install openmrs) as a native javascript library that brings the OpenMRS API and convenience functions into the client, could easily be wrapped into an ng-openmrs library for AngularJS.
I’d like to support Darius’s breakdown of concepts – it appears to cover
all of the different elements we discussed on Thursday.
My only concern about Burke’s note is that I don’t quite see where the
Reusable Best-Practice Components fit in. They would not necessarily be
used by all implementations, and they do not necessarily have to be in the
community distribution. RBPCs may be in there, but I’m not quite finding
it. I join with those who believe it is very important to
specifically include RBPCs in an objective.
I also see some differences among these responses about whether the web
application framework contains standard UI conventions, style sheets, etc.
some responders mentioned this, while others’ responses didn’t appear to
include it. I would vote for including standard UI conventions.
Here is my final suggested revision to Strategic Objective 1 and 2 (thanks to everyone for the revisions!):
Develop and evolve the foundational technical products of our community:
common platforms and frameworks to simplify development of any person-centric record system
reusable best-practice components to speed up development of high quality implementations for common scenarios
Develop and evolve a pre-configured electronic medical record application meant to be used directly in health delivery settings through a community involved process.
We will stand down on naming conventions at this point in time.
Thanks to everyone for their input. @terry and others are working towards changes in the operation plan based upon this shifting of work (i.e., some things in objective 2 need to be moved to 1, etc).
I also think there’s a need to spend more time being clear on #2 (i.e., who will volunteer to “own” the objective, and steer questions around the target audience, etc etc.)
It’s not okay for us to use “OpenMRS Core” to refer to something different from what’s in the openmrs-core github repository, and we shouldn’t change “OpenMRS Platform” to mean something other than what we’ve invested the last 2 years making it mean.
