Me too. A blog post I did on Desiderata for Successful e-health Standards a while ago might be of interest to some. It summarises the top-level priorities as:
NB these are characteristics of standards, not systems. I see (true, automatic) Interoperability as a consequence of getting the first three right.
I think that the kind of disagreement found in a science-based culture is the right one. It is always that the case the today’s theories may need to be adjusted or even jettisoned when contradicting evidence comes into view. More fundamentally, even paradigms may be overturned by better ways of seeing things.
We thus progress by the creation of ‘pretty good’ theories by some (synthesis), while others try to take them apart (analysis). The latter either strengthens them (proves they work in a greater scope than previously recognised) or demonstrates their weaknesses.
The key is never to be religiously attached to one’s theories, only the process of investigation. This is why I believe the culture of openEHR is essentially industrial R&D, rather than ‘standards development’; its good quality results find use as standards anyway (what works is what gets used).
This community’s shared mission is to ‘carry on activities which benefit the community’ , these benefits are expressed as ‘improve capability and interoperability of electronic health systems’.
In my original post I suggested that first we need to understand the community served and their motivations, (the WHY) in order to identify what the openEHR community’s activities should encompass (the HOW). Discussion so far has focused on the WHAT - interoperability. We first and foremost need to focus on why anyone wants to take up openEHR. As is relevant to any negotiation we need to understand our opposition and what motivates them in order to work out how to be able to engage with them and move forward, ie who do we need to convince and teach? Our education strategy is dependent upon understanding the motivators to change or change restrictive behaviours.
In the absence of this void Heather and I did some brainstorming that resulted in a list of stakeholders together with their motivators for you all consider. We need to put ourselves in the shoes of these stakeholders and think about the benefits they are able to attain if and when the openEHR knowledge domain is optimally adopted. Our big picture list includes:
Once we have clarified that we’ll be in a strong position to develop our educational strategic directions. We’ll also be able to identify who is dependent on others to do the right thing in order to attain the desired benefits, as there are many interdependencies. Please add any we may have missed.
Stakeholders and Motivators.docx (31.9 KB)
One thing to be aware of (should have posted this earlier) is that the definitive Vision and Mission statements are here on the website, not in the Articles of Association.
There is also quite a lot about motivations (WHY) on the What is openEHR page - see Motivations, and also Value of using openEHR.
Dear Evelyn and all,
some time back there was an analysis done by members of the board, defining personas as you listed. I’m sure the results are a good starting point and I will try to find out where to obtain the info.
Best,
Birger
Hi Evelyn,
I really like this approach. I would love to share my why, but as stated it’s a pretty broad question, hard to share via discourse.
Maybe this post of mine is a helpful start: I finally don’t feel ‘new to openEHR’ anymore
Joost I liked reading about your journey, but what made you take this journey in the first place? That’s the WHY I’m looking for.
As @joostholslag and others have stated - this is a pretty broad topic. I will give a short answer.
I want to be part of an international community with competent people who try to improve the way we develop clinical applications. Since the health and care is big and growing we need global cooperation. Both to share technical artifacts like archetypes, software and even more important; knowledge and skills.
I base much of may daily investment on this simple vision:
@bna Thank you for sharing your personal ‘WHY’, I share your why and I’m in total agreement with that vision. That vision expresses the ‘WHAT’ in terms of what will be delivered by a software vendor who uses openEHR IP. I’ll continue to be provocative and behave like a 3 or 4yr old who keeps asking why! Who within the health sector, in addition to software vendors, benefits from adopting ‘light-footed and sustainable innovation’ ? Why is that important, who are the beneficiaries , what are those benefits and why should the openEHR knowledge domain be adopted to achieve this? The answer to my last question is inferred in the vision.
@thomas.beale these pages provide very useful high level information. Developing a comprehensive education program requires us to de-compose many of the concepts referred to. This then enables us to develop specific curricula to suit the many different stakeholders and the variety of roles they are expected to occupy. Some stakeholders just need a general understanding to make the right decisions and direct others to make it happen, others need to have in depth knowledge and practical skills that enables them to work with specific aspects. The target group comes from a variety of different academic and experiential backgrounds we need to be able to build on, others need to learn about foundational principles to enable them to begin to understand various aspects of the openEHR knowledge domain.
To enable us to determine desired educational outcomes requires us to clearly identify those stakeholders, determine their prior knowledge and skills then develop content that enables them to build on those foundations to enable them to achieve their desired outcomes. That’s why we need to be far more specific.
We want to focus on developing micro-credentials based on ‘just in time role based learning ’ to best suit everyone. That is, we need a course that explains how openEHR use, enables each desired benefit mentioned to become a reality.
As expressed on the’ What is openEHR page’ the education program needs to bring the technical outputs of the other programs to the real world , to enable the efficient use and uptake of the outputs of openEHR and ensure its usability in local languages, within diverse healthcare cultures and funding environments.
Theoretically I agree of course, but this is only partly realisable I think, because the sector is highly disorganised and confused. Few institutions even know on what basis to hire what kind of people, and the result is that people with one set of skills are trying to do entirely different jobs, generally with no clear paradigm-level overview and often with no exposure to health informatics as a discipline (such as it is).
As a consequence, the situation I think we are really in is ‘gap training’, i.e. helping people who are doing tasks for which they had no prior training to fill in the gaps. This would point to a) modules with over-arching principles type material (= health informatics) and b) separated goal-oriented modules for e.g. giving HCPs interested in modelling some background in e.g. principles of ontology, terminology, UI/UX, work efficiency and so on.
This is likely to be a big program.
Anyway, in terms of drivers, my short list is from the What is openEHR page:
Thomas you’ve described an issue I’ve dealt with ever since I began teaching Health Informatics! It is continuing to be an issue. The HI knowledge domain is huge in depth and breadth. That’s why micro-credentials are most useful. openEHR is applicable to all aspects. Your short list is helpful.
We need a comprehensive program showing how these micro-credentials scaffold knowledge and skills, from one module to another. This also enables people to pick and choose what they need most now (just in time learning, gap training) enabling them to build on what they already know.
One way to deal with the current disorganisation and confusion is to de-compose required knowledge and skills relative to roles (not positions or disciplines) and identify pre-requisite foundational knowledge and skills the course design builds on. Where possible we focus on generic content that can be applied to a variety of instances. Pre-requisite knowledge and skills may be from foundational software engineering or computer science or programming or clinical or management or genetics or information management or statistics or any other foundational disciplinary knowledge. We need to identify not only the key foundational knowledge and skills each course but also provide resources for further reading/study to enable people to get up to speed. We are making use of the SFIA framework and any other framework where relevant. This education program is all about design…just like you do for architectures.
I cannot help but add an observation about two extremes:
It is a (sad) reality that the attention span, knowledge and skills of (some) HI stakeholders are often comparable to children learning new things.
Maybe what is needed are “children books” for HI/openEHR. Short, with many pictures, limited in scope. Intendent to be read in less than 30 minutes. Each such “book” would build on the previous ones in a series (there would be different series/paths focused on different stakeholders).
Some prefer reading, others prefer watching. Accordingly there should be books and videos to cover both approaches to learning.
Some examples of such “learning paths”:
I do think we should distinguish what can be properly openEHR material and what can be more general health-informatics-as-it-should-be material. For example, the concepts of knowledge driven platform are not openEHR specific; openEHR is just an instance of realising such an idea. However, much of what we want to promulgate that the openEHR community has arguably created in terms of general paradigms isn’t in health informatics courses or textbooks - platform, clinical modelling, multi-level methodology, how to use terminology and so on.
So there is a gap here: a large block of knowledge (typically the kinds of things you see on our blogs) that isn’t taught in any standard health informatics course, but also isn’t an openEHR specific.
On the other hand, openEHR industry trainers tend to train based on openEHR specifics, and they provide these concepts in passing.
It is a strategic question in my mind as to whether the openEHR Education Program should be trying to develop syllabus for and teach the missing conceptual pieces. I don’t think it should be - the missing piece is wider than openEHR, and it would also be hamstrung by being labelled as ‘openEHR’.
If there is appetite (probably yes) and resources (questionable) to build this corpus of material, then I think it should be done in a separate organisation, which could be a fellow-traveller open source education project - call it ‘Domain-centred Health Informatics Education’ or similar. We could set this up today.
If we did this, then it provides a clear(ish) separation of paradigmatic and conceptual material, and openEHR-specific material and practices. The result would be to make the openEHR Education Program more limited and focused, closer to what is already being taught in the industry context, rather than trying to be a university level course.
I think the governance and certification needs for both areas of education would the crystallise out more easily than they are now.
The highmed symposium featured a lot of speakers that said something about their why from different perspectives:
(My very rough summaries)
@patrikgh : MD “openEHR solves my problems”
@Tomazg : ceo “data for life platform (is a good business model, JH)”
@johnmeredith : national it architect “key part of national infra”
erik: consultant, “openEHR is part of smart system for complex care”
@jpieraj : “openEHR as a regional infra”
@bna : product vendor:” with openEHR I know I can handle all clinical requirements”
@ukpenguin, Proffessor: “Convergence on open standards is essential“
Edit: videos here Events
@thomas.beale I’m in total agreement with your observations. When I refer to the need to identify foundation knowledge and skills (pre-requisites) I simply use that as a method to provide context. The openEHR program itself and especially certification processes must be based exclusively on openEHR content which has built on those fundamentals. In other words they are embedded. Other education providers need to provide courses that teach those contextual fundamentals. We need to alert our target audience to the most relevant foundational knowledge required with some references to enable those with identified foundational knowledge gaps to get up to speed in any way they can.
Of course many openEHR educators provide courses that include aspects of anyone or many of those associated knowledge domains. That’s what differentiates openEHR education providers and courses offered. For example we (GeHCo) focus on data and data supply chains as that is our area of strength.
Thank you Joost, all very useful from each of their perspectives. The why I’m looking for are benefits realised by the users/recipients of care openEHR applications serve. Many of those are listed on the openEHR vision page.
I also agree with your observations, the gap in HI really exists and explaining openEHR without proper preparation of concepts is difficult.
You mention: “If there is appetite (probably yes) and resources (questionable) to build this corpus of material, then I think it should be done in a separate organisation, which could be a fellow-traveller open source education project - call it ‘Domain-centred Health Informatics Education’ or similar. We could set this up today.” I agree with this too. Probably another target group (modelers) can be approached with these knowledge.
For developers, I think more examples of openEHR prototypes, with coherent implementation of an Archetype and one or more Templates could help them thinking in openEHR terms. Simple prototypes without security and complex SoS enterprise systems. In my view developers can learn directly from code examples, and even extract conceptual thinking from coding.
Then there is another issue that is not mentioned here and adds extra complexity to openEHR. It is “open”. The openness points to extendability in the sense of adding new functionality in already existing systems, but also points to openness for other clinical professionals to add to the models and extend domain knowledge. For as far as I know this openness has not been offered in other systems in production in healthcare.
New posts here mention “open platforms”. I have some questions about the term open platform: Which party or which company has control over the platform? There is a suggestion of openness of control, but there are no agreements about this or mandatory monitoring open to users and organizations, we know that when the platform conforms to the openEHR specification it operates in a specific predictable way, but users of the platform have no control over the operations. I do not say that this is a lack, maybe I have missed specifications about the openness of platforms, but I would like a more transparent description of open platforms in relation to openEHR.
Hi Deborah,
this is a very good question and I like to give my 2 cents from a user and vendor perspective :
Which party or which company has control over the platform
This depends on the use-case. I’m quite sure the EMR vendors in the Nordics will have some say in what extensions are allowed (for patient safety reasons). In the case of our national COVID-19 platform, control is in the hands of the operating non-profit organization. It can be hospitals in other cases.
we know that when the platform conforms to the openEHR specification it operates in a specific predictable way, but users of the platform have no control over the operations
They can, if they like to. Just pick one of the open source solutions and start building and operating the open platform.
maybe I have missed specifications about the openness of platforms, but I would like a more transparent description of open platforms in relation to openEHR
From my point of view, “open platform” describes a design principle/philosophy and not such much a concrete specification. From a technical perspective, an open platform can be understood, roughly speaking, as vendor-neutral and with 100% open APIs. We are building such platforms in HiGHmed and within vitagroup but we still see some variations of the ingredients and architectures:
It would surely be the next step to standardize the “open platform” as one distinct specification (then maybe with a different name). However, I would choose an evolutionary approach driven by markets and vendors and see if a reference architectures emerges which finally could be the foundation for a standard (likely in the sense of IHE profiles or similar).
