David Clunie's Blog

Two (or More) Views of the World ...

2012-01-21T07:20:00.000-08:00

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

A Modality, by any other name (would smell as sweet ?)

2011-09-25T05:21:00.000-07:00

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

IHE Radiology Planning Committee rejects Image Manager/Archive Content Migration Profile

2011-09-18T08:43:00.000-07:00

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

PACS Migration Using A Standard-format Intermediate Offline Archive

2011-09-11T07:50:00.000-07:00

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.

Framing the Big Study Problem

2011-06-11T07:00:00.000-07:00

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:

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

MINT, as currently implemented, tries to "normalize" the entire study, and this is what was initially proposed to DICOM.

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

These ideas are not new. For example, adding informative language to the standard about how to perform the round trip for MR objects was discussed at WG 16 during the later phases of development of Supplement 49, and particularly as we were preparing to promote it and demonstrate it. I was not in favor of adding that informative text at the time, but in retrospect it might have limited subsequent confusion if we had. I for one certainly underestimated the inertia of many of the existing modality vendors. WG 16 discussed at that time the use of negotiating the SOP Class over the DICOM association, and "falling back" to sending legacy single frame images when the SCP does not support the enhanced multi-frame image SOP Classes. When I was with GE in the mid-1990's, we used this "trick" when implementing the DX objects in the digital detector systems, i.e., to fall back to CR or secondary capture if the PACS was unaware of the "new" DX objects, and this approach was discussed with the other participants in WG 2 as a means of mitigating the risk of adopting the "new" SOP Classes. If you look at the inside of a modern Philips enhanced multi-frame MR object, you will see in there a private sequence data element, within each item of which is a complete list of all the attributes necessary to reconstruct a set of legacy single frame images, even though many of these duplicate the information contained in the "proper" place in the enhanced object "functional group" sequences; this simplifies the conversion to legacy process because the converter doesn't need to "understand" the enhanced objects functional groups.

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

The emphasis in this discussion has been on the use case for cross-sectional modality acquisitions, which have been the primary source of performance concerns to date. Another area of "large study" concern is digital mammography, which is characterized by relatively small numbers or relatively large images. Given that there are a small number of these, the network transfer (or database insertion and extraction) performance problems of unoptimized implementations may be less of a factor. Arguably, it might be nice to have access to "normalized meta-data" about the handful of images before transferring the bulk data, but this is probably not a sufficient concern to justify throwing away the whole of DICOM to use MINT. A real problem is going to occur when breast tomosynthesis becomes popular, and for these there is already an enhanced multi-frame DICOM object defined in Supplement 125, and modality vendors seem committed to implementing it, given the fact that a dedicated viewer is going to be required for effective use of these, regardless.

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.

Imaging and the PCAST (President's Council of Advisors on Science and Technology) Report

2010-12-12T07:35:00.000-08:00

Summary: Is the national health care IT standards agenda going to ignore the lessons of the past and the progress made so far? If so, what impact will it have on imaging?

Long Version:

This morning I was sent a link to a report on Realizing the Full Potential of Health Information Technology to Improve Healthcare for Americans: The Path Forward released on December 8th, 2010 from the President's Council of Advisors on Science and Technology (PCAST). There is a video available of the press conference at which it was released, as well as some older video from July 16th, 2010 of a panel discussion about some of its content. The noble goals that the speakers in the videos espouse seems to be somewhat at odds with the actual content.

Already various healthcare IT bloggers involved in standards development and deployment have commented in some detail about the technical content of the report, including Keith Boone, John Halamka, and Joyce Sensmeier.

These bloggers all seem slightly dismayed that the report seems to dismiss, or at least not give adequate recognition to, many existing efforts that are well underway. In my own review I see that HL7 is barely acknowledged, CDA is attributed to the ONC rather than HL7, IHE gets a passing mention only, and there is no mention at all of XDS, XUA, XCA, BPPC or any of the many other IHE efforts to move information back and forth across communities.

Instead, amongst the other content of the report that seems pretty reasonable, there is the unsubstantiated assertion made that "document" or "record" oriented interchange is insufficient and that "tagged data elements" with accompanying meta data are necessary, and a new standard for that needs to be written.

If this were a broad non-technical review, I would have no issue with any of that, but it isn't. It is mostly a broad review, but dives into extreme detail about certain technical issues, including security and privacy and access control solutions, implying that somehow the narrowly focused technical solutions proposed are the only solutions applicable to the broad aims of the overall report. This I find distinctly surprising.

But back to imaging, and what prompted me to write this blog entry, given that the HIT professionals and their organizations are more than capable of speaking for themselves. A surprising aspect of the report is the mammogram use case, starting on page 41.

In this use case, a patient has had mammograms performed at multiple locations, and her current physician needs to retrieve them, given, and I am selectively quoting here, "enough identifying information about the patient to allow the data to be located", "privacy protection information—who may access the mammograms, either identified or deidentified, and for what purposes", and "the provenance of the data—the date, time, type of equipment used, personnel (physician, nurse, or technician), and so forth".

OK, sounds like your standard cross-community access to DICOM images use case, something that IHE RadTech is specifically addressing as a profile this year actually (XCA-I), which involves a relatively simple extension to the existing cross community access (XCA) profile used in the XDS world. Now, I don't mean to pretend that cross-community access control (e.g., via XUA) is easy, nor that reconciliation of patient identity across communities (PIX) is easy either. Merely to point out that the problems in this area are lack of deployment and shared infrastructure or the incentives to build such (as the PCAST report rightly emphasizes elsewhere), and NOT lack of standards. We already have standard mechanisms to provide images with the level of completeness and quality required for the specific use case, ranging from pre-windowed downsampled lossy compressed images for undemanding review applications, through to the full set of diagnostic quality images required for more sophisticated uses.

Since we already have standards to do exactly this, it is perhaps not the ideal use case for PCAST to pick. The idea that a mammogram image (or set of four standard view images, all 40 to 120 MB of them) can somehow be treated as a single "data element", like say, a single blood glucose value, flies in the face of decades of experience of an entire industry.

That said, if the example had been a "tagged data element" such as the BI-RADS category from the body of a series of mammography reports from different locations, the example would have been more plausible. Indeed, the notion of being able to query and retrieve that part of the content of what would traditionally be handled as entire documents is very attractive on the face of it, and undoubtedly a desirable goal, though one that does not require rejection of the traditional structured document oriented paradigm to achieve. Nor does the report address the key barrier to adoption of structured as opposed to unstructured content to facilitate data element extraction and query, which seems to be a combination of a lack of tools and incentives to author structured content in the first place.

Regardless, a new "tagged data element" approach is not a pre-requisite for progress, and we do not need to wait for new standards to be promulgated for this before realizing most, if not all of the benefits of connectivity and interoperability.

Nor frankly, do we need to be able to query across enterprises at a particularly granular level, say for which operator performed a study, or what kVP they used. The metadata envisioned by IHE is very narrowly focused for this reason, and the notion of exposing "all available meta data", whilst theoretically possible, has enormous performance implications. This is certainly not the biggest fish to fry in the short term.

The entire continuum from images through documents to "atomic" data elements share common barriers ... lack of any connection at all between enterprises and communities, lack of deployment of existing standard mechanisms for patient identity reconciliation, and lack of deployment of existing standard mechanisms for provisioning and controlling access.

Even on the access control front the report seems to ignore existing standards and infrastructure. After a basic tutorial on security principles, tied to the "tagged data element" concept, the mammography use case is revisited from this perspective, on page 51.

To paraphrase, an access control service authenticates the clinician, assures the patient has granted them access, and provides the locations of the encrypted mammography images, and supplies the necessary decryption keys. Then, and I quote, "in this and all scenarios, data and key are brought together only in the clinician’s computer, and only for the purposes of immediate display; decrypted data are not replicated or permanently stored locally".

Really ? It is hard to imagine how to enforce that. And how practical is it, given that you generally need a pretty clever viewer if not an entire mammography workstation or plugin to your PACS viewer to effectively utilize a mammogram ? Given that the standard of care currently seems to be to import outside studies into the PACS for use as priors and for distribution throughout the enterprise to allow them to be used with the (expensive and advanced) tools that expert physicians are used to using, the report's proposal seems unrealistic.

Though the mammography imaging use case almost reduces to the absurd the notion that this form of restricted access without local importation is workable, even in the case of a local doctor's EHR, I would imagine that they would want to record even a simple data element, such as the blood glucose, imported from outside systems, rather than be restricted to accessing them on demand only. Even to manifest the prior values in a graphical form or as a flow sheet, which would seem highly desirable for enhanced decision making, would be very challenging if "outside" data points could not be persisted locally, permanently. Indeed I dare say there might be a record keeping requirement to maintain such information.

Contrast the PCAST report's proposal with what is already well standardized; as described before with XDS-I used in conjunction with XCA and XUA and PIX mechanisms, the XDS-I Imaging Document Source would provide the DICOM images to the clinician once authorized, encrypted in transit but not otherwise, via the protocol and in the format requested by the recipient, and importable into a "real" mammography display system in the normal manner. All without having to have every DICOM-compatible viewer or display system be updated to support some mythical new "universal language" based on"tagged data elements" and without being prevented from importing the images for transient or persistent use as is necessary to provide quality care. See John Moehrke's blog for a primer on what security features IHE has to offer.

Anyway, without getting too strident about, at best I find some of the technical content of the PCAST report a disappointment. At worst, I see it as a distraction from the most important items of the national agenda, well espoused in other parts of the report, which include finding a way to provide the proper incentives to get connectivity adopted in a manner that improves the quality and efficiency of care, preferably in a manner that gives patients granular control over access to their information.

Also surprising is the choice of the mammography imaging use case as the poster child for PCAST, given that the ONC has essentially ignored imaging in its initial stages of "meaningful use" probably quite reasonably in terms of return on investment, but much to the chagrin of the various professional societies, judging by the ACR/ABR/SIIM/RSNA joint comments and MITA comments. When later stages of "meaningful use" get around to imaging, they will probably emphasize reporting, decision support and avoidance of unnecessary imaging (probably much more important goals), by which time, even in the absence of specific incentives, distributed cross-community image exchange via the "cloud" will probably be commonplace. One could certainly leave the RSNA show a week or so ago with the impression that this is a solved problem, and high time too.

David

RSNA 2010 RFID Update

2010-11-24T09:38:00.000-08:00

By the way, RSNA is still using RFID tags, as described in a previous blog entry ... I checked my badge that arrived in the mail recently and indeed it contains such a tag.

Since last year I microwaved it for too long and it caught fire, and I wandered around the whole week with a black hole on my chest, this year I will use the knife or the chisel.

Just to confirm that indeed the vendors do have access to the tracking information, here is the link to the RFID Exhibitor Package Order Form, a press release from the provider, and the usual spiel in the RSNA materials about what the RFID tag will be used for and how to opt out.

David

Dose Matters at RSNA 2010

2010-11-24T07:07:00.000-08:00

Summary: Look for vendors offering the NEMA X-25 Dose Check feature and DICOM Radiation Dose SR (RDSR) (IHE REM profile) output from their CT modalities, and products able to store and process RDSRs for dose monitoring, alerting and registry submission. Bring along a list of your installed base of CT, PACS and RIS model and version numbers, and ask your vendors when Dose Check and RDSR capability will be supported. Don't forget to ask your PACS, CD burning and importing, cloud/Internet storage and distribution, Modality Worklist (MWL), reporting system, ordering and decision support vendors about this too. Visit the RSNA dose demo at Booth 2852, Exhibit Hall A, South Building.

Long Version:

In my last blog entry, I discussed the need for tools for monitoring and controlling radiation dose from CT, and with RSNA's Annual Scientific Pilgrimage to Chicago coming up next week, I thought I would consider the progress in the last six months, and what attendees might want to focus on. Undoubtedly the CT vendors will be heavily focused on what new dose-reduction technology they can deliver in new products, but do not lose sight of the importance of evaluating the monitoring and management technology as well.

One notable event was the release in November of a public letter from the FDA to MITA (NEMA), the vendors' trade organization, summarizing their investigation of the brain perfusion incidents.

In October, NEMA released the X-25 Computed Tomography Dose Check standard, which you can download from here. This feature, which the vendors had already committed at the FDA Public Meeting to develop and implement, is intended to "notify and alert the operating personnel ... that prepare and set the scan parameters — prior to starting a scan — whether the estimated dose index is above the value defined and set by the ... institution ... to warrant notification to the operator". Clearly this requires two things, 1) the implementation of the feature in the scanner, and 2) suitable values to be configured by the institution. No doubt the vendors will promulgate default levels, and organizations like AAPM or ACR might provide them, or the local medical physicists may decide for themselves. Eventually the X-25 feature will get folded into the CT manufacturer's safety bible, IEC 60601-2-44.

The RSNA meeting will be an opportunity for you to ask the CT sales people and application specialists about the Dose Check feature, and particularly how and when they plan to retrofit the scanners you already have installed to support it and how much it will cost (if anything). A commitment to the FDA is one thing, but there is nothing like evidence of demand from the customers to motivate product managers to deliver.

X-25 distinguishes between "notifications" for "protocol elements" prior to scanning, and alerts for the "examination" that accumulate what has been done so far. There is also an alert prior to saving (not just attempting to perform) a protocol that exceeds limits, which specifically helps to address a concern that arose in the Cedars-Sinai perfusion incident. Proceeding despite a notification or alert requires the recording of who, what, when and why in an audit trail. DICOM is working on additional information to be included in the Radiation Dose Structured Report (RDSR) to record the X-25 parameters and audit trail information (see CP 1047). You might also want to ask the modality vendors at RSNA when they plan to implement CP 1047, which should be made final text at the Jan 2011 WG 6 meeting. If you are looking for dose monitoring systems that can process RDSRs, you might also want to ask them about when they plan to be able to provide you with a human-readable report of CP 1047 X-25 events.

On the subject of RDSR, one vendor, GE, has already provided a list of which models and versions of scanner support RDSR, and which earlier models produce dose screen secondary capture images; you can find the list here. Hopefully other vendors, perhaps at RSNA, will provide a similar list, and I will tabulate them on the Radiation Dose Informatics web site on the Software and Devices page. In lieu of information supplied by the vendors, I will also tabulate information based on what scanners and models that I encounter RDSR objects from, so feel free to submit samples to me if you encounter them.

When shopping for new CT scanners or upgrades next week, asking the vendors for RDSR support is something obvious that you should do, but even if you are not buying new equipment, it is reasonable to ask about upgrading your installed base. If I were you, I would bring along a complete list of all the equipment that I was responsible for including models and versions, and ask very specifically of the sales people, which of those on my list can be upgraded, and when, and which of those will never be upgraded. Not only will this serve to alert the product managers to your concern about this issue, but the answers will help you plan your own dose monitoring strategy. If you don't get the answer that you want to hear (all your scanners will soon support RDSR), then you are going to need to develop a strategy that perhaps involves a third-party solution that can either OCR the dose screens if the scanners produce them, or provides a means for operator data entry and transcription of the information displayed on the console.

As for "dose monitoring systems", or whatever the name the industry is going to converge on for monitoring and reporting CT scanner dose output, the upcoming RSNA is an opportunity to look around for vendors of those systems too. It remains to be seen whether this feature becomes routinely embedded in the PACS or the RIS, or whether for the time being or indefinitely, it will be the province of dedicated third-party systems (I will maintain a list of the latter at the Software and Devices page, which is, so far, depressingly short).

In the IHE REM profile, the modality can send RDSRs either to the Image Manager/Image Archive (IM/IA) (usually the PACS) or directly to a Dose Information Reporter (DIR), which might be the RIS or a third-party system, or such a system may query the PACS. The REM design assumes that since RDSRs are DICOM objects, the PACS is the logical actor to persist and distribute them.

However, RDSR output from the modality is not going to be of much immediate use to you if a) your PACS won't accept and store them, and b) you don't have something that will display their content and, more importantly, produce management reports of dose output, if not alerts and notifications when limits are exceeded. At the very worst, you can start storing these RDSRs in the PACS now, so that when you do settle on a dose management solution, you will be able to use your historical data, as both a benchmark for your local historical practice, as well as for individual patient dose management decisions (recognizing the limitations of using dose output as a surrogate for effective dose to the patient).

Accordingly, not only do you need to be asking your CT vendor for RDSR output, but you need to be asking your PACS vendor if they will accept, store and faithfully regurgitate RDSRs, even if they do not yet have plans to render and collate the contents.

This also includes recording RDSRs on CDs, since referring physicians want to know about dose too, as does the next facility in the chain that is going to import these CDs. So your third-party CD burning and import and viewer vendors are also candidates for interrogation next week about RDSR support. You also need to ask any Internet distribution and storage vendors offering "CD substitutes" in the "cloud" about this too.

