IHE Week and FDA announces mHealth regulatory approach

Another IHE Week, this time preparing Trial Implementation Profiles. I'm on the hook for Reconciliation, and we have another couple dozen comments to go.  One of the surprising responses from commenters is that the profile should REQUIRE that external identifiers for problems, medications and allergies be preserved.  That is going to result in a quite a bit of new text (now I have to explain what changes the identity of an entry).  I'm pleased with this response.  We made it a strong recommendation, but not a requirement because I felt that many EHR vendors would not implement the profile if it were required.  Most systems would need to alter their basic tables to record the external identifier.  But experience with prior implementations indicates that this really is the best way to handle it, and I certainly agree with the sentiment.

I spent a good bit of time with IT Infrastructure on Monday discussing Cross Enterprise Document Workflow (pdf).  This profile is critical for Patient Care Coordination, even though it is coming out of IT Infrastructure.  Here's a brief pitch I'm giving on it tomorrow for another group:

• In Ambulatory Care, providers are desperate for Workflow Management to track referrals, orders, and manage quality of care.
• But their workflows are loosely coupled and ill-defined.
• These need to integrate with well defined, tightly coupled workflows in a departmental system (e.g., imaging).
• XDW uses industry workflow standards to describe Human Tasks that can be well integrated across both settings.

The replacement of CDA with Human Task as the standard to manage the tasks is more than appropriate, and @rjhorniii has done a great job leading the discussion, and getting me and one of my colleagues to agree on an approach.  You can expect some significant changes to the public comment version to come out of this meeting.

---

While at the meeting, the FDA came out with a proposed regulatory approach for mHealth devices and applications.  I haven't had a change to do more than skim it once.  I'll look over it in greater detail later.  One of the tweople I follow expressed surprise at the exclusion of Mobile devices being used as an EHR.  His interpretation was that EHRs were not medical devices.  In case you are curious, they also excluded EHRs from the Medical Device Data System rule.  It's not that EHRs aren't medical devices.  It's that FDA carefully classifies things so that something doesn't fall into competing classifications.  They may be issuing separate guidance on EHR systems, so they exclude anything that can be viewed as an EHR from the other rules and guidelines.  That way, when the EHR rule comes out, it will be clear WHICH regulations and procedures apply.

Antonyms and Meaningful Use

Andrew asks: "What is the difference in the content to be included in the 'clinical summary' for each visit, in contrast to the 'Electronic Copy of Health Information'?  And goes on to suggest that: "Both of these items require either the CCR or HITSP/C32. Some of us agree they are to contain the same data as it is a summary of that point in time and the phrase 'for each visit' is not relevant."

There are two places to look for details on this information:

1. 45 CFR Part 170 Meaningful Use Standards Final Rule
2. 42 CFR Parts 412, 413, 422, and 495 Meaningful Use Incentives Final Rule  

The Standards Final Rule will tell you what a Certified EHR Product must do.  The Incentives Final Rule wil;l tell you what an EP or Hospital must do when exchanging information.

To keep your customers happy, an EHR product needs to be able to support what is required for certification, as well as what is required for a provider to obtain incentive payments.

Page 158 of the Incentives Final Rule describes what is meant by "Electronic Copy of Health Information".  The following is taken from the PDF of the display text for that rule [emphasis mine].

Comment: Commenters requested clarification of the term “health information” or alternatively a list of elements required to satisfy the objective.


Response: Subject to the withholding described above, an EP, eligible hospital, or CAH should provide a patient with all of the health information they have available electronically. At a minimum, this would include the elements listed in the ONC final rule at 45 CFR 170.304(f) for EPs and 45 CFR 170.306 (d) for eligible hospitals and CAHs as required for EHR technology to become certified.

Just for reference I'll include the referenced sections from 45 CFR 170.304(f) and 170.306(d) from the Standards final Rule below [emphasis mine]:

§170.304(f) Electronic copy of health information. Enable a user to create an electronic copy of a patient’s clinical information, including, at a minimum, diagnostic test results, problem list, medication list, and medication allergy list in:


