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)!
Friday, July 20, 2012
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
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
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:
An initial review of these shows that imaging is addressed in three objectives:
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
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.
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 ONC Proposed Rule "Health Information Technology: Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology, 2014 Edition; Revisions to the Permanent Certification Program for Health Information Technology ", and
- the CMS Proposed Rule "Medicare and Medicaid Programs; Electronic Health Record Incentive Program--Stage 2".
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)"
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").
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.
Saturday, January 21, 2012
Two (or More) Views of the World ...
Summary: Providing alternative "views" of studies via DICOM Q/R and other services allows legacy single frame and new enhanced original or converted multi-frame image header and pixel data to peacefully co-exist.
Long Version:
Needless to say, and tempting as it may be on this day of the South Carolina GOP Primary, I am not talking about alternative political views, but rather something far more interesting and important to the fate of the free world ...
As discussed in an early post, Framing the Big Study Problem, just because one does not get Enhanced CT/MR/PET multi-frame images from one's modalities, does not mean that the "legacy" single frame images cannot be converted into a similar representation. The DICOM Standards Committee has agreed to a work item to define a standard mechanism for doing that, and work is on going.
However, an interesting question has arisen, and that is, how does one distinguish between the "original" images as received from the modality, and the "converted" ones?
Or to put this another way, if the converted images are naively "added" to the same study in the PACS, then in the worst case one ends up with twice as much data in the same study, and a study level retrieval would retrieve all of it, unless there were some filtering mechanism.
Indeed, when you think about it, the requester (Q/R SCU) probably doesn't care which were "original" and which were "converted", but rather is interested in the form, i.e., whether they are "legacy" single-frame, or enhanced multi-frame, and perhaps in the latter case whether they are "genuine" enhanced multi-frame with all the standard attributes and codes, or whether they are "enhanced legacy converted" multi-frame, with only a limited amount of standard stuff but with the consolidated "header" and aggregated pixel data.
At the last ad hoc WG meeting, we discussed the idea of having two (or perhaps more) "views" of the data, and providing the Q/R SCU with the ability to choose which view they wanted.
I am not a database guy (and don't play one on TV), and I am certainly not well versed in the theory of relational databases, but the concept of a database "view" is well established (see for example, the Wikipedia description of a database view). As a historical note, the term "view" was even used in the very earliest relational database literature, to describe the concept of a "relational view" (Codd EF. A relational model of data for large shared data banks. CACM 1970 13:377), and indeed that paper also distinguishes the concept of a "stored set" from an "expressible set". Arguably, the concept of different views is perhaps similar to the concept of "subschemas" introduced in the CODASYL Database Task Group (DBTG) 1971 Report Data Definition Language (DDL), the idea therein being to restrict the application view of the database to a sub-set of the entire schema, and to allow multiple such subschemas, under the control of the database administrator. (It brings joy to the heart of an old COBOL programmer reminiscing about what fun this stuff used to be; I really must dig out my old manuals from storage.)
Anyway, it seems obvious to me that the basic idea of providing alternative ways to look at the same data and relationships is equally applicable to the access mechanisms that are relevant to this application, specifically the DICOM Query and Retrieval Service Class, or yet another mechanism for accessing the DICOM data, such as via the http-based services that DICOM WG 27 is developing (like QIDO). The definition of a "view" in the relational database world currently seems to be specific to the distinction between what the "native" representation in the tables is, as opposed to something that is derived dynamically via a query or via stored procedures, but that is probably not a distinction that is useful to us from the perspective of defining the interface boundary (though it is relevant to implementation, vide infra).
For our purposes then, we need to present the user (or their agent, the workstation) with two or more "views" of the same set of slices (in the case of a cross-sectional modality like CT, MR or PET), such that their experience is identical, regardless of the underlying representation or physical encoding or means of transfer. If the application they are using is only single-frame aware, then the query from that application to the PACS will request and receive information about one set of objects, and if it is multi-frame aware it will see a different set of objects. Semantically these will contain identical information. What they will not see will be duplicates (i.e., the same acquisition in two different forms).
The idea of these two views is equally applicable to both the query for information about the study, and the retrieval of the study and its components. That is, when the query is performed, it should return attributes of only the instances in the view that is specified, and when a retrieval of those instances is performed (whether it be at the patient, study, series, instance (image) or even frame level), only those entities in the requested view should be returned.
Note that referential integrity is important also. By that I mean that references to converted images within presentation states, structured reports, other similar non-image objects, and indeed references from one image to another (e.g., from a transverse slice to a localizer, or a derived image like an MPR to a source image) all need to be "updated" to point to the converted images, not the "original" images, as necessary. In my opinion the appropriate "scope" for preservation of this referential integrity is the entire patient, not just the study, since a current study may refer to images or other instances within a prior study for the same patient. The net effect of this is that more objects than just images may need to be "converted" in order to support an internally consistent "view".
How this is achieved behind the scenes in terms of implementation offers interesting opportunities for performance optimization. When a PACS receives images in one form, it could convert them into the other form and store both, and index both in its database, though that would seem wasteful. An obvious optimization is to store only one form and dynamically create the other form on demand, as long as one does this in a deterministic way (such that the unique identifiers generated on the fly were always consistent with previous requests for the same view). Perhaps the determinism constraint could be satisfied simply by storing the generated UIDs (rather than the whole object) in the database, on initial insertion, or just the first time they were needed.
An interesting side effect of this is that the implementer may have a choice of which is the optimum representation internally to achieve specific performance goals in specific scenarios. For example, it may be that on-demand retrieval for viewing, both in proprietary viewers built in to the PACS, or retrieval to standard displays or workstations, may be achieved by using the multi-frame representation internally, since the aggregated bulk pixel data might be more efficiently compressed, indexed and streamed, and the consolidated "header" information with its structure already factored into shared and per-frame information as well as with explicit dimensions might be more quickly transferred, parsed, navigated, indexed and retrieved for annotation, etc. Yet this can be achieved without sacrificing the benefit of using a standard DICOM PS 3.10 object inside the archive, both long term and in the short term "live" store (or cache or whatever), whether it be locally or centrally. If no other factor, the database tables indexing this stuff will certainly be more compact, given the lack of need to use a per-slice image table entry for each file, or at least one with a full set of per-image attributes as columns.
Yet at any time, the original (as received) single frame representation can be recovered from this "more efficient" internal representation, as long as an appropriate full fidelity round-trip can be defined and implemented. Arguably, it is also easier and faster to convert enhanced multi-frame to single frame images than it is the other way around, since there is a lot less "analysis" that has to be performed (i.e., trying to decide what is common and what varies per-frame and to split it into the appropriate functional groups, and then to look for standard patterns of use of dimensions like space, time and cardiac cycle position). In my experiments to date, even for very large sets of slices, the rate limiting step in either direction is limited by disk IO and header parsing, and not the business logic that is required to do the grouping and ungrouping, but I would expect that in a real-world implementation this would depend heavily on the specifics of a particular large, scalable PACS application architecture.
Like with web server front ends to PACS, it is very likely that some sort of intelligent pre-caching logic would need to be placed in the pipeline, such that predicted (as well as repeated) requests for a particular choice for a particular patient or study, could be pre-computed and stored in the cache in the likely preferred form if it is different from the natively stored form. For example, if from the modality worklist it was apparent that priors would be needed for comparison during reporting, and the priors were natively stored as single frame, yet the (new) modality produced enhanced multi-frame images, and the PACS and the reading workstation only supported multi-frame, then the PACS would know to pre-fetch, pre-convert the single frame priors to enhanced multi-frame and pre-load them to the reading station cache. As opposed to doing it on the fly if the user realized they needed these priors unexpectedly.
Some outstanding questions remain with respect to how best to negotiate and specify the selection of these views, how many views are necessary, whether it is necessary to have views that distinguish "original" (as received) objects from converted ones, and what the default view should be if it is not explicitly specified or if the view option is not negotiated. The last issue is particularly important with respect to legacy workstations and PACS that will not know how to request the option, yet may support the enhanced multi-frame objects, though it may be there is such poor support for enhanced multi-frame objects at the user-facing application level (as opposed to simple store and regurgitate in the PACS) that this is not a practical problem.
What I have written up so far in the draft supplement proposes that the negotiation of the ability to support views is an additional Extended Negotiation option on both the query and retrieval, and that if this option is successfully negotiation, a new Query/Retrieve View attribute can be included in the C-FIND, C-MOVE or C-GET request identifier, which then modulates the behavior of the SCP (i.e., effectively "filters" the set of data visible such that it is constrained to the specified view). I have specified this to also apply to the instance and frame-level retrieval and the no-bulk data retrieval, not because it is necessary to specify the view to select the objects (these require SOP Instance UIDs at the instance level already, which will be specific to the view), but rather because the retrieved objects will need to contain the correct referenced UIDs for the appropriate view (to maintain referential integrity within the view).
The foregoing all applies to "pull" (query and retrieval) use-cases and does not effect push use-cases. If an SCU and an SCP have a choice in the matter of whether to send legacy single frame images, genuine enhanced multi-frame images, or enhanced legacy converted multi-frame images, this still needs to be handled either as a matter of configuration, or by dynamic SOP Class negotiation during Association Negotiation, with the opportunity for the SCU to "fall back" to a less desirable SOP Class in the normal way, as discussed in the earlier post.
In a way the concept of "views" is vaguely reminiscent of a very specific form of the "filtering" operation that was part of the old OSI "scoping and filtering" capability that was potentially applicable to DICOM normalized objects but never included in the original standard, though of course, the filtering was way more versatile with boolean expressions, we are talking here about services on composite, not normalized objects, and DICOM never did follow through on the prospect of generalized normalized object management, nor is it really applicable to these highly specific use cases. Still, just goes to show that there is nothing new under the sun.
Anyway, it remains to be seen what the AHWG group comes up with on Monday when we review the proposal and it is subject to more detailed scrutiny. Sufficeth to say in our meetings so far we have been making fairly rapid progress, thanks in no small part to the number of vendors and others who have already been experimenting with multi-frame representations, and hopefully we will have something fairly solid to share with the world at large shortly. Anyone with a technical knowledge of the subject matter is of course welcome to join our group, physically or virtually at any time; just let me know.
David
Long Version:
Needless to say, and tempting as it may be on this day of the South Carolina GOP Primary, I am not talking about alternative political views, but rather something far more interesting and important to the fate of the free world ...
As discussed in an early post, Framing the Big Study Problem, just because one does not get Enhanced CT/MR/PET multi-frame images from one's modalities, does not mean that the "legacy" single frame images cannot be converted into a similar representation. The DICOM Standards Committee has agreed to a work item to define a standard mechanism for doing that, and work is on going.
However, an interesting question has arisen, and that is, how does one distinguish between the "original" images as received from the modality, and the "converted" ones?
Or to put this another way, if the converted images are naively "added" to the same study in the PACS, then in the worst case one ends up with twice as much data in the same study, and a study level retrieval would retrieve all of it, unless there were some filtering mechanism.
Indeed, when you think about it, the requester (Q/R SCU) probably doesn't care which were "original" and which were "converted", but rather is interested in the form, i.e., whether they are "legacy" single-frame, or enhanced multi-frame, and perhaps in the latter case whether they are "genuine" enhanced multi-frame with all the standard attributes and codes, or whether they are "enhanced legacy converted" multi-frame, with only a limited amount of standard stuff but with the consolidated "header" and aggregated pixel data.
At the last ad hoc WG meeting, we discussed the idea of having two (or perhaps more) "views" of the data, and providing the Q/R SCU with the ability to choose which view they wanted.
I am not a database guy (and don't play one on TV), and I am certainly not well versed in the theory of relational databases, but the concept of a database "view" is well established (see for example, the Wikipedia description of a database view). As a historical note, the term "view" was even used in the very earliest relational database literature, to describe the concept of a "relational view" (Codd EF. A relational model of data for large shared data banks. CACM 1970 13:377), and indeed that paper also distinguishes the concept of a "stored set" from an "expressible set". Arguably, the concept of different views is perhaps similar to the concept of "subschemas" introduced in the CODASYL Database Task Group (DBTG) 1971 Report Data Definition Language (DDL), the idea therein being to restrict the application view of the database to a sub-set of the entire schema, and to allow multiple such subschemas, under the control of the database administrator. (It brings joy to the heart of an old COBOL programmer reminiscing about what fun this stuff used to be; I really must dig out my old manuals from storage.)
Anyway, it seems obvious to me that the basic idea of providing alternative ways to look at the same data and relationships is equally applicable to the access mechanisms that are relevant to this application, specifically the DICOM Query and Retrieval Service Class, or yet another mechanism for accessing the DICOM data, such as via the http-based services that DICOM WG 27 is developing (like QIDO). The definition of a "view" in the relational database world currently seems to be specific to the distinction between what the "native" representation in the tables is, as opposed to something that is derived dynamically via a query or via stored procedures, but that is probably not a distinction that is useful to us from the perspective of defining the interface boundary (though it is relevant to implementation, vide infra).
For our purposes then, we need to present the user (or their agent, the workstation) with two or more "views" of the same set of slices (in the case of a cross-sectional modality like CT, MR or PET), such that their experience is identical, regardless of the underlying representation or physical encoding or means of transfer. If the application they are using is only single-frame aware, then the query from that application to the PACS will request and receive information about one set of objects, and if it is multi-frame aware it will see a different set of objects. Semantically these will contain identical information. What they will not see will be duplicates (i.e., the same acquisition in two different forms).
The idea of these two views is equally applicable to both the query for information about the study, and the retrieval of the study and its components. That is, when the query is performed, it should return attributes of only the instances in the view that is specified, and when a retrieval of those instances is performed (whether it be at the patient, study, series, instance (image) or even frame level), only those entities in the requested view should be returned.
Note that referential integrity is important also. By that I mean that references to converted images within presentation states, structured reports, other similar non-image objects, and indeed references from one image to another (e.g., from a transverse slice to a localizer, or a derived image like an MPR to a source image) all need to be "updated" to point to the converted images, not the "original" images, as necessary. In my opinion the appropriate "scope" for preservation of this referential integrity is the entire patient, not just the study, since a current study may refer to images or other instances within a prior study for the same patient. The net effect of this is that more objects than just images may need to be "converted" in order to support an internally consistent "view".
How this is achieved behind the scenes in terms of implementation offers interesting opportunities for performance optimization. When a PACS receives images in one form, it could convert them into the other form and store both, and index both in its database, though that would seem wasteful. An obvious optimization is to store only one form and dynamically create the other form on demand, as long as one does this in a deterministic way (such that the unique identifiers generated on the fly were always consistent with previous requests for the same view). Perhaps the determinism constraint could be satisfied simply by storing the generated UIDs (rather than the whole object) in the database, on initial insertion, or just the first time they were needed.
An interesting side effect of this is that the implementer may have a choice of which is the optimum representation internally to achieve specific performance goals in specific scenarios. For example, it may be that on-demand retrieval for viewing, both in proprietary viewers built in to the PACS, or retrieval to standard displays or workstations, may be achieved by using the multi-frame representation internally, since the aggregated bulk pixel data might be more efficiently compressed, indexed and streamed, and the consolidated "header" information with its structure already factored into shared and per-frame information as well as with explicit dimensions might be more quickly transferred, parsed, navigated, indexed and retrieved for annotation, etc. Yet this can be achieved without sacrificing the benefit of using a standard DICOM PS 3.10 object inside the archive, both long term and in the short term "live" store (or cache or whatever), whether it be locally or centrally. If no other factor, the database tables indexing this stuff will certainly be more compact, given the lack of need to use a per-slice image table entry for each file, or at least one with a full set of per-image attributes as columns.
Yet at any time, the original (as received) single frame representation can be recovered from this "more efficient" internal representation, as long as an appropriate full fidelity round-trip can be defined and implemented. Arguably, it is also easier and faster to convert enhanced multi-frame to single frame images than it is the other way around, since there is a lot less "analysis" that has to be performed (i.e., trying to decide what is common and what varies per-frame and to split it into the appropriate functional groups, and then to look for standard patterns of use of dimensions like space, time and cardiac cycle position). In my experiments to date, even for very large sets of slices, the rate limiting step in either direction is limited by disk IO and header parsing, and not the business logic that is required to do the grouping and ungrouping, but I would expect that in a real-world implementation this would depend heavily on the specifics of a particular large, scalable PACS application architecture.
Like with web server front ends to PACS, it is very likely that some sort of intelligent pre-caching logic would need to be placed in the pipeline, such that predicted (as well as repeated) requests for a particular choice for a particular patient or study, could be pre-computed and stored in the cache in the likely preferred form if it is different from the natively stored form. For example, if from the modality worklist it was apparent that priors would be needed for comparison during reporting, and the priors were natively stored as single frame, yet the (new) modality produced enhanced multi-frame images, and the PACS and the reading workstation only supported multi-frame, then the PACS would know to pre-fetch, pre-convert the single frame priors to enhanced multi-frame and pre-load them to the reading station cache. As opposed to doing it on the fly if the user realized they needed these priors unexpectedly.
Some outstanding questions remain with respect to how best to negotiate and specify the selection of these views, how many views are necessary, whether it is necessary to have views that distinguish "original" (as received) objects from converted ones, and what the default view should be if it is not explicitly specified or if the view option is not negotiated. The last issue is particularly important with respect to legacy workstations and PACS that will not know how to request the option, yet may support the enhanced multi-frame objects, though it may be there is such poor support for enhanced multi-frame objects at the user-facing application level (as opposed to simple store and regurgitate in the PACS) that this is not a practical problem.
What I have written up so far in the draft supplement proposes that the negotiation of the ability to support views is an additional Extended Negotiation option on both the query and retrieval, and that if this option is successfully negotiation, a new Query/Retrieve View attribute can be included in the C-FIND, C-MOVE or C-GET request identifier, which then modulates the behavior of the SCP (i.e., effectively "filters" the set of data visible such that it is constrained to the specified view). I have specified this to also apply to the instance and frame-level retrieval and the no-bulk data retrieval, not because it is necessary to specify the view to select the objects (these require SOP Instance UIDs at the instance level already, which will be specific to the view), but rather because the retrieved objects will need to contain the correct referenced UIDs for the appropriate view (to maintain referential integrity within the view).
The foregoing all applies to "pull" (query and retrieval) use-cases and does not effect push use-cases. If an SCU and an SCP have a choice in the matter of whether to send legacy single frame images, genuine enhanced multi-frame images, or enhanced legacy converted multi-frame images, this still needs to be handled either as a matter of configuration, or by dynamic SOP Class negotiation during Association Negotiation, with the opportunity for the SCU to "fall back" to a less desirable SOP Class in the normal way, as discussed in the earlier post.
In a way the concept of "views" is vaguely reminiscent of a very specific form of the "filtering" operation that was part of the old OSI "scoping and filtering" capability that was potentially applicable to DICOM normalized objects but never included in the original standard, though of course, the filtering was way more versatile with boolean expressions, we are talking here about services on composite, not normalized objects, and DICOM never did follow through on the prospect of generalized normalized object management, nor is it really applicable to these highly specific use cases. Still, just goes to show that there is nothing new under the sun.
Anyway, it remains to be seen what the AHWG group comes up with on Monday when we review the proposal and it is subject to more detailed scrutiny. Sufficeth to say in our meetings so far we have been making fairly rapid progress, thanks in no small part to the number of vendors and others who have already been experimenting with multi-frame representations, and hopefully we will have something fairly solid to share with the world at large shortly. Anyone with a technical knowledge of the subject matter is of course welcome to join our group, physically or virtually at any time; just let me know.
David
Sunday, September 25, 2011
A Modality, by any other name (would smell as sweet ?)
Summary: The use of the term Modality in radiology is old; its definition is vague in various standards, but relatively consistent in terms of both meaning and granularity.
Long version:
I got an email inquiry from Scott N who wrote:
My colleague and I have been discussing the usage of the term "imaging modality" and how it appears (to us) that it is commonly applied ambiguously in the literature. I would roughly define the term to mean "a method involving the employment of a physical agent to produce an image." As MR utilizes electromagnetic waves and PET utilizes positron-emitting isotopes, I would then characterize the two as separate image modalities. However, a quick Google search yields countless examples of statements such as the "DTI and fMRI modalities." By my definition, I would classify DTI and fMRI as the same imaging modality, and I believe the DICOM modality 0008,0060 always gives "MR" for these two types of scans.
I was hoping you mind have a little time to comment on this and on how the DICOM standard defines this?
This prompted me to get a little carried away in researching the matter (this being a quiet Sunday morning, too foggy to fly yet, the dog emptied and my wife absorbed in vacation planning), and I came up with the following.
DICOM defines the Attribute of the Series, Modality, in PS 3.3 C.7.3.1, to mean:
"Type of equipment that originally acquired the data used to
create the images in this Series"
and then proceeds to provide a list of defined terms (the value set) for the attribute in C.7.3.1.1.1.
Also, in PS 3 C.4.15:
"Type of equipment that originally acquired the data used to create the images associated with this Modality Performed Procedure Step."
In HL7 V2.5 Section 4.5.6.5 the Modality field is defined (in a post-DICOM modality worklist addition to HL7) as:
"The type of equipment requested to acquire data during performance of a Procedure Step. The acquired data will be used to create the images for the Imaging Study corresponding to the Requested Procedure."
In IHE, the Acquisition Modality Actor is defined in RAD TF Vol 1 Section 2.3 as:
"A system that acquires and creates medical images while a patient is present, e.g. a Computed Tomography scanner or Nuclear Medicine camera. A modality may also create other evidence objects such as Grayscale Softcopy Presentation States for the consistent viewing of images or Evidence Documents containing measurements."
Surprisingly, RadLex doesn't provide a text definition for its Imaging Modality concept (http://www.radlex.org/RID/RID10311), only relationships to parent and child concepts; this is probably an easily rectified oversight.
SNOMED CT has a concept "Imaging Method" (360037004) for which it has a synonym "Imaging Modality", but again, no textual definition; the UMLS maps this to its "Imaging Modality" concept C1275506.
The UMLS Metathesaurus (https://uts.nlm.nih.gov//metathesaurus.html) also contains a more general concept "Modality" (C0695347).
These map to the NCI Thesaurus (http://ncit.nci.nih.gov/ncitbrowser/) concept of "Modality" (C41147) defined variously as:
"NCIt Definition: A specific manner, characteristic, pattern of application or the employment of, any therapeutic agent or method of treatment, especially involving the physical treatment of a condition.
DICOM Definition: Type of data acquisition device.
NCI-GLOSS Definition: A method of treatment. For example, surgery and chemotherapy are treatment modalities."
Wikipedia says ("http://en.wikipedia.org/wiki/Modality"):
"In medical imaging, any of the various types of equipment or probes used to acquire images of the body, such as radiography, ultrasound and magnetic resonance imaging."
I don't know what the history of the use of the word "modality" in a medical imaging context is, but it would be fascinating to research it. A quick look at the earliest reference in Radiology shows a mention in 1923 of a "therapeutic quartz lamp", which "enables all patients, because of its low cost, to be benefited by the use of this modality" (http://radiology.rsna.org/content/1/4/245.full.pdf). A therapeutic rather than diagnostic radiology use perhaps, but an early similar use all the same (and I found other mention of the term in a similar vein from the same year).
Given the DICOM precedent, I think it is more practical to consider fMRI and DTI as being "sub types" of a single modality MR.
Likewise MR Angiography is also a "sub type" of MR in DICOM, as are other borderline cases, such as MR Spectroscopy, even though there is not always imaging involved (it was once separate, but not any more, in recognition that one can produce spectroscopy-based (chemical shift, metabolite map) images, for example).
We had a big fight years ago in DICOM about introducing an explicit "modality sub-type" attribute, when we were doing visible light "modalities" and ended up with a generic VL from which we carved out specific modalities like ES (endoscopy) and slide microscopy (SL) as specific needs for different information or encoding for those application areas arose. In otherwords, though the technology may remain the same (a digital camera), the different "accessory" if you will (e.g., the endoscope or microscope) and the application area (e.g., gut, slide, retina, cornea) lead to refinements of what a single attribute Modality would refer to, weighed against what was generally done "together" by the equipment. The compounding of these different dimensions leads to some confusion, but, for example, one generally performs MRI, MRA, DWI, DTI, fMRI, DCE-MRI, MRS and CSI all in the same study on the same device (an MR scanner), whereas one would not perform endoscopy (ES) with a slide microscope (SM) even though they are both visible light (VL). Nor for that matter would one general mix upper and lower GI endoscopy in practice, but it has not proven necessary to separate these by a different DICOM Modality value. Similarly, for time-based waveforms, DICOM has relatively specific modality values like ECG, HD, RESP, etc. (even though those waveforms may emerge from the same "device" as that producing accompanying images and certainly be part of the same procedure).
The reason for the fight, by the way, was that some of us wanted the single Modality attribute that is widely implemented in browsers and databases to remain a single, useful, value, and not to require implementation changes to support multiple values for the same attribute or multiple attributes. As always in DICOM, purity is sacrificed in favor of pragmatic and incremental extension of installed base functionality rather than disruptive revolutionary change.
Hybrid modalities like PET-CT (and now MR-PET) lead to some concern about conflating the "equipment" with the "modality", as well as some cardinality issues in models and queries (hence attributes like "Modalities in Study). For DICOM aficionados, one needs to remember that Modality and SOP Class are not synonymous (hence the addition of "SOP Classes in Study", etc.). Theoretically we could have introduced a new single combined modality value for these cases, but in practice the equipment was two distinct modalities "bolted together" (and still is for many vendors) and the downstream applications (e.g. to perform fusion) were novel anyway, and they evolved to cope with the "two" modalities involved in the one procedure.
However, in general conversation (or the scientific literature) where the context is more "granular", I can see why folks use the term "modality" to distinguish such things as fMRI and DTI, but we should probably try and come up with a better term for that "lower level". RadLex, for example, just makes fMRI and MRA "Is a" children of MRI, which is in turn an "Is a" child of Imaging Modality, without providing a definition of what entity those children are; which actually raises an interesting question about whether traditional hierarchical entity-relationship models such as DICOM uses are sufficient for descriptive purposes, or whether "tagging" anything with concepts that depend on an ontology of relationships, semantic web style, adds more value. E.g., should one tag (semantically annotate) a series of images as being an fMRI, without explicitly saying that it is an MR too, such that if (and only if) the recipient had access to the ontology, it would "know" that relationship. Or should one just anticipate that use case and explicitly define that it is an MR and an fMRI in a model that is explicitly encoded? Of course the current state of the art is that one gets an MR modality value and figuring out that it is an fMRI (or any other highly specific "flavor" of MR) is a challenge, but the enhanced family of DICOM objects (with much more detailed attributes and value sets, but still traditional ER models) are intended to help with that.
Anyway, thanks Scott, for the interesting conversation starter.
David
Long version:
I got an email inquiry from Scott N who wrote:
My colleague and I have been discussing the usage of the term "imaging modality" and how it appears (to us) that it is commonly applied ambiguously in the literature. I would roughly define the term to mean "a method involving the employment of a physical agent to produce an image." As MR utilizes electromagnetic waves and PET utilizes positron-emitting isotopes, I would then characterize the two as separate image modalities. However, a quick Google search yields countless examples of statements such as the "DTI and fMRI modalities." By my definition, I would classify DTI and fMRI as the same imaging modality, and I believe the DICOM modality 0008,0060 always gives "MR" for these two types of scans.
I was hoping you mind have a little time to comment on this and on how the DICOM standard defines this?
This prompted me to get a little carried away in researching the matter (this being a quiet Sunday morning, too foggy to fly yet, the dog emptied and my wife absorbed in vacation planning), and I came up with the following.
DICOM defines the Attribute of the Series, Modality, in PS 3.3 C.7.3.1, to mean:
"Type of equipment that originally acquired the data used to
create the images in this Series"
and then proceeds to provide a list of defined terms (the value set) for the attribute in C.7.3.1.1.1.
Also, in PS 3 C.4.15:
"Type of equipment that originally acquired the data used to create the images associated with this Modality Performed Procedure Step."
In HL7 V2.5 Section 4.5.6.5 the Modality field is defined (in a post-DICOM modality worklist addition to HL7) as:
"The type of equipment requested to acquire data during performance of a Procedure Step. The acquired data will be used to create the images for the Imaging Study corresponding to the Requested Procedure."
In IHE, the Acquisition Modality Actor is defined in RAD TF Vol 1 Section 2.3 as:
"A system that acquires and creates medical images while a patient is present, e.g. a Computed Tomography scanner or Nuclear Medicine camera. A modality may also create other evidence objects such as Grayscale Softcopy Presentation States for the consistent viewing of images or Evidence Documents containing measurements."
Surprisingly, RadLex doesn't provide a text definition for its Imaging Modality concept (http://www.radlex.org/RID/RID10311), only relationships to parent and child concepts; this is probably an easily rectified oversight.
SNOMED CT has a concept "Imaging Method" (360037004) for which it has a synonym "Imaging Modality", but again, no textual definition; the UMLS maps this to its "Imaging Modality" concept C1275506.
The UMLS Metathesaurus (https://uts.nlm.nih.gov//metathesaurus.html) also contains a more general concept "Modality" (C0695347).
These map to the NCI Thesaurus (http://ncit.nci.nih.gov/ncitbrowser/) concept of "Modality" (C41147) defined variously as:
"NCIt Definition: A specific manner, characteristic, pattern of application or the employment of, any therapeutic agent or method of treatment, especially involving the physical treatment of a condition.
DICOM Definition: Type of data acquisition device.
NCI-GLOSS Definition: A method of treatment. For example, surgery and chemotherapy are treatment modalities."
Wikipedia says ("http://en.wikipedia.org/wiki/Modality"):
"In medical imaging, any of the various types of equipment or probes used to acquire images of the body, such as radiography, ultrasound and magnetic resonance imaging."
I don't know what the history of the use of the word "modality" in a medical imaging context is, but it would be fascinating to research it. A quick look at the earliest reference in Radiology shows a mention in 1923 of a "therapeutic quartz lamp", which "enables all patients, because of its low cost, to be benefited by the use of this modality" (http://radiology.rsna.org/content/1/4/245.full.pdf). A therapeutic rather than diagnostic radiology use perhaps, but an early similar use all the same (and I found other mention of the term in a similar vein from the same year).
Given the DICOM precedent, I think it is more practical to consider fMRI and DTI as being "sub types" of a single modality MR.
Likewise MR Angiography is also a "sub type" of MR in DICOM, as are other borderline cases, such as MR Spectroscopy, even though there is not always imaging involved (it was once separate, but not any more, in recognition that one can produce spectroscopy-based (chemical shift, metabolite map) images, for example).
We had a big fight years ago in DICOM about introducing an explicit "modality sub-type" attribute, when we were doing visible light "modalities" and ended up with a generic VL from which we carved out specific modalities like ES (endoscopy) and slide microscopy (SL) as specific needs for different information or encoding for those application areas arose. In otherwords, though the technology may remain the same (a digital camera), the different "accessory" if you will (e.g., the endoscope or microscope) and the application area (e.g., gut, slide, retina, cornea) lead to refinements of what a single attribute Modality would refer to, weighed against what was generally done "together" by the equipment. The compounding of these different dimensions leads to some confusion, but, for example, one generally performs MRI, MRA, DWI, DTI, fMRI, DCE-MRI, MRS and CSI all in the same study on the same device (an MR scanner), whereas one would not perform endoscopy (ES) with a slide microscope (SM) even though they are both visible light (VL). Nor for that matter would one general mix upper and lower GI endoscopy in practice, but it has not proven necessary to separate these by a different DICOM Modality value. Similarly, for time-based waveforms, DICOM has relatively specific modality values like ECG, HD, RESP, etc. (even though those waveforms may emerge from the same "device" as that producing accompanying images and certainly be part of the same procedure).
The reason for the fight, by the way, was that some of us wanted the single Modality attribute that is widely implemented in browsers and databases to remain a single, useful, value, and not to require implementation changes to support multiple values for the same attribute or multiple attributes. As always in DICOM, purity is sacrificed in favor of pragmatic and incremental extension of installed base functionality rather than disruptive revolutionary change.
Hybrid modalities like PET-CT (and now MR-PET) lead to some concern about conflating the "equipment" with the "modality", as well as some cardinality issues in models and queries (hence attributes like "Modalities in Study). For DICOM aficionados, one needs to remember that Modality and SOP Class are not synonymous (hence the addition of "SOP Classes in Study", etc.). Theoretically we could have introduced a new single combined modality value for these cases, but in practice the equipment was two distinct modalities "bolted together" (and still is for many vendors) and the downstream applications (e.g. to perform fusion) were novel anyway, and they evolved to cope with the "two" modalities involved in the one procedure.
However, in general conversation (or the scientific literature) where the context is more "granular", I can see why folks use the term "modality" to distinguish such things as fMRI and DTI, but we should probably try and come up with a better term for that "lower level". RadLex, for example, just makes fMRI and MRA "Is a" children of MRI, which is in turn an "Is a" child of Imaging Modality, without providing a definition of what entity those children are; which actually raises an interesting question about whether traditional hierarchical entity-relationship models such as DICOM uses are sufficient for descriptive purposes, or whether "tagging" anything with concepts that depend on an ontology of relationships, semantic web style, adds more value. E.g., should one tag (semantically annotate) a series of images as being an fMRI, without explicitly saying that it is an MR too, such that if (and only if) the recipient had access to the ontology, it would "know" that relationship. Or should one just anticipate that use case and explicitly define that it is an MR and an fMRI in a model that is explicitly encoded? Of course the current state of the art is that one gets an MR modality value and figuring out that it is an fMRI (or any other highly specific "flavor" of MR) is a challenge, but the enhanced family of DICOM objects (with much more detailed attributes and value sets, but still traditional ER models) are intended to help with that.
Anyway, thanks Scott, for the interesting conversation starter.
David
Sunday, September 18, 2011
IHE Radiology Planning Committee rejects Image Manager/Archive Content Migration Profile
Summary: Other proposals were judged to have higher priority than the Image Manager/Archive Content Migration Profile.
Long version:
Last week I wrote about a proposal that I had drafted for an Image Manager/Archive Content Migration Profile, to use a an offline archive of standard DICOM objects on an external transportable disk array as an approach to the PACS migration problem.
Unfortunately, as you can see from the minutes of the IHE Radiology Planning Committee t/con, other proposals received higher priority for evaluation by the technical committee, which is the next step before shortening the list further.
Irritatingly, I had let my voting rights on the planning committee lapse, since I hadn't participated in the last few t/cons, and the t/con ran over time and I had to leave before the vote, so I am not sure if any else voted for it anyway.
So, not this year, at least in IHE anyway. That said, the lack of an IHE profile does not mean the one cannot implement the idea (though it does mean that one does not have the IHE Connectathon as a venue for testing it).
David
Long version:
Last week I wrote about a proposal that I had drafted for an Image Manager/Archive Content Migration Profile, to use a an offline archive of standard DICOM objects on an external transportable disk array as an approach to the PACS migration problem.
Unfortunately, as you can see from the minutes of the IHE Radiology Planning Committee t/con, other proposals received higher priority for evaluation by the technical committee, which is the next step before shortening the list further.
Irritatingly, I had let my voting rights on the planning committee lapse, since I hadn't participated in the last few t/cons, and the t/con ran over time and I had to leave before the vote, so I am not sure if any else voted for it anyway.
So, not this year, at least in IHE anyway. That said, the lack of an IHE profile does not mean the one cannot implement the idea (though it does mean that one does not have the IHE Connectathon as a venue for testing it).
David
Sunday, September 11, 2011
PACS Migration Using A Standard-format Intermediate Offline Archive
Summary: Creation of an offline disposable archive of standard DICOM objects on an external transportable disk array is proposed as an approach to the PACS migration problem; an IHE profile has been proposed.
Long version:
This isn't actually going to be very long, since most of the content is elsewhere.
On the RCR Imaging Informatics Group there was a recent discussion of PACS migration that arose in the context of the existing contracts expiring some time soon (see "http://www.pacsgroup.org.uk/cgi-bin/forum/show.cgi?2/58490"). During the course of that there was discussion of DICOM "Part 10" format objects, that ultimately lead to a proposal for all PACS to be able to create a a new archive copy on an externally supplied filesystem (directly or network-attached) of standard DICOM files with a standard (lossless) compressed transfer syntax and all the "headers" up to date.
So, since it is that time of year once again, I put together an IHE brief proposal to define an Image Manager/Archive Content Migration Profile for this. Just swap "PACS" for "IM/IA" if you are not familiar with IHE-speak.
This is not a particularly new idea. I recall that many years ago Peter Kuzmak of the VA put forth some suggestions related to an interchangeable archive format for migration with some file system organization and naming as well as potential DICOMDIR-related changes in that context, but using DVD-R; I dug out his old presentation that was referenced from the minutes of the WG 5 meeting in Feb 2000.
Nowadays studies are so large and multitudinous that migrating them on thousands of CDs or DVDs would seem to be infeasible, but the low cost of consumer price-point hard drives and RAID boxes seem to suggest that making what is essentially a "throw away" copy of an entire PACS archive is nowadays realistic. It only needs to last long enough to be populated, reattached to the new PACS and its content imported. The DICOM standard already supports the notion of USB-attached media (physical media unspecified) to allow for flash drives and hard drives, although there may be details that need to be worked through for the sheer size of an entire PACS archive.
Anyway, it remains to be seen how the IHE Radiology Planning Committee receives this, and if they (well, we, since I am a member) don't reject it out of hand, and prioritizes it relative to other profile proposals (since the Technical Committee has limited bandwidth and each year only works on a small number of proposals).
So if any of you out there have any thoughts about whether this is a good idea or a terrible one, or suggestions for improvement of the proposal, please let me know.
Long version:
This isn't actually going to be very long, since most of the content is elsewhere.
On the RCR Imaging Informatics Group there was a recent discussion of PACS migration that arose in the context of the existing contracts expiring some time soon (see "http://www.pacsgroup.org.uk/cgi-bin/forum/show.cgi?2/58490"). During the course of that there was discussion of DICOM "Part 10" format objects, that ultimately lead to a proposal for all PACS to be able to create a a new archive copy on an externally supplied filesystem (directly or network-attached) of standard DICOM files with a standard (lossless) compressed transfer syntax and all the "headers" up to date.
So, since it is that time of year once again, I put together an IHE brief proposal to define an Image Manager/Archive Content Migration Profile for this. Just swap "PACS" for "IM/IA" if you are not familiar with IHE-speak.
This is not a particularly new idea. I recall that many years ago Peter Kuzmak of the VA put forth some suggestions related to an interchangeable archive format for migration with some file system organization and naming as well as potential DICOMDIR-related changes in that context, but using DVD-R; I dug out his old presentation that was referenced from the minutes of the WG 5 meeting in Feb 2000.
Nowadays studies are so large and multitudinous that migrating them on thousands of CDs or DVDs would seem to be infeasible, but the low cost of consumer price-point hard drives and RAID boxes seem to suggest that making what is essentially a "throw away" copy of an entire PACS archive is nowadays realistic. It only needs to last long enough to be populated, reattached to the new PACS and its content imported. The DICOM standard already supports the notion of USB-attached media (physical media unspecified) to allow for flash drives and hard drives, although there may be details that need to be worked through for the sheer size of an entire PACS archive.
Anyway, it remains to be seen how the IHE Radiology Planning Committee receives this, and if they (well, we, since I am a member) don't reject it out of hand, and prioritizes it relative to other profile proposals (since the Technical Committee has limited bandwidth and each year only works on a small number of proposals).
So if any of you out there have any thoughts about whether this is a good idea or a terrible one, or suggestions for improvement of the proposal, please let me know.
Saturday, June 11, 2011
Framing the Big Study Problem
Summary: Large studies such as thin slice CT create a performance problem in unoptimized implementations; DICOM provides several means of addressing these problems without throwing out DICOM entirely and reimplementing, as the MINT folks originally proposed; retrospective use of the enhanced multi-frame family of objects may be able to alleviate this problem, even without support in the modalities, by converting legacy single-frame DICOM objects to enhanced multi-frame objects in the PACS for distribution to workstations or other PACS or archives.
Long version:
A group of folks at Johns Hopkins, Harris Corp, and Vital Images have been working on the "large study" problem and have produced a largely "DICOM free" implementation (apart from modality image ingestion) called Medical Imaging Network Transport (MINT). They are now proposing that this become a new "standard" and be blessed by and incorporated in DICOM as a "replacement". Since the MINT implementation is based on HTTP transport, DICOM WG 27 Web Technology has become the home for these discussions. Not surprisingly, the "replace everything" work item proposal was rejected by the DICOM Standards Committee at our last meeting by a large majority - you can read the summary in the minutes of the committee and see the slides presented by the MINT folks.
The rejection by the committee of the proposal should not be interpreted as a rejection of the validity of the use-case, however.
It is accepted that large studies potentially pose a problem for many existing implementations, both for efficient transfer from the central store to the user's desktop for viewing or analysis, and for bulk transfer between two stores (e.g., between a PACS and a "vendor neutral archive" or a regional image repository).
So, to move forward with solving the problem WG 6 and WG 27 met together earlier this week to try to achieve consensus on what the existing DICOM standard has to offer in this respect, and to identify any gaps may exist that could be filled by incremental extensions to the standard.
If one puts aside the assumption that it is necessary to completely replace DICOM (and hence re-solve every problem that DICOM and PACS vendors have spent the last quarter of a century solving), and instead focus narrowly on the key aspects of concern, two essential issues emerge:
Yet this approach ignores the significant effort that has already been put into "normalizing" each acquisition at the modality end, specifically, the "enhanced multi-frame" family of DICOM objects defined for CT, MR and PET as well as XA/XRF, and new applications like 3D X-ray, breast tomosynthesis, ophthalmic optical coherence tomography (OCT), intra-vascular OCT, pathology whole slide imaging (WSI), etc. The following slide (which I simplified and redrew from an early one produced by either Bob Haworth or Kees Verduin for WG 16) illustrates how the enhanced multi-frame family of objects uses the shared and per-frame "functional groups" (as well as the top level DICOM dataset) to factor out the commonality compared to encoding single slices each with its own complete "header":
Now, it is no secret that adoption of the enhanced family of objects has been very slow, especially by the modalities that already have single frame "legacy" DICOM objects, particularly the CT and MR. Currently only Philips offers a commercial MR implementation and Toshiba offers a commercial CT implementation. Many PACS are capable of storing and regurgitating these over a DICOM connection, but may not be capable of viewing them or sorting or annotating them correctly, or performing more sophisticated functions on them like 3D and MPR rendering, nor for that matter are they well supported in many CD-based viewers, etc.
But it is important to distinguish between gaps in implementations, as opposed to gaps in the DICOM standard. If the standard already specifies a means to solve a problem it should be used by implementers; inventing a new "standard" like MINT to solve the problem is not going to encourage implementation (unless it solves other pressing problems as well). The bottom line here seems to be that PACS vendors in particular are not well motivated to solve in an interoperable (standard) way, any problem beyond ingestion of images; many PACS vendors may be quite happy with proprietary implementations between the archive/manager component of their PACS and their image display devices or software. But the last thing we need are multiple competing standard approaches to solving the same problem (or entire competing standards), since that only compromises interoperability.
So, to cut a long story short, the argument was put forth this week that use of the enhanced multi-frame family of objects for encoding a single "acquisition" as a single object should suffice to achieve the vast majority of the benefits of the "study normalization" suggested by MINT.
We explored some of what could be achieved by using enhanced multi-frame objects and observed that:
So, the new action item for WG 6 (and more specifically for me, since I volunteered to write it), is to produce a work item proposal for the committee to define a new IOD and SOP Class (or perhaps modality-specific family of them), for "transitional multi-frame converted legacy" images, with the deficiency in the existing standard being the lack of a set of multi-frame images that can be fully populated with only the limited information in the legacy images but with sufficient mandatory position, orientation, temporal and dimension information to satisfy the 3D and 4D viewing and rendering and bulk transfer use cases.
In the interim, now that MINT guys have been encouraged to look at the potential use of the secondary capture multi-frame objects, they have the opportunity to experiment with them to see if they can achieve the necessary performance in their implementation.
The following four slides illustrate graphically the principle of migration from:
In what ways does this proposal differ from what the MINT implementation has done to date ?
Also discussed at our recent meeting was the availability of mechanisms in DICOM for gaining access to selected frames and to meta-data (the "header") without transferring everything. Those two features are defined in Supplement 119, Instance and Frame Level Retrieve SOP Classes, which was specifically written to address the consequences of putting "everything" in single large objects. For example, if a report references one or two key frames in a very large object, one needs the ability to retrieve just those frames efficiently. Supplement 119 defines a mechanism for doing so, by extracting those frames, and building a small but still valid DICOM object to retrieve and display. The existing WADO HTTP-based DICOM service also supports the retrieval of a selected frame, as do the equivalent SOAP-based Web Services transactions defined in IHE XDS-I, back ported into the DICOM standard in Supplement 148 WADO via Web Services, currently out for ballot. Though Supplement 119 does defined a SOP Class for gaining access to the meta-data without transferring the bulk data, if one uses the JPEG Interactive Protocol (JPIP) to access frames or selected regions of a frame in JPEG 2000, one can also gain access to the meta-data using a specific Transfer Syntax (see Supplement 106).
Unlike IHE (particularly IHE XDS and XDS-I), the MINT guys are also RESTful at heart, and this is reflected in their current implementation. We tried to keep out of the REST versus SOAP religious wars during our most recent discussion, and focus on what DICOM already has to solve the use case. Yet to be resolved is the matter of whether DICOM already has sufficient pure DICOM network protocol support and HTTP-based support to satisfy the use-cases without having to introduce additional RESTful equivalents. On the one hand there is a Committee and WG 6 level desire to not have multiple gratuitously different ways to do the same thing; on the other hand there may be significant advantages to alternative mechanisms if they can take effective advantage of off-the-shelf HTTP infrastructure components. A case in point is the use of HTTP caching that requires some statelessness in the transactions to be effective. The MINT guys were advised to present evidence that such caching is sufficiently beneficial in order to justify the introduction of yet another transport mechanism, and this is something that WG 27 intends to follow up on.
Related religious wars about whether or not DICOM or HTTP should be used "within" an enterprise (i.e., over the LAN), the extent to which DICOM can be used between LANs that are nominally part of the same "enterprise" but are separated by firewalls (i.e., if the Canadians can do DICOM between two places, why can't Johns Hopkins), why XDS-I is not sufficient, etc., were mentioned but essentially deferred for another day. One key aspect mentioned, but not discussed in much detail, was the matter of user authentication and access control, and the IHE direction that uses Kerberos (EUA) within an enterprise and SAML assertions (XUA) across enterprises; this is easy for DICOM and SOAP-based WS like XDS-I, but potentially problematic for RESTful solutions (like WADO). Whether or not Vendor Neutral Archives (VNA), whatever they are, are a good idea or not was also not debated; we simply agreed that the efficient bulk data transfer from one archive to another using a standard protocol is a genuine use case. That said, the IHE radiology guys (myself included) are contemplating considering (again) the question of whether to separate the Image Manager from the Image Archive Actors in the IHE Radiology Technical Framework, so we do have the opportunity to start a whole new war in a whole new forum.
Another interesting use case that we discussed is the so-called "zero-footprint" viewer that can run in a "standard" browser that makes use of no additional technology, whether it be a medical application or generic plug-in like Adobe Flash or whatever, since not everybody has that available (especially on mobile devices like tablets). This essentially requires that the server be able to provide a source of meta-data and bulk pixel data that is amenable to efficient rendering and sufficient interaction within something as simple as JavaScript. The extent to which DICOM, WADO and IHE XDS-I based web services are lacking with respect to this zero footprint use case, and to what extent aspects of MINT offer advantages, remains to be determined. There has already been a lot of work in this area; see for example the dcm4che XERO approach discussed briefly in this article about the Benefits of Using the DCM4CHE DICOM Archive. I am not surely exactly what state the open source XERO project is in, given that Agfa uses it in a commercial implementation now, but obviously many of the principles are generally applicable. The question of whether a JSON or a GBP representation of the DICOM header is required (as opposed to MINT's dislike of WG 23's Supplement 118 XML representation of DICOM attributes) has not yet been explored; certainly JSON would seem like a more natural fit if JavaScript is the primary mechanism of implementation, but I dare say that could become the subject of yet another religious war.
There are many other practical issues that the MINT folks have encountered, such as the lack of uniqueness of UIDs, or inconsistency in some of the patient or study information between individual slices, but many of these can be characterized as "implementation" problems faced by any PACS or archive when populating their databases, and not something that the DICOM standard (or any standard) can really resolve. I.e., if an implementation fails to comply with the standard it is just plain "bad" (or the model of the real-world in the standard does not actually match the real-world). At some point (usually ingestion from the modality, and/or administrative study merges and other "corrections"), any implementation has to deal with this, and will have to regardless of whether the originally proposed MINT approach or the conversion to enhanced multi-frame DICOM approach is used. With respect to the need for change management, the MINT proponents were made aware of the Image Object Change Management (IOCM) profile defined by IHE, which addresses the use-cases and implementation of change in a loosely-coupled multi-archive environment, as well as the IHE Multiple Image Manager/Archive (MIMA) profile, which addresses archives with different patient identity domains and what to do with DICOM identifying attributes when transferring across domains. With respect to modalities or other implementations that create non-unique UIDs, the need to a) detect and correct for this on ingestion, and b) report the defects to the offending vendor, was emphasized.
Finally, the foregoing should not be taken to mean that switching to the use of multi-frame objects is a panacea, nor indeed a prerequisite for the efficient transport of large multi-slice studies. As we were careful to emphasize during the initial roll out of the enhanced multi-frame DICOM CT and MR objects, the primary goal was improved interoperability for advanced applications, not transfer performance improvement, since it was well known at the time that optimized applications transporting single frame objects can achieve very good performance (e.g., through the negotiation and use of DICOM asynchronous operations, or multiple simultaneous associations if asynchronous operations cannot be negotiated, both of which eliminate the impact of delayed acknowledgment of individual C-STORE operations, whether it be due to network latency or application level delays such as waiting for successful database insertion before acknowledgment). Rather, poor observed performance in the real world is often a consequence of applications simply not being optimized or well designed in this respect, and many vendors' engineers are far too quick to switch to a proprietary optimized protocol and ignore opportunities for optimizing standards-based solutions. As a case in point, this old white paper from Oracle on A Performance Evaluation of Storage and Retrieval of DICOM Image Content, which shows quite impressive numbers for single frame DICOM images using JDBC (not DICOM network) based server to client retrieval over five 1 Gigabit Ethernet connections between server and client (over 400 MB/s, 852 images/s, 1497 Cardiac CT studies per hour). MINT performance figures over a single connection as published so far are also impressive (Harris's results and Vital's results) though the hardware is different. The bottom line is probably that the protocol used is less important than the architecture and implementation details on both end, and in comparing performance claims for specific commercial implementations, one needs to be sure one is comparing apples with apples rather than oranges. The lack of a published industry standard benchmark for these use-cases is probably a significant gap that we should try to close.
The following slide is one that I produced for the early enhanced multi-frame demonstration and educational lectures, about where the DICOM protocol critical delay lies:
The C-STORE acknowledgment discussion is separable but related to the discussion of TCP/IP performance in the presence of significant latency (or also significant packet loss). As was emphasized at the recent meeting by the purveyor of a potential proprietary TCP/IP replacement (Aspera), unmodified TCP/IP over wide area networks is not ideal for taking full advantage of the theoretical bandwidth limits, and both DICOM and HTTP (and hence MINT, which is HTTP-based) are potentially at a disadvantage in this respect. The conventional answer to this is to use multiple connections and associations and to swap out the TCP stack at both ends of a slow connection (e.g., a satellite link), and/or to use a "WAN accelerator" box at both ends (such as something from Circadence). I am not recommending or promoting any of these technologies or companies, since I have no experience with them. I will say that the idea of changing DICOM applications and tool kits to use something other than TCP/IP or to add the ability to negotiate something proprietary (as Aspera was suggesting), is superficially way less attractive to me, than putting in a box in between that takes care of the problem, transparent to the applications, if it achieves anything close to the maximum possible "goodput". Anyway, if you are interested in thinking about TCP/IP performance issues, I have found Hassan and Jain's book High Performance TCP/IP Networking to be a good introduction. In this discussion, not for the first time, trying to take advantage of UDP or features of various peer-to-peer network protocols was also discussed, and a quick Google search on DICOM and P2P or UDP file transfer will reveal some interesting articles and experiments.
David
PS. Note that in the foregoing I reference and provide links to numerous DICOM Supplements that introduced various features; since most of these supplements have long since been folded into the body of the DICOM standard, and may have had subsequent corrections applied, implementers need to reference the latest DICOM standard text and not the old supplement text, as appropriate. I reference the supplements only to provide a historical time line and to provide the context for interpreting their scope and use.
Long version:
A group of folks at Johns Hopkins, Harris Corp, and Vital Images have been working on the "large study" problem and have produced a largely "DICOM free" implementation (apart from modality image ingestion) called Medical Imaging Network Transport (MINT). They are now proposing that this become a new "standard" and be blessed by and incorporated in DICOM as a "replacement". Since the MINT implementation is based on HTTP transport, DICOM WG 27 Web Technology has become the home for these discussions. Not surprisingly, the "replace everything" work item proposal was rejected by the DICOM Standards Committee at our last meeting by a large majority - you can read the summary in the minutes of the committee and see the slides presented by the MINT folks.
The rejection by the committee of the proposal should not be interpreted as a rejection of the validity of the use-case, however.
It is accepted that large studies potentially pose a problem for many existing implementations, both for efficient transfer from the central store to the user's desktop for viewing or analysis, and for bulk transfer between two stores (e.g., between a PACS and a "vendor neutral archive" or a regional image repository).
So, to move forward with solving the problem WG 6 and WG 27 met together earlier this week to try to achieve consensus on what the existing DICOM standard has to offer in this respect, and to identify any gaps may exist that could be filled by incremental extensions to the standard.
If one puts aside the assumption that it is necessary to completely replace DICOM (and hence re-solve every problem that DICOM and PACS vendors have spent the last quarter of a century solving), and instead focus narrowly on the key aspects of concern, two essential issues emerge:
- transporting large numbers of slices as separate single instances (files) is potentially extremely inefficient
- replicating the "meta-data" for the entire patient/study/series/acquisition in every separate single instance is also potentially extremely inefficient, and though the size of the meta-data is trivial by comparison with the bulk data, the effort to repeatedly parse it and sort out what it means as a whole on the receiving end is definitely not trivial
Yet this approach ignores the significant effort that has already been put into "normalizing" each acquisition at the modality end, specifically, the "enhanced multi-frame" family of DICOM objects defined for CT, MR and PET as well as XA/XRF, and new applications like 3D X-ray, breast tomosynthesis, ophthalmic optical coherence tomography (OCT), intra-vascular OCT, pathology whole slide imaging (WSI), etc. The following slide (which I simplified and redrew from an early one produced by either Bob Haworth or Kees Verduin for WG 16) illustrates how the enhanced multi-frame family of objects uses the shared and per-frame "functional groups" (as well as the top level DICOM dataset) to factor out the commonality compared to encoding single slices each with its own complete "header":
Now, it is no secret that adoption of the enhanced family of objects has been very slow, especially by the modalities that already have single frame "legacy" DICOM objects, particularly the CT and MR. Currently only Philips offers a commercial MR implementation and Toshiba offers a commercial CT implementation. Many PACS are capable of storing and regurgitating these over a DICOM connection, but may not be capable of viewing them or sorting or annotating them correctly, or performing more sophisticated functions on them like 3D and MPR rendering, nor for that matter are they well supported in many CD-based viewers, etc.But it is important to distinguish between gaps in implementations, as opposed to gaps in the DICOM standard. If the standard already specifies a means to solve a problem it should be used by implementers; inventing a new "standard" like MINT to solve the problem is not going to encourage implementation (unless it solves other pressing problems as well). The bottom line here seems to be that PACS vendors in particular are not well motivated to solve in an interoperable (standard) way, any problem beyond ingestion of images; many PACS vendors may be quite happy with proprietary implementations between the archive/manager component of their PACS and their image display devices or software. But the last thing we need are multiple competing standard approaches to solving the same problem (or entire competing standards), since that only compromises interoperability.
So, to cut a long story short, the argument was put forth this week that use of the enhanced multi-frame family of objects for encoding a single "acquisition" as a single object should suffice to achieve the vast majority of the benefits of the "study normalization" suggested by MINT.
We explored some of what could be achieved by using enhanced multi-frame objects and observed that:
- though not all modalities can create enhanced multi-frame objects, it is possible to "convert" the original legacy single frame objects into such multi-frame objects
- the modality-specific enhanced multi-frame objects have many mandatory and coded attributes that are not present in the legacy single frame object, which it is challenging if not impossible to populate during such a conversion
- there are "secondary capture" enhanced multi-frame objects that do permit the optional inclusion of position, orientation, temporal and dimension information extracted from legacy single frame objects, and conversion to these might suffice for the vast majority of bulk transfer and viewing and analysis use-cases
- it may be desirable to either a) document in the standard how to perform such a conversion, or b) define new IODs and SOP Classes that are somewhere in between the "everything optional" enhanced secondary capture objects and the modality-specific objects in terms of requirements, in order to assure interoperability of archives and viewers using such an approach
- it may also be desirable to specify the requirements for full round-trip fidelity conversion from the legacy single frame objects to the converted enhanced multi-frame object and back again, to allow intermediate devices to take advantage of the multi-frame objects but still serve extracted single frame objects to legacy receiving devices, of which there will remain many in the installed base
So, the new action item for WG 6 (and more specifically for me, since I volunteered to write it), is to produce a work item proposal for the committee to define a new IOD and SOP Class (or perhaps modality-specific family of them), for "transitional multi-frame converted legacy" images, with the deficiency in the existing standard being the lack of a set of multi-frame images that can be fully populated with only the limited information in the legacy images but with sufficient mandatory position, orientation, temporal and dimension information to satisfy the 3D and 4D viewing and rendering and bulk transfer use cases.
In the interim, now that MINT guys have been encouraged to look at the potential use of the secondary capture multi-frame objects, they have the opportunity to experiment with them to see if they can achieve the necessary performance in their implementation.
The following four slides illustrate graphically the principle of migration from:
- a completely proprietary optimized PACS to workstation interface (where the "viewer" is essentially "part of the PACS"), to
- a DICOM standard PACS to workstation boundary (possible with current single frame DICOM Query/Retrieve/Store interfaces, but likely not "optimized" for performance by the vendor), to
- converting to multi-frame objects (or passing through those from modalities), combined with round-trip de-conversion to support legacy workstations, to
- supporting PACS to PACS (or Image Manager/Image Archive or Vendor Neutral Archive) transfers also using legacy objects converted to multi-frame if supported by both sides:
In what ways does this proposal differ from what the MINT implementation has done to date ?
- the aggregation of meta-data would occur at the "acquisition" level, and not the entire "study" level; this would seem to be sufficient to capture the vast majority of the performance benefit in that when viewing or performing 3D/4D analysis, the bulk of the pixel data and meta-data for each "set" will be within one object
- the enhanced multi-frame objects require that every frame have the same number of rows and columns and mostly the same pixel data characteristics (bit depth, etc.); this means that funky image shapes like localizers will end up in separate objects
- the opportunity exists to pre-populate the "dimension" information that is a feature of the enhanced family of objects, e.g., this dimension is space, this is time, etc., rather than have to "figure it out" retrospectively from each vendor's pattern of use of the individual descriptive attributes
Also discussed at our recent meeting was the availability of mechanisms in DICOM for gaining access to selected frames and to meta-data (the "header") without transferring everything. Those two features are defined in Supplement 119, Instance and Frame Level Retrieve SOP Classes, which was specifically written to address the consequences of putting "everything" in single large objects. For example, if a report references one or two key frames in a very large object, one needs the ability to retrieve just those frames efficiently. Supplement 119 defines a mechanism for doing so, by extracting those frames, and building a small but still valid DICOM object to retrieve and display. The existing WADO HTTP-based DICOM service also supports the retrieval of a selected frame, as do the equivalent SOAP-based Web Services transactions defined in IHE XDS-I, back ported into the DICOM standard in Supplement 148 WADO via Web Services, currently out for ballot. Though Supplement 119 does defined a SOP Class for gaining access to the meta-data without transferring the bulk data, if one uses the JPEG Interactive Protocol (JPIP) to access frames or selected regions of a frame in JPEG 2000, one can also gain access to the meta-data using a specific Transfer Syntax (see Supplement 106).
Unlike IHE (particularly IHE XDS and XDS-I), the MINT guys are also RESTful at heart, and this is reflected in their current implementation. We tried to keep out of the REST versus SOAP religious wars during our most recent discussion, and focus on what DICOM already has to solve the use case. Yet to be resolved is the matter of whether DICOM already has sufficient pure DICOM network protocol support and HTTP-based support to satisfy the use-cases without having to introduce additional RESTful equivalents. On the one hand there is a Committee and WG 6 level desire to not have multiple gratuitously different ways to do the same thing; on the other hand there may be significant advantages to alternative mechanisms if they can take effective advantage of off-the-shelf HTTP infrastructure components. A case in point is the use of HTTP caching that requires some statelessness in the transactions to be effective. The MINT guys were advised to present evidence that such caching is sufficiently beneficial in order to justify the introduction of yet another transport mechanism, and this is something that WG 27 intends to follow up on.
Related religious wars about whether or not DICOM or HTTP should be used "within" an enterprise (i.e., over the LAN), the extent to which DICOM can be used between LANs that are nominally part of the same "enterprise" but are separated by firewalls (i.e., if the Canadians can do DICOM between two places, why can't Johns Hopkins), why XDS-I is not sufficient, etc., were mentioned but essentially deferred for another day. One key aspect mentioned, but not discussed in much detail, was the matter of user authentication and access control, and the IHE direction that uses Kerberos (EUA) within an enterprise and SAML assertions (XUA) across enterprises; this is easy for DICOM and SOAP-based WS like XDS-I, but potentially problematic for RESTful solutions (like WADO). Whether or not Vendor Neutral Archives (VNA), whatever they are, are a good idea or not was also not debated; we simply agreed that the efficient bulk data transfer from one archive to another using a standard protocol is a genuine use case. That said, the IHE radiology guys (myself included) are contemplating considering (again) the question of whether to separate the Image Manager from the Image Archive Actors in the IHE Radiology Technical Framework, so we do have the opportunity to start a whole new war in a whole new forum.
Another interesting use case that we discussed is the so-called "zero-footprint" viewer that can run in a "standard" browser that makes use of no additional technology, whether it be a medical application or generic plug-in like Adobe Flash or whatever, since not everybody has that available (especially on mobile devices like tablets). This essentially requires that the server be able to provide a source of meta-data and bulk pixel data that is amenable to efficient rendering and sufficient interaction within something as simple as JavaScript. The extent to which DICOM, WADO and IHE XDS-I based web services are lacking with respect to this zero footprint use case, and to what extent aspects of MINT offer advantages, remains to be determined. There has already been a lot of work in this area; see for example the dcm4che XERO approach discussed briefly in this article about the Benefits of Using the DCM4CHE DICOM Archive. I am not surely exactly what state the open source XERO project is in, given that Agfa uses it in a commercial implementation now, but obviously many of the principles are generally applicable. The question of whether a JSON or a GBP representation of the DICOM header is required (as opposed to MINT's dislike of WG 23's Supplement 118 XML representation of DICOM attributes) has not yet been explored; certainly JSON would seem like a more natural fit if JavaScript is the primary mechanism of implementation, but I dare say that could become the subject of yet another religious war.
There are many other practical issues that the MINT folks have encountered, such as the lack of uniqueness of UIDs, or inconsistency in some of the patient or study information between individual slices, but many of these can be characterized as "implementation" problems faced by any PACS or archive when populating their databases, and not something that the DICOM standard (or any standard) can really resolve. I.e., if an implementation fails to comply with the standard it is just plain "bad" (or the model of the real-world in the standard does not actually match the real-world). At some point (usually ingestion from the modality, and/or administrative study merges and other "corrections"), any implementation has to deal with this, and will have to regardless of whether the originally proposed MINT approach or the conversion to enhanced multi-frame DICOM approach is used. With respect to the need for change management, the MINT proponents were made aware of the Image Object Change Management (IOCM) profile defined by IHE, which addresses the use-cases and implementation of change in a loosely-coupled multi-archive environment, as well as the IHE Multiple Image Manager/Archive (MIMA) profile, which addresses archives with different patient identity domains and what to do with DICOM identifying attributes when transferring across domains. With respect to modalities or other implementations that create non-unique UIDs, the need to a) detect and correct for this on ingestion, and b) report the defects to the offending vendor, was emphasized.
Finally, the foregoing should not be taken to mean that switching to the use of multi-frame objects is a panacea, nor indeed a prerequisite for the efficient transport of large multi-slice studies. As we were careful to emphasize during the initial roll out of the enhanced multi-frame DICOM CT and MR objects, the primary goal was improved interoperability for advanced applications, not transfer performance improvement, since it was well known at the time that optimized applications transporting single frame objects can achieve very good performance (e.g., through the negotiation and use of DICOM asynchronous operations, or multiple simultaneous associations if asynchronous operations cannot be negotiated, both of which eliminate the impact of delayed acknowledgment of individual C-STORE operations, whether it be due to network latency or application level delays such as waiting for successful database insertion before acknowledgment). Rather, poor observed performance in the real world is often a consequence of applications simply not being optimized or well designed in this respect, and many vendors' engineers are far too quick to switch to a proprietary optimized protocol and ignore opportunities for optimizing standards-based solutions. As a case in point, this old white paper from Oracle on A Performance Evaluation of Storage and Retrieval of DICOM Image Content, which shows quite impressive numbers for single frame DICOM images using JDBC (not DICOM network) based server to client retrieval over five 1 Gigabit Ethernet connections between server and client (over 400 MB/s, 852 images/s, 1497 Cardiac CT studies per hour). MINT performance figures over a single connection as published so far are also impressive (Harris's results and Vital's results) though the hardware is different. The bottom line is probably that the protocol used is less important than the architecture and implementation details on both end, and in comparing performance claims for specific commercial implementations, one needs to be sure one is comparing apples with apples rather than oranges. The lack of a published industry standard benchmark for these use-cases is probably a significant gap that we should try to close.
The following slide is one that I produced for the early enhanced multi-frame demonstration and educational lectures, about where the DICOM protocol critical delay lies:
The C-STORE acknowledgment discussion is separable but related to the discussion of TCP/IP performance in the presence of significant latency (or also significant packet loss). As was emphasized at the recent meeting by the purveyor of a potential proprietary TCP/IP replacement (Aspera), unmodified TCP/IP over wide area networks is not ideal for taking full advantage of the theoretical bandwidth limits, and both DICOM and HTTP (and hence MINT, which is HTTP-based) are potentially at a disadvantage in this respect. The conventional answer to this is to use multiple connections and associations and to swap out the TCP stack at both ends of a slow connection (e.g., a satellite link), and/or to use a "WAN accelerator" box at both ends (such as something from Circadence). I am not recommending or promoting any of these technologies or companies, since I have no experience with them. I will say that the idea of changing DICOM applications and tool kits to use something other than TCP/IP or to add the ability to negotiate something proprietary (as Aspera was suggesting), is superficially way less attractive to me, than putting in a box in between that takes care of the problem, transparent to the applications, if it achieves anything close to the maximum possible "goodput". Anyway, if you are interested in thinking about TCP/IP performance issues, I have found Hassan and Jain's book High Performance TCP/IP Networking to be a good introduction. In this discussion, not for the first time, trying to take advantage of UDP or features of various peer-to-peer network protocols was also discussed, and a quick Google search on DICOM and P2P or UDP file transfer will reveal some interesting articles and experiments.
David
PS. Note that in the foregoing I reference and provide links to numerous DICOM Supplements that introduced various features; since most of these supplements have long since been folded into the body of the DICOM standard, and may have had subsequent corrections applied, implementers need to reference the latest DICOM standard text and not the old supplement text, as appropriate. I reference the supplements only to provide a historical time line and to provide the context for interpreting their scope and use.
Subscribe to:
Posts (Atom)