Your RIS vendor doesn't escape either. Though they may not be planning on offering RDSR management, they will still be providing Modality Worklists (MWL) to the CT scanners. It turns out that it is really important to convey the age, sex, height and weight information, as well as anatomic and procedure codes, if downstream one is to make size-appropriate use of the dose output information (which after all is based on standard sized phantoms and needs adjustment for kids and for particularly small or large people). The CT scanner vendors are well aware of these issues, and hopefully can reliably copy the information from the worklist into the RDSR (another question to ask your scanner vendor if you want to get into that much detail with them).

Finally, when generating the radiology report, it is good practice if not required by regulation (such as in Germany or now California with SB 1237), to include information about the radiation dose, and a creative reporting system vendor could automatically copy information directly from the RDSR for the study into the report template being populated by the radiologist. Now is the time to get the reporting system vendors thinking about this, particularly since some of them already offer features for doing the same sort of thing from other types of structured report "input", notably for ultrasound and echocardiography. Even the ordering and decision support system vendors should not be immune to your questions, since they too can take advantage of patient-specific historical information acquired from RDSRs.

In conclusion, next week you have the opportunity to put penetrating questions about radiation dose to everyone you meet with a product that is involved in any part of the imaging chain, from ordering all the way through to reporting.

If you want to get a more detailed briefing, perhaps prior to visiting the vendors' booths, and see some of the components of the IHE REM profile in action, feel free to come and visit the RSNA Image Sharing and Radiation Dose Monitoring demonstration. A group of CT modality, PACS and dose reporting vendors, together with some academic groups, the ACR and myself will be participating. Strangely enough this will actually be held in the Technical Exhibits area, rather than in the Lakeside Learning Center, specifically Booth 2852, Exhibit Hall A, South Building. Email me if you can't find the demo or have any questions about it.

David

PS. By the way, while I am thinking of it, if you use lossy compression in your archive, make sure it is turned off for series that contain dose screens (or indeed any secondary captures containing text and graphics like perfusion curves), since not only will it make them look like crap but will also reduce the performance, if not entirely cripple, any OCR that you might later apply.

Dose Matters

2010-05-31T17:36:00.000-07:00

Summary: Reducing the radiation exposure from diagnostic imaging is an increasing priority; standards exist for encoding dose information but are not yet widely adopted, though soon will be given regulatory pressure and industry commitments; few tools, commercial or open source, exist yet for monitoring and reporting radiation dose.

Long Version:

You would have to have been living on a desert island or under a rock to not be aware that there is a heightened sensitivity amongst the general populace and the regulatory authorities to the matter of radiation dose exposure from diagnostic imaging and the risk of cancer. Whether it be well publicized disasters like the Jacoby Roth or Cedars-Sinai incidents, or general concern related to dose from procedures like virtual colonoscopy, or articles evaluating the contribution of diagnostic imaging as a source of exposure, the need to deal with the matter is inescapable. This is true regardless of whether you are a "believer" in the linear no-threshold model, which says that no amount of radiation is safe, or not. The FDA is going to require that efforts be made to reduce the dose delivered by both CT and fluoroscopy, as discussed in their initiative white paper and reviewed at the recent public meeting, though they have been working on this for some time. Vendors are already delivering equipment incorporating dose saving technology. Attention is being drawn to the radiation dose caused by the ordering of repeat or low-yield procedures, as well as optimal strategies for pediatric imaging (image gently).

Yet so much remains in the hands of the user in terms of ordering as well as performance of the examination. If you cannot measure it, you cannot improve it (Lord Kelvin), so the question arises as to how one can track the amount of radiation being delivered, either to the population, or at a site, or to an individual, and hence benchmark one's own performance then make improvements to the process. Surprisingly, though devices have long been required to provide visual feedback to the operator at the console, it has proven remarkably difficult to get this information out of the scanners and into some sort of database or registry that can be searched or monitored.

DICOM has a number of ways that dose information can be encoded, but for the last few years has been focusing on the Radiation Dose Structured Report (SR), with the goal of having the modalities produce this directly. Many people expect that dose information would be in the image headers, but the image is the wrong place to encode this; images may be transmitted before the study is complete and hence not contain the cumulative information, and more than one image may be reconstructed from the same irradiation event, creating the risk that the dose may be counted more than once. Further, not all originally acquired images are necessarily retained (e.g., thin slices from CT), and a large volume of images is a poor means of communicating what is essentially a small amount of information. One upon a time, it was thought that the modality performed procedure step (MPPS) might be a suitable mechanism to communicate this information, but it was soon realized that there is no easy way to persist what is essentially a transient message, not to mention that MPPS is relatively poorly adopted.

To meet the users' immediate needs, some vendors have gone so far as to provide images that are saved screens containing the text of the delivered dose information. Both GE and Philips do this, and there is a large installed base of such scanners as well as archives full of such information. Though Philips had the foresight to also encode the same information in the header attributes of these images (albeit in a non-standard way), both as plain text and as individual elements, unfortunately GE did not, so many folks who want to perform a retrospective review of their dose information need to manually examine these images, or develop some optical character recognition (OCR) software.

For the time being, there is a relative paucity of tools available both to handle information from legacy devices, as well as to use more standard approaches, including that espoused in the IHE Radiation Exposure Monitoring (REM) profile, which is based on modalities producing DICOM Radiation Dose SR objects, and provides specific actors for consuming and reporting information, including transmission to registries, such as the ACR's Dose Index Registry. The good news is that there has been significant activity at recent IHE Connectathons with respect to implementing REM; you can review these yourself at the connectathon results page, where you can see which vendors have specific offerings in this field. MITA, the modality vendors' industry trade group, has made a strong commitment not only to dose reduction in general, and the CT Radiation Dose Check feature, but also to retrofitting at least the current platform in the installed base to produce DICOM SR objects .

At a recent teleconference of the newly convened Quality and Safety Subcommittee of the RSNA's Radiology Informatics Committee (RIC) , it was apparent that several academic groups have been working in this field, and the need to make available open source tools was highlighted, if for no other reason than to serve until the industry catches up and provides a robust infrastructure.

To this end I thought I would externalize some of my own primitive efforts, as extensions to my Pixelmed Java DICOM toolkit. Specifically, I put together a little application called DoseUtility, which brings together a number of components that I have been working on, including the construction and validation of Radiation Dose SR objects, as well as the ability to perform OCR on GE dose screen saved images. I have already used the validator to good effect during the last few connectathons, and the experience constructing and testing it has led to a number of proposed changes to the standard and the IHE profile.

Eventually I hope to extend this tool and its components to provide a complete infrastructure for dose management, at least from the DICOM and IHE side of the problem. Currently it focuses on CT, but it will be extended to fluoroscopy and projection X-ray soon, as well as injected dose from NM and PET, as those standards evolve.

I dare say that the various academic groups who have been working on the same types of problems may well have much more sophisticated tools, likely more easily integrated with their own PACS and RIS, perhaps taking advantage of proprietary APIs. As yet, I am unfamiliar with the specifics of most of them, but I will make a catalog of whatever becomes available.

David

This blog has moved

2010-04-28T04:23:00.001-07:00

This blog is now located at http://dclunie.blogspot.com/.
You will be automatically redirected in 30 seconds, or you may click here.

For feed subscribers, please update your feed subscriptions to
http://dclunie.blogspot.com/feeds/posts/default.

To push or to pull: that is the question

2009-04-13T03:25:00.000-07:00

"Whether 'tis nobler in the mind to suffer
The slings and arrows of outrageous delay and inconvenience,
Or to take arms against a lack of bandwidth,
And by anticipating avoid it?"

Summary: Sharing of images across the network is a potentially attractive alternative to CDs, but image sets are large, bandwidth is limited, lossy compression is controversial, security infrastructure is non-existent, and recipients are busy and impatient; why have to pull images on demand slowly or with poor quality, when one can anticipate where they are needed and push or pre-fetch ? The standards and technology exists now, not tomorrow.

Long version:

There is a renewed enthusiasm for image sharing using the network.

This idea is not new, and for many years now the momentum has been growing to establish standards and build infrastructure to support image as part of the distributed electronic record. In the current US political climate, the huge cost and disparate availability of health care (and imaging utilization in particular) has IT proponents, who are as eager to jump on the stimulus package gravy train as anyone else, seeking to find a "meaningful use" of IT to address the image sharing problem.

The current generation of computer literate doctors is used to the convenience of the Internet, and on-demand access to arbitrary information à la Google. It is reasonable for them to demand that they have access with a similar level of convenience to patient information, including images.

However, this requirement is easy to demand but not so easy to satisfy. Practical realities intrude: radiological images are more complex than consumer grade images, need more manipulation for adequate interactive visualization, tend to be very large individually (e.g., digital mammograms) and occur in very large sets (e.g., thin slice CT or CT/PET). Yet bandwidth, particularly in the "last mile" from the providers to the Internet, is limited.

Some tout the use of lossy image compression as a panacea, yet this remains controversial and adequately powered studies to "prove" that such compression does not lower the quality of care are few in number. Others say the bandwidth problem will go away over time, yet in underserved rural areas, and particularly in medical offices, high-speed DSL or cable access is limited; for large institutions with very large volumes, very high bandwidth "pipes" may add significantly to operational cost. Even with high bandwidth, high latency can degrade the transfer rates achieved and impact any interactive protocol perceptibly. Like healthcare in general, not everyone has equal access at equal cost.

Leaving the DICOM images "on the server" and interacting remotely with an application, either using a proprietary approach like Terarecon's, or a generic application sharing approach like Citrix, or web browser approach that serves up consumer format images on demand, is certainly possible. These approaches introduce new classes of problems such as access control and familiarity with the user interface. One frequently hears from radiologists who serve a number of hospitals, about how irritating it is to have to learn the remote interface of each of the different installed PACS, for example. This is exactly the same problem that the AMA has raised about the different viewers on different vendors' CDs. Provisioning every possible user with the appropriate identity and authentication information, and then assuring they have access to what they should have and nothing else, is also obviously a major administrative task. In the absence of a national or regional infrastructure for centralizing such provisioning, or a framework of "trust" between providers, this will remain a difficult problem. Providing patients with access to their own information and images adds another dimension to the scale and complexity problem.

For years now IHE has been promoting its cross-enterprise document sharing (XDS) architecture as a potential solution. The idea is to have each source register what it has available with a centrally accessible registry, and then consumers use the location information in the registry to go back to the source repository to pull what they need. The underlying technology is appropriately buzzword compliant (XML and SOAP and all that), and there is an additional layer to deal with the number and size of images (XDS-I, currently undergoing revision to become XDS-I.b using MTOM/XOP to efficiently handle the binary image data). However, this architecture still presupposes an unparalled (and as yet largely unimplemented) degree of cooperation between everyone involved in the sharing problem.

Healthcare providers do not normally cooperate, at least in the US; indeed the very essence of the healthcare system encourages them to compete, and cooperation is anathema to them. Does it make sense to rely on the future deployment of an infrastructure that involves cooperation and yet likely with additional cost associated with it and little incentive to participate ? Who are the providers already interested in providing information to ? Their "customers" obviously, the referring doctors who order (or in civilized countries "request") the imaging services in the first place.

These referring doctors span the gamut in terms of technologic sophistication and requirements. Some may be satisfied with just the report. Many though, and often it depends on the specific patient and their condition, will need some access to the images. A significant proportion will need access to the original DICOM images in order to perform their own interpretation or to use their own visualization or planning tools. Yet these are busy people who have neither the patience, nor the time to waste, nor are reimbursed for, screwing around with artifical technological barriers to using the images, such as network delays or unfamiliar user interfaces

Should it not be a simple matter in this day and age to send the images to where they are needed, just as one sends (faxes or emails) the report, a well established practice ?

Obviously this is possible. No imaging facility is going to perform an examination without knowing who ordered (requested) it, so the information about where to send it exists. If the potential recipients had a system capable of receiving it, this process could be automated.

Just as I have advocated in the past that referring doctors set up a system in their office and have their staff handle CD importing, so that such images are ready to view in their system when they need them, one could envisage the same or a similar in-office system with a port listening to the outside world ready to receive incoming images. Just like the fax machine that is sitting their waiting to receive phone calls.

Do the standards and technology exist to do this safely and securly right now ? Of course they do. All one would need is to perform an ordinary DICOM network transfer of the images from the sending site (imaging center) to the receiving site (referring doctor). Should it be a secure transfer to protect confidentiality ? Of course it should, but one does not need to set up a VPN to every possible referring doctor, nor from every possible sending site, since DICOM already defines transport over TLS (SSL), the same encryption protocol that one uses for ecommerce with sites with whom one has no pre-established relationship.

Does one need any identification or authentication infrastructure to achieve these ? Beyond perhaps checking that the receiving site has a valid TLS certificate (signed by a well-known certificate authority, just like for web browsing), the answer is no. The fact that the recipient ordered (requested) the examination should be sufficient to establish that they are entitled to access the images, for example. By analogy, one does not require any special authentication to receive the faxed report.

Would recipients potentially be vulnerable to "DICOM image spam" ? Well theoretically if someone attacker was that determined, but this would easily be solved by "filtering" on a list of known and approved source sites.

Is there any risk to the integrity of the sending site ? Well no, because this is an outbound transfer (push), and there is no need for the sending site to respond to queries (unless for some reason, it wants to).

This is pretty easy stuff to set up, and apart from the encryption layer, involves nothing that imaging vendors are not already intimately familiar with. No fancy web services stuff, no XML or SOAP messages. Just plain old boring store-and-forward point-to-point DICOM. And there are certainly already software tool kits that provide support for the secure transfer of DICOM images over TLS. Some of these tool kits also support the use of the various standard lossless and lossy compression "transfer syntaxes" that DICOM defines, including JPEG 2000, which can be used as appropriate and negotiated automatically depending on the receiving system's capabilities. Is DICOM the fastest possible network transfer protocol ? Well arguably not, depending on the latency of the network and the quality of the implementation, but in a store-and-forward paradigm this is much less of a factor, and there are many ways to optimize DICOM transfers if required, without throwing away the interoperability of a well known protocol.

What about confirming the success of the transfer ? One could use the existing DICOM Storage Commitment in the same way IHE uses it between modalities and the PACS, and/or one could include a "manifest" of what should have been sent, e.g., as a DICOM SR the way the IHE Teaching File and Clinical Trial Export (TCE) profile does.

What about the matter of inconsistent patient identifiers ? How is the receiving site going to know how to match the incoming images that use the imaging center's patient identifier against their own internal patient identifier. This is certainly a non-trivial problem, but just as when paying an invoice a business normally tracks the orderer's purchase order number in addition to its own numbering system, there is no reason why an imaging system cannot do the same. There are certainly HL7 and DICOM attributes related to dealing with this class of problem, but in the short term and in the absence of a consistent convention for handling this, it may be necessary to have a heuristic matching algorithm and/or human oversight of this "import reconciliation" problem. Perhaps one day there will be a national patient identifier to reduce the complexity of this problem, but there will always be errors that need reconciliation. The same class of problem exists with CDs, and the IHE Import Reconciliation Workflow (IRWF) profile provides ways to deal with this, either an an unscheduled manner by using patient identity queries, or in a scheduled manner, whereby the system that placed the order in the first place could be expecting the result in the form of images and perform the matching against a reduced set of potential alternatives.

Note that this entire solution avoids the need for any type of centralized infrastructure. It just needs the sending site to know the "DICOM address" (host, port and AET) of the ordering (requesting) doctor's site to which to send the images. This could be configured in the system in advance, just like the fax number for the report, and it could be included in every order (printed or electronic) to allow manual or automatic addition of new sites.

Ideally the sending capability would be built in to imaging centers' information systems and PACS. Could one retrofit an existing RIS/PACS with this capability with a third-party device or piece of software ? Certainly; one could envisage a system in which the modality worklist provider was polled on a regular basis to extract information about what examinations had been requested, and within the worklist entries there should be identification of the referring doctor. Such a system would then query the PACS to see what images were available for these requests, retrieve them, and forward them on to the pre-configured recipients site. Other DICOM services, such as Modality Performed Procedure Step (MPPS) and Instance Availability Notification (IAN) might be of additional assistance in making this process more reliable or timely, and in particular help assure that a complete set of images was transferred. Alternatively, rather than polling the MWL provider, one might listen to an HL7 ADT and Order Entry feed to extract the order information or gather additional details.

The bottom line though is that the images could be in the hands of the remote referring doctor before the radiologist has even had a chance to look at them, a state that has become well established as appropriate within a typical enterprise's PACS and hence should be available to outsiders as well.

