We have been making steady progress on the openEHR Task Planning specification and visual modelling language (TP-VML) for clinical workflow. One of the differentiators of Task Planning, is that, like YAWL, it is designed as a formalism for developing fully executable process plans. This means that all the semantics of a TP Plan are formally defined and executable in a TP engine. It also means that the accompanying visual language, TP-VML, consists of visual elements formally related to the TP model. This is in contrast with BPMN, which is defined as a diagramming language with some formal elements mixed in, and other formal requirements expressed separately in the specification. Nonetheless, we are carefully studying the semantics of OMG’s BPMN2 / CMMN / DMN specifications to make sure we cover the necessary requirements, and use the same conceptual terminology as far as possible.
The NHS has around one million employees and serves most people in England and Wales. We could easily imagine a slightly larger organisation serving the whole UK, although for historical reasons Scotland and Northern Ireland are separate. Another large public healthcare organisation is the Veteran’s Administration, which manages around 160 veterans hospitals and countless clinics in the US. Brazil has an organisation called SUS – the universal healthcare system – which provides public sector care for 160m people not on private care. Smaller countries have similar, generally large, organisations, at least by the standards of each country. Large private organisations such as Kaiser Permanente and Partners Healthcare are in the same position, with the same needs.
There has been an endless search by such organisations over the 25 years I have been involved in e-health for the silver bullet to solve their IT challenge.
The Unified Modelling Language aka UML has been around for 22 years, as you can see from the OMG UML page. We use it extensively to publish the openEHR specifications, in a similar way to many other organisations. Developers often use it for whiteboard brain-storming. But hardly anyone uses it for its original purpose: formal modelling of software leading to code, ideally with round-tripping. And this is despite the availability of excellent UML tools. Architects these days tend to limit their use of UML to package diagrams and a few illustrative class diagrams, while developers tend to go straight to code or use tools that pretty-print extracted textual forms of software such as swagger and apiary.
In openEHR, we publish specifications, so graphical representation of formal models is important. UML is still the only widely used graphical format, so we use it. However, to get around all its problems, I had to develop an alternative for static models, called Basic Meta-Model (BMM), to enable correct formal model representation for our tooling. This was not done lightly – we had to do it because UML does not represent the developer view of models correctly, and that’s the one we want. Worse, its serial form, XMI, is unreliable and unusable by humans or tools other then the creating UML tool. We also developed a UML extractor for the UML tool we use, to fix some of the problems it has, so we know a thing or two about UML under the covers. I have no doubt other organisations have resorted to similar fixes.
A few years ago I asked 8 senior software engineers at a meeting who was using a UML tool in their development work. A total of zero hands went up. And yet humans love pictures, so we should be using some sort of graphical modelling language. What went wrong for UML?
Below is my list of reasons why I think NPfIT failed. NPfIT was the NHS National Programme for IT in health, starting in 2002, with Richard Grainger appointed as NHS IT director. A timeline is published here. NPfIT is generally conceded to have spent £10.7bn by the government in 2013, when it was definitively shutdown. Claims have been made that slightly more than this was delivered in value. Realistic analyses such as the one linked to from the image at the top of this post show that the realised benefits are miniscule. Right now, the benefits for ‘Choose and Book’ can probably also be written off, as it is no longer generally used. I would guess the only benefits that those in the industry would agree were actually realised are N3, the secure NHS network and possibly NHS mail. The Spine supplies some benefits, but is so badly designed and over-complicated that it will undoubtedly be completely replaced in the next 5 years.
Continue reading →
Every so often I get bored of what I am doing and start trying to draw one of those ‘services roadmap’ kind of diagrams for e-Health. These pretty pictures appear in slide presentations, standards, whitepapers etc, but are not often used as a tool to help map out the road ahead, mainly because (I think) they mix too many conceptual levels together. We do however need some sort of vision of the future for defining services. I like my latest version enough that I thought it would be worth putting up publicly to get reactions and input. Please comment and/or add content to the wiki page.
Some readers may have read my previous post FHIR compared to openEHR. If not, I recommend you do, it is available in Spanish, Japanese and Chinese as well as English. Here I aim to clarify some of the concrete differences which are increasingly common sources of confusion, particularly with the FHIR hype wave preventing coherent thinking in many places. It seems that the human psychological pre-disposition for uncritical silver bullet thinking is as strong as ever, but I still hope (perhaps vainly) that in e-health we can soon get back to real science and engineering.
For decades, most of us working in health informatics and e-health have lived on the assumption that ‘interoperability’ is one of the main things we are trying to achieve, and that it is the most important because the lack of it blocks progress on nearly every other priority. In the last decade, the gold version of interoperability has become ‘semantic interoperability’, a fabled Nirvana in which today’s sewers of recalcitrant proprietary data are magically transformed into a sea of pure Evian whose meaningful molecules will be ‘understood’ by drooling next generation apps that will instantly discover what is wrong with each of us, and tell us how to fix it.
The openEHR Basic Meta-Model (BMM) that has been in use in some form for nearly 10 years now was recently upgraded to version 3.0.0 (from 2.x), with the persistence format (now called P_BMM) being backwards-compatibly upgraded to version 2.3. The purpose of the upgrade was to improve the separation of class and type, and to greatly strengthen the semantics of generic types and classes.