This page is part of the FHIR Specification (v3.0.2: STU 3). The current version which supercedes this version is 5.0.0 . For a full list Continuous Integration Build of available versions, see FHIR (will be incorrect/inconsistent at times).
See the Directory of published versions . Page versions: R5 R4B R4 R3 R2

• Content
• Examples Detailed Descriptions
• Detailed Descriptions Search Params
• Mappings
• Examples
• Operations
• Profiles & Extensions
• R2 Conversions Extensions

10.3 10.5 Resource ImagingStudy - Content

Responsible Owner: Imaging Integration Work Group

Normative Maturity Level : 3

Trial Use Security Category : Patient

Compartments : Group , 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 can have multiple series of different modalities. modality values.

This resource is referenced by ChargeItem , ClinicalImpression ,

10.5.3 References to this Resource

• Implements: Event
• Resource References: DiagnosticReport , ImagingSelection and ImagingManifest Observation
• Extension References: AuditEvent SOPClass and Procedure Caused By

10.3.3 10.5.4 Resource Content

 

Alternate Additional definitions: Master Definition ( XML , + JSON ), , XML Schema / Schematron (for ) + JSON Schema , ShEx (for Turtle ) + see the extensions , the spreadsheet version & the dependency analysis

10.3.3.1 10.5.4.1 Terminology Bindings

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

Path	Definition ValueSet	Type	Reference Documentation
ImagingStudy.status	Availability of the resource ImagingStudyStatus	Required	The status of the ImagingStudy.
ImagingStudy.modality	InstanceAvailability Modality	Extensible	Transitive closure of CID 33 Modality
ImagingStudy.reason	ProcedureReasonCodes	Example	Type of acquired data in This example value set defines the instance set of codes that can be used to indicate a reason for a procedure.
ImagingStudy.series.modality	Modality	Extensible	Acquisition Transitive closure of CID 33 Modality Codes
ImagingStudy.series.bodySite	The performed procedure type SNOMEDCTBodyStructures	Example	Procedure Codes (SNOMED CT) This value set includes all codes from SNOMED CT where concept is-a 442083009 (Anatomical or acquired body site (body structure)).
ImagingStudy.series.performer.function	ImagingStudySeriesPerformerFunction	Extensible	The reason for the Performer function of an agent in an imaging study series

10.5.4.2 Constraints

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

10.5.5.1 DICOM UIDs

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"
	} 

10.5.5.2 Accession Number

The study accession number is encoded as Reference.identifier element using the “urn:oid:1.2.250.1.59.40211.12345678.678910” . ACSN identifier type, e.g.:

"basedOn": [
  "reference": {
    "identifier":{
        "type" : {
            "coding" : [
                {
                    "system" : "http://terminology.hl7.org/CodeSystem/v2-0203",
                    "code" : "ACSN"
                }
            ]
        },
        "system":"http://ginormoushospital.org/accession",
        "value":"GH334103"
    }
  }
]

10.5.5.3 ImagingStudy Endpoints

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 and 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 can have different capabilities, protocols or requirements; and requirements. Furthermore, the specified Endpoint.url may require manipulation. For Endpoint.address identifies the DICOM Web Service Base URI (see DICOM PS 3.18 Section 8.2 ). The URL needed to retrieve image data might need to be constructed from this base URL. See below for the details on use of imaging-related Endpoint connection types, See below for details. types.

10.3.3.2.1 10.5.5.3.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, 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 study, series, and 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 "single frame", "multi-frame", "video", "text", or series level information. "other".

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 following information in a fictional ImagingStudy resource:

• the WADO-RS service base URL constructed from a of Endpoint.address https://pacs.hospital.org/wado-rs of found in an “https://pacs.hospital.org/wado-rs” 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" "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 can 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 specified WADO-RS service supports the DICOMweb thumbnail resource, a representative image of the study 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 Section 10.4 .

10.3.3.2.2

10.5.5.3.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 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,” "single frame", "multi-frame", "video", "text", or “other.” "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 following information in a fictional ImagingStudy resource:

• the WADO-URI service base URL constructed from a of Endpoint.address.url https://pacs.hospital.org/wado-uri of found in an “https://pacs.hospital.org/wado-uri” 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 Chapter 9 .

10.3.3.2.3

10.5.5.4 IID Additional DICOM attributes

