Non-Patient Instance (NPI) Storage RESTful Service Overview
This comprehensive documentation describes a RESTful web service for Non-Patient Instances (NPIs) storage, retrieval, and search functionality. NPIs are diverse data objects such as color palettes, hanging protocols, and implant templates, distinct from patient-related information. The service allows clients to interact with NPIs efficiently using standardized transactions and search parameters, ensuring seamless data management. Retrieve, store, and search capabilities are outlined, emphasizing the unique resource structure and search attributes of NPIs compared to traditional patient-centric services.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
Supplement 194 Non-Patient Instance (NPI) Storage RESTful Service 1
Non-Patient Instance (NPI) This supplement defines a RESTful Web Service allowing a client to store, retrieve, and search for Non-Patient Instances (NPI) from a server. NPIs are composite IODs that are not related to patients. Examples are: Color Palettes Hanging Protocols Implant Templates Protocol Definitions Images of phantoms, QC targets, doorknob swab photos, etc., are not NPIs. They are expected to be handled as pseudo-patients, because they incorporate the patient/study hierarchy. 2
Goals Create a RESTful service that can Store, Retrieve, and Search for NPI Instances Use the RS Studies Service as a model for the transactions, and try to deviate as little as possible. 3
NPI Resources The URI Template for NPI Resources is: /{npi-name}{/uid} Where npi-name = "color-palette" =/ "hanging-protocol" =/ "implant-template" =/ uid = dicom-uid 4
Query Parameters Acceptable Media Type and Character Set accept-qp = "accept=" media-type charset-qp = "charset=" charset The Accept Query Parameters may be used by all transactions Search match* = (attribute = value)* include = attribute* page = "offset" = uint =/ "limit" = uint The Search Query Parameters may only be used with the Search Transaction 5
Transactions Retrieve Capabilities Retrieves the Capabilities Description document from the origin server. Retrieve GET /{type}/{uid} {?accept-parameters*} Retrieves a single NPI Instance Store POST /{type}{/uid} {?accept-parameters*} Stores one or more NPI Instances Search POST /{type}?{?accept-parameters*} {?search-parameters*} Searches for matching NPI Instances. In stances on an NPI origin server. The parameters are the standard search parameters: match*, include, offset, and limit 6
NPI Service vs Studies Service Similarities Same transactions, except no NPI Retrieve Rendered Same Query Parameters Both can store multiple instances Differences Target Resources: NPI vs Studies Resource Hierarchy flat vs tree structured Search Attributes Retrieve single instance vs multiple instances Sup194: Non-Patient Instance Storage (NPIS) RESTful Service 7
Media Types The NPI Service only supports DICOM Media Types: application/dicom application/dicom+json application/dicom+xml required default optional 8
