Tuesday, August 28, 2012

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

Posted by at 2 comments:

Friday, August 24, 2012

ONC Whimps Out On Image Download in Meaningful Use Stage 2 Final Rule at GE's Request

Summary: ONC drops Stage 2 requirement to "download and transmit" DICOM images to third-parties, blurring the distinction between viewing and transmission; GE's negative comments at least partly if not wholly responsible.

Long Version.

You may recall that when the proposed rules for Meaningful Use Stage 2 were promulgated, many of us were ecstatic to see that a lot of attention had been given to imaging; there were some very promising features that I reviewed here.

Yesterday the final rules were released (you can find them at this HealthIT.gov page). I was excited and took a quick look at the (474 page) ONC Final Rule, did a search for "images", etc., only to be immediately disappointed to see that they had DROPPED THE REQUIREMENT for images to be "downloaded and transmitted to a third party".

Aaargh !

Here is a preliminary look at ONC's discussion of the comments and their response, which begin on page 76 of the final rule, and which I quote in its entirety here:

"Download and Transmission of Images
Comments. Commenters generally supported the principle of providing patients with access to images, however, only a few commenters outright supported our proposal. One commenter that supported our proposal suggested that images also be included in the “view” part of the certification criterion and stated that diagnostic quality is unnecessary for patient viewing. They encouraged us not to suggest a standard for image viewing by patients. Another commenter asked if we intended for images to be available for viewing in a basic distribution viewer or if small images embedded in the report or images viewed without tools in a browser would meet the certification criterion’s intent. They suggested that we require a basic distribution viewer to be part of the “view” portion of the certification criterion. One commenter stated that if we did not specify DICOM as a requirement for certification, that we should at least make available the option for EHR technology to be certified to the standard for the purposes of image downloads.

Several commenters strongly opposed or requested that we remove the capability and proposed standard. These commenters stated that including images for download and transmission by a patient would be a challenging requirement. They also contended that this capability exceeded the requirements in CMS’s proposed rule. Additionally, these commenters stated that images are typically stored in a system separate from EHR technology (i.e., a PACS system) and that this requirement would add significant complexity and burden to the certification criterion. They followed this comment by stating that the industry norm is for CDs with pertinent images to be given to a patient with an image reader that allows for viewing. A similar point was made by other commenters who stated that requiring DICOM for the transmission would force the recipient of the images to have a DICOM compliant viewer and to import the images into that viewer before they could be viewed. Many commenters noted that an image’s average file size would present significant storage and cost challenges for online downloading and transmitting. The JPEG file format was recommended as a potential solution since patients did not necessarily need diagnostic quality images.

Response. In consideration of the comments received and the complexity and potential burden identified by commenters, we have decided to remove the requirement for images to be available for download and transmission to a third party. We believe further industry dialogue needs to occur with respect to images and our policy goal of enabling patients to have ready, online access to their images. We expect to include this topic on the HITSC’s agenda for the next edition of EHR certification criteria we would adopt through rulemaking and intend to propose a requirement for online image access in a future edition of this certification criterion."



Images are big ? Hard ? Need a viewer? That's news ? Some whiny EHR vendors aren't ready for them yet? Boohoo.

Further industry dialog is required? What a cop out.

JPEG is sufficient? Patients don't need diagnostic quality images? Who are these clueless assholes?

Lost in the analysis of the comments seem to be two fundamentally important factors:
  1. The whole point of the "download and transmit to a third party" requirement is the "third party"! If that third party is a neurosurgeon or a radiotherapist or a pulmonologist or a rheumatologist or any one of a multitude of specialists with imaging expertise, your damn right they need diagnostic quality images.
  2. The intent of the incentives is not necessarily to apply to one single monolithic system that a recipient of those incentives might purchase; rather they are to motivate providers to better serve patients, whether it requires the use of one piece of technology, or two, or twenty; whether the images live in a traditional "EHR", or separately in a "PACS", should be irrelevant; what these systems are called and who sells them is irrelevant; PACS can contain functions of "Certified EHR Technology" too!
Not to the mention the fact that anyone who has ever windowed a CT image in their lives knows that JPEG as an interchange format for such images is completely inadequate.

The paternalistic attitude towards what the "patient" needs is equally depressing. Why doesn't the patient deserve a diagnostic quality set of images too? Frankly, any patient who can use a web browser can also use a DICOM viewing app quite handily, thank you very much. Many patients these days seem to be far more computer literate than the healthcare providers who are looking after them.

The comment that "the industry norm is for CDs with pertinent images to be given to a patient" is quite telling, in that it displays ignorance of the fact that the AMA safety panel made it quite clear many years ago (in a statement developed jointly by the professional societies and the imaging industry vendors) that a "complete set of diagnostic quality images" was the standard of care that needed to be met, not just "pertinent images" (begging the question of the definition of "pertinent").

