Resource list - the essence of openEHR

View fullsize

When someone asks me what resources are available to provide an overview of openEHR, this is a list of resources I share and some of the reasons why…

Maybe it might be useful to others too.

1. The openEHR International CKM - a world-leading public library of clinical information models intentionally designed as a coherent data ecosystem

1. Do not miss the openEHR community Discourse forum

2. Recent publication from thought leaders in Catalonia (ie a regional/national approach) Can OpenEHR, ISO 13606 and HL7 FHIR work together? An agnostic perspective for the selection and application of EHR standards from Spain. Catalonia is in the procurement phase of going down the openEHR route, including their own CKM. And this is seriously influencing a potential whole-of-Spain approach.

3. EY white papers - EY health consultants, esp in EU, are increasingly promoting openEHR in public as a solution component to the approach in these papers. There is not really any other data modelling alternative at the moment.

   • How will you design information architecture to unlock the power of data?

   • How innovative infostructure can power the purpose of integrated care systems

4. My COVID clinical modelling paper - openEHR Archetype Use and Reuse Within Multilingual Clinical Data Sets: Case Study - demonstrates international data model reuse for a variety of clinical purposes related to the early days of the COVID pandemic.

5. Symposium held in Berlin in October 2021: openEHR & FHIR – friends or foes?

   • Especially Prof Rachel Dunscombe’s presentation about the importance of data for life, not one application -  Starting at 2:41

   • And Tomaz Gornik’s presentation re vendor-neutral platforms – starting at 4:17 – referring to Gartner & EY papers

6. Gartner’s bimodal (samurai/ninja) approach to monolith systems and openEHR platforms:

   • Rachel Dunscombe (2018) -  Bi-Modal IT in practice

   • Andy Blofield, CIO about the ‘bimodal’ approach at Plymouth NHS Trust

7. This 2018 video on the ‘Post Modern EHR’, by Tomaz Gornik again, quoting Gartner re openEHR, underpins this growing European view.

   • Up to 5:15 is setting the context; thereafter compelling viewing...

   • At ~11:00 Tomaz speaks to the mega-suite vs hundreds/thousands of apps in a single hospital

8. Italian openEHR day (in English), 2019  – featuring many openEHR International leaders and providing an excellent overview of openEHR in the real world.

9. Thomas Beale’s ‘Woland’s cat’ blog (founder of openEHR specs). There are many and all are worth reading, especially from a technical POV around digital health standards and reimagining electronic health records.

10. Roadmap to Successful Digital Health Ecosystems: A Global Perspective - a textbook published in 2021focused on the (openEHR) open platform approach – ie archetypes/templates as information models, terminology, FHIR etc as messaging but also the underpinning of coherent data ecosystems and open platforms. Many openEHR experts authoring chapters, plus a good overview of international approaches to digital health ecosystems. It is not cheap, but an excellent resource for a university library or similar or to recommend for policymakers. The principles are appropriate for anywhere that cannot/should not procure a typical US EMR mega-suite.

Not all CKMs are created equal

Despite using the same underlying tool, not all CKMs are equal. Rather than ‘one CKM to rule them all’, each CKM exists for a specific reason – for example intent, geographical domain, servicing a common community. This allows countries, organisations or programs to operate autonomously from each other when they need to. All CKMs operate independently of each other, with their own Editors and Administrators.

CKMs support some baby steps towards federation but this is hugely complex and a problem not yet able to be resolved. The tension can only be managed by the administrators governing each CKM, and the risk is significant divergence or conflicts between models.

So, when searching for archetypes to use in data sets it is important to know where to look, the focus and context of each archetype, and therefore have insight into the pros and cons of each model. Each CKM may have different ways of governing its archetypes and so choosing the best archetype for a given purpose is not necessarily straightforward. This doesn’t mean that you shouldn’t try to identify useful archetypes in various CKMs, you just need to understand any potential consequence of your choice.

There are currently five public CKMs:

1.       The openEHR International CKM is commonly described as the ‘source of truth’ for most openEHR modellers. It is ambitious, and by no means perfect, but the goal is to create a coherent health data ecosystem of shared clinical models, avoiding overlap and minimising gaps, reusable across multiple clinical scenarios – effectively establishing a universal health language. Supporting semantic interoperability is the cornerstone of the openEHR CKM and this intent is one of the key differentiators from some other CKMs.
In this context, the underlying philosophy of archetype design is a proactive approach to ‘deconstructing clinical knowledge’, rather than simply replicating existing content found in clinical systems, forms, messages or data sets. It is primarily focused on standardising current clinical knowledge and practice, aspiring to digitally represent all the things that clinicians and domain experts know and do as well as integrating relevant and sensible existing content. The resulting tension can sometimes be difficult to balance – current content vs anticipating future ‘best practice’ - this is the ‘art’ of clinical modelling. All published archetypes and those currently under review have a design intent of inclusivity of all relevant data points, always aiming towards (even if never achieving) a maximal data set and universal use case.

Any draft archetype in a project is a potential candidate for publication and reuse, otherwise it is rejected or kept separate in an incubator. @siljelb and I share that philosophy and protect the CKM library quite fiercely to establish its credibility as a high-quality resource. It's not perfect but an evolving work in progress. We meet weekly to discuss issues and actively manage the content.

2.       The Nasjonal IKT CKM mirrors the great majority of archetypes in the International CKM but local Norwegian governance ensures the representation of all archetypes in Norwegian Bokmål and inclusion of archetypes to support local requirements.
The Norwegian modellers work in parallel with the International CKM modellers, running synchronised archetype reviews and publishing/updating archetypes simultaneously. The majority of the archetypes are identical to the archetypes in the International CKM.

3.       The HiGHmed CKM references many of the International CKM archetypes, that is, it makes the international archetypes available in their archetype library as read-only. HiGHmed modellers actively contribute, and keep up-to-date, German translations to the International CKM. In this way, HiGHmed modellers have easy access to the International CKM archetypes in German. The HiGHmed governance is focused on the coordination of the modelling effort within the HiGHmed consortium, with processes that appear to mirror much of the international/Norwegian approach. Identification of HiGHmed-created archetypes that are candidates for inclusion in the International CKM has been limited by a lack of openEHR resources, especially the need for translation from German.