What if a mistake is made, and the images need to be corrected later ? This is the same class of problem that one faces with film, or faxed reports or CDs, and in the short term there likely needs to be a human process involved to be sure that everyone is notified. That said, the more immediate and automated transfers become the more this is potentially an issue; it is shared by all distributed infrastructures whether point-to-point or centralized or federated. IHE has started to define transactions for flagging images as rejected (using a DICOM Key Object Selection Document with a defined title), with the intent that the corrected images then be resent. This has work has been started in Image Rejection Note Stored transaction of the IHE Mammography Acquisition Workflow supplement.

What if there are multiple potential recipients, i.e., a "cc list" on the order, such as is often the case when a specialist orders (requests) the examination with the intent of referring the patient onwards, as well as sending a copy to the primary care doctor ? Simple, forward the images to everyone on the cc list. From a consent and HIPAA Privacy Rule authorization perspective, it would be the responsibility of the person writing the order (request) to be sure that everyone on the cc list was appropriately authorized.

What if the patient wants a copy ? Well, it is unlikely that they would have their own personal receiving setup, and unreasonable to expect the imaging provider to support every such recipient (at least until this became as ubiquitous as email). There is always CD of course, but if the patient had a personal electronic health record provider (whoever that might be), they would be able to designate that provider's address as a target, and the imaging provider could send the images there as well. Likely there would be a few such providers configured in advance and it would merely be a matter of recording which one with the patient's registration information.

Are there other use-case beyond the simple "order imaging, perform imaging, send to orderer" example ? Certainly there are. The typical emergency case referral, in which a patient is imaged at the first site then transferred for further care, is an example of whether the same point-to-point store-and-forward paradigm can be used. Though in this case, one needs an infrastructure with sufficient bandwidth to cope with the disaster scenarios where a lot of images on multiple patients need to be transferred very quickly; as a consequence, a more formal arrangement between the two sites is probably necessary than the more ad hoc "email like" pattern for an arbitrary and extensible set of referring doctors.

Teleradiology use-cases, either for a specialist radiologist consultation, or primary interpretation "at home", or even a preliminary interpretation off-shore, are other examples in which exactly the same paradigm store-and-forward paradigm is applicable. This is nothing new, and people have been doing exactly this for many years, using DICOM C-STORE transactions with or without compression in some cases and proprietary protocols in others. Some such teleradiology scenarious could be better supported by removing the patient's true identity first and replacing it with a reversible pseudonym (e.g., for specialisty or off-shore teleradiology), but that is a subtletly and not a pre-requisite.

All that is new here is essentially recognition that every potential recipient needs a secure DICOM "address", just like an email address, and that sending sites be configured to support a multitude of them, and that recipients need to have an Internet connected "DICOM listener" ready to receive images into their own preferred viewing system. I.e., it is a matter to taking well-established existing technology and making it routine rather than occasional.

Does this undermine the need for centralized and regional archives and repositories and registries, and web services orientated infrastructures that are more easily integrated with other sources of information than images ? No, certainly it does not, since there are many other use-cases in which the doctor needs to search for information whose need cannot be so easily anticipated. Still though, many of those use-cases can make use of a certain amount of prior knowledge to optimize the doctor's experience, for example by pre-fetching relevant prior or current images to local system, again to prevent interactive delays or the need to use unfamiliar user interfaces. After all, it is a rare patient that is seen without an appointment.

However, in the interim, there is no need to wait for these archives and repositories and registries to be built, administered or paid for by someone (else).

In the longer term there will no doubt be competing protocols to DICOM network services for the store-and-forward transaction (which might be zip file encapsulated, and secure or grid ftp based) and for retrieval transactions (which might be web services based). I am sure that both sending and receiving systems will grow to support multiple different transactions as this shakes itself out. The store-and-forward payload will always remain pure DICOM of course, since there is no competition for the "file format" itself (as opposed to the interactive on demand display use case, for which protocols like JPIP and its ilk show promise).

But you don't need to wait for a new infrastructure, or new standards, or a new incentive (reimbursement or regulatory) model to deal with some of the easy use-cases. Just go ahead and do it with DICOM.

David

RSNA 2008 RFID Tracking of Attendees

2008-11-29T09:21:00.001-08:00

Summary: RSNA is tracking attendees in the vendors' exhibit areas with RFID tags, with very little notice to the attendees; if you value your privacy, opt out or destroy the RFID tag in the back of your badge.

Long version:

I rarely duplicate an entire post from something that I have contributed to another forum, Aunt Minnie on this occasion, but in this case I feel strongly enough to reproduce the material in its entirety here.

Last year I got a bit annoyed that RSNA had deployed RFID tags in the attendees badges, for the purpose of piloting tracking attendance in the technical exhibits (i.e., vendor's booths), after Dalai pointed this out in his blog. See "http://www.auntminnie.com/forum/tm.aspx?m=120792". Mostly I was concerned about it not being made very clear to folks that this was going on, rather than because there was anything particularly nefarious about it.

This year, RSNA is again using this technology, and if you look for example at the back of my badge, you can see it taped underneath a label that identifies it:

In the RSNA Pocket Guide, the subject is also specifically mentioned, with instructions on where to go to "opt out" if you want:

Here is an article for from RSNA 2008 for the exhibitors, entitled "Increasing Revenue with RFID Exhibit Booth Tracking", which puts the objectives in perspective. Note that this is not a totally clandestine effort, and though in my opinion notice to registrants is hardly prominent, it was mentioned in the "November RSNA News", which contains similar text to what is in the pocket guide. What really bothers me is that there seems to be no mention of it at all in the "Registration Materials", at least as far as I can find (please correct me if I am wrong about this).

Now, whilst I am happy for RSNA to know that I attended, and happy to know which scientific sessions I participated in to help their planning, I am not at all happy about providing that information to the vendors. So, whilst I do not yet know what their "opt out" mechanism is, I suspect it is to record your details to be excluded from the reports sent to the vendors (they did that on request last year in my case).

So this year I am going to be proactive and remove or destroy the RFID tag that is in my badge. This is actually easier said than done, because it turns out they are tough little f..rs. The sticky label on the back of the badge will not peel off cleanly. Attacking the chip or antenna with a scalpel reveals that they are very hard, and without any way of confirming that the device is actually no longer working, doing a really good job (e.g., on the chip with a hammer) is going to make a mess of the badge. A Google search on the Internet (see for example, "How to kill your RFID chip") reveals that a short time in a microwave oven does the job, though at the risk of starting a fire, which doesn't sound cool. Also, most attendees won't have a microwave in their hotel room. I tried it on my wife's badge first (!), and when that didn't catch fire, did my own, and whacked the chip with a hammer, nailed it with a punch a couple of times, and cut the antenna. That said, I would still rather peel the whole thing off if it didn't look like the whole badge would tear apart.

Anyway, if you respect your privacy, as I do, then I suggest you find a way to deactivate the device before you go wandering around, and if you forget, make sure to go an opt out to prevent the information being disseminated.

David

PS. Another thing that bothered me last year was that the signage that notifies attendees that this sort of monitoring is going on was not terribly prominent. I will update this post as I wander around and investigate.

The DICOM Exposure attribute fiasco

2008-11-22T04:51:00.000-08:00

Summary: The original ACR-NEMA standard specified ASCII numeric data elements for Exposure, Exposure Time and X-Ray Tube Current that could be decimal values; for no apparent reason DICOM 3.0 in 1993 constrained these to be integers, which for some modalities and subjects are too small to be sufficiently precise; CPs and supplements since have been adding new data elements ever since to fix this with different scaling factors and encodings, so now receivers are faced with confusion; ideally receivers should look for all possible data elements and chose to display the most precise. Next time we do DICOM, we will do it right :)

Long Version:

Just how difficult can those of us who write standards for a living actually make an implementer's life ? Pretty difficult, is the answer, though largely this occurs as we strive to avoid breaking the installed base of existing applications that might never be upgraded.

Today I was responding to a question from a software engineer at a vendor of veterinary radiology equipment who had come to realize the the "normal" attribute for encoding Exposure Time was insufficiently precise, given that it was restricted to being an Integer String, and small things, like cats, may have exposure times shorter than a whole second. I say "normal attribute", because the original CR IOD, and most other IODs since, have used this and other attributes with similarly constrained encoding to describe X-Ray technique, and in some cases made these attributes mandatory or conditional. The attributes I am talking about are:

Exposure (0018,1152), which is IS VR
Exposure Time (0018,1150), which is IS VR
X-Ray Tube Current (0018,1151), which is IS VR

This problem was realized not too long after the standard was published and the resulting fix was published as final text in CP 77 in 1996, entitled "Wrong VR for exposure parameters". So, what's the problem, you might ask, it's fixed right ? Well, the problem is the nature of the fix.

A naive approach would be to just change the VR for the existing data element, say from Integer String (IS) to Decimal String (DS), which would then allow fractional values. The problem with this solution would be that recipients that expected a string formatted in a particular manner might fail, for example if the parser, or display text field or database column did not expect decimal values. I.e., existing implementations might be broken, which is something we always try to avoid when "correcting" the standard.

You might well ask why the standard makes the distinction between integer strings and decimal strings in the first place, or indeed allows for both binary and string encoding of integers and floating point values. For example, a number might be encoded as an integer string (IS), decimal string (DS), unsigned 16 bit short (US) or 32 bit long (UL) or signed 16 bit (SS) or signed 32 bit (SL) binary integer, or as a 32 bit (FL) or 64 bit (FD) IEEE floating point binary value. The original ACR-NEMA standard had fewer and less specific encoding choices; it specified only four choices for value representation, 16 bit binary (BI), 32 bit binary (BD), ASCII numeric (AN) and ASCII text (AT). Note that there was no distinction between signed and unsigned binary values, and no distinction between integer and decimal string numeric values, and no way to encode floating point values in a binary form (indeed the standard for encoding binary floating point values, IEEE 754, was released in the same year as the first ACR-NEMA standard, 1985, and certainly was not universally adopted for many years). Anyway, if you review the list of data elements, the authors of the ACR-NEMA standard seem to have taken the approach of encoding:

structural elements related to the encoding of the message (like lengths and offsets) and pixel value related (rows, columns, bits allocated) stuff as binary (16 or 32 bit as appropriate),
"real world" things as ASCII numeric, even things things that could have been binary integers like counts of numbers of images, etc.

In ACR-NEMA, there was no indication of whether or not ASCII numeric values could be integers or decimal values or whether one or the other made sense. The authors of DICOM, in attempting to maintain some semblance of backward compatibility with ACR-NEMA and at the same time apply more precise constraints, re-defined all ACR-NEMA data elements of VR AN as either IS or DS, the former being the AN integer numbers (with new size constraints), and the latter being the AN fixed point and floating point numbers. In the process of categorizing the old data elements into either IS or DS, not only were the obvious integers (like counts of images and other things) made into integers, but it appears that also any "real world" attribute that in somebody's expert opinion did not need greater precision than a whole integer, was so constrained as well. If you look at the original 1993 Part 6 Data Dictionary, you will see a surprising number of these, not just the exposure-related data elements, but also other things like cine rates, R-R intervals, generator power, focal distance, velocities, depths of scan field, etc. It is hard to know what drove the decisions to constrain these, but perhaps it was related to the fact that many of the data elements were literal translations of what vendors already included in their own proprietary image file formats, and if some engineer in pre-historic times had allocated an integer rather than a fixed or floating point value for something, that arbitrary constraint founds its way into the standard without much further evaluation or consideration. Alternatively, the authors may have been of the common mindset that it was helpful to recipients to constrain the size, length of value range of data elements to the greatest extent possible, something that now seems counter-productive in a world of nearly unlimited bandwidth, storage capacity and computing power, but in the recent past could have been perceived as a significant performance benefit, even in an interchange standard.

Unfortunately, even though the DICOM standard introduced the concept of sending not only the value of a data element but also its type in the message, using the so-called "explicit value representation" transfer syntaxes, the new standard continued to support, and indeed require as the default, the "implicit value representation" that was equivalent to the way some vendors had implemented the ACR-NEMA standard over the network. Requiring only explicit VR would have allowed recipients to use the VR transmitted to decide what to do with the value, and opened the door to "fixing" incorrect VRs in the data dictionary. One could have required that recipients check and use the explicit VR. Unfortunately, by permitting implicit VR transfer syntaxes, the VR has to remain fixed forever, otherwise receivers have no way of knowing what to do with a value that is of an unexpected form. I am told that there was significant discussion of this issue with respect to the 1992 RSNA demonstration, and that implicit VR was allowed for the demonstration to maximize participation, with the intent that it not be included in the standard published in 1993, but there was not sufficient support to follow through with this improvement after all. In hindsight it is easy to criticize this short-sighted decision. On interchange media, added in 1995, only explicit VR transfer syntaxes are permitted, but by then it was too late.

So what does all this mean for our exposure-related attributes ? Given that one cannot reasonably change the VR of an existing data element, the only option was to add a new one. So this is what CP 77 did:

it described the problem with all three data elements
it described the historic lack of constrains in ACR-NEMA
it only fixed the problem for one of the data elements (Exposure (0018,1152)), without further explanation as to why only that one was addressed
it add a new data element, Exposure in μAs (0018,1153), to the data dictionary and added it as an optional attribute in the CR Image Module
it defined the new attribute to have a scaling factor 1,000 different than the original attribute, which was defined to be in mAs (as is normally displayed to the user)
it gave the new attribute a VR of IS

You might well ask

why CP 77 didn't just make the new data element a DS, keep the same units that were used previously and that are the normal units in which a user expects to see the value displayed ?
why not just call the data element something like Exposure (Decimal), or indeed use the same name and rename the old one to Exposure (Retired) or similar ?
why was the old attribute in the CR Image Module not simply retired or deprecated in some other way ?

I have no good answers to these questions, but unfortunately the CP 77 approach set a precedent for all subsequent changes of this type, which include the data elements listed in but not fixed by CP 77, which is perhaps why we have ended up with:

Exposure Time in μS (0018,8150), which is DS VR
Exposure in μAs (0018,1153), which is IS VR
X-Ray Tube Current in μA (0018,8151), which is DS VR

Thankfully, CP 187, which introduced the new data elements, did not repeat the same mistake of using an IS rather than DS VR, but did perpetuate the notion of adding a different scaling factor to disambiguate the new data element from the old. I have to take responsibility for this particular piece of stupidity, since I was doing the editing for the DX supplement and probably this CP also at the time. Surprisingly, and I can't remember why (probably an oversight on my part), though Exposure in μAs (0018,1153) got propagated into the CR and CT IODs, Exposure Time in μS (0018,8150) and X-Ray Tube Current in μA (0018,8151) did not, which often causes implementers reading PS 3.3 not to realize that these can be used to solve any precision problems for time and current as well as exposure. Another CP on this subject is probably in order.

There are several other problems than the VR and the scaling factor with this approach of fixing inappropriate VRs by adding optional attributes that mean the same thing as what they are intended to "replace", without actually retiring and removing the old attribute. Specifically:

How is a poor receiver to know which to use if it receives both (the sensible answer is to use the more precise one instead of the less precise one, but the standard does not require that) ?
What about an old receiver that has never heard of the new attribute (it will display the old less precise one) ?
Should a sender send both a less precise and a precise value, just to be able to allow such old receivers to display something rather than nothing (almost certainly yes) ?

If you think this is unfortunate, guess what, with the new Enhanced IODs we decided to make things even "better" by introducing yet more new attributes, this time with a more conventional scaling factor but an FD value representation. These are used in the Enhanced CT IOD, as well as the new Enhanced XA/XRF, 3D X-Ray and similar IODs:

Exposure Time in ms (0018,9328), which is FD VR
X-Ray Tube Current in mA (0018,9330), which is FD VR
Exposure in mAs (0018,9332), which is FD VR

Note that this is not nearly as bad as it sounds, because these new attributes only occurr nested inside the per-frame and shared functional group sequences, and hence will not occur in the "top level" dataset in a manner that might confuse receivers. Receivers of enhanced IOD images need to extract all their technique, positioning and other frame-specific annotation information from such sequences, and hence should always use the new attributes and never need to worry about encountering the old ones. These attributes are also mandatory attributes by the way, as is the convention with all of the Enhanced family of objects. The use of FD (or FL) rather than DS, by the way, has been the policy of WG 6 for some time now when introducing new non-integer numeric data elements, since the use of binary IEEE floats eliminates any ambiguity in encoding or parsing funky string values that are not described for DS, like infinity or NaN.