(1) Human readable format; and
(2) On electronic media or through some other electronic means in accordance with:
(i) The standard (and applicable implementation specifications) specified in §170.205(a)(1) or §170.205(a)(2); and (ii) For the following data elements the applicable standard must be used: (A) Problems. The standard specified in §170.207(a)(1) or, at a minimum, the version of the standard specified in §170.207(a)(2); (B) Laboratory test results. At a minimum, the version of the standard specified in §170.207(c); and (C) Medications. The standard specified in §170.207(d).

§170.306(d)

(1) Enable a user to create an electronic copy of a patient’s clinical information, including, at a minimum, diagnostic test results, problem list, medication list, medication allergy list, and procedures:
(i) In human readable format; and
(ii) On electronic media or through some other electronic means in accordance with:

(A) The standard (and applicable implementation specifications) specified in §170.205(a)(1) or §170.205(a)(2); and
(B) For the following data elements the applicable standard must be used: (1) Problems. The standard specified in §170.207(a)(1) or, at a minimum, the version of the standard specified in §170.207(a)(2); (2) Procedures. The standard specified in §170.207(b)(1) or §170.207(b)(2); (3) Laboratory test results. At a minimum, the version of the standard specified in §170.207(c); and (4) Medications. The standard specified in §170.207(d).


(2) Enable a user to create an electronic copy of a patient’s discharge summary in human readable format and on electronic media or through some other electronic means.

And just in case you were wondering, §170.205(a)(1) references CCD and HITSP C32 and §170.205(a)(2) references CCR.  §170.207 contains the vocabulary standards and is not relevant to THIS discussion.

Looking closely at the objectives being referenced for Eligible Providers [emphasis mine]:

[pp 769] (d) Stage 1 core criteria for EPs. An EP must satisfy the following objectives and associated measures, except those objectives and associated measures for which an EP qualifies for an exclusion under paragraph (a)(2) of this section specified in this paragraph :

           ...
[pp 772] (12)(i) Objective. Provide patients with an electronic copy of their health information (including diagnostics test results, problem list, medication lists, medication allergies) upon request.
(ii) Measure. Subject to paragraph (c) of this section, more than 50 percent of all patients who request an electronic copy of their health information are provided it within 3 business days.
(iii) Exclusion in accordance with paragraph (a)(2) of this section. Any EP that has no requests from patients or their agents for an electronic copy of patient health information during the EHR reporting period.

And for Eligible Hospitals or CAHs [emphasis mine]:

[pp 777] (f) Stage 1 core criteria for eligible hospitals or CAHs. An eligible hospital or CAH must meet the following objectives and associated measures except those objectives and associated measures for which an eligible hospital or CAH qualifies for a paragraph (b)(2) of this section exclusion specified in this paragraph:
      ...
[pp 780] (11)(i) Objective. Provide patients with an electronic copy of their health information (including diagnostic test results, problem list, medication lists, medication allergies, discharge summary, procedures), upon request.
(ii) Measure. Subject to paragraph (c) of this section, more than 50 percent of all patients of the inpatient or emergency departments of the eligible hospital or CAH (POS 21 or 23) who request an electronic copy of their health information are provided it within 3 business days.
(iii) Exclusion in accordance with paragraph (b)(2) of this section. Any eligible hospital or CAH that has no requests from patients or their agents for an electronic copy of patient health information during the EHR reporting period.

Problem, medication and allergy lists can certainly be provided in the HITSP C32 (or the CCR), as can summary information on test results and procedures.  Discharge summaries are another story, which long-time readers of this blog already understand.  ONC did finally get the memo (I was one of the "few commenters"), because the Standards Final Rule has this commentary starting on page 167:

Comments. A few commenters noted that neither the CCD nor CCR contain an applicable section for discharge summary. One commenter recommended that because the provision of an electronic copy of discharge instructions was required by another certification criterion, that discharge instructions should be removed as an element in this electronic copy.


Response. We reviewed commenters’ concerns and agree that there is no applicable section for a discharge summary. Therefore, we have revised this certification criterion to reflect that while the other data elements can be conveyed using the patient summary record standards (CCR or CCD), we are not requiring the use of any standards for the discharge summary section. In order to support the meaningful use objective and measure, however, we note that we do expect Certified EHR Technology to be capable of providing a electronic copy of a discharge summary like a patient summary record, in human readable format and on electronic media or through some other electronic means.


