I heard many times that auto-generated forms in CKM were tried before but didn’t work. It was never explained why. Maybe this was good since I kept working on generating forms from OPTs without knowing that it cannot be done.
I just published my first demo version that runs in a web browser: web demo
This version isn’t ready for data entry into a CDR but it might be all that is needed for clinical modelers to visualize their archetypes. To some it is easier to understand an archetype through a form.
Only a single line of HTML is needed to run the form in a CKM tab:
<iframe src="https://example.com/demo"></iframe>
Is any CKM provider interested in integrating my little forms into their solution?
Very nice start from a technical point of view. The current interaction flow and lack of overview (too many subpages) and RM-detail-exposing headings would be extremely confusing to a clinician though, but can be fixed. It took some time before I understood how to get to the actual forms and start adding data.
Of course, we can have many discussions about technology used, the general approach, UI design and whether it makes sense / is sufficient to have GUIs that are generated in a completely automated fashion - or how much customisation is required (think 120/80 representation for BP) and where this is supposed to occur to best separate and manage/maintain it. (In that paper we superimpose specific snippets for specific elements over a generically generated default).
In CKM, we use a simple form-like view as the default view for each template. The devil, as always, is in the detail and this can of course be improved but its generation is completely automated (and can also pull in value sets from external terminology servers on the fly). And while there are better technical ways, we could also just wrap each archetype in a template to get the same form-like view more or less for free for archetypes.
More importantly to me, we do not always want to foster the assumption of an archetype <-> form equivalent. For templates, the logical disconnect is at least considerably smaller. The mind map view of an archetype in CKM is another automatically generated representation that clinicians seem to relate to quite well as an alternative to get their heads around one particular clinical concept.
Maybe I misunderstood and it was meant that “only” the forms UI cannot be standardized
I found this in the old Confluence discussion. I have it on my todo. For the first version I decided to go with two separate fields as defined in ADL. It would be great to have a DV_BLOOD_PRESSURE which would directly translate into a widget/component (just kidding )
If CKM is not the right place for these forms I have a more complex use case I could work on:
Would this be a good use for the generated forms?
Generated parts can be used alongside more specific “dashboard” like views in an application used by clinicians. I’ll write how the generated code is structured and used.
p.s.
I’ll appreciate guidance from somebody with clinical experience. I don’t want to get hospitalised just to gather requirements
Screenshot of the prototype shows that fields from different RM data items are presented on the same page (State and Protocol beneath the Systolic/Diastolic fields).
My initial forms have used separate pages for each RM ITEM_STRUCTURE. I’ll follow your example in the next version.
I’m wondering whether to also show fields for attributes such as “accuracy”. Are they entered every time? Or should they be revealed only after clicking e.g. “more” button?
I agree with this statement. And happy to report I actually use on a daily basis the form view for templates (in our Nedap editor) and the CKM mindmap for archetypes.
I’d be willing to provide clinical / ux guidance. But if you’re looking for business opportunities I’m not the best expert I guess. I do think there’s value in an open source frontend component that renders data input (and visualisation). But there’s already some opensource work from Better and medblocks. Where you’re work shines is in the fully generated code. So maybe a backend library or integration solution is interesting? But again, not an expert here, just sharing my braindump
Regarding the blood pressure I wouldn’t spend too much time on it, since I believe the visualisations of 2 related values to describe the same clinical concept is quite unique and very challenging from a design perspective imho.
The better widget looks nice, but I’m missing the main things: reference values, trends, and relation to other data like pulse, medication changes, fluid suppletion etc. again the challenge here is mostly in visual design.
While your strengths imho are in code generation and there’s a lot to do there! The main challenge I can think of that you could be invaluable for is to lower the barrier of entry for ‘new’ people to work with openEHR data. By letting people work with it in their own language/framework. How to make that (financially) sustainable is another question however.
Everything that I generate is provided with the source code with all the benefits of the open source. But most people don’t care about the source code - they want to get it free.
A project such as openEHR has a community that is too small to sustain free open source projects. I’m glad that Nedap, vitagroup, Better, Medblocks,… offer part of their work as open source. They use their commercial offerings to pay for the open source stuff. Even they cannot offer everything as free open source.
I on the other hand am a single person who found openEHR interesting and wanted to contribute. I’m sad that my contributions are treated differently because I can’t offer them for free. I mentioned that I would be willing to offer them at-cost (or as a non-profit), but many people feel that FREE is the only acceptable option.
I know Borut, and I’m trying to help you find a way for you to get paid for the valuable work you’re doing. I’m not trying to treat you differently, and certainly don’t think your work should be free as in unpaid. I’m just trying to help by sharing where I think your work has the most value to offer. But if you like clinical guidance in another way, please let me know, I can try to adept my feedback:)
Many other (realistic) people have no problem with paying for good work. You should never think that the openEHR community has any view on open source other than this: it is good when it is financially viable.
I have no doubt that you will find such support from any one of a number of vendor and possibly even procuring organisations, just requires a little patience.
Yes, certainly agree. It is a bit tempting to think otherwise because BP always tends to be one of the first examples most people can relate to, but in terms of requirements for “perfect” form generation it is probably the odd one out.
I would be surprised if people would want to enter this each time (probably never), as far as I can see it’s either automated or won’t be captured.
More generally re the paper I mentioned: It may have been the first of its kind, but it is certainly not like the time has stopped since 2006 (I wish!).
)
