OHRI Milestone: Combined OHRI+3.x RefApp completed; next step is to test!

, ,

An environment that combines the 3.x RefApp with the OHRI Package is now up on https://ohri.o3.openmrs.org/openmrs/spa

Code: GitHub - openmrs/openmrs-distro-referenceapplication at 3.x-ohri

Many thanks to @alaboso, @amugume, & @dkayiwa who got this up & working. Also thanks to @ibacher for helping us define and start work on this idea.

Why did we do this? We needed a place where the 3.x RefApp and the OHRI package are stuck together, to test - like an example of a distribution adding the OHRI package.

Other key points

1. See Microfrontend Apps (widgets/extensions etc) come together in the distro.properties file

  • In the distro.properties file you can see evidence both of shared 3.x widgets (esm apps from @openmrs repos) being used, as well as OHRI-package-specific widgets like esm-ohri-covid-app.
  • There is still work to do to further extract helpful functions/features from esm-ohri-core-app (shown below) (eg. the clinical dashboards/perspectives) but we’re definitely heading in the right direction in terms of breaking things down into explicit microfrontends (which is a key 3.x Framework technical convention). I’m really grateful to OHRI dev team lead @eudson for his shared commitment to this vision.

2. Config, config, config!

You can see the config and shared use of Initializer coming to life in the config file.

  • It also looks like we pulled in the demohivconcepts from the 3.x RefApp - so we have accidentally created a perfect situation to test what might happen where there can inadvertently be clashing concepts. (@ibacher this is also making me think we should officially move the RefApp demo metadata explicitly outside of the RefApp; I think you and I talked about that at some point?)
  • The massive Ampath HIV Adult Return Visit form was also included; this will allow us to confirm what happens when a form built for the Ampath Form Engine is included in a distro that also has the OHRI Form Engine.
  • @alaboso & @eudson I’m very interested: How does the OHRI package pull in concepts from OCL - what approach are you using now?

What’s Next?

Using this 3.x RefApp + OHRI Package environment, we need to confirm that the following elements, if completed by a user in the OHRI package / OHRI widgets, are also accessible through the General Patient Chart in the relevant area:

  • Forms (options and historical content)
  • Conditions
  • Lab tests (orders and results)
  • Vaccinations
  • Enrollments (options and history)
  • Medications (orders and history)

@mwariri & @christine & I need to break this down into who does what. Hope is that we can combine a UCSF and an OMRS resource to work through these manual checks together.

+1 great to see the default config becoming fluffier.

This config will be the one that Ozone inherits, so give us some time and we at @Mekom will provide feedback about it.

1 Like