HIPAA NPRM Summary

If you've been or catching up from hiding under a rock and getting back out from under after the holidays, there's a new HIPAA Security Rule out for review.  

Printed out, the newly proposed HIPAA Security Rule is about 465 pages, of which 121 are footnotes, and 38 pages are actual regulatory text, leaving 306 pages of prefatory/explanatory/justification material in front matter.  I'll skip to the rules in my first read through.

And then we get to Subpart C, which is the remainder of the HIPAA proposed rule changes.

First, the definitions get an update ...

Definitions were added for the following key terms:

• Deploy
• Implement
• Multifactor authentication
• Risk
• Technical Controls
• Vulnerability

Some definitions were clarified, but not really functionally changed from the perspective of a reasonably educated person.

• Administrative safeguards
• Information System
• Password
• Physical Safeguards
• Security or Security Measures
• Security Incident
• Workstation

With respect to "Reasonably educated", that includes neither lawyers nor regulatory pedants.  Both are over-educated and so might actually care about the improved text in HIPAA

Finally, three definitions were somewhat changed in HIPAA:

Access: Add delete, transmit, substitute "component of an information system" for "system resource"

Malicious software: Now includes "firmware" with more description of the intent or impact of the software.

Technical Safeguards: Clarified and included technical controls as a type of safeguard.

§ 164.306 Security standards

General rules is revised a bit, but mostly unchanged EXCEPT:

• (b)(2)(v) is added to require consideration effectiveness of the measure AND
• (c) requires both standards & implementation specifications and (d) drops [THIS IS A BIG CHANGE].

§ 164.308 Administrative safeguards 

is very little like its predecessor, although I imagine it includes all of the requirements of that, plus a lot more.  I'm going to do a deeper review of the changes to HIPAA 45 CFR 164.308 later.

§ 164.310 Physical Safeguards

Mostly the same, ADDED annual maintenance requirement to each standard whereby you must review & test policies & procedures at least annually.

And implementation specs for workstation use & technology assets (a.k.a., devices)

§ 164.312 Technical Safeguards

adds a lot of new content and is going to require deeper analysis.

§ 164.314 Organizational requirements

I would say this is largely unchanged except the new requirement that any time an organization activates its contingency plan it must notify the organization or group health plan it has a BAA with w/in 24 hours.

§ 164.316 Documentation requirements 

is largely unchanged but somewhat restructured.  The maintenance of documentation is strengthened from as needed to at least annually.

§ 164.318 Transition 

was previously about Compliance deadlines & remains so, but in proposed rule, the text gets more convoluted and has to do with existing renewals and deeming compliance based on existing contracts.  Get your lawyers to explain it, I'm not gonna.

§ HIPAA 164.320 Severability 

adds a clause that basically says:

If anything here is invalid or unenforceable, etc... it shall be interpreted to give the maximum effect & if necessary will be held separate so as to not affect anything else we said you gotta do.

That's the end for now on my read of changes in HIPAA.  There will be more as I must do deeper analysis on 308 and 312.

The Cures NRPM

You will be getting a lot from me this week.  I'm going to start with the first part of the Cures Rule, prereleased by ONC and I'm just going through the regulatory text, rather than all the prefatory material.  That's next on my late night reading list (1000 pages is a lot to read, this cuts it down by at least 80%).

To start off with, some 2014 related materials were removed from the rule.  Thus stuff no longer applies now, so it's not material to any discussion.

Content Standards added include:

• C-CDA Templates for Clinical Notes R1 Companion Guide
• NCPDP Script Standard Implementation Guide, Version 2017071
• 2019 QRDA Category I Hospital Quality Reporting Implementation Guide
• 2019 QRDA Category III Eligible Clinicians & Professionals Quality Reporting Implementation Guide