4.       The Apperta CKM also references (as read-only) many, if not most, of the International CKM archetypes. It does not appear to have a documented governance philosophy or approach but the content design and governance approach of the Apperta archetypes appear to reflect an alternative philosophy where modelling is often closely aligned to existing content and directly mirroring organisational, regional or national UK requirements, rather than aiming towards international interoperability.
To date, only 30 archetypes from amongst the 842 UK archetypes in Projects have been referenced back (as read-only) to the International CKM, and of these 30, almost all of them are scores or scales, for which there is usually little debate about clinical content or divergence in the modelling approach.
The Apperta CKM has only 7 archetypes in incubators, which implies that there is quite a different approach to the use of Projects and little use of Incubators as a ‘sandpit’ space for immature archetypes.

5.       The Slovenian CKM is a bit of an enigma and probably best not to use as a resource. It went live in 2013, has 37 registered users. In December 2020, 10 archetypes were added, to support COVID work, and prior to that the most recent changes appear to have occurred in early 2018. My understanding is that these were the archetypes that were used in the first implementation of the Better EHR around 2013.

(If any of this information about the different CKMs is inaccurate, please let me know.)

In addition, there is a Chinese archetype library, the Healthcare Modelling Collaboration, and I believe there is also one in Chile, containing .json ‘archetypes’.

In reality, anyone can build an archetype for any purpose. But is it a good one? It depends on your intent. At one end of the spectrum, the content of an archetype can be really rough, quick and dirty but if it is only used in your system then it really doesn’t matter. On the other hand, if you want to design an archetype for use within the coherent ecosystem, especially where you need broad interoperability, you need to understand how to design the content of that archetypes to optimise the potential for reuse and semantic interoperability. Considerations include a choice of class, the scope and focus of the content, the underlying modelling pattern, and how to document it clearly.

In practice, we have archetypes in the wild that are at all positions on that spectrum. That is fine, as long as we understand the consequences of our design choice. Designing for local use limits future interoperability; designing for maximal reuse can take more time to investigate and document.  However, one thing that you can be sure of, if you use an archetype that is either a draft or has not been designed with interoperability as the goal, then there is a real risk of building up technical debt and effectively you are contributing to the data silo problem again. Simply using an openEHR archetype in a clinical system does not provide semantic interoperability ‘out of the box’; using shared and published international archetypes gives you the best opportunity to achieve degrees of interoperability and break down the data silos.

Achievements of the openEHR Clinical Modelling Program

Now for a blog version of my Twitter thread celebrating the achievements of the international openEHR Clinical Modelling Program, its' Editors, & its' community of volunteer reviewers. I'm so proud of these people, these models. Together we've achieved something truly unique & groundbreaking 🌟🌟🌟🌟🌟

1. The archetype design methodology - a strategic and coordinated approach to data design that proactively deconstructs clinical knowledge & applies scientific rigour and repeatable clinical recording patterns to clinical information model development

2. The openEHR Clinical Knowledge Manager (CKM) tool - our secret weapon! This custom-built unique online tool is the coordinating centre for the Clinical Modelling Program - our library of archetypes, collaboration portal, and governance hub rolled into one.

3. Our archetype library is the most advanced and coherent collection of multilingual clinical information models available in the public domain.

4. The clinical knowledge governance methodology is unique, comprehensive and sophisticated, embedded into the CKM. Where else can you witness the innovation of parallel clinical information model content publication processes integrated with technical versioning?

5. We crowdsource the quality of our archetypes! The CKM has integrated an asynchronous, open & transparent peer-review approach to quality assurance of the archetype content so that clinicians & domain experts verify the content as ‘fit for use’ in clinical systems.

6. Clinician engagement in health data standards has been encouraged by reducing the technical/tooling barriers to enable grassroots clinicians to participate in archetype design and review.

7. We have built a spectacular CKM community, all by word of mouth and peer-to-peer recommendation.

- 2666 registered users from 104 countries, including 1017 volunteer reviewers.

- 300 registered translators and archetypes translated into 31 languages.

8. And within that CKM community:

• 33% identify as health informaticians

• 10.4% as medical practitioners

• 9% as students

• 5.8% as 'other'!

• 5.3% as software engineers

• 4.3% as administrators

• 3.8% as nurses

• 3.6% as researchers

• 2.6% as consumers

• 2.2% as academics

9. Demonstration of up to 100% archetype reuse across various, multilingual clinical scenarios in the earliest days of the COVID-19 pandemic – see "openEHR Archetype Use and Reuse Within Multilingual Clinical Data Sets: Case Study".

10. Identification of common, reusable modelling patterns in clinical recording eg the fractal nature of physical examination findings for different clinicians at varying levels of detail; tobacco, alcohol, substance use summaries.

11. Coordinating international publication of archetyped content for safety-critical, core or advanced clinical concepts where it is difficult to achieve consensus eg Adverse Reaction Risk in 2016 (incl the FHIR community); Advance care directive for patients & Advance intervention decisions for clinicians.

12. Our openEHR International archetype library underpins eHealth programs in Norway, Slovenia, England, Wales, Scotland, Alberta (CA) & Catalonia; EHRs for the City of Moscow, the Chinese Military & COVID CDS deployed in Wuhan. It also underpins an evolving national primary care data dictionary in AU.

13. And finally, if you're in the mood for some light reading, our Zotero library folder focused on #openEHR clinical modelling.

What have I missed?

The state of openEHR Clinical Modelling Program

Continuing from openEHR Clinical Modelling Program - the early days…

The situation changed significantly in 2014 when the Norwegian eHealth program acquired their own CKM. From my point of view, this marked a singular turning point in the destiny of the Clinical Modelling Programme.

The Norwegian lead, Silje Ljosland Bakke, joined the Clinical Modelling Program as my co-lead, and she recruited a small team of modellers. Between 2014 and 2017 we ran seven two-day introductory clinical modelling courses and eight advanced modelling workshops. Since 2018, the Norwegian team have run additional training workshops independently. They invested significantly in training clinicians, vendors, and decision-makers about openEHR and established their national governance processes.

In addition, the Norwegian program has invested strategically in building capacity in their national modelling team in openEHR and in training their reviewers. They are a paid organisational member of openEHR, support Silje as a CIC Board member and International CKM Clinical Knowledge Administrator and license and run their own CKM as a national resource. Their modelling team currently comprises 3 experienced members, participating since 2014, and 3 newer members who are rapidly growing in skills. Since 2014 I have met with them weekly to discuss modelling issues, initially in a mentoring role, increasingly in recent years this has been focused on joint and parallel archetype development and reviews.

Overall, during the period 2006 to 2019, I delivered more than 30 2-day openEHR clinical modelling introduction courses in Australia, UK, multiple EU countries, US, Canada, Brazil, China, Japan. In addition, I’ve run many 3-5 day advanced modelling workshops in various destinations over the years. Ian McNicoll attended his first openEHR course in 2007 and was frequently a co-lead from 2009. He has been just as active independently since he left Ocean in the early 2010s.

