1. MINT Working Group Jan 9-10 at Harris FBC Melbourne, FL

2. Agenda  Monday, Jan 9th  8:30 Badging/Breakfast  9:00 Overview (T. Culp)  9:15 MINT2.0 API Draft Final (T. Dawson)  11:30 Lunch  1:00 Open Items (All)  Replace Use Case  Update Use Case  Data Types  Image Object Change Management Image Object Change Management  UUIDs vs UIDs (CPack 64 CP 1156)CPack 64 CP 1156  4:00 Governance – Open Health Tools (J. Philbin)Open Health Tools  5:00 Adjourn  Tuesday, Jan 10th  8:30 Badging/Breakfast  9:00 Web Security for REST (T. Culp/ A. Patel)  10:30 Unfinished Business (All)  11:30 Lunch  1:00 Adjourn

3. MINT 2.0 API Decisions  Should “Create Study” allow a duplicate UID?  Should reject study or accept with an exception (202 status)  How do you distinguish Append from Replace?  Operator is a POST vs PUT. (Verified multipart PUT is possible.)  Does a study pushed to another MINT server retain the same UID?  Treat just like DICOM. Assume the UID is unique but provide business logic (outside MINT API) to disambiguate UID conflicts (like an internal Deriver 2.25.UUID).  What metadata accompanies an Append operation?  If content is application/dicom, then all the DICOM object metadata is sent.  If content is application/mint, normalized attributes are sent. Metadata must be re-normalized after the Append operation.

4. MINT 2.0 API Decisions  Should the MINT API include an admin interface?  Yes. A column was added to designate the administrator functions. The interface can be javascript wrapping these RESTful calls. Added placeholders for Undelete Study and Hard Delete Study.  Are the Cache/QC Operations sections defined sufficiently?  After reviewing the Caching operations, we expanded the lock resources to four separate URLs to make them resource based RESTful calls.  The QC Operations were changed to mirror the caching operations. This is potentially overkill since there is only 1 QC lock allowed at a time but decided to mirror the other structure for symmetry.  Decision was made to block both Read and Write operations to a study locked by QC.  Decision was made to establish a max expiration as a server side setting for any lock.

5. MINT 2.0 API Decisions  What are the parameters and content of the Changelog?  The Changelog parameters for pagination are: offset, limit, since, until.  Contents will be similar to current with the following changes:  A new parameter was added called coalesce that indicates whether the result should contain every version of a study within the search criteria or just the last.  UPDATE was split into REPLACE and APPEND.  Type will contain “DICOM” when the study contents have changed and the attachments “bucketName” when an attachment has been created, replaced, or deleted.  Should advanced Search operations just be deferred to QIDO?  Vital needs a way to find prior “relevant” studies which requires inspecting key tags.  Current API requires separate call to download metadata for each result – very expensive.  Add ?field=(g,e)&field=(g,e)… optional parameter to Search resource  Response returns existing xml with MINT metadata format embedded inside tags.  Decided to defer on decision to return tag names instead of tag numbers to make it human readable. Will use tag numbers for now since this is what the metadata contains.

6. MINT 2.0 API Decisions  UUIDs vs UIDs  CPack 64 Change Proposal 1156 suggests allowing derived UUIDs with a 2.25. prefix as an alternate mechanism for DICOM Study Instance UIDs  Decision to make {identifier} in MINT API resources always SIUIDs.  It’s suggested any UIDs generated by the MINTServer are Derived 2.25.UIDs. Traditional SIUIDs will also work although have a more likely chance of conflict.  Data Types  Changed the term “data” to “attachments”. It’s longer but more descriptive. docs was also considered but rejected because not all attachments are technically documents.  Followed the Amazon S3 Storage API convention and decided to use the term “bucket” instead of “namespace”. Recommend using domain or sub-domain names for bucket names to avoid conflicts (ie. vital.com, reports.vital.com, data.vital.com).  Buckets are a flat storage space.  Added resource for testing the existence of a bucketName or an object within a bucket.

7. Security Topics  Authentication  Authentication is orthogonal to API  MINT servers must support HTTP BASIC authorization.  Strongly recommend that MINT servers support  Digest Authorization  SSL Client Certificates  MINT servers can optionally support Sessions (ie. Kerberos, Shibboleth) and other authentication mechanisms  Other security topics discussed but not directly impacting API  Authorization  Discussed SAML, very SOAP specific; no recommendations at this time  Access Control  Privileges, groups, users, and data are all orthogonal  Potential Privileges: Create, Append, Modify, Delete  Potential Groups: Technologist, Clinician, Doctor, QC, Admin  On the wire  HTTPS, HTTP with encrypted payload

8. Open Items  Need to define an Exception Queue for results accepted with errors.  Revisit admin operations and verify we have them all identified.  Flush out the “Undelete Study” and “Hard Delete Study” operations.  Need to decide on metadata to capture for studies and attachments  Creation Time?  Modified Time?  Need to decide on “System Info” results  Timestamp?  Load information?  Property Bag?