An Endpoint.connectionType of code ihe-iid , system http://hl7.org/fhir/endpoint-connection-type , identifies Some imaging uses might require information beyond what is present in an IHE Invoke Image Display (IID) service. The Endpoint.address identifies the HTTP(S) service base url. That is, only ImagingStudy resource. Many of the scheme, authority DICOM patient and path study level attributes are included. Neither found in the question mark (“?”) nor any query parameters shall FHIR Patient, Procedure, or other resources which are referenced from an ImagingStudy instance. Other DICOM content might be included. transformed into other FHIR resources, such as DiagnosticReports or Observations, which are not directly referenced, but can be easily found.

The IHE Invoke Image Display (IID) service provides a standardized mechanism Although many ImagingStudy consumers are expected to launch a viewer need only the DICOM information contained in a particular study context. (IID also supports invoking a particular patient context, but that FHIR resources, some might need additional DICOM attributes. For these cases, which by their nature involve more imaging-aware consumers, the most flexible solution is not profiled here.) An IID-type Endpoint should be used only at to leverage the study level. As well as invoking DICOM WADO-RS metadata-only endpoint to retrieve an XML or JSON representation of the viewer on a particular DICOM study, query parameters can request particular viewer capabilities, image quality, and more. series, instance, or frame information.

To launch a viewer, append A benefit of using the appropriate query parameters metadata endpoint in this way is that the ImagingStudy creator does not need to Endpoint.address value. For example, given an Endpoint.address know each of https://pacs.hospital.org/IHEInvokeImageDisplay , to invoke a diagnostic quality viewer on the study with study.uid value attributes that each of “urn:uri:1.2.250.1.59.40211.12345678.678910” , the (current or future) ImagingStudy consumers is (or will be) interested in.

10.5.5.4.1 Example Metadata Retrieval

A client retrieves the following URL would be constructed: ImagingStudy:

https://pacs.hospital.org/IHEInvokeImageDisplay?requestType=STUDY&studyUID=1.2.250.1.59.40211.12345678.678910&diagnosticQuality=true


{
  "resourceType": "ImagingStudy",
  "id": "example-xr",
  "identifier": [
    {
      "use": "official",
      "system": "urn:dicom:uid",
      "value": "urn:oid:2.16.124.113543.6003.1154777499.30246.19789.3503430046"
    }
  ],
  ...
  "series": [
    {
      "uid": "2.16.124.113543.6003.1154777499.30246.19789.3503430045.1",
      ...
      "endpoint": [
        {
          "reference": "Endpoint/example-wadors"
        }
      ]
      ...
    }
    ...
  ]
}

For further details on IHE Invoke Image Display capabilities including additional parameters, see the IHE Technical Frameworks (See Example XR for full example)

, or

The client retrieves the introduction on referenced Endpoint (see Example WADO-RS ) and extracts the IHE IID Profile Wiki WADO-RS URL:

https://pacs.hospital.org/wado-rs

.

.

The client uses the WADO-RS URL, the identifier.value and the series.uid to construct a WADO-RS metadata request:

GET https://pacs.hospital.org/wado-rs/studies/2.16.124.113543.6003.1154777499.30246.19789.3503430046/series/2.16.124.113543.6003.1154777499.30246.19789.3503430045.1/metadata HTTP/1.1
Accept: application/dicom+json

The WADO-RS server then returns the complete DICOM metadata for the requested series.

10.3.3.3

10.5.5.5 Use Case Cases

10.3.3.3.1

10.5.5.5.1 EHR access to imaging studies Comprehensive Imaging Scheduled Workflow

Amy, a family physician, would like to see Note: reporting workflow is not described in this use case.

1. Hospital ordering system creates a list of available studies ServiceRequest and related resources ordering an echocardiogram for her a patient, Alex. Her EHR client makes linked to a FHIR call for all ImagingStudy Patient objects available for Alex. In resource
2. Radiology Information System creates DICOM Modality Worklist (MWL) entry based on the response, she is able service request and related patient information
   • Patient identifiers and demographics
   • Accession Number
   • Procedure to see the study date, procedure, modality, be performed
   • Study Instance UID
3. Ultrasound technologist queries MWL entry and accession number, for each study returned. There selects relevant entry
4. Patient is enough scanned and ultrasound device creates an echocardiogram with patient demographics and order information provided in based on the response to obtain a thumbnail via a WADO-RS call, or MWL entry
5. Echocardiogram is sent to launch a viewer using image archive and stored
6. Image archive creates an IHE ImagingStudy
   • subject is current Patient
   • basedOn includes current ServiceRequest
   • identifier is Study Instance UID
   • endpoint points to image archive WADO-RS service
   • modality is US