Very pleasingly, since 2018, the Norwegian team have felt confident to run their own training workshops independently. This was another critical moment, when we could demonstrate that the openEHR approach was transferrable. Our biggest challenge now is to make it scalable.

Between March 2018 and August 2021, the openEHR CIC engaged me on a paid consulting basis for 25 hours per month, continuing my role as Clinical Program Lead. To the best of my knowledge and in that context, the cost to the openEHR CIC and community to achieve the progress outlined in State of the CKM – 2021 has been to pay me for just under 6 hours per week for a period of 41 months. Most of those 6 hours per week has been used to maintain the CKM and support the modelling community – weekly CKA meetings, managing change requests and translations, answering questions from the community, meeting with community partners, training and mentoring new editors, etc.

So, what most people may not be aware of is that by far the majority of archetype publication progress in the International CKM has mostly been driven by an extremely close, deliberate, and strategic weekly collaboration between myself and the Norwegian modelling team. In fact, I’d estimate that >90% of the archetype publication, especially at the accelerated rate of the past 2 years, has been entirely resourced by the Norwegian modelling team – including my consulting time. While this arrangement has worked well to date, largely because the Norwegian priorities for archetype publication have closely mirrored those for the international modelling community, it is clearly not sustainable.

Let me be perfectly clear, if the Norwegian program is reduced or withdrawn, the openEHR modelling program will effectively come to a standstill. And in my opinion, there are only three individuals who are currently skilled enough to design archetypes for, protect the integrity of, maintain, and govern the International CKM – and they all have full-time jobs and live in Norway.

openEHR’s greatest asset is also its largest vulnerability. As the community, the implementations, the contracts and the number of models has grown, the capacity for modelling archetypes fit for the International CKM and training, then mentoring, modellers so that they can become independent Editors and ultimately Clinical Knowledge Administrators, has been ignored. In the first instance because we’ve essentially been in survival mode, and struggling to establish and maintain what we already had.

We have failed to approach the Clinical Modelling Program strategically and ensure that we have increased workforce capacity to support the increased openEHR activity.

Now that I have unfortunately been forced to withdraw my services, unfortunately this leaves Silje to manage the responsibility of the Modelling Program in isolation.

Yes, theoretically CKAs from other CKMs could step in. But could they, should they? If you take a look at the other CKMs you will note that they have different focuses, different content (to be discussed in another post).

There is no succession plan, no redundancy, no Plan B. The future of the Clinical Modelling Program is being made up on the fly. The community should be concerned.

After all, if the Clinical Modelling Program fails or folds, what of the rest of the organisation? If the quality and philosophy of the CKM library is not maintained and protected due to lack of skilled operators, what is the consequence for implementations?

openEHR Clinical Modelling Program - the early days

The openEHR Clinical Modelling Program commenced life as the Archetype Editorial Group and ‘operated’ between 2007 and 2012-ish. The original announcement in 2007 described it as the lead group for archetype authoring. Comprising a group of doctors influential in health IT and friendly to the openEHR approach selected by Sam Heard (Ocean, AU) in the first instance, the announcement also states the intent to develop a nursing group would be convened soon after.

Members that I can recall included Sam Heard, Sergio Carmona (Chile), Beatriz De Faria Leao (Brazil), Sundaresan Jagannathan (Jag) and Ian McNicoll (both from Scotland), Omer Hotomaroglu (Turkey, who went on to be the primary author for the ECG archetype) and Evelyn Hovenga (Australia, and despite being a nurse). Sam Heard gave me the title of ‘Convenor’, if I remember rightly, although it was never clear to me what the function of the group was, and I didn’t convene much. Effectively we had an oversight group without a clear purpose. I’d email them an archetype with some questions and, usually, no one responded. That wasn’t unreasonable in retrospect – if you haven’t any reason to be interested in the content of an archetype, then why would you spend time out of your busy day?

My main takeaway from this period was that expecting a committee of experts to provide editorial feedback about something that wasn’t relevant to their work or needs, especially without providing a framework for discussion was never going to work. We had to work smarter and be more focused on what we needed to achieve. This heavily informed the initial approach to clinician engagement and governance of CKM.

In 2007, an academic paper on the earliest thinking about clinical knowledge governance and describing the CKM precursor, the online ‘Archetype Finder’, co-authored by Sebastian Garde, Evelyn Hovenga and Sam Heard et al [1].

Sam Heard showed me some of his first archetypes in 2004 when I first joined Ocean - Adverse reaction and Blood pressure, if I remember rightly. But 2008 was the year that the first serious modelling work was done as part of an evaluation project for the NHS England’s infamous NPFIT program. Sam Heard and I worked in London for a number of months producing the first serious tranche of archetypes to support 2 use cases - the top 10 presentations to the Emergency department and archetypes to support antenatal care from a first visit through to a postnatal consultation. It was during this period that we realised that we needed the CLUSTER class of archetypes - they didn’t exist in the original specs. I still have those archetypes in an archive - interesting to see how our modelling thinking has evolved.

The first iteration of CKM development was developed during 2007/2008 - coded by Sebastian Garde, me as Product Manager, and with the first archetype uploaded around July 2008. For the next 10 years Sebastian and I battled awkward time zones to meet regularly, usually twice weekly via Skype, to plan, discuss, revise. Sebastian would code while I slept and vice versa. Ian McNicoll contributed regularly during the period when he was employed by Ocean.

Sam’s initial theory of developing groups with semi-autonomous, independent authoring and editorial responsibility for a content domain or speciality was attractive in theory, but the experience of the Editorial Group made it clear that this was not very practical. In response, the structure of the CKM was designed to support a folder-like structure – at the subdomain level as well as governed projects and ungoverned incubators to facilitate all kinds of groups with roles and responsibilities, and at various levels of granularity. This has worked quite well in practice - and is used extensively in the International CKM. Any work in projects is governed tightly by Clinical Knowledge Administrators, as these archetypes need to conform to the intent of a coherent ecosystem of archetypes, avoiding semantic overlaps and minimising gaps between concepts, always aspiring towards the ideal design each archetyped clinical concept being inclusive of any/all relevant data points and for any/all relevant use cases.

I have previously written about the State of the CKM in 2010.

From left Michael Beale (Ocean, UK), Rong Chen (Cambio, Sweden), Dipak Kalra and David Ingram (UCL, London), Ian McNicoll, Adriana Danilakova (Ocean, UK), Shinji Kobayashi (Kyoto University, Japan), Joana Feijó (Critical, Portugal), Seref Arikan (Ocean, UK), Jussara Macedo Rötzsch (Brazil), Sam Heard and myself (Ocean, AU). Photo credit: Shinji Kobayashi.

