At the February 24 meeting of the HIT Standards Committee we heard reports from each of our workgroups reviewing the Interim Final Rule.
*If regulatory language allows, the best way to support standards specificity while still enabling standards to evolve is to list general classes of standards in the regulation i.e. HL7 Version 2 and then provide very specific implementation guidance outside the regulation. If specificity is needed within the regulation, then the inclusion of a single implementation guide as a floor, with the intent that it will evolve, would meet this need.
*Standards should refer to data exchanges between organizations, not within an organization. An entity should be free to use whatever proprietary approaches to content and vocabulary standards support the needs of internal workflows as long as these can be translated into the standards specified in the Interim Final Rule when exchanging data.
*The standards in the Interim Final Rule, a regulation, replace previously "approved" or "recognized" standards published in the Federal Register if conflicts exist. This is important because Executive Order 13410 requires Federal agencies to use recognized standards when installing or upgrading their systems. The IFR will be the new source of truth.
*An allergy vocabulary is needed in 2011 to comply with quality measurement requirements
*A standard for recording vital signs is required in 2011 to compely with quality measurement requirements
*The nature of the datatypes needed to support some quality measures constrains the choice of summary exchange standards because of the need to capture actions, actors and events in a granular fashion i.e. for some quality measurement purposes, CCD is a better choice than CCR. CCR remains a very reasonable choice for exchange of summary information for care coordination.
* For Modular EHRs, security requirements should be "addressable" for every EHR Module submitted for certification. This means that not every module needs to meet every security criterion i.e. a module which calculates body mass index may not exchange data outside the organization and thus does not need to include encryption technology.
*For encryption, the committee recommended that symmetric and asymmetric encryption both be supported and that AES be specified as the symmetric encryption standard.
*Since data transmission may take many forms (MLLP, TCP/IP, HTTPS POST, SOAP and REST), providing a requirement to use SOAP and REST without specifying details is not helpful. Either provide very specific guidance for each transaction type or none at all. The committee recommended removing transmission standards from the IFR at this time, leaving security standards intact i.e. you can use HTTP, SMTP, FTP, etc but requirements for encryption and auditing still apply.
The implementation workgroup discussed March 8 hearing on "starter toolkits" to ease EHR adoption. We'll be taking testimony from the Public Sector, an array of stakeholders with implementation experiences, and innovators. We're specifically asking the testifiers to contribute white papers, software, and others enablers to a Starter Toolkit that could be used by providers, communities, and vendors to accelerate meaningful use.
The comments made at the meeting will be codified into recommendation letters for committee review and then signature by the co-chairs in time for ONC to include them in the comment process (first week of March).
0 comments:
Post a Comment