In the article before this I wrote:
“A unifying flaw in all these documents is the lack of any reference implementations to confirm any of this is useful or valuable to even the minutest extent. Standards organisations have, I believe, a responsibility to prove what they propose works and can be successfully implemented before expecting it to be adopted. All this is a long way from passing that test.”
I feel this point is so important that it should be expanded upon.
Over the last decade or so we have seen the apparent emergence of a range of specifications in the Health IT area which have progressed through various standards processes and organisations but which have yet to achieve significant numbers of real-world implementations.
Major international examples include the original and later CEN/ISO EN13606, HL7 V3.0, openEHR, possibly SNOMED CT and I am sure there are others.
It is not clear just why these processes are so slow – but in part it must be related to issues of complexity, resourcing and other less obvious factors such as change management etc.
On the other side of the coin we have groups such as Integrating the Health Enterprise (IHE), the Object Management Group (OMG) and the Internet Engineering Task Force (IETF) whose processes emphasise that real world, fully scaled, implementation is vital to final acceptance of a standardisation proposal.
The practical implication of this stance is that theory does not get too far ahead of practice so that evolutionary, rather than revolutionary, change is achieved. Also, of critical importance in the health sector, is the fact that the intangible issues (user resistance, impracticality etc) and unanticipated consequences are recognised early and managed.
An invaluable model that brings together and demonstrates all these approaches is the Healthcare Services Specification Project (HSSP).
Details can be found at http://hssp.wikispaces.com/
In essence this project is bringing together health and hard technical skills in a planned way to deliver a set of web services which will powerfully enable and facilitate projects such as US National Health Information Infrastructure and Australia’s HealthConnect should it ever get properly off the ground.
A hallmark of the work being undertaken is the approach of developing Draft Standard(s) for Trial Use (DSTU). Only once it has been shown that the standard works as expected and achieves it stated goals does it become a formal standard.
Those interested should visit the following URL for a comprehensive range of explanations and information.
http://hssp.wikispaces.com/HSSP.Navigator
It seems clear to me that the structured engineering approach being adopted here is much more likely to solve the issues around having effective standardised solutions than the non-implementation and non ‘proof of concept’ focused approach being presently adopted by NEHTA.
I wonder how aligned NEHTA’s yet to be released technical detail in areas like identity and terminology services is to the HSSP Project?
The Health Informatics Association of Australia (HISA) is also to be congratulated for working to extend the practical approaches used by IHE into Australia. This step will also help to move Health IT from the theoretical into the operational phase in Australia.
Can I suggest we are only ever going to see significant progress in E-Health space when the discipline of real world implementation and operation is applied to the worryingly large number of current Health IT Standards proposals and specifications which seem to be overly complex and out of practical control.
David.
In his blog titled ‘Implementation Really Matters!’, appearing in http://www.aushealthit.blogspot.com/ on Monday, January 08, 2007, David More has hit the nail on the head with his observations regarding the ‘adoption’ of Standards.
ReplyDeleteHe rightly suggests that Standards Organisations cannot expect the standards they are proposing will be readily adopted until the Standards Organisation can prove that the proposed standards will work and, equally importantly, that they can be implemented successfully before being formally designated as a ‘Standard’.
This raises some very important commercial and strategic considerations for health software vendors and for NEHTA.
Who should ‘carry the risk’ of proving that the intended standards being developed and then recommended can be implemented and will work?
The health industry has proven to be one of the most difficult environments for implementation of information communications technology. As an industry it is extremely information intensive, operating with finite resources and ever-changing needs in an environment of immense political and organisational pressures. At a granular level the multi-faceted sectors of the health industry are each highly politicised, exhibiting marked polarisation between a multitude of health service providers, administrators, politicians and bureaucrats who comprise the industry.
Further, the enormous diversity of the health sector is reflected in the wide range of coding systems which have been developed to-date. In mentioning some of these David has rightly observed that the development of standards for health-ICT has been quite slow for a number of reasons. This, probably, is as it should be.
History has shown that the development of standards, which are intended to be universally adopted, is best achieved when they are allowed to evolve, rather than being dictated as a fait accompli from the top down. This is ever so important in the politically turbulent and financially stressed healthcare environment in which cultural and professional competing vested interests abound; thereby contributing greatly to the complexity of the implementation issues to be addressed.
All too often the Mantra in vogue today is that ‘standards are needed before progress can be made’. Rigid adherence to this Mantra has the potential to damage the health care sector and the health-ICT vendor community. Politicians and bureaucrats do not seem to comprehend this simple fact.
By all means vendor compliance to common standards is a most acceptable long-term goal and should indeed be the overall objective. Notwithstanding this however, it needs to be appreciated that the strategies required to achieve that goal are not straightforward. They are subtle and complex, and because of the very nature of the healthcare environment they must be allowed to evolve over time and not be enforced in the form of an ultimatum for all and sundry to adopt. It should first be proven that the proposed standards work in a controlled live environment and, as such, are acceptable to the vendor community. Only then is it reasonable to consider the implications of subsequently mandating the standards and exploiting market forces to drive their uptake.
Consequently, mandating standards prematurely should be avoided if at all possible. A more pragmatic and lower risk approach is to create a collaborative environment which is conducive to allowing standards to evolve; an environment which is based on consensus and in which the ‘health-ICT’ vendor community is closely involved. This needs to be done in a way which sensibly accommodates the capabilities, experience, resources and limitations of health software vendors who work at the coal-face delivering solutions.
To bring this about it is necessary for policy makers to have a deep understanding of the subtleties of how the health-ICT industry operates, what drives and motivates vendors, and what impedes them. This should underpin the very foundation of a standards-based strategy in order for the health sector, the ICT industry and, if possible NEHTA, to move forward together.
In one way or another many health software vendors break new ground when developing and implementing new applications which are needed to keep pace with the rapid changes in hardware and communications technology. In any industry this carries significant commercial risks; more so in the health sector, due to its inherent complexities and the fact that it lags significantly behind other market sectors in the deployment of advanced Information Communications and Management Technologies.
To offset the risks canny health software vendors adopt a philosophy of ‘progressive implementation’. In this way they can continue to break new ground along the way as they stretch their skills, intellect and resources to get closer to the ‘elusive goal’ on the distant horizon – integration of, and interoperability between, the multitude of elements which lie across the many domains that contribute to the Electronic Health Record (ehr).
It is only through the ‘progressive implementation’ of solutions that continue to break new ground that the developers and implementers can truly understand and fix problems as they arise. In such an intense and complex R&D environment as health, it is folly to set a deadline and say ‘that a standard has been created and is now ready for implementation’.
Of course there are, as always, varying shades of grey.
For example, OpenEHR adheres to the philosophy of ‘evolutionary progressive implementation’ (EPI); as it should – for the OpenEHR it is too difficult and complex a problem to solve any other way.
By comparison, there are various coding systems readily available, such as the MIMS medications database, where it is fairly easy to say with a reasonable level of confidence, that we can use, adopt and even mandate that coding system as a ‘Standard’.
The same however cannot be said of SNOMED CT. This is much more difficult to work with; hence its widespread implementation should lie closer to the philosophy of ‘evolutionary progressive implementation’.
David draws attention to the Healthcare Services Specification Project (HSSP) which can be found at http://hssp.wikispaces.com . He points out that a hallmark of the work being undertaken by HSSP is its approach to developing Draft Standard(s) for Trial Use (DSTU), and that only after ‘it has been shown that the standard works as expected and can achieve its stated goals does it become a formal standard’.
This is one way of ensuring that, as David says, “the theory does not get too far ahead of practice so that evolutionary, rather than revolutionary, change is achieved”.
The prevailing politics and the complexity of the health environment are major contributors to the high commercial risks to which many health software vendors are exposed. This suggests therefore that a way must be found to support those risk takers who can demonstrate they are capable of breaking new ground along the way.
It is high time that the ‘evolutionary progressive implementation approach’ is understood and embraced at the policy making level and implemented from the top down.
© 2007 Dr Ian Colclough
Integrated Marketing & e-Health Strategies
ihsipl@smartchat.net.au
0412 059 392