Draft Fm Ifr Comments

Draft FM IFR Comments

Thoughts for the overall statement for MU:

• Applaud the approach of incentives to improve the infrastructure with the goal of improving health care overall

• Measured approach, taking into account market readiness, in logical steps moving toward full compliance

• Establishes a structural framework which gives this initiative longevity. Doesn’t tie technology to a particular point of time

• Timelines are aggressive and our experience in achieving compliant and successful [cost savings] implementations requires a longer period of time as proven by HIPAA.

• Strongly encourage ONC to work with communities to identify low tech/low cost solutions for the defined capabilities to help defray the costs and learning curves

• Successful uptake is going to require a community effort and a consistent message to providers and practices

• Concerted education effort, guide payers/givers of the funds

• Need to continue to focus on making this easier for providers

• Stakeholders should get together to determine requirements for needs – but they need to be shown/trained in how to do it

• ONC should fund development of a template registry, and implementation and testing tools for CCD and CCR through Open Health Tools and NIST

• Consider the development of a vendor resource center to ensure interpretation of the rule and allow them to “work together” to ensure software does actually meet the requirements

• Privacy and security. HIPAA has been in effect now. There are not sufficient standards in the law to support this standard now. Enforcement is ‘lax’. Consent is going to be an issue; standards are available from HL7 that have been in production in other countries for many years. ONC should seriously considering building privacy and security in to EHRs from the beginning rather than retrofitting later.

Cpt licensing issues

CPT licensing is an implementation barrier because of its expansive definition of” user” and what constitutes usage.[1] In addition to a cost of the license, meaningful use providers will incur wasteful administrative costs just managing the licensing. We urge ONC to pursue a national license or to include the cost of such a license on all users – including patients using PHRS – in the final rule’s regulatory impact analysis.[2]

use of icd-9-cm and ICD-10-CM codes for clinical problems

ICD-9-CM codes are used in billing systems for reporting diagnosis, problems, and conditions to payers. Providers are required to send ICD-9-CM to payers when they bill for services meant to eliminate a diagnosis. In HIPAA X12 837, the ICD-9-CM is accompanied by a flag that indicates whether this code is being used for that purpose. Neither the CCR nor the CCD support such a flag, so there is no way to know whether ICD-9-CM codes used in either report format accurately conveys the patient’s problems. If EHR technology must be certified as supporting use of ICD-9-CM, then providers may populate the summary records, quality measures, discharge instructions, and referrals with billing ICD codes resulting in false positives about the patient’s condition if these codes are used for analysis or decision support.[3]

X12 HIPAA Transactions

With respect to the inclusion of X12 837 claims and 270/271 Eligibility Verification transactions standards and as certification criteria, and as meaningful use measures: While implementation of an ePrescribing module as part of HITECH EHR technology makes sense, we fail to see the priority given for implementation of a module that is typically not considered part of an EHR system, and is typically implemented in a practice management system or out-sourced to a billing service, and any provider who is compliant with HIPAA ought to be doing anyway.

That aside, we are even less clear why HHS would require providers to implement the X12 4010A1 in 2011 in order to receive HITECH incentives only to have to upgrade to the X12 5010 in 2013, which they are required to do anyway. Instead, we recommend either eliminating these as certification criteria and standards, and as meaningful use measures in the NPRM.

concern about conflict between HIPAA Mandated 271 Response and medicare and Medicaid phishing prohibitions

FM is concerned that a strict interpretation of the HIPAA-mandated ASC X12N 270/271 – Health Care Eligibility Benefit Inquiry and Response, Version 4010 (004010X092) and Addenda to Health Care Eligibility Benefit Inquiry and Response (004010X092A1) as well as ASC X12 Standards for Electronic Data Interchange Technical Report Type 3, Version 5010 (ASC X12N/005010X279)requirements for the use of the AAA Segment to report errors in identifying the patient in the 271 Response transaction likely conflicts with established policies and procedures regarding phishing that many Medicaid agencies have established.

The specific concern is that a strict interpretation of the 270/271 AAA specification requires the payer to inform the requestor exactly which fields in the search request caused the mismatch with the payer data providing an opportunity for phishing.Although we support the inclusion of CORE Phase I, in Stage 1 of meaningful use, further investigation is required to determine the impact of such a strict interpretation of the HIPAA-mandated transaction set and the use the AAA segment may have on privacy and other policies of Medicaid agencies and other governmental bodies. [4]

medication reconciliation

With respect to the criterion for medication reconciliation[5], please clarify whether reconciliation is to be performed only for current medications, for a particular date range, or for all known medications. Please also define "relevant encounter."

Security and EHR Modules

FM recommends that the rule specify that all EHR modules have the capability of integrating with security services as appropriate; that certification testing includes validation that the required interfaces are included in all modules; and that the security module(s) be capable of supporting the security requirements of a configuration of EHR modules.

