Transcript MINT Meeting Agenda - medical-imaging-network

MINT Meeting Agenda
August 16-17, 2010
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
Tuesday, August 17, 2010
•
•
•
•
•
8:00 – 12:00
12:00 – 1:00
1:00 – 2:00
2:00 – 3:00
3:00
Design meeting (continued)
Lunch
Roadmap
RSNA demonstration planning
Meeting ends
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
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?
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
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
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
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 #
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
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.
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
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
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)
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
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
Implementation Challenges
• Normalization algorithm- 1-pass or 2-pass
Bulk Binary Partial Load
• Support both GET and POST
Unit and Integration Tests
• Junit 4.0
• Run unit tests before checking software in
• Integrate w/ Ant
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
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
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)
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
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
MINT Study Required Fields
• Study UID
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
MINT Study Search Results
• Returned as XML
• Data
– MINT Study UUID
– Last Update Date/Time
$MINTROOT/changelog
• Each Entry
– MINT Study UUID
– Change Number
– Last Update Date/Time
– Type (e.g. DICOM, PDF, etc)
Root Study URL
• List of all types in study
Other projects related to MINT?
•
MINT Proxy (federating MINT servers)
–
–
•
•
Anonymizing/de-identifiying MINT proxy
Storage of other data types in MINT
–
•
•
•
•
•
•
•
•
•
•
Local caching MINT server
Single MINT server proxy into DICOM archives
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
MINT Non Goals
RSNA Tasks
• Performance numbers
Deidentification
• IHE Defines this through TCE spec
• Revisit with Jim Philbin tomorrow