"Ontological Style Criteria" to create good archetypes (diabetic foot example)

Clinical Ask an editor
1

PROBLEM
In the past I have worked extensively on semantic standards in CEN and HL7, but I am not familiar with openEHR. I need to understand what is the right way to create archetypes.

MAIN GOAL
From my previous experience, I was involved in an initiative of the Italian industrial association (Confindustria).
They want to disseminate to clinicians and vendors a list of possible ‘useful’ data in situations that are frequent in major chronic diseases and that involve different professionals in terms of culture, purpose and context.

In this way in Italy we could (perhaps) start to create a critical mass of quality data, originally created in a way that is more suitable for multiple use by different actors and for different purposes.

WORK PLAN
We have gathered the consensus of both the 2 Italian diabetes societies on a list of about 150 relevant items; we have started the work on the other diseases .
We have agreements with HL7 Italy and IHE Italy for their future role.
By the end of the year we want to have harmonised data lists for 5 pathologies, ready to be structured with openEHR, and to understand how to manage them with FHIR.

QUESTION
I have prepared an example on the diabetic foot, to understand what style rules should be applied when creating new archetypes, homogeneous with existing ones.
In the file below I copied the SNOMED CT codes involved, and the subset of terms on diabetic foot agreed by the Italian diabetologists.
Then I’ve put the ontological structure inspired by that sample.

See: Dropbox - ROT31-model-diabetic foot.docx

What is the best way to build an archetype?

1 Like
2

Hi Angelo, and welcome to the community!

I’ve had a super quick look at your document, and I have some basic ideas and comments:

  1. Context wise your data set looks to me like an outpatient clinic note or summary about diabetic foot issues. Knowing the exact context is important to be able to give good guidance, but in general I’m pretty confident that this should be a template consisting of several archetypes and not one single archetype.
  2. Relevant archetypes would probably include Problem/diagnosis, Symptom/sign, Physical examination findings + a number of Examination of [anatomy] cluster archetypes. It’s likely many existing archetypes can be used as is, some may need extending, and some may need to be made from scratch.
  3. There’s a content and style guide for archetypes at Archetype content & style guide - openEHR Clinical - Confluence
3

Interesting!! I thought it was actually more about diabetes registry reporting, but absolutely agree -the first thing we need to be clear about is the exact purpose. Is this about primary data entry, or reporting?

Do we have some sort of proposed data entry form or clearer idea of the purpose of the dataset? Is this to report the outcome of a single clinical visit or part of a broader diabetes registry?

but agree that these will be multiple archetypes, as you have suggested and mostly already in existence along with some sort of ulcer grading score ? this is University of Texas Diabetic Foot Ulcer Classification System Figure 2. [The University of Texas Wound Classification System.]. - Endotext - NCBI Bookshelf or similar , which would be its own possibly new archetype.

1 Like
4

Siljeb, thanks for the reply.
I am sorry if I have caused any confusion, so let me first clarify the context and the underlying problem.

Our focus is on the deployment of the chronic care model for 5 diseases.
It implies a set of professionals around each patient, plus the patient and the caregiver.
They need to share a lot of clinical data.

However, each of them has a different perspective on the patient, according to their culture, role, and context.
This means that the same item regarding the patient is perceived and “shaped” in a different way by each of them, with different level of detail and according to different goals.
In other words, they tend to use different codes to describe the same topic, and a different set of codes to describe the situation as a whole.

For example, two users adopted SNOMED CT, but one has selected
code 398819009 for ‘Diabetic foot at risk (situation)’
and the other used
code 308106006 for ‘On examination-Left diabetic foot at risk (finding)’.
While they intend to represent the same reality, the concepts underlying these codes do not correspond to each other, in terms of granularity and category, making exact mapping difficult or impossible.
In fact, the two users formalised the same underlying reality in two different categories (‘situation’ or ‘finding’?); moreover, only the second user specified details on process (‘examination’) and laterality (‘left’).

Therefore, our goal is to use openEHR to assist the users to align as much as possible their way of describing the patient’s reality, suggesting a predefined set of possible terms and codes, at least in the most frequent situations.
These terms and codes should in future be present both in clinical pathways handbooks (for education) and within the software (with openEHR!).

I chose the diabetic foot out of the 150 items agreed by the professional societies, to be used as an example to construct the first of many archetypes that will be needed to cover all the items.

In the file “ROT31” I present a draft of a possible ontological structure around the diabetic foot, together with the terms I used to construct it.
There are many other ways to refine that structure, so I would learn how to build it in line with all the archetypes already adopted.

Before I go on to produce the actual proposal of the different archetypes that I will have to construct, I need to understand whether I am on the right track for the creation of any ontological structure in openEHR.
This is why I have renamed this thread as ‘ontological style criteria’ (different from the graphical and administrative style rules set out in the style guide you pointed out to me).