API Standards (what we've all been waiting for include):

1. FHIR DSTU 2
2. API Resource Collection in Health (ARCH) (more on this in a bit)
3. Argonaut Data Query 1.0
4. SMART on FHIR
5. Open Id Connect
6. FHIR STU3
7. Consent2Share profiles (I'm guessing you are wondering what this is to).

Of these, 2 and 7 had me scratching my head.  #2 is pretty straightforward, just click the link.  It's a list of FHIR profiles that need to be supported according to the NPRM.  #7 was a downright bitch to locate, though I finally did.  I suspect that if John Moehrke had been awake, he could have found it a lot faster.  This is basically an STU3 profile of the FHIR Consent resource.  #6 and 7 basically mean that ONC is allowing STU3, but ONLY for the exchange of consent information, not allowing STU3 for anything not already covered by 1-3 above.

So, how did I do in my bet? If the proposed rule becomes the final rule, I lose it, but I picked the options correctly.  I still think my bet is sound, but I'll give it a 60% chance of being the final result, with the alternative being what we saw proposed this morning.  If I'd thought about it harder, I would have known that ONC couldn't have submitted a proposal with R4 because IT HADN'T been published at the time it was submitted to OMB, which still doesn't leave it out of the running.  The proposed rule text published by ONC does contain a reference to R4 in section 170.299.  My bet (and I'll know more tomorrow) is that the industry will push for R4 and the US Core specifications.

Even if they don't, ONC's changed the rules so that they (and you) can upgrade to newer standards, so that the rule can set both a lower and upper bar.

USCDI is something we are all going to have to become more familiar with.  I took my first look at it a year ago.  It's still not much more than the CCDS and a collection of C-CDA templates.  For the most part, there's nothing challenging here, it's just work for your engineers and validation staff.

There's additional guidance in the rule on how to use CCDA (see the companion guide link in the previous section), and on how to handle Assessment and Plan, Goals, Health Concerns, and UDI (device identifiers) data in the rule.  Expect test procedures to change (I imaging those folks are starting to think about what to change, but won't really get to work until the rule is final).  However, I don't expect a big lift here.

Section D; Conditions and Maintenance of Certification for Health IT Developers is brand new content for certification.  It applies to the organizations who certify product, and how they must behave, rather than what the product must do.  To summarize:

400: This is authorized by the Cures act.

401: As a developer you will attest to ONC that you won't block.  This is a regulatory form that basically makes it possible for you to be fined under the false claims acf if you say you won't and then you are found to do so (c.f. recent news), if I'm reading this correctly.  This is powerful stuff which makes enforcement possible by more than just ONC revoking a certification, the DOJ can get involved.

402: Prove it, and furthermore, don't do what other guys did (see the last link), and make getting that single patient data export document out easy peasy, and keep your records for 10 years, and you have 2 years to handle that patient data export change.

403: What I call the "No Gag Rule" clause says that a health IT developer cannot restrict communication regarding:

1. usability,
2. interoperability,
3. security,
4. user experience,
5. business practices,
6. ways in which the product has been used.

Anything is fair game to be communicated, including proprietary, confidential or IP content when the communication is about one or more of the above for communications:

1. required by law
2. regarding patient safety, to government agencies, accreditors or patient safety organizations,
3. about privacy and security to government agencies,
4. about information blocking to government agencies,
5. about certification non-compliances to ONC, an ONC-ACB 

Restrictions are permitted to or about:

1. contractors and employees,
2. non-user facing aspects,
3. IP except that screenshots ARE permitted with certain reasonable provisions, EXCEPT for cases of premarket testing and development until the product ships, after which they are subject to prior rules

And must notify (within 6 months) and make effective (within a year) that any existing contract provisions that contravene the above are basically null and void hereafter.

404: This section requires a close read by your staff involved in revenue generation from APIs.  Basically it says you have to disclose everything needed to use them, make clear how you are charging, be fair in the way you charge, not specifically designed to be anti-competitive, not require non-compete clauses, not require exclusivity or transfer of IP rights, or require reciprocation.

There are some other clauses in here as well, regarding "allowing production use" quickly, and publishing endpoint addresses for systems "in a computable format". 

405: Just as FDA requires post-market surveillance and corrective action, ONC is now requiring ongoing testing and maintenance for certified product, requiring the developer to make a plan, share it with ONC, execute it, and report on the results.  

And you've got 2 years to upgrade your products to the new standards.

406: The developer must attest to all of the aforemented, aforesaid, thereunto appertaining stuff at the time of certification and every six months thereafter, therefore becoming subject to additional enforcement opportunities by ONC and DOJ.

I'm not going to spend much time on section 500, as it mostly pertains to the operations of ACBs, but there's some impact on Health IT Vendors here to look at in this section, mostly in that adopting section D above ONC now has a responsibility to verify that section D is being complied with.  This means that they may perform surveillance about developer behavior in addition to product behavior.

And, as a result of that surveillance, ONC may also BAN a developer from the certification program based on their behavior, giving them yet more enforcement capabilities.

Section D is going to be the hardest discussed section in the industry, but I think in generally it is fairly written (if complex).  There's definitely some work that could be done to make the language simpler and easier to read.  A lot of that may already be written in the preface (which I have yet to read, I like to get my first opinions by reading the regulations, rather than the regulatory body's justifications for them).

