IHE Desperation Hypothesis Confirmed

Summary: IHE USA President confirms to Connectathon Monitors that motivation is Meaningful Use.

Long Version.

One of the complaints I have had about the IHE Certification announcements is the poor communication about it, and particularly the Connectathon monitors.

Belatedly, last night a message was sent out to the IHE NA Connectathon Monitors, on behalf of Joyce Sensmeier from HIMSS, President of IHE USA.

Reading beyond the feel-good marketing hype, some phrases stand out like "certification in the US market is already a reality", "this certification program makes IHE a visible part of that process", "highlights the relevance of IHE's profiles" and "provide ... components of meaningful use Stage 3".

Desperation hypothesis confirmed.

I gather, by the way, that ONC folks will be coming to visit the Connectathon for the usual dog-and-pony show, and no doubt their attention will be specifically directed to the ICSA Labs efforts, as a sign that IHE is taking ONC seriously, or something. I bet they will get a laugh in private out of these last minute hand waving attempts to demonstrate relevance (they may not be IHE true believers, but they are certainly not morons). I would also be surprised if it influenced them one iota. I am sure they are well aware that the addition of certification does not magically vindicate the underlying standards or technologies. As enamored as they are of picking and choosing and modifying or reinventing bits and pieces of standards to create their own certification criteria, certification specifically for MU is not going to magically disappear because IHE certifies too.

It is a shame that total obsession with the US EHR Meaningful Use market is triggering an enthusiasm for certification that will contaminate the global market place for all forms of medical technology, raising healthcare costs everywhere.

Still, I have to give Joyce credit for finally having the courtesy to brief the worker bees, so here is the full text of her message:

"Greetings IHE 2013 North American Connectathon monitors,

As you have likely heard, IHE USA has announced a new program <https://www.icsalabs.com/ihe> that will offer certification to complement existing testing of conformance to IHE integration profiles. This new service will be delivered through a strategic partnership between IHE USA and ICSA Labs, and will commence in a pilot program at the 2013 North American Connectathon <http://www.iheusa.org/learnmore.aspx>. IHE USA is pleased to be working with ICSA Labs as we share the goal and experience of accelerating the adoption of usable, secure, and interoperable health information technology, to enable the improvement of patient safety and delivery of higher quality of care. Certification in the US market is already a reality. This certification program makes IHE a visible part of that process. It highlights the relevance of IHE's profiles and their ability to provide substantial interoperability components of meaningful use Stage 3 and any programs that might build on or succeed it.

The IHE North American Connectathon continues to play a pivotal role in allowing the opportunity for HIT vendors to validate their implementation of IHE profiles and help demonstrate compliance with interoperability leading to information exchange. The addition of a certification track will provide a continuum that adds independent third-party assurance that there is a credible, repeatable process that ensures quality, and that these products will exhibit the robust capabilities for optimal data exchange and security that are demanded by our industry today. Certification testing is an elective service and not required for any Connectathon participant. The intent of the certification pilot is to provide a proof of concept for vendors that choose to participate, and lay the groundwork for the ability for products to be certified for interoperability under ISO standards.

We are engaging knowledgeable parties from within IHE to help define the interface between the Connectathon process and certification. This pilot will be conducted separately, but will be convened in the same general location as the 2013 North American Connectathon process that you will be monitoring. The intent is that the pilot activities will not conflict with ongoing Connectathon testing, nor should these activities increase your burden as volunteer monitors during the pilot process over the week. Additionally, IHE USA, as a deployment committee of IHE International, will be providing oversight of the certification program to ensure confidentiality and safeguard any relevant IHE intellectual property. In addition, IHE USA will indemnify its agents (including monitors and contractors) from any liability resulting from testing and certification.

To provide you with a better understanding of this effort we are developing a message to address Frequently Asked Questions. This will be sent by Steve and Lynn in the coming days.

Thank you for your ongoing support of IHE USA as it hosts the 2013 North American Connectathon and have a wonderful holiday!

Regards,

Joyce and the IHE USA and 2013 North American Connectathon team

Joyce Sensmeier MS, RN-BC, CPHIMS, FHIMSS, FAAN

President, IHE USA"

So there you have it straight from the horse's mouth. Or whatever end you think it is coming from.


Saturnalia optima tibi exopto.

David

PS. I also got a personal response from RSNA staff leadership on the subject, which reiterates many of the same points Joyce made in more detail, but since it wasn't an official announcement to a large group, I won't promulgate it. I mention this because, sadly in my opinion, the imaging leadership that championed much of the development of IHE in the first place seems to have turned its back on its core constituency and seems to be towing the HIMSS-driven party line. If I were a major imaging equipment vendor, I would be supremely pissed, and I am looking forward to seeing what MITA's response on certification is, if any. Though after MITA's pitiful failure to comment on MU2 thanks to GE's veto, they may have already lost both their credibility and relevance.

Will Certification Kill the IHE Connectathon?

Summary: IHE Certification has been announced, is dubious but probably unavoidable; the for-profit ICSA Labs will execute it, possibly gutting the participation in future Connectathons and leading to their demise

Long Version.

With unseemly haste, and little time to go before the IHE North America Connectathon starts at the end of January 2013, IHE USA has announced a new IHE Certification program to be executed by ICSA Labs, a for-profit division of Verizon that has significant experience in security certification and is also a Meaningful Use ONC-Authorized Testing and Certification Body (ONC-ATCB), which competes with the likes of CCHIT.

There is no point in debating whether certification adds any value to the customer of interoperability products; that cat is already out of the bag, for MU at least, since ONC has a hard-on for certification (and asks standards organizations like IHE and DICOM uncomfortable questions when there is no corresponding formal certification program). Compared to all the other ludicrous costs of bring a product to market that do little if anything to improve quality or assure safety or interoperability, this is just yet another check box (and lifetime employment program) for the army of quality, safety and regulatory personnel. I don't have a strong opinion about the merits of certification per se; my anecdotal experience as a vendor and a customer and a worker in regulated industries would lead me to believe that it is neither necessary nor sufficient, unless it is conducted with such thoroughness (by which I mean depth and coverage of testing, rather than volume or rigor of documentation) as to be impractical. But I don't have any real evidence one way or the other.

I have no direct knowledge of the IHE USA Board's discussion of the matter, so can only guess as to their motivation. It isn't likely to be the potential for a significant revenue stream, since the price point precedent established by the ONC-ATCB market isn't very high, and the cost of doing the vast amount of ISO-standard inflicted paperwork isn't trivial. I am not sure whether or not IHE USA is getting a cut from ICSA Labs, or perhaps is even funding them.

The haste smacks of desperation, so another guess would be a desire by IHE USA to try to remain relevant in the US national "discussion" on what standards to adopt (if you can grace the ONC autocratic decision-making process with that term). Since a nice thing about standards is that there are so many of them to choose from, and anyone can make up a new one and call it a standard (as the DIRECT folks have clearly demonstrated), there is no question that choices need to be made. IHE USA's difficulty may be that, much to their chagrin, the ONC does not accept as a no-brainer that IHE's choices are always the best choices.

