Tuesday, September 4, 2012

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".


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).


Sunday, September 2, 2012

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.


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.

Saturday, September 1, 2012

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.


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.