I'll be covering what I call the "No Blocking" part of this rule later this week, as well as the Patient Access rule released by CMS.  NOTE: I'm reading the prerelease versions that were available from ONC (and CMS) prior to publication in the Federal Register.  I'll read those versions in my second full read through, just to see if there are any significant differences.

As always, I'm not a lawyer, and this is NOT legal advice, and you get what you paid for.  This also is my own opinion (as are all posts written here), and not the opinion of my employer nor any other organization I might have some affiliation with.  

Keith

My read through tweet streams can be found by searching my stream for #CuresNPRM, #PatientAccess and #NoBlocking.

Summary of Meaningful Use Incentives Changes

I finished my review of the Meaningful Use Incentives rule. My review was focused specifically on how the measures in that rule are tied to the standards rule (which I reviewed yesterday here), and so I only had to read about 250 of the 864 pages. I specifically did not cover quality measures, or many of the administrative details.  I also do not go into detail on the percentage measure revisions, or into the quality measures.  If you are looking for other details such as these, I recommend that you read the article in the New England Journal of Medicine, John Halamka's summary, Inga (HISTalk's) summary, or many of the other summaries available on the web.

Note that page numbers in the text below are from the PDF on display and will not correspond to the page numbers when these are finally published in the Federal Register:

• Definitions of Certified EHR Technology and Qualified Electronic Health Record in this rule are the same as, and therefore reference the definitions of those terms in the Standards Rule (see Page 22).
• You can stop being a meaningful user in the middle, and resume where you left off (see page 24 through 26), up until 2015. After that, all bets are off.
• Your first reporting period is 90 days long in your first reporting year (page 28), and you start at the Stage 1 criteria for two years, then move to Stage 2 criteria (page 39). After 2014, it isn’t indicated what will be done about getting everyone to the same level of meaningful use, but that is the stated goal.
• States are not allowed to request more stringent criteria than what can be certified in Stage 1. If you are a vender of an EHR product, you should consider certifying for optional criteria, because states would be allowed to require it for Medicaid users (page 50). Even so, if a hospital is eligible under Medicare, then it is deemed to be Medicaid eligible, even if its EHR technology does not support additional state requirements (also page 50).
• The rule takes the approach that there are core measures which must be implemented by all, some core measures which must be implemented by all EPs, others which must be implemented by all Hospitals, and then a menu of other requirements of which some number are required to be implemented. Therefore, the incentives are no longer a set of all-or-nothing requirements. From an EHR product perspective, products will probably need to support more of the “menu” requirements because different users of those products will want to select different requirements from the “menu”.
• Some requirements may not be applicable to a provider. Failure to meet these requirements will not go against the providers eligibility for incentive payments. However, note that the Incentives rule indicates which requirements are permitted to be treated this way (page 61 to 62).
• The incentive eligibility has been linked to the standards rule in many places. The phrase “We further specify that in order to meet this objective and measure, [EP/Hospital/CAH] must use the capabilities Certified EHR Technology includes as specified and standards at 45 CFR 170.3XX(x).” Basically, this phrase says that to be eligible, you must use the Certified EHR Technology to meet the objective and not some other technology, and that you must do so in the way specified by the standards identified in the certification criteria.
• Because eligibility and claims are no longer certification criteria in the Standards Final Rule, they are also no longer required to be used to obtain incentive payments.
• The NPRM required tracking of “Insurance Type”. However, given that there are no established standards to identify types of insurance, the requirement to track this information for patients was removed from the Incentives rule.
• The NPRM required tracking of Race and Ethnicity. The final incentives rule clarifies that this tracking should be consistent with OMB guidance for gathering information about race and ethnicity. See yesterday’s post in the Standards rule for a link to those guidelines.
• Hospitals must capture whether or not an advance directive is available for patients over 65. This is a new requirement for the Incentives rule.
• The use of Clinical Decision Support in the NPRM required implementation of 5 rules. This was reduced to 1 rule so that implementations could focus on good implementation of clinical decision support. The description of clinical decision support has been modified to avoid bad examples.
• In cases where providers are required to either give patients data, or make it accessible online, the time frames have been altered. Instead of 2 or 4 days, they have been changed to business days (Monday through Friday excluding Federal and State holidays), and in one case, increased from 2 to 3 days (See page 161 and 175). In addition, it was indicated that it is not appropriate to charge patients for clinical summary provided for an office visit (Page 179) since that would be enabled by the Certified EHR Technology and should be of minimal expense to the provider (Hit the print button…)
• Some measures included a required test (e.g., for reporting information to public health for surveillance, immunizations or lab results; or electronic exchange of data with other providers). For these measures, the test need not include actual patient data, but could use test data. Also, the test need not be “successful”. On this, my advice would be to show appropriate due diligence in your attempts to ensure that the test passes.