Access Control standard, and support for patient authorizations and consents

FM urges ONC to adopt functional specification for access control and for the electronic capture, management, and conveyance of patient consents and authorizations afforded under HIPAA, 42 CFR Part 2, state laws, The Medicaid program confidentiality requirements[6], and ARRA. These functional specifications should enable computable enforcement of patient authorizations and consents by means of access control technologies in order to meet the criterion: “Capability to exchange key clinical information among providers of care and patient authorized entities electronically.”

We note that the qualifier “patient authorized” that is included in the preamble is dropped from the wording of the regulation. We strongly urge that this qualifier be included in the actual regulation in order for this certification criterion to enable providers to meet multiple jurisdictional laws relating to patient authorizations and consents.

In addition, while the regulatory language does include an access control certification criteria, we are concerned that the NPRM stipulation[7] that providers must only meet certification criteria for which a standard has been named may preclude any actual certification of access control capabilities.

Finally, we recommend that ONC include a comprehensive definition of access control to include the operations that users can perform on the information once they have accessed it such as updating, printing, deleting, and forwarding.

Secure Email

The certification criterion: “Send reminders to patients per patient preference for preventive/ follow up care” seems to require that providers be capable of sending this information to patients by email if that is the patient’s preference. Therefore, there should be a secure email functional standard that puts the onus on the healthcare provider to authenticate and integrity-protect any email messages it sends.

Relation of IFR and EO13410

FM has concern that several key standards, which will be required by the IFR in order to demonstrate meaningful use Stage 1, potentially overlap and are inconsistent with the standards that already are recognized and required as a result of an existing Executive Order 13410, “Promoting Quality and Efficient Health Care in Federal Government Administered or Sponsored Health Care Programs.”[8]

1. Example 1: Any EHR that providers use to exchange data with EO 13410 covered agencies (i.e. any Federal agency administering or supporting a Federal health care program) and also to demonstrate meaningful use for purposes of CMS incentive payment will have to support both diagnostic codes systems CCD and CCR. We believe these two systems are not completely aligned, and in some cases, actually conflict.
2. In the IFR, ONC selects CCD and CCR for the adopted standard(s) to support meaningful use stage 1 for the “Patient Summary Record” purpose in Table 2a[9]. Both CCD and CCR support ICD-9-CM and SNOMED for problem values. EO 13410, as implemented, however, required Federal agencies supporting government healthcare programs to meet HITSP Standards.[10] Specifically, EO13410 recognized HITSP C32 as the constrained CCD, and this standard does not permit the use of ICD-9-CM.[11] Rather, this specification contains the exclusive use of SNOMED, and also contains many value sets that constrain the CCD. Therefore, a provider who exchanges C32s with federal health agencies and CCDs or CCRs for meaningful use measures will need an EHR that is able to support all three document types and be able to switch among them based on their trading partner requirements. This is just one of multiple constraints that the C32 enforces on the CCD that results in conflicts about the conformance strength, permitted templates, cardinality, and vocabularies.[12]
3. In addition, there are no Access Control standards (functional or otherwise) in the IFR even though there are certification criteria that directly or indirectly require access control capabilities. Under EO 13410, providers exchanging health information withfederal health agencieswould need to implement HITSP Access Control specification (TP20). And once data segmentation comes into play, there is the potential for conflict between what the HITSP Manage Consent Directives specification (TP30) requires and whatever ONC may adopt by rule for meaningful use. Due to these conflicting requirements, it will be difficult for any provider to find (or for any vendor to produce) an EHR that meets both what is recognized by EO13410
4. Example 2: ONC previously recognized HITSP access control and managing patient consent directives specifications, however, these were not adopted in the IFR despite there being certification criteria that can only be met with at least functional specifications for access control and consent directive management to ensure that only authorized individuals can access PHI in accordance with applicable jurisdictional and organizational policies and patient authorizations and consents. Specifically under theProposed Meaningful Use Stage 1 Objectives: Protect electronic health information created or maintained by the certified EHR technology through the implementation of appropriate technical capabilities:

1. Assign a unique name and/or number for identifying and tracking user identity and establish controls that permit only authorized users to access electronic health information;

2. Permit authorized users (who are authorized for emergency situations) to access electronic health information during an emergency;

8. Verify that a person or entity seeking access to electronic health information is the one claimed and is authorized to access such information;

9. Verify that a person or entity seeking access to electronic health information across a network is the one claimed and is authorized to access such information in accordance with the standard specified in Table 2B row 5

1. Example 3: Where the IFR would permit use of non-standard units of measure that are not compliant for use in CCD and C32, which requires use of UCUM. As a result, meaningful use certification testing of the CCD would be against a non-conformant CCD specification that allowed the use of non-standard, non-UCUM unit of measure codes. A provider’s EHR certified as meeting the IFR would need to support whatever unit of measure code system it received, while being required to send and receive only UCUM in C32s for purposes of EO 13410.

