MINT Meeting Agenda

1. MINT Meeting Agenda August 16-17, 2010

2. Monday, August 16, 2010 • 10:00 – 12:00 Overview and Demo • 12:00 – 1:00 Lunch • 1:00 – 3:00 Code and design walkthrough including implementation challenges • 3:00 – 3:15 Break • 3:15 – 5:30 Design meeting

3. Tuesday, August 17, 2010 • 8:00 – 12:00 Design meeting (continued) • 12:00 – 1:00 Lunch • 1:00 – 2:00 Roadmap • 2:00 – 3:00 RSNA demonstration planning • 3:00 Meeting ends

4. Demonstration • DICOM->MINT Create (series 1) • Clear Canvas (time to first image) • Single image at a time • Bulk loader • DICOM->MINT Update (series 2) • Clear Canvas MPR (time to last image) • Single image at a time • Bulk loader • MINT->DICOM • Conformance Test (Tim) • Vital Implementation

5. Design Issues • Unit and Integration Tests • Data Dictionary • Types (MIME) • Management • Versioning • Study Summary • Search Parameters • Bulk Binary Loading • file storage • partial data/sub-selection • Multi-part Mime as payload • Integration w/ MPI • Multiple Update Concurrency • Multi-frame handling • Study creation with missing/invalid fields • Part 10 information (and other 0002 info) • Security • Non-DICOM objects • De-identification • SDK design • Exception handling • Support for Multi-Frame • Comparisons after updates • Various representations (XML, GPB, JSON) • Other projects related to MINT?

6. Other MINT Issues/Questions • MINT Reference (overview, API, SDK…) • What about exceptions? we need to define them as part of MINT Standard. • Can we search using accession numbers? • Integration with MPI we need to modify the URI …/IPDI/LMRN/GUID

7. Multi-Frame Handling To handle multiple BIDs per attribute, a frameCount attribute will be present indicating the number of BIDs for that attribute. The BIDs will be consecutive starting with the bid in the bid attribute: <Attr tag="7fe00010" vr="OW" bid="1" frameCount=”10”/> BIDs 1-10 would represent each frame

8. Security / Auditing • Proposal #1 • Add XML element in changelog to indicate the user of the client. Up to MINT implementation to define how a client authenticates • Add XML element for the client to specify the end user (this is not guaranteed to be correct, but useful) • Define a HTTP header that can pass the end user identity for auditing purposes • Look at specifying how MINT servers should audit via ATNA (the exact message format/schema) • Document a cookbook recipe for how security could be implemented using MINT. This would include logging all activity to IHE ATNA audit log. Also include how fine grained security could be implemented

9. Multi-Update Concurrency • Add the baseline version # as part of the update message • Updates will fail if the baseline version # does not match current version #

10. Integration with MPI • Decision: Not a problem for MINT to solve – we allow searching on Patient ID / Issuer which is extracted from the DICOM Attributes • Clients should use PIX to resolve the different Patient ID / Issuers that it may need to search MINT with

11. Exception Handling • Use HTTP Error codes, need to define semantic meaning. If further specification for an HTTP Error code is needed, prefix the text message with a MINT standardized key.

12. De-Identification • Must have different uid’s (study, series, sop instance) • Must have different patient demographics • Must have different mint uuids • Jim Philbin to write up a proposal for this

13. Excluding Binary Items • When client requests all binary items for a given type, any excluded binary items will not be returned. If a client wants to get an excluded binary item, they will have to request it explicitly by its BID

14. SDK • Helper classes that would let you: • Add new instances • Delete instances • Modify attributes (patient name) • Load metadata for a study • Access binary items • Create a new study • Find a study • Direction – SDK will evolve as other MINT applications are built (e.g. QC, service tool, etc)

15. Needed • Utility to create the DICOM Data Dictionary automatically -> then we should use our DD to handle implicit. • DICOM people should publish DD in XML. • Should we use Proto-bufs for internal implementation. • Make the various representations lazy • How to handle updates

16. Supporting Part 10 Headers • We will store the Part 10 header in the metadata • Recommend that any updater of studies include Part 10 headers in the metadata • Rationale: More people will complain about it not being preserved than those that don’t want it

17. Implementation Challenges • Normalization algorithm- 1-pass or 2-pass

18. Bulk Binary Partial Load • Support both GET and POST

19. Unit and Integration Tests • Junit 4.0 • Run unit tests before checking software in • Integrate w/ Ant

20. Performance • Need cookbook that describes how to get maximum performance • HTTP Chunking on server side • Jumbo frames • OS TCP Buffer sizes • Size of reads on client • Size of writes on server

21. Version 1.0 Tasks • Unit tests • Integration test • Features: • Non-DICOM Proprietary types • Instructions for building, testing and configuring a download. • Binary download of MINT Server, DICOM->MINT Server and Clear Canvas client

22. High Level Decisions • REST interfaces only to return XML (no more XHTML) • GPB is supported for metadata only (for performance) • Drop support for JSON (XML is adequate) • All MINT Date/Time format is in UTC DICOM DT format (exception StudyDateTime for queries)

23. Data Dictionary • Need a document that defines DD and type creation • How to add types • Need to associate with a particular seriesInstance or SOPInstance • ** Document defining type definition • Define Use Cases (Jim P) • Define a type for Vital Volumes, AIM, MIME types • Sequence elements are atomic(?) • Management (get DICOM committee to take this over) • Versioning

24. DICOM Study Summary Fields • Patient Name • Patient DOB • Patient Sex • MRN Domain (IPID) • MRN • Study Date & Time • Issuer of Accession # • Accession # • # of series/objects • Modality • Series descriptor? • Issues: • Date & time problems • Time zone • Study summary served as xml • Study summary is all patient, study and series tags + # of instances (study level & series level) • No need for Summary in Data Dictionary

25. MINT Study Required Fields • Study UID

26. Study Queries • Study Instance UID • Patient ID + Patient ID Issuer • Accession Number + Accession Number Issuer • StudyDateTimeFrom + StudyDateTimeTo Date time searches will be inclusive of the day Time is not required in search values Date/Time format is in DICOM DT format If time is supplied, but no date, study date time queries will not work

27. MINT Study Search Results • Returned as XML • Data • MINT Study UUID • Last Update Date/Time

28. $MINTROOT/changelog • Each Entry • MINT Study UUID • Change Number • Last Update Date/Time • Type (e.g. DICOM, PDF, etc)

29. Root Study URL • List of all types in study

30. Other projects related to MINT? • MINT Proxy (federating MINT servers) • Local caching MINT server • Single MINT server proxy into DICOM archives • Anonymizing/de-identifiying MINT proxy • Storage of other data types in MINT • AIM, PDF, JPEG, PNG, TIFF, video, audio • XIP to MINT adapter • XDS Interface? • HIE Gateway across different enterprises with different patient identifiers – look at XDS model for this • QC Workstation / Toolkit (edit patient name, delete images, add images, split study, etc) • CSTORE SCP->MINT • CSTORE, CFIND, CMOVE SCU -> MINT Server • Simple viewer for web browser that is MINT enabled • Post processing example – listen for study changes and add content to server (e.g. generate JPEGs for Key Images) • Security cookbook – how to implement ACLs against MINT • Architecture cookbook – how to support MINT with a DICOM P10 archive

31. MINT Non Goals

32. RSNA Tasks • Performance numbers

33. Deidentification • IHE Defines this through TCE spec • Revisit with Jim Philbin tomorrow