Within Dutch healthcare IT, the notion that we need a separation between healthcare data and applications is increasingly embraced. Governing bodies are exploring the role the internationally supported and developed openEHR specifications can play in this regard - a good development. One topic that does need to be on the agenda where this is concerned, is openEHR governance. What does this entail, why is it important and how can we organise it?
Nictiz defines IT governance as "a system by which the current and future use of IT is guided and controlled". A practical definition. For a picture of the impact of governance, we would like to refer to David Ingram, one of the founders of openEHR:
The governance of healthcare informatics involves many big issues. How do we balance individual interests concerning privacy and group interests regarding data availability? How do we deal with the ethics surrounding the governance of information, considering the impact it can have on citizens, organisations, business sectors and governments, among others? How do we manage a system in which informatics is developing at enormous speed, while we need years to correctly assess the long-term consequences of (new) treatment methods in healthcare?
These are interesting questions - however, for the scope of this article we will limit ourselves to the discssion of one specific sort of governance (of which, in all fairness, some of these questions are also of importance): openEHR governance.
In the field of openEHR, we often talk about governance from the perspective that the specifications and all associated components (the Reference Model, archetypes, etc.) need to be managed so that they can be developed in a controlled way. At an international level, the Reference Model is managed by the Specifications Editorial Committee (SEC) of openEHR International and the archetypes and templates by the Clinical Program Board (CPB). openEHR International has a page on their website dedicated to their governance process. However, the attention and structure that goes into this process at the international level is not necessarily mirrored in local repositories. Within the Netherlands, we have our work cut out for us if we want to deploy openEHR sustainably within our healthcare system.
Without local governance around the information model (archetypes and templates), you run the risk that each software vendor will continuously create its own archetypes and templates or, in some cases, even an entirely separate CKM (Clinical Knowledge Manager). In some cases, this can work quite well, provided continuous checks for compliance with openEHR International's CKM and updates to it are ensured (for more information on this, see Vanessa Andreia Azevedo Pereira's research), but this does not (yet) seem to happen in practice most of the time.
To avoid expensive, long migration projects between systems and to ensure that systems are truly compatible with unambiguous, reusable data, governance is badly needed.
Questions to be addressed within the Dutch openEHR community include:
Who validates nationally developed archetypes and templates against the international standard? Is there a role here for openEHR Netherlands and/or the Dutch openEHR community?
Do we use already approved international components and convert them for national or regional use, or do we choose to develop regional components that we can then make available for national or even international use?
Should the Netherlands develop its own CKM (Clinical Knowledge Manager), such as countries like Norway and Slovenia have done, adapted to specific Dutch requirements? And if so, who will develop, maintain and check this for compliance?
How do we deal with translations of international archetypes? Will these be validated and managed centrally and, if so, how?
Will we create our own FHIR-openEHR mappings within the Netherlands and how will we manage them centrally?
These questions were raised last month at the onEHR event organised by openEHR Netherlands (keep an eye on the LinkedIn page of openEHR NL for the next onEHR event!). A sizeable group of participants with various areas of expertise entered into a discussion on the subject, leading to different perspectives and ideas.
With parties like HL7, the Dutch core profiles are managed by Nictiz, while HL7 Netherlands is the 'holder' and regulates authorisation by means of a validation board. It is conceivable that things could go the same way with openEHR within the Netherlands. However, this would mean that time and resources would have to be allocated for this within openEHR Netherlands and that the Dutch community would have to take a more active role in this as well.
If we want to move towards a national Dutch CKM, it is expected that we will also have to increasingly involve Dutch healthcare professionals. As mentioned, Norway has its own CKM and they also have their own governance scheme for archetypes. Research by Silje Ljosland Bakke showed that, "As the mass of clinician involvement reached a critical point at the end of 2014, the rate of archetype review and approval increased." So far, interest in openEHR within the Netherlands seems to be mainly among information professionals and policy officers - a good start, but we will also need to increasingly reach out to healthcare providers and show them of what openEHR can mean for them and their patients.
That governance has been discussed at onEHR with participants from various organisations and backgrounds is a good and important step. Now we must decide how to move forward. Based on what we see with other standards and in other countries, CODE24 sees an important role in this for both openEHR Netherlands and the Dutch openEHR community, of which we ourselves are also a part, of course. openEHR Netherlands can provide guidance and the content can come from the community, ideally made up of both developers and healthcare professionals, as openEHR always intended.
Together we will be able to make this work. Be sure to join openEHR Netherlands (as a supporter like us or otherwise) if you want to join the conversation.