OpenMRS 3 R&D - Discussions


(Jonathan Teich) #21

@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.


(Cynthia Antwi) #22

Hi @jteich Yes that is possible, and I have also provided a doodle poll for those who may be interested to attend this discussion here:

Thanks


(Cynthia Antwi) #23

I completely agree.

In addition, I would like to add clinical decision support as part of the new functionalities, at least a good MVP .


(Jonathan Teich) #24

Yes, I’d hope that clinical decision support would be a great candidate to be one of those reusable core components.


(Nathan Ruhanga) #25

Thank you @everyone for the great thoughts :slightly_smiling_face:

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.


(tendo kiiza Martyn) #26

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).


(Andrew Kanter) #27

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). :slight_smile:


(Jonathan Teich) #28

+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.


(Cynthia Antwi) #29

I will go ahead and schedule the meeting for February 25th if that is ok for everyone.


(Gregory Schmidt) #30

Hi @tendomart & @ruhanga - I agree!

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!


(Moses Mutesasira) #31

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 :slightly_smiling_face: 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 :smiley:when working on issues

(tendo kiiza Martyn) #32

@gschmidt Alright


(Gregory Schmidt) #33

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.

Anyone have experience or links to open-source communities that implemented microservices? This recent ResearchGate thread Do you know any Open Source project that migrated form a monolithic architecture to microservices? has the answer of: No.

Also - anyone in the community have experience with Event-Sourcing or CQRS? They increase complexity, but may be well suited to EHR environments.

cc @burke @darius


(tendo kiiza Martyn) #34

some work was done at https://addons.openmrs.org/ by @reubenv but am not yet sure of it’s implementation in the Platform , refapp or modules .


(Cynthia Antwi) #35

Good Morning to All

I just wanted to confirm whether we are good to go for Monday 25th of February Design Call?


(Daniel Kayiwa) #36

@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.


(Gregory Schmidt) #37

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.

cc @fali @jdick


(Gregory Schmidt) #38

Web Components

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