Excellent comment @lars.lindskold! Completely agree and very stimulating indeed. In a discussion with @jpieraj about this, we got to the point that a good start could be that the forms adapt to: who I have in front of me (the patient: its conditions, medication etc…), who am I (the healthcare provider: my specialty etc…) and the setting (where the encounter is happening). AI can definitely help with this fluidity but also old school logic if the information needed is there. At the end, is probably the combination and integration of CDS (clinical decision support) tools with the forms to capture and follow the care process. If an EHR is capable of swift integration and can adapt to different contexts in real time, it’s a winner!
1 Like
Using AI to assess and help develop forms is a complete no-brainer in my mind, but having AI in the loop in certain ways while completing a form (as opposed to simply completing a good prose journal entry) worries me.
The point about a form is that it fixes requirements and place in workflow - it captures background meta- and master-data, helps the user to working out if the form is appropriate to complete, ensures essential data for the encounter is captured in a representation that can be reused, and then allows the user to state - in a structured way - what kind of activity should follow either by explicit statement or by classifying the case for a workflow engine. It then provides a transaction that can be signed by the completer in their professional capacity.
Having active AI in the loop risks spoiling the contract implied by 'I answered this form as recommended by {insert approving body here} and discharged my responsibility.
For the record, Dipak Kalra is talking about some of these requirements right now in a TC215 working group meeting
He is explicitly asking for information requirements of an EHR system - I think this thread is a significant contribution. Would be good if openEHR community members could contribute through their ISO/CEN member body.
1 Like
A big problem has been that traditional form builder products just capture data, and are very poor at displaying or updating existing background or persistent data. If you are lucky they might allow you to copy through data from an existing form but that is just a hack. In the London UCP we have been using an approach which allows multiple templates to site behind a single ‘form’ . So for example if a sickle cell care plan ‘form’ expects to be able to see and perhaps add to the patient’s allergy list , that can be supported. The form interacts with both the core contextual sickle cell pan and the global allergies list.
This fits with @SteveHarris view that a form is more than just a data capture tool - it represents a workspace and a clear exposition what a user is expected to do.
I’m doing a session on the ideas above at the EhrCon conference at Reading but there’s a wee wiki on the thinking behnd it here as a preview!
6 Likes
More for the record:-)
You can tune in at lunch today to hear more about Dipak’s thoughts, visit a lunch webinar arranged by the Swedish Association of Medical Informatics, host of the OpenEHR initiative in Sweden—Starts at 12.10 Swedish time – Welcome.
Read more at Linkedin: https://www.linkedin.com/posts/lindskold_join-conversation-activity-7254845086646050816-oT0x?utm_source=share&utm_medium=member_desktop
2 Likes