Finally, my last comment is simply to reiterate in my own words what I found on page 219.

Meaningful Use will not be cancelled. It is law. The regulation implements what is already required under law. For this, I’m not sorry!

Having plowed through the regulations in two days, I have to say that the final results are much improved over the original regulation text delivered earlier this year. I am pleased with the final results, and proud to have been a participant in this regulatory process. The rules are not perfect, but they are certainly good enough to provide for dramatic improvements in healthcare.

Certification NRPM Comments

I started reading the Certification NPRM this morning around 10:00. The first thing I did was bookmark the rule, which you can find here. I finished that around 10:50. It's now 11:40 and I'm done reading the regulation text starting on page 146 of the NPRM. I can see the fingerprints of NIST on this document. It is remarkably clear and I have only a few comments on the entire proposed rule:

1. Kudus to the government for using standards! The new rule uses international standards: ISO/IEC Guide 65:1996 (General requirements for bodies operating product certification systems) and ISO/IEC 17025:2005 (General requirements for the competence of testing and calibration laboratories) to describe the requirements of certification and testing organizations. But shouldn't these documents be incorporated into the rule by reference along with the location where they can be obtained?

2. As proposed, the sunset of the temporary certification program begins as soon as the first permanent certification body is announced by ONC. I would prefer to see a set end date for the temporary certification program. Deadlines produce results, and a clear end date would provide incentives for organizations to be ready for the permanent program.

3. I'm not terribly sure about the value of two accreditation process, one for testing bodies and the other for certification bodies. I understand the disctinction between testing and certification, but wonder if it is necessary to have two separate accredited bodies as part of the certification process. There is a great deal of overlap in the requirements to be accredited for either and an expectation that at least some organizations will do both. It seems as if having two accrediting processes could increase certification costs without providing much additional value.

4. This is really just a minor nit: In two places the rule talks about the effect of revocation of status for a certifying body on the certifications that it issued. This can be found in sections §170.470 and §170.570, both titled: Effect of revocation on the certifications issued to complete EHRs and EHR modules. I'd like to see text in the rule that says that if a certification is called into question that the orginization whose recieved it is entitled to a refund of fees paid for certification. After all, if you paid for something and got a defective item, you should be entitled to get your money back.

5. NVLAP (National Voluntary Laboratory Accreditation Program) is never defined or expanded in the regulation text itself.

This is one I'm not going to worry about.  If the rule goes final as written, I'll still be happy with it.  Thanks again NIST!

P.S.  NIST is publishing the test methods that are cited in the NPRM and is seeking public comment on those also.  Take a look at the first wave.
P.P.S.  The PDF I bookmarked was the "corrected" rule that Brian Ahier mentions on his blog.
P.P.P.S.  Updated to fix broken links.

Meaningful Use NPRM Comments

As promised, I've been reviewing the Meaningful Use NPRM.  Below you can find some of my comments as this proposed rule relates to the use of certified EHR technology and the Meaningful Use IFR.  In the following, Roman text is quoted from the NPRM.  Text in Italics are my comments on it.  In this review I have only focused on issues of clinical content used to meet the objectives, and the measures of them, and the relationship of the NPRM to the IFR.  I have not addressed any issues related to payment, schedules, et cetera.

§495.6 Meaningful use objectives and measures for EPs, eligible hospitals, and CAHs.
(c) Stage 1 criteria for EPs and eligible hospitals or CAHs.
On each of the Measure sections of this part the text "of all unique patients seen by the EP or admitted to an eligible hospital or CAH" should be amended to include "during the EHR Reporting period". This applies to sections (c)(2)(ii), (c)(3)(ii), (c)(4)(ii), (c)(5)(ii), (c)(7)(ii), (c)(11)(ii), (c)(13)(ii) and (c)(14)(ii).  This is a minor but necessary clarification.  I don't believe that HHS intended for
the measure criteria to include all patients ever seen by an EP, eligible hospital or CAH, but it doesn't explicitely state the reporting period in the measures.

