Thursday, December 31, 2009

The Interim Final Rule on Standards

Yesterday at 4:15pm, HHS/ONC released the Interim Final Rule (IFR) - Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology.

Pages 79-81 contain the content and vocabulary standards

Page 85 contains the privacy standards.

Let's examine the major recommendations.

The standards selected leverage the hard work done by HITSP, Consolidated Health Informatics, Federal Health Architecture, NCVHS, and government agency efforts . The IFR notes that unless marked with the following superscripts, all of the adopted standards are from the ONC process that took place prior to the enactment of the HITECH Act or are required by other HHS regulations.

A number sign “#” indicates that the HIT Standards Committee recommended this standard to the National Coordinator but it was not part of the prior ONC process.

An asterisk “*” indicates that the standard was neither recommended by the HIT Standards Committee nor part of the prior ONC process.

A plus sign “+” as mentioned above indicates a standard that is not a voluntary consensus standard.

The content and vocabulary standards selected includes Adopted Standard(s) to Support Meaningful Use Stage 1 (2011) and Candidate Standard(s) to Support Meaningful Use Stage 2 (2013).

1. Patient Summary Record

The adopted content standard is HL7 CDA R2 CCD Level 2 or ASTM CCR. The candidate content standard is the hope that this will be converged to a single standard based on HIT Standards Committee recommendations. As I said in my Genius of the AND blog, I truly believe that CCD and CCR is the most parsimonious set of content standards for the summary record in 2009. I'm hopeful that HL7 and ASTM will continue their work together, simplifying the XML of CCD so that CCD and CCR can converge into a single approach which makes implementation easier for all.

Of interest, page 66 of the IFR notes that CCR must be parsed by all EHRs even if CCD is used. Per the IFR - "A final example would be, if an eligible professional uses Certified EHR Technology that has implemented the continuity of care document (CCD) standard for the exchange of a patient summary record and receives a patient summary record formatted in the continuity of care record (CCR) standard, their Certified EHR Technology must be capable of interpreting the information within the CCR message and displaying it in human readable format. We do not expressly state how this should be accomplished or in what format human readable information should be displayed (e.g., information in a CCR message could be converted to a text file or PDF). We only require that Certified EHR Technology must be capable of performing this function. We believe this requirement is critical and have included it to allow flexibility in the marketplace during meaningful use Stage 1 and to prevent good faith efforts to exchange information from going to waste (i.e., information is exchanged, but is unreadable to both Certified EHR Technology (machine readable) and humans)."

The adopted vocabulary standards for problem lists are the applicable HIPAA code set required by law (i.e.,ICD-9-CM) or SNOMED CT. The candidate standards are the applicable HIPAA code set required by law (e.g.,ICD-10-CM) or SNOMED CT. My hope is that SNOMED CT adoption is accelerated and that ICD-10's role will be limited to a back office function. Widespread implementation of ICD-10 will be costly and brings little added value to clinicians, while SNOMED CT captures clinical observations very well, enabling decision support and better quality measurement.

The adopted vocabulary standards for medications are any code set from an RxNorm drug data source provider that is identified by the United States National Library of Medicine as being a complete data set integrated within RxNorm+ (note the + indicating RxNorm is not a consensus standard from an SDO, it's a product of the National Library of Medicine). For a complete list of the allowable vocabularies, see the NLM list which includes:

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). Also, FDA Unique Ingredient Identifiers (UNII) are a component of RxNorm.

The candidate vocabulary standard is RxNorm. I believe that the EHRs will continue to use proprietary standards internally for many years to come, but will need to map to RxNorm for all data exchanged.

The adopted vocabulary standard for allergies is not specified at this time i.e. free text or local vocabularies are fine. The candidate vocabulary standard is the Unique Ingredient Identifier (UNII). This makes great sense, since it will take vendors and self built system operators several years to implement controlled allergy vocabularies throughout their products.

The adopted vocabulary standards for procedures are the applicable HIPAA code set required by law (i.e.,ICD-9-CM) or CPT-4. The candidate standards are the applicable HIPAA code set required by law (e.g.,ICD-10-CM) or CPT-4. Of all the vocabulary standards mentioned in the Interim Final Rule, only one, CPT-4, requires payment for its use. I hope that HHS licenses CPT-4 for general use just as it has licensed SNOMED-CT. This will significantly reduce the implementation burden.

The adopted vocabulary standard for Vital signs is not specified at this time i.e. free text or local vocabularies are fine. The candidate vocabulary is a CDA template. This makes sense. I'm a fan of CDA templates to make CDA easier to implement.

