Recall has suddenly got really difficult post COVID as we need to think more intelligently around how to manage our patients with their long term conditions in a constantly evolving workforce, myriad of co-morbidities and newer virtual ways of communicating with them. This blog looks into this problem in more detail with proposed solutions to this complex conundrum.
Does QOF actually work?
I’m sure many of us sitting in clinics performing our proactive care on our patients wonder if calling patients who are on the whole stable yearly actually makes any difference to their disease progression and mortality.
Interestingly the British Journal of GP released an article albeit in 2017 looking at the impact of QOF. I don’t think we’ve any systematic reviews since but the findings were very interesting. QOF started in 2004 so there has been enough time to possibly see its impact.
The QOF was associated with a modest slowing of both the increase in emergency admissions and the increase in consultations in severe mental illness (SMI), and modest improvements in diabetes care. The nature of the evidence means that the authors cannot be sure that any of these associations are causal. No clear effect on mortality was found. The authors found no evidence that QOF influences integration or coordination of care, holistic care, self-care, or patient experience.
Firstly I think it’s impossibly difficult to be able to work out as confounding variables are a plenty and it’s difficult to see which affects outcomes.
QOF has changed in terms of its targets which I believe is trying to re focus our energies to create more tangible outcomes.
The New World
QOF from a recall point of view is complex. You have lots of targets with lots of conditions all changing at different times for you to manage so that come year end all patients have their qof targets ticked. Some targets are also time limited in year (eg Depression and Cancer Review)
In the brave new world we are in we are constantly trying to find better ways to manage our recall. In the surgery, we have 2 types of demands
Reactive Demand from patients calling for an appointment
Proactive Demand from Recall via QOF, LESs and DESs
We were fortunate enough last year to be able to focus more on passive demand just due to the pressure from Covid but this year it’s all guns blazing.
The other big problem we face is that we can no longer opportunistically “quickly do the blood pressure” as they leave the surgery as we are seeing much less face to face. So we need to find more intelligent ways to manage the recall which are different to how we managed recall before.
Tick Box Exercise
Don’t you sometimes get that feeling that we are doing QOF just to tick that box? I know I do. There are a few targets which have outcome measures which we have to manage (eg blood pressure control or Hba1C control). In total there are about 78/635 points linked to outcomes = 12% which is generous when you consider thresholds too. The remaining 88% is attributed to reviews and measuring values which are more qualitative or have no bearing to getting patients better. For example we record the MRC scale on COPD as a non outcome driven target. If we were make this target outcome driven it would change for example to percentage of COPD who improved their MRC scale by 1 in the last year.
I’m not saying at all that everything should be measurable as there is a lot of qualitive work we do with our patients which is so important.
Another aspect to consider is I also do think we are giving similar focus to our stable patients who just need a gentle touch compared to our patients who are unstable and not controlled who need more frequent reviews to help them and their deeper dive into the sea of their morbidity.
The lack of focus on outcomes and unstable patients I believe are some reasons why we are not seeing as much of the expected outcomes we should by now with the investment in QOF over the years.
Risk Stratification
What if there was an evidence-based way of being able to subdivide our QOF patients into priority groups to give us the opportunity to focus more on those patients who need more time rather than treating all patients equal?
I came across the free UCL risk stratification tools (Search and risk stratification tools | UCLPartners) a few months back and was so excited by what they have to offer. This is an evidence-based set of searches to sub divide your population into priority groups and we now have a set of EMIS searches for us to be able to give focus where focus is due.
By spending more time on our more unstable patients there will be several benefits
our passive demand will decrease as these patients will not get as unwell
our mortality in our surgeries will go down
we will have less hospital admissions
we will achieve our quantitative QOF points quicker
We’ve been working with PatientChase to incorporate this to make it easier to identify and call in the right patients at the right time. With PatientChase we are able to offer risk stratification at a co-morbid level so you no longer just treat risk stratification at a conditions level.
With PatientChase we are now able to offer risk stratification at a patient co-morbidity level
The Big Black Box
BUT (and there is a big but) what are we looking at now? How many rabbit holes are we going down? With risk stratification we potentially have the following layers to manage
The new world of Recall
In other words it also gets more complex with a myriad of various processes which now also include a new workforce and the best contact media (Email, Telephone, Video, Face to Face). With all things considered we now need something like a Black Box akin to this diagram
For example Mr West who is a low risk Hypertensive patient needs a Health Care assistant for contact via email initially
In our new world of a varied workforce with different skillsets we need ways to generate demand to allocate patients to appropriate clinicians in a safe and efficient way. So there is a need to link patients in the correct pot by using middleware applications to manage this shift and divide the population accordingly to help the workflow.
Media
We now looking to contact patients in more ways than just face to face. These can be via
Email
Telephone
Face to Face
Media to contact them for their review
It’s important to differentiate out how we can use different forms of communication and need to define differences between media used to contact them for their review and media used for the review. They can be the same or different. For example we can email the patient to let them know the they are due a review then in the email ask them to contact the surgery for a face to face.
In our surgery we are looking to focus on the mantra of virtual by default by contacting them in the cheapest method possible which is email or text. Post is too expensive and I’d urge you seriously to consider other methods of calling the patient in
Email to me is amazing as it’s the best of both worlds in that if offers a rich environment to contact the patient with (like a letter) but for free so I’d very much recommend you look into this. In terms of governance issued please refer to my previous blog Email Consultations – Raza’s Site (wordpress.com)
Email to me is amazing as it’s the best of both worlds
Media used for the review
What type of media do you use for what type of target? We’ve been experimenting in our surgery around this and as with most non committal and vague answers, it depends. We’ve found the main hurdles are managing observations which need physical contact. These include
Blood Pressures
Peak Flows
Foot checks for Diabetics
Spirometry
In the review focus on managing their condion/s in the following order
Email -> Telephone -> Face to Face
But the main hurdle of going virtual surprisingly isn’t the physical aspect, it’s the patient and there has to be a will to try to go virtual on their side or it just doesn’t work. Off all the above aspects only really foot checks and spirometry need a face to face and patients can be worked up prior to face to face for these observations to make the consultation quicker and easier.
But the main hurdle to using virtual methods isn’t the physical aspect, it’s the patient.
We’ve found that email consultations especially for Asthma and Blood Pressure when the patient is motivated and happy to buy a machine or use the prescribed peak flow to monitor their levels are the most rewarding and enriching reviews because they have time to query about their condition and the clinician has time to reply. You can both use google to your advantage.
PCNs and ARRS Workforce for Recall. The right patient with the right staff
The plot thickens more as not only do you have to work out the best media to contact (Email, Telephone, Video, Face to Face) with the new workforce coming to you via the ARRS funding you also need to work out which type of patient is best suited to which role you have in the workforce. With the ARRS workforce we now have a varied skillset of clinicians from nurses to pharmacists to dieticians to HCAs on top of doctors all of which can manage certain type of intensity of patients.
We need a system which can work out of your recall population which ones need to go to your varied workforce based on their skillset and what they can manage.
This is why Risk Stratification is a game changer as it’s the perfect key to fit the ARRS Workforce lock. We can push high risk to more experienced staff and tier down accordingly. This way we can optimise the way we run our recall by tying up the appropriate clinician to the right type of patient.
Risk Stratification is a game changer as it’s the perfect key to fit the ARRS Workforce lock.
Non-QOF Targets
On top of QoF there are a myriad of target driven payments ranging from Nationally funded DESs down to Locally provisioned LESs which all require recall within the practice. CQC have also asked surgeries to look at the safety aspect of their practice care eg with DOAC monitoring and Drug Safety monitoring so it’s no longer all about QOF but everything related to recall with the same principal that the patient is in the middle and has all their Qof and Non-Qof Targets associated with them. PatientChase has for sometime offered Non-Qof Targets via external searches from EMIS for users to focus on all target driven schemes.
Using Recall with PatientChase
The concept of recall is simple
you have the whole population you have to see in the year ie the demand.
you have the capacity in your staff to see them
Just like a toothpaste coming out of a tube you have to squeeze the patients at a certain rate otherwise the demand will be unmanageable.
PatientChase used at it’s fullest is a full recall application which merges procured and managed targets and allows the user to contact them in which method they wish and records this back into EMIS. It automates the recall process in the surgery for both QoF and non-Qof treating both types of targets the same.
And now we are able to correlate patient complexity with workforce experience in general practice with Risk Stratification so high risk patients go to more experienced clinicians tiering down accordingly
Risk Stratification with PatientChase
With the latest version of PatientChase you can import the UCL searches which allow you to risk stratify any search which has any risk stratification searches in them.
This will help you be able to filter populations with multiple comorbidities into groups based on priority. The idea is.
The low priority groups
need low intensity care with a telephone or email nod of the head and a check of compliance
Can be managed by workforce other than doctors or specialist nurses
The high priority groups
need more focused and regular follow ups and more intense care possibly via face to face or regular updates.
Need more experienced workforce to manage them
PatientChase Screenshot with Risk Stratification (Dummy Patients)
Workflow for managing Recall using PatientChase
With all the above said how can we then actually operationalise our recall in a better way? Below is a proposed suggested workflow. Where PatientChase excels is in creating this workflow at a patient level including all the co-morbidities associated with that patient and all non-Qof related items so the focus is the patient and not the targets.
Step 1 Which type of Surgery Are you?
There are 2 types of entry points which are Month of Birth or Risk Stratification
Month of Birth
You are cutting up that recall toothpaste into months of birth to call in to manage the capacity in your system. This is a tried and tested patient centric model which works well as the capacity is static and patient know when their review is.
Risk Stratification
In theory recall should be all year long with each month being the same as the other but in reality we start the push after April and then rush to get everyone seen by March the following year. In this model the idea is to manage as many of the high risk earlier in the year which will have 2 effects
It will help you have more chance of bringing in patients abnormal values earlier to give you a better chance of achieving them come year end
You are focusing on the most important patients first which goes in line with trying to getting away from Qof being a tick box exercise as described above and also have the opportunity to call high risk patients in more often. We should be trying to divert our energies more on the high risk than low risk. At the moment we are giving each cohort the same air time.
However to do this properly it’s important to do an exercise in asking patients to get their blood tests done early and prior to the risk stratification. This way you are more likely to focus on the right cohort with the most up to date information and has the added benefit of prepping the patient prior to their appointment helping the nature of the review.
We should be trying to divert our energies more on the high risk rather than the low risk.
Step 2 Risk Stratify and Manage the volume
Volume created from Month of Birth manages itself.
If going down the Risk Stratification arm the recall team has to decide how much of the flood gates need to be opened for what type of workforce so this requires some forward thinking. The idea is simply to keep the clinics full for the next week.
Step 3 Contacting the Patient
Once you have your population you can the siphon off the associated population with the associated workforce via correspondence informing them of how to book their appointment.
Already stated above there are several ways to contact the patient and really think about using SMS and Emails to save you money on the not insignificant stamp costs. Surgeries frequently say they don’t have enough emails. We sent a blanket SMS message to our patients asking them to email us their email which we collected and entered in. Within a day we had 1,000 more emails of our list size of 4,000 so updating your email list is a tedious but I think an essential exercise if you plan to use this line of communication moving forward. As stated in my blog about email consultations, the IG is much more flexible to what it was previously on this front.
Step 4 – Virtual by Default
The focus should be virtual by default with email->telephone->F2F.
Even though for example diabetics need their feet checked and possibly weight done if they can’t report back their weight to you, you can work them up prior to the F2F such that this consultation which will be a fraction of the normal time taken.
As stated earlier in the blog this should be a personal decision between the patient and the clinician. In our surgery patients love email only as well as face to face only. By having this flexibility the workload will get better as the patient who now does email was one who had to have a face to face and emails done correctly are an efficient and potentially more productive way of managing the patient’s own condition.
Summary
Whether you use PatientChase or not I truly believe the future of how we should manage our disease registers should be skewed to spend more time on the higher priority patients. Tools such as the UCL Partners Risk Stratification Tool finally are here to help us achieve this.
Have you ever had a vision about an application but when you ended up creating something the reality isn’t quite what you expected it to be?
Vision vs Reality
It can be very hard to turn your thoughts onto paper then once you go through several layers you can end up in a game of Chinese whispers where the end results is very different to how you envisaged it. It’s difficult to get the reality to live up to the vision.
I’ve been asked by many fellow clinicians to do this blog even though I don’t think I’m still qualified. There is still lots around this specialised area of healthcare which I haven’t done and know little about. This blog is just my experience which I hope others will find useful. If anything I hope I’m showing there is much more to IT development in the corporate healthcare sector to a visage we have of releasing an application then going back to your day job.
However looking back I can say that there is much more to the story than just the fantasy of transmitting your thought to code, waiting for the money to rake in and exiting left on a tropical beach with an early retirement which just doesn’t happen often. You have to love what you do and be committed and consistent all the way through the journey.
The Journey
I’ve also realised there is no destination until you truly exit so there really is no real good time for this until you consciously choose there to be. There is only the journey and we choose when to leave rather than there being an endpoint. Think of a train ride with no endpoint but not a circular track, a train with endless stops and no real end destination. When we want out we wait for the next stop and go onto the platform and exit. The question is if you are prepared to start the engine and go on the ride?
This is a practical Blog for those fellow clinicians who maybe have ideas or a small prototype who want to go to the next level in Healthcare IT. There are other avenues to help you take you up the ladder. 2 examples in my area are the following so please look them up. However, as with other aspects of this market, you are not alone and there is competition in applying for these grants or apprenticeships.
Accelerator – DigitalHealth.London – Helps SMEs to take their idea into Healthcare by giving them an NHS Navigator to take them and help them manage the pitfalls which potentially could be encountered.
I personally have got to where I am with no external investment just from directors own money but I’m not necessarily saying that is a good idea.
There is a concept called the infinite game which was coined by Simon Sinek which I think is a brilliant analogy in short-sightedness vs long term game players. He summarises it much better than I could in this video
In essence, we need to look more at the infinite game for any business and look at improving ourselves to be better rather than worry and change to beat others, but more importantly, always be moving forward and not sit and be happy with what we have.
Vision for your self
Before you even start you have to have some idea about where you want to go with your vision which will depend upon time commitment, effort and resource.
I used to think that sheer brute knowledge in development can force you into a position where you don’t need cash but to be honest this is just not the case. If you want to move at any pace and still keep your day job the bottom line is you need a funding injection.
I saw this simple graph once and it really hit home around where individuals want to be when it comes to growing their business and it boils down to 3 types of risk takers
1. Those that want all in and want to be millionaires. They invest or convince others to invest in an idea at great cost hoping their idea will stick and they will float and go to that beach. The rewards could be substantial but if you crash you crash hard so this is very much a high-risk high reward avenue.
2. Those that constantly grow their business with time not interested in going public but would like something more out of it in the long run. They normally invest their own money into their venture hoping it will sell to give them a return and tend not to give much of the company away initally.
3. Those who just want to pay for their holiday and reach a certain level and stop happy with the income they have. These are the lowest risk-takers but in the end, their input is less so they can spend more time doing other activities they like.
Growth Wish
The other aspect to really appreciate is that it’s really true when they say success doesn’t happen overnight. A friend once told me it’s like a bamboo tree. After years of nurturing and growing little seeds, you get nothing. Then one day the seeds grow 80 feet in 6 weeks.
Be as large as what you want to be and what you are prepared to sacrifice if do you really want to give up your day job for it. I’ve known plenty of successful clinicians who have given up their day job so this isn’t a rhetorical question.
So in summary
Keep the growth as a lifestyle to medium if you want to keep your day job
Look to sacrifice more if you are looking at larger external investment with a higher risk and potentially higher reward.
You need to decide how much time are you willing to give up for this cause.
Intellectual property and trade-offs
IP
Intellectual property is so important that it deserves a whole section in itself. As with most things in life it starts off with an idea. Please don’t be frightened of telling others about your idea. Ideas are a dime a dozen and very few ideas actually take root and turn into fully blown products. You know what they say 1% inspiration 99% perspiration.
Keep your idea simple and try to find a niche initially and be very specific about your audience and your scope. Know in yourself that you can’t replace Emis and don’t even try.
At the same time be meticulous about exactly what you want but more importantly the steps you need to take on how to get to the first release. I’ve frequently heard from colleagues that they want to digitise this and that with no thought of how. You can’t make an app from behind your cigar on the top floor of a multistory office in the middle of the Shard and shout “I want to create the best app ever” and just expect it to be done. It’s easy to express an emotion about an application (eg I want an intuitive application) but much harder to create it.
You can be top down and start off with screenshots or mocks of your final version or start off with what data you require and work bottom up but have a white paper which explains as much as you can to more technical people.
IP Flows
IP in Simple Terms
In simple terms your IP is how you manipulate data from various sources into your mentioned output.
Where to get the data from?
Drilling down into more detail where do you get the data from? There are several sources as listed below
As you can see the concept is simple but the complexity is how you automate the data feeds into your system, how you manipulate the data and how you then present that to the user.
Vehicle for your IP.
You could argue as GPs were are the equavalent of consultancy but for healthcare. We impart our IP to patients in exchange for a salary given by the government as a monopolised business
The IP you create when making your product needs to be injected somewhere if you are serious about this industry and the best place is a limited company mainly owned by yourself. I say mainly as you should offer shares to others who buy into the idea to share the IP which is now company based rather than individual-based. I don’t know anyone who has built up a business without a vehicle and some form of governance structure within so don’t think this can be done without it. You need a business, you need to inject your IP into this business to give it a defined quantity and you need to involve a solicitor and bank manager to set up your company
I can’t stress to you how important this point is and it’s something you only realise after you’ve passed the point of no return. If you are prototyping you have to choose where you put your IP and if you are converting this into a product, the NHS needs you to have a legal entity with the correct structure in place in order to accredit you. After you get your prototype up and running the next best course is to get a grant or invest your own money and gather interest locally to build up from there. To be honest, NHS bodies hardly ever give money to untried or untested companies without the backing of larger companies. You have to wait until you are large enough or have been in the industry for long enough to be able for NHS bodies to trust you or sell to individual practices with the hope that word of mouth will spread. Alternatively starting local with close connections you’ve created over the years can help you build up.
Another option is to create an independent NHS tech body to inject your IP into and build up from there as an in house entity within a symbiotic relationship with your local NHS non-tech body. From here you can branch-off and sell to the rest of the NHS with the same concept you have tried and tested locally.
By the way it is extremely difficult to patent an application so don’t try. It has to be truly innovative and new and this is extremely difficult to achieve and most applications are an evolution of apps from other industries massaged into healthcare or an iteration on and existing product design or concept.
TradeOffs
As you probably know or soon will know there are so many different options to chose from in IT and it’s for good reason. No shoe size truly fits otherwise everyone would be developing the same way with the same language and the same frameworks. There are tradeoffs with one type of solution probably being better than another at some expense and it’s a matter of what you can live without the most rather than what you think is better!
With this in mind there should be several factors involved with making decisions around what route you want to take and what trade offs you are prepared to make
Who is your market?
patients – server side but don’t necessarily need patient identifiable data
clinicians – if sharing clinical data on a server need to go through IG
operational or management – might have server side IG issues but depends on your scope
TradeOff – Are you happy to deal with anonymised data or do you want to go through the IG issues to deal with patient identifiable data which will give you greater functionality
Familarity vs innovation.
There is a unwritten rule in UX design that all roads lead to Amazon. They are the kings of how we understand how a web page design should be. Other web applications emulate this not because they are lazy but because the familiarity of the way the page is laid out means that visitors instantly know how to navigate their way through because everyone knows Amazon.
The flip side of this is that you don’t innovate if you stay cautious. When designing the screens bear this trade off in mind.
Web or Desktop?
Most of the direction of travel is Web based currently to be honest. Web site development is the holy grail of development as you have an environment where you deploy once to the server and instantly everyone has the latest version with no deployment issues. Having a central repository means the code base is instantly maintainable and scalable especially when moving more to cloud development.
However you look at it though, you are never going to get close to the richness of Desktop API which holds a more direct connection to the operating system so gives you better options in terms of speed and UI
Can have hybrid system which offers both. Indeed EMIS is a sort of fat client at the moment where it is a deployed app but there is a database which is held on a Web Server. One issue with this solution though is you have to maintain both the desktop and the Web Server which is the worst of both world scenario!
What Environment?
Also there is no ideal development environment or ideal deployment method or ideal language. Each have their pros and cons and it depends a lot on personal preference as well as what you think is right for the scenario you want to achieve. Having said that please stay clear of Excel and vba for production. It’s just not scalable.
IG issues and Hosting a solultion
One question I’m sure you want to ask is where to start if you want patient data on the Web. As you can imagine this is a huge IG issue so there have to be robust mechanisms in mind to manage this or we will have data breaches everywhere.
For Patient Facing Services and also getting API access for business apps dealing with patient data you will need to have separate contracts with each supplier or go through IM1 Paring Integration
The advice of others is to contract and outsource this out to companies who know how to go through these processes and will have access to UK cloud base services which you will need in order to manage the data and know far more than you around how to do this.
Be prepared for the Journey
Ah the Journey and be prepared for a bumpy ride. This sections just comprises of thoughts which are important but don’t fit in other sections. Think of each point as items to take into consideration during your journey
More than just the Application…
Sorry for those who used to do NHS hack days but I found them to be a false economy. For the one I attended over 95% of ideas generated were simply already in production so this ended up being more of a showcase rather than just seeing what you can create in the weekend you had available.
The 1st release is only just about 5%-40% of the total lifetime of a product depending on how you grow your product and add additional features so an idea that generates a spark soon dies off as clinicians realise just how much it takes to go to the next level.
“Great software isn’t built. Great software is grown” Bill de hÓra chief architect with NewBay Software
There should be better ways to cultivate the richness of ideas we have in healthcare but it goes to show that development is more than just the first release.
Find the time
You have to find the time and you have to persist with your endeavour if you want to get anywhere. As I assume you are also practising this means creating time during the day by working part-time or evening and weekends.
There is also only so much you can do with your time which you have to divide between coding, implementing business logic, training, promoting, seeing patients and spending time with your family!
As stated above products don’t sell themselves. You can have the best product out there which does something which is much more clever than anyone else’s but if no one knows about it no one cares. So make sure you market your product well and keep it simple for the audience (something I fail to do!)
Going Solo and your day job
Don’t do it alone even though you think you can. Try to build a team which is good at each aspect of the business rather than several people who are competing for the same spot.
I get asked this a lot and each is different depending on your situation; should you give up your day job? Initially, at the start of your journey, I’d say definitely not. The Healthcare IT industry is very conservative and it takes time to grow and be in a position to be able to leave at least part of your day job. But whatever you do enjoy the journey and enjoy what you do.
Hobbyist vs professional
Are you a hobbyist or professional when you start your venture. There is an objective answer and a subjective answer.
To me, the objective answer is when you get your first paycheck and have a company you are deriving payment from you have moved to be a professional in your chosen sub industry.
The subjective answer is that the question is irrelevant and it’s less about how you think but more about how others perceive you. Once you have more of an infrastructure in your business to support, train and market to, others will consider you and take your business seriously.
Product or services
Services, services, services. In this industry don’t even think about creating an off the shelf product which sells itself and maintains itself. One which you can just release and forget. This isn’t a video game and you need to constantly evolve it, learn from your mistakes, keep it up to date, support it and constantly train new staff on it.
What does scalable mean?
We get asked this question a lot from people who are looking for an opportunity to invest or just want to ask the question and see how you squirm. A scalable product is one where you can provide a similar service to one user up to 1,000s of users and it’s a total misnomer when you start off. Just get what you can off the ground and see if has legs. Don’t worry about if it will work when 1,000 when the first 10 you market it to don’t like it.
It’s something you normally think about after you’ve got over the hurdle of keeping your business alive but a few key initial seeds which will help are
reduce the number of dependencies you have with your application (by dependences I mean reliance on other products for your product to work)
think when you make your product if you can push everything to the cloud and how this would work. As a rule of thumb cloud products are scalable by default.
Don’t rely on frameworks with no flexibility. VBA, excel, macros applications are not scalable. You need a reliable data source with an API that will work if there is one user or thousands of users. In other words only allow access of the data source through automated methods.
How much money do you need?
The aim is more about how much do you need to take the product to market to generate sales rather than how much you need for the product in it’s entirely which in essence is where to walk a thin tight rope on decision making.
Once you have enough sales you can fund further development and to keep the company going, pay off your investment and provide a service with training support and debugging.
There then becomes a question on how much are you happy to keep and how much do you need to invest back in to the company to drive it forward.
Apologies for not getting to the point. So how much do you actually need? This depends so much on
what the skill set of your existing company is (who in essence are providing resource in the hope they will get a return for the shares they have)
the complexity of your application
server and infrastructure cost
dependencies on the application which you have to pay for
contracts with other companies who take a slice of your revenue in exchange for the service they provide or data end points you need
how much you plan to sell the application for to recoop your investment
whether you decide to outsource your work (more expensive in general but less hassle) or employ people in house (less expensive but can be a lot of overhead around employment side of the business)
Apologies yet again for still not getting to the point. If I were pushed I’d say
upto £20k for a small sized application or prototype
about £40-60k for a medium sized application
over £100k+ for a medium-large size application
£100ks for large size
Naturally you can cut these values if you have in house developers or manage to get something out yourself.
There is an unwritten rule to double the cost and double the time from the plan you pick and this is definitely true so some extent so bear this in mind.
As you start ploughing into your budget it then gets to be a judgement call on when to release as running out of money is a common reason to release more often than not. we sometimes release too early in order to be able to kickstart the revenue generation. Release too early and you have a buggy mess with no functionality and just isn’t attractive to users, release too late and you suck up your funds and have a mammoth task to then recoup your losses.
There is no right path it’s always a trade off between options and which one is the best one for you. See this diagram
Juggling Balls
You are juggling between time taken to complete, how much development time you have and the scope or how big your application will be. The money in the middle is normally the fixed element
for example, you find the time is dragging on so you need to reduce the scope if you have a given budget. Alternatively you want to increase the scope but this will require more resources or will take up more time.
Ultimately adding more money resets the system and allows you to
increase resources
increase scope
reduce the time taken
Thus it’s so important to understand the scope for release one to allow you to be in budget but have enough functionality to sell then grow from there.
If you are contracting out you can pay developers an hourly rate or a fixed rate for the agreed scope. Both have pros and cons and relies a lot of trust. A good half way house is to have a fixed rate but give penalties if milestones are not achieved by within a certain timeframe.
Be Realistic, be persistent and don’t procrastinate
JFDI! (google this if you don’t know what it means) If you think the idea is cool just do it but spend as little time and money as you can to prove that it works first. This is how we started with PatientLeaf to test the UI to see if it work and if there was a potential user base who would like it. I still don’t think we’ve got it right with PatientLeaf to keep all kinds of users happy but we will get there.
Which goes onto my next point which is to be persistent
Ambition is the path to success. Persistence is the vehicle you arrive in. ~ Bill Bradley, Starbucks Corporate Director.
Success is not the absence of failure; it’s the persistence through failure. ~ Aisha Tyler, Broadcaster and Actor
If you get criticism, don’t ignore it: take it on the chin and try to learn from it. You have to understand why people don’t like your app and if you believe they have a point, fix your app. At the moment the an area I have with PatientLeaf is that it’s too overwhelming although to be fair what I’m showing is complex. A lot of clinicians love this so I am also finding ways to manage this and keep all types of users engaged.
Start off with something small and build up in a direction you want to go in. Don’t try to build Rome in a day and go at a pace that you can realistically achieve which leads to my next point which is to find a niche and focus on this. Please don’t try to reinvent EMIS but do try to complement aspects of it.
In summary don’t give up!
Should you Code?
The bigger question is if you need to code and, to be honest, I’m very much split on this debate which I know has been going on for a little while.
The argument against coding
The dilemma we face as doctors is that if we want to stay as doctors we don’t have much spare time and as development takes so long you are using up the precious free time you have left to code when you should be working on other important facets of your business. The end result is that you take too long to get something up and running if you want to do it yourself or just lose interest.
Also to be honest it’s the developer’s job to take your mess of a concept and formulate it into 1’s and 0’s and the key to success is more to find a good developer who can take abstract ideas and understand what is in your brain to convert it to digital rather than spend the time to do it yourself.
On the other side of the argument is
If you know how to code you know how to create worlds so can establish yourself in a position of real power in creating or directing the creation of your products and the chance of success is higher as you understand the limitations and capabilities of your created engine. But it takes a lot of time and a lot of effort to get to this stage.
A lot of projects start off with prototypes which are ugly vertical snapshots to prove the concept you have that your idea will work in the proposed setting. Prototypes normally have pre-populated data rather than automated feeds and just show and prove how the product would work in the real environment. This is important for most projects as you need to dip your toes into the vision to see if your application will have the desired outcome before jumping in at the deep end. A very low-risk way of starting off is to prototype yourself rather than charging a developer and from this prototype get investors or others who can share your vision involved to help you commercialise it. It’s always easier selling a physical snapshot that others can see as opposed to an idea.
Sitting right in the middle are doctors who don’t know how to code but are good enough to be able to use tools to inject IP into an existing product to make it desirable for others to buy and off load the risk too. Ardens and Primary Care IT are examples of such individuals
Whether you code or not there is a specific skill set you need to have to be successful and I think most doctors have this. That is the ability to break big jobs up into smaller bite-size chunks. I say most doctors know this as this what we had to do for years on understanding the huge topic of medicine the subject and being able to break it down to understand each aspect of it. Coding is no different.
How Big Do you want to be?
There is also a question on how big you want to be which ties in to the start of this blog
For larger projects gets clinicians to code is a very inefficient use of their time
For smaller projects, you need to have a larger skillset and if you have your own small business you should be able to fill the shoes of every part of that business. You can mitigate this by giving the developer a share in the company to tie them down. Otherwise, this represents a reliance you can do without so being able to code then becomes more advantageous if for example you lose a developer and have to maintain code while finding a new one.
There is another solution which is to go Open Source which has several advantages as you don’t really need a legal entity and if you get a few like-minded individuals you can all work together on a common goal more focused on the vision rather than worrying about other aspects of the business. But if you are giving your code for free how can you pay your bills? Well, the hope is that by being free it will increase penetration which in turn will help your standing and you can offer consultancy in its implementation within the NHS. I would love this concept to work but I don’t think it does at the moment as for all intents and purposes IT is free for NHS staff or perceived that way. Costs are abstracted out from the user and paid for by the taxpayer via contracts and procurements. So going open source and not going open source has little meaning to the user (not the commissioner). Where I think there have been success stories are in large movements such as OpenEHR and some US movements eg Mirth Connect which is now called NextGen but these are huge and have taken a long time to grow. Conversely, open source happens when a company is really big and wants just open-source to grow its community. Microsoft is a good example of this. From a commissioners point of view, I think the problem with open source is the risk. Why would they look for an open-source solution when a company offers them a proprietary solution albeit at a more expensive rate but at a perceived lower risk to them. Ironically though mature open source solutions tend to be more robust as they’ve had a whole community looking over them rather than a smaller development team
For Wanabe Coders
If you really want to code this will start you off in your direction of travel but bear in mind if you haven’t done much before it’s a very difficult mountain to climb and maintain your day job and sanity. There is this 10,000 hours of practice. It’s a common rule of thumb, popularized by Malcom Gladwell in his bestseller Outliers: The Story of Success. More recently it’s not as popular as a concept but that aside 10,000 with a practical time investment for doctors at consistent 3 hours a day is about 10 years so be prepared.
So where do you start? Well it all depends on what you want to do as your final end point. It’s similar to medicine where we qualify but don’t decide on specialisation until later but in this case it would be good to know as you just don’t have the time to learn everything.
Having said that there are basic core concepts which are across everything in software development which everyone needs to be aware of (eg object orientated programming and to an extent relational database concepts) but bear in mind which cog you want to be in the larger engine. Very early on I wanted my main focus to be on Line of Business applications within GP Surgeries and have focused my learning based on this core philosophy.
Development 101
You sometimes hear this term “I’m a full stack developer” but what does that mean?
Almost all applications have data following layers of separation.
There are 2 ways of looking at this
3 Tier
This is a principal more for an enterprise solution where you have 3 distinct physical locations where the data is stored or presented.
The lines between each location represent the internet or networks which move secure packets to and fro depending on the need. A term we use when transferring data in the pipe is a DTO or Data Transferable Object with Json (a way of structuring data in text files) nowadays being the preferred format of transfer.
There is another concept is around how applications at a smaller scale are organised which is similar in some ways
3 Layers
In this example, you are moving data up to present information to the user and back down to a persistent data source with your programming language as the glue to connect both together but this can happen on the same machine .
Full-stack is normally associated with this concept so if you want to code you need to think about where you would fit in.
Which language you want to learn depends on where you fit into the “Stack”. Personally, I think Doctors should be more front end as the nuances of the User Interface requires a lot of knowledge in the field.
Which language should you choose
To be honest, nowadays it doesn’t really matter. More recently with Mono, .net is open to non-Microsoft platforms and JetBrains offers amazing Java environments on Microsoft platforms. I’m .net C# but that not really by design. It’s just something I’ve learnt from a young age which I’ve carried on and I haven’t the time to learn new technologies.
.Net
Ah, the land of corporate NHS and its bread and butter. Microsoft has a long history with NHS applications but this is changing. EmisX will be using the cloud platform of Amazon Web Services rather than Azure which is Microsoft based. Also, the NHS spine is Java-based. As stated we are in a mix and match stage where we can truly have different technologies talking to each other.
However, if you are developing a desktop application you have to choose .net
Java
More for back-office development and middleware Java is essential. In terms of pure coding languages, there are more Java developers than anyone else in the world. If you want to attempt more back office and you want to focus on popularity, Java is your jam.
However this is probably one of the hardest to learn from scratch probably with .net
CSS Html Javascript
Focus here is around the front end or web page development. Javascript from what little I know of it is a very poorly formed scripting language but has become probably the most powerful and popular one to learn because of one simple fact. It achieves the holy grail of update once and deploy everywhere. You change a line of code on your web page, bang it changes everywhere no patching no update and no environment issues. There are more browser-specific issues to take into consideration but this is why it’s so powerful.
Html is a way of showing your web pages. The content goes here
CSS is a way of formatting your web pages. The styling goes here
Javascript is a way of how you interact with the web page. The coding goes here.
If you wanted to focus on web development this is where you should start
Html is not a programming language!
Python
Python hits that middle ground between a scripting (interpreted) language like Javascript and coding (compiled) language like Java.
It’s a good start for beginners as you don’t have to worry about data types (ie how a text is stored vs how a number is stored) and it takes a lot of the hassle of coding away from you.
It has a low level of entry and a high ceiling. If you were really interested in coding I’d go for python to start off with then move to .net or Java as you become more comfortable with the coding environment. You could also stay in Python and there is a large community and it’s open source.
PHP
I had to include this as a lot of developers use PHP as the glue between javascript (Front end) and MySQL (database). I don’t know much about it for good reason but from what I do know it’s fast, complex and ugly but gets the job done. Don’t mess with PHP developers! Facebook is developed in PHP as is WordPress which is probably the most popular container for web sites.
If beginning do not even think about starting on PHP!
How to Learn
There is so many resources out there its so difficult to recommend any and everyone will have a different opinion. A few options are
Attend a Course or formal degree.
To be honest, if you are really serious you need to attend a course or go for a formal software development postgraduate degree. The reason for this is that it focuses your mind and gives you a goal and formalises your thought processes and gives you structure. It will also help you with your self-motivation as it forces you to work!
Subscription Level Web Sites
These are a few sites I’ve used and have had good feedback from. They help you to work through at your own pace and if you are self-motivated enough will not only help you once you have got to a certain level but will help you go to more advanced topics. I subscribe to Pluralsight which is more .net focused but has other areas of interest too. Others include Codecademy (for Python) and Code with Mosh who I found such a good teacher of concepts. Otherwise, there are a myriad of YouTube Videos.
General Coding Advice
A few points which helped me on the road
Get a good Patching Software if you are planning for desktop development
Learn about GIt and use it, regularly. I’ve recently been introduced to GitKraken which I’m so impressed with
Decouple the Code Separate the Data from the application. Look into interfaces between layers and look into onion architectures
Reduce your software dependencies ie what external applications you need to depend upon to get your app working
Automate data transfers into the application via an API rather than rely on users to do this
Do not use the GUI of another application for example AutoKey as it’s not a reliable way of obtaining data. The other application developer can just make a subtle change to the GUI and it will make your application fall apart for you
Don’t use media that you can’t automatically deploy and patch up. You need to avoid manual updates. Although Excel VBA spreadsheets can be ok for prototyping you can’t really use them for larger-scale applications.
Finally a shout out to a book that took me to the next level from doing little snippets of code to being able to do full-blown applications. It is an old book now and there should be modern-day equivalents but this book really helped in crossing the chasm for me. There a lot of YouTube videos now that fill this role
For non Coders
This is probably simpler but it’s important to get a developer and define your boundaries and be very meticulous about your vision with the ability to break everything down to its most atomic level.
The Business Logic is your jam which is the layer between the database(what you store)and the GUI (what you see).
Get the developers to create tools for you to use this as your playground
Product Life Cycle
Just to give you an idea that it’s just not creating code this is a brief timeline of what is expected from you in your journey
The Pitch
Selling the vision without showing anything but asking others around the to buy into your idea.
Prototypes would sit here
The Investment
As stated you cannot develop at pace without investment be it from your dividends, a loan, external source. There is a risk if you invest yourself but a potentially higher return if you can manage not to get external investment. With external investment though might also come expertise in the area which will help you be a success.
The Dev
Working with developer to create the first release
The First Release
1st build is very rarely good. You need to persevere and iterate and learn from mistakes. Unless you are very lucky you will need to change the product to adapt to what everyone wants rather than what you want.
So when to release your first version? The hardest question I’ve ever had to face and still get it wrong
The Market
The concept of the product selling itself is a misnomer. Products in healthcare don’t sell themselves and marketing to me is one of the most important aspects as highlighted above.
You need a way of promoting new features so they don’t disappear in the app and aren’t used. A Spike of interest occur when this happens which helps the marketing
The Support
Users need a port of call to do reinstalls, crashes, password issues. These require telephone and remote support.
The Training
Very few products don’t require training unless they are really simple and fill a specific niche. If you don’t train users won’t use it to its fullest capability and might now renew when the time is up
The Iteration
Further research and development is required to move forward.
You always gain more interest with each iteration. After each release interest wanes until you develop a new feature that you can promote which will help sales. Hence you need to continually develop your product and don’t sit on your laurels.
From feedback and your own roadmap, you develop further then go back to The First Release section above. Rinse and repeat
The Sahara of Development
Summary
When I got my Master’s degree Mark Shuttleworth who is the creator of Ubuntu gave a passionate keynote lecture. He spoke in terms of not chasing after success, just work hard in what you do and if you do well, success will follow you. I think at the moment I’m far from successful but that doesn’t stop me from enjoying what I do.
And for those who haven’t been dissuaded by the content of this blog or have managed to read to the end, I have a message for you.
“Welcome aboard. The train will be departing in 10 minutes.”
I’ve been mulling around this idea for a few months now and thought I’d finally put fingers to the keyboard. It started from a conversation I had with my local commissioning team around how much impact does primary care actually have on “waste” in health care. What I meant by waste is around having to manage patients in a more expensive way which also tends to be worse for the patient too as it can entail non-elective admissions. As the idea evolved it was less around where money is wasted and more about how as health professionals we can make the health care system more efficient.
The ultimate end point is to
provide the patient with the best evidenced based care
focus on the right patient before they get worse
promote “upstream” care which is to encourage patients to live healthy lives to prevent them from even entering the medical engine until later in their lives.
Do this together in a joint collaborative way rather than in individual silos.
The diagram above represents providers within health care and how much a provider has influence over another provider. The boxes represent various providers within the health care system, the line of interactions between each provider but more importantly my suggestion on systems or interactions between providers to improve the overall efficiency.
Systems represent keys to unlock the door to prevent waste in health care. The better quality of input into the provider, the more efficient the output provider will be. The boxes in between providers represent this. Others might have different ways in which these interfaces can be made to be more efficient. The areas in grey are just my suggestions and my thoughts around improving the input quality. You may have your own.
As you can see in the UK Primary care is right in the middle which is the reason why GPs make such good commissioners of care whether they like it or not! By commissioners I mean look after patients within the constraints of a budget.
Each System in Turn
As I know a bit of IT, I believe we can really leverage technology to help improve the efficiency of each system and will go each with examples
Access to Primary Care
Lacking Primary Care Skills in relation to Access to Primary Care leads to more A+E Attendances
Patients due to society have an amazon type expectation around how responsive services should be. The government as well has fuelled patient expectation on how the NHS should run. We could ask inappropriate A+E attendees to be redirected or educate patients but if GPs can only see them after a few days and they’ll get want they want in A+E after a few hours guess which service they will go to? The reality also is that A+E staff have to manage the risk of sending someone home and also they just get on with their job which is caring for patients rather rejecting them. “GP Jobs” can also be hard to work out and staff just tend to get on with seeing the patient in front of them rather than worry what the most cost-effective way to manage them is. To be able to get patients to not choose A+E when they should see their GP, you are left with worsening the A+E Experience or improve access to primary care. I occasionally get the odd remark “The waiting time in A+E was >6 hours so I thought I’d come to you!”
It’s a shame the government stopped giving a financial incentive to improve access to primary care as this was an important system due the following
The more patients who can’t access their GP in a timely manner the more will go to A+E
More patients who go to A+E will result in more Non-Elective Admissions by the sheer volume of numbers.
Non-Elective Admissions is the least cost-effective way of managing patients but it is essential if the need arises.
Tech Suggestions
We should deal with today’s problems today and aim for the same day turnover for urgent cases but still allow for some non-urgent slots. Give patients a responsive service in primary care.
Virtual by Default. Managing Access On-Line
In the world of Covid we are in we have the perfect opportunity to continue to contact the patient via more efficient methods rather than face to face and Telephone Triage systems have become the rule rather than the exception. I sure I am with others when I say I’m very surprised at the number which we can manage over the phone and takes my mind back to what we were all told at med school; that diagnosis is mostly from the history; the examination is just to confirm this.
Communication with the patient is the key here with lots of ways to connect
I think Accurx by luck or design has managed to fill a need in this area although others I know are around. Ironically iPlato and Mjog are more around recall although Mjog has it’s own offering for consultation messaging I guess in reply to Accurx. iPlato offers access to our appointment book but I think this is wrong by default as we need a triage system to be more efficient with access. Patients through no fault of their own have no idea what the best way of managing their problem with their GP is, so require triage.
I’ve found video has its uses more for unwell patients but it’s not for everyone as the price of entry to try to set up can take more than handling the patient via a phone call!
I’ve blogged about emails here but have found pictures of rashes essential via email. Accurx also allows pictures to go into the notes which is very useful but the compression can affect the view we see which is not entirely their fault.
Imaging and Investigations
Primary Care Skill who offer good work up of Imaging and Investigations will result in better quality Outpatient Care
It goes without saying that if you do the work up on a patient before referring you are better off doing a good referral and not waste the consultant’s time.
It’s important to say that there are different reasons for referral. I’ve blogged about this in my blog called Reasons a little while back
Tech Suggestions
Virtual by Default for Secondary Care
Just like patients can talk to Consultants why can’t GPs? We should have a portal to allow allocated time slot for a GPs to discuss cases with consultants which are properly commissioned and performance managed
We need to use advice and guidance as more productively than just a single fire and single return at least and maybe even forced for some specialities.
Microsoft Teams has come at the right place and the right time to be the communication tool we need to achieve this efficiency
Extracting Snomed Codes from the referral letters Letters we get from the hospital contain a wealth of information. At the moment the only way to insert these into our clinic systems is to manually insert them or use OCR via Docman which is slow and cumbersome. We need letters to and from the hospital containing Metadata of important Snomed Code with text which automatically inserts into the clinical system eg Hba1cs and OGD with the result. At the moment eRs is just a wrapper for text with no real intelligence.
Connecting the referral letter with the reply to help to educate GPs in why they referred to help them improve for the next patient. Because there is such a difference in time between our referral and the consultant’s reply you forget why you have referred. It would be nice to automate this connection to reflect on this and prevent further referrals as the GP would learn from the referral and response. Yet again if used properly Microsoft Teams could achieve this endpoint as discussing a case with a consultant in realtime in itself is a learning experience for primary care.
MDT, Risk StratificationTools
Community Care by using MDTs can focus on the right patient to prevent Non-Elective Admissions
Ah, the holy grail of the health system! For those who have seen or read minority report the systems out there are trying to be pre-cogs.
The vehicle which is the governance and getting the right people talking at the right time (the easy bit)
The content which is choosing the right patient (the challenge)
For those who just want the money slide, this are my thoughts about choosing the right patient in one slide which can be difficult to create an algorithm for as it requires a human element
Tech Suggestions
There are a myriad of precog “solutions” out there so I can’t really comment but bear in mind most of them don’t provide a 100% accurate list as the human factor is difficult to record and analyse. You know what they say…rubbish in…rubbish out.
However, the direction we are travelling in is to try to risk stratify populations not only within the community but within our registers and to tailor care and focus on the most unstable. My product PatientLeaf can help you with this when seeing patients in clinic.
Prescribing and Patient Compliance
Primary Care Skills will help the patient experience and improve compliance and trust which will help patients take their prescribing
For me, no money on prescribing is wasted money to an extent. My pharmacist would probably have a fit hearing this but to clarify. Prescribing drugs to me is the most cost-effective way to treat patients.
Complaince is a huge problem and I believe it’s truely related to
How you involve the patient with your care. Patients who you work with tend to take medication more than those you order.
How much they trust you. This is normally based on previous experience with them and developing the relationship.
One of the big strengths of PatientLeaf is exactly to address this problem during the clinic in realtime.
There are several intelligent dashboarding and data analytic tools such as Eclipse and Pincer which help you identify the patient based on medication usage and other factors. PatientLeaf will help you manage this patient in your clinic.
Proactive Care with Good Recall
Primary Care Skills help you to be proactive and with Good Recall can call the patient in to help Preventative Medicine
Not rocket science but there are 2 types of patients which keep us busy. Those that come to us (reactive) and those which we call in (proactive). QOF and Target Driven Payment schedules have allowed us to focus on this important aspect of Health Care. As we move forward we need to subcategories these populations into risk or severity of their condition to put more energy on the ones whose values are off kilt.
I’ve always said this but Pharmacists are such an underused resource for preventative medicine and should be working with Practice Nurses around Good Recall systems. We need better coordination with this.
The idea is to automate interfaces as much as possible. These need to require no human interaction more than a simple click of a button. Example of how data should integrate between organisations eg surgeries should just do EMIS exports to get their KPI targets which require no work. Conversely, commissioners should have tools to process this data without manual effort.
Tech Suggestions
As this is my blog I have to promote my products (dammit!)
PatientChase which helps you with your recall so one patient with multiple conditions is contacted once a year as well as automatically coding this into EMIS. We are branching into other non-QOF areas such as immunisations and Drug Monitoring and offer SMS, Email and Letter contact.
PatientLeaf is our new product. PatientLeaf is a real-time clinical safety and efficiency app which clinicians use in their consultations. Everything users need about the condition is on one page as a filtered timeline of the patient’s medical history to give you the information you need at the time you need it. This allows the user to make better clinical decisions faster. With this, you are able to easily identify patients who you need to focus your attention on
SMS Texting via both iPlato and Mjog offer solutions to contact the patient. If Accurx offers this, they will close the market for these competitors.
Ardens and QMasters offer solutions in terms of enhanced EMIS Templates but my experience of them is that they are busy and take more time during the consultation but I appreciate what they are trying to achieve.
Health Campaigns and Preventative Medicine
Social Services via Health Campaigns will help Preventative Medicine
Preventative Medicine is a gearing ratio which affects the whole system ie if we focus more on preventative medicine we will have fewer patients in the system and as such can manage the load better.
Tech Suggestions
Social Media We should integrate campaigns with social services so if they are promoting a stop drinking week all the web pages other avenues of social media outlet from Health and Social Services should push on the same message at the same time. This requires coordination but also knowledge of social media which has become the defacto way of communicating with the general public
Pulling the Strings
We are constantly given incentives by commissioners around how to improve one budget area but occasionally fail to realise this can have a negative effect on the total health economy in terms of patient care and the budget. You pull the string in one place and it unravels elsewhere Example of this are schemes to
stop referrals to hospital outpatient which improves the elective budget but will have the more detrimental effect of getting them admitted non-electively which will affect the bottom line more
reduce investigating patients which is brilliant in terms of us helping the lab test budget until you realise on average a blood test cost 5 pounds and by casting the net wider you could prevent a 50,000 admission.
Pushing on reducing the Prescribing Budget. The prescribing budget of one of our local CCGs a little while back was very low. Impressive until you realised that their non-elective admissions were incredibly high and as a result, the bottom line was not good.
GPs in the Middle
GPs are thankfully not employed by the NHS but contracted out and as a NHS protected business actually I believe makes them more efficient as they take more ownership of their own surgery and how it’s run.
Also thankfully there is a disconnect between GPs and the commissioning budgets they hold. This I believe is the cornerstone of the high-quality care we offer as we treat patients based on getting them better rather than how much they will cost us. Patients are the commodity not the budget .
So how can you encourage GPs to improve the systems next to them? In my experience, there are things which make GPs tick
Help them optimise their Income
pay them more money to achieve a common end point but not in a way which goes against patient care, for example, do not offer money for them to reduce referrals but more money in systems to enhance the quality of referrals
Offer more Patient-Centred Care
Offer systems to help connect and focus on the patient
Provide Evidence Based Medicine
Provide and educate GPs
provide systems to help them improve and get close to best practice medicine such as PatientLeaf
Schemes which help make the systems more efficient which are out of primary care contracts need to take these 3 above points in mind in order to actually get GPs to implement efficiency changes.
The bottom line is GPs as with normal human nature always ask “What’s in it for me” and schemes need to create a Win-Win for GPs and commissioners.
Summary
In the health care horizon, our focus needs to be on systems to improve on our efficiency between providers
Each interaction represents a system with the aim to focus on best practice
If we can really look hard at redesigning each system in turn and we can improve cost-effectivity yet still maintaining quality.
This short blog is one of those really frustrating scenarios where one service exports in a certain format but imports for a 2nd service only accept a different format. Welcome to the world of disjointed healthcare!
Before I explain further this might be hitting a sledgehammer with a walnut and please let me know if there is an easier way from EMIS
Exeter is a services which manages our claims, payments, immunisations and other operational aspects of the surgery. It’s a connection between us and other providers who want to receive or give data.
One of the many tasks we have to do is to export childhood immunisations from EMIS and import them into Exeter. Unfortunately though the export from EMIS isn’t quite in the format required to import into Exeter and I’ve heard of some surgeries having to manually import each immunisation in!
Mapper
I’ve created a simple mapper which takes the EMIS export and converts this into a format which is importable into Exeter
For non-techies
You can find the files you need below. Simply extract the zip file into a folder and run the files. There are 2 executable files, one for the 2 year olds and one for the 5 year olds. Choose the relevant file for the list you are converting. The resulting Exeter ready file will appear on the desktop for you to upload.
This is a simple mapping application using MVVM with WPF with a sprinking of the onion architecture although this is all in one assembly, the folders are positioned to separate the code out. This is ok as the codebase is so small.
The main meat of the app happens when you click on the Export to Exeter Button. This fires of an async wait which fetches the data and imports it into an in memory Repo then exports the csv to the desktop
The Repo object imports the data, the ExportCSV exports the data
This code imports the Emis File using CsvHelper. CsvHelper has evovled into an amazing library to facilitate csv to models mapping and models to csv and is brilliant.
Noticed I’ve used an interface in the core assembly, in case in the future I want to do something extra like import the data into a persistent store or separate out the code into assemblies but to be honest I’m don’t think this is needed with this code.
Once the emisData is imported in (in the form of EmisModels) they are then converted to ModelExeter Objects conforming to the Exeter required input csv format
We then use our old friend CsvHelper to export the Models to csv
Nice and simple!
I thought about having both 2 and 5 year olds as one application but I didn’t want to confuse users so left them as 2 separate projects. For future refactoring they should be in one project to avoid unnecessary duplication.
Emails have become an essential method of communicating for the last 40 years and ubiquitous for at least the last 10 years. Every business you can think of uses emails. So why is primary care so far behind?
Talking about the service especially to our younger cohort it’s become clear that there is an expectation for us to be able to communicate this way with lots of patients being pleasantly surprised or just saying why we didn’t do it sooner.
The problem is patients ring their GP surgery which is invariably engaged in the morning just to get on the queue for us to ring them back. Then when the GP rings back, and the patient isn’t available and you can play a frustrating game of phone tennis. If you miss them, they ring back just to get on the queue again. Very frustrating and you can end up with a non contact thus missing a diagnosis or the patient going to other health care providers eg A+E to get their health worries addressed.
In our surgery, we’ve been piloting a system to allow patients to have direct contact with their GP via email without using online consultations for the last 4 months. This Blog is initial thoughts and the pros and cons of using this system.
Information Governance
The biggest question myself and I’m sure you would be asking is around information governance and confidentiality of the email sent and received. We’ve worked with our local GDPR representative on the back end of an email they sent explaining the current stance around communication via unsecure email with your patients and visa versa.
This is a quote from this email from Miles Dagnall (thank you Miles), our independent Sutton Data Protection Officer
“In situations where there is a conflict between the principles of providing care and controlling data, the provision of care must take priority. Having said that, the practice needs to minimise the risk to data and systems integrity wherever practically possible.
Practices can do this by telling patients about the system and begin to make this the norm for communicating with the patient, explaining that this keeps their data secure.
If decrypting the email remains impractical when communicating with patients, practices should preferably respond to an email received from the patient within the practice e-mail system. If that is not available then the practice should check with the patient verbally where possible that the e-mail details on the patient record are correct and to use those.”
The bottom line is that so long as you are sure the email you are sending will be sent to the expected individual, provision of care is the over ridding principle. In our system, we wait for the patient to contact us so we know that the reply will go to the correct inbox. Happy to share our DPA within anyone if required.
BTW if you did want to send a secure email to a patient, it’s easy: just type the word [secure] in the 1st word of the header of the email and it will send the email securely asking for the recipient to log into a secure web page location to retrieve this.
We offer secure emails to patients but not one has taken us up on this offer so far!
So we work on an implied consent model. We text the patient to show them the link explaining the system and when they have read it (based on trust) and are happy they can use the email service. Our standard text message is as follows
By receiving this text you are happy to send/receive emails and have read the information on our webpage link which is: http://www.parkroadcentre.co.uk/?page_id=317 This service will only be monitored from 8 am to 12.30pm weekdays. If it is more urgent please contact us directly on 0208-647-4485 or dial 111 outside our normal working hours of 8am-6.30pm. If your condition is very urgent or life threatening dial 999. This email is not for prescriptions or appointments. You can email us on mysurgerysemail@nhs.net
Workflow
Below is a self explanatory flow diagram of the current model. We state to patients that we will reply for the next working day from 8am-12pm to manage expectations but we tend to reply when we have the time. We are also clear in saying that we do not manage urgent conditions and they need to contact us directly or ring 111 for this.
The above is a workflow example of how to manage communication when the patient rings. However once the patients has the email, they don’t need to go through this system and they can email us directly.
Once the email thread is complete the GP either copies and pastes or types up a summary of the email consultation in the notes. We also add the code 9N3B (E-mail received from patient) in the consultation. BTW, in the consultations tab of EMIS there is an option called CR Config. From here you can add a Consultation Type and name it “Email Consultation”.
Microsoft Outlook
We use outlook as the operational software to manage messages. Since this is normally installed in each users machine, installation was not a problem. Otherwise a few points
Each doctor has a category (Categorize in the Home Tab) which is colour coded. Once an email has been allocated, their name is tagged in the category and their colour appears next to their email. In our surgery the most senior clinician does this but in larger surgeries there is no reason why this can’t be taken over by a senior administrator.
We work on a Zero Inbox policy so as soon as a message is completed we move the email trail to Archive. This way we are aware of outstanding emails.
Occasionally we found a few emails in the Junk mail so look out for this. You can disable Junk Filtering by right clicking on the junk folder and choose junk mail options
You need to sort out the email via conversation and also group them with the newest on top them otherwise the email thread may appear as separate entries which can be confusing. See this screenshot
online TRIAGE SERVICES
This Blog isn’t about comparing this method to Online consultations such as DrLink, AskmyGP or eConsult and at the moment we don’t have the data to see if email consultations actually improve access. In our workflow we have provisions for online consultation document which points to the surgery email to be triaged accordingly.
I can imagine though it can be frustrating for patients who want to talk to a real person having to go through an algorithm to achieve this, similar to us trying to talk to a big company on the phone for support and having go through reams of options on the number keypad before being told they have to talk to a real person or being pointed to a web page to manage the problem themselves.
Managing different sources
One concern raised is that you are introducing yet another form of communication with the patient. I’ve put together a table around initial thoughts of each method.
It’s a matter of fitting the right consultation in the right place and more importantly trying to avoid overlap which creates inefficiencies eg an email consultation leading to a telephone consultation which leads to a face to face taking up “3 slots” when it could have been managed with one.
We’ve found that with email, replying back to change the type of communication is as simple as “see me in clinic”. With a telephone triage it can take as long as a face to face to achieve the same result.
The other issue is having direct contact with the GP which is lovely for the patient but potentially an issue as systems are in place normally to protect this so GPs can make appropriate use of their time. Reception normally manages the telephone and a triage GP manages face to face.
Below is a table of my thoughts about each form of communication
Pros
Cons
Face to Face
Human Interaction | Examination
Patient Travel | F2F often not required
Telephone
Most Convenient Method
Unable to Examine | Missed Contact
Email
Contact not missed | Convenient
Unable to Examine | Direct GP Access
Every day your patient population generates work passively by contacting you and actively by your surgery recall. Your job is to ensure you have the capacity to manage this to maintain the health of your population. My hope is that email with help manage this rather than generate more passive work!
What we can’t do
We encourage patients not to use this service to get an appointment or for a repeat prescription and if emailed about this we direct them to other apps which can do this or ring at reception. It’s actually more obvious that you would realise around what needs to be seen face to face. I’ve had patients who have asked me to look at a skin lesion and one patient asked for an alcohol detox via email! I kindly directed them to book an appointment for a face to face.
Worry of Litigation
We discussed the concept of emails consultations in a small group discussion recently with other GPs and the worry about ligation came up. I remember the time when we shunned telephone consultations and the medico-legal issues this would create but now it’s accepted as the norm. I believe this is the way emails are travelling in as a communication form.
One could argue that emails are better as documenting conversations than face to face or telephone as frequently we have to interpret patients communication which can lead to disputes between what the patient thought of the consultation vs what the GP typed. With email it’s black and white and in theory would be safer so long as you have the appropriate safety netting.
Dr Google and EMail length
The dreaded Dr Google and this now famous meme which I think is very arrogant.
I actually don’t mind patients looking up their condition and coming to us about it and am the first to say I don’t know. As GPs we can’t expect to know everything and from how I’ve approached this method, patients do understand. But what Dr Google does show is that patients have a vested interested in their condition so it’s easier to work with them to find a treatment but more importantly compliance goes up.
Where I do have an issue with Dr Google is in educating the patient on, in essence, what we learn with experience and that is
Common things are common!
Just like a junior med student it’s important to go through common causes of their symptoms first before exploring the exotic which tends to come on the top of search results or the diagnoses they worry the most about.
So why mention Dr Google? I’ve found the quality of the conversation between myself and the patient is exponentially better than face to face or telephone where the patient has to reply on the fly as do you. With emails they can compose their thoughts and write to you clearly. You can then compose your thoughts and write back to them. Both can use Dr Google or NICE guidance to check up on, which just isn’t possible face to face or on telephone. So in my opinion.
The quality of the communication improves with email.
We frequently get emails of epic proportions which was another potential issue with were worried about. From my experience you can quickly scan these emails to their essence and also have lots of text to look back to if you need to get a recap on their symptoms. As we are so busy my patients appreciate that our replies are short and to the point. We don’t have to and actually can’t reply back in length.
Scalable?
Our surgery is 4300 so it’s not a big surgery. The question is if it is scalable to larger sites. I’m afraid I don’t know the answer to this but am currently proposing this method to local surgeries who have a larger population based on the above workflow.
Does it ACtually Improve Access?
The million dollar question.
With regard to access. We haven’t as yet promoted this feature to all our patients and have just been trialling it in our surgery on an ad hoc basis for the last few months which is in the region of 40-50. Anecdotally it seems to improve access at the moment but need to do proper analysis to see if it helps with face to face once we release it to all our population and promote it. Will feed back findings here.
Where it has without doubt improved is in patient care. Patients who use the service love it and get their issues resolved quicker and better from their point of view.
Some quotes from our survey although this population is probably rather biased!
No the service is brilliant! Very Happy! No. It’s beyond perfect! Nothing at the moment. I am impressed by the response time
One offset we also have is that where a patient would normally try to work out how to manage themselves if they have easy access to GPs via emails they might overuse the system. So far we have had a small number of emails where we’ve wondered why they emailed us but to be honest these are the easiest to reply to!
Summary
Email consultations have the potential of transforming how we communicate with the patient. There is no doubt it is patient-centric and panders to their needs but will it be a win also for the GP to help access?
At the moment I believe it will help access and improve efficiency but instead of having 10 minute face to face consultations, we will have shorter more rapid dialogues with patients. The ultimate aim is to prevent overlap of communication as mentioned above. Overlap introduces inefficiencies in the surgery appointment workflow where we spend 20 minutes with a patient who we phone and see rather than just 10 minutes face to face.
Enclosed are my summary of pros and cons
Pros
Extremely Patient-Centric. Younger patients have an expectation to want to be able to contact their GP this way
Might pick up on patients who wouldn’t normally contact their GP via other methods
Will help patient population health and won’t miss as many missed contacts
Quality of the conversation improves
Has potential to help access and reduce inefficiencies.
Cons
Extra avenue of contact to manage in our regular workflow
Will it increase workload?
Will need buy in from all the GPs for the system to work
Direct access to GPs might open up the system being overused by patients for matters they can easily manage themselves
I’ve been wanting to get into WPF for sometime. As a GP it’s hard to keep up with software development and my personal niche is always going to be desktop. That’s not to say WPF is new but its principals are here to stay in the desktop .net world. Now I’ve done a little example app and it’s fresh in my mind it’s a good place to share my thoughts. When looking into this there were a lot of basic principals which I felt weren’t explained properly, little key points when I got after a little while which I hope will be helpful to newcomers.
Pre-requisites
Before looking into WPF your C# knowledge should be up to at least knowing about XML – a structured format of storing data Events – A way of encapsulating method calls Interfaces – A robust way of getting classes to communicate with each other If not you are going to struggle with basic concepts in WPF. Unfortunately, it’s not a subset of C# which is as easy as Windows Forms.
MVVM – Model-view-viewModel
MVVM Pattern
The Cornerstone of WPF is MVVM. It’s a pattern around how to layout your application into separate sections which have separate responsibilities
The View All Classes relating to the view are in XAML with Code Behind. Put these in a separate namespace|folder within your UI project|assembly. XAML is XML for WPF and allows you to create controls easily via elements and attributes. eg <Grid></Grid> will create a Grid Control where you can define the number of rows and columns with separate attributes and elements.
The View Model The View Model is the powerhouse of MVVM and is where most of the work is done to manage data from the Model to the View. This should be as a separate cs file in a different folder|namespace as per the diagram below.
You need to have one ViewModel for every View
Laying out your Views and ViewModels
The Model The model is well, the model and is where the data is housed. Naturally, you’d map the database entities to Models to facilitate using them in the code but this is out of the scope of this blog. However the data is fetched, the data for the view model should be only models relevant for the view.
View knows nothing
The view is dumb and knows nothing. It and its code behind should not contain any properties or methods related to the view. This is all managed by the corresponding View Model. The way data is viewed in the View is indirect via bindings. More about this later.
This way you can create a totally different view or layout with the same bindings without changing any code. The vision was that an Artist created the views and all they needed to know was the Binding Names without knowledge of any code.
The View has no properties and methods but does have indirect access to them via data binding
Binding and the ViewModel
This is the important bit of MVVM and the one I found the hardest to find a decent simple explanation about.
You shouldn’t have any properties or methods in your View but you can in your corresponding ViewModel. You connect the corresponding entities via data bindings. A binding is basically a bit of reference text which links the property or event in the view with the corresponding property or event in the ViewModel. It is defined in the View Model and referenced in the view. It can be any bit of text defined by the coder but normally relates to the property or event in question.
To do this you need to do 2 things as explained below 1. Inform the View of changes in the ViewModel and 2. Tell WPF which ViewModel is linked to which view.
1. To notify the View when changes have been made to the ViewModel to update the View accordingly
We do this by using the INotifyPropertyChanged Interface. This is a bit of boilerplate code but basically, it allows you to have properties which the View Model can tell the View to update when a change is made
This is an example of the implementation in a ViewModel
ViewModel implementing INotifyPropertyChanged
In the above example, what is an Observable Collection? It’s basically a List, So if your property is a List of Objects, Change it from a List<> to ObservableCollection<>. The key to the above example is that whenever I set the property, I raise an event which triggers an update on the View. But where does WPF know which area in the view needs to be triggered?
Here is a picture of the relevent place in the view. Notice how the Text next to the word Binding relates to the corresponding property within the View Model. The word Two Way means that I want to connect the view and model so that changes in one will automatically update with changes in the other and visa versa! This is a very powerful feature.
2. Which View relates to which View Model There is one missing piece of the jigsaw, we need to tell WPF which ViewModel Object relates to which View. We do this via the DataContext. It’s simply a reference to connect the View to ViewModels. Once this is done the Bindings make sense. You can do this in the code behind but I think it’s slicker doing this in the XAML
In this example xmlns is just the XAML equivalent of the “using” term in the header code of a cs file.
Once the Data Context is set the Bindings and Notifications should marry up and the connection will then make sense to WPF
Properties, Buttons and Behaviours
Ok so we said that INotifyPropertyChanged is used to inform the View of changes made in the ViewModel (and visa versa for Two Way Binding) and we use the setter of the property accessor to raise the notification but what about events eg mouse button clicks?
In this case, we have the Command Interface which Button Events use to the link the View to the ViewModel via Data Binding. They are a way of abstracting out your execution logic for actions like clicking on a button. Even though they are associated with buttons they can be supported by almost all WPF Controls. Unlike commands, Behaviours extend controls without having to subclass them. This makes changing the behaviour of an associated element easier. So commands delegate out responsibility to another entity (ie the ViewModel) and behaviours extend the functionality of existing classes.
In the Example below clicking on Export to XML triggers a method to run an export on a linq query to export a List to a XML File
You start off by defining the ButtonCommand which implements ICommand. This can be put into a utilities project|assembly
Here is the boilerplate code (note you to reference PresentationCore!)
ButtonCommand
In your ViewModel you then define your ICommand Object which exposes the method calls relating to the constructor of the ICommand Interface. In this example it’s ExportToXML and CanExportToXml
In ViewModel
Within your XAML you can now bind your Button to this Interface
In the View
Behaviours are similar to Commands but apply to non-button controls (ie not buttons, check boxes or radio buttons)
So the View Models Interface with the View via – Data Bindings for Properties – Commands for delegating the responsibility of events to other classes eg Buttons, radio buttons and checkboxes – Behaviours which extend existing classes enhancing functionality
Features out of this Blog’s Scope
Toolkits
MVVMLight is probably the main toolkit for WPF developers to help them simplify a lot of WPF. Look at this for further development
Data Templates
Data Templates are a way of massaging the data shown in the view for example if you want to not show primary keys from the Models or have the date in a different format in the View from a Model. Out of the scope of this Blog to go in more detail
Getting ViewModels talking
It gets very messy when you want ViewModelA to talk to ViewModelB and C and can create spaghetti coding. A better way is for ViewModels to talk to each other via a Messenger Service which acts as a mediator where you can get a ViewModel to register to listen for a message and another ViewModel to send a message to be picked up by the listeners. MVVM Light for example provides this service off the bat.
Example Project
I’ve written a little application showcasing the above which I hope you will find useful. In PatientLeaf we needed a better way to export Read Code | Snomed Code to our own XML standard and created a small parsing tool to do this.
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
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!
PatientLeaf has been a labour of love over the last 8 years. Being a clinician it’s the one application which I’ve been thinking about for some time and most importantly truly believe it’s made a difference to my clinical care in terms of time taken to make a sound clinical decision in the clinic and also clinical safety to understand what’s been tried before at speed which is how UX design should be.
In essence, PatientLeaf is an updated overlay which gives you a specific view of the patient based on what you are looking at during the consultation. When I see a patient they normally come with one issue at a time (although it can be several during the consultation!). The idea is we slice the medical notes to focus on this issue and present this in an easily digestible format.
We’ve taken an age-old horse-chestnut as the core of its functionality. As clinicians since the dawn of time, we’ve used medication to improve the health outcomes of patients. Though hypothesis and sheer luck at times we associate modifiable objective and measurable values with health outcomes of patients with the conditions in question. In some area’s it’s very clear eg Hba1c for Diabetes, Blood Pressure for Hypertension in other’s it’s not eg with COPD does FEV1 relate entirely to mortality?
The normal loop is to take a modifiable value -> add a drug/s to help improve this -> record the modifiable value to see if it’s improved -> add a drug/s to help improve this ….rinse and repeat until the value is within or below the ideal value based on evidence. PatientLeaf uses this concept to help the clinician to make the right choice next in the nirvana of patients taking their medication to get them to their ideal value for the least amount of drugs.
Below are some concepts which we’ve tried to address with PatientLeaf
Ideal Value
Our first leaf is Blood Pressure and you’d think it was easy to pick up what the correct blood pressure to aim for would be. This is an entire blog by itself which I will post after this blog but as you’d appreciate it’s very condition specific eg a patient over the age of 80 would have a different optimal blood pressure for a patient with diabetes.
There are several articles around compliance of medication which can vary from 30-60% depending on several factors eg age, polypharmacy. 2 examples can be found here in Medication Non-Adherence Among Elderly Patients Newly Discharged and Receiving Polypharmacy or Changes in Antihypertensive Therapy – The Role of Adverse Effects and Compliance The 2nd article is very interesting and mentions reasons why we change medication. It’s hard to find Randomised Controlled Trials with significant numbers but compliance is a huge problem in the NHS which I will mention in another blog. How often have you had a patient in front of you who swears by taking the medication regularly and you frequently want to say “so where are you getting the drugs because it’s not from me”
PatientLeaf offers a very easy to show colour coded visual indicator of each issue so you can actually show the patient and let them make their own conclusions.
A typical question I frequently ask is what drug should I try next? This is normally at the 8-minute mark when I’m thinking that we need to wrap this up as I only have 2 minutes left on average to write up the notes and call the next patient in. The next question is so what have they tried before and why did they stop it if they did? If you know current clinical systems you know they are long lists of history entries which normally take more time than you have to unpick. Unfortunately and I’m as much to blame as others we don’t code intolerances to medication unless it’s target related. So we frequently have to rely on the patient to tell us if they’ve been on the new drug we want to try before or just give it and go and make the same mistakes again.
With PatientLeaf it’s really easy to view the notes to see when you stopped medication to know why.
Frequently in the current clinic notes, we have a screen with coded information which is a smorgasbord of values and data and frequently we miss out on useful information in relation to the condition we are querying. The noise and chatter of other data make us miss out what we need to know in the pressure of the consultation.
PatientLeaf data mines through the notes and lets you view what you need to know about the condition in focus for example smoking status, Qrisk, ECGs or last echo result for patients in our Hypertensive leaf.
We are still starting our journey with PatientLeaf even though it’s been a long time in concept and development. I’m at a stage that I miss it when I’m not using it and hope you do too! www.patientleaf.com
Read Codes are no more and for those who are unaware we are in a state of flux quietly having to change over to SnomedCT for all coding in primary care. As with most things in the NHS Read Codes are a shining example how to take a promising concept and totally shred it to pieces. We seem to be good at taking good ideas, involving as many people as possible to add their 2 cents to the fray and let it slowly suffocate to become an unwieldy mess which it ended up as. The vision of Read Codes were sound yet flawed: to have a hierarchical view of all things in primary care so an anterior MI is a form of a MI which is a form of Heart Disease the more down the tree you go the more granular the description. Where it fell on its face was on crossover concepts and as we know medicine is never that simple for example is TB a lung condition or an Infection? I know let’s put it in both the Respiratory and Infection Disease Main Branch! Read Codes soon turned into a guessing game to work out which codes were used for what and you had to have a myriad of codes for the same item just to cover your bases. However, they are simple to understand and have served us well over the last 33 years.
Enter SnomedCT. The vision is to encompass medicine and all its complexities into reproducible code which is more accurate and descriptive of the item you want to code. One thing I really like about SnomedCT is that unlike Read Codes, SnomedCT separates out the logic for the user. Whereas some Read Code knowledge was essential, we don’t and are encouraged not to know any SnomedCT codes for any associated text and that’s how it should be. We worry about the text and let the computer convert it into a standard format.
Unfortunately with this comes a lot of complexity and unpicking SnomedCT from the start isn’t easy. I don’t really understand the detail but this is my simple take on it which I hope you may find useful as a starting point.
For each item, you have up to 3 associated features
The Concept– This represents the item and is important as it forms in the links in the chain connecting this item to other items, for example, the ConceptID for a MI is Myocardial Infarction (disorder) = 22298006
The Description – This represents synonyms associated with the linked Concept one of which has to be the same name as the Concept which is called the Fully Specified Name or FSN . For example, Myocardial Infarction (disorder) is also a DescriptionID (751689013). So for this Concept, we also have a preferred term or PT and our synonyms or S.
For Example for the above mentioned MI we’d have
FSN – Myocardial Infarction (disorder) whose Description ID is 751689013
PT – Myocardial Infarction whose Description ID is 37436014
S – Heart Attack whose Description ID is 37443015
All the above synonyms or DescriptionID would link to the same ConceptID which is 22298006
The Relationship – This is the complex bit and defines where the item lives in the hierarchy. It’s not as easy as Read Codes and addresses problems where an item can be all over the place. Relationships only use Concepts. They also have a Destination Concept which tells you where this item is heading to in the hierarchy. But most importantly they have a characteristic which tells you about the relationship between the source and destination concept. It kind of acts like the glue between concepts.
We can only do searches on Concepts (or Descriptions which map to the Concept) and let the SnomedCT engine define the interactions between this Concept and other ones linked to it.
For Example Appendicitis (source) can be
– An Inflammation of the large Intestine (parent)
– A Disorder of the Appendix
– A location (also called Finding Site Concept) which links to Appendix Structure
– A type of morphology (also called Associated Morphology) which links to Inflammation
The type of link is called an attribute and is defined as the typeid in the relationship file specification. So, for example, you can differentiate if a concept is a body|anatomical structure or a clinical finding in relation to another concept. From what I’ve been informed, these attributes however at the moment aren’t being used fully at the moment.
An example of this is shown in this diagram from the SnomedCT Browser
For the techies, the RelationshipID linked to the concept must have metadata which provide a mapping linking Concepts like a linked list. We just know that this Concept links to another concept which links to another concept with the associated relationship of a certain type.
For every given Concept it has references to the parent and child node so you can only go up and down one hierarchy level.
In the UK we have mapped Read Codes to SnomedCT as a first stage. After this, we can then move into the world of SnomedCT. Just make sure you keep warm!
I’d like to thank Dai Evans for looking over this post for me.
SERVICES, INTERFACES & SEPARATING ASSEMBLIES. One thing you realise the more you write code is that the less “moving parts” you have the better or to put it another way the more you put your moving parts into one contained place the better. Pushing items which change or where there will be change in the future to places you can manage is really useful.
Interfaces help a lot here and if you can talk interfaces and just pass the implementation of what you want to do to specific areas, you code is more maintainable.
The following is a brief tutorial in pushing the return of a string depending upon a value in a settings file. This way you can change certain aspects of your code base from a simple text switch.
The Problem
We would like to return a SQL String but the content will vary depending on which area in the UK you are from (England, Scotland or Wales).
We want to push the logic for this into a separate core assembly which manages all the business.
In this case we want the application to know that we want to return a string which will contain a SQLQuery but we are not worried about what the content will be until it’s implementation at runtime. Interfaces define the core of the app and are visible by everything
Step 2 – Create your logic
Next we describe the implementation of Interfaces by inheriting them in the classes where we want to do the work in this case it will be English, Scottish or Wales specific query strings.
Example of the English Class which implements the query above.
Step 3 – Create your Service Layer
The service layer will contain 2 components and abstracts out connection between the Main Application and the Business. This useful in that in the future we can change Layers but because the interfaces stay the same, we won’t break much by doing so.
1. Where we resolve our dependency.
This is where we plumb in exactly which class in the logic layer we wish to instantiate. In this case we take text from the settings file which will either say “England”, “Scotland” or “Wales” and from this inform the complier which object, which implements the Interface, we need for this run.
2. We use dependency injection to pass the ISqlQueryable Object to return the String.
Step 4 – Plumbing it together in the Main.
For this console app, we first have to get the object we need which will implement the Interface. We then pass this Interface to the service to return the string we require.
Hope this will help loosen up your code up. Having this here helps me too as seeing patients take up a lot of my time and I always need a reference to jog my memory of what I know now but frequently forget!
Raza's Site 
You must be logged in to post a comment.