@paul, @darius and others, definitely agree with making this something that is clear and that moves easily from discussion to practical reality. One of the artifacts forming the basis of the discussions so far among @gschmidt, @tgreensweig and (to a more modest extent) me is a collection of thoughts about how this breaks down into categories. That also reflects some of the larger-group discussions in Nairobi, and is still being collected; that will inform both what the big picture is and what the starting point is.
If I were to make an elevator summary at this early point, Iād say that there is a focus on modularity, sharing good work from site to site, and trying to provide a small number of core elements (platform, functional, UX, etc.) that can be assembled and reassembled to solve a large number of end-user needs. That means that the problem space has to balloon out for a while to understand its scope, but then fairly quickly has to come back to one or two pieces of demonstration work. I know there was discussion in Nairobi about two starter projects, and that may still pan out ā one way or another, a concept this large has to start with a small demonstration of what weāre talking about that people can participate in, look at and understand the direction.
I have a management-approach opinion on what Iād like to be achievable with OpenMRS 3.0. This is mostly connected with modules but generally affects the whole project.
Currently, there is barely a way to let a given module, say Module-A, that depends on Module-B, know about changes (which may include new features, bug fixes or code modification among others) made on Module-B. Apparently, Module-A will keep depending on the older version until need arises to depend on new version of Module-B, which may have gone through series of evolution. At this point, it is natural to rely on luck, hoping nothing breaks when dependency versions are switched to newer ones
Way foward
Adaptability in programming of existing modules to depend on newer/currently stable versions of their counterparts. This may require a huge leap into refactoring dependencies for some of the existing modules and resolving breakages for a start. This when achieved and coupled with thorough documentation will help implementers and developers know what pieces fits just fine and not get stuck at any one instance. Versioning and knowing what bits work together smoothly will be simplified.
Strict compatibility requirements in code developments and maintenance of modules or different pieces making up OpenMRS will need to be encouraged with guaranteed downwards/backwards compatibility in mind. This is adapted for some of the existing modules but can be of great help if adopted for all vital modules. This implies that any dependency can be updated to newer version at any time without breaking anything. This may involve coming up with a way of test running changes of a module against existing and current versions of modules that depend on it.
These I suppose will systematically encourage and strengthen consistency and robustness of OpenMRS 3.0.
Way to go @ruhanga , iād love to see this in the **OpenMRS 3.0 ** oh and how i wish it could also incorporate warning triggers to the user of what could happen to the system if Module B was missing and vise versa ,that would save users a great deal of time trying to deal with a broken system just because of outdated / missing module/s (dependencies).
I think this is a wonderful discussion and look forward to the first call about it. Next week is HIMSS, however, so that is going to be difficult. Hopefully the 18th works for folks. As for the topics, not only did we always assume that re-use and modularization would require a standards-based and common information model (shared content and metadata) but that we would create a platform for sharing content and metadata. The concept dictionary and OCL is just the first part of that process. Producing more shared content on the form/query/analytics front would be an important discussion point.
Iād also want to be sure that whatever step(s) we undertook as part of this ambitious goal, that the steps are driven by real user needs and folks willing to contribute time/money/resources to make it happen (and benefit from the results).
+100 to that, @akanter. Itās so much more fun doing work that will actually be used and valued and helpful.
@gschmidt and @tgreensweig and I are making good progress in our work, but we would like a little more time to assemble and filter our thoughts to make the most useful group forum. Weād like to suggest moving this topic to the design forum on Monday Feb. 25, if that works for others, or any time after that.
Iām working on a demo architecture trying understand how to decompose an EHR (front end, and back-end parts) into functional components (micro-services).
As you mentioned, the tricky part is trying to understand the boundaries and required interactions and events between services.
Ideally, if the interactions & events between services were standardized (ideally following existing International Standards, or helping lead development of such standards) anyone could build a service and easily swap or add it in the EHR without breaking dependant modules.
If anyone has any resources or ideas on this, please get in contact!
I would also love to bring up this opinion.
As far as I know , currently for all our wepp apps that consume the rest endpoints, we currently use server sessions for Authentication.
Using JWT for Authentication rather than Server Session For OWAs
I would suggest we can instead use
JWT Authentication rather than Server Session based Authentication.
The Advantage is JWTs completely keep session state on the client side and removes the dependence on the server side sessions ,hence the OWA doesnāt have to hit the server for Authentication ā¦this will seem to save time when Authenticating.
Another opinion
Complete module development in Python
One of our goals is to increase on the resources we have in Open-MRS especially Developers. Could there be anyway we can incorporate in complete module development in languages like Python that are very significant on the market?..I know that will require heavy code refactoring in the coreā¦
Because I understand majority of young developers coming up on the market are more comfortable with languages that have simpler syntax to use and less configurations when it comes to web application development
If thats possible ā¦we could attract alot of new developers on the boardā¦
Regarding code quality
Adding the codacy badge to improve code quality
I understand we have code conventions to guide the quality of how code is written. I would also suggest that to improve more on our code quality , we start adding the codacy badge on our repos ,this will greatly help guide much on how code is written, putting in factors like the maximum lines of code a method should have , avoiding over-nesting the āifā statement etc .
At the end of the day it will greatly improve code Readability , which will help make worker easier for newbies like me when working on issues
Hi - Microservices may help. Although they bring with them a lot of new difficulties. One of the benefits is language-agnostic services. In theory, if people wanted to write a new version of an existing service, or a new service, in Python they could do so.
Further, decomposing the code into loosely coupled functional units reduces its size, and makes it easier to come into a project & understand how a piece works.
@gschmidt i have not had a chance to learn from the experience of some one who has used Event Sourcing and or CQRS in the EMR/EHR domain. But i have read this paper: https://www.infoq.com/articles/healthcare-emr-ehr whose recommendation i liked and will put it below:
The entire EMR/EHR application architecture, especially in a large distributed implementation, need not be CQRS and ES. Rather, CQRS and ES should be used where there is a clear benefit given the healthcare tasks involved.
Hi I agree, the entire platform shouldnāt be ES & CQRS.
There may be benefit in a CQRS model in populating the UI with patient data. We use CQRS at AMPATH to populate the Angular framework, and it seems to work well.
Re ES, we use a version of event based architecture (though not event-sourced architecture) with Apache Spark & Kafka in automating updates of some of the tables used in CQRS & analytics.
I havenāt seen true event-sourced architecture in an EHR before.
Web components in theory may help create common, reusable, modular, UX components across application frameworks.
However, React still has trouble handling web component events, and requires that the component is placed in a React wrapper. https://custom-elements-everywhere.com/
Anyone tried using them in the last 6-12 months? Or know of any developers using them in their systems? Its a shame they donāt play smoothly with React atm
when working on issues