During an extended Board meeting held in London in September 2012, Martin Severs (not in the photo), the man who had recently coordinated the transformation of SNOMED into its new organisation, joined the meeting as a guest and he identified the Clinical Modelling Program as the single most critical success factor for openEHR. Everyone agreed that the programme should receive priority for funding from the Board.

At that point, at Martin’s request, I developed a proposed cost for a paid CKA at one day per week, just enough to kickstart the transformation of the CKM and modelling program from a special interest group towards a more formal and strategic approach. But no funding was able to be made available and unfortunately, this was the first and last meeting held about the strategy for the modelling program, at least to my knowledge.

From day one the Program has evolved, somewhat organically and based hugely on goodwill and a shared vision. We made do, growing and promoting the modelling approach the best we could with almost zero resources available from the fledgling Foundation. Ocean developed the CKM and provided it to the openEHR community for free, as well as covering my time and Sebastian’s. Others volunteered their time and effort, or their time was covered by their employers.

In building up and growing the Clinical Modelling program in the early days, I couldn’t find any examples of similar work to leverage - not on clinical modelling with the intent of building a coherent domain for the whole of health, nor associated clinical knowledge governance. We seemed to be in uncharted territory, armed with little more than the earliest Archetype Editor tool, an unstable flaky Template Designer, a fledgling CKM and a lot of enthusiasm.

If anyone has any additions or corrections, I’m happy to include or amend…

Next… the state of the Clinical Modelling Program

[1] Garde, Sebastian & Hovenga, Evelyn & Gränz, Jana & Foozonkhah, Shahla & Heard, Sam. (2007). Managing Archetypes for Sustainable and Semantically Interoperable Electronic Health Records. eJHI - electronic Journal of Health Informatics. 2. e3.

State of the openEHR CKM - 2021

As I leave my leadership role in the Clinical Modelling Program, let me start by sharing with you some facts and insights…
As of 2 November 2021, from CKM statistics:

Clinical modelling community

All insights into the clinical modelling community is represented by those registered in CKM.

• 2663 registered users from 104 countries.

• 1015 individuals have volunteered to participate in archetype reviews - that’s 38% of the total number of registrants. This is the pool of people who we can draw on to invite to an archetype review. It does not represent whether they have been invited, nor if they have responded to an invitation.

• 300 (11%) have volunteered skills in translation.

Active archetype statistics, projects only

It’s been difficult to get a consistent handle on these as CKM has some inconsistencies in calculations but the trends are sound.

• All active local archetypes, projects only – ~519

  • Draft – ~365

  • In review – 30, counted (6% of 519)

  • Published – 139, counted (27% of 519)

  • Review suspended – 7

  • Reassess – 5

Data point statistics

·         All active archetypes, projects only - 5915

·         Published archetypes - 1478 (25%)

Language statistics

• Number of languages - 31

• Top 5 languages

  • Norwegian Bokmål – 239

  • German – 206

  • Portuguese (Brazil) – 151

  • Swedish – 112

  • Arabic (Syria) - 78

Roles

• Clinical Knowledge Administrators – 2

• Editors

  • Archetype content

    • Regular - 5

    • Guest Editors on a special interest or per project basis -~15 have had varying levels of training/mentoring

  • Translation – 20+

Compare this with ‘State of the CKM’ in 2019

• 2343 registered users from 96 countries   

  • 857 reviewers

  • 281 translators

• 478 archetypes

  • 92 published (11%)

And just for reminiscing about the good old days – ‘State of the CKM’ in 2010.

Archetype numbers -Analysis and discussion

The Clinical Modelling Report presented at the recent 2021 AGM represented more about the dynamic nature of activity in the 12 months to August that is not evident from the stats above:

• 73 newly created archetypes – mostly by the Editorial team or via CKM proposals

• 155 archetypes modified/corrected/refined

• 30 archetypes newly published or republished

• 31 archetypes have undergone 47 review rounds due to 77 unique reviewers contributing 468 reviews (an average of 6 reviews per reviewer)

• The top reviewer completed 39 reviews.

I think most people will agree that this reflects a dynamic and active Editorial and reviewer community participating in the CKM hub.

BUT let’s do a quick reality check…

The first archetype was uploaded in mid-2008.

In 13 years, we have published 139 archetypes – that’s an average of only 10.7 archetypes per year.

In the past 2 years, we have had a net gain of 41 archetypes over the past 2 years – mainly acquired through proposals, the COVID collaboration and projects such as the Genomics work program. Many old patterns or concepts were retired. The CKM has undergone quite a big clean-up to ensure it reflects the evolving modelling patterns, always aiming to create a coherent ecosystem of models.

In that same timeframe, the number of archetypes published has increased by 47, and the corresponding percentage rose from 11% to ~27% - that’s an average of 23.7 archetypes per year. This sounds positive, but is it really? Is this publication rate enough? What numbers should we be aiming for?

In the past, I’ve estimated that if we design archetypes well, 50 core archetypes would support most of a primary care EHR, maybe 2000-3000 to support all the clinical requirements for a hospital EHR. These estimates are probably still relevant. Although as we start to explore standardisation of secondary data sets that can be abstracted from the original EHR records – for purposes such as research, registries, and reporting – numbers will blow out even further.

Let’s use 2500 as a working number for the required number of archetypes to support an EHR.

At historical average rates, it will take us 233.6 years to publish the number of archetypes that we need. At rates from the past 2 years, it will take us 105 years. That’s clearly not realistic or sustainable. And if we add in archetypes for standardising secondary use, reporting, research etc, this balloons further.

What about the 365 draft archetypes that we already have? At historical rates = 35 years; at recent rates, 15 years.

Let me be perfectly clear here, in my opinion openEHR has the potential for becoming the ‘universal health language’, a lingua franca for health IT.

In order to transform digital health we need a common information model, and the best candidate we have to achieve this is with openEHR… This is what I’ve been working towards for over 15 years - a common domain information model supported by a coherent set of archetypes as the foundational clinical models.

But the reality is severely lagging, held back by a Board that has been absent and uninterested.

____________________

At the AGM, the CIC Board has proposed ‘refreshing’ and ‘rethinking’ the Clinical Modelling Program, apparently by going to vendors to request more models…

We have more archetypes than we can cope with at the moment. While gathering more archetypes will help to fill the content gaps, the rate-limiting step is actually the review and publication process. And this has been ignored for more than a decade.