(5)(i) Objective.
(A) Preferred language.
(B) Insurance type.
(C) Gender.
(D) Race.
(E) Ethnicity.
(F) Date of birth.
(G) For eligible hospitals or CAHs, the date and cause of death in the event of mortality.
Subpart (5)(i)(B) should indicate what is meant by Insurance Type.  There are several vocabularies used to describe insurers, including those found in the 4010 and 5010 implementation guides from X12N and others found in HL7.  At the very minumum, we need to know what distinctions are important here.
Subpart (5)(i)(D) and (E) should reference OMB Guidance on the reporting of Race and Ethnicity.  It will not be helpful to report race and ethnicity if everyone does it differently and cannot role up to the OMB categories.


(5)(ii) Measure. At least 80 percent of all unique patients seen by the EP or admitted to the eligible hospital or CAH have the demographics specified in paragraphs (c)(5)(i)(A) through (G) of this section recorded as
structured data.
This section should be amended to state 'recorded as structured data or an indication that the patient declined to provide this information or does no know it.'  This change is needed because under OMB guidance and as elsewhere defined in healthcare standards (e.g., HL7), Race and Ethnicity are self declared by the person being so classified, and such classification should be voluntary.

(c)(6)(i) Objective.
(1) Height.
(2) Weight.
(3) Blood pressure.
(B) Calculate and display the body mass index (BMI) for patients 2 years and older.
(C) Plot and display growth charts for children 2 to 20 years including body mass index.
(ii) Measure. For at least 80 percent of all unique patients age 2 years or older seen by the EP or admitted to the eligible hospital, record blood pressure and BMI and plot the growth chart for children age 2 to 20 years old.
The measure in subpart (6)(ii) requires the recording of BMI, not height and weight.  However, BMI can be dynamically computed from Height and Weight as recognized in subpart (B), and the latter two have other clinical uses (e.g., weight based dosing).  I would recommend that the measure be altered to replace BMI with height and weight.  This measure would then be aligned with 42 CFR §170.302 (e) Record and chart vital signs found in the IFR, which indicates that a system should "..electronically record, modify, and retrieve a patient’s vital signs including, at a minimum, the height, weight, blood pressure, temperature, and pulse."

Also in 42 CFR §170.302 (e) (3) "Plot and display growth charts. Plot and electronically display, upon request, growth charts for patients 2-20 years old.", but (6)(ii) Requires that the growth chart be plotted for children age 2 to 20 years old.  In this case, the NPRM should be altered to state that the EP, eligible hospital or CAH has enabled functionality to plot a growth chart for children age 2 to 20 years old.

Why?  While an annual review of the patients BMI should be performed, it should not be made necessary for every visit made by the patient.  It may not be relevant for the condition for which the
patient is being treated (e.g., a referral to an ENT for an ear infection), and would require providers to engage in additional activitity in order to be a meaningful user without a specific medical benefit to the patient.

The modified section (6)(ii) appears as I suggest rewording it below:
(6)(ii) Measure. (A) For at least 80 percent of all unique patients age 2 years or older seen by the EP or admitted to the eligible hospital, record blood pressure, height and weight.and BMI and
(B) The EP, eligible hospital or CAH has enabled functionality to plot a growth chart for children age 2 to 20 years old.


(d) Additional Stage 1 criteria for EPs.
Under this section, several references are made to use of certified EHR technology to report, transmit or provide information.  However, these transmissions can be performed in a number of ways, only a few of which conform to use of the standards selected by the Meaningful Use IFR and which would be required for certification.  For example, prescriptions could be ordered by the certified product using FAX technology rather than use of the selected NCPDP SCRIPT standard.  I would like to see
clarification made to these sections to be clear what form of report, transmission or provision of this information is acceptable. 

(4)(i) Objective. Send reminders to patients per patient preference for preventive/follow-up care.
(ii) Measure. Reminder sent to at least 50 percent of all unique patients seen by the EP that are 50 years of age and over.
The objective and measure are not coordinated.  There are a number of reminders (e.g.,
immunization) that are appropriate for patients under 50 years of age.  I would recommend removing the age constraint on the measure.  Yes, this will increase the burden on providers to remind
patients of necessary treatment, but to counter that, I would suggest that the percent be reduced to 25% of all unique patients to compensate.


