"Benefits Realisation" or "Impact Analysis"

Far too many projects have no follow-up at all.  The job is done and everyone moves on.  "Benefits Realisation" is an improvement - but there is a risk that in focusing on benefits the overall impact of the project is missed - and that lessons learned are missed.  Any project that is self-aware enough to have committed effort to "Benefits Realisation" should be self-aware enough to realise that "Impact Analysis" would be more useful and clear sighted.

SNOMED is good for health records, but why not also for Policy, Regulaton, and Evidence

The NHS has rightly said that having a standard terminology will make a real difference to the ability to analyse electronic health records and really get value out of their contents.
What is weird is that this enthusiasm for SNOMED coding of Electronic Health Records does not extend to NHS Health Policy Documents, Regulations, or Guideline documents.
Why are these not SNOMED coded -- this would:

• make it easier to compare different policy documents
• remove ambiguity form the documents (what cancer is being talked about, what is the definition of Diabetes, etc)
• Make it easier to link indicators to the policy - how will we know whether the policy has been enacted, and how will we know if it has worked.  What are the intended benefits, and what are the metrics that will be used as evidence for those benefits?
• Make it easier for groups within and beyond the NHS to show that what they are doing (or propose to do) delivers of the Policy.
• Make it easier for commissioners to purchase in line with policy (or to knowingly deviate)

This seems to be an area where leading by example would work wonders - and would deliver immediate benefits.  
The rich semantics of SNOMED CT is ideally suited to such documents -- if SNOMED CT will add value to individual health records, how much more value will it add to health service organisations under constant organisational change that much provide care plans for their populations.

Healthcare is a Complex Adaptive System with different perspectives and ways of seeing

Healthcare can be seen as a complex adaptive system, as can the information that underpins, permeates and radiates from it.

According to the TED talk below,  complexity implies that the system cannot be understood from one perspective alone, or using a single language. 
Adaptive means that the behaviour of the system cannot be fully anticipated, but that its behaviour  is determined by its previous state, and the changing environment that it is in.  Of course for healthcare the environment is complex and adaptive too.



Healthcare information provision can be seen, categorised and described from a vast number perspectives.

The following list can be read in two ways.  One is as a set of perspectives.  How the health service looks to me as a patient and how it looks to me as a programmer are different.  How it impinges on the life of a tumour or what the health service looks like from the perspective of a tumour is different again.

The other way of reading the list is as a set of categories - what is being looked for from a particular perspective.   As a patient I may be totally unaware of the costs and money flows associated with my treatment - or I may be very sensitive to it.   From each perspective there are many different ways of seeing.

The list is not intended to be exhaustive - in two significant ways - the set of categories / perspectives is not complete, and nor is is the only way of categorising the space.  Indeed the selection/discovery of categories/perspectives is part of the process of engaging with subject matter, and is an area where good choices can help to make that engagement more fruitful.

• The actual people involved (who does what when and why)
• The job descriptions / roles of the people involved (patient, doctor, parent, friend, guardian, nurse, programmer, venture capitalist, politician, voter, neighbour, manager, ...)
• The products (software, hardware, intellectual property, etc)
• The projects and programs involved
• The money involved (who pays how much for what, the result of a particular payment, etc)
• The activities (treatments, tasks, events, actions, encounters, processes)
• The subjects of care (genes, tumours, organs, patients, families, groups, populations, citizens, etc)
• The organisations involved (providers, suppliers, payers, interest groups etc)
• Purposes and Outcomes (what is the point - comfort, autonomy, health, care, QALY,  social cohesion, individual care, public health,...)
• Metrics (what can be measured?  what can be compared?  what questions can be answered?)
• Information Standards and Specifications, and the organisations that maintain them.

In a complex adaptive systems we should be cautious of single perspectives overshadowing all others, and becoming a dominant ideology. 

• "Evidence-based medicine" is a way of seeing healthcare that has a lot of value, but it is not the only way of seeing.  We do not insist on evidence-based marriage, or evidence-based cooking.  In both cases there is relevant research but for most of us that is not the best language to use.  The research indirectly informs us, but we do not see it as the basis of how we love or feed each other.
• Patient-centric.  The patient's is a valuable perspective to consider.  However if I need an operation on my knee, I want to know that the place I am going to will do a good job on my knee.  I want them to really care about doing great operations, and that the staff want to be working there.  As a potential patient, I care less about it being patient focused, and more about it doing a great job.

Evidence-based medicine is great. Patient-centered care is great.  What I am suggesting is that healthcare is bigger and more diffuse than either of them alone.  

As we engage with healthcare information we seeing in a particular way from a particular perspective and can strive to achieve particular outcomes.  This involves working with others who have different perspectives and ways of seeing.  Healthcare Informatics is about helping to build and sustain those bridges, as well as making it easier to deliver outcomes from a particular perspective and way of seeing. 

