To all openEHR vendors,
The English NHS is going out to pre market engagement for a single patient record (SPR).
If there was ever a time to get openEHR into this its now 
:
Also there is a Webinar for suppliers this Friday 9th May
7 Likes
What we have achieved with openEHR is the data aspect of a patient-centric health record (and there are still improvements to be made). But what is needed in the future is an ‘active EHR’, which includes care process tracking. Today, there is no single human who knows everything that is going on with a patient - care is provided in sliced up pieces by specialists, hospitals, allied health, etc, with an attempt at an overview by the GP, although the GP is mainly reduced to referral and being a mail box for all other comms in the system. So the patient-centric record is the only entity that has any hope of representing a continuity of care view for the patient. To be be realistically useful, it will have to include a representation of the ongoing processes, including routine appointment schedule, emergency events and so on.
Without this, there will never be a reliable way for any given clinician to be find out what is going on with the patient, what they need to do next, what has been done, and what the outlook is. THere will also be no organising framework to attach CDS (including AI powered ) or other analytic or plan-oriented tools.
What I believe we need to propose in this kind of RFI is not the openEHR EHR of today, but what it can be in the future, which must involve care pathways and guidelines (the goal of the Task Planning work).
10 Likes
(Apologies if I’ve picked the wrong end of the stick here) I always thought that this is an archetype/template/ADL problem rather than a two-model capability problem. If there is a record of a plan, then execution against that plan can be assessed by comparing the record store to the plan with some judicious ADL queries - looking for records that satisfy the plan either explicitly through an assertion by a record creator, or implicitly through specification of the kinds of records expected to be completed if this step has happened.
Since all decisions or significant evidence should be the subject of a record - any planned branching or unscheduled deviation on/from a care pathway requires a decision or evidence - as such we ought to be able to work out where we are with a patient if we can access all of the record.
Which of course is the intent of the secretary of state’s vision - all of the record (logically) in one place.
That said I think it might be incredibly helpful if we could establish a meta model for a care process to constrain the development of plan archetypes and templates so that the ADL queries would be easier to write.
???
1 Like
Well that by the way records where entered (using AQL) is not the exact scope (you could tho but will be messy).
The goal is giving doctors or systems kind of an SOP to work trough making the whole process transparent and controlable e.g. where is the patient currently in the admission process etc.
BTW its called AQL queries not ADL 
1 Like
AQL Doh! - apologies.
That said, I don’t think we need anything anywhere near as complex as a BPMN kind of language though. Certainly the kinds of planning I used to see in Haematological Cancer at Oxford - one of the more controlled disease areas I understand - was establishing which treatment menu to apply, and then personalising that plan.
Are there any places on this forum where this is being discussed, or paper threads in the journals I can follow - keen to understand why this is seen to be more complex than I think it needs be …
(and the plan was a series of appointments and orders …)
1 Like
Well there is always the possibility to define something easy, in regards of what thomas said, you want a language that scales and is generically usable for different use-cases.
Maybe for small clinic X there are just exactly this workflows so one can hardwire (but they can change etc pp) them.
In general the complexity of these flows can be very high, that why up-to-date there isnt a good solution out there (at least from what i know).
1 Like
If your language is correct for the expected level of complexity, then a more capable language is surely just going to be a refinement rather than a revolution?
Somewhere I have a map of the entirety of ovarian cancer standard of care at Addenbrookes in the UK, (15 years old TBF) and while the map is big and recurses - it is just a flow chart with branches depending on the availability of data. The semantics of the model are very simple.
Lots of money and significantly better outcomes can be derived from very simple interventions
Anyway, I’ll follow up and try to find out who is active in the field. Thanks
I believe this is a very relevant topic and I completely agree on this drive to a more process-centric EHR. From my point of view, we need to find the way to generate process artifacts that are shareable. Humbly, I have proposed the fellowship project along these lines.
2 Likes
If it would be so easy, i think everyone would be already using vanilla BPMN.
The fact that several communities don’t (including openEHR and HL7) tell us otherwise.
Anyhow, i’m not involved in these processes.
3 Likes
There is one thing even more complex than BPMN – clinical pathways 
Written pathways are long, but their “paper” version isn’t validated and doesn’t expose all the “bugs”. The complexity and the required level of detail are realized only once they are turned into an executable processes.
GDL and Task Planning are probably the most well-thought languages at the moment. At least TP is lacking a modeling tools and an execution engine. Since an execution engine is another complex beast, I wondered in the past if using an existing BPMN execution engine could be used (we need something well tested before using it on humans).
BMPN has all the building blocks for processes but it lacks higher level components that would make it practical for healthcare. I’ve come up with few such components during my research (see BPMN patterns for healthcare).
Maybe a relatively simple example of a process for the management of catheter related bloodstream infections can show the complexity we need to model: bloodstream infections pathway
Will we one day be able to use standard workflow tools for a combined GDL+TP 
Building such tools from scratch is a hurdle for the adoption in my opinion.
3 Likes
- the solution template is available here.
1 Like
To do this, there needs to be a computable representation of a plan(s) for the patient, instantiable as plans (that can be modified at the definition level) and also instantiable as executions (when repeated sections unroll, and particular decision paths taken are instantiated). Otherwise there is no way to connect any specific item in the record to any specific plan, and there is no way to write queries (which are in AQL, not ADL, in openEHR). Further, what is instantiated in the record is due to the plan running in an execution engine, i.e. the plan is logically prior. The level of Plan representation I am talking about here allows for every individual task (e.g. one administration of one medication to a patient) to be represented and tracked.
If you just look at any particular kind of plan, then it will appear that a ‘simple’ custom solution can be created, generally speaking, an application that hides the workflow definition within its UI design or similar (i.e. hard-wired and hidden, so already a complete failure semantically). That is exactly the problem we have today. Every different kind of plan is just its own application in Epic or some specialised Obstetric solution or whatever. There is no way to generalise anything in this situation. We can’t see even on a dashboard what plans are currently running or where they are at. Worse, we can’t even contemplate generalised technology for integrating plans into the cognitive workspace of healthcare professionals. Right now they are just stuck inside specific applications, and overloaded with bad UI/UX, hidden semantics - leading to guessing of what is going on, and too many mouse clicks.
As soon as you look at realistic plans - even simple ones like diabetic monitoring and review, you want to have the plan represented in a way that it can be understood, modified, and also crucially - based on guidelines which may be issued by higher authorities or research institutions - in other words, ‘plan templates’. This part of the Task Planning overview gives an idea.
Pretty much all the serious efforts in this space today assume the use of something like BPMN:
- YAWL (now historical but formally superior to BPMN) was partly designed to handle clinical workflows
- the entire current BPM+ standards effort (on which I worked for some years, and amusingly, was the US VA representative on various OMG committees for a while); this effort is stuck with BPMN 2.x however, which has real limitations for health.
- there are many projects within institutions like Mayo Clinic working with things like BMPN, BPEL and other workflow languages.
If you think about it, what is a workflow language? It’s really just a formalisation of the following concepts:
- Task
- Decision (sometimes called ‘gates’)
- Wait states
- Events
Everything else is details. But without this minimum, you can’t even represent an appointment to get your eyes checked. So the question is: do we want to re-invent these primitives (and how they connect) for every clinically specific workflow / plan / guideline? Because that is what happens today, and why we have no scalable / manageable process automation in healthcare.
Have a look at the Task Planning overview document. It provide a reasonable overview of the field with some useful references. I can find more if you want.
Without a generalised approach to process automation, there is unlikely to be any scalability - just endless custom, disconnected applications.
Exactly.
Steve, have a look at these examples, they’ll give you an idea of some simple clinical processes. The BPM+ site will get you to other examples.
We could contemplate the creation of say a TP-VML design tool that exports to BPMN, for execution. Some basic things have messy mappings (e.g. user intervention in a decision evaluation isn’t a BPMN capability) but probably mostly doable. Personally, I think a POC engine is not hard; a really hardened engine with full explainability, high performance and full adaptiveness is of course another question.
3 Likes