(5)(i) Objective. Provide patients with an electronic copy of their health information (including diagnostic test results, problem list, medication lists, and allergies) upon request.
(ii) Measure. At least 80 percent of all patient requests for an electronic copy of their health information are provided it within 48 hours.
(6)(i) Objective. Provide patients with timely electronic access to their health information (including diagnostic test results, problem list, medication lists, and allergies) within 96 hours of the information being available to the EP.
(ii) Measure. At least 10 percent of all unique patients seen by the EP are provided timely electronic access to their health information.
I happen to like this one, as it basically gives patients the right to electronic access to their information without some of the rigamarole I've had to go through in the past.  However, these two basically state the similar things, with two different measures of performance.  I would remove one of these and alter the other to include the requirements of the first.  For example:
(6)(i) Objective. Provide patients with timely electronic access to their health information (including diagnostic test results, problem list, medication lists, and allergies) upon request within 96 hours of the information being available to the EP.
(ii) Measure. At least 80 percent of all patient requests for an electronic copy of their health information are provided it within 96 hours of the information being available to the EP.

This restatement also eliminates the issue of having to rely on patient participation to be seen as a meaningful user, as would be the case in the existing measure under (6)(ii).


(8)(i) Objective. Capability to exchange key clinical information among providers of care and patient authorized entities electronically.
(ii) Measure. Perform at least one test of certified EHR technology's capacity to electronically exchange key clinical information.
As noted under my comments on the Meaningful use IFR, the capability to communicate key
clinical information crosses the boundaries of provider type, and so this requirement should be moved up to section (c).  All provider types should be able to recieve key information regardless of the provider type that communicated it.  Definitions of "key information" produced by a provider type might be retained under section (d) and section (e) and referenced in section (c).

(e) Additional Stage 1 criteria for eligible hospitals or CAHs.
Under this section, several references are made to transmit or provide information, or to report "in the form and manner specified by CMS." However, these transmissions can be performed in a number of ways, only a few of which conform to use of the standards selected by the Meaningful Use IFR and which would be required for certification. I would like to see clarification made to these sections to be clear what form of report, transmission or provision of this information is acceptable and ensure that it is aligned with the standards selection (e.g., PQRI).


(3)(i) Objective. Provide patients with an electronic copy of their health information (including diagnostic test results, problem list, medication lists, allergies, discharge summary, and procedures), upon request.
(ii) Measure. At least 80 percent of all patient requests for an electronic copy of their health information are provided it within 48 hours
(4)(i) Objective. Provide patients with an electronic copy of their discharge instructions and procedures at time of discharge, upon request.
(ii) Measure. At least 80 percent of all patients who are discharged from an eligible hospital or CAH and who request an electronic copy of their discharge instructions and procedures are provided it.
Again I like these, but there are repetetive and can be combined.  I would merge them into one
requirement:
(3)(i) Objective. Provide patients with an electronic copy of their health information (including diagnostic test results, problem list, medication lists, allergies, discharge summary, discharge instructions and procedures), upon request.
(ii) Measure. At least 80 percent of all patient requests for an electronic copy of their health information are provided it within 48 hours (5)(i) Objective. Capability to exchange key clinical information (for example, discharge summary, procedures, problem list, medication list, allergies, and
diagnostic test results) among providers of care and patient-authorized entities electronically.

§495.332 State Medicaid (HIT) plan requirements.
    ...
(f) Optional--proposed alternatives. A State may choose to propose any of the following, but they must be included as an element in the State Medicaid HIT Plan for review and approval:
    ...
(2) (i) Additional requirements for qualifying a Medicaid provider as a meaningful user of certified EHR technology consistent with §495.4 and §495.316(e) of this part.
(ii) A State may propose additional meaningful use objectives beyond the Federal standards at §495.6, if they do not require additional functionality beyond that of certified electronic health record technology. See also §495.316(e).
§495.8 Demonstration of meaningful use criteria.

(a) Demonstration by EPs. An EP must demonstrate that he or she satisfies each of the applicable objectives and associated measures under §495.6 of this subpart as follows:
(1) For CY 2011,
(iii) For Medicaid EPs, if, in accordance with §495.316 and §495.332, CMS has approved a State's additional criteria for meaningful use, demonstrate meeting such criteria using the method approved by CMS.
I'm not particularly in favor of adopting standards only to allow them to be altered or modified so that we wind up with 56 different requirements across the country.  While the States need to have input in how they deal with Medicaid recipients, the altering of meaningful use criteria on a state-by-state level will not be beneficial to patients or providers country wide.  I'd like to see more clarity made in §495.332 that functionality includes the selected standards.  For example, functionally the electronic transmission of prescriptions could be performed using standards other than the selected standard in the IFR.