The Board doesn’t need to ‘rethink’ the Clinical Modelling Program. It does need to stop ignoring it and start supporting it.

At the simplest level, it needs:

• to understand the work of the Clinical Modelling Program (It thinks it does, but it doesn’t)

• to understand the skills required to manage a Clinical Modelling Program that builds archetypes to support a coherent data ecosystem (No, despite the rhetoric, it absolutely doesn’t)

• to develop a joint strategy with the CKAs who know how to protect the quality, integrity and credibility of the international CKM as the ‘source of truth’ for openEHR archetypes;

• to identify and source adequate funding to:

  • train and upskill Editors and Clinical Knowledge Administrators to ensure that the current asset is independent and sustainable

  • ensure that the CKM can continue to function as an independent entity that underpins all openEHR implementations

• a succession plan

The Clinical Modelling Program has effectively operated as an orphan within the organisation. It is more by luck than strategy or design that we have achieved what we have. This needs to change or openEHR could fail.

This is the kind of thing I wanted to speak to the Board about each time I approached it this year. Each time my request was rejected, with the reason being that Silje Ljosland Bakke had been appointed the Clinical Modelling Program representative on the Board at some point. Silje (already on the Board as an organisational rep) has repeatedly denied that she fulfils this role. So what on earth is going on. Certainly, the appointment of a Board representative has never been discussed with me. Rather both Silje and I feel that the Modelling program could only be fairly represented if both co-leads were involved in any Board discussions or program strategy.

One has to wonder, is this a consensus position of the Board as a whole, or it is just the position of the Co-chair who responds to my emails, who hasn’t spoken to me once during my period of paid engagement, not to understand the Modelling Program, nor even to enquire why I withdrew my services.

It’s messy and ugly and totally unnecessary. And the openEHR community is the ultimate loser.

More to come…

Adventures in FHIRland

In February I attended the HL7 International meeting in Sydney. Despite being openly aligned with openEHR AND a clinician, a classic double whammy, I was universally welcomed. It was a treat to catch up with some long term colleagues and renew acquaintances whom I hadn’t seen for some years.

I dropped in on some working group meetings to observe and soak in the ambience, particularly Patient Care, Vocabulary and the Genomics groups. An unexpected treat was to participate in the BPM+ Health workshop where I was able to learn to use some online OMG tooling to build clinical workflows, and it was super exciting to see where high quality atomic data has the potential to trigger initiation of care pathways, which could have a massive impact on health outcomes.

However the main reason for my attendance was to participate in the ‘Clinicians on FHIR’ day, initiated by Kate Ebrill from AeHRC. The ubiquitous Prof Ed Hammond, regarded by many as the father of HL7, and I jointly presented on clinical data modelling and standards.

Still pinching myself, but if it is on Twitter, it must be true!

A couple of moments from Ed’s talk stood out for me - ones that I’d like to share. The first was his slide, below. With apologies to Pieter Brueget the Elder, he described the current state of interoperability…

And the health professionals said “Let everybody choose their own data elements and terminologies, and we can map it all together.”  And the result was interoperability-breaking chaos.

Per Prof Ed Hammond, with permission.

Without a doubt FHIR is a realistic and achievable way for our diverse silos of clinical data to share selected data. It’s international momentum and growing community bear witness to it successfully meeting an immediate digital health need in 2020.

I had asked Ed to speak about his vision for the future in healthIT, especially in the context of his announcement at Medinfo 2019, in Lyon, for a HL7 universal health language. Unfortunately Ed wasn’t able to share anything more about this new HL7 vision but I captured one of his quotable quotes on twitter instead…

Ed Hammond: “If you’re solving today’s problems, you’re out of date!”

It is no secret that I view FHIR as a great interim solution for today, but essentially as a patch to create opportunistic interoperability between systems, but I have also expressed concern about it’s governance of models, coordination and sustainability.

I’ve also publicly stated many times that we need a universal health data foundation, a major leap forward where all systems based on common information models can share data natively. So you can understand how exciting it was to hear Ed declare a similar vision publicly at Medinfo. Now, my particular flavour of that lingua franca is no secret - it’s obviously openEHR. Ed and I agree on the vision, but differ on the the flavour of solution. I can live with that :)

Reading between the lines here (so please don’t quote either Ed or I on this), I suspect that Ed is also recognising that FHIR alone is not enough as the ‘final solution’. Without a doubt it is kicking major goals in the short term, patching between systems to start to create some limited order in Ed’s Tower of Interoperability chaos, but for a long term solution for digital health Ed and I seem to agree that we need a universal lingua franca as a digital health foundation.

openEHR, SNOMED CT & FHIR collaboration: an emerging case study

I’ve been working with CSIRO’s Australian eHealth Research Centre (AeHRC) on their Primary Care Data Quality Foundations specifications for the past 18 months.

The project is quite unique in its approach, at least for Australia, in that it is unashamedly using an open, transparent, co-design, co-development approach - and it’s getting rave reviews from those participating. It is actively engaging clinicians, terminologists, vendors and policy/organisation stakeholders. The outputs are agreed information models and terminology value sets, which form the basis of a national data dictionary. The information models (currently published as a Word doc only) and value sets are used by the AeHRC team to build FHIR AU profiles that will be implemented by participating primary care clinical systems.

View fullsize

It is being shared at the CSIRO eHealth Research colloquium in Brisbane today. The project materials are all publicly available and the team are encouraging the widest possible dissemination through open publication and active networking/sharing. All materials can be freely accessed on CSIRO’s confluence site. Feel free to delve into the details and share with your networks as well.

So how on earth has an openEHR person been engaged to work on a FHIR project? There has been a lot of FUD spread about openEHR & FHIR in the past, and it is super pleasing that David Hansen, Kate Ebrill and their team have been able to push past this nonsense and bring the right group of participants into this project. And it’s working so well…

I’m bringing my best openEHR modelling skills to the table, even though it’s not technically an openEHR project, as an information modeller and a clinician informatician. I’ve analysed both the data currently in the AU primary care clinical systems and potential data needs for our use cases. Working closely with AeHRC’s best SNOMED CT terminologists, I’m proposing the potential information models in this project, using the openEHR archetypes as our starting point. So as a clinician, informatician and modeller I’m acting as a bridge between the grassroots clinicians and stakeholders who own the clinical requirements and software engineers building the FHIR profiles and implementation guides.

