This page is part of the FHIR Specification (v3.0.2: STU 3). The current version which supercedes this version is 4.0.1 . For a full list of available versions, see the Directory of published versions

• Content
• Examples
• Detailed Descriptions
• Mappings
• Profiles & Extensions
• R2 R3 Conversions

10.3 10.4 Resource ImagingStudy - Content

Imaging Integration Work Group

Maturity Level : 3

Trial Use

Security Category : Patient

Compartments : Patient

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.

10.4.3 References

This resource is referenced by ChargeItem , ClinicalImpression , DiagnosticReport and ImagingManifest Observation .

This resource implements the Event pattern.

10.3.3 10.4.4 Resource Content

 

Alternate See the Profiles & Extensions and the alternate definitions: Master Definition ( XML , + JSON ), , XML Schema / Schematron (for ) + JSON Schema , ShEx (for Turtle ) + see the extensions , the spreadsheet version & the dependency analysis a

10.3.3.1 10.4.4.1 Terminology Bindings

ImagingStudy.availability ImagingStudy.series.availability ImagingStudy.modalityList ImagingStudy.series.modality ImagingStudy.procedureCode

Path	Definition	Type	Reference
ImagingStudy.status	Availability The status of the resource ImagingStudy.	Required	InstanceAvailability ImagingStudyStatus
ImagingStudy.modality	Type of acquired data in the instance instance.	Extensible	Acquisition Modality Codes http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_33.html
ImagingStudy.procedure.value[x]	The performed procedure type type.	Example Extensible	Procedure Codes (SNOMED CT) http://loinc.org/download/loincrsna-radiology-playbook-file/
ImagingStudy.reason	The reason for the study study.	Example	Procedure Reason Codes ProcedureReasonCodes
ImagingStudy.series.modality	Type of acquired data in the instance.	Extensible	http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_33.html
ImagingStudy.series.bodySite	Codes describing anatomical locations. May include laterality.	Example	SNOMED CT Body Structures SNOMEDCTBodyStructures
ImagingStudy.series.laterality	Codes describing body site laterality (left, right, etc.).	Example	Laterality http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_244.html
ImagingStudy.series.performer.function	The type of involvement of the performer.	Extensible	ImagingStudySeriesPerformerFunction
ImagingStudy.series.instance.sopClass	The sopClass for the instance.	Extensible	http://dicom.nema.org/medical/dicom/current/output/chtml/part04/sect_B.5.html#table_B.5-1

10.3.3.2

10.4.4.2 Implementation Notes

A referenced DICOM SOP instance could be:

• A single- or multi-frame, still or video image captured by a variety of imaging modalities, such as X-ray, MR, and ultrasound;
• A set of various presentation parameters, including annotation and markup;
• A set of measurements or a report, including radiation dose report and CAD analysis;
• An encapsulated PDF or CDA document;
• A list of instances, such as key “of interest” images, or instances to be “deleted”; or
• Other DICOM content.

DICOM Series Instance UID values follow and SOP Instance UID use the FHIR convention of expressing UIDs as URNs. 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 1.2.250.1.59.40211.12345678.678910 2.16.124.113543.1154777499.30246.19789.3503430046 is expressed 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 “urn:oid:1.2.250.1.59.40211.12345678.678910” . 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 ImagingManifest.study.endpoint ImagingStudy.endpoint elements and ImagingManifest.study.series.endpoint 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 ImagingManifest.study.series.endpoint ImagingStudy.series.endpoint of a particular Endpoint.connectionType provides that service for that series, and all contained instances. An ImagingManifest.study.endpoint ImagingStudy.endpoint of a particularconnection 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 ImagingManifest.study.series.endpoint ImagingStudy.series.endpoint overrides a ImagingManifest.study.endpoint an ImagingStudy.endpoint of the same connection type. (Since 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.) defined.

Different Endpoint connection types may have different capabilities, protocols or requirements; and the specified Endpoint.url Endpoint.address may require manipulation. For See below for the details on use of imaging-related Endpoint connection types, See below for details. types.

10.3.3.2.1 10.4.4.2.1 WADO-RS

An Endpoint.connectionType of code dicom-wado-rsi dicom-wado-rs , system http://hl7.org/fhir/endpoint-connection-type 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, 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, a native DICOM PS3.10 instance file can be retrieved (if consistent with using the Accept header) by performing a GET on a URL constructed from following information in a Endpoint.address fictional ImagingStudy resource:

• the WADO-RS service base url of “https://pacs.hospital.org/wado-rs” found in an ImagingStudy.endpoint.address ,
• the study.uid value DICOM Study Instance UID of “urn:oid:1.2.250.1.59.40211.12345678.678910” “1.2.250.1.59.40211.12345678.678910” found in an ImagingStudy.identifier having Identifier.system of “urn:dicom:uid” , study.series.uid value
• the DICOM Series Instance UID of “urn:oid:1.2.250.1.59.40211.789001276.14556172.67789” “1.2.250.1.59.40211.789001276.14556172.67789” found in ImagingStudy.series.uid , and study.series.instance.uid value
• the DICOM SOP Instance UID of “urn:oid:1.2.250.1.59.40211.2678810.87991027.899772.2” : “1.2.250.1.59.40211.2678810.87991027.899772.2” found in ImagingStudy.series.instance.uid

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 (rendered to a size of 400 columns by 100 400 rows) of a region extending from the top-left corner of the original image, across image to 1000 pixels across and down 3000 pixels, pixels right, 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

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=400,400,0,0,1000,3000