Information standards and specifications fit into this complex adaptive system as  tools that can be used, and as points around which collaborative momentum can be built.   They emerge as part of the complex adaptive system where and when there are the resources and engagement necessary for their creation and maintenance.  Different perspectives and ways of seeing will engender different metrics for evaluating them, and different outcomes to expect from their use.

How this diversity of perspectives and ways of seeing impacts specific information standards or healthcare outcomes  are topics for another day.

Written in reaction to:

  TEDxRotterdam - Igor Nikolic - Complex adaptive systems

trafficlight CDA to manage scope and support document evolution

Managing scope is a key part of delivering a successful project - and this is particularly true when using information standards in healthcare projects.  The challenge is that the standards are designed to meet a wide range of requirements, and the project's success will be measured against a specific set of local requirements.

Green CDA was envisaged as a way to take the full CDA specification, and reduce the complexity for implementers by exposing just the information items that matter to the project.  These information items could then either be exposed to the developer as an API, with full CDA documents being generated and shared "over the wire", or could be serialised as an XML document that just contains the Green CDA elements.

One of the problems with Green CDA is that it does not do enough - it tells you the information items that matter to the project - but it does not tell you what to do with the rest of the information items.

TrafficLight CDA is a way to specify more.

• Green for the information items that matter in the project, and that receivers are expected to process or knowingly deal with.  The sender can reasonably expect the receiver to have dealt with this data.
• White for information items that may be ignored or processed by the receiver.  The Sender cannot assume that the receiver will process these, but nor can the sender or receiver expect that the receiving user will see this information.
• Yellow for information that the receiving system must log as out of scope, but which does not need to be brought to the attention of a user before the document is processed or viewed.  The logs must be available for review by the receiving organisation.
• Amber for information that is out of scope, and the inclusion of which should generate a warning which has to be acknowledged by the receiver before the document is processed.  
• Red for information items that must result in the document being rejected, and the sender being informed that the document has not been accepted.

The current CDA specification implies that anything that is not Green or explicitly excluded is White and may be safely ignored.  This proposal builds on existing conformance rules that are described in the HL7 core principles and  in the conformance documentation - an introduces a delightful visual metaphor to help with understanding the different conformance requirements.
Adoption of TrafficLight specifications for how CDA documents are handled will make it easier for suppliers and those testing systems to know what they have to do - and more importantly will ensure that users can clearly understand what will happen when they share a document.

This can be done is a very light-weight way -- saying that anything that is not Green is White (open templates) or saying that anything that is not Green is Red (closed templates).    In practice using the TrafficLights will help projects retain flexibility in an affordable way - enabling explicit distributed evolution of the document set that is supported within a configuration management framework - but that is for another post...

Self monitoring vs telehealth

 Excellent comment my Mary Hawkins on the EHI article.  There is a lack of evidence for most specific implementations of telehealth.  This could be because, as Mary suggests, self-monitoring already happens without devices being directly linked to the EHR or health services - but with the patient or local carer doing the monitoring and calling the health services when needed.

It may be that the technology is moving on faster than the evidence base can keep up with, so there is little incentive to invest in long-term research projects to evaluate technology and methods that will be out of date when the research results are out.

It could also be that we will not call it "telehealth" when it works.  Thousands of people are using online weight monitoring and calorie counting tools - these could be linked up to provide extracts to the NHS.  Gym equipment and pedometers provide electronic logs of the exercise that people are doing in a way that could be linked to EHR data - either for routine care, or for better targeting of care. 

Maybe the way to get "telehealth" working is not to look at buying and installing new kit -- but looking at the way that existing kit and information is being used, and seeing how services can be adapted to make better use of the existing infromation landscape.  Helping patient to become "expert patients" and use the data and data processing tools that they have, and helping healthcare delivery services to be more proactive in finding and reaching out to those who will benefit from their attention, rather than waiting for patients to make appointments.    This will accelerate improvements in health outcomes, and will result in a better definition of what useful telecare services might look like.

Monitoring devices and the "Tele" bit: http://www.ehi.co.uk/news/EHI/8375/pathfinders-losing-their-way

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.

convergence of formal standards and search engine optimization

Formal healthcare information standards organisations are always working to engage effectively with the communities that they serve, and also to discover where their standards are being used, and what issues are being encountered.  Standards that work and meet a need are successful, but it is often hard to discover how to improve specifications that have not got traction. 

Standards Organisations excel at establishing clear definitions, and providing frameworks and specifications against which conformance can be asserted, and which can be included by reference in contracts.  Crucially they also provide a forum where those specifications can be discussed and issues resolved at arms length from the contracts that depend upon them.

