Path | Short | Definition | Comments |
---|---|---|---|
A set of images produced in single study (one or more series of references images) | Representation of the content produced in a DICOM imaging study. A study comprises a set of series, each of which includes a set of Service-Object Pair Instances (SOP Instances - images or other data) acquired or produced in a common context. A series is of only one modality (e.g. X-ray, CT, MR, ultrasound), but a study may have multiple series of different modalities. | ||
identifier | Identifiers for the whole study | Identifiers for the ImagingStudy such as DICOM Study Instance UID, and Accession Number. | See discussion under [Imaging Study Implementation Notes](imagingstudy.html#notes) for encoding of DICOM Study Instance UID. Accession Number should use ACSN Identifier type. |
status | registered | available | cancelled | entered-in-error | unknown | The current state of the ImagingStudy. | Unknown does not represent "other" - one of the defined statuses must apply. Unknown is used when the authoring system is not sure what the current status is. |
modality | All series modality if actual acquisition modalities | A list of all the series.modality values that are actual acquisition modalities, i.e. those in the DICOM Context Group 29 (value set OID 1.2.840.10008.6.1.19). | |
subject | Who or what is the subject of the study | The subject, typically a patient, of the imaging study. | QA phantoms can be recorded with a Device; multiple subjects (such as mice) can be recorded with a Group. |
encounter | Encounter with which this imaging study is associated | The healthcare event (e.g. a patient and healthcare provider interaction) during which this ImagingStudy is made. | This will typically be the encounter the event occurred within, but some events may be initiated prior to or after the official completion of an encounter but still be tied to the context of the encounter (e.g. pre-admission test). |
started | When the study was started | Date and time the study started. | |
basedOn | Request fulfilled | A list of the diagnostic requests that resulted in this imaging study being performed. | |
referrer | Referring physician | The requesting/referring physician. | |
interpreter | Who interpreted images | Who read the study and interpreted the images or other content. | |
endpoint | Study access endpoint | The network service providing access (e.g., query, view, or retrieval) for the study. See implementation notes for information about using DICOM endpoints. A study-level endpoint applies to each series in the study, unless overridden by a series-level endpoint with the same Endpoint.connectionType. | Typical endpoint types include DICOM WADO-RS, which is used to retrieve DICOM instances in native or rendered (e.g., JPG, PNG), formats using a RESTful API; DICOM WADO-URI, which can similarly retrieve native or rendered instances, except using an HTTP query-based approach; DICOM QIDO-RS, which allows RESTful query for DICOM information without retrieving the actual instances; or IHE Invoke Image Display (IID), which provides standard invocation of an imaging web viewer. |
numberOfSeries | Number of Study Related Series | Number of Series in the Study. This value given may be larger than the number of series elements this Resource contains due to resource availability, security, or other factors. This element should be present if any series elements are present. | |
numberOfInstances | Number of Study Related Instances | Number of SOP Instances in Study. This value given may be larger than the number of instance elements this resource contains due to resource availability, security, or other factors. This element should be present if any instance elements are present. | |
procedureReference | The performed Procedure reference | The procedure which this ImagingStudy was part of. | |
procedureCode | The performed procedure code | The code for the performed procedure type. | |
location | Where ImagingStudy occurred | The principal physical location where the ImagingStudy was performed. | |
reasonCode | Why the study was requested | Description of clinical condition indicating why the ImagingStudy was requested. | |
reasonReference | Why was study performed | Indicates another resource whose existence justifies this Study. | |
note | User-defined comments | Per the recommended DICOM mapping, this element is derived from the Study Description attribute (0008,1030). Observations or findings about the imaging study should be recorded in another resource, e.g. Observation, and not in this element. | |
description | Institution-generated description | The Imaging Manager description of the study. Institution-generated description or classification of the Study (component) performed. | |
series | Each study has one or more series of instances | Each study has one or more series of images or other content. | |
series.id | Unique id for inter-element referencing | Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces. | |
series.extension | Additional content defined by implementations | May be used to represent additional information that is not part of the basic definition of the element. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. | There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone. |
series.modifierExtension | Extensions that cannot be ignored even if unrecognized | May be used to represent additional information that is not part of the basic definition of the element and that modifies the understanding of the element in which it is contained and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions. Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself). | There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone. |
series.uid | DICOM Series Instance UID for the series | The DICOM Series Instance UID for the series. | See [DICOM PS3.3 C.7.3](http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.3.html). |
series.number | Numeric identifier of this series | The numeric identifier of this series in the study. | |
series.modality | The modality of the instances in the series | The modality of this series sequence. | |
series.description | A short human readable summary of the series | A description of the series. | |
series.numberOfInstances | Number of Series Related Instances | Number of SOP Instances in the Study. The value given may be larger than the number of instance elements this resource contains due to resource availability, security, or other factors. This element should be present if any instance elements are present. | |
series.endpoint | Series access endpoint | The network service providing access (e.g., query, view, or retrieval) for this series. See implementation notes for information about using DICOM endpoints. A series-level endpoint, if present, has precedence over a study-level endpoint with the same Endpoint.connectionType. | Typical endpoint types include DICOM WADO-RS, which is used to retrieve DICOM instances in native or rendered (e.g., JPG, PNG) formats using a RESTful API; DICOM WADO-URI, which can similarly retrieve native or rendered instances, except using an HTTP query-based approach; and DICOM QIDO-RS, which allows RESTful query for DICOM information without retrieving the actual instances. |
series.bodySite | Body part examined | The anatomic structures examined. See DICOM Part 16 Annex L (http://dicom.nema.org/medical/dicom/current/output/chtml/part16/chapter_L.html) for DICOM to SNOMED-CT mappings. The bodySite may indicate the laterality of body part imaged; if so, it shall be consistent with any content of ImagingStudy.series.laterality. | |
series.laterality | Body part laterality | The laterality of the (possibly paired) anatomic structures examined. E.g., the left knee, both lungs, or unpaired abdomen. If present, shall be consistent with any laterality information indicated in ImagingStudy.series.bodySite. | |
series.specimen | Specimen imaged | The specimen imaged, e.g., for whole slide imaging of a biopsy. | |
series.started | When the series started | The date and time the series was started. | |
series.performer | Who performed the series | Indicates who or what performed the series and how they were involved. | If the person who performed the series is not known, their Organization may be recorded. A patient, or related person, may be the performer, e.g. for patient-captured images. |
series.performer.id | Unique id for inter-element referencing | Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces. | |
series.performer.extension | Additional content defined by implementations | May be used to represent additional information that is not part of the basic definition of the element. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. | There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone. |
series.performer.modifierExtension | Extensions that cannot be ignored even if unrecognized | May be used to represent additional information that is not part of the basic definition of the element and that modifies the understanding of the element in which it is contained and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions. Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself). | There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone. |
series.performer.function | Type of performance | Distinguishes the type of involvement of the performer in the series. | |
series.performer.actor | Who performed the series | Indicates who or what performed the series. | |
series.instance | A single SOP instance from the series | A single SOP instance within the series, e.g. an image, or presentation state. | |
series.instance.id | Unique id for inter-element referencing | Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces. | |
series.instance.extension | Additional content defined by implementations | May be used to represent additional information that is not part of the basic definition of the element. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. | There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone. |
series.instance.modifierExtension | Extensions that cannot be ignored even if unrecognized | May be used to represent additional information that is not part of the basic definition of the element and that modifies the understanding of the element in which it is contained and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions. Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself). | There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone. |
series.instance.uid | DICOM SOP Instance UID | The DICOM SOP Instance UID for this image or other DICOM content. | See [DICOM PS3.3 C.12.1](http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.12.html#sect_C.12.1). |
series.instance.sopClass | DICOM class type | DICOM instance type. | |
series.instance.number | The number of this instance in the series | The number of instance in the series. | |
series.instance.title | Description of instance | The description of the instance. | Particularly for post-acquisition analytic objects, such as SR, presentation states, value mapping, etc. |
ImagingStudy provides information on a DICOM imaging study, and the series and imaging objects in that study. It also provides information on how to retrieve that information (in a native DICOM format, or in a rendered format, such as JPEG). ImagingStudy is used to make available information about all parts of a single DICOM study.
This resource provides mappings of its elements to DICOM attributes. DICOM attributes are identified by a 32-bit tag, presented in canonical form as two four-digit hexadecimal values within parentheses and separated by a comma, e.g. (0008,103E). The name and value representation (data type) of each attribute can be found in DICOM Part 6 Data Dictionary. The use of the attributes in the context of information objects, including detailed description of use, can be found in DICOM Part 3 Information Object Definitions . Attributes used in the DICOM query information models, such as "Number of Instances in Study", can be found in DICOM Part 4 Annex C.
ImagingStudy provides access to significant DICOM information but will only eliminate the need for DICOM query (e.g., QIDO-RS) in the simplest cases. The DICOM instances are not stored in the ImagingStudy resource; use of a DICOM WADO-RS server or other storage mechanism is needed.
An ImagingStudy SHALL reference one DICOM Study, and MAY reference a subset of that Study. More than one ImagingStudy MAY reference the same DICOM Study or different subsets of the same DICOM Study.
ImagingStudy is used for DICOM imaging and associated information. Use Media to track non-DICOM images, video, or audio. Binary can be used to store arbitrary content. DocumentReference allow indexing and retrieval of clinical “documents” with relevant metadata.
A referenced DICOM SOP instance could be:
DICOM Series Instance UID and SOP Instance UID use the id
datatype, and are encoded directly. For example, an image with SOP Instance UID of 2.16.124.113543.1154777499.30246.19789.3503430045.1.1
is encoded in ImagingStudy.series.instance.uid
as “2.16.124.113543.1154777499.30246.19789.3503430045.1.1”
.
The ImagingStudy’s DICOM Study Instance UID is encoded in the ImagingStudy.identifier
element, which is of the Identifier
datatype. When encoding a DICOM UID in an Identifier
datatype, use the Identifier system of “urn:dicom:uid”
, and prefix the UID value with “urn:oid:”
. Therefore, an ImagingStudy with DICOM Study Instance UID of 2.16.124.113543.1154777499.30246.19789.3503430046
is encoded as:
"identifier":{ "system":"urn:dicom:uid", "value":"urn:oid:2.16.124.113543.1154777499.30246.19789.3503430046" }
The study accession number can also be encoded as an Identifier
using the “ACSN”
identifier type, as follows:
"identifier":{ "type" : { "coding" : [ { "system" : "http://terminology.hl7.org/CodeSystem/v2-0203", "code" : "ACSN" } ] }, "system":"http://ginormoushospital.org/accession", "value":"GH334103" }
The ImagingStudy.endpoint elements and ImagingStudy.series.endpoint elements indicate network services that can be used to access the studies, series, or instances; for example, a DICOM WADO-RS server. An ImagingStudy.series.endpoint of a particular Endpoint.connectionType provides that service for that series, and all contained instances. An ImagingStudy.endpoint of a particular connection type provides that service for all series in that study that do not have a specified Endpoint of that type, and their contained instances. That is, an ImagingStudy.series.endpoint overrides an ImagingStudy.endpoint of the same connection type. Systems can determine if a particular study, series, or instance is available or offline by interacting with the endpoint. Since each study, or individual series of a study can be stored on different imaging archive servers, per-series endpoints are required. For the identified services and use cases, all instances within a series would be stored together, and thus instance-level endpoints are not defined.
Different Endpoint connection types may have different capabilities, protocols or requirements; and the specified
Endpoint.address
may require manipulation. See below for the details on use of imaging-related Endpoint connection types.
An Endpoint.connectionType
of code dicom-wado-rs
, system http://terminology.hl7.org/CodeSystem/endpoint-connection-type
,
identifies a DICOM WADO-RS service. The Endpoint.address
identifies the HTTP(S) service base url.
That is, only the scheme, authority and path are included. Sub-services, such as study
, shall not be specified.
The path shall not contain a trailing slash.
The DICOM WADO-RS (Web Access to DICOM Objects, RESTful mode) service uses a RESTful approach to instance retrieval.
This service allows for retrieval of native DICOM SOP instances, or instances “rendered” into other formats, including
JPEG and MPEG. The media type of a response is specified by the request Accept header (preferred); or, by the accept
query parameters. Supported media types depend on the capabilities of the WADO-RS server and the classification of the instance
as “single frame,” “multi-frame,” “video,” “text,” or “other.” The WADO-RS service also allows retrieval of study
or series level information.
The path to retrieve a DICOM instance is constructed by appending the appropriate sub-resource paths to the Endpoint.address
value.
For example, using the following information in a fictional ImagingStudy resource:
“https://pacs.hospital.org/wado-rs”
found in an ImagingStudy.endpoint.address
,“urn:oid:1.2.250.1.59.40211.12345678.678910”
found in an ImagingStudy.identifier
having Identifier.system
of “urn:dicom:uid”
,“1.2.250.1.59.40211.789001276.14556172.67789”
found in ImagingStudy.series.uid
, and“1.2.250.1.59.40211.2678810.87991027.899772.2”
found in ImagingStudy.series.instance.uid
https://pacs.hospital.org/wado-rs/studies/1.2.250.1.59.40211.12345678.678910/series/1.2.250.1.59.40211.789001276.14556172.67789/instances/1.2.250.1.59.40211.2678810.87991027.899772.2
Query parameters on the "rendered" sub-resource can control other aspects of the rendering including: the rendered dimensions, the quality (compression ratio), the region of interest to render, the brightness/contrast (window center/width) adjustments, and whether to “burn” patient or study demographics into the rendered result. Specific frames of a multi-frame instance may be retrieved using the frames sub-resource.
For example, provided the Accept header indicates a preference for image/jpeg, the example above can be extended with parameters that cause a JPEG thumbnail (100 columns by 100 rows) of a region extending from the top-left corner of the original image, across 1000 and down 3000 pixels, to be retrieved (additional sub-resource and parameters emphasized):
https://pacs.hospital.org/wado-rs/studies/1.2.250.1.59.40211.12345678.678910/series/1.2.250.1.59.40211.789001276.14556172.67789/instances/1.2.250.1.59.40211.2678810.87991027.899772.2/rendered?viewport=100,100,0,0,1000,3000
For further details on DICOM WADO-RS capabilities including additional rendering parameters, see DICOM PS 3.18.
An Endpoint.connectionType
of code dicom-wado-uri
, system http://terminology.hl7.org/CodeSystem/endpoint-connection-type
,
identifies a DICOM WADO-URI service. The Endpoint.address
identifies the HTTP(S) service base url.
That is, only the scheme, authority and path are included. Neither a question mark (“?”) nor any query parameters shall be included.
The DICOM WADO-URI (Web Access to DICOM Objects, URI mode) service uses HTTP query parameter syntax. This service allows for retrieval of native DICOM instances, or instances “rendered” into other formats, including JPEG and MPEG. The media type of a response is specified by the request Accept header (preferred); or, by the contentType query parameter. Supported media types depend on the classification of the instance as “single frame,” “multi-frame,” “video,” “text,” or “other.”
The query to retrieve a DICOM instance is constructed by appending the appropriate query parameters to the Endpoint.address
value.
For example, using the following information in a fictional ImagingStudy resource:
“https://pacs.hospital.org/wado-uri”
found in an ImagingStudy.endpoint.address
,“urn:oid:1.2.250.1.59.40211.12345678.678910”
found in an ImagingStudy.identifier
having Identifier.system
of “urn:dicom:uid”
,“1.2.250.1.59.40211.789001276.14556172.67789”
found in ImagingStudy.series.uid
, and“1.2.250.1.59.40211.2678810.87991027.899772.2”
found in ImagingStudy.series.instance.uid
https://pacs.hospital.org/wado-uri?requestType=WADO&studyUID=1.2.250.1.59.40211.12345678.678910&seriesUID=1.2.250.1.59.40211.789001276.14556172.67789&objectUID=1.2.250.1.59.40211.2678810.87991027.899772.2
Additional query parameters can control other aspects of the rendering including rendered dimensions, quality (compression ratio), the region of interest within the image to render, brightness/contrast (window center/width) adjustments, whether to “burn” patient or study demographics into the rendered result, and which frame of a multi-frame instance to retrieve.
For example, provided the Accept header indicates a preference for image/jpeg, the example above can be extended with parameters that cause a JPEG thumbnail (100 columns by 100 rows) of the left half of the image to be retrieved (additional parameters emphasized):
https://pacs.hospital.org/wado-uri?requestType=WADO&studyUID=1.2.250.1.59.40211.12345678.678910&seriesUID=1.2.250.1.59.40211.789001276.14556172.67789&objectUID=1.2.250.1.59.40211.2678810.87991027.899772.2&rows=100&columns=100®ion=0,0,0.5,1
For further details on DICOM WADO-URI capabilities including additional rendering parameters, see DICOM PS 3.18.
An Endpoint.connectionType
of code ihe-iid
, system http://terminology.hl7.org/CodeSystem/endpoint-connection-type
,
identifies an IHE Invoke Image Display (IID) service. The Endpoint.address
identifies the HTTP(S) service base url.
That is, only the scheme, authority and path are included. Neither a question mark (“?”) nor any query parameters shall be included.
The IHE Invoke Image Display (IID) service provides a standardized mechanism to launch a viewer in a particular study context. (IID also supports invoking a particular patient context, but that is not profiled here.) An IID-type Endpoint should be used only at the study level. As well as invoking the viewer on a particular study, query parameters can request particular viewer capabilities, image quality, and more.
To launch a viewer, append the appropriate query parameters to Endpoint.address
value.
For example, using the following information in a fictional ImagingStudy resource:
“https://pacs.hospital.org/IHEInvokeImageDisplay”
found in an ImagingStudy.endpoint.address
,“urn:oid:1.2.250.1.59.40211.12345678.678910”
found in an ImagingStudy.identifier
having Identifier.system
of “urn:dicom:uid”
,https://pacs.hospital.org/IHEInvokeImageDisplay?requestType=STUDY&studyUID=1.2.250.1.59.40211.12345678.678910&diagnosticQuality=true
For further details on IHE Invoke Image Display capabilities including additional parameters, see the IHE Technical Frameworks, or the introduction on the IHE IID Profile Wiki.
Amy, a family physician, would like to see a list of available studies for her patient, Alex. Her EHR client makes a FHIR call for all ImagingStudy objects available for Alex. In the response, she is able to see the study date, procedure, modality, and accession number, for each study returned. There is enough information provided in the response to obtain a thumbnail via a WADO-RS call, or to launch a viewer using an IHE Radiology - Invoke Image Display (IID) profile call using the url elements found in the ImagingStudy.
Joe Angina complains of shortness of breath and occasional chest pain to his primary care physician, Dr. Pat Down at Local MultiClinic, who orders a stress echocardiogram; the order is created as a FHIR Task resource to manage the workflow, with a link to a ServiceRequest resource with the details of the request. The order is scheduled and assigned to cardiologist Dr. Art Skann, also at Local MultiClinic.
On the scheduled day of the exam, Joe arrives at the echo lab to meet with Dr. Skann and have the study done. Dr. Skann’s workstation shows the daily list of Task, and he follows the link to retrieve the ServiceRequest. (He may follow the links through the referenced Patient resource to access Joe’s electronic medical record, but that is not the concern of this storyboard.)
The Task and ServiceRequest has been transcoded to a DICOM Modality Worklist Scheduled Procedure Step, and in the echo lab the equipment has downloaded the Modality Worklist. The study is performed, and the acquired images and sonographer’s preliminary measurements are stored in the Local MultiClinic Picture Archiving and Communication System (PACS). The PACS creates an ImagingStudy resource for each study it manages.
Dr. Skann interprets the study on a PACS workstation, and he selects two key image frames to be included in the diagnostic report; this selection is stored back to the PACS as a DICOM Key Object Selection with the title "For Report Attachment", and the PACS makes it available (transcodes it) as a FHIR ImagingStudy resource. Dr. Skann dictates the report using a structured data entry report writing program, including a recommendation for a cardiac catheterization procedure, and signs it. The report writing program formats the report as a CDA document, retrieves the ImagingStudy resource, and inserts the referenced key images into the report.
Dr. Down meets again with Joe, and they review the results of the stress test. Joe has a question about the findings that the key images in the report do not show, so Dr. Down uses the Local MultiClinic EMR to query the PACS for the full ImagingStudy resource and uses the references there to open an image display for the full study. Joe agrees to proceed to catheterization, and Dr. Down sends a referral to the Ginormous University Hospital cath department and triggers the PACS to share the echo study through the Metropolitan Health Information Exchange.
The PACS creates an imaging study as an ImagingStudy resource, which includes all the images but excludes the sonographer’s preliminary measurements (which as a matter of policy are not shared outside the Local MultiClinic). The imaging study is published to the Metro HIE. (In accordance with IHE XDS-I, the images themselves are not directly published to the HIE, but available for on-demand retrieval from the PACS.)
At Ginormous Hospital, Dr. Cora Plummer receives the cath referral, and looks up the study in the Metro HIE registry. She retrieves the study ImagingStudy, and uses it to access the shared images, which she uses to prepare for the cath procedure.
basedon | The order for the image | ImagingStudy.basedOn |
bodysite | The body site studied | ImagingStudy.series.bodySite |
dicom-class | The type of the instance | ImagingStudy.series.instance.sopClass |
encounter | The context of the study | ImagingStudy.encounter |
endpoint | The endpoint for the study or series | ImagingStudy.endpoint | ImagingStudy.series.endpoint |
instance | SOP Instance UID for an instance | ImagingStudy.series.instance.uid |
modality | The modality of the series | ImagingStudy.series.modality |
performer | The person who performed the study | ImagingStudy.series.performer.actor |
reason | The reason for the study | ImagingStudy.reasonCode |
series | DICOM Series Instance UID for a series | ImagingStudy.series.uid |
started | When the study was started | ImagingStudy.started |
status | The status of the study | ImagingStudy.status |
subject | Who the study is about | ImagingStudy.subject |