Resource type: imagingstudy

Description

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.

Elements

PathShortDefinitionComments
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.
identifierIdentifiers for the whole studyIdentifiers 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.
statusregistered | available | cancelled | entered-in-error | unknownThe 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.
modalityAll series modality if actual acquisition modalitiesA 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).
subjectWho or what is the subject of the studyThe 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.
encounterEncounter with which this imaging study is associatedThe 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).
startedWhen the study was startedDate and time the study started.
basedOnRequest fulfilledA list of the diagnostic requests that resulted in this imaging study being performed.
referrerReferring physicianThe requesting/referring physician.
interpreterWho interpreted imagesWho read the study and interpreted the images or other content.
endpointStudy access endpointThe 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.
numberOfSeriesNumber of Study Related SeriesNumber 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.
numberOfInstancesNumber of Study Related InstancesNumber 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.
procedureReferenceThe performed Procedure referenceThe procedure which this ImagingStudy was part of.
procedureCodeThe performed procedure codeThe code for the performed procedure type.
locationWhere ImagingStudy occurredThe principal physical location where the ImagingStudy was performed.
reasonCodeWhy the study was requestedDescription of clinical condition indicating why the ImagingStudy was requested.
reasonReferenceWhy was study performedIndicates another resource whose existence justifies this Study.
noteUser-defined commentsPer 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.
descriptionInstitution-generated descriptionThe Imaging Manager description of the study. Institution-generated description or classification of the Study (component) performed.
seriesEach study has one or more series of instancesEach study has one or more series of images or other content.
series.idUnique id for inter-element referencingUnique id for the element within a resource (for internal references). This may be any string value that does not contain spaces.
series.extensionAdditional content defined by implementationsMay 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.modifierExtensionExtensions that cannot be ignored even if unrecognizedMay 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.uidDICOM Series Instance UID for the seriesThe 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.numberNumeric identifier of this seriesThe numeric identifier of this series in the study.
series.modalityThe modality of the instances in the seriesThe modality of this series sequence.
series.descriptionA short human readable summary of the seriesA description of the series.
series.numberOfInstancesNumber of Series Related InstancesNumber 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.endpointSeries access endpointThe 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.bodySiteBody part examinedThe 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.lateralityBody part lateralityThe 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.specimenSpecimen imagedThe specimen imaged, e.g., for whole slide imaging of a biopsy.
series.startedWhen the series startedThe date and time the series was started.
series.performerWho performed the seriesIndicates 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.idUnique id for inter-element referencingUnique id for the element within a resource (for internal references). This may be any string value that does not contain spaces.
series.performer.extensionAdditional content defined by implementationsMay 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.modifierExtensionExtensions that cannot be ignored even if unrecognizedMay 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.functionType of performanceDistinguishes the type of involvement of the performer in the series.
series.performer.actorWho performed the seriesIndicates who or what performed the series.
series.instanceA single SOP instance from the seriesA single SOP instance within the series, e.g. an image, or presentation state.
series.instance.idUnique id for inter-element referencingUnique id for the element within a resource (for internal references). This may be any string value that does not contain spaces.
series.instance.extensionAdditional content defined by implementationsMay 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.modifierExtensionExtensions that cannot be ignored even if unrecognizedMay 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.uidDICOM SOP Instance UIDThe 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.sopClassDICOM class typeDICOM instance type.
series.instance.numberThe number of this instance in the seriesThe number of instance in the series.
series.instance.titleDescription of instanceThe description of the instance.Particularly for post-acquisition analytic objects, such as SR, presentation states, value mapping, etc.

Scope and Usage

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.

Boundaries and Relationships

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.



Implementation Notes

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.

WADO-RS

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:

we can construct the WADO-RS URL to issue an HTTP GET for a native DICOM PS3.10 instance file (if consistent with the Accept header):


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.

WADO-URI

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:

we can construct the WADO-URI URL to issue an HTTP GET for a native DICOM PS3.10 instance file (if consistent with the Accept header):


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&region=0,0,0.5,1 

For further details on DICOM WADO-URI capabilities including additional rendering parameters, see DICOM PS 3.18.

IID

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:

we can construct the IID URL to invoke a diagnostic quality viewer on the indicated study:


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.

Use Case

EHR access to imaging studies

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.

Comprehensive Imaging Scheduled Workflow

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.

Search Parameters

basedonThe order for the imageImagingStudy.basedOn
bodysiteThe body site studiedImagingStudy.series.bodySite
dicom-classThe type of the instanceImagingStudy.series.instance.sopClass
encounterThe context of the studyImagingStudy.encounter
endpointThe endpoint for the study or seriesImagingStudy.endpoint | ImagingStudy.series.endpoint
instanceSOP Instance UID for an instanceImagingStudy.series.instance.uid
modalityThe modality of the seriesImagingStudy.series.modality
performerThe person who performed the studyImagingStudy.series.performer.actor
reasonThe reason for the studyImagingStudy.reasonCode
seriesDICOM Series Instance UID for a seriesImagingStudy.series.uid
startedWhen the study was startedImagingStudy.started
statusThe status of the studyImagingStudy.status
subjectWho the study is aboutImagingStudy.subject

Extension Definitions

These are extension definitions for this resource defined by the spec