Other electronic means could include, for example, the discharge summary represented as a CCD plus the "Hospital Course" CDA section or provided as a PDF. We have revised the certification criterion accordingly.

So, how does this help answer Andrew's question?

To be certified for an inpatient setting, you need to be able to support the rule under §170.306(d)(2) as well §170.306(d)(1), which means that you need to be able to support exchange of Discharge Summaries.  You probably know my views on that, but if you don't read If I had a Hammer and the Redux which report them.

That means that the difference between a "Clinical Summary" and "Health Information" includes at least the Discharge Summary for EHRs in an inpatient setting.  For ambulatory settings, the difference is still vague.  It seems as if you could use the Clinincal Summary to support the requirements for certification for both Clinical Summaries and Health Information.  BUT:  From my perspective, I'd also expect to get the rest of the ORIGINAL test reports in human readable form, which would include Imaging or other study reports, and lab test results.

Why?  Because summaries are just that, and for my PERSONAL health records, I want not just summaries, but also DETAILS.  I suspect that other patients will feel the same way, and that Eligible Providers will want to provide their patients with details.  The details of an ECG report, lab report, or other test result or procedure just don't belong in a summary document.  

From my viewpoint, the antonym of summary is detail, and visa versa.

So, if you want to get away with the minimum for meaningful use for ambulatory care, you can probably just send the summary.  But to be really meaningful to your customers and their patients, you'll have to do better than that.

    Keith

DISCLAIMER: I am neither a lawyer, nor a representative of CMS or ONC.  These are my personal opinions about the wording in these regulations.  I would advise you to obtain your own expert legal advice before acting on the information reported above.  You assume any of the risks in using these opinions for decision making.

Net Neutrality in Healthcare

Net Neutrality is a topic that is heating up the interwebs.  Just Bing It (Google not being an impartial observer of trends here), or read this report from the Guardian.  Just a wee bit of thought and some recent experiences dealing with limited access due to my cell-phone carrier makes it pretty clear to me that I'm very much in favor of Net Neutrality.

The sheer audacity of Google to propose that: "Fourth, because of the confusion about the FCC’s authority following the Comcast court decision, our proposal spells out the FCC’s role and authority in the broadband space" has me flabbergasted.  I'd love to be in the position to tell a federal agency what to do or how to do it (and do quite a bit), and so would every other company in this country.   But I also expect regulators to take me with a grain of salt, and I expect them to take Google even less seriously than that.  Quite honestly, I feel much better about the FCC as a regulator than I do about the industry if Google and Verizon's response is any indication of what I'd get from the latter.

The "wireless/innovation" argument simply doesn't fly for me.  We've got more bandwidth and power today with cellphone/wireless than I had ten years ago with wired at home.  And, I know what can be done with that much bandwidth.  Wireless innovators have enough bandwidth to play with, without giving preferential treatment to anyone.

Favoring one content provider over another isn't the kind of "innovation" that I want.  Could you imagine not being able to effectively access your health records online because they are "second tier" content?  Would you like it if your wireless provider favored FOX or NPR for news content? 

I don't want my healthcare content impeded artificially in any way through the web.  I want my family, my healthcare providers, and my customers to have the same level of access to that content.

IHE Profiles Support Meaningful Use

An alum at Florida State University asked for this one.  Essentially, he wanted to know if it was possible to map the Meaningful use requirements into specific IHE profiles.  I had developed four slides on this which were presented at the HIMSS 2010 Annual Conference during the IHE PCC Domain update in the IHE Interoperability Showcase booth.  These were based on an evaluation of the IHE PCC Perinatal Workflow profile that I discussed earlier this year.  Here is a map from the meaningful use requirements from the Interim Final Rule on Standards (§170) and the Notice of Proposed Rulemaking on Incentives (§495) to various IHE profiles.


Standards

• §170.202(a) Transport – XDS.b uses SOAP 1.2
• §170.205(a) Patient Summary Record – CCD and SNOMED CT®
• §170.205(f) Laboratory Orders and Results – HL7 2.5.1 and LOINC®
• §170.210(a) Encryption – ATNA uses AES and TLS

