Coding Blood Pressure

If you’ve ever wondered how to convert business concepts to 1s and 0s you are in the right place. This blog is a meander around at least how I approach and tiny aspect the problem with Blood Pressure as an example as it’s the first Leaf we are creating in our new application PatientLeaf.

Introduction

Blood Pressure is the archetypal silent killer. It’s probably one of the best examples of bread and butter General Practice and hits the core of what makes us GPs well GPs. It’s a chronic condition which needs regular input, tweaking of drugs and most importantly encouraging compliance.

The main problem is the side effects of medication can be worse than the symptoms of blood pressure until the patient gets some significant sequelae from persistently high blood pressures from not taking medication and then it’s too late to tell the patient I told you so. This is why it’s so important to

• Involve the patient in the decision to start medication when making a diagnosis
• Don’t be happy by telling the patient to manage side effects unless there is no other choice. Don’t be frightened to change medication to help side effects.
• Regularly involve the patient in the process. This is why I really like Home Blood pressure monitoring as it gives control to the patient in monitoring and decision making.

Basically, anything you can do to improve compliance will yield it’s weight in gold later down the line.

I used to wonder why QOF was so simple in choosing optimum blood pressures for the conditions. Here are all the QOF targets related to Blood Pressures for 18/19

• CHD002 – <150/90
• HYP006 – <150/90
• PAD002 – <150/90
• STIA002 – <150/90
• DM002 – <150/90
• DM003 – <140/80

It seems that they took the highest evidence-based blood pressure reading and populated it with every cardiovascular domain. I guess the moto was to just keep it simple and practical.

NICE is different and more focused on condition-specific Blood Pressures which I’ll explain below

Out of interest, I thought I’d join the dots on how QOF and NICE link for STIA

For STIA002 this is what is in 2018-19 QOF guidance for stakeholders

When I look at NM93 I get

Looking at 1.5.6 appears the following text in NICE for Hypertension

QOF links Stroke patients to Over 80 year old when it should be <130/80 from NICE Guidance!

So how is a computer meant to understand all the above to form some kind of coherent logic to present to the user? The first step is to gather information about Blood Pressures and their related conditions.

Trawling through NICE

NICE is evidence-based with a tint of cost-effectiveness so value some of it’s recommendations with this in mind, however, it’s good at grouping all the chaos and giving some direction.

We used NICE to look at the evidence around Blood Pressures with relevant conditions. You’d think BP recommendations for all conditions would be put into the Hypertension section of NICE, but it’s not quite like that for the maintenance of Blood Pressure and just focuses on mono morbidities.

Hypertension
After the diagnosis, the current recommendation is around targets for over 80s and under 80s

CKD
CKD has a bit more focus on Co-morbidities namely Diabetes. To keep it simple we are suggesting all patients with CKD and Diabetes target blood pressure should be 130/80

Stroke
For Stroke, the recommendation is 130/80 when reviewing NICE

Diabetes
Diabetes is 140/80 without cardiovascular damage or 130/80 with cardiovascular damage

Bringing it all together. Creating a Decision Flow

Now we’ve done some information gathering and know what blood pressures are required for which conditions what next?

Well, we have to be clear about what we want to do. Coding is an art as well as a science, a lot like medicine but you need be very clear about what you want. If I told a developer I want to “Code Blood Pressure” I’m sure they’d disappear back into the shadows and never be seen again.

A sensible question would be

What is the optimum blood pressure for this patient sitting in front of me in the clinic?

Do we have the information we need to work this out? No, as we need patient data! But what if we did have patient data, could we work it out then? A lot of time when you code you are fitting jigsaw pieces together without knowing or making assumptions about their shape and size.

So if I had patient data how would I work out their optimum blood pressure? Well, I’d need a way of querying blood pressures for each condition until I get the one I need. This would be a good place for a flow diagram where we query certain parameters and based on this we’d either chose this blood pressure or go to the next one

After a bit of tweaking, we might come to something like this

Notice how the lower BPs are at the top of the diagram and the higher ones are down below. This is because we’d want to always try to pick the lowest blood pressure possible. For example, if a patient was <80 but had a stroke we’d need the blood pressure to be <130/80 rather than <150/90

Converting to Code

So what’s next? With each level, we move from Medical Concepts to Design Concepts to Code.

So from this example, we are taking Patient Data, adding a Business Logic Filter to it to retrieve the Blood Pressure required as shown in this diagram above.

When a program runs, normally data moves from a persistent source to an in-memory source where it is manipulated. By persistent source, I mean a place where the information will remain even if you turn the computer off, for example, a hard drive. The way data is stored persistently is another big topic and can be in the form all the way from a text file to a relational database or NoSQL database. This can be on the computer’s hard drive all the way to the cloud.

XML is a concept of storing and transferring data but in a structured way. This has the immediate advantage of giving the computer a set of instructions and so long the data is structured in a defined way, you can easily get it in-memory to manage. In the above example, a suitable way of storing the business logic would be in XML and the Patient Data in the database which can be stored in a database but extracted as a dataset, XML or another format. If you’ve heard of Json, it’s similar to XML but more efficient over the internet and has other advantages when using it with Javascript. Json is like “Skinny XML”.

The aim is to copy these persistent data items in memory in the form of “Models” which are a kind of in-memory object which can then be manipulated.

The flow diagram above could be stored in XML in a form of a logic tree a brief example of which is below

So each “Node” value has a Type which can be defined somewhere else in the XML or be picked up by the code to represent an action.

In the example above, we check if the patient has had a Stroke or TIA. If they do ie decision is True, we make the blood pressure 130/80. If they haven’t had a stroke, we check to see if they have Diabetes, if they have Diabetes, we check to see if they have any End Organ Damage, if they do we make the blood pressure 130/80. Looks familiar? This is because it’s an XML representation of the Data Flow Diagram above.

Parsing XML

There are several ways of getting XML into Models but I find a better way of parsing (transferring data between media) is to use XDocument but it also depends on what you are trying to do. This is an example of importing the above code into a group which uses LINQ heavily in creating the Models.

 

Once it’s in memory we used a data manipulation in the form of logic methods, recursive loops and LINQ which is the magic sauce to compare patient models with the business model and work out what the ideal Blood Pressure should be. Examples of LINQ can be found on my blog about LINQ TRINKETS

I hope this gives you an idea of how I go down the rabbit hole from what clinicians are familiar to going deeper into the matrix!

Photo on Foter.com