More files for NPRM and IFR Reviewers

Robin Rainford's been at it again.  This time she's taken the tables from both the IFR and the NPRM and put them into spreadsheets so that every vendor and provider in the country is not going insane doing the same thing.  In the spirit of sharing hours of work that we are trying to achieve, Robin asked me to share these with you.  Happy requirements review from the both of us.

• NPRM Tables 
• IFR Tables 

   Keith

P.S.  If you missed previous announcements, their are also bookmarked versions of the IFR and NPRM available.

Bookmarked IFR

Inspired by Robin Rainford of Eclypsis who bookmarked the NPRM for Meaningful Use, I have bookmarked the Interim Final Rule on Standards and am sharing it here:  http://bit.ly/4tZQz5 

I'm sure she could have done it better and faster, as she's a champ at these sorts of things.  Oh, and if you don't have her bookmarked NPRM, you can find that here http://mycourses.med.harvard.edu/ec_res/nt/3E57FAE4-A6AB-4CA8-AF6B-FAB1537595A4/nprm.pdf where John Halamka uploaded it for all.

Meaningful Use IFR Comments

Like just about everyone else I know involved in healthcare in the US, I've been reviewing the IFR and the NPRM. As you can imagine, I have quite a few comments on the IFR that I'd like to share. 

The IFR seems to be a very realistic and pragmatic approach.  That part of it appeals to the pragmatist in me, but there are other parts that are disconcerting.  Given the state of the industry, this IFR can work, however, as a taxpayer, I really wish the IFR was making better use of the incentives that are being provided.  I'm also an optimist, and I may be too optimistic in my hopes that we can move faster -- time will tell.

The IFR represents a state of EMR use that is just a little bit more than the status quo for organizations that have already implemented an electronic medical record system. While the EHR industry itself seems ready for more than what's been specified, it appears that ONC expects that deployed systems are not. If you look at the adoption numbers for EMR systems, this seems to be reasonable. Providers are still somewhere in the 10-25% range for adoption depending on whose statistics you look at and what markets you are focused upon.  The adoption rate has also increased quite a bit in the last few years (though not as much in the last year I expect).  That means that there are a lot of providers out there with relatively recent EMR implementations that may not be completely ready for meaningful use.  Many will need to have new interfaces implemented to support the IFR.  Given the low bar that has been set, it appears that upgrades might be able to be avoided for many providers with existing systems.  Providers may want to upgrade anyway to get better implementations of the standards that have been selected by the IFR.

What is most disappointing are some mistakes made in the regulation with regard to the capabilities of the standards, and some factual misstatements in the prefatory material.  I understand how difficult it is to write 136 pages of complex text in 3 months, but the key to avoiding them is in following the standards activities.  Many of the issues I identify below have been discussed in great detail here, in SDO discussions, HITSP discussions and in discussions with NHIN work groups, and I believe could have been avoided if there had been more direct ONC participation in harmonization efforts.  I hope this will be addressed in the future.

I won't provide comments here on the prefatory material in the Interim Final Rule, as that material is not itself the regulation.  What follows are some of my observations about the IFR.

§170.202 Transport standards for exchanging electronic health information.
If you want to find the SOAP 1.2 standard, please look on the W3C web site and not the OASIS web site.With all of the discussion of SOAP vs. REST that has been going on in the HIT Standards and Policy Committees, I would expect ONC to demonstrate a better understanding of these standards in the IFR.

Also, with regard to REST, does ONC really mean to suggest that any transport that uses a RESTful approach should be supported?  REST is an architectural approach that can work with HTTP, FTP and SMTP (ever used subscription commands with a mailing list server? That's RESTful). Most RESTful architectures use HTTP as their transport standard.  I would suggest that intention was to use HTTP in a RESTful manner and would hope that they clarify the in the final rule that HTTP is the other transport standard.

§170.205 Content exchange and vocabulary standards for exchanging electronic health information.
(a)(1)

The IFR defines both "Implementation Specifications" and "Standards".  But the IFR adopts an Implementation Guide as a standard.  I would hope that IFR acknowledges the CDA Standard as well as the CCD Implementation Specification.

The magic of the AND in the IFR is a perpetuation of the un-harmonized use of standards in the industry that we've been trying to move away from since about 2006.  We must support two standards, and then make one of them go away in two years.  I really don't have any concern about a competition between the selected standards, because I believe the best one will win.  What I am concerned about is that the IFR makes no choice now, and thus incentives are A) not supporting movement in the industry, and B) supporting duplicated effort the costs of which will be borne by providers.  I don't think this was the point of choosing standards in the first place.



