Translating ideas into (health) software – the safe way

I was invited to give a presentation at the University of British Columbia as part of the Biomedical Engineering (BME) workshop this year. This year’s workshop theme was “translating ideas into practice”. Being a software engineer rather than a biomedical engineer, I chose to present on software engineering concerns, in particular safety and security concerns, related to biomedical software. Here are the slides for my presentation.



SEHC is not like SE[x]

There has been lots of reports about “badly engineered” software in health care. Clearly, the health care domain is complex, but is it really more complex than for example the airline industry (which also mostly runs on software by now – and with a very good track record)?

The Software Engineering (SE) research community has had a series of venues (conferences and workshops) targeted to “Software Engineering in Health Care” (SEHC). One of these venues has been co-located with the Intl. Conference on Software Engineering (ICSE) since 2008. This year, ICSE (and the SEHC workshop) is located in San Francisco. There is a common theme in all presentations on the morning of the first day, which tries to answer the question: Is SE in Health Care really substantially difference from SE in *x* (where x could be any other domain that software has been successful in).

Our lab has a paper at the workshop arguing that SEHC is indeed different from SE[x] and that we need to explicitly focus on knowledge translation in order to increase our impact.

Smart software for better communication in health care

For the last several months, our lab (specifically Caleb and I) has been working with a startup company in town on securing cloud-based software for critical messaging in health care. This has been a very interesting project, as it is a heavily regulated industry and using cloud-based software technologies here is quite new. The company (SmartPager) has recently rolled out their first product installations. Out collaboration is ongoing. Here is a new article describing the service.
Saanich News

How to certify health information system software?

I have just spent one week at Schloss Dagstuhl, a center for informatics research in a rural part of Germany, meeting other researchers interested in software certification.

Schloss Dagstuhl

The seminar brought together researchers from academia and industry, looking at software certification problems in a variety of domains, including nuclear power, aviation, medical devices and transportation.

The seminar was very worthwhile and I learned many new things. I also gave a presentation entitled: “Certification of Medical IS – A paradigm shift: from devices to systems, from functions to data“.

There were many interesting presentations and discussions and I will post about several of them in the next few weeks while I collect my thoughts on what I learned. One presentation that was very well done and that resonated with me in a special way was given by John Rushby of SRI International. The title of his presentation was on “Logic and Epistemology in Assurance Cases“. Traditionally many of the correctness assurance methods in software engineering have concentrated on proving that the software artifacts meet specified requirements. This is commonly called software verification and may be based on logic or other theories.

Notably though, many of the problems we see with health information system software today do not pertain to software not meeting its specified requirements but rather to problems with the specified requirements, for example making unrealistic assumptions about the clinical context and being incomplete.

Assurance cases have recently seen much attention as a method to structure safety or security arguments in software systems. The three main concepts in Assurance Cases are

Claim <– Argument <– Evidence

Assurance cases go beyond software verification (and logic reasoning about the software program and its specification) and also consider validation of the software, explicitly testing our knowledge and assumptions about the real world. In other words they span epistemology (the knowledge we have about the world) and logic.

John Rushby made an interesting point in his presentation stating that in software certification we can to some degree trade complexity between the two domains of epistemology and logic: if we specify strong assumptions about the world (the software’s deployment environment), we can get away with simpler program logic, and vice versa.

Resilient systems are those that make weak assumptions on the environment. Which means that the resulting program logic will have to deal with more complexity. The health care environment is known to be complex and ill-structured. Consequently, we need to shift complexity from epistemology to logic in order to provide resilient systems. This may be one of the key challenges in certification of health information system software.