7. Image archive notifies EMR of imaging study
8. Radiology - Invoke reading workstation retrieves study images from image archive
9. Radiologist reads study and selects several images as "key images"
10. Radiology reading workstation sends DICOM Key Object Selection (KOS) to image archive
11. Image Display (IID) archive updates imaging study to include KOS
    • modality is now US,KOS
    • KOS series added
12. Imaging study available to EMR clients

profile call using the url elements found in the ImagingStudy .

10.3.3.3.2 10.5.5.5.2 Comprehensive Imaging Scheduled Workflow EHR access to imaging studies

Joe Angina complains of shortness of breath

1. EMR client searches for imaging studies for a patient:
   • Search parameters:
     • status=available
     • subject.identifier=[identifier for selected patient]
2. Image archive returns matching imaging studies, each containing:
   • Study Instance UID ( ImagingStudy.identifier )
   • Accession Number ( ImagingStudy.basedOn.identifier )
   • Procedure codes ( ImagingStudy.procedure )
   • Imaging modalities in study ( ImagingStudy.modality )
   • WADO-RS endpoint ( ImagingStudy.endpoint ) pointing to image archive hosting DICOM study
3. EMR user selects relevant imaging study based on search results
4. EMR client launches enterprise image viewer
   • Passes WADO-RS endpoint and occasional chest pain Study Instance UID
5. Enterprise image viewer loads image data from image archive
   • Makes WADO-RS call to his primary care physician, Dr. Pat Down at Local MultiClinic, who orders a stress echocardiogram; the order is created as a FHIR Task endpoint with specified Study Instance UID

resource to manage

10.5.5.6 Size Considerations

Depending on the workflow, with modality and procedure type, a link DICOM study can range from having one or two instances (as in many X-ray procedures) to a ProcedureRequest resource with the details several thousand instances (for some CT exams) or even tens of the request. thousands (for functional MRI studies). The order number of series within a study has far less variability, and is scheduled usually under twenty, although post-processing, computer-aided detection, and assigned to cardiologist Dr. Art Skann, also at Local MultiClinic. AI applications could cause modest increases. An ImagingStudy resource describing a large DICOM study would itself be of significant size.

On the scheduled day of the exam, Joe arrives at the echo lab Issuing narrowly tailored queries can help a client avoid search results containing many ImagingStudy resources. The _summary=true query parameter will omit several resource elements, including all instance-level elements; this can be used to meet with Dr. Skann and have examine search results before retrieving the study done. Dr. Skann’s workstation shows full instances. If a server limits the daily list byte size of Task , and he follows search bundle, this can impact the link number of ImagingStudy resources returned per search result page; a client can use the _count query parameter to retrieve influence the ProcedureRequest . (He may follow number of resources per search result page.

Although not reflected in the links through ImagingStudy resource, the size of an individual referenced Patient resource instance can be anywhere from a few kilobytes (a compressed 256x256 pixel MR or 640x480 pixel ultrasound image) to access Joe’s electronic medical record, but that is not a gigabyte or more (for digital breast tomography imaging). When retrieving the concern referenced content of this storyboard.) an ImagingStudy, applications can consider methods to reduce transfer time, such as:

The Task

• Loading only specific instances or series
• Specifying compressed Transfer Syntaxes
• etc.

10.5.5.7 ImagingStudy Create and ProcedureRequest Update Workflow has been transcoded to

The ImagingStudy resource can be hosted by an image archive application — such as a DICOM Modality Worklist Scheduled Procedure Step, and PACS or Vendor-Neutral Archive — or a more general healthcare informatics application such as an EMR. In some cases, it could be hosted in both locations.

However, the echo lab image archive is typically the equipment has downloaded source of truth for the Modality Worklist. The study is performed, and content of the acquired images and sonographer’s preliminary measurements are stored in ImagingStudy.

Depending on where the Local MultiClinic Picture Archiving and Communication System (PACS). The PACS creates an ImagingStudy resource is hosted, there are several available mechanisms for each study it manages. keeping the two applications consistent.

10.5.5.7.1 Image Archive hosts ImagingStudy

Dr. Skann interprets In this scenario, the study on a PACS workstation, image archive:

• Hosts FHIR ImagingStudy resources
• Hosts DICOM / DICOMweb endpoints
• Ensures consistency between the FHIR and DICOM metadata
• Ensures consistency between ImagingStudy and he selects two key related resources
  • Patient, ServiceRequest, etc.