(a)(2)(iv)  and (c)(2)
While we'd like everyone to use RxNORM eventually, the IFR itself selects the vocabularies that went into it but not RxNORM itself.  I believe this is just an oversight and hope that it too is corrected in the final rule.

§170.210 Standards for health information technology to protect electronic health information created, maintained, and exchanged.
(a)(1) I was able to find at least 10 symmetric 128 bit fixed block ciphers capable of using a 128, 192, or 256 bit encryption key.  That's not sufficient identification of a standard, and as John Moehrke points out in his blog, could allow XOR with a fixed encryption key which is extremely insecure (it can be broken in seconds).  Most of the cipher algorithms have notable defects and several were NOT chosen as the replacement for DES because of those defects.  Couldn't we just say "AES", or better yet, "a FIPS 140-2 approved cipher function" (see Annex A of FIPS 140-2).  This might provide an incentive for some vendors to support AES in versions of their IT products installed at healthcare institutions today.  Furthermore, it would also support other suitably secure ciphers readily available by providers for communication and storage (e.g., via VPN, TLS and through disk encryption).



(b) This is just a minor nit.  With regard to SHA-1 or higher, I'd prefer that they list out the specifics (SHA-1 or SHA-2 family).  SHA-3 is currently under development and is expected in 2012, but do we want to identify something that doesn't exist yet?  There should be sufficient time to change the regulation to adopt SHA-3 when it becomes readily available (which will be a couple of years after it gets selected).



§170.299 Incorporation by reference.
(c)(3) The title of the HL7 CCD does not contain the words "Level 2".  That's a concept found in the CDA Standard.  Inclusion of this term could imply that "Level 3" is prohibited, but that would be counterproductive given other requirements of the IFR (e.g., medication reconciliation) which would seem to require it.



§170.302 General certification criteria for Complete EHRs or EHR Modules.
I find the text which appears in multiple locations following this structure to be confusing to read.
At a minimum, the version of the standard specified in §170.###(a)(#)(i)(A).
It should be altered to read:
The standard specified in §170.###(a)(#)(i)(A) or a later version of that standard.
It means the same thing and is easier to understand.


(j) Check insurance Eligibility and (k) Submit Claims
These two functions are more often found in what the industry calls "practice management" or "revenue cycle management" systems rather than EHR systems.  I agree with the selected standards, but wonder whether conflating these systems together with the EHR is useful.

The text found in §170.306 (d) regarding Electronic copies of healthcare information should be moved up to §170.302 and altered slightly.  First of all, the need to be able to view discharge summaries is much more frequent in ambulatory settings where followup care is performed, than in inpatient settings, where one would hope the patient wouldn't wide up again, so both ambulatory and inpatient settings need to be able to view the discharge summary.  

§170.306 Specific certification criteria for Complete EHRs or EHR Modules designed for an inpatient setting.(d) This text talks about exchanging diagnostic test results, problem list, medication list, medication allergy list, immunizations, procedures and discharge summaries in a CCD.  

I've said in the past (see If I had a Hammer) , repeatedly that neither the CCR nor the CCD contain appropriate sections for discharge summaries.  These are ancillary documents that can be referenced by the CCD or CCR, but should not be incorporated into it as a whole document for several reasons.

1. The discharge summary is a separate report required by accreditation agencies of inpatient hospitals
   
2. It contains information duplicated (problems, meds, allergies, procedures, et cetera, ) in the standards identified in §170.205(a)(1) of the IFR (CCD and CCR).
3. But there is no place in the CCR (or the CCD) for a "complete" discharge summary.  These are transmitted in both as references to other docuements.
   
4. The discharge summary also contains important information for which there is no real place in the CCR (and thus the CCD).  For example, the discharge summary contains Admission and Discharge Diagnoses, and Hospital Course.  You could put the Admission and Discharge diagnoses in the problem list, but you would have no way to identify them as such, and that could be confusing and might result in patient safety issues if the Admission DX which was changed at Discharge to something else (e.g., from Heart Attack to Ulcer).  Not having a place to put Hospital Course misses much of the detail of the Discharge Summary.
   
5. Presently, it is often available as text, which would make it suitable for transmission using CDA, but not CCD.

This post is already long enough, so I'll comment later on the NPRM.  

As always, the comments that I make upon this blog reflect my own opinions and not necessarily that of my employer.