DreamItBuildIt

So you want to code?

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.

3 thoughts on “So you want to code?”

  1. I agree with Scott.
    A good many years ago, I pointed out that I was a third generation car driver: first generation worshipped the machine (only happy underneath, tinkering): scond generation devoted to finding out what the machine could do (happiest racing up the M1 with police helicopters left far behind): third generation think its a very useful thing – good as a box on four wheels, useful for carting children, dogs and groceries around the country.
    I used to have far more knowledge of engines when they were simpler – out of financial necessity.
    Unlike car maintenance, using IT – and possibly even Coding (I started learning fortran at one time – after BBC Basic) seems to have become easier rather than impossible without specialised equipment: even so, I remain unconvinced that learning to write Code would actually be a good use of my time: I think I’ll remain concentrated on Health Informatics…
    Coding is a means to an end: are clinicians expected (by Tim Kesley) to be interested in ends – or is the means assumed to encompass the ends to the extent that if you haven’t studied the means (Coding) and other expertise will be disregarded?

  2. I guess that there are too many variables in the equation to know what the best path is around the ultimate aim of improving healthcare with better outcomes by using IT. It will take all types, those that want to get down and dirty and those that have vision and focus. Why should you code when you can get someone else to do it quicker, better and cheaper? You may not, however the closer you are the “metal” the less chance there is of someone to misinterpret your vision and waste time redoing code. It depends on how far down the rabbit hole you want to go..

    Most good quality products I know don’t just appear from nowhere, they start small, are prototyped, iterated upon then professionalised for market. This nurturing should start with grass root staff and I really believe though we need a bottom up approach to the problem, as you know the top down didn’t really work. I don’t even think the market is ready yet. My ideal world would contain services of nationally defined read only data (eg read code, snomed, SuS and ultimately patient data with the correct governance) open to developers to call and manipulate as they see fit. Clinicians would be essential in this process to help craft their concept into reality and would need the correct tools to do this.

    Your last paragraph reflects my comment on where clinicians should be placed. Are we at the top of the tree (System Analysts) or at the bottom (Hackers)? I guess our expertise is what makes us who we are and will bring this to the table in whatever form we want to contribute.

    Thank you for your post Mary.

    1. Perhaps Dr Foster could address the dominonater issue once and for all by comparing death rates calculated using day of admission and those calculated using day of discharge, evaluating both elective and non elective care seperately. Worth discussion and directly related is the etent to which length of stay is a feature in these assessments of death rates.Many ThanksLuke Readman

Comments are closed.