The image frames to be included in the diagnostic report; this selection is stored back to archive could share ImagingStudy information by:

• EMR performing on-demand FHIR ImagingStudy searches
  • Typically using the PACS as Accession Number associated with a service request. e.g., GET http://example.org/fhir/ImagingStudy?basedOn=ServiceRequest/123&status=available
• Subscription to ImagingStudy resources
  • e.g. Requesting notification when ImagingStudy.status=available
• Legacy mechanisms, such as:
  • HL7 v2 messages
  • DICOM Key Object Selection with Instance Availability notification

10.5.5.7.2 EMR hosts ImagingStudy

In this scenario, the title "For Report Attachment", image archive:

• Hosts DICOM / DICOMweb endpoints
• Ensures consistency between DICOM and the PACS makes it available (transcodes it) as a key FHIR ImagingManifest resource. Dr. Skann dictates resources
  • Patient, ServiceRequest, etc.

while the report using a structured data entry report writing program, including a recommendation for a cardiac catheterization procedure, EMR:

• Hosts FHIR ImagingStudy resources
• Ensures consistency between ImagingStudy and signs it. key related resources
  • Patient, ServiceRequest, etc.

The report writing program formats the report as image archive could share ImagingStudy information by:

• EMR performing on-demand DICOM / DICOMweb searches
  • Typically using Accession Number
  • Response would be converted from DICOM to FHIR
    • ImagingStudy is intended to support mapping to and from DICOM / DICOMweb search responses
• Image archive creating / updating ImagingStudy resources hosted in EMR
  • Either via PUT method or by posting a CDA Bundle
• Subscription to ImagingStudy resources
  • As above example
• Legacy mechanisms, such as:
  • HL7 v2 messages
  • DICOM Instance Availability notification

10.5.5.7.3 document, retrieves the ImagingManifest Both image archive and EMR host ImagingStudy resource,

In this scenario, the image archive:

• Hosts FHIR ImagingStudy resources
• Hosts DICOM / DICOMweb endpoints
• Ensures consistency between the FHIR and inserts DICOM metadata
• Ensures consistency between ImagingStudy and key related resources
  • Patient, ServiceRequest, etc.

while the referenced EMR:

• Hosts FHIR ImagingStudy resources
• Ensures consistency between ImagingStudy and key images into related resources
  • Patient, ServiceRequest, etc.

Mechanisms for ensuring consistency between two systems holding representations of the report. same data are still in development.

Dr. Down meets again with Joe, and they review As the results image archive is the "source of truth," the stress test. Joe has above methods might still be applicable. See Provenance resource.

10.5.5.8 ImagingStudy.status

Typically, an ImagingStudy is a question about the findings FHIR representation of imaging data that the key images is stored in a DICOM device, such as an image archive (e.g., PACS). The value of the report do status element reflects the status of this representation and does not show, so Dr. Down uses necessarily reflect the Local MultiClinic EMR to query status of either the PACS for underlying imaging data or any ServiceRequest or Task resources that resulted in the full ImagingStudy resource, and uses being created.

In some cases, the references there to open an image display for ImagingStudy could be created before any images have been acquired. In this case, the full study. Joe agrees to proceed to catheterization, and Dr. Down sends .status will have a referral to the Ginormous University Hospital cath department, value of registered .

After at least some images have been acquired and triggers the PACS ImagingStudy has been updated to share reflect that, the echo study through ImagingStudy will have a status of available . At this stage the Metropolitan Health Information Exchange. ImagingStudy can be presented to viewing applications.

The PACS creates a manifest of If the study as an ImagingManifest resource, which includes all ImagingStudy is canceled before images are acquired its status SHOULD be set to cancelled .

If the ImagingStudy is incorrect - e.g., due to images but excludes being acquired with the sonographer’s preliminary measurements (which as wrong modality worklist entry selected — it might be corrected with an update operation or set to entered-in-error and replaced with a matter new ImagingStudy.

Additional DICOM images, key object notes, etc. could be created later, so a status of policy are complete is not shared outside the Local MultiClinic). The manifest meaningful for an ImagingStudy. For this reason, this status is published not defined for an ImagingStudy.

Any applications waiting for the completion of an imaging-related ServiceRequest or Task SHOULD track the progress of those resources directly.

10.5.5.9 Source of ImagingStudy Content

