clinicians who code
Posted By Paul Cooper on 15-Oct 2012 at 14:01
There is a thread on Doctors.net about 'clinicians who code'.
There are several attractions for suitably-minded people
- its a fine example of 'problem-based learning'. You look up the resources to help you solve the problem in front of you.
- you may want an application that isn't available as a program written by someone else
- I'm not going to let this ****** box of ****** defeat me .
- This is a more useful endpoint than completed sudoku grids.
My personal preference is for perl - practical extraction and reporting language, or perhaps pathologically eclectic rubbish lister , initially devised by Larry Wall, whose real job is a linguist for Wycliffe Bible Translators.
Perhaps I'm just too old for Object Oriented Programming.
Anyway a common theme on Doctors.net is that many NHS IT departments are shall we say 'less than helpful' when it comes to providing assistance to interested clinicians who want to use computers to solve a work problem.
The stated reason is often security.
Ive had a perl script that mimics my personal login to a telnet system at work and then screen-scrapes and parses out information I needed, The view of a head honcho in IT is that they cant sanction people 'willy-nilly' downloading data. So it's OK for me to log in and spend an afternoon reading screens and transcribing data, but not OK for me to use my personal login (so they know its me) in a script that will do the same thing in 10 minutes. Of course the several hours spent writing and debugging the script and looking up VT100 emulation isn't counted, but I'm happy to donate that time to the cause and the ability to take 10 mins rather than an afternoon each time I want the data is still a time-saver.
Go figure, as they say.
There are many positives in getting interested clinicians involved in hospital IT systems.
· Projects are likely to reflect a local problem that needs solving.
· There is immediate user buy-in and a willing tester of interface/system and 'clinical champion'
· Potentially hours of time will be devoted to project at no (or minimal) cost.
Of course there are also negatives
· Enthousiastic amateurs with limited insight can be a positive hazard. I suspect code I write isn't as secure – at least at first go - as stuff written by people who do it for a living. So knowing what you don't know and being receptive to advice is important.
· Lots of little projects can lead to duplication of work.
· Changes 'upstream' can stop things working if the people in charge don't know whats dependant on what they change. The script I telnetted into the system with was waiting for a string of text to appear that it used for parsing out data . They replaced the line on the page that included 'Details', the text the script looks for , so it stopped working.
Puzzling, tedious, frustrating but easily fixable.
Security is a reason often given for blocking and stopping things. But in the greater scheme of things, how big a threat is accessing a system from the computer in my office ?
I think the real reasons are different.
The default is to say no – then you cannot be responsible for any imagined, actual or perceived problems. And I think many of the people in NHS IT are just administrators who just apply rules and have little knowledge or understanding of the technology and hence cannot decide whether or not a proposal is reasonable and do-able or fatally flawed.
It was also pointed out that clinicians wishing to access data and write code are usually single knowledgeable individuals bucking a trend of relative ignorance, both within IT departments and clinicians. To encourage these individuals will require more thought around information governance and the in-house technical expertise. Of course its easier to just say no.
Interested amateurs when encouraged and guided can achieve quite a lot. I was at a meeting in London and Prof Les Hatton had a graphic (included in this presentation). According to his graph, the linux kernel is one of the most secure systems in existence and has been largely written by interested amateurs.
So given the correct environment and encouragement 'clinicians who code' could achieve quite a lot.
I wonder if the corporate NHS will try it out ? I won't hold my breath.
Posted by Grant on 25-Jan 2012 16:01
As you know, there are lots of us in SCATA that write code. I've written and deployed a web-based clinical messaging system that is being used by GPs to seek clinical advice. I had to go through my local IT procedures to get this sanctioned but it's been a success. Alan has numerous projects running in his area, including rota software, critical incident reporting and acute pain audits. There are probably hundreds of clinician-authored systems in use up and down the UK - maybe we should take a poll !
My IT guys would never let me Telnet into anything though - very surprised you get that option.
Posted by Alan on 03-Feb 2012 13:02
It's a mixed experience being a clinician-coder, especially with mission-critical stuff.
Every time I go on holiday I dread problems with my Rota/Leave software which is indispensible in 3 hospitals now, and feels like a noose round my neck.
And part of our RCA discussion on the future of logbooks was what to do about the significant number of third-party "RCA-compatible" logbooks, and their trusting Users who may suddenly become "RCA-incompatible" overnight.
Posted by VJ (Dr V J Joshi) on 27-Feb 2012 06:02
I was directed here by one of my colleagues (oss-uk-health) and found your post fascinating because I had to exactly the same. I was working off McKessen's TotalCare PAS in NW London.
I coded mine in VBA embedded in Publisher2003. In effect, I put an entire telnet client in there & screenscraped the output in order to populate this Publisher file that would print out patient demographics, all drawn back from the hospital number.
ICT become aware of it because my Consultants were chuffed that I had prototyped in one afternoon what they had been for many years demanding from IT and refused.
Since I benefited from it myself, it got an informal trial that resulted in 'public demand' :) that it be adopted. It did & all were happy as I could rapidly revise it to improve ease of use and almost realtime bugfix (assuming I was on shift). It did not require any additional installations as was based off Microsoft Office & ran from the shared network drive.
I then went further and extended the code to track attendances and follow patients through the A&E department, with the additional ability of being able to record Admissions, Discharges & Transfers (ADTs) back into PAS [if the user had such rights]. It also maintained a shadow database to allow Performance monitoring by recording time to be seen, time to xray etc; things that were not recorded in PAS.
Unfortunately although it was considered but not adopted & thus not developed further as the Trust was concerned that as 'sole developer' they would be compromised if I were to be hit by the proverbial bus.
Posted by p cooper on 27-Feb 2012 13:02
of course the best response would have been 'how interesting, you are obviously meeting an identified clinical need. How can we help/sustain this project ( (given that we have had a fair bit of expertise from you for free) "
But that doesn't happen because
- Most NHS IT departments don't contain the expertise
- they are too busy just keeping the current IT infrastructure afloat
-it loses control of the data, and empowering clinicians is not a high priority for them.
It seems different in Scotland. I wonder why ?
Posted by Claire on 05-Mar 2012 11:03
I'm a medical doctor and I don't code, but i would like to meet people who do. Along with a colleague who's a medic and programmer with his own EHR company I'm launching a digital health accelerator programme in London later this year. The aim is to support healthcare startups through mentorship, access to investors and last, but far from least, purchasers and providers.
Just interested in whether this something anyone on here would be interested in? Also if there are other similar forums you could point me towards where I can connect with people who would be interested in taking part in such a programme.
I'm also looking to create a platform that enables entrepreneurial medics to connect with developers and vice versa as well as mentors, investors and so forth, so if anyone is interested in helping with that or knows of others who may be keen to help (or simply join the network in due course) please do let me know.
Thanks in advance for your help
Posted by Grant on 13-Mar 2012 22:03
Are you involved with this at all ?
Posted by Richard Muirhead on 07-Apr 2012 16:04
As the last chair of the Software Developement Group I am well-aware of legal issues and responsibilities.
Perhaps IT departments do not want to host your programs as they will then take responsibility (on behalf of the Trust) to ensure that it works problem-free.
As most of you know I don't write much management software but have been engaged in looking at lean body mass equations in respect of TCI pumps and presented this to SCATA last year. An augmented presentation was made in the form of a poster to SIVA UK last November.
As part of the presentation I included details of a website where the poster itself and some software could be downloaded. As this website cannot be found with search engines I felt that the only persons who would be accessing it would have attended the meeting and thus the software should be in safe hands!
However the clinical software was prefixed with a 'licence' screen that stated that was not a medical device and was to be used only by anaesthetists familiar with TIVA and it their responsibility to set the pump! So far I have not had any comments back ( good or bad ) so I can't tell you how others have found it!
Posted by NHS IT Manager on 21-Nov 2012 19:11
It's clear some people on here have a pretty low opinion of the attitude and expertise in their respective IT departments. I am on here doing a bit of research for an anaesthetist colleague who needs to link up systems with intensive care and is wondering what the market is like.
The starting point of any IT department will be to treat development as a risk, both internally (within IT) and outside of it (among doctors etc). That is not because they do not understand or know how to do it, but is actually more a product of the fact that they do, and carry some of the scars from the experience. We have all lived in hospitals where a system wrote by someone three years ago and left has become mission critical but it's now unsupportable. The tale of the person here who wrote the roster system is a famialiar one. Think very hard and consult before you get into any of this stuff. There is nothing that ingenious or clever about a bit of scripting, but the follow on can be quite disastrous in a number of ways:
- clinical safety. How is the code checked and released and version controlled. Is it checked off by the clinical safety officer for IT. If these are clinical systems then there is a whole new raft of corporate responsibility that could be ignored here and the organization can be put at risk.
- data loss. If we allow people to telnet and screen scrape data they can mine millions of rows of into who knows where. They can they keep it in a non secure way, and use it for purposes that have not been agreed i.e. a straightforward breach of data protection. This is potentially another HMRC in the making. We all accept people can transcribe records but this is a relatively low risk process though having said that any databases that are created should still be notified to the information asset register (mandatory NHS standard).
- the support and mission critical nature of these applications becomes a problem that is well understood and documented in any IT department. We do not know that you are using correct techniques and that data cannot be transposed wrongly. It can be an absolute minefield.
All of that said, it is unforgivable for a hospital not to support its clinicians in the work they do through the use of IT. This should start with a reasonable dialogue where a strategic way forward can be found. If the organization strategy group deems that this is the correct way to go then you are covered but I would not do this under any other circumstances. If your IT departments are not resourced then that is down to the director to garner that support or they are not doing their job. It is up to clinical staff to support them in this to achieve the aim. It will never be the right thing to do to just allow a load of maverick access to data as that will result in fairly predcictable and sometimes serious consequences.
Posted by Paul Cooper on 30-Nov 2012 16:11
The original post that I referred to came from a doctor whose first job was in IT and he as comparing the response to local initiatives within and outside the NHS . It depends on what the Trusts/Boards wants to do with clinicians who have (or think they have) some IT-related knowledge, and have identified a local problem and think they have a solution.
One option is “go away“. Clinicians have the basic tools to do your job -WP, Excel, PACS access - and IT is concerned with the Organisational stuff and there will be a trickle -down benefit. ( NPfIT anyone ? )
Another is “it cant be done “. “but it might be possible like this ….. “ . “ no we cant do that . now go away.“
Alternative responses , given with varying degrees of enthusiasm could be some mixture of :
" how interesting, how can we help you do this.”
“ The ability to do that is resource that the organisation might need in the future. (or others could use now).”
“ I don’t know how it might be done but talk to X who may do.”
“ You might be able to do that but we can we talk about whether its possible with the restrictions ( we want to see the generated data, you have to run the script from here, we’ll generate a limited dataset for you ) that we think would have to be in place".
“Lets see what you have written and we'll get someone to look at it.”
Something useful may come of it. Involving the IT department helps mitigate against the one-man -show becoming too important . But I’ve seen Trusts buy software from one man shows and being part of a bigger setup hasn’t been any use to GP users of Premiere etc . http://www.ehi.co.uk/news/ehi/8082/csc-axes-gp-software-line-up. - so im not convinced by that argument . And the good GP systems in the UK have started from interested GPs doing it themselves.
There is some labour going for free, addressing something that is perceived locally as a problem. OK I accept the stuff i write may not be cutting edge, and at my age I struggle a bit with OOP but I’m willing to learn. Ive heard Les Hatton talking about software vulnerabilties- this talk , i think http://www.leshatton.org/wp-content/uploads/2012/01/FOSS_2010.pdf . the linux kernel , quoted as an example of secure software, has been developed on the whole by interested amateurs - they just need some guidance and prodding in the right direction.
IT departments would also be aware of what’s going on - “Better to have him inside the tent pissing out, than outside pissing in”(LBJ of Hoover) . It would also increase the organisational knowledge and I’m sure there are common themes and needs across clinical specialities. The stuff i was wanting to do on extracting retrospective length of stay would be applicable to many different clinical situations.
The NHS , and i think the public sector are very risk-averse ( its the blame-free culture we work in i.e. Ensuring I’m not to blame) , whilst other organisations may be actively on the lookout for ideas and innovations - or perhaps its a function of the size of the organisation and a disconnect between the people at the coalface and the people with the power to make decisions.
There is quote from the ehi thread “Allowing clinicians access to decent reporting tools and the training needed to use them properly might well create some radical change”.
If nobody is prepared to give it a go , its never going to happen
Posted by Dr Adrian K Midgley on 05-Oct 2013 17:10
The Linux kernel coders I think you\'ll find tend to be professionals. Torvalds was a student, studying operating systems when he wrote the initial parts of it, but now...
The essence of FLOSS is that if something does bother you, there is no way you can be prevented from looking to see why it is wrong, and proposing a fix. Propritary code usually prevents that.