Why most health IT procurement fails and how to fix it


A strange thing happens in health IT solution procurement, and by extension government initiatives that seek to influence it. See if you can disagree with the following characterisation of health provider organisations as solution purchasers.

Think You’re Getting What You Want?

CIOs and CMOs have known for years if not decades that:

  • the data used inside their institution are their most important asset – either as a productive resource, or at least as an object of risk management. Most today would understand it as both.
  • the data used inside their institution is not all produced inside their institution – lab data often comes from external lab companies; they obtain or would like to obtain GP data such as medications lists, problem lists and so on;
  • their main vendor solution never supports the data richness actually required by clinicians – it is well known for example that most hospitals contain dozens if not hundreds of hidden specialist’s databases, often referred to as the ‘Access Database problem';
  • if they want to switch to a new vendor, the changeover costs related to the data alone are massive and the risks so great that this consideration alone paralyses them for years with the current ineffective solution;
  • no one vendor can produce all the functionality they require - even the biggest vendor has a ‘roadmap’ containing numerous features the provider wants today; no large procurement doesn’t involve significant and horribly expensive ‘customisation';
  • they cannot possibly afford to buy all the functionality they require in one go – if they wrote down the full wish list and then published a tender for it with an open budget, the resulting price tag would undoubtedly be beyond their means;
  • procurement of multiple ‘best-of-breed’ solutions for e.g. inpatient, ER, ambulatory etc, come with huge ongoing cost for data and workflow integration;
  • they cannot possibly afford logistically to deploy all the functionality they want in one go – the human costs and challenges of change management not to mention solution integration make this impossible;
  • asking for even the smallest change to the data schema or core functionality costs inordinate amounts of money and usually a long wait as well;
  • it would be nice if their IT department could have access to ‘their’ data, but of course they can’t, not without the vendor’s say so and price tag.

Read the rest of this entry »

What is an ‘open platform’?


The word ‘platform’ is starting to reach the same status as the word ‘internet’ – part of the bedrock, but many have no idea what it really is. In e-health particularly, ‘platform’ is often mixed up with ‘open source’, ‘APIs’ and ‘standards’ in ways that don’t always make sense. Regardless, public policy in the NHS, US ONC and in other countries is being formulated without necessarily a clear common understanding. I’m going to try to address some of the ambiguities here.

The key thing to understand about a platform is that it represents progress away from being locked-in to a monolith of fixed commitments, toward an open ecosystem. This is true both technologically and economically. Any platform operates in two environments: development, and deployment, and these need to be understood distinctly to understand how to use the platform concept properly.

platform_pic Read the rest of this entry »

Why clinical models are essential to big data


I attended HIMSS 2014 in the mammoth convention centre in Orlando 10 days ago, and went to a session on ‘Clinical Decision Support – is progress being made?’. Despite this being the dead Thursday of HIMSS, around 50 people showed up.

The presentation was done by Cory Tate (sen research dir. KLAS) and Adam Cherrington (research dir. KLAS). KLAS is the organisation that performs research into the shape of the health IT industry and publishes the results. So when they say something, it usually means that it’s actually statistically true across the US at least, rather than just a supposition of one person.

What they said was, in a nutshell was: progress is being made, there are Order set products (Elsevier, ProVation etc) and some surveillance products, e.g. infection control rule sets and so on. These have some nice features. Etc Etc. A discussion developed with the audience in which it became clear that both the presenters and others present identified the main blocker as the inability to connect the order sets and other CDS or analytics modules to the EMR products in use. Read the rest of this entry »

Archetype unification proposal – node identifiers




happy new year and best wishes for 2014. I hope your new year’s day is a bright one (unless you live in the UK, in which case it’s a lost cause here today ;-)


I have been working in the last few months to produce a final version of ADL/AOM 1.5, based on:

  • existing requirements,
  • emerging requirements – Intermountain, CIMI,
  • Harold Solbrig’s proposals for terms-as-URIs,
  • Dave Carlson’s MDHT / AML work at OMG led by Robert lario,
  • general feedback on the openehr-technical list, particularly from David Moner’s group at UPV, where they have implemented different rules
  • implementer feedback

So here’s the new idea. To date, We have been trying to keep ADL/AOM 1.5 backwardly compatible at the syntax level for ADL 1.4. However, I think this keeps too many old problems unsolved. I propose a new approach:

  • make the central ADL/AOM 1.5 specifications as clean as possible
  • provide a series of updates to ADL 1.4, coming from the 1.5 specs, that are carefully designed to be applied to 1.4 tools, to bring them up to date
    • e.g. things like how to post-fit the new identifiers, tuple support, annotations, to DAL 1.4 archetype tools
  • provide rules and tooling to deal with differences between archetype paths, upon which querying is based
  • provide a 1.4 => 1.5 upgrade tool to completely convert existing ADL 1.4 archetypes to the new format

The latest changes I propose (and have in fact implemented) are primarily about dealing properly with the long-running problem(s) of archetype node ids, i.e.:

  • the quirky 4-character top-level codes like at0001, at0003 etc, also lower level codes like at0001.0.1, at0.0.2
  • the root node code at0000, which really should be ‘1’ not ‘0’
  • the question of whether all nodes should have codes or not (in openEHR we have not done this; the 13606ers have)
  • the lack of separation between node id codes and value codes
  • sibling alternate C_OBJECTs under a single-valued C_ATTRIBUTE were not properly distinguished by their paths

The proposal is documented here on the wiki.

All comments and criticism welcome. If you think the proposal is broken in some way, or could be done better, don’t be afraid to say so. Please comment on the openehr-technical list, or for substantive comments, the wiki page above.

Let’s try and get to a final proposal that works for all ADL/AOM users – not just openEHR. I think that would be a real achievement.

CIMI – time for clinician collaboration?


How can CIMI ‘standard’ clinical models be created?

In CIMI, we mostly seem to assume two pathways:

  • de novo authoring, e.g. with an archetype tool that consumes the CIMI RM
  • accession and conversion of external models, e.g. CEMs, openEHR, 13606, R4C, VA, etc

Neither of these is as simple as it sounds, and they are likely to have different outcomes. Below I have tried to tease out some issues in order to think about CIMI’s approach from here on in. Read the rest of this entry »

The real reason most software fails


To my mind there is a problem in academia to do with where disciplines like ‘computer science’ (CS) and applications of computing sit.  Pure computer science is the study of computational theory and applications. It develops things like data structures, algorithms, models of parallel computing and much else relating to computation as an object of study. Things like bio-informatics, financial computing and avionics, just to name a few, aren’t usually thought of as proper ‘science’, but as some sort of ‘applied’ form of pure CS. Somewhere in the middle is ‘software engineering’.


However, in my view, the offspring of CS were never properly conceived as disciplines, but rather artisanal pursuits.  In this post I have a look at a few domains and try to show how disciplines derived from computing should be understood as both proper science and engineering. In doing so, I came up with the schema above, as a way of establishing the key concepts. There’s nothing on this diagram that can’t be found in a dozen books on philosophy of science. But … I like diagrams.

Read the rest of this entry »

ADL/AOM 1.5 (major) progress update


I have been working for some years on the side on the long overdue Archetype Definition Language (ADL) 1.5 and Archetype Object Model (AOM) 1.5 specifications (dev page). I have made some major progress just recently, of the ‘nice’ kind, where the specification simplifies, becomes more generic, and the formalism becomes more powerful (you know it’s the right change when you think, ‘ah if only I had done it this way years ago’. Such is the nature of R&D).


Read the rest of this entry »


Get every new post delivered to your Inbox.

Join 245 other followers