Like many of you who read this blog, I've been spending a great deal of time reviewing the HIT Standards Committee recommendations that have been out for about a month now, and the most recent updates to them for Security, Privacy and Infrastructure.
Interpreting the Clinical Operations Recommendations
The Clincial Operations document has been very difficult to read because it groups various functions together when making the standards recommendations. But then it doesn't identify which standards apply to which functions. I did a little calling around and digging to find out what it all means, and am reporting my findings here in the hopes of helping to dispell similar confusions others face.
However, I must note that you use this information at your own risk. The interim final rule will be published in the Federal Register some time in December. While I may have some good guesses, nobody except those at ONC who are writing it really knows what it will contain.
First of all, the Clinical Operations Workgroup spreadsheet was limited to two pages to avoid scaring people off. However, if you've tried to print it out like I did, and your vision is as good (as bad really) as mine, you'll see that the information is as dense as what could have appeared in four or more pages. Also, the tabular format really wasted a lot of white space that could have been put to better use.
Summary Records, Clincial Reports, Encounter Messages, Radiology Messages, Allergies, and Clinical Notes Content Exchange
The HIT Standards Committee recommended use of the Standards specified HITSP Capabilities 117, 118, 119, 120, 126, 127 and 137 for these purposes. What they didn't say which would have been helpful, is which of these capabilities applies to Summary Records (119 and 120), Clinical Reports (126, 127), Encounter Messages (137), Radiology Messages (137), Allergies (I haven't figured that one out yet but it appears to be 117 and 118 by a process of elimination), and Clinical Notes Content (119 and 120).
As always, when you use a term or short phrase, it's really helpful if you give a definition of it, especially if your readers weren't part of the norming process that you went through. I'd like to point out that "Clinical Reports" and "Clinical Notes" are pretty hard to distinguish between, and I've only managed to do so because I did the mappnig. This is one of the principals that the HITSP Data Architecure specification uses. Each thing we discuss has both a name and a definition. Hopefully, future communications from the Standards Committee will be more helpful here.
I won't go into all the gory details for the other requirements. Now that you know the general pattern, you should be able to apply it on your own. The key thing in understanding the HIT Standards document is to A) look at the HITSP Capabilities they identified, and then B) break down the requirements by function and map them to capabilities.
I'll be working on some thoughts about how to better present this information and communicating those to members of the Clinical Operations Workgroup subsequently.
Interpreting the Privacy and Security (and Infrastructure) Workgroup Recommendations
The output of this group is much easier to read. There are four tabs in the spreadsheet, crossing certification/guidance with security/infrastructure (there's very little here with respect to privacy yet). My interpretation of this is that the guidance tabs identifies the appropriate HITSP specifications that will help you to understand what to implement, and the certification tabs tell you the standards that have been recommended. Why they couldn't just identify the HITSP specifications and leave the naming of standards to those documents is beyond my pay grade.
Document Exchange
This was most helpful except for one thing, which was Document Exchange. The question that I've had to track down is whether or not one a document exchange standard (e.g., XDS.b, XDR or XDM) is required for 2011 or not . The spreadsheets from the workgroup call out specifically standards that are required, and specifically name XDS.b, XDR and XDM but in 2013 and beyond. However, they also call out HITSP Service Collaboration 112, which specifically names XDS.b, XDR and XDM.
So, I sent out several queries, and the feedback I've heard and seen from others who have been in communication with the Security and Privacy Workgroup and the Clinical Operations Workgroup is that intent was that ONE OF these would be needed to support the exchange of patient information, just as is specified in Capability 119 and 120, and the underlying Service Collaboration 112.
The Privacy and Security updates were fixes. They consisted of two items:
ReplyDelete1) SOAP version now fixed at 1.2. There was a misunderstanding before that SOAP 1.1 was needed, but reality is that the marketplace using the selected healthcare standards isn't actually using any SOAP 1.1
2) Kerberos. This was a misunderstanding as well that I outlined on my blog http://healthcaresecprivacy.blogspot.com/2009/09/kerberos-required-in-2011-then.html
As to the XDS, XDR, XDM question... I have been told that the answer is as Keith has stated. Pick at least one. Anyone will do. What is not as clear is that when you pick one, you need to pick both-sides of that one. That is you must pick a way to send and receive. For Example: If you pick XDM, then you must be able to publish to XDM and consume XDM. Ill be interested to hear Keith's perspective on consumption, does this mean just 'view' or does it mean 'import in full fidelity with complete attribution of source'?
Bravo Keith, my sentiments exactly. And many others are going through the exact same exercise you mention, because of the 'many-to-many' relationships of requirements to standards in each row of the spreadsheet. The EHRA actually made a public comment to the same effect, through Charles Parisot. Your specific breakdown of one "row" was good to illustrate this in terms that the public can understand.
ReplyDeleteDavid Tao