Sharing a few of my reflections on some concepts which has been shaped by the health informatics program so far regarding challenges of developing software systems for clinical or medical settings. After a host of course ‘projects’ , a few clichés seem to be becoming part of my daily vocabulary ,stakeholder analysis, context, user,clinical setting,iterative, care flow,scenarios,etc. This is actually forms the basis of the health informatics field which bridges the gap between the two professionals (clinical and software developers) Each context is unique,during a class visit to an emergency department of children’s hospital in Stockholm, an issue mentioned by a physician was the IT systems are not customized to the specific needs of the children’s emergency ward which were starkly different from the context of the other hospital departments. Which leads to one question how do you avoid falling into the unending statistic of failed health informatics projects.
Frustrations of a system designer
Know your end user It’s sounds quite basic, but knowing the user of your software products is the most critical aspects of the development process. It might seem straight forward that in case there is a challenge at the hospital which can be resolved through a technological tool, why not just develop a code and implement it or even buy an already developed system which might be cost effective and less time efficient unfortunately, but in reality clinical settings are far more complex and any solution would not necessary be accepted. Rejections of information system is far more frequent in clinical settings than any other fields.
One of the course seminars i had was to analyse a ‘decision support system’ which had been implemented at a university hospital in Iran but medical staff were threatening to resign because the system designed was making the life at the hospital ‘unbearable’.. ….in the end a system meant to make care more efficient at a hospital turned into the main problem at the hospital. Most failed projects lack input from the users of the system and therefore design might not fit into the ‘workflows’ at the hospital. First approach is to engage your intended users who could be nurses,doctors etc at the and find out what challenges they have , do they need the solution actually or someone in the hospital management assumes the need the system. The user is always not sure of how to communicate needs to a software, that means as a system designer should constantly evolve as your understanding of the needs gets more clearer until the final output is appreciated by the end-user.