The problem with these new data elements is that now that they are in the data dictionary, some creative implementers of non-enhanced images have started to stuff them into the "old" IODs in order to send values with greater precision, instead of sending the intended CP 77 and CP 187 data elements. Strictly speaking this is legal as a so-called "Standard Extended SOP Class", but it creates an even greater problem for the receivers. When I first encountered someone doing this, I added a specific check to my dciodvfy validator to display an error if these attributes are present when they should not be in the DX IOD, and I have subsequently the check to other "old" IODs as well, including CR, XA/XRF and CT; I also implemented some limited consistency checking when multiple attributes for the same concept are present, since I encountered examples where completely different values were present that made no sense at all. As more and more modalities implement the Enhanced family of objects, however, and include the ability to "fall back" to sending the "old" objects if the SCP does not support the new ones, and do it by copying the "new" attributes from the functional group sequences into the top level datasets of old IOD objects rather than converting them to the "old" attributes, we may see more proliferation of a multitude of different data elements in which the exposure parameters might be encoded.

So back to the problem of what a poor receiver (of non-enhanced IOD) images is to do ? The bottom line in my opinion is that a modern receiver should check for the presence of any of the alternative attributes that encode the exposure parameters, and use whatever they find in order of greater precision. I implemented this rather crudely recently in the com.pixelmed.display.DemographicAndTechniqueAnnotations class in my PixelMed toolkit, if you are interested in taking a look at one approach to this; look for the use of the getOneOfThreeNumericAttributesOrNull() method.

If the foregoing sounds a little critical and sarcastic, it is intended to be. I continue to amaze myself with my own poor expedient decisions, lack of consistency and frequent carelessness when working on corrections and additions to the DICOM standard, and so this missive is intended to be as self-deprecating as it is critical of my contemporaries and predecessors. Much as we would like to change DICOM to make it "perfect", the need to correct problems and add functionality yet avoid breaking things that already work and avoid raising the implementation hurdle too high to be realistic are overriding; the result of compromise is significant "impurity".

If we ever had the chance to start DICOM all over again and "do it right", I am sure that despite our best intentions we would still manage to screw it up in equally egregious ways. We sometimes joke about doing a new standard called just "4", so-called because it would be the successor to DICOM 3.0, would not necessarily be just about images, and which would be an opportunity to skip the past the morass that is HL7 version 3. I doubt that we would really do much better and would no doubt encounter Fred Brooks' "second system syndrome". Indeed, DICOM 3.0 being the successor to ACR-NEMA already suffers in that respect, perhaps being accurately described as an "elephantine, feature-laden monstrosity". From what little I know about HL7 v3, it is not exempt either.

David

Basic CD viewer requirements; extending PDI; software for sending images on CD media

2008-11-16T06:31:00.000-08:00

Summary: IHE is defining requirements for basic CD viewers; PDI is being extended to add DVD, USB, compression and encryption; IHE PDI and DICOM CD media require viewers and importers to understand what is on the media; as compression, encryption and new types of images are used, receiving software struggles to keep up; this can be alleviated by executable software on the media that can decompress, decrypt and convert new image types to whatever has been negotiated with the recipient and then transmit them via the local DICOM network.

Long Version:

Since the cardiology community first began standardizing, promoting and adopting DICOM CDs as a means of interchange of images in the early 1990's, and radiology has rapidly caught up, CDs have proven to be wildly successful despite legitimate complaints about interoperability and ease of use. The PDI promotion effort by IHE initially focused on reducing confusion by insisting on only uncompressed images on CD, to reduce the burden on any device or software that the recipient may have installed. Dependence on on-board viewers was somewhat discouraged by IHE, both because of the potential security risk to executing externally supplied code and the variation in features that such viewers support.

As I have discussed previously, referring physicians who are the victims of a multitude of different viewers are "encouraging" us to improve the situation, both by endorsing the use of PDI as opposed to proprietary media, as well as joining with IHE to develop standards for what viewers are required to be able to do, in a manner that makes them intuitive to use. This latter effort is the Basic Image Review Profile. Last week we had our first Radiology Technical Committee meeting to discuss the requirements for this profile. The involvement of the users who are interested in this was extremely encouraging ... no fewer than three neurosurgeons attended the meeting to contribute! We discussed what features any basic viewer should have with respect to loading studies, navigating through them using thumbnails, comparing series side-by-side with synchronized scrolling, panning, zooming and windowing, making simple distance and angle measurements, displaying any if report present, and printing. We also discussed hardware and software requirements for such a viewer agreeing that it had to run on Windows (blech, but that's reality), and more controversially, to what extent elements of the user interface could be standardized in appearance to make unfamiliar viewers intuitively easy to use. Tooltips are one obvious means to assist with ease of use, but we also agreed to at least attempt to define what tools should be visible in the main interface and what they should look like (e.g., hand for pan, magnifying glass for zoom, etc.). We know there is a balance between consistency across vendors and the added value of proprietary look and feel, but hope that some consensus can be achieved on general principles. One item that everyone seems agreed on is the concept that the "basic" interface should be uncluttered, and "advanced" features should not be visible until they are called for, so the profile may well end up specifying what shall not be there in addition to what shall.

In the same meeting we also discussed extensions to PDI. For some time many applications have been limited by the size of datasets relative to the capacity and speed of uncompressed CD media. Accordingly, after our informal interoperability tests of DVD readability earlier this year at the Connectathon, the idea of extending PDI to support DVD as well as CD has been accepted, and at the same time it makes sense to add support for compression (as DICOM requires for DVD support) as well as for faster media like USB memory sticks and the like. The fuss about encryption of portable media makes this an opportune time to deal with that issue as well, to make sure that there is not a proliferation of proprietary alternatives to the DICOM secure media standard.

Yet extending PDI raises the bar for recipients that want to use their own pre-installed software or devices to display or to import media that may be compressed or encrypted in a manner that older software does not support. At the same time, we are well aware that any media may contain a multitude of different types of images, presentation states, key object selection and structured report documents, and IHE does not constrain this. What this means in practice is that though a viewer or importer (such as a PACS) may well support most of the image types, there may be content that is not successfully displayed or imported, the consequences of which may be unfortunate. The Basic Image Review Profile will address this for on-board viewers by adopting the fundamental principle that a compliant viewer on the media shall be able to view all the DICOM content on the media. That is a "no-brainer", but it doesn't help the pre-installed viewer or importer.

A solution that I have proposed for this that may help is to introduce the concept of "sending software" on the media. That is, even if one does not want to view the content on the media using an on-board viewer, which may or may not be present, easy to use, or even possible to execute on your hardware, it may be possible to execute software that helps to import the content into your own locally installed software. The requirements that I have drafted so far for the PDI extensions supplement include the ability to:

allow the user to enter the recipients network location (IP, port, AET)
read all the content of the media via the DICOMDIR
select what to send
coerce patient & study identifiers using local values supplied by the user
decrypt content if encrypted using the password supplied by the user
decompress content if the receiving devices doesn't support compression
convert instances whose SOP classes the receiver does not support to one that it does
transfer everything

The idea started out as a means to get around the fact that most of the installed base does not support encryption, or some of the more advanced compression schemes, but in fleshing this out it seemed reasonable to also address the fact that more recent SOP Classes like Digital X-Ray and Enhanced CT or MR are still not widely supported, and the same "fall back" strategy of converting SOP Classes that modalities use to deal with primitive PACS in this regard could be used on media too. A typical DX modality may, for instance, attempt to send a DX object that the PACS doesn't support, and can fall back to sending CR or even Secondary Capture instead if that is all that can be negotiated on the network; modern MR devices that support Enhanced MR do something similar. The key to this is the DICOM Association Negotiation mechanism that allows this to be figured out on the fly, rather than being pre-configured.

Ideally, the "sending software" present on the media would be multi-platform, and it is certainly possible to do that (say with Java and on-board JRE's for the popular platforms in case they are not already installed). But at the bare minimum, given the prevalence of Windows, the requirements are that it executes:

from the media without installation
on desktop Windows operating systems (XP or later)
without requiring the presence of or installation of supporting frameworks (e.g., .NET or JRE), other than to be able to execute them from the media if required
without requiring administrative privileges

Obviously, the requirements for "sending software" could be satisfied by an on-board viewer that had such functionality embedded within it, and in many cases that may be simpler than adding separate standalone software. That said, very few viewers supplied by commercial producers of CDs at least, include any kind of networking capability, at least not yet.

A potential problem is the need for the user to supply network parameters for the recipient (in the absence of self-discovery support, something not very widespread, unfortunately), and at the other end for the receiving PACS or workstation to be willing to accept inbound objects from a strange source (some are "promiscuous" in this respect, others are not). In the case where the media sending software is executed on the same machine as the "workstation" (or pre-installed viewer) into which the images are going to be imported, this should be less of a problem. Indeed defaulting to sending to port 104 or 11112 on the localhost with a pre-defined AET might well work for this and we could consider defining that in the IHE PDI profile option.

Anyway, though obviously the "sending software" option is not something ordinary users such as referring physicians will want to have to deal with, since their pre-installed or on-board Basic Image Review Profile viewer should cope most of the time, it provides a means of "last resort", if you will, for support personal to extract content from media that for some reason is unreadable locally through normal means. It also provides a means of helping the enterprise-to-enterprise interchange use-case, when the receiving PACS does not supported the more modern DICOM objects that advanced modalities produce, more modern compression techniques such as JPEG 2000, or the encryption that is being mandated by some jurisdictions specifically for this use-case.

David

UK Encryption Update

2008-11-07T05:47:00.000-08:00

Summary: Encryption is not required for CDs given to patients in the UK

Long Version:

In the discussion on AuntMinnie on this subject, Brandon Bertolli from London provided an update of the UK situation that clarifies when encryption is expected to be used, or not used. Specifically, a note in a letter from NHS Chief Executive David Nicholson to the president of the British Orthopaedic Association, dated 29 October 2008, includes a important statements:

"Patients can continue to be given their own images on CD to carry away with them ... provided that the CDs are given directly to the patient, they are made aware of the risks and they take responsibility for their safekeeping, there is no fundamental problem if these are not encrypted."
"If ... a CD needs to be used, which is possibly the case if the X-Ray is taken in a non acute setting ... then it should be encrypted ... alternatively it can be given to the patient and therefore encryption would not be necessary."

For those of us involved in teaching and research, there is another very important clarification:

"Naturally images will need to continue to be used for teaching, and the system for protecting data on CDs should not prevent entirely legitimate teaching activities ... if the teaching is outside the clinical environment then as long as the data on the CD contains no patient identifiable information then there is no need for it to be encrypted."

These are very important and sensible clarifications, which should ease the concerns that some folks have had about the potential negative impact of privacy protection in the UK on safety and convenience, and the practicality of long term accessibility of password based encrypted media.

It seems very clear that the NHS is taking action primarily for transfers between organizations and between providers, which is as it should be. But the need for encryption can still not be dismissed lightly and is described in the letter as "good practice" even for CDs for patients. So we do need to make sure that we promote the appropriate standards for media creation vendors to implement so as to avoid the NHS or anybody else needing to adopt proprietary schemes for such transfers.

But the sky over Britain's CD users is not falling after all.

David

PS. Here is the scanned in text of the letter and the accompanying note (with thanks to Miss. Clare Marx who kindly provided a copy of the entire letter):

CD Encryption Revisited - UK Leads the Charge

2008-11-05T05:30:00.000-08:00

Summary: UK NHS demands encryption of image CDs; should we use device or file-based encryption, standard or proprietary, password or public-key based ?

Long Version:

In a previous post I talked about Media Security and Encrypted DICOM CDs, and this topic has also come up on Aunt Minnie. Whilst there has been a general concern that the threat to privacy is small and the risk to usability high, it seems that in the UK at least, this discussion has been pre-empted by a decision by the NHS to require encryption, outlined in a letter from the NHS Chief Executive, David Nicholson. I quote from this letter:

"You are aware that there is a mandatory requirement that all removable data, including laptops, CDs, USB Pens etc must be encrypted."
"The encryption mandate applies equally to PACS images whether on CD or back-up tapes."
"There could be occasional exceptions on patient safety grounds ..."
"The CD and the password MUST be transferred by different routes."

Note that the NHS is not mandating any particular encryption scheme, though they have procured a proprietary piece of software from MacAffee (SafeBoot, now EndPoint) for this purpose. It is unfortunate that the NHS has not chosen to promote a standard interoperable and vendor-neutral solution, but perhaps that is because they have not been able to find one, or at least find one that is widely adopted or adopted at all.

Regardless, it would seem that the writing is on the wall for encryption of DICOM media, and solutions will need to be provided, even though the inconvenience and risk to patient safety will likely be significant. Accordingly, we have been considering a number of strategies to address this need, specifically, the encryption of an entire set of files (or an entire device), such as the open-source cross-platform TrueCrypt approach, or the encryption of individual files, such as by using the Cryptographic Message Syntax (CMS) that was designed for secure email (S/MIME) and which is already included in the DICOM standard for secure media. Further, one needs to make a choice between a password-based mechanism (so-called Password Based Encryption (PBE)), or a scheme that depends on the use of public keys and certificates and so forth, dependent on there being a Public Key Infrastructure (PKI) for senders and recipients.

The primary advantage of encrypting the entire file set or device would seem to be that one could do that, then present the encrypted set as if it were an ordinary filesystem, and the effect would be completely transparent to applications like DICOM viewers and PACS importers, once the decryption had been activated by the user entering a password or the appropriate private key being matched. Unfortunately, great as this sounds, it turns out that one needs to install some software into the operating system (like a device driver) to actually make this happen, and this requires administrative privileges. Either recipients need to have software pre-installed on their machine by someone appropriately authorized, or they need to have the right to do this themselves, for example when auto-running such a tool from the media itself. The latter is indeed supported by TrueCrypt, for example, but how likely is it that the average doctor receiving media will have such privileges, and how safe would it be (in terms of the risk of viruses) to allow them to do so ? This may be a showstopper for what otherwise seems on the face of it like the most expedient solution. There is also the matter that TrueCrypt is not a standard per se, nor is it included in other standards like DICOM, but the latter could easily be rectified since the format is fully documented and free from intellectual property restrictions.

By contrast, what seems like a more complex approach, inclusion of support for encryption directly into the DICOM viewing or importing software, may actually be a more effective solution, since it requires no additional permissions or privileges on the part of the user. Since often a viewer is supplied on the media anyway, that viewer can support the encryption mechanism used for the files. As long as the encryption scheme is a standard one, then other software can also view or import the media, if that other software also supports the standard scheme. In the interim, whilst other viewers and importers are being "upgraded" to support encryption, one could add to the on-board viewer the capability to not only decrypt and view the files, but also to send the decrypted images over a DICOM network to a PACS or workstation (preferrably allowing editing of the Patient ID field to allow for reconciliation of different sites identifiers in the process).

As mentioned, DICOM already defines the use of CMS for this purpose for secure media, though to my knowledge this feature has never been implemented in a commercial product. Further, in anticipation of this need we have been working on adding a standard password-based mechanism to augment the public-key approach used in the existing standard, specifically in DICOM CP 895, so that now we have the option of using either PBE or a PKI as the situation warrants. There are free and open-source encryption libraries that have support for CMS as well as the underlying encryption schemes like AES, for example the excellent Bouncy Castle libraries, and I and others have begun work on testing this concept using these libraries. Indeed, you can download from here a small test dataset that I created encrypted using the DICOM Secure Media profile using the CP 895 mechanism.

Regardless of which technical approach prevails, in all likelihood the simpler password-based mechanisms will likely be deployed, if only because of the complete lack of an existing PKI in most health care environments. Obviously, the privacy protection from encryption is only as good as the password chosen. Though security folks talk about long and complex passwords and phrases to improve protection, one does have to wonder how in reality imaging centers will choose passwords, and to what extent they will be based on well-known information that is memorable and predictable to simplify use, balanced against the relatively low perceived likelihood and consequences of a security breach. Further, there has yet to be discussion on good security practices and procedures for exchanging the media and the passwords separately, and what the recipient should do in this regard. For example, should the password be included in the printed report that is faxed or email to the intended recipient ? Should the patient have a copy of this for their long term use ? I would certainly expect so, but inevitably the patient sill store the report with the CD, which rather defeats the point !

None of these mechanisms address the concern that if a password is lost or not transmitted or the recipient cannot for some reason run the on-board viewer, then the patient's safety and convenience are potential at risk. In a network-based scenario, emergency access can be granted on demand, perhaps simply recording an auditable event that such emergency access by an authenticated but otherwise unauthorized individual was granted. With physical media, the sender and recipient are decoupled, however; indeed the recipient may not even be known a priori, such as when a patient takes their images for a second opinion, or for use as priors at a subsequent event. In such cases, loss or lack of access to the password becomes problematic. The problem is exacerbated in regions where it is not traditional for the imaging facility to provide long-term archival of images, such as Australia. One could imaging a scenario in which a woman has her screening mammogram recorded on an encrypted CD, the radiology center does not archive the images, and next year they cannot be used as priors because she has forgotten or lost the password.

Conceivably one could use a more complex form of encryption that allowed for escrow of additional keys that would allow recovery from some central authority perhaps, but such escrow schemes have been widely unpopular in the security community for many reasons. In the absence of an infrastructure to support this, all CDs could include the use of an additional key that was "well known" to some central authority, but of course eventually someone might be able to compromise such a key (consider the DVD Content Scramble System (CSS), for example).

So, though we do not yet have broad consensus on the standard mechanism that the industry should adopt, globally and not just in the UK, we are making some progress. Next week we will be meeting as the IHE Radiology Technical Committee and encryption is one of the topics for discussion for this year's extensions to PDI. The agenda is here, if perhaps you are interested in attending.

Though improving interoperability and reducing the barriers to viewing images on media has always been our primary goal, and encryption has the potential to threaten that objective, hopefully we will have a clear technical direction shortly for those folks who may no longer have the option of avoiding media encryption.

David

A little PACS history

2008-10-04T05:15:00.000-07:00

There has been a lot of discussion lately about certain PACS features and how long the ideas have been known to the community.

A good "snapshot" of features is available in the military specification for the MDIS (Medical Diagnostic Image Support) system, what later became the Siemens Gammasonics, Lockheed Martin, Loral and finally GE PACS - the precursor of the first "Centricity PACS". You can find a link to a scanned, OCR'd copy of the MDIS RFP here. This document is dated 28 March 1990.

If one turns, for example, to the Soft Copy Image Display (SCID) requirements in section 4.4, one will see such features as have been taken for granted since the early days of PACS and are now ubiquitous:

4.4.3.2. Pictorial Patient Directory. The workstation shall display the images from a patient's master "folder" and individual image subfolders (e.g., chest, bone, GI). Anatomic region subcategories shall be possible within each subfolder (e.g., elbow, ankle). Single or multiple images shall be easily selectable for full resolution viewing.
4.4.3.3. Worklist. The workstation shall automatically generate a worklist of unread exams to enable each radiologist to review the amount of the work ready for their review. The worklist can be created by radiologist or type of workstation (e.g. CT review workstation) at each as determined at each site.
4.4.3.4. Image Rearrangement and Display. The workstation shall display multiple reduced resolution images on a selected monitor with the ability to easily rearrange these images on the same monitor. It shall also allow rearrangement of the images easily from monitor to monitor on the same workstation.
4.4.3.5. Image Paging. Quick paging through multiple user selected images of an exam displayed on a single monitor shall be provided.
4.4.3.6. Default Display Protocol. This required function displays the images of a patient study in a user-selectable default protocol, activated each time the individual user logs on the workstation. The default display shall be modality and body part specific. It shall be a site-specific requirement- i.e. each MDIS site shall be capable of setting their own parameters.
(For example - a patient has new and previous posterioranterior (PA) and lateral chest studies to be interpreted. The radiologist viewing the study prefers to view the PA images on the central two monitors and the lateral images on theouter two monitors of a four monitor workstation. The radiologist also prefers to view the lateral images with the anterior border of the chest closest to the left monitor edge, the new PA images on the right central monitor, and the previous PA image on the left central monitor.)
Additionally, the images shall automatically be presented in an upright as well as correct right/left orientation.
4.4.3.7. Image Enhancements Defaults. The workstation shall include user selectable image enhancement defaults for grayscale window and leveling, variable edge enhancement, and inverse video, activated each time the individual user logs on the workstation.

This document is well worth a read for those who are students of PACS history, but also for those who are seeking to establish the state of knowledge and understanding of PACS concepts in the late 1980's (the document is from the beginning of 1990, and presumably there were earlier drafts well before that describing the same concepts).

I am not sure exactly who the authors of this document were, or I would give them credit here, but I intend to research that a little further amongst some of my older colleagues (:)). Indeed, I think I will begin a little "PACS History" section in my FAQ, and start to accumulate links to documents that describe the early days, or at least references to papers and conference proceedings where the copyright is held by some publisher. Anyone who wants to contribute links or documents, please feel free to email me.

PS. I have to say that I am most impressed by Acrobat 9 Mac's OCR capabilities, which I rarely use. The original scanned paper PDF of the hand-typed MDIS RFP document that I submitted for OCR, primarily to index it for searching, also allows me to cut and past the above paragraphs with only a few edits for punctuation and without a single meaningul error; most impressive.

Is the winter of discontent with CDs finally upon us ?

2008-08-28T06:25:00.000-07:00

It is not news that I have been whining about systems that produce non-DICOM and non-PDI compliant CDs for a long time now. Yet some folks continue to believe that it is acceptable for vendors and sites to create proprietary CDs with proprietary viewers on board, despite the fact that these offer no advantage over standard CDs. I am often criticized for harping on this subject to the exclusion of all others (most recently in response to a comment on Sam's blog), but I make no apologies about it, since I believe it is indeed the primary interoperability issue facing the digital imaging community at the present time.

Well, those of us who have been focusing on the radiology-centric aspects of this mess have now been joined in battle by the community of physicians out there in the real world who have been struggling to deal with this nonsense.

The American Medical Association, as a consequence of complaints initiated by the American Association of Neurological Surgeons with respect to viewing MRIs, has produced a report from their board of trustees that resulted in a resolution with respect to "Development of Standards for MRI Equipment and Interpretation to Improve Patient Safety". Note that the discontent being expressed by the AMA is not confined to neurosurgeons, but involves everyone who receives CDs. Further, the emphasis is on safety, specifically, if media is unreadable or unusable or takes to long to use, then the safety of the patient may be at risk. This activity has been going on for several years, though few people outside of the groups involved have been aware of it.

Yesterday, I attended an interesting meeting in DC at the AMA office, which involved many of the stakeholders mentioned in the resolution, including vendor representatives from MITA (NEMA) as well as the ACR. Those referring physicians present made it abundantly clear that swift, dramatic and effective action by industry and by radiology facilities is expected without delay, and that delay will result in engagement of the regulators and the legislators.

During the course of that meeting we came to the consensus that emphasis would be placed on establishing that the standard of care will be compliance with the IHE PDI specification, and in the absence of any explicit enforcement mechanism, promulgating this as an AMA principle may suffice. Woe betide anyone who then expects to get paid for producing non-compliant CDs (since payers might not pay for less than the standard of care when they become aware of the issue), or who expects to prevail in the civil courts in the event of a negligence action caused by an unfortunate outcome from inability to read a CD.

The other outcome of the meeting was acceptance of the goal of defining a set of minimal functional requirements for a "simple viewer" that would set the lower bounds on what such a viewer would do (and to some extent, how it would do it). An IHE effort, with evaluation of compliance performed by users (not radiologists or engineers) was proposed as the mechanism to implement this.

There was debate, but not consensus, about actually standardizing aspects of the user interface, including what icons should be used and what they should look like. Though this may seem impractical, given the installed base and the investment by each vendor in their own look and feel, the matter arises because physicians faced with a completely unknown and unexpected interface have great difficulty figuring out how to make a viewer perform even basic tasks. This problem needs to be solved somehow.

Regardless, the writing is on the wall for proprietary media, and vendors who create it, or permit their users to create it, and sites that provide it. Let them all be "in the deep bosom of the ocean buried".

David

Media Security and Encrypted DICOM CDs

2008-04-29T04:13:00.000-07:00

Summary: CDs of images are vulnerable; encryption is possible and new DICOM mechanisms could make it easier; does the threat really justify the inconvenience and cost?

Long Version.

Recently there has been increasing interest in providing some sort of secure DICOM CD so that at least not just anybody can read the contents of such a CD that is lost or stolen. An Aunt Minnie post exemplifies the concern.

DICOM does provide mechanisms to encrypt the CD (using the same tools as are used for S/MIME secure email), but they are rarely, if ever, used in practice.

I am not sure whether this is because a) most people don't care about security or b) reading CDs is hard enough without adding an extra barrier or c) the mechanisms in DICOM are too complicated to deploy.

It is easy enough to extend DICOM to support security mechanisms that are "easier" to deploy and don't require a priori knowledge of every recipient and the use of certificates and a public key infrastructure, such as a password-based encryption mechanism, and I have put in a CP to do so (adding RFC 3211 PKCS#5-based PBE for the KEK to CMS, for those who care), but ...

... my real question is, would anybody want to use it ?

Deployment would require sending a "password" "separately" from the CD (e.g., in an email), and probably keeping track of these in order to answer calls from recipients who have lost or forgotten it, days, weeks or years later. There is no question that this would also make importing of old studies from old CDs as priors more likely to fail.

I don't think the industry will be able to resist demands to provide such capabilities from those with serious (if not excessive) privacy zeal, but is the cure worse than the disease in terms of the cost and complication it will trigger ?

If we are going to have to do this, obviously using a standard DICOM mechanism is preferable to any proprietary scheme, to support 3rd party viewers and PACS importation; however, such devices would have to be upgraded to support the DICOM media security profile. In the interim an on-media viewer that supported the DICOM encryption scheme would at least make the images viewable, though there are many reasons why on-board viewers are undesirable that don't need to be reiterated here.

With modern processors, the speed of encryption/decryption should not be a rate limiting step compared to reading the physical media, although with media that is faster than CD or DVD, such as USB memory sticks, there might be some compromises with respect to number of iterations and key length to consider.

David

Requirements for an "office imaging system" for requesting practitioners

2008-04-02T04:05:00.000-07:00

Summary: Film is dying but requesting doctors hate loading slow and unpredictable CDs; they need pre-loaded images on a system in their office; specific requirements for such systems are defined; there is no need for them to be expensive or complex.

Long Version.

Doctors, much like everyone else on the planet, crave instant gratification. If it takes more than a negligible amount of time to gather information in the context of seeing a patient, they either won't bother or will become irritated. And after all, even in a salaried setting, time is (somebody's) money.