In Phase 1, the outputs were deliberately simple – an agreed basic set of standardised atomic data that we wanted to be implemented in the same way across all existing systems. Our use case was a Practice-to-Practice transfer of patient data and the level of detail was simply enough to be safe, and requiring only a minimum of change or additions to existing software. Essentially, we were testing the collaboration and co-design process. Phase 1 deliverables (R1)are published here, with the initial version of the AU primary care data dictionary being published as a Word doc.

Phase 2 is currently building on this foundation, aiming to reuse and extend the concepts from Phase 1 plus adding new concepts. Phase 1 extensions include a addition detail about individual family members in a Family history plus usage details related to Alcohol consumption and Tobacco smoking. The use case is focused on a standardised and digital version the Aboriginal and Torres Strait Islander health assessment (MBS item 715) that can be implemented in clinical systems. In truth the scope of a 715 form is massive and covers most of primary care, and in the initial iteration we are reusing the R1 models and adding clinical concepts around social determinants of care (SDOH).

View fullsize

R1 models in green; R1 extensions in purple; SDOH in yellow

All of the massive collective clinical engagement and knowledge and experience held in the openEHR archetype library is being used to inform the data structures in this national project. That it has a FHIR implementation is effectively irrelevant from my point of view - it’s the openEHR clinical content shaping the SNOMED value sets and FHIR outputs.

I was deliberately pretty tentative about declaring the openEHR source in the early days, but increasingly finding that the clinicians don’t care, nor do the CSIRO team or vendors, as the archetypes are fast-tracking the clinical requirement gathering and confirmation. As the foundation for sensible discussions around a coherent set of Australian primary care data, the openEHR archetypes are also being validated as fit for use in this Australian context for the first time. Our philosophy of building archetypes for broad reuse across different domains aligns perfectly with the philosophy of this AeHRC project and potentially how this work is broadened and deepened over time.

To be truthful, I expected more push back from clinicians, but once the approach is explained the straw-man content as recommended has been almost universally accepted. Clinicians are agreeing with it and feeding back that it is better than they’ve seen before, so why change it! Subsequently the focus of most discussion is about the level of detail they want exposed for the use case and the content of the terminology value sets – an important and familiar discussion, and a primary reason for using templates in an openEHR-enabled world.

With my openEHR hat on, this is business as usual. We’ve been making data sets using this methodology for many years.

But where I’m starting to get just a little excited is where it connects with FHIR…

For my own purposes and in the interest of transparency to the FHIR team, last week I uploaded my modelling work on the 715 form to an openEHR CKM incubator for the AU Primary Care Data Quality Project. It’s not a formal thing for the project, but useful as a way for me to govern the openEHR related artefacts for my modelling purposes.

View fullsize

Only two archetypes have been added for this project, otherwise all are reused from the openEHR CKM. Template for two data sets have been created, plus 7 reusable subtemplates for reuse of R1 & R2 constrained models.

You can see the master template for the Aboriginal and Torres Strait Islander health check which is still a very early draft, firstly needing confirmation of the content, then more constraints applied as we nail down the first draft content with the stakeholders. It is fascinating to see how paper forms built without consideration of clinical data can require significant refining and revision - but that is the story for another blog post…

What I want to emphasise are the 7 ENTRY level templates, each prefaced with R1 or R2. You will note that I’ve created R1 and R2 versions of Tobacco smoking summary and Family history item. These are the constraints applied for phase/release 1 and 2, with R2 demonstrating the extended content agreed only last week. R2 Education and R2 Housing are templates for new content on Social determinants of health to be included in this next phase.

R2 Occupation is a template comprising the EVALUATION for Occupation summary and it’s repeating CLUSTER for each occupation or role. They concurred with our openEHR community decision that the scope should be broader than just ‘employment’ but embrace all roles in life including ones that didn’t focus on paid employment. I actively tried to persuade the clinicians to reduce this amount of content for this phase, but after demonstrating how the model could potentially be extended with more detail about each job or role in the future, they wanted it all and they wanted it now! Not so much for SDOH purposes but to support generation of medical certificates and a more comprehensive occupation history.

As the Australian information models get agreed, finalised and published, I intend to use this incubator and these templates to support my modelling efforts for this project. I need at least this level of project governance to keep track of changes and evolving content.

Imagine if the FHIR profiles were built to match these clinical models – likely not on a 1:1 basis given the technical constraints, but in principle - one templated concept matching a known set of FHIR profiles. This means that as easily as I drag and drop a subtemplate into my next data set, we could conceptually do the same with the matching FHIR profiles. If the project modelling work and the FHIR profile generation were aligned and changes synchronised, this would showcase the build once, reuse many times principle across both the openEHR and FHIR efforts.

Clearly the FHIR tooling is not yet available to support this work. CKM can’t accept FHIR profiles at present, so we’d need to use GitHub or similar. But with potential Ontoserver integration to CKM and EHRbase, there’s a pretty neat little ecosystem evolving.

We’re getting closer to a sweet semantic ecosystem here. It just takes a willingness to play together and abandon the turf wars. Participants are raving about the process and return to each meeting with much enthusiasm. I absolutely commend David and Kate’s leadership to initiate this collaboration here in Australia - it demonstrates a depth of vision that has not been present for a long, long time.

If we can continue this process, I’m feeling more optimistic about Australian #healthIT than I have for a long time.

State of the clinical modelling program and international CKM

I sent this email to the openEHR lists yesterday. Published here for broader sharing, and perhaps as a resource for future benchmarking…

---

22 July 2019

Dear colleagues,

We recently passed the eleven-year anniversary for the first upload to the international CKM – the body temperature archetype. As Europe readies itself for summer holidays and the clinical review season slows down, it is a good time to review the progress of the openEHR clinical modelling program.

 Roughly 6 weeks ago I created and downloaded a number of reports from CKM. I’ve spent some time analysing the data and thought I’d share what I learned with you.

This exploration was triggered by a tweet from Ewan Davis last December asking:

“How many person hours do you think has gone in to creating the openEHR archetypes available via CKM - I think it must be in excess of 100,000 hours (40 person years)”

 It took a while to gather the data and propose reasonable assumptions so that we could make time and effort estimates, but here goes…

CKM stats

(As of July 5 2019):

1. Community

   • Registered users – 2239

   • Countries represented – 95

2. Archetype library

   • Total archetypes – 785

   • Active archetypes

• Published – 93

• Published as v1, needing reassessment - 6

• In review – 31, with at least 7 about to be published

• Draft - 351

• Initial (in incubators) – 110

• Proposed archetypes - 10

Behind the scenes

(from CKM reports, May 2019)

1. Number of archetypes which have completed or are undergoing a review process – 130

2. Number of review rounds completed - 295

3. Number of archetype reviews completed by all reviewers – 2995