Certification Criteria

• §170.302(a) Drug checks – Request for Clinical Guidance
• §170.302(b-d) Maintain Problem, Medication and Allergy Lists
• §170.302(r) Audit Logs – ATNA requires Audit
• §170.302(s) Integrity – ATNA and XDS.b use SHA-1
• §170.302(t) Authentication – ATNA requires authentication
• §170.304(a) CPOE – Order Placer/Order Fillers for Imaging and Labs
• §170.304(c) Demographics – PIX and PDQ Support Required Data
• §170.304(d) Clinical Decision Support – Request for Clinical Guidance
• §170.304(f-i) Electronic Access – XPHR/CCD, XDS-MS, XDS.b and XDM

§495.6(c) Stage 1 Criteria

• (1) Drug Checks – Request for Clinical Guidance (RCG)
• (2) Problem List – XPHR Requires Problems, Supports SNOMED CT® or ICD-9-CM
• (3) Medication List – XPHR Requires Medications, Supports RxNORM and other vocabularies
• (4) Allergy List – XPHR requires Allergies
• (5) Patient Demographics – PIX/PDQ
• (6) Vital Signs – XPHR requires Vital Signs
• (8) Clinical Lab Tests – XD-LAB and HL7 V2.5.1
• (10) Decision Support – Request for Clinical Guidance
• (12) Medication Reconciliation – Built in all PCC Discharge Summaries
• (14) Summary Record – XPHR

§495.6(d) Stage 1 Criteria for Eligible Providers

• (1) CPOE – Order Placer/Order Fillers for Imaging (SWF) and Labs (LTW)
• XPHR, XDS-MS, XDS.b and XDM support:
• (5) Electronic Copies
• (6) Timely Access
• (7) Clinical Summaries
• (8) Exchange of Key Clinical Information

§495.6(e) Stage 1 Criteria for Hospitals

• (1) CPOE – Order Placer/Order Fillers for Imaging and Labs
• XPHR, XDS-MS, XDS.b and XDM support:
• (3) Electronic Copies
• (4) Discharge Summaries including Procedures and Instructions
• (5) Exchange of Key Clinical Information

The Perinatal Workflow Profile developed by the Patient Care Coordination domain brings all of these profiles together into a collection of actors and transactions that support many of the meaningful use requirements.  This profile is currently available for public comment.

IFR vs IDE

I'm still playing catch up from being away from the office for two weeks, so today's post comes late and is a little disjoint.  Recently I had a very good experience with standards that I'd like to share.  The other day, an old computer I inherited suffered a terminal power supply failure, but I needed to get data off it's hard drive.  I bought an external drive enclosure and plugged my drive it into the Standard EIDE connector, checked the very nicely labeled jumper connections on the drive, and installed it into the enclosure.  The enclosure contains a very nice little gadget that bridged between the EIDE connector of the drive to a USB connection.  I plugged the drive into the USB connection and my home laptop recognized it nearly immediately.  I was able to use some diagnostic tools to fix the partition corruption and will later offload the files we wanted.

Now, a USB connection has 4 connectors, two for power and two for signal.  An EIDE connected is one of those big wide things that uses ribbon cables.  One transmits data in parallel and the other serially.  There's also a lot of details about interrupts, addressing, and other stuff on the EIDE connector that all gets serialized in USB communications.  Fortunately for me, theres a nice little simple-minded piece of hardware that goes from the EIDE connector to the USB connector.  It is very simple minded because these two standards (and the USB standard for media) are very well specified.  The most perplexing thing would have been the drive jumpers but those were also very well labeled and the instructions on the enclosure were very clear.  The way they operate is very different, but the functionality is the same, and bridging between the two nearly painless and VERY inexpensive.  This is interoperability at its best.

On the flip side, when we look at doing something that should seem very simple (connecting an interface), it can take quite a bit longer.  You'd think that all you need to do there is hook up a network cable, enter an internet address (and port), install a few certificates, and be done.  In fact, to achieve interoperability at the transport level, that is all you need to do and I can train someone to do repeatedly and well in less than an hour.  It's the other issues that take up all the time.  What is the format of the data? What has to be there? What should be there? Et cetera.  What are the policies that surround the use of the interface? And on and on.

