Hello everyone,
Today, I want to delve into Clinical Views in OpenMRS.
This development is particularly notable for its potential to significantly streamline and enhance the responsiveness of our programmatic needs.
The Challenge: Navigating Form Overload
In the realm of clinical practice, one common challenge is the sheer volume of forms clinicians must navigate.
When faced with a list of forms, it can be overwhelming and time-consuming for a clinician to determine which form to use for a particular patient encounter or workflow. This can lead to inefficiencies and even errors, as the wrong form might be selected or critical data might be overlooked.
The Solution: Introducing Clinical Views
TAP-UCSF has addressed this issue ingeniously by introducing Clinical Views within OpenMRS. This design paradigm has already been utilised by implementers such as Palladium in Kenya, Namibia, and ICAP in Ethiopia.
But what exactly are Clinical Views?
Grouping Workflows LogicallyClinical Views allow implementers to group program-specific workflows in a logical and intuitive manner.
This means that instead of presenting clinicians with a long, unstructured list of forms, Clinical Views categorize and organize forms based on specific clinical programs or workflows. For instance, a clinician working in a maternal health program would see forms related specifically to prenatal visits, delivery, and postnatal care grouped together. This logical grouping simplifies the decision-making process, making it easier and faster for clinicians to find and complete the appropriate forms.
Launching Forms with Intents
Another key feature of Clinical Views is the ability to launch forms using intents. Intents are a powerful tool that allow the same form to be rendered with different business rules, depending on the clinician’s intention. For example, a single patient visit form could be adapted dynamically based on whether the clinician is conducting a routine check-up, a follow-up visit, or an urgent care assessment. This adaptability ensures that the form captures relevant information tailored to the specific context of the patient encounter.
The form intents are defined in the JSON form schema and supported by the react form engine.
Rendering of the same form for retrospective data entry where there may be missing data elements on the primary record.
Benefits of Clinical Views
- Enhanced Efficiency: Clinicians spend less time searching for the correct form and more time providing patient care.
- Reduced Errors: Logical grouping and context-specific rendering minimize the risk of selecting the wrong form or missing crucial data.
- Improved User Experience: An intuitive and streamlined interface makes it easier for clinicians to navigate the system, leading to higher satisfaction and better adoption rates.
- Scalability: Clinical Views can be customised and expanded to accommodate various programs and workflows, making them a flexible solution for diverse healthcare settings.
How Clinical Views are being used
EthiOHRI in Ethiopia
PTracker in Namibia
KenyaEMR in Kenya
Conclusion
The introduction of Clinical Views in OpenMRS can be a game-changer for healthcare providers, offering a practical and elegant solution to the problem of form overload. By grouping workflows logically and enabling forms to adapt based on clinician intent, we can create a more efficient, accurate, and user-friendly experience for our healthcare professionals. This, in turn, leads to better patient care and more streamlined healthcare delivery.
BUT, What currently exists to support this?
If you all remember couples of months ago @mksd started the content packages templates post and on my intervention I somehow described how UCSF implemented content packages and shared the library behind this support.
From the date of the post we have had in the community a few discussions about the possibility of making the Clinical Views Workflow configurable and as I stated and proposed that this, similarly to how the Form Engine works, could leverage from a JSON Schema (configuration) and an Engine to render the JSON.
Good news 
We have embraced this idea and experimented and out of this experiment we can tell that we proud of the results: hundreds of lines of code reduced to a simple json configuration.
This post is already long, so I would like to request we discuss this on one of the upcoming MFE or TAC calls next week (to allow reflections and comments on this post). The agenda would be:
- Clinical Views in OpenMRs, to gather inputs from the different implementers that are interested on this feature and how should this be implemented, is the PoC we have enough, if not what should be added, etc;
- Moving the “ohri-commons-lib” to OpenMRS, similarly to what was done with the
react-form-engineandmamba-etl. To eliminate duplicated efforts on building the same things within the different implementers.
@grace if possible we are happy to Demo this on the next MFE call just to give an idea on how things are looking like, I believe that might help to give more context.
@dagimm @ICAPEthiopia @UCSF @michaelbontyes @grace @mksrom @PIH @METS @PalladiumKenya