Friday 26 July 2013

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...

Monday 11 February 2013

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