In the pre-digital days, it often took more time than it was worth to bother to extract and hang films properly, or even find a real view box, hence the frequent sight of films held up to the nearest window or fluorescent light, hardly optimal viewing conditions. Radiologists, with a more pressing need to view the films "properly" and in bulk, addressed the film handling problem with pre-loaded panel viewers on which trained but relatively low cost staff "hung" the films in advance. Some radiologists rarely lifted their foot off the pedal as the films scrolled mechanically by whilst they dictated rapidly.

During the transition to soft-copy interpretation of digitally acquired images, the importance of effective work lists and hanging protocols to efficiently report increasingly complicated large studies has been obvious to radiologists. Such features are a vital component of any modern PACS. In an inpatient setting, or an ambulatory clinic attached to a large facility that does its own image acquisition, an enterprise-wide PACS can (in theory) provide ready access to images when and where they are needed, in an appropriate presentation, whether it be in the examination room in the clinic, in the operating theatre, or somewhere convenient during ward rounds. Where appropriate, dedicated staff are deployed to optimize the performance of the process when it cannot be totally automated.

Yet in a traditional ambulatory environment, in which radiology facilities and requesting practitioners office are geographically and organizationally separated, as films disappear and imaging centers insist on handing out CDs to outpatients instead, there is a growing problem.

For the busy doctor, CDs suck; there is just no question about it. They are relatively slow to load, regardless of how fast the drive is, they usually have some awful viewer that one is not familiar with and which takes a while to start (making the process even slower) or fails to work. Once started, there is usually no clue which images are important out of the hundreds or thousands present. Even though these CDs are increasingly standard DICOM and IHE PDI compliant as the vendors finally get their act together (with a few notable and reprehensible exceptions), and there is talk of faster, higher capacity media (DVD and even USB memory sticks), that doesn't get around the fundamental problem that handling and loading physical media "on demand" is inherently troublesome.

The key issue is the handling and loading of the media. The obvious solution is to pre-load it.

When a patient is referred to a large facility with a PACS, whether it be for a specialist consultation or further imaging, typically any "prior" films and CDs will be requested in advance, and these will be pre-loaded into the PACS, so that they are available for review and comparison using the normal tools and work flow. Any necessary "import reconciliation" of foreign patient identifiers will be performed, etc.

Clearly, a scaled down version of this process would be feasible in a small office, even for a solo practitioner. Patients do not walk directly off the street into the examining room. There is always some sort of reception facility. At that time, a clerk could take the media and "import" it into a system of some sort. This would require no technical expertise, and the media would either load successfully (if it were DICOM and IHE PDI) or not (if it were proprietary Philips/Stentor or Amicas rubbish). Loading an entire CD should take no more than a matter of a few minutes. If the receptionist was really busy, then a dedicated staff person might be necessary. Media that failed to load would be dealt with by clerical staff interacting with the offending imaging center, which argues for having the media sent in advance of the patient's visit if at all possible.

