Paracetamol Overdose App

Hi All,

I would like to introduce a project I have been working on (off and on) for a couple of years.
This is a web based App aimed at delivering the pathway for paracetamol overdose (Acetylcysteine pathway) and is a small part of ongoing work to operationalize the different classes of pathways as proposed by @karen.j.green.
This pathway appeared prime for an IT solution because of the maths required for first establishing if treatment is indicated and second calculating the dose, volume and rate of three infusions. There are plenty of opportunities for error particularly if the practitioner is not mathematically adept.
The App is a prototype only, I have built it as an HTML with JqueryUI to make user input and charting nicer. At the moment it is entirely client side with no data model or recording anywhere as it purely serves as an example, if this were to be used in anger it has been quite rightly pointed out that the calculations would need to move to server side or be hosted and called from an external API as proposed by Marcus @pacharenero and Ian.

So the App starts with basic demographics collection:


followed by capture of the time of paracetamol ingestion this is used to plot on a timeline to show the stage of treatment, if past 8 hours the rest of the form reorders so that treatment is commenced before blood tests :
Otherwise the App prompts for bloods next and shows the appropriate bottles:
Blood results can be input next to plot the plasma levels back over time on a chart, there is also a “treatment line” on the chart if the plasma level plots above this then treatment is indicated:
The weight of the Su can be input to calculate the dose, volume and rate of three infusions again this uses visual prompt, thanks to Marcus for suggestions re drip bags changing appropriately and scale for comparison.
Final blood tests are then prompted:
and finally referrals on:

This can be seen at: ParacetamolPathway

This has been submitted as a code4health challenge and we hope to progress this soon.
Yet to be done… their needs to be the addition of guidance for activated charcoal administration, there may need to be a post administration continuation depending on final blood results, and the really difficult bit will be adding functionality to accommodate staggered overdose (across a period of more than one hour).

I hope this proves of interest, any comments, advice or guidance are very gratefully received.

Are you planning to use this as a standalone app or combine it with an existing EPR or Pharmacy system?

For the latter, you would get the data from the source system. Something like these apps https://gallery.smarthealthit.org/

Hi Kev

Thanks very much for your post and link to smarthealthit, this is really useful.

“Are you planning to use this as a standalone app or combine it with an existing EPR or Pharmacy system?”
The original intent wasn’t to do either it was purely a way to demonstrate how a tool could be built to support a presentation based pathway as opposed to an intervention based pathway or rather the progression from one to the next. Then someone pointed me at the code4health challenge which I submitted it to and since the talk has been much more of actually delivering this. Ian Mcnicoll and Hildi have been very supportive and has already done the data template for it and Marcus has been brilliant with advice and ideas. I think that the ideal solution is to allow both integration and standalone application to exist.

So in answer to your question Originally neither … now both!

Building on the principles of openehr the data model should be available to all to build their own variants of the app, but also the calculations for each of the sections (eg dosage and half life etc) which I know Ian talked about and can be done. What I’m not sure about is how the process itself can be coded in an open format ie what happens in what order and when the order changes?

Hi John,

Your last question is an interesting one and your comments about process caught my eye - this is something I have been working on for some time and ended up helping to set up Synapta for; how to code process in an open format and what happens in what sequence, coping with contingencies and so on.

While not everything below is directly relevant to your ideas, it all flows from the relatively simple question you posed. Of course, not everyone will see it quite the way I see it, so take these observations with a pinch of salt.

Just for now, the Synapta work has had to take second place to getting an open platform available to run it all on, (without which it will not be open) so we’re having to tread water for a bit, while the work on an underlying platform is done.

To give a flavour of the issues though; there are open standards associated with process modelling, such as the workflow notation BPMN. BPMN 2.0 allows a ‘direct to code’ (and even ‘round-trip’ integrity) approach under controlled conditions, which is potentially very helpful.

However, just because BPMN is an open standard, it unfortunately doesn’t solve the problem by itself. What you’ve got with BPMN is an open standard for notation, but it doesn’t come with e.g. an open health process framework to standardise the component tasks, objects, actors, etc. The process has to hook into external systems at various points along its path. What this means is there needs to be an open semantic framework, so that we all mean the same informational thing / data artefact etc when we refer to it, which is not automatically the case. It requires shared clinical information models.