5

yes, Ian, I would say that our intent is to use the archetypes mainly for a data entry form.

However, I assume that adopting a ‘good’ archetype as early as the data creation phase propagates the quaity to the rest of the system (after all, isn’t that the purpose of openEHR?).

In my view, intercepting the moment when the data is created means improving the quality of each single item and the completeness of the cluster of data in a given situation.

Thus these well defined data, thanks to openEHR, can enable the software to trigger functionalities and calculate the most important clinical and managerial indicators, using data created by different users.

As I wrote in the other reply, diabetic foot is only a first example (perhaps one of the most articulated), out of the 150 items for diabetes agreed by the clinical societies as the most relevant for treatment and management purposes.

However, my problem (at the moment) is not discussing the diabetic foot, but learn how to render the terms given to me by our scientific societies and those taken from SNOMED as a ‘perfect’ archetype.

6

To intrigue those who do not yet feel inclined to download the file in my the initial post, here is the draft of my ontology model that I would like to refine according to the principles of openEHR.
For example, can a ‘lesion’ have the value ‘non-diabetic foot’, i.e. the absence of a lesion?
Or can I leave ‘other bone infections’ and ‘unspecified bone infection’, which are clearly an artifact derived from a classification, i.e. ICD, and thus have an interpretation that strictly depends on that context?

Please note that labels (e.g. self-care, pathways, …) are provisional, because I still have to figure out how to make them context-independent for the archetype

‘diabetic foot’ has children

  • self care [able to manage foot care]
  • pathway [seen in diabetic foot clinic | did not attend diabetes foot screening]
  • when [on examination]
  • reported [problem | complaining of foot symptom]
  • laterality [right | left]
  • amputation [amputation | amputated forefoot | amputated midfoot | amputated foot | absent foot | major | minor]
  • lesion [non-diabetic foot | ulcer | deformed foot (hammer toes, claw toes, hallux valgus, prominent metatarsal heads…) | neuropathic foot (hyperkeratosis, anhydrosis, areas of hyperpressure) | vasculopathic foot | mixed foot | osteomyelitis / Charcot osteopathy / periostitis | skin and subcutaneous tissue infections | gangrene]

where ‘lesion’ has children:

  • osteomyelitis [acute osteomyelitis, tibia and fibula | acute osteomyelitis, bones of the foot | chronic osteomyelitis, tibia and fibula | chronic osteomyelitis, bones of the foot | osteomyelitis unspecified, tibia and fibula | osteomyelitis unspecified, bones of the foot | other bone infections of the leg in classified diseases | other bone infections of the ankle and foot in diseases classified elsewhere | unspecified bone infection, tibia and fibula | unspecified infection of bone, foot bone]
  • skin [cellulitis and toe abscess | phlegmon and abscess,unspecified | other phlegmon and abscess,lower limb except foot | other phlegmona and abscesses, foot except toes | unspecified phlegmon and abscess of finger]
  • gangrene [atherosclerosis of native limb arteries with gangrene]
  • ulcer status [absent | present | healed | at risk | at low risk | at moderate risk | at high risk | previous (absence at the time of observation of a full-thickness lesion) | atherosclerosis of native limb arteries with ulceration]
  • ulcer evolution [increased risk]
7

Well, I have tried to compare my model with some of the current archetypes and clusters.

I interpret that I could use the cluster “Examination of a foot” as a basis, and use:

  • the item “System or structure examined” for my “laterality” (already in the cluster)

  • the item “Examination found” for my “lesion” and “amputation”

  • the item “Examination not performed” with the associated “CLUSTER.exclusion_exam”, to say that it was not examined

  • the item “No abnormality detected” for the absence of injury

  • the item “Clinical interpretation” for the values “non-diabetic foot” and the values as [at risk | at low risk | at moderate risk | at high risk | at increased risk].

REMAINING ISSUES

Can the cluster “Examination of a foot” have a child “Examination of a diabetic foot”?

How can I handle my children of “lesion” and “amputation”?

How can I represent the following items?

  • self-care [able to manage foot care]
  • pathway [seen in diabetic foot clinic | did not attend diabetic foot screening]
  • when [examined]
  • reported [problem | complained of foot symptom].
8

Making the assumption that the context of the patient encounter is a specific diabetic foot outpatient clinic or similar, I’ve created a mockup template including several different archtypes selected from ckm.openehr.org to try and capture your requirements. I purposefully haven’t constrained out any data elements in the archetypes used, to show the possibilities within each of them, and for simplicity I’ve only used the free text terms from your document, not the SNOMED CT codes.

For making a real template for actual use, a lot more work would be needed, and possible a couple more archetypes would need to be created or an existing one extended.

https://tools.openehr.org/designer/#/viewer/shared/Pz9zaGFyZWRJZD0xJDhiZmU5MDc0Mzk0OTRiNTM4MWZlOWZiOTdjZDA0MzZj