Search Engine Optimization (SEO) is the rapidly growing profession of presenting data on the web in a way that results in appropriate placement in search results.  Here there is no problem with engagement - those following "best practice" get to the top for the search terms that they care about.  The process is policed by a combination of published rules and private algorithms, both controlled by commercial search engine organisations, who are in turn motivated (controlled) by commercial drivers to attract and retain users, advertisers, and other revenue streams.

While SEO practitioners do not care about the precise definition of the terms that they are optimising for, they do care about which terms effectively express the relevance of their sites, and which terms the potential users and customers of that site will use.  There is a virtuous circle here of users looking for information that meets their needs, site maintainers making their sites easier to find, policed by the search engine companies and their algorithms who are looking to maximise successful search experiences for their customers.  The search engine companies provide tools to site maintainers to help them improve the relevant ranking of sites - and the site maintainers have business reasons to use these.  There is not the same strong feedback loop in the development of formal standards.

Similar searches are done within organisations using business intelligence engines to extract management and marketing information from the raw data that the organisation holds or has access to.  Here some of the data may have been created for human readers, but much will also have been created conforming to specifications or standards that enable machine processing, albeit not necessarily for the purposes of business intelligence.  This is often transactional data, and changing it requires changes to the workflow processes and the information systems that support them - which is very different to changing the way that websites are structured and populated.  However those of us interested in translational research and innovation in healthcare need to learn from the drivers that are effecting large-scale change in the way that the web looks and functions.

Childish Simplicity

The recent post by Keith Boone suggesting that healthcare information topics should be taught in schools is part of a wider recognition that healthcare IT is far too insular.  We certainly do need to make healthcare information topics available in schools - partly because its useful stuff to understand, and partly because its interesting and challenging.
Another way of doing this that I have been looking at is joining healthcare IT project outreach activities with providing material for existing school courses.  The idea would be to provide "background" material for exercises and coursework that could be used in existing lessons.  What is clear is that the benefits would flow in both directions - more interesting materials for schools, and better public engagement by the healthcare services.  The background material may not be used directly in the classroom, but could be taken home ans shared with the family - this is a well established way to get effective public information out.

Cleaning up the HIT environment: Reduce, Reuse, Recycle

"Reduce, Reuse, Recycle" is a mantra that works for the environment, but how does it play out in the healthcare IT ecosystem? 

Reduce: Stopping the routine collection of needless information has resulted in significant savings in cost, time and frustration.  This requires active review of information flows and uses, but is a very low cost and low risk way to improve things.  It also creates the goodwill and confidence that will sustain other change initiatives.   Focusing on specific Collaborations where information needs to be shared for a particular purpose is also a way to avoid the collection of precise data when something simpler is good enough.
Reuse: Finding ways to reuse existing information systems and infrastructure rather than assuming that it must be replaced makes sense.  This applies to software and networks, but it also applies to paper forms and processes.  Using architectural frameworks and standards-based interfaces to support incremental change, and a collaboration-based strategy that focuses on the human and systems issues that support specific collaborations allows for strategic improvements to be introduced with minimal change.  
Change management is hard - leveraging the reuse of infrastructure, processes, skills and ideas is a good way to increase the benefit:change ratio - and so the return on expensive and risky change management effort.
Recycle:  Healthcare data is full of "toxic" confidential information that prevents it being made available for purposes other that those for which it was collected.  However we get value out of scrap metal and glass by dramatically denaturing it and throwing away much of the structure that was painstakingly designed in for the initial use.  We should be getting value out of de-identified healthcare data.   Some recycling is better than none - so even if much of the semantic value has to be lost to avoid perceived or actual risks to confidentiality - in the interests of health we should be recycling more.  The next step will be to make our healthcare data more recyclable in the first place, just as has been done with physical packaging.  How to promote recyclable healthcare information is a topic for another day.

There is nothing new or radical in this post - other than reusing an idea from one area where widescale and dramatic change is needed (the environment), and applying it to another (health). 

informatics for efficiency

If the NHS is to save 4% a year for four years that means that there is a great deal to be done to improve the clarity of what is being asked for and what is being done - all of which will require better ways to manage and use information.
http://bbc.in/gMawYC

are precise semantics the top priority?

I have been getting increasingly uncomfortable with the assumption in interoperability standards work that we are working to acheive semantic interoperability.    Information systems need to be useful, and shared information needs to be well enough understood to do the job - written notes are not very precise, or universally understood/interpreted in the same way --  they are created when there is something useful to do with them.
I suggest that as we look at interoperability standards, we should not always be looking for global consistency across all of healthcare around the world, but looking for where there is a role for lingua-francas that will share enough information to be useful, with enough consistency and clarity to be useful.
This means far more focus on what the intended use is - and moving away from assuming that because it is information, it must be expressed in a way that can be understood by every machine and every clinician.
Greater clarity as to what the purpose of sharing the data is, will help to clarify both the business case for making it happen, and the rules and agreements around the appropriate uses of the information that is shared.

