Information Architecture, Archigram, and the Olympics

The Olympics venues in London have been built with reuse in mind, building on the ideas of the Archigram architects, the structures are modular, can be reconfigured, repurposed, or relocated with relative ease (relative being an important word here).  There is a delightful BBC piece describing this [1].
Large Health Information System architectures need a similar flexibility and usability. Olympic buildings take upto seven years to plan and build, and have to find a new purpose after only 4 weeks of use.  For healthcare information systems the planning and building should be shorter than that, but there is not even an initial four weeks that can be relied on where they will be needed and used in the way that was anticipated when planning and building began.
Like the very successful planners for the London Olympics, Healthcare Informaticians could do worse than reread some of the Archigram literature.
[1] http://www.bbc.co.uk/news/entertainment-arts-18811200
[2] http://en.wikipedia.org/wiki/Archigram

Steps to open healthcare data - lets get open specifciations and examples first

Open access to interface specifications and example data for all healthcare IT systems funded by the NHS would enable innovation and quality improvement in the health service.  It is a cheap and effective policy option, aligned with current politics. 

It is understandable that healthcare data such as prescriptions and extracts of medical records are not routinely published for anyone to see.  We all know that this information is private, and belongs to the patient, with the clinicians that recorded it, and the organisations that they work for having some rights and responsibilities to use, take care of, and make available the data  the data when appropriate.

It is understandable that "cleaning" real data so that the patients cannot be identified is hard, and that to do so reliably enough to be comfortable publishing the clean data openly on the internet would be expensive.

What is less understandable is that the specifications for the formats that data may be made available, and invented examples for fictional patients are not available.   The specifications exist but are often only shared once a contract between suppliers and a provider organisation is signed.  They may be based on standards from one of the many SDOs (for which there are rarely examples available), but that is not well published.

Access to specifications and example data would allow new suppliers to show what they could do, and would allow standards organisations (including those setting standards within the NHS) to identify and promote common approaches where there is evident need.  It will allow new entrants to show innovative solutions without requiring "rip-and-replace" for existing systems that deliver value.    
It is reasonable that access to healthcare data should be controlled on behalf of the patient -- but open access to the specifications and example data will help to create  a vibrant marketplace in healthcare IT systems - which is in the interests of patients, clinicians, the NHS and that UK economy.


The Following advice to DHID from an Ehealth Insider  editorial  in May 2012 puts it very well: 

"First, it [DHID] should re-procure the spine as a platform, or series of core re-usable national services, these should be as easy to access and connect to with clear certification criteria. Currently it can take a ludicrous 18 months to go through a Byzantine assurance process. Apple publishes its criteria and manages a rigorous approvals process in less than a month.

The second step would be to insist that all vendors who want to be funded by the NHS meet very basic minimum data standards. Yes, the NHS Commissioning Board is to look at standards, but giving a clear recommendation would avoid re-inventing the wheel. The third step would be to insist that all vendors publish clear, usable Application Programming Interfaces. No API, no funds."

The next step would be to establish open statements saying what has to be done to connect to these interfaces - including the certification criteria and costs.  But getting from where we are to a vibrant market will not be done in one step, so get the APIs published first so that people can create viable and valuable products, then simplify the environment for buying and selling them.