MINT search
Tim Dawson
I’d like to propose a minor enhancement to the existing MINT search that I think will greatly improve its usefulness and align with the upcoming QIDO specification.
One of the features of QIDO’s search is that the results contain metadata information about the study. As you may know, MINT’s search results currently contain no such information. This was done originally based on the fact that the only thing we could agree on regarding the tags to include in the results was that we’d never agree on the tags to include in the results. Different use cases would need different fields, and different implementations would have an easier/harder time providing them. So the (somewhat controversial) decision was made to not include any metadata, but simply provide a list of matching studies – identified only by the Study UUID, the last modified datetime, and the version of the study (a counter incremented each time the study was changed) – and require the caller to request the metadata for each.
<?xml version="1.0" encoding="UTF-8"?>
<studySearchResults xmlns="http://medical.nema.org/mint" timeZone="GMT" offset="1" limit="50">
<study studyUUID="ff6dd0e6-aae3-496e-92c2-de85d9e4ec44" lastModified="2012-02-20T23:20:51.78Z" version="1"/>
<study studyUUID="3dd3ad35-af48-41e0-b9b6-a14cb83c9ab4" lastModified="2012-02-20T23:10:37.97Z" version="4"/>
</studySearchResults>
The obvious problem with this approach is that it requires a 1+N http requests and there’s no way to provide a responsive user interface with this. So what clients ultimately needed to do is work in conjunction with the changelog and the study metadata request to create an index of the archive on their side. This can work for some use cases but has all the obvious synchronization issues.
The way QIDO handles this is better – yes, there is a default set of metadata returned which not everybody may agree upon, but QIDO adds the ability to specify fields to include/exclude, e.g. includeField=00081030 to include the study description, or excludeField=00080020 to eliminate the study date from the results. (I’m not really sure excludeField necessarily needed, but it was put in there for symmetry).
It will be some time until QIDO is finalized and approved, but I believe we can get the benefit of this immediately in MINT, and leave MINT to be more aligned with QIDO. I would like to propose that we make a minor enhancement to the existing MINT 1.1 search API to add the includeField parameter. If fields are specified to include (e.g. /studies?includeField=00081030&includeField=00080020) we would include sub-elements within the <study> tag – this would follow the existing element definition used by the MINT metadata.
<?xml version="1.0" encoding="UTF-8"?>
<studySearchResults xmlns="http://medical.nema.org/mint" timeZone="GMT" offset="1" limit="50">
<study studyUUID="ff6dd0e6-aae3-496e-92c2-de85d9e4ec44" lastModified="2012-02-20T23:20:51.78Z" version="1">
<attr tag="00080020" vr="DA" val="20101123"/>
<attr tag="00081030" vr="LO" val="SLIT LAMP PHOTOGRAPHY"/>
</study>
<study studyUUID="3dd3ad35-af48-41e0-b9b6-a14cb83c9ab4" lastModified="2012-02-20T23:10:37.97Z" version="4">
<attr tag="00080020" vr="DA" val="20000913"/>
<attr tag="00081030" vr="LO" val="Abdomen^COLON STUDY 1"/>
</study>
</studySearchResults>
Compliance with the requested fields would be optional. If a field isn’t available, no <attr> element is created for it. This is a key point to adoption - not all implementers will have ready/fast access to all DICOM fields for a study, and we don’t want errors generated if 1 out of 15 fields requests is not available. This matches the current plan for QIDO.
One difference with QIDO is that I’m not recommending including any default metadata – the <attr> elements are only provided if includeField parameters are specified and data is available. This allows complete backwards compatibility … any existing client would not provide the includeField parameter and so would not receive (or error out upon receiving) the <attr> elements. Because compliance with the field is optional, if a client with a newer version uses includeField on an old version of MINT search, it knows that it may or may not get metadata for any of the requested fields.
This is a relatively minor change, but would allow clients (VitreaView for example J) to query an archive directly to search for studies for a given patient, e.g. for priors.
If there are no objections, I’d like to propose doing this in a minor update to the existing spec, say MINT 1.2 rather than waiting for MINT 2.0. (If approved, I will also volunteer Vital’s time to make the change in the reference implementation.)
Tim
___________________________________________________________________________________________________________________
| Tim Dawson | Chief Architect | Office of the CTO 5850 Opus Parkway, Suite 300 l Minnetonka, MN 55343 |
A Toshiba Medical Systems Group Company |
___________________________________________________________________________________________________________________