Ever struggled to make sense of past visits in OpenMRS – hunting through orphaned labels, free-text snippets and layouts that don’t match the original form? Clinicians end up spending extra minutes just to rediscover context that should be front and center.
Figure 1. The Patient Visit Form as it is being completed.
Figure 2. Patient Visit Form: Encounter Summary
SolDevelo and MSF are on a mission to fix that by embedding each encounter’s original form – fully rendered in true read-only mode – right on the patient summary page. Here’s what we gain:
– Instant familiarity: section headings, question groups and coded answers appear exactly as they did at data entry
– Context-rich reviews: every field stays in place, no more hunting
– Reduced cognitive load: clinicians absorb patient history in a single glance
Our trick? Leveraging the Form Engine’s existing View Mode and Embedded View so we don’t reinvent the wheel. The one speed bump we’re tackling now is HTMLFormEntry encounters; if you’ve wrestled with HFE normalization, please share your insights, thoughts or any tips you’ve picked up.
First and foremost, what do you think of the core idea – embedding forms inline on the summary page? Any objections, concerns or missing use cases we should consider? Feel free to share war stories, code snippets, GitHub issues or quick pointers in the comments below.
Thank you in advance for your valuable input. Have a great day!
Thanks to community input and feedback on Slack, we’ve created an Epic on the MRS Jira board [LINK]. It shows the current status and includes tickets to fix questions in the wrong order and labels that got left out in all encounter forms.
Once again, a huge thank-you to everyone involved!
To handle HTMLFormEntry (HFE) encounters consistently, we could develop a lightweight HFE-to-JSON adapter that:
Parses HFE’s rendered HTML into a structured schema (using DOM traversal or a predefined mapping)
Leverages the existing Form Engine’s embedded-view for rendering, ensuring UI consistency
Falls back to the legacy Obs table if parsing fails (progressive enhancement)
This avoids iframes for most cases while reusing O3’s React components. For forms like Vitals, we could extend this with specialized renderers (e.g., a <VitalsSummaryView/>). Would this align with the core goals?
As with anything with HFE, the problem is that we can only ever convert the structured elements (i.e., the HFE-specific tags). But the point of HFE as a form engine is that you can build arbitrary HTML with just some special tags that get rendered and processed in specific ways, meaning that any such conversion is always going to lose information. This is why the iframe approach is simpler and more expedient; HFE user’s can continue to get the full benefits of HFE and we don’t need to maintain yet another tool that’s of fairly limited value.
thanks @ibacher, you make an excellent point about HFE’s arbitrary HTML making full conversion impractical. Thought about this compromise: We use sandboxed iframes as the primary solution (preserving all HFE functionality), but add lightweight client-side detection for forms using only standard tags, these we could safely render natively via the Form Engine. This gives us the best of both worlds: no loss of functionality for complex forms, while allowing optimized rendering for simpler cases.
