We clinicians expect a lot from our electronic health records (EHR), & so we should.
Yet I am surprised at how remarkably passive we, as a group, are about the structure & quality of the data that underpins it.
- Does it store the data we need?
- Can it be utilized for decision support.
- Will it support our research?
- Can it easily be shared?
Most of us don't know - we just don't tend to look 'under the bonnet'.
Yet we are undeniably clinical domain experts. We also understand what information we need for providing patient care & our research. What if our systems don't capture what we need or in the optimal way for us to use?
We need to ensure that all our efforts to conscientiously enter good patient data is reflected in the underlying data structure - that our clinical data is 'fit for purpose'.
It is important to understand & acknowledge that there are many ways to represent the same data, and not all are equivalent! We need those trained as both clinicians & informaticians to be intimately involved in developing high quality eHealth tools. Clinician informaticians provide the critical link between our software engineers & our grassroots clinician experts.
Have you ever considered how the data in our systems is designed? What is the process? What is the criteria for 'quality'?
I have seen many examples of clinical information requirements that have been gathered 'with extensive stakeholder engagement'. OK, but when you enquire who gathered the requirements it is not always (& sadly, most often not) a clinician informatician who has asked the questions. I have to ask the question. If you are not a clinician & don't understand how health data is going to be used (content, processes, reference models, querying, use of terminologies etc), how can you ask a reference group the right questions in the first place & ensure that you have the right answers? The chances of the reference group consisting of clinician informaticians to spoon feed you the right information is pretty slim. So by my reckoning there may be a significant risk of 'the blind leading the blind' syndrome occurring in this not uncommon scenario. Learning point: Always question the credentials of the initial data requirements!
On a number of occasions I have been shown some data requirements for core archetype modeling - problem/diagnosis, adverse reactions, medication orders & the like. It is frequently clear they have been developed by a technical analyst with very little clinician informatician input. Turning these requirements into an archetype is not an issue, however I have concerns that my 'fit for clinical use' criteria will not be met. They might be perfect for reporting back to government, but for clinical care, decision support, research, sharing etc... maybe not so good, yet they are being created for use in desktop clinical EHRs.
Interestingly in openEHR training sessions I have supplied a set of clinical requirements for an archetype to participants, encouraging them to break into mixed teams of both clinicians & technicians to try their hand at collectively building their first archetype. Not so surprisingly, they most often split into clearly demarcated technical & clinical groups - no cross-pollination at all;-). Despite being presented with the same requirements, inevitably both groups tend to represent the data quite differently - clinicians intuitively represent it the way they know it & need it; the technicians making a best guess based on their incidental domain knowledge.
When I train people in how to build archetypes, I always state that the best archetypes - by that I mean 'fit for purpose' - are those built by clinician informaticians. Next best are those built in close collaboration with clinician experts, preferably staring over their shoulder & offering feedback in real time! Lastly, those built by technical modelers with little or no direct domain understanding. (Unfortunately, by far the most modelers that are in the employ of our national eHealth programs & large vendors are in the latter category.)
I have seen surprisingly bad archetyping efforts by very proficient technical modelers, largely just because they don't understand the clinical context. In most instances, a spreadsheet or UML diagram of requirements just isn't enough. On many occasions over the past few years I have found that their idea of a clinical concept is often quite different to that of a clinician - not unexpected really!
My conclusion - clinical experience matters!
Health informaticians are few on the ground. Clinician informaticians are even fewer. We need a transformational approach to EHR development - working smarter & more efficiently. Clinician informaticians are critical to ensure the development of shareable, 'fit for purpose' clinical content specifications as a solid foundation for good quality health data, both within & for sharing between systems.