Early Feedback on the IFR and NPRM

I've received hundreds of emails of from colleagues, friends, and staff about the IFR and the NPRM.

Many really like what they see. ONC and HHS are to be congratulated.

Some think there are needed refinements. Here's an inventory of those comments:

The Interim Final Rule on Standards

1. Several folks believe the lab standards are not specific enough. 100% of the optionality of the HL7 base standard is still allowed because specific implementation guidance is missing at this point. For labs this does not lessen the customization of interfaces nor indicate a move away from individual point to point arrangements between commercial labs and their customers. If details like implementation guides are not added to rules that set a firm technical direction for Stage 2 with a minimum of 2 years advance notice for implementation, it will not be possible for the country to achieve the policy targets of Stage 2 for structured information exchange until a later date

2. Several folks believe that transmission needs more detail. The IFR notes that SOAP or REST are acceptable. SOAP could include CAQH Core Phase II, XDS.b/XCA/XDR, the FHA Connect software, or any proprietary implementation of SOAP 1.2 which vendors/HIEs would like to implement. REST is an architecture so it provides great latitude to implementations. Google and Microsoft have implemented RESTful interfaces that are not compatible with each other to support their personal health record products. Specificity such as using the CAQH Core Phase II Implementation Guide for all data exchanges (administrative and clinical) or requiring a very specific URL format for RESTful interfaces would enhance interoperability.

3. Several folks are unsure how to implement the RxNorm requirement in Stage 1. Must EHRs internally have one of the RxNorm source vocabularies

GS - 10/01/2009 (Gold Standard Alchemy); MDDB - 10/07/2009 (Master Drug Data Base. Medi-Span, a division of Wolters Kluwer Health); MMSL - 10/01/2009 (Multum MediSource Lexicon); MMX - 09/28/2009 (Micromedex DRUGDEX); MSH - 08/17/2009 (Medical Subject Headings (MeSH)); MTHFDA - 8/28/2009 (FDA National Drug Code Directory); MTHSPL - 10/28/2009 (FDA Structured Product Labels); NDDF - 10/02/2009 (First DataBank NDDF Plus Source Vocabulary); SNOMED CT - 07/31/2009 (SNOMED Clinical Terms (drug information) SNOMED International); VANDF - 10/07/2009 (Veterans Health Administration National Drug File); FDA Unique Ingredient Identifiers (UNII)

or is the requirement that data exchanged from the EHR include one of these vocabularies? Some EHRs have proprietary vocabularies that could be mapped to one of these vocabularies or RxNorm itself when data is exchanged. Others have asked if these source vocabularies fully mapped to RxNorm since the vendors may not have submitted their complete product, just a subset. The strategy of using a source vocabulary inside an EHR and RxNorm for transmission outside an EHR requires a complete mapping.

4. Some have highlighted that there are a number of emerging standards in the quality area such as Quality Reporting Document Architecture (QRDA) and Healthcare Quality Measure Format (HQMF). Although these standards are not mature enough to require in Stage 1, giving implementers credit for early adoption would advance quality reporting.

5. Some have said that there is too much optionality in the security standards. AES should be required for encryption, SHA-1 or SHA-2 for data integrity and TLS, IPv6 or IPv4 with IPsec for secure transmission should be the only choices.

The Notice of Proposed Rulemaking

Many folks find the NPRM intimidating. Taking a typical community hospital from their current state to the degree of functionality required in the NPRM is a challenge. Here are a few of the comments I've received

1. The CPOE requirement should include emergency departments. Currently, the NPRM seems to exclude the ED as qualifying for the 10% electronic ordering threshold. Many people believe the ED could be a good first place to implement CPOE and the transaction volume would meet 10% of hospital orders.

2. Many have said that the quality reporting requirement is too much too soon.

3. Many have said that the Patient engagement requirements are too much to soon. Vendors have commented that they do not understand how to send reminders to patients per their preference (email, fax, phone call, PHR, Facebook, twitter) and since there is no standard secure API for doing this, it is unimplementable. Providing 80% of patients with a clinical summary of office visits or care transitions will require significant retooling of software and incremental staffing.

4. Electronic Medication reconciliation at each transition of care is challenging to implement technically and requires significant workflow redesign.

5. There is no standard API for submission of immunization, syndromic surveillance data or public health lab reporting, making this challenging to implement. Given that the transmission standards in the IFR lack detail and there is no national reference implementation to follow, there will be significant heterogeneity in each locality, creating a challenge for vendors.

Summarizing the comments I have received - aggressive interoperability timelines require specific implementation guides and reference implementations. This leaves a choice - either the standards need more detail, especially in the transmission area, or the NPRM goals need to reduced in scope/extended in time.

At BIDMC, we have worked for years on several healthcare information pilots among payers, providers, government, and patients. Because of these pilots we do have local implementation guides, a defined architecture, and transmission standards. This means that we're in reasonable shape for implementing the IFR and NPRM as written. However, we would appreciate clarification of the patient engagement requirements. We can send the patient summary record to Google Health and Microsoft Healthvault. We make all patient data available via our tethered PHR. We do not send unsecured email to patients nor do we make extensive use of interactive voice technology. I'm hopeful the comment period will provide these clarifications. HITSP and the HIT Standards Committee will be providing comments and I'll submit my own to ensure all the concerns I've heard are broadly communicated.