There has been a lot of talk recently in UK health related IT sites around getting clinicians to code mainly catalysed by an article on Tim Kelsey’s opinion on the matter in E-Health Insider.

This subject has been very emotive for me for a little while. When I talk tech to fellow GPs, they tend to look at me with a glazed look unless I speak like a soft system designer. Developers on the other hand either don’t know how to handle me, or take me with a pinch of salt. You’re in this half way house and don’t quite fit into either world.

2 Blogs whose authors I have a great amount of respect for summed up the issues perfectly:

By Jeff Atwood on how not to code.
By Scott Hanselman on trying to dig a bit deeper.

Please read both links before coming back here… I’m more in Scott’s camp in that if you have a passion you should work towards a goal with help and assistance but also can appreciate Jeff in that learning to code doesn’t happen overnight and should never happen when certain types of individuals are so casual about it.

One obvious answer is that clinicians shouldn’t code at all and that they should just stay in their role, be advised or advise accordingly. However, when appropriately managed and understood, clinicians can be perfect for the task, so long at they know their limitations. For my agile friends, why be a chicken when you can be a pig?

Putting everything into perspective and as with all things in the NHS, no shoe size fits all, but in summary here is my take. IT itself is as broad and diverse an industry as healthcare but there are 2 areas in my opinion that lead themselves more to the capabilities of health care professionals.

1. Clinician Coders make good System Analysts or Enterprise Architects
Here’s the problem. In order to be a good designer you need to have been a proficient coder. Most coders move this way starting from getting down and dirty with the code up to looking at architecture and design. So clinicians can’t just be fast tracked to understand UML without first knowing the difference between an object and a class. However in my opinion the best place for them is at a strategic level to get developers to operationalise concepts. It’s an interesting paradigm and in my opinion is why enterprise level applications might not work as well in the NHS due to lack of IT proficient advisory clinicians.

2. Clinician Coders make good hackers
A bit tongue and cheek but you ask any clinician who ended up coding how they started and most will say they just tinkered with code which grew and grew. For those in the know, our little niches are perfect for prototyping applications for proof of concept and in understanding the business requirements. We also are quite obsessional and perfectionists, the perfect traits of coders. With this in mind….

Clinicians should be given tools to hack the Business Layer

There are 2 takes on this.
– Clinicians should learn tools which can be supported by devs creating services which they can cherry pick based on need. For example a NHS guru developer can create a RESTFul web service around read codes. A clinician can be given or learn tools to extract this information through calls and process the data as they see fit. Of course it’s more complex than this as they then need to present it but you get the idea : they act as the glue between the data and its presentation.
– Clinicians should be integrated into creating the business layer through some kind of scripting language. From my embryonic knowledge of OpenEHR this is the approach I think they are taking.

Tools for the Job
I really admire the work of HandiHealth and will watch with total fascination around how they approach the problem of getting clinicians on board and working closer to the back office and GUI guys to implement suggested ideas. I’m skirting around the issue a bit around tools for the job, but HandiHealth is a good start to realise that clinicians are not alone and we shouldn’t think ourselves as one man bands. It will take a collaborative effort both on a small scale and a large scale to make IT work in the NHS.

Beyond understanding the nuances of any open standard architecture, what tools should clinicians start to learn? I think Python really fits the bill here and clinicians who want to start coding should learn this high level language together with XML.

I’m the first to say I have rudimentary knowledge of Python but it seems to tick the boxes in many fronts: it’s a high level scripting type language; it’s object orientated; it’s open source; you can call services from it; it’s OS independent.. the list goes on.

So in summary in my opinion,

clinicians who really want to start to code should HACK the business layer using high level tools eg python in collaboration and in support with developers

This isn’t a revelation and maybe echoes other’s thoughts on the matter.

In future blogs I’ll try to do my bit on teaching fundamentals of coding from a clinician’s point of view.