There is also little point in bemoaning what, as far as I can tell, has been a distinct lack of consultation with the IHE community at large. Almost nobody I have talked to knew anything about this before it was announced, and even those meetings that I am supposed to participate in (being Rad TC co-chair) like the Domain Coordination calls (which discuss such boringly bureaucratic and tedious topics that even I with my love of standards documentation can't stomach), were not, I am told, briefed about this. Nor was there a peep on the Testing and Tools mailing list. Clearly the lowly workers did not merit either the opportunity to comment nor advance warning. Strangely enough, the vendors I have talked to were not aware of it either, and indeed the vendors have a long history of opposing the additional burden of certification and have lobbied against it on the basis that self-certification has a demonstrated successful track record, and certification adds cost without value. Perhaps the IHE Board knew how controversial this would be and did not want their decision second-guessed, or perhaps they just got snowed by a plausible argument by a talented evangelist for the concept.

Or perhaps ONC just issued one of its edicts and the board had no choice ... conspiracy theories abound given the lack of transparency in the decision making process.

For better or for worse, unless the pilot ICSA Labs project overlaid on top of the IHE NA Connectathon somehow fails spectacularly, IHE Certification, now that it has been "announced" may be here to stay. If few vendors sign up for certification, then it might fail, but given the loss-leader price of $1,500 for each actor (in packs of 5) that they are offering, it seems unlikely that there won't be a sufficient critical mass of product managers who are tempted to get an additional potential marketing advantage over and above their normal Connectathon passing "gold star", or are just scared of being left behind if certification does become a trend. Today's briefing by ICSA Labs was certainly laced with dubious but blatent teasers for marketing folks. Besides, like UK National healthcare IT projects, it may be sufficient to "declare" victory even in the face of obvious failure, if the political motivation to proceed is strong enough.

So, with that background, on to the question of what this means for the upcoming and future Connectathons. One of my initial concerns, that the work product of the army of volunteer monitors who staff the Connectathon would somehow be "re-labeled" as a certification result, was clearly assuaged by ICSA Labs on today's call - their tests will be separate from the Connectathon tests, executed by their own staff (who they are calling "inspectors" to distinguish them from "monitors"), though they may repeat the same test, or add more steps or tests, and will certainly add more documentation. So, the volunteers will not be "exploited" in the sense of their work being reused for someone else's commercial gain. Nor will ICSA Labs interfere with the process; the certification work will be additional, and later in the week, though predicated on a Connectahon pass.

So far, so good, but what about in the long term? If I, as a vendor product manager, feel the need to obtain certification for any or all of my products, why would I bother to participate in the Connectathon at all? If I have to do the same amount of work, gain the same experience, and the additional cost is small related to the real or perceived marketing benefit, why do it twice? Though the certification testing will take place at the Connecthon itself for the pilot, in the long term ICSA Labs plan to do this separately as needed, virtually (over the Internet) if possible. Arguably, the Connectathon serves as dry run, but those can probably be done just as easily at home or informally.

Similarly, why would I ever volunteer to staff a Connectathon, when I could probably charge my hourly rate to ICSA Labs, or get a job with them, to do exactly the same thing (unless of course ICSA Labs treats its employees like parent company Verizon treats its linemen)? There is an educational component to volunteering, but for experienced folks, the supply is small and now there is a competing consumer.

That is why, at this date, I am opposed to IHE Certification process as announced; not because I think it is a waste of time and money (which I sort of do), but because it puts at risk what I think is much more important, the opportunity to gather and learn and test and even experiment at the Connectathon, in a relatively informal manner that encourages iteration, improvement and collegiality between competitors. In my opinion, there will inevitably be a dramatic reduction in Connectathon participation as a consequence of the need to become certified; regardless of how much the engineers might want to test at such an event, their marketing bosses who hold the purse strings just will not have the will or the resources to do both.

If I were one of the IHE decision makers, and felt bound to jump on the certification bandwagon to survive, I might have made a different choice, one which did not put at risk the Connectathon, but instead leveraged it, and found a means to certify Connectathon results, building on the experience and dedication of the existing staff, and added the necessary documentation (preferably automated) to satisfy the ISO processes. This sort of thing has been discussed before, including by the people who do the work. I dare say I would have been skeptical about the feasibility and initial cost of this, and tempted by the offer of an existing organization like ICSA Labs with the ISO infrastructure already in place, but I would have prioritized the future of the Connectathon, and seen the modest revenue stream from certification as a means to (belatedly) beef up the tests and tools that have languished somewhat for lack of resource investment over the years.

Not to mention avoiding the slap in the face to the core Connectathon staff, who, for well over a decade, have been putting on this event with diligence and dedication, and who are now probably destined for unemployment or a future as underpaid mistreated Verizon drones, in addition to seeing their many person-years of work in the form of openly available tests and tools handed off to a for-profit to reap the benefits, as well as being denied the opportunity to turn their vast talent to performing certification themselves. They are obviously not able or willing to speak about this, but observation of their reaction would suggest that they were not consulted or warned about this either; if that is the case, it is shameful treatment by the IHE organization that they have served so loyally.

Given my upcoming New Year's resolution to be more of a glass half full kind of guy though, perhaps I should view this as a precedent and take the opportunity to start a new initiative for DICOM Certification, probably the last thing the world really needs, but hey, there is no point in standing on principle in the face of a tidal wave, and if you can't beat them join them. Give the customer what they think they want, not what they actually need.

I still haven't decided whether or not to withdraw from volunteering as a monitor for the upcoming Connectathon. I would hate to miss it, but given that it is one of the few tangible ways to express my displeasure, I don't think I have much choice other than to boycott the event.

David

PS. An interesting side question, is why IHE USA did not select the non-profit CCHIT organization as a partner in this, particularly since they are doing the certification for Healtheway (formerly the Nationwide Health Information Network NWHIN). Perhaps it is just because Mike Nusbaum, a long time IHE player and expert has joined ICSA Labs as Program Consultant and seems, judging by today's briefing, to be a key player in this effort; they certainly have someone who knows what they are taking about. Not that I have any great love for what CCHIT does either, just wondering.

Patient Empowerment: Real Time Wireless Synchronization of Images and Records to Their Smart Phone

Summary: Your image-enabled personal healthcare records belong on your smart phone, the instant that they have been created.

Long Version.

Imagine you are a patient, and as you climb off the CT table, return to the dressing room and prepare to leave, your smart phone or similar device, which is always turned on, has already authenticated itself on your behalf to the PACS, and proceeded to download the complete set of images just acquired (which come out of the reconstruction pipeline almost instantly nowadays).

Then, whilst sitting in your doctor's waiting room (or perhaps whilst stuck in traffic on the way there; naughty, no reading images whilst driving) you could scroll through the images and decide what questions you wanted to ask about them, perhaps with the benefit of the previous images and reports that you already had, or even with the fresh report that just popped up as the radiologist (finally!) got around to reporting the study half an hour after it was acquired (probably the delay was negotiating for the lowest bidder to report it in India or China).

Technical challenges of bandwidth, storage, compression and so on aside, this is entirely within the realm of possibility right now, much less in a few years, when we will fondly recall how limiting 4G was and how quaint 2GHz quad-core processors were. As applications and services providing seamless synchronization between an individual's myriad devices proliferate, together with remote "backup" (on "cloud" providers), the sort of device-independent availability of information that users already expect for mail, contacts and documents, will become available for healthcare records too.

The imaging use case is more challenging, given the large volume of data, but it is qualitatively if not quantitatively similar.

As for security, authentication and access control, most healthcare facilities seem more than capable of finding ways to identify the patient in order to bill them or or their insurance company. It seems likely that just as one typically enables personal devices like phones to automatically authenticate to commercial service providers for shopping, music and video access, a patient that establishes a relationship with a medical facility ("registers") could at that time (or subsequently) register their device, just as one does with any other online "portal", and the device would cache the credentials (or not, depending on the paranoia and personal policy of its owner).

Subsequently, the "patient health care record app" on the device would take care of automatic synchronization with the most recent record information, at every provider that the patient visited, seamlessly, automatically and silently. It could merrily beep as it received new information, make more arousing noises to notify when more critical information arrived (like an out of range lab test or abnormal radiology result). As the longitudinal record grew it could flush from its cache older information (on a rule driven basis), with the patient secure in the knowledge that the multiple "cloud" servers on which everything was backed up and the entire record stored would allow them to retrieve older stuff on demand as necessary. Geographic proximity to the provider would be unnecessary, and the device would, as they typically do already, even for voice, adapt to the fastest accessible network (Wifi if local, 4G or less if not).

Then, when visiting a new provider and registering with them, the reverse could occur. The patient's own device could synchronize whatever the patient wanted to share with the providers systems immediately on registration, or communicate the unique identifiers of each piece of information to the provider's system so that it could synchronize it from the cloud servers if not locally cached.

With nearly half of all US phone subscribers acquiring a new phone now choosing a smart device, it seems inevitable that the penetration of these devices will asymptotically approach ubiquity.

The single device that a person already carries offers the potential to eliminate the need for paper tokens like airplane boarding passes or entertainment tickets, and for payment, instead of cash and credit cards, and already serves many of us as the primary interface for online information gathering, decision making, navigation and shopping (see it, snap a picture or bar code, buy it online). It seems inevitable that it will also become the primary conduit for all personal information access and storage, so why not healthcare information, including diagnostic images, too?

The idea of a PHR on a smart phone is incredibly obvious, and already various PHR groups are starting to provide such apps and services with varying degrees of sophistication and integration (see, to name only a few, motionPHR, MyMedicalRecords.com, mobileStorm) and it is inevitable that the sophistication of all aspects of "mHealth", as it is now referred to, will grow at a phenomenal pace. Extending it to include diagnostic imaging beyond the current crop of simple "viewers" (like Mobile MIM) to include seamless synchronization as part of the integrated personal record seems like a no-brainer.

Perhaps by the time we get to Stage 3 of Meaningful Use, the neanderthals who colluded to cripple Stage 2 will have been outpaced by more disruptive innovators, and it will be timely to reimburse specifically for seamless patient-controlled synchronization of images and everything else, not only in a general "download and transmit" sense, but with a specific certification requirement to permit this via their mobile devices.

David

HL7 to Become a Truly Open Standard After All

Summary: HL7 to implement a free IP policy by Q1 2013, and become a truly Open Standard, with both Open Access and Open Use.

Long Version.

I got a whole bunch of emails this morning from HL7 members who had received a special announcement via email from the HL7 CEO, Charles Jaffe.

The long and the short of it seems to be that the HL7 Board of Directors has "committed to licensing its standards and other selected HL7 intellectual property free of charge".

Outstanding!

The details are described in an FAQ at "http://www.hl7.org/about/faqs/FreeIP.cfm", which was only accessible to HL7 members, but as of a few minutes ago, became generally accessible.The CEO's announcement has also just appeared as news on the HL7 home page here.

A few of the highlights of the FAQ include:

• recognition that "charging for standards is a barrier to widespread adoption"
• "increasing government demand for standards that do not require a licensing fee"
• HL7 will retain copyright (i.e., not "public domain") to retain control over change and improvement process (conventional for most standards)

My understanding is that both access to the standards, and the right to use the standards in implementations, will become free, globally, so that any current barriers to open implementation will be removed.

There will be some delay until this policy is in place, and in the interim the current licensing policy applies, but the commitment is to roll this out by Q1 2013, apparently.

I am certain that other open source code developers are as pleased by this as I am, and I am sure that we are all equally grateful to whoever those HL7 stakeholders were who were responsible for this development (like Keith Boone, for example).

David

Diagnostic Quality is Vital; Download and Transmit is Feasible

Summary: ONC could have and should have required CEHRT to include provider viewing of both key review images (fast) and complete sets of diagnostic quality images (slower), and patient viewing, downloading and transmission of both review and DICOM diagnostic images, assuaging the fears of EHR vendors by suggesting the use of links to PACS for the latter, just like for provider viewing. The lack of specificity on diagnostic quality may allow re-emergence of a patient care quality risk and an unsatisfactory standard of care. Deferral to a later stage undermines the progress already being made, due to diversion of all available resources to Meaningful Use.

Long Version.

It may certainly appear from my recent comments about Meaningful Use Stage 2 as if I am a "glass half empty" kind of guy. After all, some might say, one could put a positive spin on the fact that anything to do with imaging at all is included in the certification requirements; John Halamka, for example, sees it as a balance (whilst warning that what remains is still a stretch).

Unfortunately, there is a danger in what has been included, which puts what has been excluded at greater risk than it might otherwise have been. Specifically, there is a risk that the standard of care will be lowered by the suggestion that an incomplete set of non-diagnostic quality images may be sufficient, or will be all that is made available.

There is no question, of course, that there are use cases for which only key images of "review" quality are sufficient; one commenter drew attention to the scenario of reviewing a diagnosis with a patient, perhaps for treatment or prognosis explanation purposes. And that's fine. Certainly, for these scenarios, the manner in which limited review quality images is provided should not be burdensome or slow.

However, as we all know, there are many scenarios in which a complete set of diagnostic quality images are required. It seems that these will not need to be available through the EHR system, whether through a link or direction incorporation, because CEHRT will not be required to provide them, whether to providers or patients, and we all know that all available resources of vendors and providers will be diverted to CEHRT exclusively in order to "cash in" (to use one popular media outlet's tasteless expression) within the required timelines.

Deferring the need to support provision of a complete set of diagnostic quality images unfortunately may undo the good work of the AMA safety panel convened a few years ago to address this very issue, the conclusions of which the AMA reiterated in their CMS comments (not their ONC comments).

One may argue that since the actual final rule itself is silent on the matter of whether diagnostic quality or a complete set are or are not required, that this is not a problem. I am not so sure, since comments were made about the matter, and discussed in the response, and the absence of a requirement seems to establish the lower expectation.

In summary, not only is the "glass half empty", but what remains in it is potentially noxious.

So let me return to the feasibility of the Download and Transmit Images capability that was dropped (and for that matter Viewing by patients, as opposed to providers, which is also not specified), and why I still think both CMS and the ONC could have done better (and for that matter, how I think more commenters could have suggested constructive, non-threatening solutions as opposed to just objecting).

I will address this by discussing how Download and Transmit Images might have been implemented, what the implications are with respect to standards and infrastructure, and how the objections raised by the commenters to either the 170.314(a)(12) – Imaging, and § 170.314(e)(1) - View, download, and transmit to 3rd party could have been addressed, particularly where they overlapped or were addressed in the final rules, either from ONC or CMS.

First of all, let's address the "DICOM images are too big" issue, which is related to both the availability of high bandwidth connections, as well as the impact on the "local" infrastructure (computing resources). Certainly complete sets of diagnostic quality images can indeed be large, very large, even if compressed, and even if irreversibly compressed in a manner that preserves diagnostic information.

Though I have focused on the certification requirements, the means to address the bandwidth concern is apparent from the CMS response to comments, which specifically addresses it in connection with the remaining measure for View, Download and Transmit:

"any EP that conducts 50 percent or more of his or her patient encounters in a county that does not have 50 percent or more of its housing units with 3Mbps broadband availability according to the latest information available from the FCC on the first day of the EHR reporting period may exclude ..."

The CMS response also points out that this is a menu objective.

In other words, there was no need to deny patients the benefit of this capability in those areas where bandwidth is sufficient, since CMS was willing to establish an environment-sensitive exclusion.

What about when there is no digital imaging technology available in the first place (e.g., the chiropractors who commented that they are still using film)? Or when there is no PACS in which what digital images there are can be stored? Again, the CMS response indicates that this can be handled by an exclusion "for providers who have no access to electronic images". Just as this applies to the provider viewing requirement, it could equally have applied to Download and Transmit. Also, though it was not specifically mentioned in the response, it appears that there is no expectation that the images be digitized (which would make them "accessible"), as some commenters had feared.

Then there are "DICOM images are complex", "a complex viewer is needed" and "patients can't be expected to find a DICOM viewer". Well, Word files and PDF files and Flash files and MP3 files are "complex" too and the average consumer seems quite capable of locating the necessary software to do what needs to be done; hunting down extra plugins, codecs and helper applications is second nature to most consumers nowadays, albeit not ideal. The computer literate patients likely to be "engaged" (to use ONC-speak) are also likely to be better able to handle this class of issues than is the typical healthcare provider; what is more, they are not hampered by regulatory requirements or local IS policy; they can download and use what they need to get the job done.

Furthermore, the negative comments in this regard seem to miss a key intention of the View, Download and Transmit to a 3rd party requirement, to enable the patient to get what they need and then pass it on to the next provider, not just to be able to view it themselves. Whilst it is likely true that the vast majority of patients have no interest in any of this electronic stuff at all (i.e., are not "engaged"), and of those, only a further subset will be interested in the images, those who are, can in my opinion, be expected to adapt to whatever is available, more readily than inflexible institutions for whom adaptation is much more challenging (and costly). Nor should patients be treated in the paternalistic manner of some of the commenters, particularly those who assert confidently that "patients do not need diagnostic quality images", without considering why the patients need the images in the first place (such as previously stated, to supplement an inadequate or non-existent provider-to-provider transport network). Even for the patient viewing scenario, adequate free downloadable DICOM viewers that are easy to use are readily available for both Windows and Mac, and likely soon most mobile devices, so I don't think this objection has a leg to stand on. Arguably, the free viewers are better than what the vendors provide in some cases anyway. Frankly, getting the images to the screen may be less of a challenge for many patients than understanding what they are seeing when then get them there, but I would not put it past them to find the subtle or incidental finding that the radiologist may have overlooked.

EHR implementers do indeed have good reason to "fear" the "complexity" of DICOM images though, since actually implementing the software to handle their contents does require expertise and hence consumes scarce development resources. It is not that the DICOM images are much more or less complex than most other formats for images or other structured data, but rather that specific expertise is required, beyond what they are used to. Fair enough, but this is no more or less true (arguably less in fact) than for the provider Viewing requirement, and hence it is clearly reasonable to suggest a way not to burden the EHR implementers, and outsource the solution.

It seems obvious, therefore, that the same "link" rather than "duplicate" policy that ONC and CMS accepted for the Viewing objective would have been equally applicable to the Download and Transmit objective, yet few commenters picked up on this and the ONC elected not to take this approach, which surprises me.

This may be a reflection of the limited state of the art in EHR to PACS linkages. It may be common enough right now for EHRs to contain links to pre-rendered individual images (e.g., via WADO or similar) or external image viewers (whether they be PACS or VNA or cloud storage provider or some other system like an XDS-I repository in an HIE), but typically the viewers that are spawned by this mechanism do not then support further handling of what is being viewed. Some may allow download of DICOM images to the local hard drive or CD or USB media, but not all. Probably none currently support forwarding to a third party, other than perhaps to request transmission of the set via local DICOM network services to an analysis workstation.

Furthermore, in many cases the EHR linkage to a PACS viewer may currently only be implemented as a provider-accessible feature, with provisioning mechanisms for security credentials only for staff and a limited set of external providers. The patient-accessible portals are likely implemented in quite a different manner to the provider-accessible portals, and this dichotomy may be the primary source of anxiety about this.

That said, how hard would it be, assuming that one has adequately authenticated the patient who is already using such a portal, and is authorized to view scheduling, billing and electronic record information, to extend that authority to allow them to view their images? This would require that the mechanism used to span the PACS viewer specify the patient's identity, and that the viewer not permit navigation to other patients; not terribly difficult; and likely exactly what has been implemented for the provider portal, since providers are not (or should not be) allowed to just cruise all the patients in the PACS either. In other words, it seems entirely feasible that whatever standard or proprietary mechanism of access control is implemented whilst spawning the provider viewer could be reused for the patient viewer. Yet this was not required by the ONC in the final rule.

What about the burden of shipping a relatively large set of images around in order to be able to Download or Transmit them? Certainly in the case of the Download proposal, the diagnostic quality image set takes a finite amount of time to move across a connection. This is true whether they are encoded in DICOM format or any other, since it is not the fact that they are DICOM per se that makes them large, rather that they are a complete set, and of diagnostic quality. In the case of a patient portal, at a minimum, there is a need to move the entire set from a server location to the patient's desktop, by definition. Ideally, the download would be performed from where the images are already stored, rather than having to first retrieve them to a cache in the portal server, and then provide them to the user. This might be most easily performed by whatever application was spawned to view the images, as discussed above, since such an application would likely already have access to the images in the correct form. Alternatively a specific application on the PACS or archive could be spawned to perform such a function. But in the worst case scenario, the "simplistic" albeit crude approach of just having an application in the portal "pull" (retrieve) the image set from the PACS or archive to its own cache and then download them isn't really that bad; it consumes local resources and it adds a delay that the user might see before the download starts, but if the portal and the archive are co-located at the same site with a high speed connection this may actually not be that bad. EHR implementers might be terrified of the need to learn how to perform a DICOM retrieval, but this is expertise that is easily outsourced and existing free and commercial toolkits have this sort of thing built in; all EHR implementers need to know is how to send via http a bunch of files in a folder, and presumably they are experts in that, and have to do it for other content anyway. Inelegant, but arguably sufficient, and better than nothing at all.

Likewise the Transmit to a 3rd Party requirement isn't really that burdensome either, if one takes a crude approach to it rather than waiting for an ideal solution. If one is willing to retrieve the image set from the archive to a local cache to satisfy the Download requirement, then sending it on to someone else is not hard either, assuming that one has the location and credentials of the recipient available. Since the final rules do indeed still require this feature for non-image data, then the "addressing" capabilities have to be implemented anyway; reusing them for the images would be fairly trivial for the EHR vendor to implement themselves, if they were willing to first retrieve the images and then send them via the ONC specified mechanisms (secure email or XDR, the latter obviously more suitable for large packages than the former).

The Transmit to a 3rd Party requirement would certainly be more challenging to implement in a more sophisticated manner by passing a request to a spawned PACS application. Certainly there are no standards for an EHR to request that a PACS "copy" ("move") a set of images from where they reside to somewhere else, except for the DICOM C-MOVE service, of course, but that only allows copying to a known DICOM network node, and the request has to be made as a DICOM network command, which limits its applicability when one is sending beyond the enterprise's own network. This is actually a bit of a gap in the DICOM Web Services roadmap and the IHE profiles for that matter too; we have defined plenty of services and transactions for actually doing the transfer, but not for requesting the transfer. I.e., there is no DICOM WADO-* or IHE XD* equivalent of the basic DICOM C-MOVE. I need to discuss that gap with both groups, and particularly the need to be able to incorporate in such a hypothetical new standard whatever "address" for the receiving endpoint has been specified by ONC for non-image content.

That said, just as ONC has been willing to accept the proprietary rather than standard mechanisms for linkage of the EHR to the PACS for the provider Viewing requirement, there is no reason that they could not have permitted the same for the Transmit to a 3rd Party requirement, as an alternative to implementing the requirement via the less efficient "retrieve, cache, and transmit" mechanism that I just described. As long as the patient portal in the EHR takes responsibility for access control, i.e., for authenticating the requester and limiting the request to that patient, the spawned application could then "do the work" of transferring a copy to the specified recipient. The PACS application would have to implement the specified transfer protocols though, but it is possible they already support XDR (though unlikely that they support secure email). Of course, for the vendors (and the customers) the proprietary linkage does require the usual n:m integrations between the two sides, with its attendant costs, but if it was good enough for satisfying the provider Viewing requirement, it could have been good enough for the Transmit to a 3rd Party requirement too, had that been considered a high enough priority.

On the subject of priority, it really bothers me that the EHRA insisted that "the images could be provided to the patient on a CD or DVD". Haven't we had enough of the problems associated with physical media? Isn't the goal of the Meaningful Use initiative in the first place to provide better care through electronic access. Sure, once upon a time, physical media was the best we could manage, but the literature and the Internet are filled with a litany of complaints about the problems caused by CDs up to this point, and surely it is a priority to insist that readily available technology be used (just Google "imaging cloud" for instance, not to mention XDS-I). I find the EHRA's comment that "electronic communication of DICOM images, particularly when possibly needing to allow the patient to see the images, is still a new area" to be extremely uninformed at best, if not outright disingenuous.

All in all, as far as I can tell, the final certification requirements boil down to no more or less than this:

"electronically indicate to a user the availability of a patient’s images and narrative interpretations (relating to the radiographic or other diagnostic test(s)) and enable electronic access to such images and narrative interpretations."

No requirement for a complete set, no requirement for diagnostic quality, nothing for images under the category of patient engagement.

Disappointing, since it was entirely feasible, in my opinion, to do better and push the vendors harder.

Farzad tells me that he hopes that the business case is so clear that it will happen regardless, and he may well be right. However, I fear that Meaningful Use seems destined to suck up all available resources and to drag the vast majority down to the lowest common denominator of "no better than Meaningful Use", which is still a pretty high bar and significant progress, apart from imaging. In particular, the dangerous precedent of not requiring diagnostic quality images may directly lead to patient harm. In due course, I dare say we will hear what the plaintiff's attorneys have to say about all this, when someone misses a critical unreported finding when they view an incomplete or low quality EHR image set with the consequence being an unfortunate outcome, since being proactive in this respect seems to be beyond our ability to mandate.

David

PS. I should, by the way, draw attention specifically to the comments of one EHR vendor, who did not follow the crowd of their naysaying peers. Cerner was notable in that it drew attention in a very constructive manner to such things as the need to specify requirements for what the viewer actually should do to be useful (pan/zoom/scroll), for example. In an interview for Radiology Today I had mentioned that this was a factor that we could have addressed in the comments, using something like the IHE Basic Image Review (BIR) Profile perhaps; i.e., provide some functional requirements for the viewer in the certification requirements. Regrettably, I did not think to suggest this when I had an opportunity to contribute to the draft RSNA comments before they were submitted. Not that BIR has had stellar adoption, largely due to the installed base of existing viewers whose implementers are resting on their laurels, and are uninterested in retooling their user interface in the name of consistency; but it does define a baseline for a minimum feature set negotiated with the user community.

PPS. On the matter of the comments related to whether or not this is confined to just radiology images, the CMS responses attempt to clarify that by defining the measure in terms of "tests whose result is one or more images". Perhaps this is clearer, but is the "result" of an echocardiogram or a coronary artery calcium scoring CT the images themselves, or just the numbers (LVEF or Agatston score)? Also, if one is self-referring (e.g., a neurologist with their own MR or a cardiologist with their own CT), is that included in the measure? I guess so, since the measure states "ordered by the EP" and to the extent that an "order" is required to get paid, even if one is fulfilling the order oneself, I suppose it is included. The ONC certification requirement does spell out "radiographic or other diagnostic test(s)".

PPPS. Surprisingly, I could find little mention of some key issues that commenters could have objected to that are real infrastructural challenges, For example, nobody mentioned (as far as I could find) the matter of patient identification, which would have been an issue for Download and Transmit, since during importation at the other end, one often has to do this manually (though the IHE IRWF Profile provides ways to automate this). The focus seems to be more on getting stuff out rather than back in again, so I suppose that is fair enough, and having a national patient identifier seems to be a dead duck in the US for now.

PPPPS. All this talk of "links" to other systems, whether via WADO or similar proprietary mechanisms, spawning of external viewers, or even synchronized applications in a CCOW-like manner, reminds me that this is not a new topic and that there is a lot of experience, favorable and unfavorable, in this respect, which might lead one to the conclusion that links are an interim step and that a monolithic system will one day be needed (e.g., real images really stored in the EHR, and advanced visualization built in). You might want to read "Radiology IT: Applications Integration vs. Consolidation" by Peter Kijewski about the MSKCC experience, as well as Wang et al "Five Levels of PACS Modularity: Integrating 3D and Other Advanced Visualization Tools".

Also, now that I think of it, there is a reason that the VA has, for a very long time, had Vista Imaging as part of their EHR system, rather than depending on accessing images through the various locally deployed PACS. You might want to track down old articles by Peter Kuzmak or Ruth Dayhoff on the subject; there are too many to enumerate here, but this 1999 (!) symposium paper on "Providing a complete online multimedia patient record" is a classic. It is amazing to consider how fearful contemporary EHR vendors are of images, yet well over a decade ago the VA just got on with the job and took care of the needs of their users. "Electronic communication of DICOM images ...  is still a new area" (says the EHRA); yeah, right; Luddites.

By the way, the VA's Consolidated Health Informatics Standards Adoption Recommendation Multimedia Information in Patient Records is good read too.

Influencing the ONC - Collusion or just reasonable lobbying?

Summary: The EHR vendors amongst themselves and/or through their EHR Association appear to have colluded to ensure that imaging download and transmit was excluded, and Epic in particular lobbied their customers to comment; this was presumably obvious to the ONC; regardless of the merits of the argument, is it fair?

Long Version.

This post is not going to discuss the merits of including Download and Transmission of images, which I will save for another post, but rather the appropriateness of the comments and the manner in which they are submitted.

I wasn't going to bother addressing this issue further, but the topic of the commonality of certain aspects of the comments was picked up from my summary on the Healthcare Renewal blog in "Health IT Vendor EPIC Caught Red-Handed Using Customers as Stealth Lobbyists; Did ONC Ignore This?", so I suppose I should.

Also, an anonymous commenter on my blog entry responded last night:

"But that doesn't mean that there is a conspiracy - or that one organization (as you blogged earlier in the week) has deeper influence than any other .. and if you think that Epic's redundant comments parroted by their many customers counted as anything more than one opinion - you underestimate the aptitude of our friends at ONC and CMS. They weren't born yesterday, ya know."

I do agree that it is likely that similarity of the comments was completely obvious to the government folks, who no doubt did a very thorough analysis, and that they took this into account. It seems likely that they were sensitive to the intensity of the strident opposition of the entire EHR industry, and considered the merits of the arguments independent of the manner in which they were submitted.

I can't say that I agree, however, that there might not have been a "conspiracy", although I don't think there was anything particularly clandestine about it (particularly since many of the comments from the customer sites were prefaced in their covering material with "I agree with Epic", etc.).

I took a look with Google and on the HIMSS EHR Association web site to see if I could find minutes or other records of EHRA meetings, where perhaps they might have discussed a consistent response in order to discourage the inclusion of View, Download and Transmit images, but I couldn't find anything.

I don't know what anti-trust protection procedures these EHR vendors follow when they meet in their association, and there was no mention of that on the association's site or on the parent organization HIMSS web site either (in their bylaws or any where else). I found this a bit surprising, since in my experience, NEMA (the DICOM parent organization), as one example, is obsessive about this issue, and has all minutes both reviewed by counsel and posted publicly to assure transparency and appropriate conduct.

Since the public comment process for a proposed rule-making is not a procurement or grant award, I dare say that the "Red Flags of Collusion" described on the DOJ web site are not directly relevant here, even though the Final Rule specifies certification criteria that products will have to meet to be viable in the marketplace, and hence the conduct of the public comment process directly shapes that market. Certainly if they were applicable, the "similarities between vendor applications or proposals" criterion would be met! I am not sure to what extent this does or does not fit within the concept of conduct to "encourage uniform action" (as distinct from "voluntary parallel action").

I guess there is a fine line between trying to develop or adopt standards to promote interoperability, a goal that is clearly in the public interest, and trying to manipulate the market to satisfy the shared objectives of a group of vendors. Others have expressed general concerns (in a context that has nothing to do with imaging) about the MU certification process distorting the marketplace and leading to increased prices for certain functions (e.g., see the comments by the Kansas Hospital Association).

Likewise, making public comments may or may not constitute "lobbying". I couldn't easily find online any documentation of whether the EHRA or HIMSS does or does not formally engage in lobbying or have a separate PAC, or how this is related to their non-profit status (insubstantial portion), or whether they report this. By contrast, in NEMA, as I understand it, the standards development and other activities are separated from lobbying activities, and there is a separate NEMA PAC, and it makes the required reports to the Senate about how much it spends, etc. I mention NEMA only because I have some familiarity with them, not to imply that they are pure as the driven snow.

What about the distinction between comments from vendors and customers? Why, for instance are so many Epic customers apparently willing to relay the EHRA's message that single sign-on is not wanted? Why on earth would a user want to log in separately to the PACS every time they wanted to look at an image, even though they were already logged in to the EHR application (and the operating system for that matter)?

I suspect the answer is the obvious one, the responses aren't from actual "users" at all, but rather from the IS folks who deploy the systems, and who are on the hook for providing the service and paying for the infrastructure, which in many cases may not be supported by their existing software choices (and in some cases obsolete versions). It is clear from the Epic template, as well as explicit comments from other vendors, that customers were left in little doubt that the single sign on feature was going to either cost them money or divert resources from other developments that they might perceive to be a higher priority, as well as require engagement from other vendors. This almost suggests "intimidation" but I suppose can be construed as simply laying the facts on the table (resources are limited; choose what to focus on).

Amongst those other vendors making similar comments were the PACS vendors, some of whom may be equally lame when it comes to infrastructure friendliness features like single sign on, and may well be equally opposed to being forced to deal with this, as would their "customers" (as opposed to "users") too; in theory the PACS vendors might be happy to have the infrastructure manage security and access control, but in practice, how many customers want to be forced to upgrade their PACS just to support meaningful use, and how much would it cost them? Bottom line is that many folks may well want to do this, but in their own time, with as little extra cost as possible, and not be regulated into doing it.

And, with respect to the single sign on feature in particular, it may simply be that the technology and the standards are not ready for prime time; the fact that ONC has a Challenge to study this currently in progress would seem to substantiate that. But I am digressing into the "merits" rather than the "appropriateness", so I will defer that for another occasion.

The same goes for downloading and transmitting images on the network, which is largely a security integration question too, since the EHR "portal" would likely just be acting as a proxy to the PACS where the images reside; this is perhaps not as technically difficult as some have construed (a later discussion), but it is one more thing that involves two vendors talking, and that, as we all know, despite standards, costs money. Contrast the position of the vendors and the customers, with that expressed by the "real" users, the physicians in this case, as expressed by the support, for example, by the American College of Physicians.

So, as the line from the movie goes, "follow the money", not in the sense that any bribery or corruption is involved, of course, but rather in terms of commenters' motivation. The cynical view is that everyone wants to receive the incentives (or benefit from the market created by them) yet spend the least in the process.

The lesson for me, of course, is that those of us who wanted this done "right" should have worked harder to assure that ONC was swamped with supportive comments (and sufficient technical detail to clarify feasibility) and then they might have felt more comfortable sticking to their guns; in failing to do so, "we" were outmaneuvered by the naysayers.

Presuming it is indeed legal and ethical to engage in such conduct, next time "we" need to call in the super-PACs (and not in the imaging sense of the word).

By "we" in this context, I mean those of us who believe that ready access to a full set of diagnostic quality images encoded in DICOM is a critically important and entirely feasible part of any comprehensive electronic healthcare "system", and hence equally deserving of incentives, lack of penalties and certification criteria.

David

PS. My Anonymous commenter also made the point that "doesn't mean ... that one organization (as you blogged earlier in the week) has deeper influence than any other", presumably referring to my initially singling out as GE Healthcare as the prime evildoer in this respect. And he/she is probably right to some extent, since, as it turns out, GE's comments parrot those of their other EHR "fellow travelers"; I would though, be very interested to know how much influence GE individual contributors had in terms of developing the EHRA position in the first place (I have no inside knowledge in that respect). That said, comments that come from companies like GE, which have a reputation as both imaging and EHR vendors, might well, in my opinion, have held greater sway, given their presumed experience in both fields. Hence I suggest that GE and their ilk deserve extra vilification as a consequence of their disloyalty to the imaging cause.

What is An Open Standard Anyway ?

Summary: Not everyone agrees on the definition of Open Standards, especially HL7 enthusiasts who work for global multi-national companies and don't seem to be sensitive to the needs of Open Source developers.

Long Version.

It seems that standards are like opinions. Everyone has one, and everyone can make them up on a whim.

So it seems is true for Open Standards too, not only for the standards themselves, but even for the definition of what a Standard, or an Open Standard, is.

In Keith Boone's latest rant (his words), he apparently objects to the recent movement in opposition to the observation that HL7 is a CLOSED STANDARD, by many peoples' definition, though not his.

He apparently objects to the fact that he works his butt off (and is paid by GE Healthcare for the privilege) to develop standards for an organization (HL7) that is getting criticized for both CHARGING FOR ACCESS and CHARGING FOR USE of its standard. And he points to the principles espoused by a new organization OpenStand as being justification for the position adopted the HL7 Evil Empire.

As Keith quite rightly points out, nothing is free, somebody has to pay, and there are all sorts of revenue models for standard development organizations, but making standards Open Source unfriendly is not, in my opinion, a desirable approach.

Hence he prefers global multinational vendor friendly industrial definitions of "open standards", since for those companies the cost of fees and contributions is lost in the noise and patent litigation is a way of life.

I prefer Open Source and developing nation friendly definitions of "open standards" such as those of the Open Source Initiative listed under Open Standards Requirement for Software.

For a fairly exhaustive review of other peoples' definitions, you may find the Wikipedia entry about Open Standards informative.
 
From the perspective of the independent open source developer, I disagree with Keith strongly; it is indeed extraordinarily important that FREE (as in no cost to obtain or use the standard) is part of the definition.

In my opinion, Open Access and Open Use are a much higher priority than having the formal privilege of voting, which he sees as the tradeoff when contrasting the revenue model of standards organizations that have large fees for membership, but not for access or use (like the W3C standards). I can't say I value that privilege as highly, since one can still contribute. I have no W3C experience, but if one uses DICOM as a model for comparison, the formal privilege of voting is vastly over rated, since almost every decision is made by consensus and on merit.

Also, I don't feel too sorry for Keith's desire for control, since GE is an HL7 Organizational Member, so he gets to contribute and make decisions. GE also contributes vast sums to NEMA, which funds DICOM, so arguably GE's generosity (enlightened self-interest) is more than partly responsible for DICOM's existence and continued success.

Regardless, the term Open Standard has become relatively meaningless given that there is no authoritative source of a definition, but I will make no apologies for continuing to lobby for HL7 (especially CDA) to either become Truly Open (by my definition), or for us to find an alternative.

Keith also mentions the matter of respect.

He gets a lot of respect, from everyone, including me, and he well deserves it, for the merit of his many contributions in many forms.

But he does not get a free pass for being a lackey of the Evil Empire, which continues to expand its greedy tentacles into every aspect of US healthcare IT, extorting fees from the public as it goes.

David

Why ONC Whimped Out - An Annotated Bibliography of Public Comments

Summary: There was a surprisingly large number of comments about imaging and download and transmission of images!

Long Version.

In my last blog entry describing ONC dropping their proposed "download and transmit images to a third party" requirement in the final rule, I promised that I would try and find the entire docket of comments, and see who else, other than GE Healthcare, contributed to this disappointing result.

The entire docket is available at the regulations.gov site, and it contains some 445 public submissions (one withdrawn), a lot of which, of course, make no mention of imaging. So, I downloaded them all, searched for mentioning of imaging, which narrows the field somewhat, and here is what I found (with hyperlinks directly to the comment page). I have omitted mention of comments related to the measures since my primary focus is on the technical requirements, and I apologize in advance if I have missed (or misinterpreted) a relevant comment.

Here I have itemized the comments, and refrained (mostly) from too much editorializing ... I will make a separate post with my interpretation of all this.

These are the ONC document comments not the CMS comments ...

• Eastern Maine Healthcare Systems - Imaging - want images "and/or" results to be "or" only (guess what they don't want to bother providing ?) - ask whether this is just radiology, or also cardiology or pathology (very good question, they want only radiology) - don't want single sign on requirement - estimate cost to implement in PACS to be $1M - View, Download and Transmit to 3rd Party - they want this removed for images entirely - they reference the mention of the NIH RFP to develop technology for this and claim it is unreasonable to require developmental technology (clearly it was a tactical error for ONC to mention this NIH RFP, since this is off-the-shelf technology that has been around for years and is available from commercial providers; surprising EMHS doesn't recognize this) - they make a good point about ther being no mention of "how long" information has to be available after last contact
• Aware and a second comment - doesn't call out specific sections but comments on general on how good DICOM and JPEG 2000 are, how bad CDs and proprietary viewers are, how bulky images are to transmit especially via email, and how links to sources of streamed images in a standard format are good - all true, but unfortunately they also ignore the importation use case in promoting streaming whilst deprecating bulk transfer of DICOM images; I quote, "without the necessity to download, store and upload the massive DICOM files themselves" (Aware is, of course, a company that sells streaming software solutions, I note, uncharitably).
• RSNA - Imaging - recommends a complete set of diagnostic quality images in DICOM format, and the use of reference pointers using WADO - View, Download and Transmit to 3rd Party - agree with the proposal of DICOM and XDR and XDM, with comments about practicality of a PKI, and suggestion to include XDS.b also (nothing surprising or offensive to me here, since I helped edit this comment).
• Ascension Health - Imaging - recommend dropping single sign on (due to their negative experience trying it) - also report difficulties with using links (URL embedding) in some systems - warn about the diagnostic quality of displays and the very poor viewing software tools that are state of the art - mention that network image distribution (CD replacement) solutions are geared to providers and not patient portals - View, Download and Transmit to 3rd Party - want to remove the entire provision due to issues with codes, DIRECT protocol, CDA, etc., but do not comment on imaging at all
• HIMSS EHR Association - Imaging - support requirement but via link and without single sign on - View, Download and Transmit to 3rd Party - recommend deferment to Stage 3, but do offer constructive suggestions about combining View in non-diagnostic format with option to Download DICOM images, and also suggest that "the patient should be able to identify the location of a study to be referred to another provider" (not entirely clear what this means) - specifically oppose the inclusion of a requirement to Download DICOM images though, distinguishing the EHR from the PACS, stating that DICOM viewers are not available online (!) - recommend staying with CD or DVD or USB - and get this, "electronic communication of DICOM images ... is still a new area and will require more discovery" - and they object to having to import DICOM images and prefer a "significant subset" of JPEG images instead (my overall assessment of these comments is that they are a little schizophrenic and probably compiled from several contributors with varying degrees of experience with imaging)
• HIMSS - Imaging - what about non-digital practices and in-office versus outsourced imaging - does immediately available mean when image is taken or after narrative is produced ? - View, Download and Transmit to 3rd Party - technically challenging - images in separate PACS - DICOM is not the best "patient facing" standard - link to PACS from EHR works for [physician] viewing but not for patient portal - DICOM images need specialized viewing software and are too large (for viewing and for DIRECT transport) - same "the patient should be able to identify the location of a study to be referred to another provider" as the EHR Association
• Medical Information Technology - Imaging - support a link without single sign-on - View, Download and Transmit to 3rd Party - portal is separate from PACS, file sizes are large, "reference" images might be sufficient, use CD rather than on-line, DIRECT is too new to adopt, transmission begs the question of to whom and recipients can't handle images
• SRSoft -  Imaging - the DICOM images are in the PACS and the EHR does not have them so don't specify a format - need to specify either a limited number of systems or a standard for the link to where the images are needs to be specified (this seems to contradict their request not to specify a format) - Download and Transmit to 3rd Party - usual comment that it is the PACS's responsibility and not the EHR's
• American Academy of Ophthalmology - View, Download and Transmit to 3rd Party - applauds the adoption of DICOM but wonders how imaging equipment vendors work with the EHR and ask is it OK to have a separate "image management system" (yes ! someone who gets the idea that Certified EHR Technology is distinct from a monolithic EHR system)
• Epic via University of Michigan Health System Meaningful Use Workgroup also the same Epic comments from University of Miami (who liked them so much they submitted it twice and then a third time and then a fourth and fifth time) and again from the Martin Health System and Metro Health Hospital and The Methodist Hospitals and Fairview Health Services and Sutter Health and Parkview Health System and the Everett Clinic and Dayton Childrens' and UMDNJ and NYU Langone Medical Center and Hawaii Pacific Health and finally as submitted by Epic themselves - others like the Community Health Network just stated they had read and agreed with Epic's comments - Imaging - concur that DICOM is not needed for that objective and PACS images do not need to be duplicated - concerned about single sign on if two systems - View, Download and Transmit to 3rd Party - images are not in the EHR but the PACS - patients would need DICOM viewers - size of the images is a problem - disks are better (also if you look at some copies of this, there are some pretty funny "remove before submitting to ONC" notes that say things like which versions support what and how much it would cost to retrofit, etc.; how embarrassing, both for Epic and their lackeys at these institutions)
• American Academy of Pediatrics - general comment "appropriate and necessary standards and implementation specifications do not yet exist to allow for the accessing of images and imaging results through certified EHR technology" (wow, that's depressing)
• JBS International - View, Download and Transmit to 3rd Party - concurs with the use of DICOM and "supports that greater image sharing capabilities for patients will empower individuals with and without a disability to have a greater role in their own care coordination and reduce the amount of redundant and duplicative imaging-oriented tests performed" - also comments on the need for the download and transmission capabilities to be universally accessible to support those with disabilities
• Society for Participatory Medicine - Imaging - support streaming links "without the delay related to use of DICOM file transfer and without the requirement to install additional software beyond the standard web browser itself" (presumably they are referring to a zero footprint viewer) - also emphasize that patients should have same access as providers (yeah, patient empowerment) - and in a second comment that it should made made available to the patient at the same time as soon as it is made available to the physicians - and in a third that four business days is "barely acceptable" and 48 hours would be preferable
• Markle Foundation - general comment - "When the VA enabled patients to download their information, the private sector responded by demonstrating a wide range of applications that made that information useful to patients (e.g., making it easier to know when to take medications, storing medical images, and connecting with peers who have similar health conditions)." (I guess by the way, that the ONC didn't conclude that if the VA can do it, private industry can)
• Abbeville Area Medical Center - Imaging - wanted to be clear that a certified PACS would be OK rather than putting the images in the "main" EHR
• Guthrie Health - another Epic user but these guys actually made (some) of their own comments - Imaging - results OK but NOT images - concerned about bandwidth consumption in their rural setting and that "a single reader will not all allow viewing of all imaging formats" - View, Download and Transmit to 3rd Party - just quoted the standard Epic spiel
• Bill Russell MD Health IT Consulting - Imaging - "immediate access to images from certified technology is of high value to [long-term post-acute-care] LTPAC physicians ... addresses a weakness in diagnostics in the setting, where studies are obtained portably, equipment and positioning are suboptimal"
• ACR - Imaging - strongly supports - agrees with single sign on - encourages interaction with radiology community and mentions WADO as an example of something ONC should be familiar with (you mean to say perhaps they weren't ?) - View, Download and Transmit to 3rd Party - silent on this, sadly
• Wisconsin Health Information Technology Extension Center - Imaging - concerned about single sign on solutions that don't actually provide access to images or need additional (costly) third party "modules"
• New York Hospital Queens - Imaging - wanted clarification that this did not include photography or ECGs - states that "the technology has not matured yet to facilitate exchange [of images]" - also says there are no standards for ECG exchange (yes there are, too many of them) - mentions the need for a CCOW-like function for synchronizing the patient and study and authenticating the user
• CPSI - Imaging - PACS and EHR are separate - link only - no single sign-on - View, Download and Transmit to 3rd Party - images are in separate PACS - norm is CDs with viewer - viewing not possible via portal - download technically difficult - "identify the location of a study to be referred to another provider" (same language as EHR Association)
• Kentucky Governor's Office of Electronic Health Information - Imaging - clarify images versus results - images are big - is a link sufficient or must EHR copy? - View, Download and Transmit to 3rd Party - didn't address images specifically but did expect that transmission of data to HIE through which patient should interact should suffice in lieu of access through a portal
• STI Computer Services - Imaging - same language as EHR Association - no single sign-on - View, Download and Transmit to 3rd Party - includes parts of same language as EHR Association
• Intermountain Healthcare - Imaging - does not support access to images through the EHR - "the infrastructure to display images from all possible modalities, along with all possible technology solutions within the ambulatory setting, would require huge numbers of costly interfaces to integrate the images into the EHR technology"- View, Download and Transmit to 3rd Party - "does not support unbounded expectations of downloading images that may contradict local or state policy" (that's an interesting one; how could there be a local or state policy that prevented patients from downloading their own images, which would contravene the patient's access rights to their own record under the HIPAA Privacy Rule ?)
• Pharmacy e-Health Information Technology Collaborative - Imaging - references the "ANSI accredited" HL7 Pharmacist/Pharmacy Provider EHR Functional Profile (including access to images)
• GE Healthcare (both a covering letter, and the public comment form filled in) - Imaging - access via link not copy and no single sign-on (standard EHRA "beyond the control" spiel) - View, Download and Transmit to 3rd Party - covering letter is silent on this, but the comment form describes images as being in the PACS not the EHR, how the provider may have a link but not the patient portal, DICOM images need a specialized viewer and are too large, and recommend against "the DICOMS [sic]" being a stage 2 criterion, industry standard is CDs with "pertinent" images, and "view technology does not allow such capabilities via a portal" - for download they say "getting access to images in order to enable download will be a challenge ... we suggest for Image Download that patient ability to identify the location of a study to be referred to another provider as the certification criterion" (standard EHRA language)
• UNC Health Care - asks if the PACS have to be certified if it provides the image viewer launched from the certified EHR?
• Missouri State Chiropractors Association - View, Download and Transmit to 3rd Party - requiring DICOM or even digital images is an "undue burden on the chiropractors and other smaller medical providers who do not have a digital system" - shouldn't have to scan in plain films
• Greenway Medical Technologies - Imaging - which "imaging tests" included ? - will patients link through PACS with another login ? - what about security ? - single sign-on is beyond the control of the EHR (standard EHR Association language again) - View, Download and Transmit to 3rd Party - entire EHR Association boilerplate
• Texas Medical Association - Imaging - link from EHR to inpatient radiology systems is OK, but "for ambulatory EHRs, image and report interfaces are not yet standardized to where all radiology system vendors are using the same interface so that physicians do not require a separate interface for each system" (this may be true for reports but I am surprised they think that is true for the images)
• Patient Privacy Rights and a second copy - Imaging - patients should be able to "receive" images - View, Download and Transmit to 3rd Party - four days is far too long, should be real time
• ICSA Labs - Imaging - need narrative as well as images so change "and/or" to "and" - View, Download and Transmit to 3rd Party - [for any information] transmission is too burdensome for provider, should place the responsibility [for transmission] on the patient or other entity (I guess they are trying to distinguish between downloading and transmission)
• Radiology Business Management Association - Imaging - agree - View, Download and Transmit to 3rd Party - 'EHRs should be both "image enabled" to view images via such links and capable of downloading and uploading images from portable media (e.g., CDs)'
• Minnesota eHealth Initiative - Standards to Access Information - should include simple formats like JPEG or TIFF - "not practical for patients to have DICOM viewers in their iPads/laptop at home" (not sure why they think TIFF images are so easily viewable) - View, Download and Transmit to 3rd Party - real time is burdensome should be "on request"
• Philips Healthcare - Imaging - discusses DICOM WADO at length and suggest establishing a set of minimum  security requirements then evaluating WADO versus many current PACS "non-standards based approach" - also asks if EHR with link to PACS need to be certified as bundle" or separately - View, Download and Transmit to 3rd Party - silent (with respect to images)
• Stamford Hospital - Imaging - is a link sufficient ? - are non-radiology images such as [scanned] patient charts and photographs required ?
• Clinovations - Imaging - need to distinguish between images and results - discusses practical aspects of EHR link to embedded PACS viewer (esp. tracking "availability" or "clicked on") - not everyone has PACS or digital imaging
• First Insight Corporation - Imaging - worried about dependency on "imaging vendors" - how does CMS "enforce" this on imaging vendors (? required to be certified) and how is security of imaging system handled
• Practice Fusion - Imaging - link and no single sign on (paraphrase EHR Association) - View, Download and Transmit to 3rd Party - images are on PACS, DICOM requires viewer, images are big and what about low bandwidth connections, suggest deferral (standard EHR Association talking points)
• NextGen Healthcare - Imaging - support link, opposed to storing images in EHR, opposed to single sign on - View, Download and Transmit to 3rd Party - images are on PACS, suggest HIE or continue to use CDs with viewer - images are big and complex
• Nationwide Children's Hospital - Imaging - agree - View, Download and Transmit to 3rd Party - images are not in EHR - need a DICOM viewer - images are big - better on disk on request
• CCHIT - Imaging - endorse DICOM standards
• Wisconsin Statewide Health Information Network - Imaging - "EHRs should support imaging functionality" and "support integration with an HIE for image query, retrieval, and viewing"- View, Download and Transmit to 3rd Party - support, but recommend HIE for the transmit portion (not an imaging-specific comment)
• Quality Health Network - Imaging - is a link OK ? - clarify if results or images - where will these large files be stored ? - View, Download and Transmit to 3rd Party - many concerns not specific to images but include suggestions to "just start with results" and use an HIE community portal
• Oklahoma Foundation for Medical Quality Health Information Technology Group - Imaging - concerned about cost of interface - most ambulatory EHRs do not contain PACS link 
• Lakeland Health Care - Imaging - agree that link is the best way - opposed to single sign on
• Success EHS - Imaging - express concern about the lack of specificity and standards and means to comply with single sign-on - lead to high cost of implementation and impact on other interfaces - View, Download and Transmit to 3rd Party - object to "enormous" DICOM files and download is not supported by their product
• Athena Health - Imaging - "support the comments of the EHRA" - link and no immediate access (single sign-on) - View, Download and Transmit to 3rd Party - "support the suggestion of EHRA to provide patients with the ability to identify a study for transmission to a referring provider instead of requiring functionality that provides patients with access to images for download"
• New York State Department of Health - Imaging - agree - "Would like to see the images imported directly and not have to be done manually. Also important to be able to share this information with other providers." - View, Download and Transmit to 3rd Party - agree, but who will pay for the expenses ?
• T-System - Imaging - supports on the assumption that link not importation is OK - want "immediacy" clarified "so as not to impose requirements on system technical performance, but to require that systems enable access in a fashion that minimizes the burden on the user" (? contradiction in terms ?) - View, Download and Transmit to 3rd Party - "generally agree" (no specific negative comment about images)
• McKesson - Imaging - link and no single sign on (paraphrase EHR Association) - View, Download and Transmit to 3rd Party - images are big, complex, elsewhere, suggest deferral (standard EHR Association talking points)
• Bipartisan Policy Center - Imaging - supports (via link or otherwise)
• Allscripts - Imaging - link and no single sign on (paraphrase EHR Association) - View, Download and Transmit to 3rd Party - standard EHR Association spiel
• QuadraMed Corporation - Imaging - link and no single sign on (standars EHR Association text) - also suggest having  image in two locations would "cloud the legal medical record ... if ... in any way modified ... during its incorporation into the EHR" (an interesting point, depending on what the recipient acts upon and the consequence of that action)
• Office of Health Information Technology -  Imaging - agree, including without havibg to login to a separate system - View, Download and Transmit to 3rd Party - agree with requirement to download as DICOM - "this will promote interoperability and exchange, reduce redundant and duplicative imaging-oriented tests performed, and empower patients to take a greater role in their own care coordination"
• Cardiology Advocacy Alliance - Imaging - support measure and mention access through PACS without details about the certification criteria
• HealthBridge - Imaging - recommends focusing on results not images
• Kaiser Permanente - Imaging - "ONC’s proposed certification criteria would require direct access to imaging results ... but without requiring specific standards. We support a flexible approach to standards at this point in time" (not sure what they mean by this; do they want standards or do they not ?) -"the term “imaging”encompasses a wide array of data types; thus we recommend limiting this requirement to radiologic images only for Stage 2, with the corresponding certification testing to include only radiologic image access" - View, Download and Transmit to 3rd Party - oppose entirely (not specific to images) "in part because such capability would require a more sophisticated set of tools and interfaces than what is enabled by the secure messaging specifications for provider-to-provider exchange"
• New Jersey Health Information Technology Extension Center - Imaging - "may be challenging for the EHR vendor to be able to include the ability to view images and/or narratives from the inpatient to outpatient setting and more so bi-directionally" - View, Download and Transmit to 3rd Party - no comment
• Regional Extension  Assistance Center for HIT (REACH) - Imaging - agree - need to test availability and workflow (usability and human factors) - View, Download and Transmit to 3rd Party - no comments wrt. images
• Healthwise - Imaging - "a copy of the image, e.g., advanced jpeg is satisfactory" (what is an "advanced" JPEG, one wonders?) - View, Download and Transmit to 3rd Party - no comments specific to images, but they did mention "should accommodate patient generated data to 'upload' into the EHR" (which would be interesting if one considered what that would mean for images)
• Memorial Healthcare System - Imaging - agree that DICOM is not necessary for this criterion - View, Download and Transmit to 3rd Party - paraphrase standard EHRA opposed language
• American Hospital Association - Imaging - described results of survey (Fall 2011) that showed 66% of hospitals had "PACS for Imaging Results" but comment that "it is not clear, however, that these images are always available through the EHR" - "recommend that ONC explicitly not require that the source of the image be certified, as many images are created in many different modalities" - View, Download and Transmit to 3rd Party - "very concerned about the practical implications of requiring the distribution of diagnostic images in this way [DIRECT], as they are very large and generally require use of specialized software to view. Radiology reports may contain more useful information with much lower technical requirements" - "Images are generally very large files, and would require that the individual downloading or receiving the file have specialized, expensive software to access the images. The effort required to make the images available would be tremendous"
• Sharp Healthcare - Imaging - "and/or" question about images vs. narrative - and if it is "and" images, just radiology, or also cardiology and pathology (recommend only radiology) - also recommend "that the image required is clinical quality rather than diagnostic" (aargh ! I can already imagine the gnashing of neurosurgeons' teeth and the salivating of plaintiffs attorneys)
• American Dental Association - Imaging - ADA has adopted DICOM for image exchange, and believes "that the use of the DICOM format is highly desirable", but agrees DICOM is not needed for the viewing objective
• Partners Healthcare - Imaging - focus on report not images themselves - "in most cases, the text report is most meaningful to the ordering provider" - "many studies that result in one or more images when the image itself is intentionally never released to the ordering EP (barium swallow, cardiac cath, interventional radiology, etc.)" (an interesting comment, but if it is part of the medical record, should it not be available ?) - "it is unreasonable to require image exchange ... [if] a link to an external system accessed through the EHR is acceptable ... it is impossible to require the EP to take responsibility for transmitting data that is not housed in his/her CEHRT" (their use of impossible is hyperbole; anything is possible albeit possibly technical challenging, e.g., to pass on a request to transfer)
• Spectrum Health - Imaging - narrative and decision support (appropriateness criteria) may be sufficient to prevent overuse compared to images - clarify "and/or" - clarify that link is sufficient and images don't have to 'reside" in EMR - clarify limited to images read by a board-certified radiologist [presumably they are trying to exclude in-office imaging by non-radiologists like neurologists etc.] - View, Download and Transmit to 3rd Party - concerned that images may be burdensome because "it requires a single vendor for both imaging and EMR" and "Cerner and Epic for example do not have the top rated imaging software" - completely opposed to transmission (of anything) to a 3rd party
• American College of Cardiology - Imaging - "standards for the transmission of 3-D echocardiography images ... lag behind" (fair comment, though the standard is there, just not the implementation by the vendors) - also concerned about adoption "image viewing relies on the employment of a strict DICOM standard that does not exist today ... physicians continue to receive studies on disk that cannot be read by a PACS system, let alone an EHR" so recommend against core measure - but "the imaging-related provisions ... of [the] standards, implementation specifications and certification criteria do not go quite far enough ... many vendors of cardiovascular imaging equipment claim that the format of stored files is DICOM compliant; however, the reality is that this is frequently not the case ... the ability to view a “DICOM compliant” study created by one vendor with a second vendor’s DICOM viewer that is not guaranteed ... this problem permeates the market ... ONC clearly fails to appreciate this reality, at least not for cardiovascular images ... to execute successfully, the specific components of DICOM compliance need to be specified ... ACC urges ONC to include this requirement in the final rule." - they also say "require that the viewer application maintain the
  aspect ratio of the original image (i.e., square should remain square), rather than reflect the
  aspect ratio of the monitor" (wow, are there EHR viewers out there that are really that lame?)
• Keith Boone (personal comments, not on behalf of GE) - "I very much would like the opportunity to download my images, but not all practices have the tools to manage patient images. This capability is more common in specialty practices and hospitals that use imaging frequently. I urge ONC to keep this capability, but to make it optional, so that providers who use a lot of imaging can support it. I also strongly support the use of the DICOM standard for images formats. While patients may not readily have DICOM viewers, it is clear that they are able to locate them on the web, and there are numerous freely available viewers that can be found. Smart providers and vendors supporting the View/Download/Transmit capabilities can readily make links to these DICOM viewers available."
• American College of Physicians - Imaging - "though we support the use of DICOM for many purposes, we agree that the DICOM standards should not be required for displaying images and their associated narrative" - View, Download and Transmit to 3rd Party - "we support the availability of DICOM capability but not to the exclusion of simpler mechanisms for delivering images e.g. images as JPEGs, as JPEGs or TIFFs within Word documents or PDFs, and the way they are often delivered to doctors at present"
• Healthcare Management Systems - Imaging - link to PACS only - in the future use HIEs - View, Download and Transmit to 3rd Party - "The requirement to have images available for view, download and transmission will be very difficult and may cause technical issues resulting in poor performance and increased provider and patient dissatisfaction with the EHR"
• Arizona Hospital and Healthcare Association - View, Download and Transmit to 3rd Party - general concern about "downloading large volumes of PHI" and that OCR (under HIPAA) should regulate this, not CMS
• Future Health - Imaging - a DICOM image should not be required - "in review with the patient a jpeg ... is acceptable" (good point, but review with a patient is not the only EHR use case) - access should be restricted to those the EP ordered "rather than all images on record for the patient" (why???? doesn't the EP need all available information for decision making?) - how long must access be for (contrast with retention requirements), esp."immediate" access
• Adventist Health System - Imaging - restrict to radiology - convert to JPEG due to large file sizes - View, Download and Transmit to 3rd Party - again, restrict to radiology and convert to JPEG due to large file sizes - "do not believe diagnostic quality is necessary for patient viewing"
• Electra Memorial Hospital - Imaging - link and no single sign on (standard EHR Association language) - View, Download and Transmit to 3rd Party -  images are in separate PACS - norm is CDs with viewer - viewing not possible via portal - download technically difficult - "identify the location of a study to be referred to another provider" ( (standard EHR Association language)
• HealthFusion - View, Download and Transmit to 3rd Party - DICOM images large and costly to duplicate - "point-to-point connectivity with multiple radiology centers places and unfair burden on EP" - suggest store in one place and exchange just the link to be the method to make both report and images available
• Siemens Healthcare - Imaging - suggest access via pointers to PACS viewers only (not copy of images into EHR) - "reference pointers as metadata in APIs" - also suggest PACS viewer certification mechanism - View, Download and Transmit to 3rd Party - make modular criterion to allow base EHR to integrate with others - clarify which 3rd parties (not friends and relatives) - SMTP (part of DIRECT) is not suitable for transmitting images - suggest focus on "ability to view and download images by known, registered patients and their authorized, registered representatives" - suggest excluding images from EHR Technology and instead "including this as part of a supplemental certification ability for HIT that complement the EHRT" - until then use CD/DVD/USB per IHE PDI
• Cerner - Imaging - what does "and/or" mean - suggest images "and" narrative - just radiology or also cardiology and pathology - suggest cardiology OK but not pathology - suggest a "basic viewer" (panning, zooming, scrolling a stack) is required not just static small images or embedded images in reports - View, Download and Transmit to 3rd Party - should be consistent with Imaging rule - "do not believe diagnostic quality is necessary for patient viewing so do not suggest a standard for image viewing for patients ... original images may be provided to the patient portal or PHR with diagnostic quality viewing enabled, but the diagnostic quality viewing capability should not be required of the system supporting the patient access for viewing" - DICOM format download of diagnostic quality images should be required (e.g., to allow patient to burn their own CD) - separate certification criteria if optional - DIRECT should not be used due to large file sizes - JPEG capability should also be present for transmit -  clarify that data must be transmitted, not just link (static links may go stale) - how long must remain accessible
• Steindel, Steven - Imaging - "DICOM is the standard used by the medical imaging community and is required for diagnostic quality images ... DICOM embraces other common image formats that are also medically useful such as JPEG but that is not generally recognized ... criteria should be silent as to specific standards but provide suggestions for common ones and perhaps a short description of when use of that standard is appropriate" - View, Download and Transmit to 3rd Party - no image specific comments

And that's it ... whew ... I don't envy the job ONC must have had sorting through all these ... my interpretation will follow in a subsequent post.

David