1. CONCLUSION: We understand that the intent of the IFR is to align:

“the initial set of standards, implementation specifications, and certification criteria adopted by this rule to focus on the capabilities that Certified EHR Technology must be able to provide in order to support the achievement of the proposed criteria for meaningful use Stage 1 by eligible professionals and eligible hospitals under the Medicare and Medicaid EHR Incentive Programs.”[13]

However, we are concerned with the potential contradictions between the requirements of the IFR and the more prescriptive requirements under EO 13410. These contradictions could pose a dilemma for providers who are currently meeting the requirements recognized under EO13410, but who would also like to demonstrate meaningful use for purposes of the Centers for Medicare & Medicaid Services (CMS) Electronic Health Records Incentive Programs. Therefore, FM recommends that prior to finalizing the proposed set of standards in this interim final rule, that ONC conduct a thorough review of the entire set of standards required under EO 13410 and provide clarification and assurances that any overlapping standards or inconsistencies do not undermine the stated intent and requirements of the IFR.

[1]End User Definition: CPT data files are licensed on an individual (as opposed to concurrent) user basis. We consider an individual a CPT user if he or she directly accesses CPT data in a product or, in the case where CPT is embedded in a product and not directly accessible, relies on embedded CPT data to perform his or her intended function with the product or its output. Distribution Licenses

Nonexclusive right to use CPT material in content-added products (that is, where CPT is combined with other information). Reprinting of CPT material alone is not permitted.

Reports and payments are made semi-annually.

Royalty is $12.50 per user per product licensed. Print publication royalty is 7.5% of sales price, not less than $10 per distributed copy.

Distribution may be in print, electronic media, or over the Internet. Internet distribution requires use of certain security features.

International rights are available.

Internal Use Licenses

11 or more users (CD product) or 26 or more users (file download) at a single location, for internal use only, not for redistribution.

Royalty is $70 per legal entity plus $12.50 per user.

Licenses for internal use by 10 or fewer users can be obtained through the AMA Bookstore or by calling (800) 621-8335 to purchase the CD-ROM data file.

Licenses for internal use by up to 25 users can be obtained as immediate download of electronic CPT data file through the AMA online catalog.

[3] Dr. John Halamka comments on the patient safety issues at and . Sean Nolan, Microsoft, discusses issues with using billing diagnosis codes here:

[4] §170.205 (d) (1) (ii): Requiring providers to check insurance eligibility checked electronically for at least 80% of all unique patients seen by the EP or admitted to the eligible hospital - as specified in the NPRM - will likely increase in "phishing" . Please see the CMS Medicare rules of behavior In addition, please note that for Medicaid MITA Level III - Medicaid Agencies must implement anti-phishing logic. Provider's consistently receiving negative/not enrolled responses may trigger alarms/penalties.

[5] §170.302 (l): Medication reconciliation.Electronically complete medication reconciliation of two or more medication lists by comparing and merging into a single medication list that can be electronically displayed in real-time

[6]The State Medicaid Manual Chapter 11 Section 11281.1 D. Safeguards.--You must insure that appropriate safeguards are in place to protect the confidentiality of eligibility information. The use or disclosure of this information is restricted to purposes directly connected with the administration of the Medicaid program.

[7] Federal Register / Vol. 75, No. 8 / Wednesday, January 13, 2010 / Proposed Rules, page 1846 "In a related proposed rule, the Department will propose the development of a certification program for health IT. Specifically, we have sought to ensure that the definition of meaningful use of certified EHR technology does not require EPs and eligible hospitals to perform functionalities for which standards have not been recognized or established"

[8]Executive Order 13410 (Aug. 22, 2006, effective Aug. 28, 2006), available at see also HHS Progress Report on the Implementation of Executive Order 13410, at and Carolyn M. Clancy, M.D., Testimony before the U.S. House Energy and Commerce Committee, Subcommittee on Health (June 4, 2008),

[9] ONC IFR, at 2033.

[10]Federal Register /Vol. 73, No. 15 /Wednesday, January 23, 2008 /Notices 3973; Federal Register /Vol. 74, No. 12 /Wednesday, January 21, 2009 /Notices 3599

[11] See HITSP Summary Documents Using HL7 Continuity of Care Document (CCD) Component, Version 2.5 (July 8, 2009), at (Version 2.5 references The Clinical Document and Message Terminology Component and defines the vocabularies and terminologies utilized by HITSP specifications for Clinical Documents and Messages used to support the interoperable transmission of information).

[12] See HITSP Summary Documents Using HL7 Continuity of Care Document (CCD) Component
Version:2.5 and HITSP CDA Content Modules Component page 85 – 108

[13] ONC IFR at 2015.