@bharatak Awesome!!
Just to point out explicitly, as this is a complete rewrite, any existing data integrity checks/rules that youâd have in prior versions of the dataintegrity module would be lost when moving to this new version. (And thatâs okay, right?)
@darius yes, that is correct. That is why I have also asked for a version bump from 3.0-SNAPSHOT to 4.0-SNAPSHOT which illustrates a non-compatible change. While leaving the 3.x versions on their own branch
@bharatak, I feel like you are onto something more important than it seems here. Developing features so that not only the module but its UI is shipped as âdistribution independentâ (albeit perhaps primarily aimed at Bahmni in the case of the Data Quality Dashboard) should ideally be part of OpenMRS development guidelines.
On the OMOD side, we have made our new VDUI module as a set of UI components (Angular components) because we knew that we would port this to Bahmni eventually. However we wanted it to be Ref App friendly for starters. So right now we have got a few GSP pages and fragments that just wrap those components to get it all going where it has to within the Ref App. But since we have Angular components, we would be really interested to see how this has to be organised (perhaps using OWA as you said) so that we get as close as possible to a situation where the module can be installed on either the Ref App or Bahmni and just functions in both.
We would be more than happy to contribute, perhaps document in the wiki as it goes⊠etc.
Anyone, thoughts, suggestions?
Hi @mksd,
- Personally, I think that the distros should be able to accommodate new apps and that way we benefit mutually from the community.
- There could be some sort of cross cutting concerns like Authentication and authorization that needs to be taken care. I think sometimes they are very specific to the distros. Things on server side can be managed inside the OMOD (using Context.isAuthenticated() or @Authorized annotation etc). But on client side it becomes difficult across distros.
- Its also a good idea to have components (like angular directives or react components) instead of apps and distros provide some sort of container for hosting these components with a simple glue might help for more reusables to be developed.
Regarding your questions around standard guidelines from OpenMRS, I am not sure about it. I see OWA as one way. Iâll leave it to senior openmrs contributors to answer that question.
Just created a pull request with latest data-integrity code as 4.0-SNAPSHOT.
@sdeepak Thanks for turning this around so quickly - I have merged the PR. @bharatak is there any documentation to provide examples of rules that can be built? I would like this to support those including our team to write rules using this module
Hi @ssmusoke, The documentation for this feature is available here. This package has some rules coded for endtb project.
Please let us know if is sufficient.
@bharatak The documentation is for setting up the module, what I was looking for are how to write some rules - missing obs data, invalid obs data etc - simple examples to get one started. For example if a patient is 5 years old and pregnant, or a 7 year old male on IUD family planning, a pregnant male etc
Sure. Will write something and ping you the URL.
1 Like
Dmitri, you are right to highlight this is one of the most important issues facing openmrs at this point.
Setting a good precedent for how developers for didistributions like Bahmni can create functionality that will work in other user interfaces could make or break our ability to collaborate in the future. Since you are actively interested in both the reference application and Bahmni, perhaps you can dedicate some brain cycles to suggesting how shared components can be written, and to reviewing what Bharat and his team put out.
It is clear that the Platform is calling for the ability to plug any UI onto the OpenMRS backend, and it feels that both the Ref App and Bahmni should comply to this new paradigm as much as possible. In other words, we should have some sort of big picture MVC pattern where the Ref App and Bahmni are just two different views and it would be awesome if we could ever swap the viewsâŠ
I could definitely think through this a lot more yes when comes the time to migrate VDUI into Bahmni. This is not exactly current yet though⊠The only thing I knew, was that ensuring that a UI made of Angular components would eventually make it easier to move things around (simply based on the UI Commons model basically.)
Hi @ssmusoke Very sorry for the delay. Held up in some meetings last week. Will create some examples and provide them by this Friday. Hope that is fine. Thank you.
Hi @ssmusoke, We have created around 4 sample DQ rules. Its available at the wiki here.
Invalid Date Of Death Invalid Observations Invalid Program Enrollment
@ssmusoke The OMOD will add an OpenMRS scheduler task. You can tweak it to run at your interested frequency. Once the results are available, you can have a look at dataintegrity_result table. If you are using Bahmni, you can use the UI for viewing it.
@bharatak any plans to add a basic Ref App page to run different rules and show results within the omod? So that the module has basic self contained functionality
1 Like