The specification is designed to meet the needs for CMS Auditing with respect to attachments. The payers in the room indicated that their needs were mostly met already just using the Consolidated CDA, and they didn't need further conformance requirements. So now it seems that we could have two kinds of attachments, one required for CMS, and other that would be desired by Payers.
"How," I asked, "is this administrative simplification?"Several other people in the room responded positively to that query, but we never quite got an answer.
One of the issues raised by this document was how you would be ask for attachments conforming to it, rather than just the Consolidated CDA. One proposal was to request new LOINC codes, at which point I almost exploded (OK, perhaps I did explode). After all, the LOINC codes that are used in CCDA came out of the original Attachments guides, why did a new attachment guide using the same concepts (History and Physical, Consult, et cetera) need to have NEW LOINC codes. If we start messing around with new LOINC codes, those codes aren't even going to show up in CCDA, so many will question whether they are even valid CCDA (they still would be since those value sets are dynamic). One possible solution is to simply request a new LOINC modifier code, which doesn't confuse LOINC document ontology, and meets the requirement need. That suggestion seemed to have merit, but we never decided on it.
Following all this discussion, the comment that raised up all these issues (a descriptive name for the guide) triggered a motion to rename the document. I observed then something I've never seen in all my years of committee work, which was a tied vote which had to be broken by the chair. The motion failed, which means that we remained at status quo. This is a good thing in my mind for a tied vote, because it is easy to move from status quo later, but hard to go back to it.
I'm sure there will be a lot more to do on this topic, the guide itself attracted quite a number of negatives (89 out of 101 votes), many of which still have to be resolved (70 out of 101) before it can move forward. There's enough negatives on this ballot that the committee may decide it needs to go out for another cycle.
I really appreciate you for all the valuable information that you are providing us through your blog.
ReplyDeletehttp://health-care-and-agility.blogspot.com/2014/05/healthcare-industry-is-growing.html
ReplyDeleteOne question that came to mind about this request was, "What is the rationale for this 'everything is required' concept?" My suspicion is that CMS's internal discussions are, perhaps, trying to drive HL7 down the road of the "if not required do not send" framework that forced changes to all the X12 5010 guides. Trying to do this for every potential HL7 element seems like administrative hubris elevated to existential folly.
ReplyDeleteSo, perhaps a zen-like response -- to unask the question -- would be better than trying to satisfy a mindset that favors paper-based unstructured abandon ("We send the entire medical record so we can get paid") over sensible, consensual rational exchange ("Here are the things you need, here is where you will find it, and our trust agreement ensures I have sent only the necessary content.").
Or to put it another way. Not just "No," but "Nirvana No."