If the WADO-RS service supports the DICOMweb thumbnail resource, a representative image can be requested, for example, to display alongside the study. The URL would look as follows:

https://pacs.hospital.org/wado-rs/studies/1.2.250.1.59.40211.12345678.678910/thumbnail

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

10.3.3.2.2

10.4.4.2.2 WADO-URI

An Endpoint.connectionType of code dicom-wado-uri , system http://hl7.org/fhir/endpoint-connection-type 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 quetstion 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.url . Endpoint.address value.

For example, a native DICOM PS3.10 instance file can be retrieved (if consistent with using the Accept header) by performing a GET on a URL constructed from following information in a Endpoint.address.url fictional ImagingStudy resource:

• the WADO-URI service base url of “https://pacs.hospital.org/wado-uri” found in an ImagingStudy.endpoint.address ,
• the study.uid value DICOM Study Instance UID of “urn:oid:1.2.250.1.59.40211.12345678.678910” 1.2.250.1.59.40211.12345678.678910” found in an ImagingStudy.identifier having Identifier.system of “urn:dicom:uid” , study.series.uid value
• the DICOM Series Instance UID of “urn:oid:1.2.250.1.59.40211.789001276.14556172.67789” “1.2.250.1.59.40211.789001276.14556172.67789” found in ImagingStudy.series.uid , and study.series.instance.uid value
• the DICOM SOP Instance UID of “urn:oid:1.2.250.1.59.40211.2678810.87991027.899772.2” : “1.2.250.1.59.40211.2678810.87991027.899772.2” found in ImagingStudy.series.instance.uid

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 .

10.3.3.2.3

10.4.4.2.3 IID

An Endpoint.connectionType of code ihe-iid , system http://hl7.org/fhir/endpoint-connection-type 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 the 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, given using the following information in a fictional ImagingStudy resource:

• the WADO-URI service base url of “https://pacs.hospital.org/IHEInvokeImageDisplay” found in an Endpoint.address ImagingStudy.endpoint.address ,
• the DICOM Study Instance UID of “urn:oid:1.2.250.1.59.40211.12345678.678910” found in an ImagingStudy.identifier having Identifier.system of https://pacs.hospital.org/IHEInvokeImageDisplay “urn:dicom:uid” ,

we can construct the IID URL to invoke a diagnostic quality viewer on the study with study.uid value of “urn:uri:1.2.250.1.59.40211.12345678.678910” , the following URL would be constructed: 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 .

10.3.3.3

10.4.4.3 Use Case

10.3.3.3.1

10.4.4.3.1 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 .

10.3.3.3.2

10.4.4.3.2 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 ProcedureRequest 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 ProcedureRequest 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 ProcedureRequest 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 ImagingManifest 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 ImagingManifest 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, 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, department and triggers the PACS to share the echo study through the Metropolitan Health Information Exchange.

The PACS creates a manifest of the an imaging study as an ImagingManifest 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 manifest 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 manifest ImagingManifest ImagingStudy , and uses it to access the shared images, which she uses to prepare for the cath procedure.

10.3.4 10.4.5 Search Parameters

Search parameters for this resource. The common parameters also apply. See Searching for more information about searching in REST, messaging, and services.

Name	Type	Description	Expression	In Common
accession token The accession identifier for the study ImagingStudy.accession basedon	reference	The order for the image	ImagingStudy.basedOn ( ReferralRequest Appointment , AppointmentResponse , CarePlan , ProcedureRequest Task , ServiceRequest )
bodysite	token	The body site studied	ImagingStudy.series.bodySite
context dicom-class	reference token	The context type of the study instance	ImagingStudy.context ( EpisodeOfCare , Encounter ) ImagingStudy.series.instance.sopClass
dicom-class encounter	uri reference	The type context of the instance study	ImagingStudy.series.instance.sopClass ImagingStudy.encounter ( Encounter )
endpoint	reference	The endpoint for te the study or series	ImagingStudy.endpoint | ImagingStudy.series.endpoint ( Endpoint )
identifier	token	Other identifiers Identifiers for the Study, such as DICOM Study Instance UID and Accession number	ImagingStudy.identifier	26 Resources
instance N	token	SOP Instance UID for an instance	ImagingStudy.series.instance.uid
interpreter	reference	Who interpreted the images	ImagingStudy.interpreter ( Practitioner , PractitionerRole )
modality	token	The modality of the series	ImagingStudy.series.modality
patient	reference	Who the study is about	ImagingStudy.patient ImagingStudy.subject.where(resolve() is Patient) ( Group , Device , Patient )	31 Resources
performer	reference	The person who performed the study	ImagingStudy.series.performer ImagingStudy.series.performer.actor ( Practitioner , Organization , CareTeam , Device , Patient , HealthcareService , PractitionerRole , RelatedPerson )
reason	token	The reason for the study	ImagingStudy.reason
referrer	reference	The referring physician	ImagingStudy.referrer ( Practitioner , PractitionerRole )
series N	uri token	The identifier of the DICOM Series Instance UID for a series of images	ImagingStudy.series.uid
started N	date	When the study was started	ImagingStudy.started
study status N	uri token	The study identifier for status of the image study	ImagingStudy.uid ImagingStudy.status
uid subject	uri reference	The instance unique identifier Who the study is about	ImagingStudy.series.instance.uid ImagingStudy.subject ( Group , Device , Patient )