4. Number of unique reviewers – 272

5. Reviews completed per review round – 10.15

6. Average number of reviews per archetype – 23.04

7. Average number of reviews per reviewer – 11.01

8. On average, during the past 12 months, approximately 100 unique reviewers logged into CKM on 900 occasions per month.

Time estimates

This is where things become interesting…

This equates to roughly 8.5 person years.

Obviously, I have made some assumptions about the average time for many activities and if we factor in incidental conversations or pondering modelling conundrums or cross pollination between CKMs we could reasonably increase the estimate to 10 person years. However, try as I could, there was no way I could justify bumping them up in order to achieve estimates of 20, much less 40, person years.

These numbers reflect the work for archetypes that are owned and managed in the international CKM. This includes an estimation of work done by the reviewers and editors from the Apperta and Norwegian CKMs if their archetypes are now residing in the international CKM, or multiple CKMs. It does not reflect the work done on reviews from the now retired Australian CKM, although estimates of design time have been part of the assumptions.

I interpret Ewan’s estimate to reflect his impression that the effort to achieve what we have done so far was huge. I too believed that the effort was epic, but in my head it was still only in the ballpark of about half of his initial estimate. That the actual effort appears to be only 8-10 person years totally surprised me. Initially my figures were considerably lower; I did go back to the figures and tried to massage them upward because this is obviously a rather inexact science, more like an educated guestimate, but this is as far as I feel comfortable going.

In addition, Thomas Beale estimates that on average there are 14 clinically significant data elements per archetype, according to the ADL Workbench. These are the relevant data points that we design, review etc. So 785 active archetypes x 14 data points/archetype suggests that we have a library of approximately 10,990 data points, none of which are duplicates or overlapping in the governed archetypes. And if we agree with my estimate of a total of 16289 hours, the amount of time per data element is 16289/10990 - only 1.48 hours each, covering design, review, maintenance, governance.

 What conclusions can we draw?

• Firstly, modelling ‘openEHR style’ seems to be quite efficient, surprising even those of us who are involved daily and secondly, this unique collaborative and crowdsourced approach to standardisation of clinical data is working well. On top of that, if you remember that more than 95% of the editorial work and reviewer’s time has been volunteer, then it this truly has been an extraordinary community endeavour.

• Secondly, the ratio of reviewer time to design time is noteworthy – 1498 hours of review, compared to 10437 hours of design. In effect, we have successfully minimised reviewer effort by making each 30-minute review count as efficiently as possible, and that has been achieved by attention to detail and spending time investigating and developing strong design patterns before we send them out for review. Over the years we have made some bad design choices and had to rethink our approach. Gradually we have been developing some good patterns and, before you ask where we have documented them, I will point you to the published archetypes – each of them functions as a potential pattern for the next archetype we intend to develop – we reference and reuse the patterns as much as possible. In this way our library is growing, and our modelling is improving. As an example, a current area of serious rework is the Physical examination archetypes which are being ‘renovated’ at present. It does make me think that for every hour spent in design it is a good investment of time and effort – that may not seem apparent in the early days, but I think that we are finding that it is paying off for the archetypes that we are designing years later, based on the (good and bad) learnings from those earliest archetype designs.

• Thirdly, we have some insights into the modelling community, and for the first time we have some idea about the level of activity by those with various roles and activities. We also have an estimate of the size of the data library at data element level, so that we are able to compare to other similar modelling efforts elsewhere in the world.

I would particularly like to thank my co-lead, Silje Ljosland Bakke, and Ian McNicoll for their dedicated efforts, and of course to all of the other Editors, Reviewers and Translators who have so generously volunteered their time and expertise to create a strong free and public foundation for digital health data standards. 

We should all be very proud of this work. This will be our legacy that will live on after well after we’ve all long retired.

Kind regards

Heather Leslie

Representing FHIR clinical content in openEHR

Over the past few days I’ve attempted the task of representing the FHIR Skin and Wound Assessment profiles using openEHR archetypes.

I note that there are three Skin and Wound Assessment FHIR Implementation Guides available online:

1. "Full CIMI" version – which is the one I chose to model;

2. Federal Health Information Model (FHIM) version; and

3. Mitre’s ‘mini-CIMI’ version.

I’m a clinical modeler, a clinician by background, so I’m always looking at how we can best represent clinical data in ways that are friendly to grassroots, non-technical clinicians of any sort. The FHIR IG is a tough beast to decipher, despite my experience of gathering patient requirements and turning them into implementable specifications for more than a decade.

My intent as I started this work was specifically that as a clinician I didn’t want to have to fully understand the FHIR representation. I wanted to be able to look at the clinical data and recreate it using my familiar openEHR tooling and representations.

I estimate that it has taken me nearly 2 full days of work – much more than I anticipated - and mostly to trawl through the myriad of online pages for each FHIR resource and associated profile, then to piece together the connections visually so that I could create/reuse appropriate openEHR archetypes and templates. The openEHR representation didn’t take long, largely because of reuse. It was the analysis that was the time killer.

Despite all of that effort, I am still not confident that I’ve got it right. But the following post reflects my experience, plus learnings and some queries.

My modelling assumptions

The three base clinical representations that I’ve gleaned is the Wound Presence Assertion, the Wound Absence Assertion and the Wound Panel Assessment.

Rightly or wrongly, my openEHR templates assume the following:

• ‘Wound Presence Assertion’ profile is the equivalent of our recording a diagnosis and overview of a wound – so I’ve created a Wound Presence Assertion template, based on the EVALUATION.problem_diagnosis);

• ‘Wound Absence Assertion’ profile is the positive assertion that a wound is excluded or not present; and

• ‘Wound Assessment Panel’ is the equivalent of clinical examination findings about a single, identified wound – so I’ve created a Wound Assessment Panel template, based on the OBSERVATION.exam archetype.

• If FHIR components were modelled as 0..1 occurrences then I added them to the archetype at the root level – see the size measurements and edge related data elements in the Examination of a Wound CLUSTER archetype.

• If FHIR components were modelled as 0..* occurrences then I added them as repeatable internal cluster groupings – see the Tunnelling and Undermining clusters in the same archetype.

openEHR Representation

You’ll note that I haven’t created a template for the Wound Absence Assertion. I’ll be curious to understand the use case from the FHIR modellers but I cannot understand the use case where a clinician will explicitly record that a wound is absent, not there. They will record that a previously known wound has healed over, or that the skin in the area is normal. But to record that a pressure ulcer on the right buttock is absent – I don’t think so, not even in a medico-legal scenario! If someone can provide me with a use case, I’m happy to reconsider…