There are potential candidates for such an open framework (i.e. terminology sets and classifications), perhaps at least as a starter for ten, but most are not process aware standards and not all are open (e.g. processes mapped in systems using proprietary, internal clinical models). This is the stuff of semantic interoperability. Many aspects of this are addressed by OpenEHR archetypes.

After agreeing what things are, there comes next the issue of what, exactly are we doing with them and what are the intended outcomes. In linguistic terms this concerns pragmatics. It is not a trivial task to ensure that a system ‘knows’ what it must do or achieve in the ‘real world’ and how to reach that goal under all the possible circumstances which might occur. We usually overcome this by using human oversight to ensure that a process actually does what it should do. There is a role for certain levels of decision-making or decision support to cope with real-world variability.

The short version is that each process needs effectively to be ‘solved’ for each run-time instance and open-standards processes are needed, a bit like we already have the clinical archetypes. These might be ‘process archetypes’ , which themselves could be described using an open decision support language.

This is where things like PROforma might come into the picture. This allows automated clinical decision support and automated pathway execution under conditions of uncertainty. Where BPMN for example is effectively deterministic (even if it has been cleverly designed), something like PROforma ‘solves’ a pathway each time it runs.

Finally, to be open, all this needs to be done in a way which allows the flow of the process to cross system, organisational, professional and health / social care domain boundaries and is agnostic of any given implementation technology.

Not a small task then and certainly not all required to implement your ideas. But it’s interesting to get a flavour of what will be involved in ‘coding process in open format’ and storing them in open libraries to be shared and reused.

Mark

Hi Mark,
just a quick comment. As part of my workflow work with Intermountain Healthcare, I have studied YAWL for a few months. I now see it as probably the best bet for an underlying technology for health. BPMN is too rigid; YAWL is a superset, but mostly, it has a declarative style of workflow definition, not just imperative as BPMN has (i.e. YAWL has both). The YAWL tools can be downloaded and will run on most machines.

  • thomas

Hi Mark, Thomas,

Thank you so much for your comments and information, I will take a good look at whatever I can find on both BPMN and YAWL.

May I ask if I am not only looking to encode the workflow (ie the order in which each of the elements of the app are arranged) but I’m also looking to encode the Boolean logic to the workflow (ie if hours since ingestion are <8 then bloods before infusion else infusion before bloods) would this be integral to the YAWL or BPMN definitions? This might be what you were referring to Mark when you mentioned coping with contingencies?
If not presumably the same mechanism that allows the logic for the calculations in the app (such as the dosage calculations) to be open to all could also be used to apply the logic that orders the pathway? I’m not sure what this mechanism is yet, I know both Ian and Marcus have talked about it. So we would be building and rebuilding the form dynamically based on a combination of the YAWL or BPMN definitions and input variables within the form itself passed to an externally held function.

The function itself as stands is stupidly simple using client side Jquery:
//change order of pathway if 8hrs have elapsed since ingestion
if (hours>7){
$("#dosage").insertAfter("#Timeline");
}
else{
$("#dosage").insertAfter("#plasmalevel");
}

That’s it! I feel so primitive!
You can see the reordering of the form in action if you set the date and time of paracetamol ingestion to more than 8 hours ago: http://www.ideasofmine.net23.net/Acetylcysteine%20Pathway%20V6.2/Paracetamol%20Pathway%20with%20timeline.html

I am just in the process of updating the app to include more functions including a “significant overdose” calculator and “activated charcoal administration” section, as soon as I have done this I need to apply the data model that Ian and Hildi built so the variables can be passed allowing me to move the functions out. It needs an awful lot of tidying up before that and even then I think this will only ever serve as a working prototype for someone else to follow.

The final thing which is more from a pure applied maths perspective is getting staggered overdose calculations cracked! On my current prototype, which I haven’t shown yet, I am projecting backwards the plasma levels on a proportionate basis to each ingestion (back to the last point there was over 36 hrs between ingestions) and then using calculus to derive the total areas below the graph line, my maths is pretty good but this is really hard, I think I will need help on two fronts at some point, from someone better with calculus than me to get the manual formula right and then finding the best way to handle calculus in code probably using a plug in. If we get this cracked then the whole thing changes its complexion from being a handy tool to being a serious bit of kit.
Anyone good with calculus??

Dreaming of the future it would be nice to be able to work our way through toxbase and do this for everything including common combination overdose… maybe oneday.
Many Thanks
John