An ImagingStudy might be created to represent the Metro HIE. (In accordance with content of:

• A DICOMweb Studies Service Search response
  • See DICOM PS 3.18 Section 10.6.3.3
• A DICOM Study Root Query / Retrieve response
  • See DICOM PS 3.4 Section C.6.2.1
• An IHE XDS-I Manifest KOS Document
  • See IHE RAD TF Volume 2 Section 4.68.4.1.2.1.1 ,

The set of ImagingStudy elements is broadly aligned with these three information models.

10.5.5.10 Imaging Study Procedures

In DICOM, a Study can be related to two types of "procedures": requested procedures and performed procedures.

In the images themselves FHIR model, "requested procedures" are not directly published to represented by the HIE, but available for on-demand retrieval from ServiceRequest resource while "performed procedures" are represented by the PACS.) Procedure resource.

At Ginormous Hospital, Dr. Cora Plummer receives Therefore, the cath referral, and looks up requested procedure associated with a particular imaging study would typically be encoded as the ServiceRequest that the imaging study in is basedOn.

Similarly, the Metro HIE registry. She retrieves performed procedure would be encoded as the ImagingStudy.procedure that the imaging study manifest ImagingManifest , is part of.

Searching for an imaging study by its requested procedure can be done by including based-on as a search parameter, and uses it to access by its performed procedure by including procedure as a search parameter.

10.5.5.11 Body Site and Laterality

The series.bodySite element can include the shared images, which she uses to prepare for laterality of the cath procedure. (possibly paired) anatomic structures examined – e.g. left knee, bilateral lungs, etc. This can be conveyed in several ways:

• series.bodySite contains an anatomic code that includes laterality, e.g.

  
  "bodySite": {
    "concept": {
      "coding": [{
        "system": "http://snomed.info/sct",
        "code": "5951000",
        "display": "Left wrist"
      }]
    }
  }
  

• series.bodySite contains a reference to a BodyStructure resource whose includedStructure.structure element contains an anatomic code that includes laterality
• series.bodySite contains a reference to a BodyStructure resource whose includedStructure element includes a laterality value. See this example BodyStructure representation of the Left Wrist, with laterality and SNOMED coding for anatomical structure .

10.3.4 10.5.6 Search Parameters

Search parameters for this resource. See also the full list of search parameters for this resource , and check the Extensions registry for search parameters on extensions related to this resource. The common parameters also apply. See Searching for more information about searching in REST, messaging, and services.

The accession identifier for the study ImagingStudy.accession basedon

Name	Type	Description	Expression	In Common
accession token based-on	reference	The order for the image such as Accession Number	ImagingStudy.basedOn ( ReferralRequest Appointment , CarePlan , ProcedureRequest Task , ServiceRequest )
body-site bodysite	token	The body site code studied	ImagingStudy.series.bodySite ImagingStudy.series.bodySite.concept
context body-structure	reference	The context of body structure resource associated with the study ImagingStudy	ImagingStudy.context ( EpisodeOfCare , Encounter ) ImagingStudy.series.bodySite.reference
dicom-class	uri	The type of the instance	ImagingStudy.series.instance.sopClass
encounter	reference	The context of the study	ImagingStudy.encounter ( Encounter )	27 Resources
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	ImagingStudy.identifier	26 59 Resources
instance	token	SOP Instance UID for an instance	ImagingStudy.series.instance.uid
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) ( Patient )	31 61 Resources
performer	reference	The person who performed the study	ImagingStudy.series.performer ImagingStudy.series.performer.actor ( Practitioner , Organization , CareTeam , Device , Patient , HealthcareService , PractitionerRole , RelatedPerson )
procedure	reference reason	The performed procedure for the study	ImagingStudy.procedure ( Procedure )
reason-concept	token	The reason code for the study	ImagingStudy.reason ImagingStudy.reason.concept
series reason-reference	reference	The resource reference describing the reason for the study	ImagingStudy.reason.reference	uri
referrer	reference	The identifier of the referring physician	ImagingStudy.referrer ( Practitioner , PractitionerRole )
series of images	token	DICOM Series Instance UID for a series	ImagingStudy.series.uid
started	date	When the study was started	ImagingStudy.started
study status	uri token	The study identifier for status of the image study	ImagingStudy.uid ImagingStudy.status
subject uid	uri reference	The instance unique identifier Who the study is about	ImagingStudy.series.instance.uid ImagingStudy.subject ( Group , Device , Patient )