I’ve uploaded the resulting two templates and the associated archetypes to a public incubator on CKM. You can view them all here: https://ckm.openehr.org/ckm/#showProject=1013.30.9.

The two templates comprise 6 reused archetypes, and I created two new archetypes:

• Wound assertion details CLUSTER to extend the Problem/diagnosis archetype with FHIR and wound specific content; and

• Examination of a Wound CLUSTER representing the examination findings of the wound.

The clinical content within the FHIR IG is generally very sound, and I can see that a lot of work has gone into the development of it and especially the value sets. It is a very useful resource, if you can discern the content in amongst all of the rest of the tech spec. I must admit I got very frustrated and very confused and had to restart a few times.

Once I’d teased it out, I’m very grateful to those who did the hard yards of clinical analysis that underpins this Skin and Wound assessment. Credits on the IG attribute the domain content analysis to Susan Matney from Intermountain Health. I have some other questions for clarifications and would like to discuss a few issues but otherwise this is a really sound piece of work and I’m very pleased with the end result in openEHR.

The templates are up on CKM for you to take a look at:

• Wound Presence Assertion template

• Wound Assessment Panel template

The rather ugly CKM default UI for templates is deliberately designed for displaying the individual data elements and most of the relevant constraints – much easier for a clinician to be able to review and approve from a content point of view. CKM doesn’t display the URL to value sets, although if you download the .oet and .opt files you will find them safely stored within the code.

Questions, issues

General modelling

I’ve reconfirmed that the openEHR reference model is a godsend. That the data types have set attributes is a given and doesn’t need to be represented over and over again is something I now appreciate enormously, including null flavours etc. Brilliant. There is so much endless repetition in the FHIR resources for RM related data and it takes ages to locate the real clinical data amongst everything else.

View fullsize

Wound Presence Assertion

• Anatomical location of the wound is only recorded in this model. I’m not so sure about whether this is a good idea. I think that anatomical location should also be modelled for each examination event (ie included in the Wound Assessment Panel) so that what is being examined is clear and unambiguous. At present the anatomical location of the wound represented by the Assessment Panel appears to only be associated with the Presence Assertion via a common identifier (WoundIdentifier).
  Note that I can only find the Anatomical location model in the Logical model and not in the Profile, so maybe I’m missing something?

• In the logical model, Laterality is represented as ‘Unilateral left’, ‘Unilateral right’ and ‘Bilateral’. I totally agree with the left and right but I have a major problem with identifying one (or more) wound(s) as ‘bilateral’. ‘Bilateral’ should probably not refer to direct observational exam findings at all, but is may have some value in recording conclusions. For example, in examination of each ankle, the finding of pitting oedema may be made, but each side is likely to need explicit recording of different severity or association with ulceration etc, so the findings from each side should be recorded one separately. However, the conclusion of the clinician, at a higher level of abstraction in a physical findings summary or as a diagnosis, may well be bilateral ankle oedema, but it is not advised for use at the point of recording the examination findings.
  Given that this representation of anatomical location is in the Assertion and as best I can tell the concept being modelled is a single Wound (SNOMEDCT::416462003), the notion of a bilateral wound is not appropriate.

• Clinical status values – now these were tricky. We have an existing ‘Problem/diagnosis qualifier’ archetype. It is a messy beastie, largely because clinicians are notoriously messy at how they record these kind of things. The FHIR value set used in this template comprises values from 4 (yes, four) data elements that we have identified as having completely different axes in our archetype. The FHIR value set is drawn from parts of each of our ‘Active/Inactive’, ‘Resolution phase’, ‘Remission status’ and ‘Episodicity’ data elements.

View fullsize

Wound Assessment Panel

• As above, I’m concerned that there is no explicit recording of the Anatomical location/laterality parameters so that we can track examination findings over time, especially if there are multiple wounds. An identifier as a connector seems a little flimsy for me.

• The concept seems to be a generic wound, but the data elements seem to be focused on recording the findings of an open, ulcerated lesion in reality. If the wound was a long laceration, for example, there are parameters missing such as beginning and end point, relative location to a body landmark. An animal bite might also be difficult to record at the best of times, and something simple like a narrative description would also be helpful.

• There is a data point about a pressure ulcer association, with two values – device and pressure site, which reinforces the focus on a pressure ulcer and is very specific. I have modelled that same data point as a repeating cluster pattern of a ‘Factor’ associated present/absent attributes to make this model more applicable to a range of wounds.

• Tunnelling is a tricky concept to model. In the FHIR model, tunneling seems to assume that the tunneling radiates out from the edge of the wound but doesn’t allow for deep tunneling from the middle of the wound to be recorded.

• The use of a clockface direction is common in a few clinical scenarios, including this one. However the openEHR experience has identified that in order to represent it accurately a few assumed items need to be recorded, such as identification of the central landmark around which the clockface is oriented, as well as the anatomical landmark that identified the 12 o’clock reference point. See our recently published Circular anatomical location archetype.

• The Undermining model is represented in the archetype/template as a repeating CLUSTER to allow multiple measurements of the amount undermined in different directions. In the FHIR model, the length and direction are both optional. In the archetype I’ve made the length mandatory as there is no point recording a direction by itself.

• I did not model exudate volume in the template as it is measured, and it is not clear to me how you measure a volume at an examination (assuming this assumption about the recording context is correct). Rather it is usually recorded over time, and so does not seem to belong here. I did model the Amount, with a value set that is not available to view, as I assume it is descriptive and could be appropriate here.

• Episode is modelled within this context, however it seems to me that it is probably better placed in the Assertion. See the ‘Episodicity’ data element within  the Problem/diagnosis qualifier archetype.

• Similarly ‘Trend’ feels a little tricky in the context of examination findings. I guess that it could be useful if part of a sequence of exam findings and if it correlated back to the longer timeframe of ‘Course description’ narrative within the Problem/Diagnosis archetype.

• There are a few data element which record Yes/No/Unknown answers as though it is answering a questionnaire within the context of recording exam findings. In openEHR we tend to record these as findings that are Present/Absent/Indeterminate so that we can bind, arguably, more meaningful codes to each value and not mix history-like recording with observations.  

---

For a grassroots clinician to review the content there is no doubt that the IG is next to impossible. Perhaps the FHIR community has a more clinician-friendly view that I’m not aware of. It is absolutely needed!

Wouldn’t it be great if FHIR and openEHR communities could collaborate such that this CKM representation could be used to support the FHIR work… but I’ve probably said that a million times… or maybe more. Perhaps one day <sigh>.