Even though there is basic support to have an HFE form useable in an O3 interface (opens the HFE form in a new tab), this was meant to be a temporary measure for orgs who want to start using O3 in production but don’t have time to change their 10’s or 100’s or 1000’s of HFE forms into O3 forms. But, at some point, this work is still needed - so we’ve been wanting to help automate this conversion where possible.
Kudos to @aojwang & @kmakombe at Palladium-Kenya, who as of this week have started planning the script to help convert HFE form schemas to O3 form schemas - at least to some degree. If we can automate even some percentage of the effort, this is still useful for implementers, and is something @eudson and the UCSF @OHRI team were already thinking about.
Thanks @grace for this post. We are currently using forms in KenyaEMR to help guide the process. This will limit us, at least in the beginning, to the html tags used in our forms. This can then be expanded to support the common tags supported by html form entry module.
The idea is to have a basic JSON schema for every HTLM form which can then undergo cleanup and proper validation checks.
Update from @aojwang’s work as of today: The schema migration seems to work! He has done a small prototype for KenyaEMR HFE forms and below is a sample questions list for the form.
I am so excited because what we have already in this prototype relieves us from having to type so much for the question concepts and answers (for coded obs). We can render date, text, numeric, coded obs. Next I will handle obsGroup which I think is simple right now.
We’ll share more details next week!
Payload example below. Of course it still needs some work and they will continue to iterate.
Sorry I haven’t updated our progress for a while now. We managed to move over 50 forms last week where the automated schema migration script/code played a key role. Although not perfect, it is able to provide for over 60% of what would have been done manually. The automation is currently able to do the following:
Generate appropriate json for obs and obsgroup tags - coded, text(area), date, boolean, diagnosis
Repeating groups
Group coded obs (checkboxes) defined using same conceptId but different answer concept
Extract question labels from inline obs labelText attribute, text before or after obs tag, or any preceding td if obs tag is within a td. This is common in our forms but can be expanded to handle any common practices
Extract answer labels from obs answer label(s) or concept names if explicit label(s) are not provided
Pick obs id as defined in the schema
We had to modify the html schema to guarantee a complete and well descriptive json schema for certain forms. This was important in cases where the conversion logic couldn’t find appropriate label for a group or obs hence requiring for a manual fix. For a quick turnaround time, we updated the script so that it is able to read html forms from a configurable directory outside of OpenMRS.
@slubwama I am happy to take you through what we have done so far. We can plan with next week if that’s OK with you.
@aojwang / @slubwama can I humbly ask that when you walk through this together, could you use this zoom link, so that it automatically records for others to watch? (If that’s okay w/ you of course): Launch Meeting - Zoom
@aojwang thanks for the offer for a work through. @grace we could organise this a virtual event that may help all the current implementers who are using html form entry
In case folks are now trying to better understand or leverage this migration script, here is the video recording from last year where @aojwang gave a helpful deep-dive into this HFE to O3 Schema migration tool:
Here are some times that would work on the OMRS Community Calendar.