The "norm" in the US right now is indeed the use of CDs, and fortunately these are now well standardized, but I thought the whole point of the Meaningful Use exercise was to move to doing things on the network, to make things better, not just ratify the existing, unsatisfactory, status quo. Sadly, the opportunity has been well and truly squandered this time around :(

There seems to have arisen tremendous confusion with respect to the distinction between the "viewing" use case, and the "download and transmit" use case, and the comments as described in the rule making, and the responses, seem to have further blurred the distinction to the point of making the assumption that if one can view the images (in a proprietary manner if desired), there is no need for "download and transmit". Clearly someone has forgotten about advanced visualization, surgical or radiotherapy planning, comparison with priors whilst reporting and the myriad of other scenarios that invalid the simple viewing requirement, but there you have it.

One very depressing element of the response is the statement that "only a few commenters outright supported our proposal". Most folks probably assume that when a proposed rule is promulgated, that the merits of the proposed rule are apparent from the outset, and that comment is primarily being sought on what is "wrong" with it, as opposed to nice cheery "good job, keep it up" supportive comments, but that is not necessarily the case. In the absence of strong supporting comments, anything that garners significant opposition might get dropped, as appears to have happened in this case.

Unfortunately, in retrospect, the ACR's comments did not specifically mention the "download and transmit" requirement, in positive or negative manner, though the RSNA's comments (to which I contributed a little) explicitly did. Surprisingly, or so I thought at the time, MITA (NEMA) did not submit comments.

As it turns out, if one goes searching to find out just who the naysayers are, amongst them turn out to have been none other than our friends at GE Healthcare; here is the text of their comment, much of which you can then see reflected in the ONC's summary and response. I wonder if GE has a product that (currently) does not support "such capabilities via a portal", or that is not integrated with their PACS in this respect? I guess they haven't bought LifeImage yet.

With GE in opposition, it is not much wonder that MITA made no comment at all on the MU Stage 2 rules, apparently because the vendor members "could not reach consensus"; at least that implies that some vendors must have been supportive, or MITA's comments would have perhaps been negative in this respect. I remain disappointed that MITA senior leadership could not have acted more strategically for the long term benefit of the entire industry, but they are, when all is said and done, a trade organization and beholden to their members.

All that said and done, at least ONC didn't drop the (separate) image viewing requirement, which still stands, albeit with links and without single sign on; that is what GE required in their comments.

By the way, if anyone knows how one can go about getting the entire set of comments that were submitted, what I believe the government calls the "docket", please let me know; I would have though this would be easy, and one would not need to make an FOI request, but I haven't been able to find them yet. It would be interesting to review them all to see how many other comments were negative, in the GE vein, or whether ONC just choose to prioritize GE's negative comments over RSNA's positive ones.

David

PS. There were also the following additional comments also mentioned:

 "Comments. We received the following additional comments that did not fall within the general scope of the comments summarized above. One commenter proposed that a secure hyperlink to the image, supplied by the radiologist and conveyed via the Direct Project standard, become the method of making DICOM images and radiology reports available to patients and ordering providers. A commenter suggested that for image download a patient should be able to identify the location of a study to be referred to another provider as acceptable for the certification criterion. Last, a separate commenter asked that we specify for the “download and transmit” requirements, the IHE Portable Data for Imaging (PDI) profile.

Response. We appreciate commenters’ feedback. Given our decision to remove the requirement for image downloading and transmission to a third party, we will take this feedback into consideration for our future work with the HITSC as well as our next rulemaking."

PPS. If you are interested in an analysis of the "rest" of the final rule-making, the usual suspects have started their usual through analyses; here are Keith Boone's "What Changed" and John Halamka's "Rules Released" blog entries.


Posted by at 3 comments:

Sunday, August 19, 2012

A Simplified Medical Document format based on static web pages semantic annotation

Summary: Static HTML web pages augmented with semantic markup are sufficient to use as medical documents, such as radiology reports, and can satisfy all the goals of HL7 CDA, but by using only free and open standards used by all industries and consumers; RDFa seems to have advantages over MicroData for the semantic markup and is sufficient.

(Very) Long Version.

For some time I have been railing against the evils of HL7 attempting to extort fees from "users" of its standards; putting aside whether or not they have any legal or ethical basis to stand on, there is clearly a need to find a truly open alternative to HL7 CDA as a medical document format.

Once one stops drinking the "CDA is the way" Kool-Aid and starts down the road of exploring alternatives that are consumer-industry-based, one comes across a plethora of alternative options, ranging from de novo XML creations, through existing XML-based document formats used in publishing (such as DocBook and DITA), through to page-layout-based formats like PDF (which though managed by Adobe, is surprisingly open, especially compared to HL7).

But the more one explores these questions, and especially as one searches the web for information with a browser, whether it be from one's desktop, laptop, tablet or phone, the more obvious it becomes that the choice of ubiquitous open document format is already clear - it is the HTML web page.

Most folks know that web pages are HTML files served up for rendering to browsers, and in contemporary web usage these typically contain a lot of dynamic (scripted) content or even require plugins for rendering of multi-media content. But they can be simplified down to their original basics, their bare essentials, files that contain a single page of static information without frames and making use of relatively limited rendering flexibility, and most importantly, without "hyperlinks" to external content; i.e., they can be self-contained and detached from their environment and remain fully meaningful. This is analogous to the use of HTML as a common email message format, for example, except without the cutesy pictures and embedded links to advertising in the spam that one receives. These are, by any other name "documents".

Formalizing the use of static HTML for medical document use would require placing constraints on what HTML base features (version) were required and what features (scripts, frames, etc.) were prohibited, but that is easily done. And for XML aficionados, there exist XHTML flavors of HTML that browsers happily render.

It turns out that folks have been suggesting to HL7 for many years that XHTML should be used in place of CDA's own flavor of narrative content specification, and that it is likely that CDA R3 will take this course (see Keith Boone's blog post on "XHTML for CDA Release 3").

What about how to handle the identification and management information that is needed to use a document, and how to identify as any coded or structured content therein? Can this be done without inventing a medically-specific "header" or "wrapper" format around the HTML content, and most importantly, can it be done in a pan-industry standard way?

For years the "semantic web" folks have been trying to convince everyone to use standards like RDF to say stuff about web resources, and this finally seems to be coming of age, if for no other reason than the "enlightened self-interest" of the major search engine vendors, particularly Google, Bing and Yahoo. The more formal RDFa effort has been competing against the MicroData effort, but it seems that both will be supported and arguably there are some advantages to RDFa (and particularly RDFaLite if it proves sufficient).

What I propose is that we use either RDFa or MicroData to "semantically annotate" narrative content in HTML form so that the resulting "document" meets certain minimal requirements for identification, management, coded and structure information, sufficient for use as a medical document. I am further proposing that there not be a "header" at all per se, at least not in the traditional sense, nor that such information be confined to the HTML header (contents of the HEAD element). Rather such information can be distributed throughout the document, in the place where it naturally occurs in the narrative, and just be tagged as having a specific meaning. For ugly but important staff (like unique identifiers that are not human readable and do not need to be rendered), there would need to be a means to hide such stuff from visibility.