The adopted vocabulary standard for units of measure is not specified at this time i.e. free text or local vocabularies are fine. The candidate vocabulary is UCUM. This is a very reasonable approach, giving commercial and hospital labs the time they need to implement a controlled unit of measure vocabulary standard.

2. Drug Formulary Check

The adopted content standard for Drug Formulary Check is the Applicable Part D standard required by law (i.e., NCPDP Formulary & Benefits Standard 1.0). The candidate vocabulary standard will also be whatever is required by Part D. This standard is widely deployed and there are no credible alternatives.

3. e-Prescribing

The adopted content standard for e-Prescribing is NCPDP script 8.1 or NCPDP script 10.6. The candidate standard is NCPDP Script 10.6. We debated this at the HIT Standards Committee, hoping that NCPDP 10.6 could be accelerated, but it is a reasonable compromise to offer some transition time.

The adopted vocabulary standards are the same as for the Patient Summary Record above.

4. Administrative Transactions

The adopted and candidate standards for Administrative Transactions are those required by HIPAA i.e. 4010 now and 5010 in 2013. This is expected.

5. Quality Reporting

The adopted content standard for quality reporting is the CMS PQRI 2008 Registry XML Specification#,+ (note that this means it was suggested by the HIT Standards Committee and not by HITSP, it's not an SDO product but was produced by CMS). The candidate standards are those to be suggested by the HIT Standards Committee. We debated this at the HIT Standards Committee because QRDA is an emerging standard for quality reporting but not a widely implemented one. This glide path is reasonable, but does require implementers to change course - implementing PQRI XML now and possibly QRDA or other standards later. It will be interesting to follow the comments on this one - maybe PQRI and QRDA should be allowed now to prevent this rework.

6. Submission of Lab Results to Public Health Agencies

The adopted content standard for lab reporting is HL7 2.5.1. The candidate standards are potential newer versions to be recommended by the HIT Standards Committee such as CDA documents. This is very reasonable given that all lab transactions in the country currently use HL7 2.x approaches.

The adopted vocabulary standard is LOINC when LOINC codes have been received from a laboratory. The candidate vocabulary standards are LOINC, UCUM, and SNOMED CT or Applicable Public Health Agency Requirements.

What does this mean? Per the IFR "We do not require Certified EHR Technology to be capable of mapping all laboratory orders or tests to LOINC codes. Rather, we require that Certified EHR Technology be capable of using LOINC codes that are received and retained to populate a patient summary record. Moreover, having LOINC codes used internally for meaningful use Stage 1 will prepare Certified EHR Technology for any future potential meaningful use Stage 2 requirements. We believe the use of LOINC, Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT), and other vocabulary standards will accelerate the adoption and use of clinical decision support. Requiring LOINC as a vocabulary standard that Certified EHR Technology must have the capability to support for meaningful use Stage 1 provides an incremental approach to achieving these future goals." This is a very reasonable glide path to accelerating adoption of LOINC.

7. Submission to Public Health Agencies for Surveillance

The adopted content standards are HL7 2.3.1 or HL7 2.5.1. The candidate content standards are potentially newer version(s) or standards based on HIT Standards Committee Input, such as CDA documents. Of interest, Geocoded Interoperable Population Summary Exchange (GIPSE), a summary format for surveillance data submission, is listed as a vocabulary standard. I believe it should be moved to the candidate content standards area, as it is a great way to report summary surveillance data content.

The adopted vocabulary standard is listed as According to Applicable Public Health Agency Requirements. The candidate vocabulary standard is listed as GIPSE or According to Applicable Public Health Agency Requirements.

8. Submission to Immunization Registries

The adopted content standards are HL7 2.3.1 or HL7 2.5.1. The candidate content standards are potentially newer version(s) of standards based on HIT Standards Committee Recommendations such as CDA documents. The HIT Standards Committee discussed this, since HL7 2.3.1 is the currently accepted standard for immunization exchange, but HL7 2.5.1 is now ready. Allowing both for now makes sense.

The adopted vocabulary standard is CVX*,+, the CDC's National Center of Immunization and Respiratory Diseases (NCIRD) maintained HL7 code set. Note that this recommendation is marked as not made by either HITSP or the HIT Standards Committee, but actually it was made by both via the HITSP Interoperability Specification for Public Health Case Reporting

The Privacy and Security adopted standards represent the simplest set of technologies and policies that protect confidentiality and ensure data integrity. They are:

1. General Encryption and Decryption of Electronic Health Information - A symmetric 128 bit fixed-block cipher algorithm capable of using a 128, 192, or 256 bit encryption key must be used (e.g., FIPS 197 Advanced Encryption Standard, (AES), Nov 2001).+. This was recommended by the HIT Standards Committee.

2. Encryption and Decryption of Electronic Health Information for Exchange - An encrypted and integrity protected link must be implemented (e.g., TLS, IPv6, IPv4 with IPsec).+ This is a very reasonable recommendation that represents the best thinking of the HIT Standards Committee, HITSP and industry experts. We all recognize that TLS is great for point to point connections, while IPv6 and IPv4 with IPSec are better for organization to organization secure connections. It's a very wise approach.

3. Record Actions Related to Electronic Health Information (i.e., audit log) - The date, time, patient identification (name or number), and user identification (name or number) must be recorded when electronic health information is created, modified, deleted, or printed. An indication of which action(s) occurred must also be recorded (e.g., modification).+ Rather than require ATNA or CT profiles, this recommendation leaves the audit trail to policy - what data to record. This is a reasonable compromise distilled from many hours of expert testimony.

4. Verification that Electronic Health Information has not been Altered in Transit - A secure hashing algorithm must be used to verify that electronic health information has not been altered in transit. The secure hash algorithm used must be SHA- 1 or higher (e.g., Federal Information Processing Standards (FIPS) Publication (PUB) Secure Hash Standard (SHS) FIPS PUB 180-3).+ This was recommended by the HIT Standards Committee.

5. Cross-Enterprise Authentication - Use of a cross-enterprise secure transaction that contains sufficient identity information such that the receiver can make access control decisions and produce detailed and accurate security audit trails (e.g., IHE Cross Enterprise User Assertion (XUA) with SAML identity assertions).+ Just as with auditing, this is left to policy and does not require a single specific standard/profile such as XUA. The use of SAML approaches does make great sense and will be widely adopted in healthcare, since it is already widely used in other industries.

6. Record Treatment, Payment, and Health Care Operations Disclosures - The date, time, patient identification (name or number), user identification (name or number), and a description of the disclosure must be recorded.+ This too is left to policy, which is a great choice, since the industry has yet to figure out how disclosures will be tracked operationally.


These recommendations are consistent with the work of thousands of experts over the past decade. They do not include all the detailed recommendations from HITSP or implementation profile writers such as IHE but they do include all the highly mature constructs that are deployable in 2011 without over burdening the industry. From what I know about standards harmonization, the state of standards adoption, and the unresolved controversies/debates, the rule is the right mixture of harmonization and compromise. Not every stakeholder will be happy with it, but it is good enough. It moves us all forward toward the goal of less optionality, more constraints, and vocabulary controlled semantic interoperability.

Well done!

4 comments:

David said...

Thanks John for your detailed reading and summarization of key points that help us see the big picture. I expect that the * and + items will receive the most attention and public comment. It's good to see that so much work from HITSP and the Standards Committee, as well as prior ONC-accepted certification criteria, are included. Note that CVX vaccine codes actually should not be marked as a "*" because CVX is already part of the HITSP vocabulary recommendation (in the immunization capabilities and C80 specification) and thus was implicitly recommended by the Standards committee by reference -- so that's a good thing (not a surprise). Once again, thanks for explaining standards in terms that help a wide audience to understand.

Ahier said...

The ONC has clarified that the comment period does not begin until the interim final rule and proposed rule are published in the Federal Register on 1/13/2009:

http://healthit.hhs.gov/blog/onc/index.php/2009/12/30/a-defining-moment-for-meaningful-use/comment-page-1/#comment-342

Happy new year!

Certain Ambiguity said...

Why are there no use cases or examples for
"Verification that Electronic Health Information has not been Altered in Transit - A secure hashing algorithm must be used to verify that electronic health information has not been altered in transit."
Is this applicable to data at rest or in motion? If at rest, who is responsible for the verification? Typically, the sender has no control over the recipients system to perform such checks.

Graham said...

The quality reporting requires the PQRI 2009 registry XML specification, but as far as I can tell, this specification is for registries submitting data on behalf of EPs and is not the appropriate format for EHRs to submit data. That is EPs submit data to a registry and the registry then uses this format to submit on their behalf. The other kicker is that CMS is requiring in 2011 data to be submitted in QRDA format so asking EHRs to be able to report in 2009 XML format seems a waste of time.