MINT update

77 views
Skip to first unread message

Jonathan Whitby

unread,
Oct 11, 2012, 4:48:45 PM10/11/12
to mint...@googlegroups.com
Hello,

This is just a quick update on the latest MINT activities for those who are interested in MINT but may be following the activities of DICOM WG-27.

Work is ongoing on a version 2.0 of the MINT API. Additionally, some members of the MINT community are working with DICOM WG-27 to define DICOM RESTful web services that are closely aligned with MINT 2.0.

The main focus of the MINT 2.0 and DICOM work has been on four groups of services:

DICOM WADO-RS / MINT Retrieve Services

- DICOM Supplement 161 (ftp://medical.nema.org/medical/dicom/supps/PC/sup161_pc.pdf)

- Currently in the Public Comment Stage

- Consists of the following services:

o Retrieve Study Metadata (XML)

o Retrieve Study / Series / Instance (DICOM binary or binary pixel data)

o Retrieve Frames (binary pixel data)

o Retrieve Bulk Data (binary bulk data)

- Includes the possibility of transfer syntax negotiation and transcoding

- MINT 2.0 services will be identical to the DICOM services except for the fact that the Retrieve Study Metadata may use a different XML format from DICOM

- Currently aiming to have this supplement at Final Text stage in January 2013

DICOM STOW-RS / MINT Storage Services

- DICOM Supplement 163

- Will be up for Second Read in November 2012

- Consists of the following service:

o Store Instances (DICOM binary or XML and binary bulk data)

§ Optionally restricted to a specified Study

- MINT 2.0 will support the DICOM service (again with the possibility of a different XML format) but may also support additional storage-related services - still to be determined

DICOM QIDO / MINT Search Services

- No current DICOM supplement number

- Will be up for First Read in November 2012

- RESTful search that maps to both DICOM C-FIND and IHE XDS document search

- Includes Study-, Series- and Instance-level queries with results available in DICOM or JSON

- MINT 2.0 will support the DICOM service (again with the possibility of a different XML format)

MINT Attachment Services

- No planned DICOM equivalent

- Allows for the non-permanent storage of proprietary objects

- As this does not tie to a DICOM service this may be finalized before other parts of MINT 2.0

- A follow-up e-mail will include details of these services

There are still a few open issues around MINT 2.0, such as questions on other services to be included in MINT 2.0, XML format and around transcoding of binary objects, but overall there has been significant progress, particularly in terms of DICOM acceptance.

Please feel free to reply to the group with questions.

Regards,

Jonathan

_________________________________________________________________________________________________________
[cid:image0...@01CDA7D0.47709890]

Jonathan Whitby | Product Analyst
5850 Opus Parkway, Suite 300 l Minnetonka, MN 55343
+1 952 487 9736 l m +1 647 966 6441 l www.vitalimages.com<http://www.vitalimages.com/>

A Toshiba Medical Systems Group Company

_________________________________________________________________________________________________________

image002.png

Damien Evans

unread,
Oct 11, 2012, 7:20:26 PM10/11/12
to mint...@googlegroups.com
Thanks for the update.  I was wondering what had happened to MINT. 

 -- Damien

Thomas Sondergaard

unread,
Oct 12, 2012, 6:03:15 AM10/12/12
to mint...@googlegroups.com
Thanks for the update!

What is the reason for using two different XML formats in MINT 2.0 vs DICOM?

Will DICOM WADO-RS also mandate support for retrieving the full
metadata-set in one query (except for the binary bids). To me this is
the big deal with MINT and I imagine a lot of existing archives would
have trouble being adapted to a model where the full meta-dataset has to
be made available in a single query - a query that should also be fast!

Should MINT not try to limit the number of pixel encodings/formats? It
seems DICOM has shied away from trying to dictate limitations in this
area, making it more complex to write a client than it has to be. Big
endian, little endian, embedded bitmap overlays, etc.

Thanks,
Thomas

Jonathan Whitby

unread,
Oct 12, 2012, 2:46:59 PM10/12/12
to mint...@googlegroups.com
Hi Thomas,

Thanks for the feedback.

MINT 1.0 had its own metadata XML format that supports study-level objects with common attributes normalized.

DICOM Part 19 XML is essentially equivalent for storing the metadata for an SOP instance but doesn't allow for normalization of attributes at the study or series level.

WADO-RS does include an operation to get the metadata for an entire study. However, as this is in DICOM Part 19 format it will be transmitted as a multipart message with one part per SOP Instance. This can of course be gzipped.

The metadata will not contain any binary attribute values but just references to the objects, which can be retrieved using the Retrieve Bulk Data service (or various other services for getting pixel data).

While transfer syntaxes and pixel encoding are still under discussion, what seems to make sense is to restrict non-pixel objects to little Endian but allow pixel data to be encoded in current DICOM transfer syntaxes.

It would be nice if the JPEG-related MIME types were rich enough to mirror the DICOM encapsulated transfer syntaxes but this does not appear to be the case.

If you have any thoughts on what types of transfer syntax restrictions might be useful or how this area could best be addressed please look at DICOM supplement 161. Public comments are still open and that would be useful information.

Regards,

Jonathan
_________________________________________________________________________________________________________

Jonathan Whitby |  Product Analyst
5850 Opus Parkway, Suite 300  l  Minnetonka, MN  55343
+1 952 487 9736 l  m +1 647 966 6441www.vitalimages.com
A Toshiba Medical Systems Group Company 

_________________________________________________________________________________________________________

> +www.vitalimages.com<http://www.vitalimages.com/>
>
> A Toshiba Medical Systems Group Company
>
> ______________________________________________________________________
> ___________________________________
>



________________________________________________________________________
This email has been scanned for all viruses and found to be virus free. If you have questions regarding this scanning please visit the Information Services area of http://home.vitalimages.com ________________________________________________________________________

Thomas Sondergaard

unread,
Oct 12, 2012, 3:48:38 PM10/12/12
to mint...@googlegroups.com
On 2012-10-12 20:46, Jonathan Whitby wrote:
> Hi Thomas,
>
> Thanks for the feedback.
>
> MINT 1.0 had its own metadata XML format that supports study-level objects with common attributes normalized.
>
> DICOM Part 19 XML is essentially equivalent for storing the metadata for an SOP instance but doesn't allow for normalization of attributes at the study or series level.
>
> WADO-RS does include an operation to get the metadata for an entire study. However, as this is in DICOM Part 19 format it will be transmitted as a multipart message with one part per SOP Instance. This can of course be gzipped.

Thanks for the explanation. The normalized single-query single-result
MINT style is far better, in my view. I wish DICOM would standardize that.

Thanks,
Thomas

--
Thomas Søndergaard
R&D Manager

Mobile: (+45) 5157 3090
Skype: tsondergaard

Medical Insight A/S
Krumtappen 4, Etage 3
2500 Valby
Denmark

Reply all
Reply to author
Forward
0 new messages