What I realized from this experience is that SOAP vs REST is a pointless discussion SO LONG AS THE FUNCTIONALITY IS IDENTICAL where it matters (I remain unconvinced, but lets ignore that for now).

1.  Transport is easy, and if functionally two transports are the same, bridging between them is also easy (and cheap).  SOAP, REST, I really don't care.
2.  Deciding on content to exchange is hard.
3.  Crisp documentation is a big help.

That hard drive?  The hardest thing about making it work again was selecting the appropriate content format to exchange.  Fortunately for me, there were only 18 choices for the file system format, and I knew exactly which one would work for my situation, and for other things, the crisp documentation was really valuable.  For healthcare content exchanges, there might be 18 choices for the first item you need to decide, and another 18 choices remaining.  That's something like 18¹⁸ which is a pretty big number (~40 sextillion).  Those are the real choices that we need to reduce. 

Let's look at a very simple example from the recent IFR.  In order to communicate information between an EHR and Public Health Agencies, we are directed to use HL7 Version 2.3.1 or HL7 Version 2.5.1.  That's a start, even if a choice between two items.  Look further.  Which of the more than 100 HL7 V2 messages should be used?  The IFR doesn't say.  Could I use a BAR message to post a charge transaction in HL7 V2.5.1 to post information to public health?  That seems remarkably unlikely.  Given what I know, it should be ADT, ORU or MDM, and probably would be the second or first.  Having gotten that far, there are a number of different segments than have to be debated.  Where does the patient ID go?  PID-2, PID-3 or PID-4?  Well, according to the standard, it could be any of these...  Moving on, what must PV1 contain?  Do you even need a PV1?

So, lets stop worrying about whether everything should be SOAP or REST, and start worrying about these more challenging issues.  I'm concerned about what a system needs to do for public health surveillance. The current IFR has basically solved the EASY problem without any guidance for the hard one, and there is no crisp documentation identified that would help.

If you happen to have any insight or ideas about what is intended for public health reporting, or what SHOULD go there, I'd very much like to hear your thoughts and would also ask you to share them with others.

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.

Don't Panic

DON'T PANIC

Unlike the Hitchhikers' Guide to the Galaxy, the HITECH ACT of ARRA does not contain the words "Don't PANIC" printed in big bold text on the front cover, but it should. 

The HITECH provisions describing meaningful use are principally concerned with motivating healthcare providers to use electronic medical records wht the anticipated goal of reducing the costs of care. They do so through INCENTIVES.  See the definition below from wiktionary for the term:

incentive (plural incentives) Something that motivates, rouses, or encourages. I have no incentive to do housework right now. A bonus or reward, often monetary. Management offered the sales team a $500 incentive for each car sold.

As we all anticipate the pending regulation my current frustration is with various people who are panicing about there being "too much, too fast" for providers to adopt, or that the standards are not ready.  If the standards aren't ready, then how is it that 47% of the hospitals responding to the AHA Most Wired survey are already able to support CCD, or that 84% of the most wired can (see Connecting all Your Docs)? 

HITECH is nothing like HIPAA in what it requires of providers.  HIPAA regulation basically stated that you had to use certain standards if you wanted to use electronic claims transactions, and that you had 2-3 years to do it, and there was no money from the Federal government to help it along.  HITECH basically says that if you want to recieve incentive payments, then you have to do certain things over five years, and you'll be ahead of the game, and after five years, there will start being penalties for non-conformance.

Yes, this results in a great deal of craziness as everyone tries to ensure that they get as big a piece of the pie as they possibly can.  But...

If you aren't ready, slow down.  The world won't end tomorrow (or in the next two weeks), nobody is poised to bulldoze your practice.  You have some time to make reasoned and good decisions.  The incentives are structured so that the biggest payouts will be in the first years of technology adoption.  Waiting a little bit won't cut a huge chunk off the potential incentives you can recieve, just read Page 354 of ARRA.  In fact, you'll see that waiting a year (being a meaningful user in 2012) is just as good as starting in 2011.

That doesn't mean I don't want you to start now, because I do, but do so in a thoughtful way, and if you need more time, by all means take it.