notes from yesterday's meeting
Tim Dawson
Here are my raw notes from the MINT meeting yesterday at RSNA to review the MINT 2.0 API. We will be updating the proposed API list and will send out a note when it is ready.
Decisions
· Support get and put for MINT and DICOM
· On DICOM multipart upload – expects consistent data (same values across all instances for study and series attributes), if normalization error occurs, return 400 bad request – vendors may provide auto-cleanup
· Remove /info – not needed. Discussed /summary – also not needed. People can grab full metadata and parse what they need.
· Discussed XPath – also not needed – at least on the fly. This will be slower and less scalable than just having the client grab the full metadata and sax parse what they needed.
· Discussed multipart MIME vs. zip as the result format – multipart MIME is more ‘webby’, but tooling support for multipart mime download is poor (most uses of multipart mime is for upload only). Plus using zip allows for ‘application/mint’ to be symmetrical in upload and download.
· If we want proprietary formats, use content negotiation and specify a couple of required formats to support – for downloads.
· For transfer syntax encoding, limit request to basic type (whatever is returned in the mint metadata), or negotiate to explicit little endian uncompressed.
· Discussed the difference between ‘changes’ and ‘versions’. Decision was that we need ‘versions’, not ‘changes’.
· ‘Versions’ will be challenging for adoption - TeraMedica does not store the changes right now, they simply audit that a change occurred – needs to be optional to simplify implementation for VNA.
· For metadata – XML is required, others (e.g. GPB, DICOM, JSON, etc.) are optional. Part 19 xml is ‘application/dicom/xml’ , mint is “application/mint/xml”
· For getInstance… add series to path for uniqueness and to support CFIND proxies
· Jim says we need to rename from ‘binaryitems’ to ‘bulkdata’.
· For non-dicom attachments, switch ‘type’ to ‘bucket’, remove API for creating buckets (this will be handled by the server – either admin, or on demand). look at S3 for API inspiration, e.g. access control
· “zip is the new multipart”
· Is changelog unnecessary – can simply use search with ‘since’ parameter? – what about delete… problem for external indexes
o Need to use ‘since’ and ‘until’ to apply to last modified.
· Study search – specify level of response – cursory (current), study (without series or normalized), series (without instances or normalized series attributes), instance (entire metadata)
o Do we support non-xml metadata? (multiple gpb, dicom, etc.)
o Still TBD is search fields
· Discussion of supplement 148 reopened the multipart-mime vs. zip… we may end up going back to multipart mime – this is the basis of MTOM (SOAP)
______________________________________________________________________________________________ | |
| Tim Dawson | Chief Architect | Office of the CTO 5850 Opus Parkway, Suite 300 l Minnetonka, MN 55343 |
A Toshiba Medical Systems Group Company | |
______________________________________________________________________________________________ | |