It turns out, not surprisingly, that I am not the first to suggest HTML based narrative content; I gather it has come up on the HL7 Structured Documents mailing list, and again I point you to Keith Boone's excellent blog, where he too has been considering this sort of thing; see for example "A Wickedly Fresh look at CDA through Microdata and HTML5"; Grahame Grieve has also been considering XHTML for his FHIR effort (which, by the way, he has contributed to HL7, with the proviso that it remain open and free; he is one of the good guys). But both these guys (if I am understanding them right) are still thinking "wrapper" and "header", and encapsulating the (X)HTML, and not using the HTML as the entire and complete document in its own right; see for example Grahame's description of his DocumentHeader resource. There may well have been other prior work along similar lines; I haven't attempted to perform an exhaustive literature search.

Let's get concrete now, and see what this sort of thing might look like. I will start with a toy radiology report, and then move on to a real one, and then consider another simple document that contains something else like vital signs.

Suppose we have a very simple CT Chest report that contains only the following information:


We can create a very simple minimal static HTML document that would result in this content being rendered in an ordinary browser; i.e., this:

 

 would result in this being rendered in a typical browser:

Ugly, but no worse than the typical plain text report one often sees. Obviously one can get more fancy and add prettier formatting, fonts, institutional details and the like, but this suffices for the purpose of a basis to start to semantically annotate this report.

So, now lets add a little RDFa markup that uses the existing identification and management information. Here we will do two things, markup the information, and in some cases add alternative (hidden) values for data that needs to be in a "standard" format, in this case the dates and times:

 

This does not change the resulting rendered output in the browser in any way at all, but it does let us extract the information using an RDF-aware tool; here for example, I have pasted the above HTML source into the RDFa/Play tool, and the result is a visualization that describes the extracted semantic content:


Here is the so-called "Turtle" (Terse RDF Triple) form of RDF that is also extracted by this tool (in the Raw Data panel):


The point here is not to learn the specifics of RDF, but rather just to recognize that the information that one would normally find in the "header" of a CDA document (or PDF or DICOM document for that matter) is extractable, and most importantly using conventional, non-medically-specific tools. Also, though the markup is not terribly pretty, it is clear and straightfoward.

Without getting into too much detail, the way this works is to specify one or more "vocabularies" that define the "typeof" something (in this case I have defined the document as being a "typeof" "RadiologyReport"), and the vocabulary is specified by the URL "http://www.dclunie.com/vocabulary/keywords/dicom/". That "entity" (thing) then has "properties" (which are a subset of "relationships"), several of which I have enumerated with text values, such as the "patientName" property. I am sure you get the basic idea.

What would need to be medically-specific would be the "vocabulary", and in this case I have defined a hypothetical one, in which I have started to use concepts from DICOM as properties of a hypothetical RadiologyReport document entity ("type").  What is more, there already exist many vocabularies that have been used for other semantic web activities (such as the Dublin Core for describing resources), as well as a more recent initiative in support of MicroData and RDFa (and reusable for either), specifically the schema.org effort. The latter, surprisingly enough, already includes some vocabulary intended for the markup of medical web pages, including a means of referencing existing medical codes through the MedicalCode entity. I don't know who was responsible for doing the medical vocabulary, but they have done a nice job so far.

Indeed, we can use some of the schema.org stuff as well as some of the more advanced RDFa features to markup our primitive report to include more than just the identification and management data in text form; we can code the procedure type, and we can code the diagnosis and impression. Here we are also going to use the "rel" attribute rather than the "property" attribute, since it allows us to point to a vocabulary term (resource) as a value, rather than plain text (this requires RDFa, not just RDFaLite, by the way). Once again, the rendered HTML in the browser looks just as boring, but the extracted semantic content is richer:


There is a little more fluff in this example, in order to introduce the mechanism for defining more than one vocabulary (needs the "prefix" attribute), since I have shown the use of RadLex and ICD-9-CM as sources of codes for the report content and the clinical history, respectively, and I have also used a RadLex Playbook ID for the CT procedure code. Note that in some cases I have defined the values as URL based resources (a la schema.org) and in other cases I have used the traditional coded "triplet" of value, scheme and meaning with schema.org/MedicalCode. I have also illustrated two different ways of hiding the coded content (using the "content" attribute or a "visibility:hidden" style; the former is probably preferrable), and that the data can be typed (see the xsd:string type for one of the codes). This is what it looks like in RDF/Play, visually:


and as Turtle:

 

Note that the visual rendering does not show the nesting ("chaining" in RDFa-speak), whereas the extracted Turtle does.

Another good tool for extracting the RDF content from the web page is the Green Turtle plugin for Google's Chrome Browser, which provides an extra tab that shows the semantic content when it is detected, and also provides an interactive graphic rendering of the semantic information that one can use to highlight specific nodes and their tuples (and which does illustrate the chaining visually):


OK, I am probably getting too deep into the technical details, so I won't go any further, since I don't want to detract from the primary message, which is that static HTML web pages with semantic annotation are sufficient to encode medical documents. To illustrate the point I will finish with two final examples.

The first is a "real world" radiology report that was distributed in plain text form via fax, which I then redacted to remove all identifying information (except the source institution), then recreated as a simple HTML page using limited formatting features, and to which I added the semantic markup for the identification and management information, as well as a limited amount of coded content along the same lines as the basic example above. I deliberately did not attempt to structure and code the bulk of the narrative, though this would obviously be possible, since I do not want to detract from the message that this mechanism is useful for existing reports, not just for future hypothetical structured content authoring systems.

Here is the original redacted content:

Here is a screenshot of the recreated HTML as rendered in a browser, with an attempt to preserve as much of the original formatting and style as possible, and with the insertion of synthetic values for names and identifiers and dates and times:


Here is the corresponding HTML source code:


and here is the Turtle extract:


To belabor the obvious, there is nothing radiology-report-specific about this approach, and so here is the final example of a single "vital signs" reading of body temperature, using an example from Bob Dolins CDA R2 JAMIA article (his Figure 4); here is the browser rendering, extended a little from Bob's example to render the date and time:

