In the past few weeks, the HIT Standards Committee has gathered a significant amount of written and in person testimony from standards stakeholders. We've run the FACA blog and multiple personal blogs.
On Thursday November 19, we'll present a complete distillation of everything we've learned but there are several recurring themes can could be called Guiding Principles. Just as HITSP was guided by Harmonization Readiness principles to choose standards that were good enough, the HIT Standards Committee has a been told to think about the following whenever it recommends standards:
• Keep it simple; think big, but start small; recommend standards as minimal as possible to support the business goal and then build as you go
• Don’t let “perfect” be the enemy of “good enough”; go for the 80% that everyone can agree on; get everyone to send the basics (medications, problem list, allergies, labs) before focusing on the more obscure
• Keep the implementation cost as low as possible; eliminate any royalties or other expenses associated with the use of standards
• Design for the little guy so that all participants can adopt the standard and not just the best resourced
• Do not try to create a one size fits all standard, it will be too heavy for the simple use cases
• Separate content standards from transmission standards; i.e., if CCD is the html, what is the https?
• Create publicly available controlled vocabularies & code sets that are easily accessible / downloadable
• Leverage the web for transport whenever possible to decrease complexity & the implementers’ learning curve (“health internet”)
• Position quality measures so that they will encourage adoption of standards
• Create Implementation Guides that are human readable, have working examples, and include testing tools
We'll refine this during our meeting on Thursday and the end result should be a polished list of guidance for all our future work.
Jon,
ReplyDeleteThese are great. Refreshing to see such cogent principles, particularly the use of the Web and design for the little guy. This is going to likely set things in motion that we will live with for a long time, so it's imperative to keep it simple, use the Web, and leave the door open to innovation. Seems the committee recognizes the task before them is bigger than any of the individual players. Encouraging.
John,
ReplyDeleteI agree with your principles "Leverage the web for transport whenever possible to decrease complexity & the implementers’ learning curve (“health internet”)." and "separate content from transmission standards." Bravo! HITSP has done that! I'm pleased that HITSP selections leveraged pre-existing web standards, such as WSDL, SOAP, and Transport-Layer Security, so that data can move securely over the Internet and NOT require private networks or point-to-point interfaces. The wise path forward is to continue industry momentum by sticking to the course of these proven standards, which many have collaborated on via open consensus processes and implementation testing. The proposed principles must have been implicitly accepted, in that HITSP-selected content standards (such as C32/CCD) and transport standards (such as XDS.b, which uses the abovementioned web standards) are already independent. The recent HITSP effort to repackage them into "Capabilities" had some benefits but may have had the unintended consequence that some people mistakenly concluded that content and transport were intermixed in the same standard. In fact, I believe that the principles you espoused have been guiding HITSP's work. Thanks.
David Tao
Look great. K.I.S.S method, love it.
ReplyDeleteOne question:
Separate content standards from transmission standards; i.e., if CCD is the html, what is the https?
I agree with statement but the i.e. a bit confusing, CCD is XML. What is the https? ??
thanks,
Jeff Brandt
www.comsi.com
I have again posted the rough draft transcript if you would like to review the meeting. Even in this rugged form it is pretty interesting reading...
ReplyDeletehttp://ahier.blogspot.com/2009/11/hit-standards-meeting-11-19.html
Hello John,
ReplyDeleteExcellent principles. I would suggest that we consider adding user centered design (Providers & Patients) into the user interfaces.
John:
ReplyDeleteI really like what you've said here, esp.,"Keep the implementation cost as low as possible; eliminate any royalties or other expenses associated with the use of standards."
What about CPT codes and the AMA?
In the spirit of KISS, I'd like to see REST as an alternative to WSDL/SOAP.
Alan Viars http://videntity.com
Jon,
ReplyDeleteThis is a great start. Sure we need to focus on security especially when we open doors on internet (as transport), especially with web services that pose new threats (both externally and internally). We may have to include tools to check on standards and best practices compliance and scan for vulnerabilities. BTW, I would recommend to standardize REST for consumer end and SOAP for the B2B end (enterprise to enterprise).
Regards,
SP