Reconciliation of identifiers could be performed automatically (if the imaging center's numbering scheme was recognized), or semi-automatically (by patient name matching confirmed by the clerk), or manually (by typing in or selecting from a list of scheduled patients) as required.

Perhaps the report (quite likely not on the CD, and perhaps faxed separately), would also be scanned into the system, or be available in whatever electronic document handling system the practice used, or perhaps just be present in the paper chart in the old fashioned way.

The images would now live on a fast central server in the office, and be available anywhere the necessary display hardware and software was located. Prior images might or might not also be archived on the system, but the primary goal here is to describe how to make images available, not address questions of whether or not and how the requesting practitioner should archive them.

Ideally, every exam room would be equipped with an appropriate display, perhaps just a reasonable sized color LCD, unless the specialist practice was of a type that demanded a high intensity calibrated grayscale display. As is standard security practice, the display would need to be blanked and locked unless the doctor was in the room and then only the appropriate patient's images would be visible. For example, the doctor could apply their finger to a biometric keypad to activate the system, which would then display nothing until the patient's ID from the paper chart was read with a bar-code wand, at which time the images would instantly appear, preferably jumping directly to the key images if they had been flagged as such on the CD in the first place (using the standard DICOM objects for this purpose). One could imagine ways to use RFID tags creatively to make this almost totally automatic, with the presence of both the patient and the doctors RFID tags in the room activating the display automatically.

The doctor would already be familiar with the "viewer" since it would not be the one on the CD but rather whatever was installed on the system and on which they were trained. It would have the necessary features that they had chosen (such as orthopedic templates or 3D cardiac visualization or whatever, depending on their specialty).

Exactly the same strategy can be applied in the operating theatre, whether it be in an inpatient setting in the absence of an enterprise PACS, or for outpatient surgery. Images should be preloaded and made available in the OR to which the patient is assigned or in which they are currently located. The physical type, mounting and interaction with displays is more complex, but these issues are not specific to this discussion.

How hard or expensive would all this be ? It is pretty straightforward really , when one considers the simple work flow and similarity to existing systems. The use of off-the-shelf consumer computer, display, network, biometric and bar-code hardware and software could make this very low cost. There are obviously already free and open source tools to implement this if one is technically sophisticated, and there are no doubt already commercial systems that are designed for this purpose or which could be re-purposed easily enough. One could clearly add potentially expensive bells and whistles like integrating with practice management systems, room scheduling systems, electronic medical record systems and the like, as desired.

In future, as Internet transfer of images directly from the imaging center to the recipient's system becomes commonplace, this mechanism could replace CDs as the transport media. Still though, the images should be ready to view on the local system, and there should be no need for the physician to wait to load them on demand from some off-site local over a relatively slow connection, or be forced to learn how to use whatever web-deployed client that particular imaging center used.

To repeat the key message, regardless of the transport mechanism, the requesting practitioner should have the images pre-loaded on their own system and accessible to them at the point of care instantaneously and using their own preferred tools.

The bottom line is that there are few excuses for whining about "slow" media or problematic viewers, when a small investment in each user's office could produce a near optimal solution.

David

An impending reality - the Patient Contributed Image Repository

2007-11-18T09:04:00.000-08:00

Summary: A test site for the PCIR is now up and running, allowing contribution and downloading; feedback is sought on the idea, the contribution process, the contribution agreement, and the site design itself. Go to "http://www.pcir.org/".

Long Version.

As you may recall from an earlier blog entry, I have been exploring the feasibility of a repository to which members of the general public could contribute their own digital medical images. Rather than wait for some grand scheme involving multiple protagonists and sources of funding to come together, I thought that it might be easier just to "build it" in the hope that "they will come". The "they", in this case, being patients willing to contribute their data.

By leveraging some very simple tools, existing relatively cheap web and data hosting services and my own time and funds, this turned out to be relatively straightforward, at least for the initial pilot.

If you wish to take a look at the test site that I have created, go to "http://www.pcir.org/". Send any comments you have back to me at "mailto:dclunie@dclunie.com".

The principles behind this site are straightforward, if perhaps somewhat naive:

that patients have an interest in promoting the common good;
that they can be convinced that contributing their own images to the public domain is for the common good;
that if only a modest level of effort is required they would be willing to do so;
that patients have sufficient basic computer skills, equipment and fast enough connections to do so;
that patients will be satisfied that their privacy will be protected;
that providing unrestricted downloading will disseminate the images to the most users;
most important of all, that the images will actually be useful.

As I said in the introduction, the currently deployed site is a test site, and this is the pilot phase of the project. Success criteria for the pilot include confirmation that:

there is sufficient interest in the concept to justify proceeding
the ease of use is within range of the target audience of non-medical, non-IT patient contributors
the level of effort to obtain images +/- accompanying information is feasible
the type of images and information collected will be of sufficient use
the concept of anonymous contribution to the public domain stands up to legal and ethical scrutiny

The next steps, if the pilot is successful, are to:

form the non-profit corporation to manage the effort,
have the "contribution agreement" tidied up by the lawyers,
start soliciting contributions of images and funds from the general public, and
engage the advocacy organizations in promoting and supporting the effort.

If you have any interest in assisting with any aspect of this, please contact me directly. All features of the site are accessible from the PCIR home page.

Approach.

The basic approach is that:

patients agree to contribute their own images and documents TO THE PUBLIC DOMAIN
the PCIR receives and de-identifies their images and documents
the PCIR distributes the de-identified set to ANYONE WITHOUT RESTRICTION

Or, to put this another way, there is no "consent" to particular uses, and there are no "data use agreements".

The definition of "public domain" is somewhat nebulous in this context; it is well-defined with respect to "creative works" like art and music and literature (and even computer software), but it is unlikely that medical images are creative works. The term is also used in the context of patents and land. Perhaps there can be no formal definition of "public domain" with respect to medical images, or medical records in general, until the term is used in a legislative or common law context to apply to such things, or until it is declared that they should be treated as if they were creative works and subject to copyright (not that I am advocating the latter). Regardless, for the PCIR's purposes, the analogy to creative works may suffice to convey the intent of both the contributor and the PCIR in this regard.

Do patients' even have the right to contribute their own images ? For that matter who actually owns them ? Certainly in the US, the HIPAA Privacy Rule has clarified that patients have a right to a copy of their medical record, regardless of who owns the "original". This seems to be a general principle that spans international boundaries, including in Europe, where the Privacy Directive specifically addresses access rights in general, not just to medical records. We assume that medical images are to all practical intents and purposes also medical records; though some medical records departments in hospitals may deny this, that seems to be because they do not store them (nor have a responsibility to), the radiology department does. The PCIR agreement in its current draft proposes that contributors do have such a right and are agreeing that they are not constrained in any manner from exercising it. This seems to be a reasonable strategy until somebody argues otherwise.

Implementation.

You may also be interested in some of the details of how this test site currently works.

To make tractable maintenance of the informative web pages, I use Apache Forrest. This tool, as discussed in a previous blog entry, allows one to construct the source form of the text and organization and external links in a simple XML format, and then to "build" the site using an appropriate "skin" to generate the look and feel. I can't really say enough good things about Forrest. I dare say many folks have commercial web site design tools that are more sophisticated and produce a more visually appealing result, but for the humble novice like myself who is more comfortable at the command line with a plain text editor, Forrest gets the job done.

The uploading tool when the patient decides to make a contribution is a Java Applet. This approach was chosen because a platform-neutral approach is a basic requirement; I dare say something Microsoft Windows specific would cover the majority of potential contributors, but I do not want to exclude anyone if possible. Using Java applets requires that the contributor's browser be both capable of and enabled to allow these to work. The invocation of the applet is through an HTML page that will prompt the user's browser, or the user themselves if necessary, to install a sufficiently recent version of Java to work. The lowest level of JRE that will work is SE5 (1.5), due to the need for support of various encryption features used by the applet.

The applet also requires access to resources on the local machine, both in order to read files and CDs to be uploaded, as well as to be able to transfer these over the network to the PCIR. This requires a signed applet, and for the user to agree to "trust" the applet. It seems to have become relatively commonplace nowadays for users to routinely click on "yes I trust you", pretty much regardless of the source of the applet.

It is possible to use a "self-signed certificate" to sign a Java applet and allow it to work, as long as the user does not mind seeing a message that the "digital signature has not been verified"; if one goes to the trouble of obtaining a legitimate code signing certificate from a certifying authority that is installed in the JRE, then the user instead sees a message that the "digital signature has been verified". The difference, frankly, is a little subtle. For the purposes of the test site, the applet used has been signed by PixelMed's verifiable certificate from Comodo.

[As an aside, getting such a code signing certificate is actually reasonably cheap and not too difficult; being inherently cheap, I searched long and hard using Google to find the lowest cost provider. Verisign charges a fortune for these; Thawte is not much cheaper. Comodo themselves have a relatively high price on their own site, but their reselling partners are generally much cheaper. I ended up using KSoftware; their price is right ($USD 85 for one year), and though their web site sucks, and causes all sorts of browser error messages, and will not accept credit card numbers until you give up and use their PayPal payment method, eventually you get to the Comodo site and things go smoothly from there. Since PixelMed is a legitimate business entity already, I had no trouble providing the appropriate credentials (in this case a bank statement by fax) and got the certificate almost immediately. I was also worried about getting just a Microsoft Authenticode certificate, which is all Comodo offer, since I had read all sorts of early posts about how to convert the various certificate forms from one to another and into something that the Java jarsigner can use. I need not have worried; since I was using Firefox (on a Mac as it happens), when I picked up my certificate it got automatically saved in the browser's collection of certificates. All I needed to do was then "export" it (to a PKCS12 file, as it happens), specifying a password for that exported file that I would need every time I signed with it; it worked fine with jarsigner, by specifying the exported file as the "-keystore" command line option, and using the "-storetype pkcs12" option, though I am not sure if that is strictly necessary). The CAcert Wiki was somewhat helpful in figuring out some of this.]

How does the applet manifest itself to the user ? Well, when the user navigates to the page, it checks to see if they have agreed to the contribution agreement, if not it asks them to do so, then displays the applet in the page. The user can:

specify a reason for the exam that they are going to upload,
upload an entire CD (e.g., of DICOM images), or
upload selected image files (e.g., of scanned documents like reports)

Once they have chosen an upload option, a file dialog appears to allow them to choose what to upload, and then packaging, compression, encryption and transfer begins immediately. When the process is complete, they can upload more if they like.

You can try this out yourself by going to the PCIR upload page, and uploading your own images; please be sure that you really do agree to contribute these to the public domain if you do so.

What is happening behind the scenes is that:

on starting the applet, any existing session information (stored in local preferences) is checked, so as not to keep asking the user to re-agree
if it is a new session, then the agreement itself is downloaded from the web site (in order to keep the web site version and the applet displayed version in concordance) and rendered in a dialog box to the user; they must agree to in order to proceed
when "enter reason" is clicked, a pop-up dialog is opened with buttons that have automatically generated tear off menus attached to them - these menus allow the user to choose from a pre-defined hierarchy (by category or by alphabetical nesting) of reasons for imaging exams (more about this later)
when upload disk or files is selected, a file chooser dialog appears; the reason for the separate buttons are two-fold; firstly, that the default directory is different (e.g., to the "My Computer" directory on Windows for CDs, or the "My Documents" folder on Windows for files); secondly, there is a well-known Java bug related to not being able to select entire drives under Windows
once the user has selected a CD or a set of files, these are packaged into a zip file, compressed whilst doing so, and encrypted using an AES symmetric cipher
the packaged, compressed and encrypted files are then transferred to the PCIR server, together with an RSA encrypted copy of the symmetric key encrypted with the current PCIR uploading public key, as well as an encrypted copy of the contribution agreement; the received files are not accessible for downloading

Note that the files chosen by the user never leave their computer in an encrypted form, satisfying is a primary requirement of the upload process to protect the contributors privacy, which is of course of paramount concern.

Once uploaded, the files enter a manually supervised de-identification process and all images and documents are both mechanically and visually checked for leakage of identifiable information, which is then removed. This includes:

editing of the pixel data to remove burned in identification
removal of all text strings that contain identifying information
checking and removal of either all private attributes, or those that are unsafe

Dates and times are normalized to an epoch, and longitudinal contributions (exams for the same patient on different dates) maintain their relative temporal interval. Some effort is applied to detecting separate contributions for the same individual on different occasions, both by matching of one way hash values derived from original identifiers, as well as through detection of persistent session information ("cookies") set in the user's computer's preferences (which helpful only if they use the same computer and same account on it to perform successive uploads).

On the download side, since this is only a test site, there is relatively little present; just a few examples. The primary requirement here is to make bulk downloading easy; no unwieldy "shopping cart" interfaces here. The de-identified exams are packaged up as a single set into bzip'd tar files. The reasoning for this is explained in the FAQ, but in short is to make the most efficient use of the bandwidth and storage available in lieu of their being any need to "browse" or "visualize" individual images from the PCIR website itself; i.e., you need to download and unpackage the set to use them.

Entering Reasons and Other Conditions

One of the core issues with having patients contribute their own images, is that those images would be more useful in context than alone. The PCIR site tries to encourage the contributor to also scan their radiology and pathology reports, but frankly, this may be too burdensome for many of them. With luck, some uploaded CDs may contain at least the radiology reports. A modest amount of information may occasionally be present in the DICOM image headers. As a fall back position, better than no information at all might be something that the patient themselves was willing to enter.

Accordingly, I put some effort into constructing a set of menus from which the patient could chose from a list of categories. After looking at a bunch of different available coding schemes, including SNOMED, ICD-9CM and ICD10CM, I finally settled on the Medical Subject Headings (MeSH) used by the NLM to index articles in medical journals. MeSH seemed to offer a comprehensive range of terms without being too detailed, is not encumbered by expensive or nationally-specific licensing restrictions, can be downloaded in an easily processable XML form, and most importantly, was already organized into hierarchies that translated well into menus. Some massaging was required for the lay person (e.g., to turn words like "neoplasm" into "cancer"), and there were a few missing critical categories (such as for healthy screening exams).

Let me know what you think of the result, which you can test by going to the PCIR upload page and clicking "Enter Reason".

David

On generating and searching static web pages

2007-10-14T09:16:00.000-07:00

Summary: Adding search capability to static pages is easy with Google; creating heavily template-based web pages with Apache Forrest is not quite so easy but worth the effort, there are some nice templates around like Mollio.

Long Version.

Anyone who has looked my web pages knows that they are lacking in style, both figuratively and literally, at least with respect to appearance. My pitiful excuse is that they started out as a place to disseminate the Medical Image Format FAQ, and since that started out as a set of plain text files posted via Usenet Newsgroups, the bulk of the material had no style to start with. Since then, I guess I have just focused more on content than appearance; shameful, I know.

But recently I have been thinking about how to create a more friendly web site, specifically in the context of the "Patient Contributed Image Repository" site that I am working on building. Since the primary audience will be ordinary people like patients and their families, a pleasant, professional appearance with easily navigable and clearly readable content is required. At the same time I have been working on the XML representation of the DICOM Standard, which we are doing in DocBook, and though I have previously used XSL-T quite a lot to transform structure and extract content, I have also been forced to learn something about CSS as well.

Accordingly, I began looking around for both nice "templates" to use, as well as ways of automating the transformation of structured content into web pages (without having to re-invent this from scratch).

I am looking only for straightforward navigation and layout, preferably CSS-based, since frames and tables seem to be regarded as passé these days. Frames in particular seem to be positively "harmful" in some folks opinion. Table-based layout versus CSS -based layout seems to be more a question of ease versus browser compatibility (see for example, Tables Vs. CSS - A Fight to the Death, and Why avoiding tables (for layout) is important). Strict XHTML requires the use of styles anyway, forbidding the legacy appearance related tags, though of course one can still use tables for layout; but the writing is on the wall, avoiding CSS is just not an option. But such stylesheets are potentially sufficiently complex that using somebody else's professionally designed template seems like a good tactic, especially if that professional is a trained and/or experienced graphic designer or artist.

In my hunt for nice templates for web sites (as opposed to entire documents), the only (free and reusable) ones I have come across so far that I liked enough to recommend are those from Mollio, which have a stark simplicity with sufficient functionality to match most typical modern web sites.

But I was still faced with having to do a lot of untidy manual cutting and pasting on multiple pages, as well as maintaining many internal and external navigation links. Most tedious. Being both an XSL-T and DocBook aficionado, I was most pleased to discover the "Website" package amongst the (many) types of DocBook stylesheet generated output possibilities, and even more pleased to discover that it was reasonably thoroughly documented in the standard text, "DocBook XSL: The Complete Guide". However, before getting too far into playing with it, I found what seemed to be a more "active" set of tools developed from DocBook Website called SilkPage. These stylesheets seemed to be quite a lot easier to use, and more thoroughly documented. Some preliminary experiments were quite promising. However, yet more searching revealed the existence of the Apache Forrest project, which seems to have taken over where SilkPage left off (and indeed the SilkPage developer, Sina K. Heshmati, seems to have moved on to Forrest). This is dead easy to get going (all pure Java and client-side), including generating a "seed" set of pages with a single command, which can then be edited to include the outline, content and layout that you desire. Though Forrest is still in development and not officially released yet, what is currently supplied looks like it works pretty well, and the default appearance of the seed "project" looks pretty good using the supplied appearance ("skin"), with more skins promised in the future (if you don't want to create your own). You can see some real-world examples here. Even better, Forrest promises DocBook support as well, though the primary "content" format seems to something called "xdoc", which contains a limited set of tags and I gather grew out of the Maven project. I haven't experimented sufficiently yet to decide whether xdoc or DocBook will be more suitable for my new web pages; there is probably a lot more tooling for the latter, but if the former is sufficient I may well opt for its simplicity.

Anyway, if I find anything better I will let you know, but for the time being Forrest seems to satisfy my relatively straightforward requirements of being able to create, and more importantly maintain, a non-trivial set of static page content with a contemporary appearance and navigation.

Of course it goes without saying that the pages will avoid the use of proprietary rubbish like Flash, which I (and it seems, many others) hate with a vengeance and regard as the modern equivalent of flashing text or banners. Indeed, I hate Flash so much that maybe I will start a "Flash-free validation service", maybe with a cute little logo to include on your site if you pass.

To the extent possible, I also want to avoid anything that might be configured off in the user's browser or require plugins or be non-portable across browsers, which includes Javascript, applets, etc. So I don't yet know to what extent Forrest supports these. The Patient Contributed Image Repository site will allow uploading of files, so something like Java Web Start will probably be required, but there is no getting around that, unfortunately (I do love Java Web Start, by the way, and have had great fun experimenting with pages that automatically download the correct JRE on a platform-neutral and browser-neutral basis and load the right native libraries for JAI, etc., but that is a subject for another day).

I have mentioned static content several times, and this is a consequence of my preference for avoiding server-side deployment issues that require any particular choice of server pages, database, etc., if at all possible. For complex content this always raises the question of how to search for stuff, and in perusing the Forrest documentation I came across a page that addresses this question, which reminded me about the possibility of using Google to search a particular site.

The bottom line is that one just needs to get the right parameters into the URL. A normal Google search for word "bla" looks like "http://www.google.com/search?q=bla". To constrain the search to a specific site only, such as my site, just add "&sitesearch=www.dclunie.com". Note that the sitesearch parameter can include sub-folders. It is trivial to insert a simple form element in any static web page to do this, and there are some simple examples at Dave Taylor's page. Note in particular that no Javascript is required to do this, no indirection through anybody else's site is required (which some downloadable scripts for this seem to do, perhaps nefariously to gather your details), and you don't have to have a special account or be registered with Google. This despite links to what apparently used to be the Google Free page describing this,
"http://www.google.com/searchcode.html", which now redirects one to a page called Google Custom Search Engine, which seems to imply that more is necessary. I am sure there are more powerful features there, but the simple approach seems good enough.

It took me only a few minutes to augment my own home page with an ugly little search tool and configure it to search not just my own site, but also a few favorites, like the current DICOM standard. Indeed, since these blog pages, though created with Blogger, are actually stored at and served from my primary web site, they get searched as well. As do PDFs, which is particularly cool.

Anyway, just thought you might like to know. Not that I am promising to update my primary site so that it looks halfway decent anytime soon. As I mentioned this is for a new project. The FAQ though, is quite structured despite its hand-written content, so it might be possible to automate most of that conversion.

iPhoto and importing large numbers of images

2007-09-28T04:39:00.000-07:00

Summary: Panasonic Lumix DMC-FX01 and Nikon D200 rule, iPhoto sucks, external iPhoto libraries still use gobs of temporary space on startup disk during large imports (need to move /private/var/tmp)

Long version:

It has been a while since I posted, which I will attribute partly to having been on a long, computer-free, vacation back in Australia, visiting my parents, and indulging my wife's passion for wild-flower photography. The latter accounts for the timing, in that spring is not perhaps the best time to visit due to the prospect of rain, but a few weeks in September are the only time that the flowers in Western Australia bloom. Which brings me to the subject of the post ...

We took two cameras. The first was a tiny little Panasonic Lumix DMC-FX01, a great little 6MP snapshot camera that we bought immediately when we saw a friend's, because it is one of the very, very few with a macro (5cm) mode. The second was a recently purchased Nikon D200. My old 35mm Nikon had finally given up the ghost (its tiny little almost 15 year old brain just locked up one day), and on an impulse walking past Adorama on 18th St we decided to get back into the world of "real" photography. Though I have a good set of AF lenses that still work perfectly well with the D200, I also couldn't resist the impulse to replace our old manual macro lens with an AF Micro Nikkor 60mm f2.8, which worked very well for our wildflower photography in the field on this trip. The D200 has more than enough buttons and functions to make a programmer happy and yet in its default mode is easy enough for a normal human being to point and shoot; just be careful not to inadvertently move the auto-focus target away from center with the cursor buttons accidentally, which is easy to do. The best thing for me as an old Nikon user is that the buttons and functions are an incremental improvement on the film-based predecessors and hence fall naturally to hand.

So the cameras worked well and on returning with several thousand photos and a severe case of jet lag, I eagerly proceeded to import them into my wife's computer. Like me, Eleanor has always been a Mac aficionado. In her daily work as an artist, she lives and breathes Photoshop, but for expediency's sake uses iPhoto to manage her personal digital photographs. I am ashamed to say that her machine is not the latest and greatest, something that I will rectify next time she is between contracts and can tolerate some downtime, so it has a bit of a hybrid collection of disk drives to spread things around, which brings me to the primary subject of this post.

Since space on the startup internal hard drive was tight, I had recently moved the iPhoto library from its default location at "~/Pictures/iPhoto Library" to a folder on an external USB attached drive (by copying the library with the Finder, and then holding Option during iPhoto startup which prompts the user to create a new library or to locate one). This was with iPhoto 2.0, since I had not ever bothered to update iPhoto even when updating her system from Panther to Tiger. Anyhow, everything seemed to work just fine that way, in iPhoto's usually inimitable (sluggish) manner.

So back to importing. I plugged in the D200 via USB with its 8GB CF card with several thousand large JPEGs on board (told you I wasn't a serious photographer; no camera raw format for us at this stage). Told iPhoto to begin the import, and since it looked like it was going to take a really long time, left it overnight.

Surprise, surprise, in the morning a) there was a message that disk space was low on the start up disk, b) only 700 or so photos had imported and c) the battery in the D200 was now depleted. No message within iPhoto that anything was wrong though, and in particular no message that despite having started to import 2309 pictures only a small set had succeeded.

Concluding that I was an idiot for not having ordered an external power supply for the camera in the first place (having either not thought about it or assumed that USB power might be available or suffice), I thought that perhaps that was the root cause of the problem, and ordered a Nikon EH-6 AC Adapter ($79.80 from Amazon; at the price there is no excuse for not having one of these). Whilst waiting for it to arrive I was of course unable to resist playing around though.

Let's swap batteries and just try again and pay a little more attention this time; but I first I thought about the matter of running low on disk space on the startup disk. The iPhoto library was definitely on the external drive. There was nothing to speak of in /tmp, before or after quitting iPhoto. Strange, I thought. Assuming that perhaps iPhoto had just been allocating lots of memory to keep track of things, build thumbnails or whatever, and had run out of swap space (wherever that might happen to be stored, something I had not previously considered), I figured a reboot might be in order, and sure enough there was a gigabyte and half or so spare back again after restarting the machine.

Repeated the import process (selecting not to reimport duplicates when the dialog appeared) and a few more were imported, but again, not all, no message from iPhoto to confirm this or explain why, and a shortage of startup space once again. Tried a few other things, like disabling the inactivity sleep in energy saver as well as moving the library from the external USB drive to another internal hard drive with lots of space, but no joy. Old software perhaps, I mused, time for an upgrade, since I had a family pack of iPhoto 6 kicking around that I occasional used on my own machine.

Just to confirm that jet lag impairs decision making, this process did not of course go smoothly, though I did at least check that I had a pre-vacation backup of the the iPhoto Library, which it turned out that I needed ! Somewhere in the process of repeating the import and/or upgrading iPhoto, I managed to completely corrupt the iPhoto database, I don't recall exactly at which point. No amount of rebuilding (hold down command and option whilst starting iPhoto) thumbnails and/or the database succeeded in recovering the database despite the presence of all the photos themselves right there in the various folders in the library. Since my wife had put a considerable effort at sorting her existing (pre-vacation) collection into albums, starting afresh by just re-importing all the photos was not an option, so I restored the old database from the Retrospect backups, started up iPhoto 6 which then wanted to upgrade the library, which it did OK this time, and things seemed more or less back to normal.

Repeated the import from the D200 with exactly the same results - incomplete import, consumption of space on the startup disk, and no helpful message from iPhoto. Each time I repeated the process iPhoto would import a handful more, but never the complete set. I was still running out of battery power, but when my external power supply arrived, nothing changed. Of course the camera remained powered up and mounted as a disk, but the import behavior remained the same.

Hmm; time for some more serious Googling. I could find no specific reference to large imports failing in a similar manner. I did find somewhere though mention of iPhoto using "/private/var/tmp", particularly in relation to such a folder not being cleaned up on restart, though that turned out not to be relevant. Having a more than passing familiarity with "/tmp", but never having heard of "/private/var/tmp", some investigation seemed in order.

Sure enough, when iPhoto begins importing, a folder is created in "/private/var/tmp" and it starts to fill up with hundreds if not thousands of large JPEGs named in the same pattern as the camera file names; it seems that the import process involves copying to this folder prior to copying into the iPhoto library folder. It doesn't seem to be the complete set though, and perhaps there is some queue mechanism with one thread copying from the camera to the temporary folder and another copying them to the library and then removing them.

Whatever, the net result is that a large iPhoto import results in a huge amount of temporary space being consumed on the startup disk, and hence failing when it runs out, even if the iPhoto library is on another disk with plenty of space. Furthermore, though the operating system warns about this (presumably because there is a competition with swap space), iPhoto itself remains silent, which I find particularly dismaying.

It was possible to work around this simply enough, by:

- creating a temporary folder on another drive (e.g., "/Other/private/var/tmp") and giving it the appropriate permissions (as root, using chmod to make it rwxrwxrwxt (+arwx,+t))
- replace the "/private/var/tmp" folder with a symbolic link
(ln -s) to "/Other/private/var/tmp"

Then everything worked fine.

I was a little reluctant to mess with the temporary folder on a running system, and was too lazy to go down to single user mode, but I did quit all other applications and it worked OK; I wasn't game to reboot in this configuration though, in case "/private/var/tmp" is need during boot before the other file systems are mounted, so I put it back to normal before rebooting.

So, in short, I can't say that I am that impressed by iPhoto's robustness or scalability. To be fair, I have not tried the very latest version, which I gather is iPhoto 7 (in iLife 2008), since one has to pay for the upgrade and it has some significant changes in user interface and library organization so may interfere with my wife's workflow.

But I find it hard to excuse a silent failure to import images, since that has the potential to lose a photographer's hard work if they are not very careful to check for this (e.g., by comparing the expected number of images with the actual number in the last imported "roll").

It's probably a bit harsh to go so far as to state that iPhoto sucks, but like most people, it only takes one really bad experience to really put me off a product and this has come close; thankfully no pictures were actually lost though. Last time I was this irritated at a product to the point of publicly eviscerating it was when Retrospect did not keep up with support for the internal DVD writers in the new Mac laptops causing my entire personal backup strategy to go down the toilet. I guess I just have a low tolerance for inconvenience.

As far as my work around is concerned, I would not recommend it, and post it here only to make folks aware of the problem. Messing with system temporary folders as root is obviously not something for the average digital photographer and Mac user to be doing, so I conclude that in general imports of a large number of photographs requires a correspondingly large amount of free space on the startup disk to be completed reliably, regardless of the location of the iPhoto library itself.

David

PS. Note that at no stage did I check the "remove from camera after import" button in iPhoto. I was not willing to risk the camera images being deleted without having been successfully imported.

Where to get images for research and testing - Public collections, routine re-use, and the possibility of direct patient contributions

2007-06-17T05:38:00.000-07:00

Summary: Large useful collections of publicly accessible medical images for testing and research are few in number; despite public initiatives to build such collections, progress is slow though improving; the additional possibility of having individual members of the public contribute their own images and data directly has been raised; logistic and legal concerns are significant but surmountable, and there would seem to be few privacy and human research regulation issues.

Long version:

I have long fantasized about the existence of a large collection of complete sets of images suitable for research and testing purposes, whether it be for testing image pixel data for different types of compression, display, analysis, or similar studies, or for more mundane tasks like checking for DICOM compliance or testing DICOM-capable tools like PACS and workstations against the installed base of equipment. Indeed, I first developed an interested in DICOM in the early nineties not for clinical interchange, but as a means of formatting and organizing my own teaching and research collections. Little did I know where that would lead !

Traditionally in academic research studies, one begins with a laborious exercise of collecting patient-related images prospectively or retrospectively; this often involves multi-site collaboration, approval by Institutional Review Boards (IRBs), etc.; this is very expensive, time consuming, and frankly, beyond the capabilities of many scientists, engineers, programmers and students who just want to test their ideas, algorithms and code. Further, the folks who need the images may not have the academic affiliations, credibility or stature to even get to first base as far as funding or approval is concerned.

Some of us are fortunate enough to be actively engaged in large scale multi-center clinical trials and industry testing collaborations and we can often find ways of re-purposing and reusing images gathered for other purposes, with the appropriate approvals and permissions. This avenue is not open to many folks who need images though. Some of the NIH folks are keen to remedy this problem by recruiting images from other studies and making them publicly accessible via such mechanisms as the National Cancer Image Archive (NCIA) and the Alzheimer's Disease Neuroimaging Initiative (ADNI) projects to name just a few of several. These projects emphasize the importance of gathering not just any images, but complete sets, in a relatively homogeneous manner with respect to acquisition protocol, at multiple time points in the course of diseases that need to be followed over time, and with additional related data, such as experts' assessment of lesion location and outcome and historical data where relevant. Such efforts still require significant resources and involve sometimes difficult negotiations with respect to funding and permission.

Another option that I have considered in the past is to somehow capture images and associated information as a "side effect" of routine clinical use. For example, many facilities are partially or totally digital already, with respect to images, diagnosis codes and reports if not the entire medical record. Further, many such sites already use "off-site storage" provided by third-parties either as their primary archive or to support disaster recovery. Would it be a difficult step to go a little further and automatically collect and de-identify all such image and related data and make it publicly available for research ?

From a legal perspective, possibly all it would take would be for the facility to add consent and authorization for such routine (as opposed to prospectively identified) re-use purposes; however, each IRB would undoubtedly weigh in with policy and risk-management related issues that might be difficult to get by. And frankly, many physicians might feel threatened by releasing what they otherwise consider their proprietary material, which potentially provides them with a competitive advantage with respect to grant applications and publishing papers. To put it another way, one would need to provide a facility with one hell of an incentive to get by the obstacles that naysayers might raise.

One such incentive might be to provide free or really cheap storage; how many CFOs or CIOs would drool over the possibility of reducing or eliminating bulk data storage costs if a third party (such as a non-profit organization established for the benefit of the public research community) were to underwrite these costs, on the proviso that their de-identified form be made available ? Such an incentive might serve to significantly undermine any opposition within an institution. It might be possible to leverage the capabilities of existing commercial providers of off-site archives, who could offer a reduced price for such data sets. Conversely however, less well intentioned folks might see this as a commercial opportunity and explore the possibility of selling the data instead of making it publicly available for free.

Some existing archive providers also provide the opportunity for patients to contribute and maintain their own images, allowing access to their health care providers as appropriate, myNDMA being an example (though I noticed as I was researching this post that myNDMA are "accepting no new registrations at this time"). The concept of patient empowerment and patient-centric control of one's own destiny is perhaps a concept whose time has come, though obviously only a subset of the population will be willing to or capable of taking on such responsibility. An example of extending this concept to one's entire record is the MedCommons project.

On a previous occasion, frustrated by the difficulty of getting images from a broad range of installed modalities to test DICOM software, I had considered setting up a publicly accessible archive that would also allow anybody from the public at large to contribute. My plan was to canvas the community of digital imaging and PACS users as well as ordinary people undergoing imaging to submit material that I would then de-identify and make available for testing. At the time my primary interest was in the "DICOM-ishness" of the data and not the research applications, though I was interested in complete sets rather than individual images. I did not pursue this, since about the same time NEMA was initiating an effort to gather images from modality vendors for similar sorts of testing (the NEMA DICOM Object Library). However I was sorely disappointed when, despite my strong protests, the NEMA vendors decided to keep this a closed and secret database not accessible to non-NEMA members or the public, which it remains to this date. Bet you didn't even know about it, did you ?

However, I was reminded of the possibility of direct patient contribution to image archives at a recent Cancer Research and Prevention Foundation Lung Cancer Workshop, during which the concept of approaching patients, people under going screening, and survivors for image contributions was raised. A lively conversation among the participants ensued led by Jim Mulshine, David Yankelevitz and Rick Avila. In essence, most of the attendees were quite excited by this concept, particularly since there is an opportunity to leverage the good will of the survivor-driven charitable organizations to organize and promote such an activity. KitWare has kindly volunteered to coordinate some of this work and you can follow along on their Wiki once it gets under way. Though this was discussed in the context of lung cancer, and particularly with respect to gathering images for CAD testing and validation, the concept is obviously generalizable.

For example, in lieu of there being a good publicly available collection of images for digital (as opposed to digitized) mammography image compression research, one might consider attempting to build such a collection with the assistance of contributions from individual women. One of the obvious problems with this is the relatively low prevalence of disease; i.e., one might receive far more normal contributions than abnormal, which makes performing research on disease-enriched data more difficult, or conversely, means storing and curating a large amount of data for a relatively low yield of useful information. However, unlike the unfortunate situation for lung cancer, a far higher proportion of women either have a negative biopsy or survive their disease, and potentially a high yield of images with positive findings could be obtained from this group.

Another problem is the matter of gathering additional outcome data; for many types of experiment it is necessary to have some knowledge of the truth beyond what can be ascertained from the images themselves. Contribution of pathology reports and/or follow-up images would be desirable. The former presents problems in that these reports are less often accessible to patients (or screening participants) in digital form, though perhaps they could be scanned or faxed The latter might be contributed on a separate occasion, but if de-identified, how are they to be linked to the same (anonymized) individual ?

In general, the problem of reliable de-identification and anonymization (or pseudonymization) on a large scale is hard. Sure, one can clean the DICOM header information well enough, especially if one can discard most of the string descriptive and private attributes without affecting reuse, though even that is non-trivial in the general case. The problem of burned in pixel data identification can at least be detected in a subset of images (by automated algorithms examining header patterns as well as OCR-like analysis of pixel data), which can then be sequestered for manual review. Anything that is not an image though, such as a scanned or faxed, or even PDF or HL7 plain text or DICOM structured report will likely require manual (and hence error prone) attention. The resource burden of manual de-identification (and QC process to check on it) is not to be underestimated.

One approach would be to have the contributor themselves actually perform the de-identification by providing them with the appropriate web-deployed tool to use to contribute, view and edit the content; that way they could both do the work and absolve the archiver from future responsibility in this respect. Indeed, if all the work were performed client-side, the central server would not ever need to have access to or knowledge of the actual Protected Health Information (PHI), which might considerably simplify the necessary security measures. Continuity across contributions would be more difficult but could be achieved with some sort of registration or identity hash based mechanism. It would be shame if this additional burden were to prove a disincentive to contribute, though.

Thorough de-identification in the general case remains non-trivial though, especially if one goes so far as to consider facial information possibly recognizable from a 3D rendering of images of the head; there are means to disrupt the data to prevent this, but that would make it useless for many (though not all) potential future uses. Though trials on the matter of recognizability are currently under way, there is no consensus on this yet, and perhaps it would be easiest just to have the contributor consent around this issue.

Indeed, on the matter of consent, this might be more challenging than all the procedural and technical and resource issues put together. One would have to be sure that the contribution agreement would stand legal scrutiny, cover all potential uses of the data, irrevocably, and allow for the archive maintainer to disclaim any liability. Liability might include not only privacy concerns, but also responsibility to feed back any findings with respect to the data to the contributor. For example, in the case of CAD testing, one would not want the contributor to have the (unrealistic) expectation that if a future CAD experiment found something undesirable that they would receive feedback that would impact their care. Such an agreement would somehow need to be "signed", presumably, to have any legal standing, and a mechanism to do this via the web at the time of contribution and to archive the signature would be necessary.

Note that I distinguish the matter of the individual contribution agreement with respect to permission and liability from the matter of permission from others. To my knowledge, at least in the US, there are no regulations that would govern the establishment of such a repository of images. Whilst the HIPAA Privacy and Security rules might provide helpful guidance, the repository would not in and of itself be a Covered Entity, and hence would not be subject to the rules. Further, since contributions would be directly from individuals rather than Covered Entities, no HIPAA provisions on the sending side would come into play.

Would some form of IRB approval be required, either to contribute, maintain or to use any of the data ? The US federal regulation on Protection of Human Subjects, which potentially applies to federally funded activities, specifically exempts "research involving the collection or study of existing data ... if these sources are publicly available or if the information is recorded ... in such a manner that subjects cannot be identified ..." (45 CFR 46.101(b)(4)),.

However, whilst there might be no formal need for an IRB approval, review of the policies and procedures and agreements by some form of central IRB might well be worthwhile to mitigate any concern that the rights of the contributors are not being abused. Perhaps the NCI's Central IRB (CIRB) Initiative might be willing to take on this responsibility. One could envisage drafting a set of standard "open source" pre-approved documents that would allow any number of willing organizations to implement and replicate this strategy.

This is of course a somewhat US-centric view of the privacy and human research situation biased by my own experience; since any such repository might be open to global contributions, a further analysis of the issues in other countries is desirable.

But the bottom line is that there would seem to be few if any restrictions to a person who has access to their own record in electronic form to use it in any manner they see fit, and hence to contribute it to such a research collection for the public good. Whilst one may debate about who actually "owns" the data, I hope few would be so crass as to attempt to restrict an individual's use of their own personal data in such a manner.

What remains now is for those of us who see merit in this approach to take action to make it happen, and in such a manner that the data becomes useful in advancing the state of the art.

David

On the lack of DICOM Police, the example of IHE content profiles, and the need for usability standards and cross-certification ...

2007-06-03T14:40:00.000-07:00

Summary: Neither DICOM nor IHE may be sufficient to solve users' real world problems with usability of imaging devices, neither a hypothetical DICOM police nor the existing IHE Connectathon process would solve this problem, and there may be a need for a new type of "usability" standard and certification process, even to the extent of cross-certification of combinations of devices.

Long version:

As everyone is fond of saying, there are no "DICOM police".

NEMA, for example, specifically disclaims responsibility for policing or enforcing compliance to the DICOM standard. There is, for example, no DICOM "certification".

Nor is there an "IHE police", nor, for the time being, IHE "certification".

Some folks are under the mistaken impression that successful participation at an IHE Connectathon represents some sort of certification, but what is tested at IHE is not necessarily a product and may be a prototype, and often is not representative of what you can go out and buy, now, or ever. Furthermore, the IHE tests are limited in scope and depth, not only to the limits of the "profiles" being tested but also by the rigor of the tests themselves. For example, though vendors may demonstrate transfer of images within a specified workflow with the correct identifiers during the Connectathon, whether those images will be usable in any meaningful fashion by the receiver is not tested. These issues may be addressed over time as the IHE testing approach matures and is revised, and more "content" profiles like NM and Mammo are developed and tested. The Connectathon is a fantastic cooperative effort and an enormous investment of time and resources that results in considerable progress, but the fact remains that products are not certified during this process.

Hence the publicly posted "Connectathon Results" are only a guide to what vendors might or might not choose to make available as product, one is left to rely on so-called "self-certification" by the vendors. Vendors dutifully provide DICOM Conformance Statements and IHE Integration Statements, which both guide users with respect to what features are supposed to be available and outline what a product is supposed to do, but it seems that not infrequently products remain deficient in some small or significant way, either with respect to what is claimed, or even correct implementation of the underlying standard.

Who then, will police the compliance of the vendor in this respect? Currently, this is left to the users, or the experts with whom they consult. The vendors mostly appear to act in good faith, but when problems arise some are none too swift to acknowledge that they are at fault or to provide a solution.

But even if there were a DICOM (or IHE) police, would it actually help the users ?

Take for example the matter of compliance with the standard with respect to the encoding of images for a particular modality, say projection X-ray using the DICOM DX image object. Consider a frontal chest X-ray, which, depending on whether it is taken AP or PA, might from the perspective of the pixels read out from the detector have the left or the right side of the patient orientated towards the right side of the image. Now, the DICOM standard does NOT say that the transmitted image must be oriented in any particular manner; rather it says that the orientation of the rows and columns must be sent. In this case the row orientation would be sent either as towards the patient's left, meaning that the pixel data if rendered that way would look the way (most) radiologists would expect it, or the row orientation might be sent towards the patient's right, meaning that the receiver could use this orientation to flip the image into the expected orientation.

And therein lies the rub, since no standard, DICOM or IHE, currently requires that the receiver flip the image into the "desired" orientation for display based on the encoded orientation parameters. So a completely DICOM (and IHE) compliant storage SCU (Acquisition Modality actor) could encode an image in one orientation, and a DICOM (and IHE) compliant storage SCP (Image Display actor) could display it, and the user would still be unsatisfied and have to manually flip the image. No DICOM (or IHE) police or certification or anything else would be able to solve this problem for the user, beyond explaining it.

Conversely, if the modality were to not send the orientation at all, and violate the DICOM standard in this respect, if the pixels happened to be oriented correctly, the user experience would be satisfactory, and no problem would be perceived (except perhaps for the absence of an orientation marker to indicate the side). Indeed this would typically be the case for devices that use the older CR image object in DICOM, which allows the orientation to be empty, ostensibly on the grounds that sometimes it won't be known (e.g., there is a plate reader but no means for the operator to enter this information on the QC workstation, if there is one).

The acquisition modality vendors may solve this problem by making the sending device configurable in such a manner as to "flip" the images as necessary to give the expected result at the other end, either automatically or with the assistance of the operator, but the fact remains that this sort of configurability is not required by the standards.

Another example would be the matter of display shutters, such as to blank out the perimeter around a circular or rectangular angiography or RF acquisition, so that it remains black regardless of whether the image is inverted or not. The DICOM standard defines their existence encoded within an image, but does not mandate their application by the display (unlike in a presentation state). I was recently reminded of this when there was a compatibility issue between one vendor's acquisition device and another's PACS. The modality was sending a display shutter and the PACS was ignoring it, and the resulting white background was unacceptable to the user. A modality vendor would typically provide a configuration option to burn in the background as black in this case (resulting in white when inverted, but you can't configure around everything), and handle the lame PACS, but this particular modality did not have that feature. The PACS vendor had I am told only just released display shutter capability in a new and expensive release, so the user was essentially out of luck. Again, there would be no help from the DICOM police in this regard, assuming they could only act within the bounds of the "law" (what is written in the standard). Furthermore, it is very difficult to ascertain a priori from conformance statements what is possible in these situations, there typically being little if any documentation of the scope of configuration possible on the sending end, or the display behavior on the receiving end.

So, one is inevitably led to the conclusion that the standards are insufficient to satisfy the users needs in this regard, and that DICOM police or certification, whilst arguably necessary, would not be sufficient in their own right.

Or to put it another way, there seems to be a need for "usability" standards, perhaps layered on top of the DICOM and IHE standards. This is an area that vendors may be reluctant to address, since such standards might potentially erode what they see as "added value" (though many users might argue the same are "bare necessities"), and are a source of risk in that if they fail to offer the complete spectrum of "usability" requirements, they might be unmarketable.

There are two categories of precedent for this sort of thing that may be relevant. One category includes the IHE Radiology "content" profiles, specifically NM and Mammography; the other is the federally-mandated certification effort, exemplified currently by the Certification Commission for Healthcare Information Technology (CCHIT).

The IHE content profiles differ from much of the other radiology work in IHE in that they are less about workflow and more about modality-display interaction. Anyone with NM experience knows exactly how woeful most general purpose PACS are with respect to handling NM images, either in terms of providing interface tools with which NM physicians are comfortable, providing layout and reconstruction capability appropriate to different types of acquisition, not to mention analytic tools for quantitative measurements, especially cardiac. The NM folks (in the form of the SNM) finally said enough and ultimately decided to work through the IHE framework to achieve their goal. I have little experience in this area, so cannot say to what extent this profile has actually influenced purchasable products or helped the users in the real world, but this effort paved the way for content profiles that specified image display behavior in detail.

The IHE Mammo profile, on the other hand is one that I was directly involved in. In this case a bunch of very disgruntled users who had faced the realities of owning multiple vendors' FFDM equipment and trying to use it in high volume environments expressed their disappointment at a special SCAR session, which resulted in the formation of a sub-committee in IHE to address the concerns, and ultimately a profile that specified mutually compatible requirements for both modalities and displays.

The process by which the Mammo profile was developed is instructive. First the users expressed their concerns and requirements with respect to real world experience with products; second, the FFDM and dedicated display system vendors admitted that there were problems and expressed willingness to engage in a dialog; third, everyone met together face-to-face to hash out what the priorities were and where there was common ground. There was considerable argument on the fringes, especially with respect to exactly how much application behavior could be standardized or required as a minimum, and which of several competing solutions to choose for particular problems when there existed an installed base of incompatible solutions, but ultimately a reasonable compromise was reached. The users insisted that deployment be swift and arranged a series of public demonstrations at short intervals to ensure that progress was made.

What distinguishes the Mammo profile is that it is very specific about how displays behave and in particular what features they must have, e.g., the ability to display images all at the same size, current versus prior, regardless of vendor and detector pitch, to display true size, to display CAD marks, to annotate in a particular way to meet regulatory and quality requirements, and which DICOM header attributes to use in what manner to implement those features. Further, given the different type of processing and grayscale contrast from the various detectors, the display is required to implement all of the possible grayscale contrast windowing and lookup table mechanisms, not just a vendor-specific subset. I.e., in some cases the vendors agreed to standardize the "intersection" of various different possibilities, and in other cases the "union" of all possible, depending on the impact on the installed base and the usability of the feature.

This cooperative effort seems successful so far, though I am biased in this assessment having been intimately involved. However, is it scalable to more ambitious "content", "functional" or "usability" specifications, either within IHE or elsewhere ?

The mammography effort was made considerably easier by the fact that the digital mammography user and vendor communities are relatively small and tightly focused, if by no other factor than the regulatory burden imposed by MQSA. Everyone knows everyone else, basically everybody gets along and likes one another, and it is hard to take too unreasonable a stance in this group for very long. A certain amount of "cat herding" was required of course, but on a level of difficulty scale of 1 to 10, I would rate this one about a 4.

One risk to scalability is that "users" will not bother to ask for the IHE profile in their RFPs and contracts, and will buy whatever non-compliant lame "mammo package" their existing PACS vendor deigns to offer and force their radiologists to use it. This risk could be mitigated if the FDA were to require that only certified products were used for primary interpretation, but this would be a very special case since mammography is about the only area in which the FDA has authority to regulate the practice of medicine, and is not generally applicable. Other organizations, like JCAHO or third party payors could require certified compliance, but would there be any benefit for them to do so ?

Another risk with respect to generalizing the approach is the lack of interest by users in developing usability standards. The mammography and NM examples were perhaps atypical in that there were highly motivated individuals to champion the cause who devoted enormous amounts of time and energy with the support of their organizations. Is this degree of user involvement likely to be repeatable in other areas where the problems may not be so acutely felt, where the scope is broader, or the problem is larger in scale ?

Likewise, there is the risk that the vendors will be unresponsive to such efforts. Both DICOM and IHE development have been characterized by the active participation (some might say total domination) of vendors and have as a consequence been at least somewhat successful. Externally imposed standards to which there may be outright vendor opposition would be less likely to be successful.

On the subject of scale, it is potentially enormous, if one were to go the extent of defining the required functionality of an entire PACS with respect to usability of workflow and display. Anyone who has written requirements specifications and test scripts for the implementation of such products is familiar with the level of effort, but then again since this has already been done internally by vendors many times over this is not a new experience.

To that end it may be instructive to review the work of CCHIT so far; kick-started by federal funding and a requirement to certify ambulatory EHRs, this effort has produced some interesting materials, even if one is not a fan of the politics involved. On their web site you can find documentation of their process, the functional requirements against which certification takes place, the actual test scripts that are used, as well as the public comments received as these materials were being developed, which give an interesting insight into the vendors opinion of the process and the expense as well as the heavy handiness of the CCHIT.

I have no involvement in this process at all, so can't speak to its success or value so far, and you can read the materials as well as I can. It is interesting though, to review the functionality criteria for an ambulatory EHR and envisage how one might write similar criteria for a PACS. Likewise, to review the test script for these criteria from the perspective of perhaps testing an Image Display with the same approach. To return to the example at the beginning of this entry, one could envisage a criterion for a PACS such as "shall be able to display a frontal chest x-ray rotated or flipped into the correct orientation based on the DICOM orientation description" and a corresponding test script entry with a range of test materials that included images encoded in a manner that required such flipping. This is exactly the sort of testing that we did for the IHE Mammo profile.

If this were to be done, would self-attestation or self-certification be sufficient or would there need to be in addition external verification and certification such as CCHIT performs ?

Who would require either form of certification ? The users themselves ? The payors ? The government ?

What would be the appropriate organization to perform such work ? Would CCHIT take on imaging or do they have enough on their plate, not to mention no expertise in this area ? Could or would IHE do it, particularly now that it has grown well beyond radiology into other domains that have their own issues and priorities ? Would ACR, who are all very eager to "accredit" modalities, be interested in or capable of this ? SIIM would perhaps be a logical choice, were it not for the apparent influence vendors have on their decision making process about things controversial. How about RSNA, or are they too invested in IHE already to begin a separate effort if one were thought to be necessary ?

Or is there a need for yet another independent organization to do this ? If so who would start it ? Who would run it ? Who would pay for it ?

And ultimately, would "standalone" certification against criteria be of sufficient benefit ? It would be a start, but if there is one thing that the IHE Connectathons have demonstrated it is that the proof is in the testing of multiple devices working together. To that end, does one need an infrastructure to support certification of permutations and combinations of devices inter-operating together, either in a test environment or in the field ?

One could envisage an approach in which the two (or more) vendors involved submitted a "joint application" for certification of a combination evaluated against specific criteria based on the first actual deployment. Funding, implementing. monitoring and promulgating this information would be a challenge, but perhaps not insurmountable.

Imagine in the display shutter example that the forward thinking purchaser of the PACS had included in their support contract a requirement that the PACS vendor participate in such cross-certification activities as new modalities were acquired by the site; likewise before accepting the new modality the site would have required the same of the modality vendor. If both had been previously cross-tested satisfactorily they would already be certified, and indeed the purchaser would have known this by consulting the certifying authorities web site; any limitations would have been publicly documented and disclosed. If the particular combination had not, then a first-time test would need to be performed against the certification criteria, supervised by some sort of "designated examiner" trained and licensed by the certifying authority. The result, whether successful or not, would be promulgated in full. Fees to cover the cost would be payable by the pair of vendors, and they would recover this in their service contracts or purchase price. If one or other of the vendors refused to participate then the user could still execute the (publicly available) test script themselves at their own expense, with or without an examiner, the results could still be promulgated with or without either vendor's prior approval, and failure might be a clue to the user not to accept the modality or to plan to replace their PACS.

So we have come full circle, in that this is exactly the sort of paradigm that the IHE Connectathon supports. Except, that it would involve products rather than experimental or prototype systems, the details of test script execution would be fully public, rather than categorized as a simple pass/fail or prevented from disclosure by confidentiality agreements, a considerably more comprehensive range of old and new products would be tested, the result would be a formal certification, the criteria would be at a level that addressed functionality and usability not just message transfer and workflow, and the users and sites could specify certifications as criteria in their purchase and support contracts.

Or perhaps, the "great learning experience" for engineers, which is essentially what the Connectathon is, could be translated into a formalized process of direct, rather than only indirect (albeit very important), benefit to the user.

David

Welcome to David Clunie's Blog ...

2007-06-03T08:39:00.000-07:00

... in which you will find various ruminations (calm, lengthy considerations ?) and periodic stream-of-consciousness dumps, in a less structured form than the regular material on this site ... feel free to leave comments but do not be offended if I edit or delete them at will ...