and here is the HTML used to generate it, with the semantic markup:


and here is the RDFa/Play visualization of the RDF tuples extracted from it:

In this example, I have chosen to imply that the referenced vocabulary defines an entity that is a VitalSignBodyTemperature, since I wanted to show a model of date, value and units, but alternatively I could have just used a schema.org MedicalCode reference to a SNOMED code like the CDA example did (but since SNOMED is a closed standard too, let's not go there for now).

Obviously there remain many details to flesh out, such as what constraints on HTML to specify, what basic vocabulary elements are the minimum mandatory set (without getting too carried away trying to reinvent or entirely map DICOM or HL7 headers or XDS meta-data), and what style-related issues raise questions of what the attested rendered content is. But I think that these are probably all surmountable.

In conclusion, I believe that we can do away with CDA entirely and resort to a pure web-standard-based document format with medical specifics defined only in constraints in the form of schemas, templates and vocabularies. I am deliberately glossing over the effort or complexity of defining adequate vocabularies (and free ones at that), but we have a large playing field to choose from and decades of experience if we have to do it over.

Instances of such a document format could be distributed and exchanged by all of the normal "transport" mechanisms for documents, whether it be via HTTP, ordinary email, one of the NHIN DIRECT flavors of transport, IHE XDS or XDR, on physical media, etc. I.e., as with all "documents", the transport mechanism is independent of the "payload" that is the encoded document itself, and all of the usual additional (non-medical-specific) security and digital signature mechanisms could be applied as necessary.

I propose that we should call such a new standard that would define the necessary constraints the "Simplified Medical Document" format (SMD, or SMDF perhaps), and to resolve that it should be and should remain a truly open standard; if necessary, we can produce an entirely HL7-free solution for the whole world to use without fear of the evil empire and their lawyers.

PS. Before someone mentions it, and I saw this raised as a comment on one of Keith's blog entries, at first glance this might seem somewhat reminiscent of the controversial "tagged data element" approach mentioned in the much maligned PCAST report (which I too criticized previously for a host of reasons), at least until one digs into the details of what was being proposed. I still disagree with most of that report, especially its access control suggestions; and I am not suggesting that relevant meta-data not be pre-extracted and indexed in the normal manner. Rather, the semantic annotation approach here is largely just a repositioning and reformatting of conventional document "meta-data". Nor is there a need for a new "universal language" as suggested in that report, except to the extent (and perhaps one could interpret the report in that way) that specific vocabularies do need to be defined (or re-envisaged) to support the RDFa or MicroData approach. In particular, I am not suggesting, as the PCAST report does, that "each unit of data [be] accompanied by a mandatory metadata tag that describes the attributes, provenance, and required privacy protections of the data"; quite the contrary. The PCAST report essentially suggests a data-unit rather than document-centric approach, and that is most definitely NOT what I am proposing. That said, the semantic annotation approach would indeed allow for "tagged data elements" to be extracted from documents as necessary, and they would be meaningful as long as sufficient parent and sibling context was also extracted and remained related. To be fair, there is probably some point at which the opposite approaches converge into a similar solution, however.

Posted by at 3 comments:

Friday, July 20, 2012

Office imaging systems revisited

Summary: An office-based CD importation system with a single centralized store and viewer dramatically improves ambulatory workflow efficiency (as one would expect).

Long Version.

An excellent article this week in JACR, entitled "Streamlining the Receipt and Upload of Diagnostic Images in a Clinic Setting", by Bartels et al from the UCLA Dept. of Neurosurgery, reminded me that it was time to take another look at the matter of how clinicians are coping with images, since it has been over four years (!) since I wrote a post about "Requirements for an 'office imaging system' for requesting practitioners".

The UCLA article addresses the entire process of receiving outside images through to viewing by the neurosurgeon, relatively formally as a process improvement initiative using the Lean (Toyota) methodology. The net result is summarized as reducing the neurosurgeon involvement in CD handling from 91% prior to the improvement to 5% after, largely as a result of introducing an automated import process executed by the clinic staff and providing a standard viewer for pre-loaded images. Automation of the staff import process was also described as significantly reducing their time.

The process is described as opening the (DICOM) CD (in iQ-View perhaps, or possibly in some GQC-specific importer), pushing to the Global Care Quest (GCQ) Neurosurgery cloud-based PACS, and using some pre-caching (auto-load) strategy that was then improved by the use of higher bandwidth connections (from 10Mb/s to 1 Gb/s). The process handles CDs brought prior to the visit as well as those brought to the clinic "at the last minute".

Non-DICOM CDs are specifically mentioned as being handled with a "red sticker" to cue the neurosurgeon to fire up the native CD viewer; how often these are encountered is not mentioned explicitly, but presumably they account for much if not all of the residual "5%" that requires physician handling the CD.

It is gratifying to see that this relatively simple process is indeed feasible and practical in an ambulatory setting, and furthermore on a relatively large scale, using ordinary components, despite some comments from an orthopedic surgeon on my previous blog entry that this sort if thing was "completely unrealistic".

We have certainly seen over the last decade that importation of outside images (and reports) into the hospital (enterprise) PACS has become routine and the standard of care, but it is gratifying to see that the ambulatory setting is being addressed too.

The article was a bit light on technical details though, particularly of the existing infrastructure that was being re-used, and I would be interested to know why they use a dedicated neurosurgery PACS, and also why it is cloud-based. Digging into this a bit deeper, it turns out that Global Care Quest (GCQ) is actually a commercial spin-off from this same UCLA neurosurgery group, and this description in the press describes some of the disparate data source, multiple site and mobile device integration problems that it was designed to address. There is a video of one of the authors, Neil Martin, who is the chairman of Neurosurgery, describing it. I get the impression that since they have sophisticated critical care informatics solution in place, it made sense to leverage it for the ambulatory setting too, though that does raise the question of how smaller less sophisticated "offices" would address the same problem without a pre-existing infrastructure in place.

Locally obtained images were described in the article as being pre-fetched into the neurosurgery PACS from the UCLA PACS, so that a single viewer provided a longitudinal view.

One has to wonder what all the other ambulatory departments that are heavy image users (like orthopedics, neurology, rheumatology, pulmonology, etc.) are doing about importing and why there isn't a pan-UCLA solution in place.

Certainly, using an outside provider to host the system in which the imported images live makes a lot of sense, compared to neurosurgery having its own IT department (i.e., the usual "software as a service" benefits), but given the large size of images and the cost of bandwidth (which the authors noted as an issue that they addressed), having an on-site archive (even if managed by outsiders as a contracted service) might make more sense in other situations. I.e., "outsourcing" does not necessarily imply the need for "off-site". For smaller offices for whom external access or collaboration is not a requirement, for whom long term archival is not an issue, and who cannot afford the bandwidth, on-site may be a better option.

The article also did not specifically address the matter of identifier reconciliation on import, and whether this is handled at all, manually, or using an automated approach (whether based on IHE Import Reconciliation Workflow (IRWF) or homegrown procedures).

In the long term, of course, we all hope that CDs (or any other form of physical media) will go away, as the producers of images find more "modern" ways to get them to the consumers, whether it be via external portals indexed via registries (a la the original XDS-I model), or regional (central) repositories (a la the Canadian DI-r or various "cloud-based" image storage and distribution providers), informal push networks, or just by inclusion of images as part of every patients' external PHR, such as espoused by the RSNA's Image Share project. Until questions such as those about cost, scalability, sustainability and access control are addressed though, for many people these more ambitious approaches remain elusive.

But in the short term, the UCLA Neurosurgery experience is further evidence that an individual ambulatory facility can take control of their own destiny, minimize the inconvenience and mazimize the utility of the existing CD-based infrastructure, using tools that are becoming, if not already, off-the-shelf commodities.

David

PS. There do now exist third-party importers that claim to address some if not all the proprietary formats, including Amicas and iSite (iSyntax), so even the residual "5%" problem could be addressed with a more sophisticated importer, though admittedly there will always remain the problem of unburned, un-finalized or physically damaged CDs. I did take a crack at the Amicas CDs myself a while back (see "ConvertAmicasJPEG2000FilesetToDicom"), but reverse engineering the iSyntax format looked like way too much effort, so I am glad somebody has implemented it.

PPS. The article does mention training the surgeons to use a single "universal" viewer; I wasn't able to tell from the GCQ site whether or not their viewer was compliant with the IHE Basic Image Review (BIR) profile, which was specifically developed with neurosurgeon involvement to satisfy their review needs; as far as I know, GCQ has not tested the product at an IHE Connectathon.

PPPS. After the recent debate in the UK Imaging Informatics Group, I hardly dare mention reports, and it may be that the neurosurgeons are not all that interested in the radiologists' reports, but I would like to know how and if the outside reports are being imported if present on the CD or provided in some other manner (fax, email, scanned paper document, EHR, PHR, RIS, HL7 V2 feed) and how they are handled in GCQ and linked to the images.

PPPPS. There has a lot written about the mechanics, benefits and policy issues of importation of CDs before, and I wouldn't want to ignore the literature on this subject, a lot of which can be found with a Google Scholar search, a search of the Aunt Minnie Forums, and Yahoo pacsadmin, as well as various SIIM materials; I call attention to this article though, because it is specific to an ambulatory setting and involves non-radiologists. I was a bit surprised though, when I realized that the article had absolutely no references at all (and that this got past the reviewers and editors)!


Posted by at 3 comments:

Saturday, June 23, 2012

Oracle v. Google: Opening the Closed HL7 Standard (including CDA) ?

Summary: HL7 is a closed standard; HL7 claims to require (expensive) membership to implement its standards, including CDA; the Oracle v. Google ruling that API's are not protected by copyright suggests that HL7 may have no legal basis to prevent implementations by non-members or to extort a fee; but until this is clarified, perhaps CDA should be avoided in lieu of more open alternatives.

Long Version.

Unlike the DICOM standard, whose governing body requires no fee for implementation, the HL7 family of standards (including V.2, V.3 and CDA, amongst others) are not "open standards" in this respect. In particular, the HL7 organization that publishes the standards currently states quite explicitly that organizational (not individual) membership is required in order to "use the material" (HL7 International IP Policy). The cost is decidedly non-trivial, requiring a continued annual contribution of between $1260 - $19,635 (HL7 Membership).

There is not universal consensus about what exactly the definition of an "open standard" is, and how it relates to the matter of fees; this is well summarized in the Wikipedia entry on the matter. Fees for use can be needed in two contexts, as fees to the organization in control of the standard, and as royalty-fees for patents. The European Union definition, for example, precludes the charging of fees of either type; the same goes for the Open Source Initiative's definition, which further requires that the standard also be freely available. 

Since many (if not the majority) of contributors to activities like DICOM, HL7 and IHE are large organizations, and since the membership or fees demanded by HL7 pale in comparison with other costs (like that of EHR certification for Meaningful Use in the US), this has not been a very big concern to decision makers. Just as most global technology companies are not that concerned about patent issues, being participants in patent portfolio sharing cabals, it has sometimes been difficult to promote the case for openness, when a conflict with convenience or expediency arises. As a consequence, the criticality of this issue for open source software developers, non-profit organizations and small users is routinely overlooked.

CDA is a case in point; both IHE, and more recently DICOM, have been nonchalantly pursuing a course of encouraging the use of CDA, and developing profiles (or what HL7 calls "implementation guides") that rely on the underlying CDA mechanisms, without some of us realizing, frankly, that we were building upon an inherently closed standard. The problem has been compounded by the adoption by the ONC Healthcare IT Standards Committee in the US (in the context of Meaningful Use), and in other activities like the European cross-border epSOS pilot project. Indeed, the ONC Proposed Rule for the Phase 2 of Meaningful Use contains language that would preclude the use of "competitors" to CDA for encoding of patient summaries (you recall the bitter fight between HL7 and ASTM over CCD versus CCR).

What HL7 International thinks about the interpretation of their IP Policy with respect to CDA implementation is explicitly reiterated in this response, "Questions & Answers on the use of HL7 CDA and required licensing".

Obviously, it would be unfortunate if there was to be discrimination in the market place against smaller participants (both implementers and users), as a consequence of imposing a mandatory requirement to use fee-based standards. Surely this is not the intent of the policy makers; perhaps they may not have been sensitized to this concern, though this would be surprising, given the sophistication of the stakeholders.

I am not involved in HL7 politics or administration, so I have no insight into their motivation or their future plans. I have heard that they are considering changes to their policy, but whether it is to make things better and relax these constraints, or to make things worse in order to maximize their revenue stream, I have no idea.

Some folks pointed out to me though, that there may be hope, regardless of HL7's intent or desire, in the form of the recent order from the court in the case of Oracle v. Google. You may recall that this litigation was in part related to the independent Android implementation of a sub-set of the documented Java API's provided by Oracle. A copy of the order itself is available as document "Case3:10-cv-03561-WHA Document1202: Order Re Copyrightability of Certain Replicated Elements of the Java Application Programming Interface". Commentary on it can be read in several places, such as in John Harris's article "Judge in Oracle v. Google Case Rules that APIs are Not Copyrightable", in which he notes "... this is not really a new result ... this has been the law for quite some time, until the API copyrightability question was squarely raised in this case". The question of what subject matter is or is not copyrightable in the US is apparently explicitly defined in "17 USC § 102 - Subject matter of copyright: In general", which states in (b) "in no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work".

That definition would seem to squarely encompass standards like HL7, including CDA; though I am no lawyer, and have not consulted one, it would reassure me if were planning on implementing any part of HL7 in my own open source code, or using someone else's implementation in a production environment, and couldn't justify the non-trivial expense of joining HL7 as an organizational member. I am not sure wherein lies the legal basis of HL7's claim of a right to restrict the "use of the material".

That said, since there are truly open alternatives to CDA, until HL7 clarifies the situation in a satisfactory manner, should one consider avoiding CDA altogether? After all, regardless of the merits of any legal question, one hardly wants to get in a legal wrangle with a large organization, and since the policy makers at a national level seem to have abrogated their responsibility to select only open standards, it males sense to look for alternative standards that are open.

Since the standards for the "payload" can largely be separated from standards for the exchange and workflow management, (e.g., XDS, XDR or DIRECT are just useful for PDF, text, or any XML document, not just CDA), there is an opportunity to jump off the CDA bandwagon (juggernaut). Indeed CCR was just such a deviation (that the HL7 folks would no doubt was rather forgotten about sooner rather than later).

One interesting possibility is the CE/ISO 13606 (OpenEHR extract); since this is an ISO standard, it is not free to obtain the specification from CEN or ISO (like HL7 and ASTM, CEN and ISO also charge for copies of their standards, unlike DICOM, IETF or W3C), but it is free to implement, and (unofficial) XML schemas can be obtained from the EN 13606 Association website, and "last drafts" of the CEN standards may be available with a Google search. Charging a "nominal fee" for access to the text of a standard is permitted by some Open Standard definitions (such as in the European Interoperability Framework) though not others (such as the Open Source Initiative). There is an insightful UK NHS Connecting for Health report about "Investigating implementing CEN 13606 with HL7 V3 and SNOMED CT".

Since I am not really involved at all in this EHR and CDA stuff, and my primary interest remains radiology imaging and hence the imaging report, I cannot speak to the practicality of CDA alternatives, and to what extent the issues may be, but they certainly seem to be worth exploring.

This matter of HL7 fees for use came up at a DICOM WG 10 (Strategic Planning) meeting recently; a summary of the discussion can be found in the minutes. Not recorded in the minutes, but identified by one participant, was the need for care with respect to contributing material developed  in a DICOM context (such as radiology report templates), that was then made available to HL7 for joint publication; at the very least, any material developed on the joint DICOM-HL7 group, WG 20, should be accompanied by language indicating that it must remain free for use and cannot be restricted by HL7 when jointly published. Likewise, though DICOM WG-8 has been encouraged to focus its report template standardization efforts related to the RSNA reporting initiative, on CDA encoding, this position may need to be either reconsidered, or the templates produced in a manner such that they can be encoded in other open standards rather than CDA.

At a national level, this is similar to the problem with SNOMED, which also was not "free" for general use; again one wonders whether they have the legal right to restrict use, since SNOMED is all about "concepts", which are explicitly excluded from copyright protection under 17 USC § 102. Regardless, for US use, the NLM "paid them off" with a $32.4 million five year license (them being CAP), and now pays an annual fee of about $6 million to IHTSDO, which now owns SNOMED. My reason for mentioning this, is that it may have set a precedent for well-established closed standards organizations extorting non-trivial sums of money from national governments, and perhaps that is what HL7 International is hoping for. It also doesn't help international users.

From my perspective, the best outcome would be for HL7 to back away from this position, and to allow anyone to implement any of their standards royalty-free anywhere. Indeed, anything less than that would seem to me to be a strong incentive to lobby against using CDA at all, and seeking out a replacement.

David


Posted by at 13 comments:

Saturday, March 3, 2012

Imaging and Meaningful Use 2 - First Impressions

Summary: Imaging and results now included; DICOM payload required for transfer to 3rd party, not necessarily for viewing. Transport mechanisms uncertain. Division of responsibilities between EHR and viewer uncertain in linked scenario.

Long Version.

In the second round, it seems that the Meaningful Use effort in the United States will address the matter of access to imaging as well as results from imaging studies, including a patient-initiated ability to download and transfer to a 3rd party. Excellent news, after having been excluded in the first round, assuming that the important stuff survives the public comment phase.

A summary and links to documents can be found at the the HealthIT.gov site, the relevant documents being:
The first of these contains the technical details of what standards are proposed to be required for certification, whilst the second proposes the objectives and measures for incentive payments. Both are scheduled to be published in the Federal Register on March 7th.

An initial review of these shows that imaging is addressed in three objectives:
  • "Use computerized provider order entry (CPOE) for medication, laboratory and radiology orders directly entered by any licensed healthcare professional ..."
  • "Imaging results and information are accessible through Certified EHR Technology"
  • "Provide patients the ability to view online, download, and transmit their health information within 4 business days of the information being available to the EP (Eligible Professional)"
Ordering.

I won't discuss ordering here further, except to note that the use of ICD-10-PCS for procedure codes is addressed under the discussion of "view online, download, and transmit", but not under the "use CPOE" certification criteria. It is certainly high time that there was more public debate about whether the ICD-10-PCS are sufficient for ordering or not (as opposed to billing), and the RadLex Playbook community will no doubt have views on this subject, but that is a debate for another day.

Imaging Accessibility (Viewing).

I quote the text of the "Imaging results and information are accessible through Certified EHR Technology" objective in full:

"Making the image that results from diagnostic scans and accompanying information accessible through Certified EHR Technology increases the utility and efficiency of both the imaging technology and the CEHRT. The ability to share the results of imaging scans will likewise improve the efficiency of all health care providers and increase their ability to share information with their patients. This will reduce the cost and radiation exposure from tests that are repeated solely because a prior test is not available to the provider.

Most of the enabling steps to incorporating imaging relate to the certification of EHR technologies. As with the objective for incorporating lab results, we encourage the use of electronic exchange to incorporate imaging results into the Certified EHR Technology, but in absence of such exchange it is acceptable to manually add the image and accompanying information to Certified EHR Technology."

Hard to argue with much of that, though it is a bit of a cop out to not include a requirement, as opposed to "encouragement", to use electronic means to get images into the EHR, particularly since it is so easy from the provider's side given the ubiquitous use of DICOM for payload and transport (any issues with which are not addressed by any "manual" alternative); I think the public comments should suggest a reversal of this stance, and require that electronic means be used.

For the Proposed Measure for this objective, the following text is included:

"For Stage 2, we do not propose the image or accompanying information (for example, radiation dose) be required to be structured data. Images and imaging results that are scanned into the Certified EHR Technology may be counted in the numerator of this measure."

Hmmm. For results, one can see the logic in this, since convincing radiologists to author structured content has been an uphill battle (esp., in the absence of tools and incentives). Efforts like the RSNA Radiology Reporting initiative are pragmatically focused more on structure narrative rather truly structured content (with codes for findings) in the sense that I think is meant here, and the return on investment in the MU2 timeline for demanding truly structured (coded) radiology reports is perhaps not clear enough yet.

But for the images themselves, I am not so sure. Personally, I think the MU2 objective should require "structured data" for images (as the input to the EHR at least; vide infra wrt. the viewing mechanism, as distinct from interchange), and the form of that structured data should be DICOM, and be specified in the certification criteria for this proposed objective (in the sense that a DICOM image with a "header" contains "structured data" about the patient, study, series, other demographics and acquisition technique, etc., whereas a JPG or GIF image does not).

I also think the objective should require that radiation dose information be structured, and that the structured form of that should be DICOM RDSR (in the certification criteria), since this is regarded as such a "hot" topic (if you will excuse the pun) (with the FDA and the state of California, at least), and it is high time that we more seriously engaged the EHR vendor community in helping with this (esp. wrt. a longitudinal patient record of structured radiation exposure and/or dose information).

The proposed measures further state:

"We define accessible as either incorporation of the image and accompanying information into Certified EHR Technology or an indication in Certified EHR Technology that the image and accompanying information are available for a given patient in another technology and a link to that image and accompanying information. Incorporation of the image means that the image and accompanying information is stored by the Certified EHR Technology. ... A link to the image and accompanying information means that a link to where the image and accompanying information is stored is available in Certified EHR Technology. This link must conform to the certification requirements associated with this objective in the ONC rule."

That sounds reasonable on the face of it too; a "link" rather than embedding "by value".

However, if one turns to the certification requirements in the other document, one finds:

"We clarify that the phrase “immediate electronic access” is intended to mean that a user should be able to electronically access images and their narrative interpretations directly and without, for example, having to login to a separate electronic system or repository. This access could be provided by multiple means, including, but not limited to, “single sign-on” and “secure identity parameter passing.”"

Way cool ! Nobody wants to have their workflow interrupted by having to sign on to multiple systems.

But ...

"We also note that there are data format standards for the transmission of imaging data (Digital Imaging and Communications in Medicine (DICOM)) that we reviewed for this certification criterion, but do not believe that the adoption of these standards is necessary to enable users to electronically access images and their narrative interpretations, as required by this certification criterion."

Hmmm. At first site this may seem strange, at least for the "images" as opposed to "narrative interpretation" part, but I think what they are trying to say here is that for the purpose of just viewing images in the context of an EHR, it is not necessary to use DICOM as an "image format" per se. And that is probably true, in that one may well have an interactive "application" that is part of the access mechanism (e.g., a proprietary thin or thick web browser client or plugin or JPEG or HTML5 or whatever type of viewer), and as long as one doesn't bother the user with having to sign in to a separate system (i.e., makes the experience transparent), then they are good to go.

It does beg the question though, of how interoperable this will be, given different browsers and platforms and local security settings and all that. Should there be elaboration on this in the certification criteria with respect to the need for a "zero footprint" viewer or similar, or the use of standard web-based access mechanisms like DICOM WADO ? Also, how does one go about certifying the mix-and-match combination of an EHR with a link to a different viewing system (like the web front end of a PACS or P/VNA univiewer) ... will every combination of EHR and PACS and viewer need to be certified, or can these be separately certified as components (and how can one do the latter without interoperability standards)?

Further, one needs to consider the question of the input format versus the viewing mechanism, as hinted at earlier wrt. "structured data", and this again relates to the matter of decoupling the viewer from the EHR (linking rather than embedding).

Another question that arises is the quality of the images viewed; in my opinion these should be held to the "diagnostic quality" criterion that the AMA imaging safety and standards panel made it clear was required, since without doubt, clinicians will be using images viewed in the EHR to make diagnostic decisions that affect patient management.

I think there is significant room for comment and improvement in the certification criteria for the image viewing requirement, and perhaps even a need to have separate requirements for the "embedded" approach as opposed to the "linked" approach.

Download and Transmit (Sharing, Interchange).

The suspicion that the viewing objective is distinct is confirmed by looking at the details of the other objective that is related to sharing and interchange, and which replaces the former generic objective for "timely access" and "electronic copy" for patients, though obviously there is overlap given the presence of the word "view".

Specifically, though the new "Provide patients the ability to view online, download, and transmit their health information" objective itself states nothing with regard to imaging per se, the certification criteria for this objective do specifically address imaging:

"We propose to require EHR technology to be capable of enabling images formatted according to the Digital Imaging and Communications in Medicine (DICOM) standard[11] to be downloaded and transmitted to a third party. We believe this specific capability has the potential to empower patients to play a greater role in their own care coordination and could help assist in reducing the amount of redundant and duplicative imaging-oriented tests performed. In fact, the National Institutes of Health has recently funded activities focused on personally controlled sharing of medical images[12] and published a solicitation notice on the same topic.[13]"

Good stuff, though perhaps there is a need for a few more specifics about the means of transmission of the DICOM images (as opposed to the payload being DICOM images), and this is a subject that has been debated recently in response to one of John Halamka's comments on his blog. During the public comment phase, it would probably be a good idea to clarify the role of IHE XDS-I and XDR-I in this respect, since those are certainly the mechanisms that most folks think are appropriate for this "CD replacement with the network transport" for imaging. In particular, the DIRECT mechanism that uses email to transport documents is not likely to scale well for the purpose of image transport, and though the proposed MU2 certification criteria talk about DIRECT, they do so in the context of the summary of care document. More information about DIRECT is available at their home page and their wiki.

I am not sufficiently familiar with the addressing and security-related aspects of DIRECT, which use DNS and LDAP to obtain X.509 certificates for encryption for intended recipients, for example, to know how well this will interact with using XDR-I as a "push" mechanism, nor whether the DIRECT idea of using a "push", as opposed to a "pull" using XDS-I (which has been widely promoted for this use-case up until now), or something in between like the RSNA's Image Share project (which is the one that the NHLBI solicitation referred to in the certification criteria is about), is more appropriate.

One other aspect of this objective (stated in the objective, rather than the certification criteria) is that:

"Transmission can be any means of electronic transmission according to any transport standard(s) (SMTP, FTP, REST, SOAP, etc.). However, the relocation of physical electronic media (for example, USB, CD) does not qualify as transmission although the movement of the information from online to the physical electronic media would be a download."

which I find interesting
  • because it to some extent overlaps with and/or perhaps contradicts the certification criteria which promote specific transport mechanisms, and
  • because it clearly defines that physical media does not satisfy the objective (which of course is the whole point of the exercise, to substitute the network for "sneakernet").
Anyway, arguably the "sharing" objective is much more interesting than the "viewing" objective, seems to expose some inconsistency between the objectives and the certification criteria (if not a division of opinion between the respective drafters), and without question in my opinion will require quite a lot more work on the certification criteria side at least to define how best to select a suitable set of standards to cover the imaging use cases.

In addition to the transport technology, it might also be appropriate to comment on how some of this is actually required to be implemented in terms of the actors involved and the sequence of operations in specific scenarios. For example, if the patient initiates a "transfer" of a DICOM study to a recipient, need it be required that those images then be importable into whatever system that recipient is using, automatically and electronically? Or to put this another way, since the certification requirements apply to the "EHR", what does this mean in terms of a required capability for the recipient's workstation or PACS? Anything ? Or nothing, since they may be out of scope of certification. This does open up a can of worms with respect to standards for "import" workflow (and the sort of issues that IHE addresses in the IRWF profile and the extensions to IRWF that we are working on this cycle).

Again, we should not forget to comment on the fact that "diagnostic quality" is required for the interchange objective, in addition to the viewing objective, since merely specifying DICOM as the payload is not sufficient in this respect, as opposed to, for instance "the original DICOM images as they were interpreted for patient care". Now there's a can of worms!

Retention (Not).

A further element of the proposed measures is:

"Meaningful use does not impose any additional retention requirements on the image."

OK, that seems fine to me too; who the entity of record is responsible for retention, and for how long, are things the ONC considers out of scope. We know that we are not getting a federally funded national archive of patient images any time soon, nor a mandate that there be similar archives at the state level or in the private sector.

Provider-to-Provider Image Transport Missing.

What I cannot see, at least with respect to imaging, is a mechanism for providers to exchange images, without the need to engage the patient to initiate and manage it.

E.g., where is the imaging correlate to the objective for "The EP who transitions their patient to another setting of care or provider of care or refers their patient to another provider of care should provide summary care record for each transition of care or referral."

Should there not be a similar objective:

"The EP who transitions their patient to another setting of care or provider of care or refers their patient to another provider of care should provide images for each transition of care or referral."

I.e., the current proposed objectives talk a lot about access with an EHR, and access by patients, but not so much about the scenarios in which the patient is transferred to other providers who do not have access via the EHR (or any other system) of the previous provider.

This omission seems to disregard the current trend towards using "cloud" based or simple pre-negotiated point-to-point push mechanisms as CD replacement solutions for provider-to-provider communication, without having to bother the patient with the details.

If two PACS talked to each other to satisfy such an objective, if it existed, then presumably they could be "modular certified" for the purpose of MU.

David

PS. Keith Boone has a nice mapping table of objectives to certification criteria on his blog at "MeaningfulUse Objectives Mapped to the ONC Certification Criteria" and also a "MeaningfulUse Certification Criteria Crosswalk to Standards". One strange thing that his table highlights is that "eligible providers" (EPs) are required to implement the "view online, download and transmit" objective, but "eligible hospitals and CAHs (critical access hospitals)" are not. It is not obvious to me what the reason for this distinction is for this objective, and what the specific implications are for imaging.
Posted by at 2 comments:
Subscribe to: Posts (Atom)