1 Like
9

You beat me to it!! The only slight difference I might have modelled was to use Problem/diagnosis as Complications to handle the, rather than Precaution, to handle the amputation code list but that probably just needs further discussion to clarify the requirement.

I think key thing here @Angelo_Rossimori is that openEHR (and actually FHIR) is working from a different ontological basis - the perspective of “documentation of clinical information”, not of the associated ‘biomedical ontology’ of the condition itself

So we are modelling an ‘assessment of the diabetic foot’ not ‘the diabetic foot’, as such. That is why we see information structures such as ‘Reason-for-encounter’ and ‘problem/diagnosis’ , within an overall ‘Assessment of foot’ in a diabetes clinic context. We would not really recognise an entity like ‘Diabetic foot’ as starting point for the model. Of course I think Silje has captured the clinical requirements very well but it might seem at-odds with your original ontology of the diabetic foot.

1 Like
10

Thank you! You have made me come up with so many ideas…
Give me some time to reorganise them, I don’t want to waste your time explaining everything to me.

In the meantime, I’d like to clarify the context.
I was involved in this initiative of Confindustria (the Italian industrial association), because of my past on semantic standards some 30 years ago [1].
With Alan Rector, in GALEN and GALEN-in-use we dreamt of the “universal” ontological model.
Instead, I really like openEHR’s approach of putting together a set of ontological fragments on which to hang clinical (and other) data.

The problem now is to find ontology experts in Italy, who are not necessarily the software developers.
That is why I am trying to grasp the logic behind openEHR, to build the first examples of ontological fragments on 150 items for diabetes, and a few hundred more to come by the end of the year on 4 other pathologies.

The [assessment of the] diabetic foot was just a good example to get a grip on how to set up the ontology fragments of openEHR.

I would say that my real purpose, if you see my posts on Linkedin, is to guide the creation of quality clinical data in the minds of healthcare professionals.
So yes, one preliminary goal is clinical data entry, but then gradually also:

  • the construction of ‘code-independent’ repositories
  • the production of smart software to meet the information needs of all actors around the patient,
  • the construction of effective dashboards for managers.

I am hesitant to use the tools offered by openEHR right away, because first I have to better understand how to interlock archetypes and clusters.
I will digest your suggestions, study a bit and then return to you ASAP.
Thanks again, your advice is already very helpful!

[1] e.g. Exploiting the terminological approach from CEN/TC251 and GALEN to support semantic interoperability of healthcare record systems - PubMed

1 Like
11

Exactly. If the intent was to record for the first time “omg, this patient has had their foot removed😲”, I’d totally go for Problem/diagnosis. While if the intent was to record “hey, this is a thing we need to remember about this patient☝”, Precaution is probably the way to go.

1 Like
12

And these are exactly the aims of what we are trying to do. Manual data capture is only part of the story - the information is going to have to be managed in a way that it supports all of these outputs but fundamentally it has to support patient journeys and the professionals supporting those journeys.

Biomedical coding systems and ontologies are part of that story and Alan Rector’s famous diagram captures the need for interplay very well.

image

Some versions of this diagram refer to ‘Models of Meaning (biomedical ontology)’ vs ‘Models of use’ which I think is misleading since it bundles User interface adaptations together with attempts to define standardised fragments of information context (alongside the biomedical ontology).

1 Like
13

Well, so far I would say I am satisfied.
I know enough to start looking for Italian ‘health oncologists’, to reason further with them.
As I had written:

The problem now is to find ontology experts in Italy, who are not necessarily the software developers. That is why I am trying to grasp the logic behind openEHR, to build the first examples of ontological fragments on 150 items for diabetes, and a few hundred more to come by the end of the year on 4 other pathologies. The [assessment of the] diabetic foot was just a good example to get a grip on how to set up the ontology fragments of openEHR.

Let me stress that the main reason I am interested in semantic interoperability today is to ensure that the set of interconnected ‘priority clinical data’ available at a given stage of a clinical pathway are natively conceptualised by each professional for multiple uses, to then satisfy their own and other actors’ information needs:

I would say that my real purpose, if you see my posts on Linkedin, is to guide the creation of quality clinical data in the minds of healthcare professionals.

Repeated for many clinical pathways, especially on chronic diseases, it allows to build very large repositories with consistent and high quality clinical data from multiple sources.
A huge effort will be needed to reach a consensus within the scientific societies to declare what these priority clinical data lists are.
For this openEHR can be an excellent tool to validate and harmonise the lists of ‘priority data’ produced by each scientific society and across the various specialties (and of course to deploy effective solutions to support real cure and care processes).

I am very grateful for your help.
I hope to return to these discussions soon, together with other Italian colleagues!
Angelo

1 Like