I’ll just add a small reality check in here. Models of the sort created in openEHR will report the following kinds of things with respect to procedures (assuming some initial appropriate Dx):
the order & booking
procedure note, i.e. standard summary of what was done
follow-up care orders and actions.
The long list of ‘new terms’ you mentioned above are taken care of by terminology such as Snomed, not openEHR. openEHR data will record the procedure type and location using Snomed (or some other) terminology, potentially one day in the form of sophisticated post-coordinated expressions (this has not happened yet in the field).
In the worst case, let’s say there is some new procedure that isn’t even listed in the terminology - it will just be recorded as text.
So, as an overall challenge for industry, the ongoing churn in ‘concepts’ is mostly a challenge for terminology. openEHR takes care of the structures of how to record the various kinds of investigations, notes, summaries, etc etc but the anatomical / physiological and procedural specifics will come from terminology.
Where change is a challenge for openEHR is where any of those specifics are encoded directly into the structure of the information, not just the values. Examples: imagine medicine invents something to replace systolic / diastolic / MAP BP with; imagine 12 lead ECGs are replaced by some new kind of device (already happening), then openEHR modellers will have to react.
Here’s a blog post on semantic scalability, containing some estimates on how large the numbers might be, both absolute and rate of change.
The whole design of openEHR is predicated on change being constant, and being able to technically keep up without a break in service in all those 24 x 7 x 365 systems.
I think there is a lot of truth in this statement - not many people outside openEHR have witnessed the power that comes from the reuse of well-designed, stable archetype patterns, combined with strategic use of terminology.
Anyone can easily whack some data elements into an archetype and start using it for local purposes, but if we want to create a coherent ecosystem the data needs to be designed with careful consideration about how it fits within, and complements, the entire modelling ecosystem. This takes some time & forethought, but surprisingly is often much less onerous than anticipated; the rewards for the initial implementers and all those reusing it can be enormous. This requires a deliberate design choice - with consequences for each option.
The design of the published ACTION.procedure archetype is clearly intended as a framework, as the Use states, for use in the simplest, everyday procedures through to the most complex imaginable. This archetype is well-used in many implementations, but this is where the modelling momentum/resourcing has faltered. It is critical that the archetypes that we design to extend procedures further are created in the context of the broader surgical domain. There is no doubt in my mind that a huge number of standardised patterns that can be elucidated in collaboration with clinicians - think ‘approach’, ‘closing’, ‘intra-surgical exam findings’, etc - there will no doubt be many. And while none of these will be specific for bypass surgical documentation, many should be suitable to provide the general context for the specific bypass use case.
The concept of a surgical bypass is really interesting in this context and @sobath’s mind map is a great initial insight into the clinical requirements - clearly, they have identified some valuable, emerging patterns. I have so many additional questions for @sobath , especially to determine whether a maximal ‘bypass’ pattern can be archetyped for all bypass situations and how we cater for variables required in specific situations.
At some point, we will probably need specific ‘end point’ archetypes that are simply unique for each individual procedure, such as this rather old Myringoplasty procedure example - although I acknowledge this archetype could also be revisited to utilise better reusable patterns.
The art of skillful clinical modelling resides in the identification of the repeating patterns that underpin clinical practice and its associated documentation. When we identify a practical, reusable model, we know we have been successful. When we create a ‘dead end’ archetype only applicable for a single use case, it should be a trigger to question our design - sometimes it may be quite appropriate; but sometimes we will have gotten it terribly wrong.
The surgical domain has had very little strategic modelling activity to date - it is largely a greenfields domain. Identifying the next level of reusable CLUSTER patterns for nesting within, and extending, the ubiquitous ACTION.procedure should be the next priority - patterns which represent the activities and findings common to many surgical activities. Unfortunately, I suspect most implementers are utilising the 'quick & dirty approach for modelling extensions for ACTION.procedure in their clinical systems.
As @joostholslag suggests, we need resourced modellers working in collaboration with savvy surgeons to plan and develop a coherent surgical domain ecosystem of archetypes that the openEHR community deserves.
Many thanks for illustrating the bypass archetype and the link to the archetype designer.
If there is an effort to model surgical concepts I am willing to help with some input into the following specialities.; vascular surgery, endovascular procedures, transplant surgery, gastrointestinal surgery.
Is there an LMS or an online course for someone like me to learn more about modelling?
Thank you for pointing out how you can incorporate existing archetypes to document bypass surgery.
My illustration was to show how I think of a surgical concept relevant to my speciality and the type of information I would want to retrieve from the documentation.
Concepts like suturing technique and intraoperative anticoagulation are not unique to the bypass and should be captured in other archetypes and linked to the bypass concept. For my understanding can you explain the definition of a concert in openEHR modelling?
If you check on Pubmed, there are more than 180,000 articles on the word “bypass”. This concept will provide valuable information to the surgeons, and researchers to identify and extract information such as patency and its relationship to the conduit used etc. It will also be useful to the industry engaged in the development of bypass conduits.
To answer your query regarding the project we are working on; we are attempting to identify
concepts like the operative procedures, relevant OPCS codes, prosthesis used, and surgical consumables used during surgical procedures to document and maintain registers that any surgeon can use. We are employing NLP-NER techniques and trying to identify the best model for this purpose.
Thanks for the explanation on how models are created and used in openEHR.
Examples you have given ;
Are more relevant to managerial tasks that are useful in running a clinical service like a hospital. But if I want to identify information like;
Is bypass more durable for treating an occluded external iliac artery than a “covered stent graft”?
Compared to bypass surgery, is endarterectomy more durable for treating occlusions/stenosis at the level of the common iliac artery?
To answer the above questions you need to model surgical concepts like “bypass”, “endarterectomy” and “covered stent” analogous to blood pressure and ECG. Please correct me if I am wrong about these concepts as I am still trying to grasp the basic principles of openEHR.
My approach to the Operation report would be to create a template using COMPOSITION.report at the root level, then adding a variety of ENTRY-level archetypes, extended as necessary with CLUSTER archetypes.
In the attached example:
Existing archetypes
COMPOSITION.report
ACTION.procedure
ACTION.medication
OBSERVATION.imaging_exam_result
OBSERVATION.capillary_refill
Proposed new archetypes
Surgery-specific CLUSTER archetypes related to general surgical concepts such as approach, closing etc for nesting within the ‘Procedure detail’ SLOT in ACTION.procedure
Vascular surgery-specific activity-related archetype/s for nesting within the ‘Procedure detail’ SLOT in ACTION.procedure
ACTION.imaging - to record the process of planning to completion of an imaging examination/procedure
Terminology value sets - used to populate the myriad of procedure and imaging test names, device names, consumables etc. This is where you’d find “bypass”, “endarterectomy” and “covered stent" and all the rest of the procedure names - a value set used in the ‘Procedure name’ data element, within the ACTION.procedure archetype.
In this way, we should be able to build up a common-ish, reusable pattern of archetypes as building blocks that form the foundation for representing the most common types of vascular surgery. Then we can aggregate and constrain the archetypes to suit a typical vascular surgical process, such as your use case.
Adding relevant terminology value sets will support further refinement and differentiating between the same type of surgery performed in different locations or under different circumstances.
Additional archetypes may need to be added for outlying situations such as when complications occur or more complex procedures are undertaken eg combos, pregnancy, paediatrics etc.
Many thanks for your explanation and the suggestion how you can modify the operation note template to capture these surgical concepts.
When I was designing the my d map for bypass surgery I was thinking on the more border reach as you have suggested in your previous post. As bypass can be done not only blood vessels but also for bowel, billiary system.
Don’t let me discourage you from thinking about all types of bypass! We usually have the opposite problem of people modelling for a single purpose.
I don’t have enough detailed insight to say if your approach could work or not. The pattern you showed in the mind map works in theory, but we need a plan for where and how the specific details for bowel, biliary etc would also be modelled and whether it works for each possible context.
The only way to work out what works best is to model within a plan for the ecosystem - it’s an investigative process in practice. If we just add archetypes piecemeal and without a strategy, we run the risk of ending up with disconnected fragments. This is the ‘art’ I was talking about in a previous post. Trying a design, testing it, maybe failing - there are many archetypes that were good in theory but we found didn’t work in the context of the bigger ecosystem view.
For example, we used to model all measurements in a single archetype - you know, length, height, width, area, volume of an ‘object’ - good in theory, especially from a potential reuse point of view. We thought this would be a ubiquitous pattern but querying on a standardised data element of ‘length’ was found to be of little value & removing irrelevant measurements in every template became a modelling burden, so we eventually found it was actually easier just to add relevant measurements into each exam archetype, and only the ones that were relevant for each context - this works better. We learned that sometimes we can overthink patterns as well.
Now you really are into details. These detailed procedures would be modelled with a process model, such as these ones you can see here, expressed in openEHR Task Planning formalism. (This formalism is still under development.) Note that this formalism includes decision rules / pathways, which could implement the kinds of choices you mention (i.e. what method is better in what circumstance), and indeed, some ‘plans’ can be mainly formed of such decision rules.
Other ways to express such processes include BPM+ (also emerging, and I guess about 2y away from implementation in tools). There are also various products on the market, not standardised, but that would allow you to build some kind of process definition. Theoretically you could just try to use a normal BPMN tool, but there are limitations in this approach and they do not handle data definition well (which is why BPM+ exists).
So this area is at the ‘leading edge’!
There is already some capability to create Task Plans within the Archetype Designer (main openEHR archetyping tool, produced by Better), but things are still changing in the specifications. So it would be good to know if your needs are immediate, or if you are thinking more over the next say 2-5 years.
Great slide & analysis! These kinds of data would be created in the EHR as a result of Task Plans being followed (future), or just of work being done today (i.e. with no computational plan). They report / summarise activities after the fact of course, rather than defining a plan of work to do.
So according to Heather’s analysis, we have a ‘pretty good’ means of reporting what was done, in detail (and using terminology). We (= the whole industry) still have some way to go on being able to routinely create prospective, detailed plan definitions for such work.
I used to facilitate this work on behalf of the openEHR community but I was forced to step away from that role just over a year ago. The methodology we developed works well and I still follow that methodology in work with clients, and I ensure our archetypes are always designed so they can be contributed back to the public good via CKM. We still run reviews through CKM to garner broader participation and consensus.
I’m not sure how this will change when the openEHR Board kickstart its new Clinical board that will endeavour to recreate & expand on what we had - @joostholslag is one of the key players. I suggest you get in contact with him.
I do use the national vascular registry to record all the vascular procedures I perform.
Most specialities have their mandatory quality Improvement registries. The main aim of these is to compare the performance of all the units in the country. But the data structure they use is a very basic one.
Here is a tool I developed almost 10y ago as an SHO(resident) for one of the London vascular units. This was to record bypass procedures and generate information useful for research.
A typical query was; How many male patients over 60y, currently on clopidogrel preserved their Femero-Antierio tibial bypass constructed using vein after 6 months with only one salvage revision?
But for the current project, I would like to go further and develop a tool for all surgical procedures.
Just to clarify if I understood it correctly, do you plan to use the process modelling to capture the entity relationship relevant to different specialities?
I did come across BPM+ at one of the British Computer Society - Health and Care group lectures. Sounds very interesting and will have a look at it in more detail.
@sobath At the risk of expanding this already lengthy and very interesting thread, I just wanted to highlight that the Anaesthetic community are facing similar challenges. In particular, we have struggled to come up with a coherent representation of a clinical procedure such as an epidural, where there are multiple concepts such as guidance, positioning, monitoring and invasive devices.
It strikes me that there are many similarities between surgical and and anaesthetic procedures and it may be useful to abstract these at a high level and then try to specialise for specific use cases. We’ve been at this for years in the HL7 community, but are a long way from having a usable IG in Anaesthesia, as the modelling entities such as ACTIONs and OBSERVATIONs are currently unable to deal with the all the nuanced complexity.
As @thomas.beale points out, there is a wealth of Terminology to support the effort. The SNOMED Anaesthesia CRG has 5,000+ terms in its vocabulary - no doubt the vocab for surgical procedures is even larger.
The challenge is that Terminology only gets you so far - eventually you need robust yet flexible clinical models to represent what happens in the real world. I’d be very happy to join forces in a project to model surgical procedures as it will undoubtedly present similar challenges to the work we’re doing in structured care records for Anaesthesia.
This is really helpful! So your primary aim is collecting data for research/case review. In openEHR this would usually be considered secondary usage of health data. But certainly is part of the goals! The primary implementation would be collecting data for the principal care proces (OR report, post-operative instructions etc; the stuff described in my and others earlier posts). And getting the data you want for research will be done using AQL. Where one can query across entries in the primary EHR for identical concepts. @ian.mcnicoll are you up to create an AQL example for the query @sobath desribed?
This research vs primary process is probably why openEHR data modelling feels different/needlessly complex even to you?
But what you’re trying to achieve is certainly possible with openEHR. And I would encourage you to try. And others have done similar things, there’s been a recent webinar by Better.care about rare disease registry’s in Italian/Slovenian pediatrics iirc. Let me know if you need a link.
But honesty demands to share other standards like omop-ohdsi, might be a bit quicker to achieve your goal. If however you want to be able to perform the research query from data collected in the primary process, without additional work, openEHR is by far your best shot. But depending on your EHR (provider) that might be (too) far in the future.