Standards promote commodity products

A recent report [1], [2]  by The Network for the Post Bureaucratic Age calls on the government to use commodity products and services wherever possible.  This will help to control costs, quality and responsiveness by encouraging platforms upon which commodity services can be sold.  The "Innovate, Leverage, Commoditise" model recommended proposes something beyond the NHS "Do once and share", as it recommends that small scale investments be encouraged, and successful reuse be tracked and promoted, within an overall open ecosystem.  This is consistent with a "fail early, fail often" approach encouraging small commodity innovations.  Those that do succeed can then be rolled out across the standard platforms.
This vision assumes that there is a network of standards providing the fabric for the platforms - so that successful products really can be rolled out.  That in turn is something that HL7UK, HL7 international  and the other standards bodies can contribute to.
The document assumes that open source is the key to success here.  That basis for that is not clear to me.  There is a strong case for commodity - but there also needs to be a business model that sustains the development and maintenance of the commodities.  Those business models should not be restricted to open source.

[1] http://bit.ly/exzhcN
[2] http://bit.ly/dJBxCm

dementia

Did you know that dementia is one of the three main causes of disability in later life, ahead of cancer, cardiovascular disease and stroke. One in three people over 65 will die with dementia.
http://alzheimers.org.uk/tv

what micro-credit has to teach Healthcare IT standards developers

The account by Muhammad Yunus of how he started the Grameen Bank has many lessons for those of us trying to improve health through the development and promotion of interoperability standards. 
Yunus saw a local problem - the need for small amounts of credit to get small businesses off the ground.  He devised a local solution that was repeatable, adaptable and scalable. 
Scalability is important because the local problem/opportunity that he saw is repeated everywhere, and the rapid growth of Grameen and similar micro-credit schemes has shown that the solution he developed could be replicated.
To better support the scalable use of IT in healthcare we need an information sharing framework that allows local projects and trust relationships to be quickly and easily established, with the information requirements easy to define and implement, yet consistent with broader national information needs, and using commodity information management tools as much as possible. 
The requirement to be able to develop implementation guides that work for local projects quickly and cheaply is vital to the successful uptake of interoperability standards - taking this as a core requirement will change the sort of standards that we develop, and help us to deliver something truely useful.

Specification Development Organisations need Strategic Methodology

Looking through the ITIL Service Strategy document it is clear that SDOs such as HL7 would greatly benefit from using the ITIL methodology to define and maintain a set of services that they deliver to their membership and other customers and stakeholders.  As a membership organisation that creates standards, HL7 has been delivering valuable services for years - but these have never been well defined, and their value has therefore not been demonstrated or managed.
Taking on such a methodology would also open up the interoperability space to those who work on delivering other services to support healthcare - who happen to be major stakeholders who will benefit from effective healthcare interoperability standards.
This is a critical part of broader stakeholder engagement by the Standards Development Community

Microsoft article on DSLs

An interesting article from the Microsoft site posted in Jan 2010 on the use of DSLs in C# -- a resource worth looking at when thinking about how this approach can be used to simplify the implementation of HL7.  Patterns in Practice - Internal Domain Specific Languages http://bit.ly/bYyhI5

Specifications available online

The availability of the HITSP specifications at http://bit.ly/9VOxGC is a great example of how  making the specifications freely available simplifies evaluation and adoption.  We need to establish a business model for SDOs that makes this an affordable norm for standards publication.

UK Deparatment of Health strategy on Global Health

The UK DoH strategy on Global Health is interesting in the priorities that it does identify, and those that are not mentioned.  There is no direct reference to the need for international healthcare information standards, but it does identify a set of strategic objectives that could usefully be compared with those of BSI-IST35, HL7UK and other UK health informatics groups that face outwards.  http://bit.ly/bV65eB

What does HL7 do?

When thinking about what HL7 does, what it is paid for, who gets the value, and who provides the resources, I have come up with the following headings for the things that HL7 does. 
The last two are delivered through meetings that are funded by registration and sponsorship, and through electronic services to members (telcons, website, mailing lists, newsletters etc).
The first three are far more interesting - while HL7 does create a lot of value in these areas, there is no real link between who pays for that value to be created, and who benefits from it.  Only recently has work stared to look at quantifying what the value is, who realises it, and how HL7 can capture a portion of that value for reinvestment.  Something for a future post...

The headings are:

•Publish and distribute standards

•Facilitate standards development

•Maintain a Specification Development Methodology

•Networking for healthcare interoperability and informatics business

•One stop shop for healthcare interoperability issues