--- type: "resource" title: "ImagingStudy" resource: "ImagingStudy" --- # ImagingStudy ## Introduction ## Scope and Usage The ImagingStudy resource provides information on available imaging data. An ImagingStudy provides information on a single 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). 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](http://medical.nema.org/medical/dicom/current/output/html/part06.html). 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](http://medical.nema.org/medical/dicom/current/output/html/part03.html) . Attributes used in the DICOM query information models, such as "Number of Instances in Study", can be found in [DICOM Part 4 Annex C](http://medical.nema.org/medical/dicom/current/output/html/part04.html#chapter_C). ImagingStudy provides access to significant DICOM information but will only eliminate the need for DICOM query (e.g., a DICOMweb search transaction) in the simplest cases. The DICOM instances are not stored in the ImagingStudy resource; use of a DICOM service is needed (e.g., a DICOMweb retrieve transaction). One ImagingStudy SHALL reference one DICOM Study. This resource can change as additional information is added to the related DICOM Study. See notes for guidance on [how imaging study element values can be populated](imagingstudy#source) and [when imaging studies are typically created and updated](imagingstudy#workflow). ## Boundaries and Relationships The [ImagingStudy](imagingstudy) resource is used to store details of an entire DICOM Study and its relationships to other resources, such as [Patient](patient), [ServiceRequest](servicerequest), and [Encounter](encounter). The [ImagingSelection](imagingselection) resource is used to reference to a subset of a study. Instances of this resource are created for specific clinical purposes and are unlikely to change once created. An [Observation](observation) typically relates to a set of images in the following ways. - [Observation.partOf](observation) references an [ImagingStudy](imagingstudy) - [Observation.derivedFrom](observation) references an [ImagingSelection](imagingselection) when it directly relates to an identified subset of a study - [Observation.derivedFrom](observation) references an [ImagingStudy](imagingstudy) when it does not relate to an identified subset of a study. - [Observation.derivedFrom](observation) references an [ImagingSelection](imagingselection) when it is a measurement of an identified subset of a study described by the [ImagingSelection](imagingselection) The [DocumentReference](documentreference) resource is used to store non-DICOM images, video, or audio with relevant metadata. The [DocumentReference](documentreference) resource might be appropriate for including a rendered DICOM image in cases where only the image is needed and not the full image context. ## Notes ## 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 UIDs 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" } ### Accession Number The study accession number is encoded as [Reference.identifier](references#reference) element using the `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" } } \] ### ImagingStudy Endpoints The ImagingStudy.endpoint elements and ImagingStudy.series.endpoint elements indicate network services that can be used to access the studies, series, and 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 can have different capabilities, protocols or requirements. Furthermore, the specified `Endpoint.address` identifies the DICOM Web Service Base URI (see [DICOM PS 3.18 Section 8.2](https://dicom.nema.org/medical/dicom/current/output/chtml/part18/sect_8.2.html) ). 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. #### 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 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 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: - the WADO-RS service base URL of `https://pacs.hospital.org/wado-rs` found in an `ImagingStudy.endpoint.address`, - the DICOM Study Instance UID of `1.2.250.1.59.40211.12345678.678910` found in an `ImagingStudy.identifier` having `Identifier.system` of `“urn:dicom:uid”`, - the DICOM Series Instance UID of `1.2.250.1.59.40211.789001276.14556172.67789` found in `ImagingStudy.series.uid`, and - the DICOM SOP Instance UID of `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 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 (rendered to a size of 400 columns by 400 rows) of a region extending from the top-left corner of the original image to 1000 pixels across and 3000 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**/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](https://dicom.nema.org/medical/dicom/current/output/chtml/part18/sect_10.4.html.). #### 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 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: - the WADO-URI service base URL of `https://pacs.hospital.org/wado-uri` found in an `ImagingStudy.endpoint.address`, - the DICOM Study Instance UID of `1.2.250.1.59.40211.12345678.678910` found in an `ImagingStudy.identifier` having `Identifier.system` of `urn:dicom:uid`, - the DICOM Series Instance UID of `1.2.250.1.59.40211.789001276.14556172.67789` found in `ImagingStudy.series.uid`, and - the DICOM SOP Instance UID of `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®ion=0,0,0.5,1** For further details on DICOM WADO-URI capabilities including additional rendering parameters, see [DICOM PS 3.18 Chapter 9](https://dicom.nema.org/medical/dicom/current/output/chtml/part18/chapter_9.html). ### Additional DICOM attributes Some imaging uses might require information beyond what is present in an ImagingStudy resource. Many of the DICOM patient and study level attributes are found in the FHIR Patient, Procedure, or other resources which are referenced from an ImagingStudy instance. Other DICOM content might be transformed into other FHIR resources, such as DiagnosticReports or Observations, which are not directly referenced, but can be easily found. Although many ImagingStudy consumers are expected to need only the DICOM information contained in 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 to leverage the DICOM WADO-RS metadata-only endpoint to retrieve an XML or JSON representation of the DICOM study, series, instance, or frame information. A benefit of using the metadata endpoint in this way is that the ImagingStudy creator does not need to know each of the attributes that each of the (current or future) ImagingStudy consumers is (or will be) interested in. #### Example Metadata Retrieval A client retrieves the following ImagingStudy: { "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" } \] ... } ... \] } (See [Example XR](imagingstudy-example-xr.json) for full example) The client retrieves the referenced Endpoint (see [Example WADO-RS](endpoint-example-wadors.json)) and extracts the 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. ### Use Cases #### Comprehensive Imaging Scheduled Workflow _Note:_ reporting workflow is not described in this use case. 1. Hospital ordering system creates a [ServiceRequest](servicerequest) and related resources ordering an echocardiogram for a patient, linked to a [Patient](patient) resource 2. Radiology Information System creates DICOM Modality Worklist (MWL) entry based on the service request and related patient information - Patient identifiers and demographics - Accession Number - Procedure to be performed - Study Instance UID 3. Ultrasound technologist queries MWL entry and selects relevant entry 4. Patient is scanned and ultrasound device creates an echocardiogram with patient demographics and order information based on the MWL entry 5. Echocardiogram is sent to image archive and stored 6. Image archive creates an [ImagingStudy](imagingstudy) - `subject` is current [Patient](patient) - `basedOn` includes current [ServiceRequest](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 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 archive updates imaging study to include KOS - `modality` is now US,KOS - KOS series added 12. Imaging study available to EMR clients #### EHR access to imaging studies 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 Study Instance UID 5. Enterprise image viewer loads image data from image archive - Makes WADO-RS call to endpoint with specified Study Instance UID ### Size Considerations Depending on the modality and procedure type, a DICOM study can range from having one or two instances (as in many X-ray procedures) to several thousand instances (for some CT exams) or even tens of thousands (for functional MRI studies). The number of series within a study has far less variability, and is usually under twenty, although post-processing, computer-aided detection, and AI applications could cause modest increases. An ImagingStudy resource describing a large DICOM study would itself be of significant size. 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 examine search results before retrieving the full instances. If a server limits the byte size of search bundle, this can impact the number of ImagingStudy resources returned per search result page; a client can use the \_count query parameter to influence the number of resources per search result page. Although not reflected in the ImagingStudy resource, the size of an individual referenced instance can be anywhere from a few kilobytes (a compressed 256x256 pixel MR or 640x480 pixel ultrasound image) to a gigabyte or more (for digital breast tomography imaging). When retrieving the referenced content of an ImagingStudy, applications can consider methods to reduce transfer time, such as: - Loading only specific instances or series - Specifying compressed Transfer Syntaxes - etc. ### ImagingStudy Create and Update Workflow The ImagingStudy resource can be hosted by an image archive application — such as a 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 image archive is typically the source of truth for the content of the ImagingStudy. Depending on where the ImagingStudy resource is hosted, there are several available mechanisms for keeping the two applications consistent. #### Image Archive hosts ImagingStudy In this scenario, the image archive: - Hosts FHIR ImagingStudy resources - Hosts DICOM / DICOMweb endpoints - Ensures consistency between the FHIR and DICOM metadata - Ensures consistency between ImagingStudy and key related resources - Patient, ServiceRequest, etc. The image archive could share ImagingStudy information by: - EMR performing on-demand FHIR ImagingStudy searches - Typically using the 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 Instance Availability notification #### EMR hosts ImagingStudy In this scenario, the image archive: - Hosts DICOM / DICOMweb endpoints - Ensures consistency between DICOM and key FHIR resources - Patient, ServiceRequest, etc. while the EMR: - Hosts FHIR ImagingStudy resources - Ensures consistency between ImagingStudy and key related resources - Patient, ServiceRequest, etc. The 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 Bundle - Subscription to ImagingStudy resources - As above example - Legacy mechanisms, such as: - HL7 v2 messages - DICOM Instance Availability notification #### Both image archive and EMR host ImagingStudy In this scenario, the image archive: - Hosts FHIR ImagingStudy resources - Hosts DICOM / DICOMweb endpoints - Ensures consistency between the FHIR and DICOM metadata - Ensures consistency between ImagingStudy and key related resources - Patient, ServiceRequest, etc. while the EMR: - Hosts FHIR ImagingStudy resources - Ensures consistency between ImagingStudy and key related resources - Patient, ServiceRequest, etc. Mechanisms for ensuring consistency between two systems holding representations of the same data are still in development. As the image archive is the "source of truth," the above methods might still be applicable. See Provenance resource. ### ImagingStudy.status Typically, an ImagingStudy is a FHIR representation of imaging data that is stored in a DICOM device, such as an image archive (e.g., PACS). The value of the status element reflects the status of this representation and does not necessarily reflect the status of either the underlying imaging data or any ServiceRequest or Task resources that resulted in the ImagingStudy being created. In some cases, the ImagingStudy could be created before any images have been acquired. In this case, the `.status` will have a value of `registered`. After at least some images have been acquired and the ImagingStudy has been updated to reflect that, the ImagingStudy will have a status of `available`. At this stage the ImagingStudy can be presented to viewing applications. If the ImagingStudy is canceled before images are acquired its status SHOULD be set to `cancelled`. If the ImagingStudy is incorrect - e.g., due to images being acquired with the wrong modality worklist entry selected — it might be corrected with an update operation or set to `entered-in-error` and replaced with a new ImagingStudy. Additional DICOM images, key object notes, etc. could be created later, so a status of `complete` is not meaningful for an ImagingStudy. For this reason, this status is 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. ### Source of ImagingStudy Content An ImagingStudy might be created to represent the content of: - A DICOMweb Studies Service Search response - See [DICOM PS 3.18 Section 10.6.3.3](https://dicom.nema.org/medical/dicom/current/output/chtml/part18/sect_10.6.3.3.html) - A DICOM Study Root Query / Retrieve response - See [DICOM PS 3.4 Section C.6.2.1](https://dicom.nema.org/medical/dicom/current/output/chtml/part04/sect_C.6.2.html#sect_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](https://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol2.pdf) The set of ImagingStudy elements is broadly aligned with these three information models. ### Imaging Study Procedures In DICOM, a Study can be related to two types of "procedures": requested procedures and performed procedures. In the FHIR model, "requested procedures" are represented by the `ServiceRequest` resource while "performed procedures" are represented by the `Procedure` resource. Therefore, the requested procedure associated with a particular imaging study would typically be encoded as the `ServiceRequest` that the imaging study is basedOn. Similarly, the performed procedure would be encoded as the `ImagingStudy.procedure`that the imaging study is part of. Searching for an imaging study by its requested procedure can be done by including `based-on` as a search parameter, and by its performed procedure by including `procedure` as a search parameter. ### Body Site and Laterality The `series.bodySite` element can include the laterality of the (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](bodystructure-example-dicom-includedStructure). ## StructureDefinition ### Elements (Simplified) - **[ImagingStudy](/imagingstudy-definitions#ImagingStudy)** [0..*]: - A set of images or image-related data produced in single study - **[ImagingStudy.identifier](/imagingstudy-definitions#ImagingStudy.identifier)** [0..*]: [Identifier](/Identifier) Business identifier for imaging study - **[ImagingStudy.status](/imagingstudy-definitions#ImagingStudy.status)** [1..1]: [code](/code) required:[imagingstudy-status](/valueset-imagingstudy-status) registered | available | cancelled | entered-in-error | unknown | inactive - **[ImagingStudy.modality](/imagingstudy-definitions#ImagingStudy.modality)** [0..*]: [CodeableConcept](/CodeableConcept) extensible:[sect_CID_33.html](/valueset-sect_CID_33.html) The distinct values for series' modalities - **[ImagingStudy.subject](/imagingstudy-definitions#ImagingStudy.subject)** [1..1]: [Reference(Patient](/Reference(Patient), [Device](/Device), [Group)](/Group)) Who or what is the subject of the study - **[ImagingStudy.encounter](/imagingstudy-definitions#ImagingStudy.encounter)** [0..1]: Reference([Encounter](/Encounter)) Encounter with which this imaging study is associated - **[ImagingStudy.started](/imagingstudy-definitions#ImagingStudy.started)** [0..1]: [dateTime](/dateTime) When the study was started - **[ImagingStudy.basedOn](/imagingstudy-definitions#ImagingStudy.basedOn)** [0..*]: [Reference(CarePlan](/Reference(CarePlan), [ServiceRequest](/ServiceRequest), [Appointment](/Appointment), [Task)](/Task)) Fulfills plan or order - **[ImagingStudy.procedure](/imagingstudy-definitions#ImagingStudy.procedure)** [0..*]: Reference([Procedure](/Procedure)) Imaging performed procedure(s) - **[ImagingStudy.referrer](/imagingstudy-definitions#ImagingStudy.referrer)** [0..1]: [Reference(Practitioner](/Reference(Practitioner), [PractitionerRole)](/PractitionerRole)) Referring physician - **[ImagingStudy.endpoint](/imagingstudy-definitions#ImagingStudy.endpoint)** [0..*]: Reference([Endpoint](/Endpoint)) Study access endpoint - **[ImagingStudy.location](/imagingstudy-definitions#ImagingStudy.location)** [0..1]: Reference([Location](/Location)) Where imaging study occurred - **[ImagingStudy.reason](/imagingstudy-definitions#ImagingStudy.reason)** [0..*]: [CodeableReference](/CodeableReference) example:[procedure-reason](/valueset-procedure-reason) Why was imaging study performed? - **[ImagingStudy.note](/imagingstudy-definitions#ImagingStudy.note)** [0..*]: [Annotation](/Annotation) Comments made about the imaging study - **[ImagingStudy.description](/imagingstudy-definitions#ImagingStudy.description)** [0..1]: [string](/string) Study Description or Classification - **[ImagingStudy.numberOfSeries](/imagingstudy-definitions#ImagingStudy.numberOfSeries)** [0..1]: [unsignedInt](/unsignedInt) Number of Study Related Series - **[ImagingStudy.numberOfInstances](/imagingstudy-definitions#ImagingStudy.numberOfInstances)** [0..1]: [unsignedInt](/unsignedInt) Number of Study Related Instances - **[ImagingStudy.series](/imagingstudy-definitions#ImagingStudy.series)** [0..*]: [BackboneElement](/BackboneElement) The set of Series belonging to the study - **[ImagingStudy.series.uid](/imagingstudy-definitions#ImagingStudy.series.uid)** [1..1]: [id](/id) DICOM Series Instance UID - **[ImagingStudy.series.number](/imagingstudy-definitions#ImagingStudy.series.number)** [0..1]: [unsignedInt](/unsignedInt) Numeric identifier of this series - **[ImagingStudy.series.modality](/imagingstudy-definitions#ImagingStudy.series.modality)** [1..1]: [CodeableConcept](/CodeableConcept) extensible:[sect_CID_33.html](/valueset-sect_CID_33.html) The modality used for this series - **[ImagingStudy.series.description](/imagingstudy-definitions#ImagingStudy.series.description)** [0..1]: [string](/string) Series Description or Classification - **[ImagingStudy.series.numberOfInstances](/imagingstudy-definitions#ImagingStudy.series.numberOfInstances)** [0..1]: [unsignedInt](/unsignedInt) Number of Series Related Instances - **[ImagingStudy.series.endpoint](/imagingstudy-definitions#ImagingStudy.series.endpoint)** [0..*]: Reference([Endpoint](/Endpoint)) Series access endpoint - **[ImagingStudy.series.bodySite](/imagingstudy-definitions#ImagingStudy.series.bodySite)** [0..1]: [CodeableReference](/CodeableReference) example:[body-site](/valueset-body-site) Body part examined - **[ImagingStudy.series.specimen](/imagingstudy-definitions#ImagingStudy.series.specimen)** [0..*]: Reference([Specimen](/Specimen)) Specimen imaged - **[ImagingStudy.series.started](/imagingstudy-definitions#ImagingStudy.series.started)** [0..1]: [dateTime](/dateTime) When the series started - **[ImagingStudy.series.performer](/imagingstudy-definitions#ImagingStudy.series.performer)** [0..*]: [BackboneElement](/BackboneElement) Who performed the series - **[ImagingStudy.series.performer.function](/imagingstudy-definitions#ImagingStudy.series.performer.function)** [0..1]: [CodeableConcept](/CodeableConcept) extensible:[series-performer-function](/valueset-series-performer-function) Type of performance - **[ImagingStudy.series.performer.actor](/imagingstudy-definitions#ImagingStudy.series.performer.actor)** [1..1]: [Reference(Practitioner](/Reference(Practitioner), [PractitionerRole](/PractitionerRole), [Organization](/Organization), [CareTeam](/CareTeam), [Patient](/Patient), [Device](/Device), [RelatedPerson](/RelatedPerson), [HealthcareService)](/HealthcareService)) Who performed imaging study - **[ImagingStudy.series.instance](/imagingstudy-definitions#ImagingStudy.series.instance)** [0..*]: [BackboneElement](/BackboneElement) A single SOP instance from the series - **[ImagingStudy.series.instance.uid](/imagingstudy-definitions#ImagingStudy.series.instance.uid)** [1..1]: [id](/id) DICOM SOP Instance UID - **[ImagingStudy.series.instance.sopClass](/imagingstudy-definitions#ImagingStudy.series.instance.sopClass)** [1..1]: [oid](/oid) DICOM class type - **[ImagingStudy.series.instance.number](/imagingstudy-definitions#ImagingStudy.series.instance.number)** [0..1]: [unsignedInt](/unsignedInt) The number of this instance in the series - **[ImagingStudy.series.instance.title](/imagingstudy-definitions#ImagingStudy.series.instance.title)** [0..1]: [string](/string) Name or title of the instance ## Mappings - [ImagingStudy Mappings](/imagingstudy-mappings) — 91 mapping entries ## Resource Packs ### list-ImagingStudy-packs.xml ```xml ``` ## Search Parameters - [based-on](/imagingstudy-search#based-on) — **reference** — The order for the image such as Accession Number — `ImagingStudy.basedOn` - [body-site](/imagingstudy-search#body-site) — **token** — The body site code studied — `ImagingStudy.series.bodySite.concept` - [body-structure](/imagingstudy-search#body-structure) — **reference** — The body structure resource associated with the ImagingStudy — `ImagingStudy.series.bodySite.reference` - [dicom-class](/imagingstudy-search#dicom-class) — **uri** — The type of the instance — `ImagingStudy.series.instance.sopClass` - [encounter](/imagingstudy-search#encounter) — **reference** — The context of the study — `ImagingStudy.encounter` - [endpoint](/imagingstudy-search#endpoint) — **reference** — The endpoint for the study or series — `ImagingStudy.endpoint | ImagingStudy.series.endpoint` - [identifier](/imagingstudy-search#identifier) — **token** — Identifiers for the Study, such as DICOM Study Instance UID — `ImagingStudy.identifier` - [instance](/imagingstudy-search#instance) — **token** — SOP Instance UID for an instance — `ImagingStudy.series.instance.uid` - [modality](/imagingstudy-search#modality) — **token** — The modality of the series — `ImagingStudy.series.modality` - [patient](/imagingstudy-search#patient) — **reference** — Who the study is about — `ImagingStudy.subject.where(resolve() is Patient)` - [performer](/imagingstudy-search#performer) — **reference** — The person who performed the study — `ImagingStudy.series.performer.actor` - [reason-concept](/imagingstudy-search#reason-concept) — **token** — The reason code for the study — `-` - [reason-reference](/imagingstudy-search#reason-reference) — **reference** — The resource reference describing the reason for the study — `-` - [referrer](/imagingstudy-search#referrer) — **reference** — The referring physician — `ImagingStudy.referrer` - [series](/imagingstudy-search#series) — **token** — DICOM Series Instance UID for a series — `ImagingStudy.series.uid` - [started](/imagingstudy-search#started) — **date** — When the study was started — `ImagingStudy.started` - [status](/imagingstudy-search#status) — **token** — The status of the study — `ImagingStudy.status` - [subject](/imagingstudy-search#subject) — **reference** — Who the study is about — `ImagingStudy.subject` - [procedure](/imagingstudy-search#procedure) — **reference** — The performed procedure for the study — `ImagingStudy.procedure` [Full Search Parameters](/imagingstudy-search) ## Examples - [example](/imagingstudy-example-example) — imagingstudy-example — Example ImagingStudy - [example-xr](/imagingstudy-example-example-xr) — imagingstudy-example-xr — Example X-ray ImagingStudy with full elements - [imagingstudy-example](/imagingstudy-example-imagingstudy-example) — imagingstudy-example - [imagingstudy-example-xr](/imagingstudy-example-imagingstudy-example-xr) — imagingstudy-example-xr - [imagingstudy-examples-header](/imagingstudy-example-imagingstudy-examples-header) — imagingstudy-examples-header [Full Examples](/imagingstudy-examples) ## Mapping Exceptions ### imagingstudy-event-mapping-exceptions.xml ### Divergent Elements - **Event.identifier** → **ImagingStudy.identifier** - commentsUnmatched | reason=Includes baseline comments with additional text specific to resource and capitalization of MAY | pattern=Note: This is a business identifier, not a resource identifier (see [discussion](resource.html#identifiers)). It is best practice for the identifier to only appear on a single resource instance, however business practices may occasionally dictate that multiple resource instances with the same identifier can exist - possibly even with different resource types. For example, multiple Patient and a Person resource instance might share the same social insurance number. | resource=Note: This is a business identifier, not a resource identifier (see [discussion](resource.html#identifiers)). It is best practice for the identifier to only appear on a single resource instance, however business practices MAY occasionally dictate that multiple resource instances with the same identifier can exist - possibly even with different resource types. For example, multiple Patient and a Person resource instance might share the same social insurance number, or an accession number MAY be used to relate a Task, an ImagingStudy and a DiagnosticReport. See discussion under [Imaging Study Implementation Notes](imagingstudy.html#dicom-uids) for encoding of DICOM Study Instance UID. - **Event.basedOn** → **ImagingStudy.basedOn** - missingTypes | reason=Reference type not relevant to resource | pattern=Reference(Request) - extraTypes | reason=Additional reference types are relevant to resource - shortUnmatched | reason=Proposal not relevant for this resource | pattern=Fulfills plan, proposal or order | resource=Fulfills plan or order - definitionUnmatched | reason=Proposal not relevant for this resource | pattern=A plan, proposal or order that is fulfilled in whole or in part by this imaging study. | resource=A plan or order that is fulfilled in whole or in part by this imaging study. - **Event.partOf** → **ImagingStudy.procedure** - missingTypes | reason=Reference type not relevant to resource | pattern=Reference(Event) - extraTypes | reason=Additional reference type is relevant to resource - shortUnmatched | reason=Meaning is more specific in this resource | pattern=Part of referenced event | resource=Imaging performed procedure(s) - definitionUnmatched | reason=Meaning is more specific in this resource | pattern=A larger event of which this particular imaging study is a component or step. | resource=The performed procedure(s) during which the data associated with this imaging study was created. - commentsUnmatched | reason=Context element not present in this resource | pattern=Not to be used to link an imaging study to an Encounter - use 'context' for that. | resource=To link an imaging study to an Encounter use `encounter`. - **Event.status** → **ImagingStudy.status** - shortUnmatched | reason=Imaging study status codes are specialized | pattern=preparation | in-progress | not-done | suspended | aborted | completed | entered-in-error | unknown | resource=registered | available | cancelled | entered-in-error | unknown | inactive - commentsUnmatched | reason=State transition diagram does not apply to imaging study statuses | pattern=A nominal state-transition diagram can be found in the (Event pattern documentation 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. | resource=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. - **Event.subject** → **ImagingStudy.subject** - extraTypes | reason=Phantoms can be subjects of imaging studies - shortUnmatched | reason=More specific definition used | pattern=Individual service was done for/to | resource=Who or what is the subject of the study - definitionUnmatched | reason=More specific definition used | pattern=The individual or set of individuals the action is being or was performed on. | resource=The subject, typically a patient, of the imaging study. - requirementsUnmatched | reason=Requirement is not needed for this resource | pattern=Links the imaging study to the Patient context. May also affect access control. - **Event.encounter** → **ImagingStudy.encounter** - shortUnmatched | reason=Imaging studies not generally part of an encounter | pattern=Encounter the imaging study is part of | resource=Encounter with which this imaging study is associated - definitionUnmatched | reason=Imaging studies not generally part of an encounter -- only loosely associated | pattern=The Encounter during which this imaging study was created or to which the creation of this record is tightly associated. | resource=The healthcare event (e.g. a patient and healthcare provider interaction) during which the imaging data represented by this imaging study was acquired. - commentsUnmatched | reason=Imaging studies not generally part of an encounter | pattern=This will typically be the encounter the imaging study was created during, but some imaging studys 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 lab tests). - requirementsUnmatched | reason=Requirement not needed for this resource | pattern=Links the imaging study to the Encounter context. May also affect access control. - **Event.occurrence[x]** → **ImagingStudy.started** - missingTypes | reason=Imaging study started is always an instant | pattern=Period, Timing - shortUnmatched | reason=Started is more specific than occurrence | pattern=When imaging study occurred/is occurring | resource=When the study was started - definitionUnmatched | reason=Started is more specific than occurrence | pattern=The date, period or timing when the imaging study did occur or is occurring. | resource=Date and time the study started. - commentsUnmatched | reason=Comment not relevant for this resource | pattern=This indicates when the activity actually occurred or is occurring, not when it was asked/requested/ordered to occur. For the latter, look at the occurence element of the Request this {{event}} is "basedOn". The status code allows differentiation of whether the timing reflects a historic event or an ongoing event. Ongoing events should not include an upper bound in the Period or Timing.bounds. . - **Event.performer** → **ImagingStudy.series.performer** - extraTypes | reason=Performer needs to be qualified with role - shortUnmatched | reason=Performer is at the series level not the imaging study level | pattern=Who performed imaging study and what they did | resource=Who performed the series - definitionUnmatched | reason=Performer is at the series level not the imaging study level | pattern=Indicates who or what performed the imaging study and how they were involved. | resource=Indicates who or what performed the series and how they were involved. - **Event.performer.function** → **ImagingStudy.series.performer.function** - bindingStrength | reason=Specific codes almost always applicable | pattern=example - **Event.performer.actor** → **ImagingStudy.series.performer.actor** - extraTypes | reason=HealthcareService is a possible performer for an ImagingStudy.series - **Event.reason** → **ImagingStudy.reason** - definitionUnmatched | reason=Patterns has unnecessary capital | pattern=Describes why the imaging study occurred in coded or textual form or Indicates another resource whose existence justifies this imaging study. | resource=Describes why the imaging study occurred in coded or textual form or indicates another resource whose existence justifies this imaging study. - commentsUnmatched | reason=Imaging study does not contain text element | pattern=Textual reasons can be captured using reasonCode.text. | resource=This MAY correspond to the indications or reasons encoded in an associated service request. - **Event.note** → **ImagingStudy.note** - summary | reason=All elements above instance level are included in summary by convention | pattern=false - shortUnmatched | reason=More specific definition used | pattern=Comments made about the event | resource=Comments made about the imaging study ### Unmapped Elements - **Event.reported** — Not relevant for this resource - **Event.relevantHistory** — Not relevant for this resource - **Event.code** — Not relevant for this resource - **Event.statusReason** — Not relevant for this resource - **Event.category** — Not relevant for this resource - **Event.recorded** — Not relevant for this resource - **Event.product** — Not relevant for this resource - **Event.researchStudy** — Not relevant for this resource ### imagingstudy-fivews-mapping-exceptions.xml ### Unmapped Elements - **FiveWs.what** — Not relevant for this resource - **FiveWs.recorded** — Not relevant for this resource - **FiveWs.author** — Not relevant for this resource - **FiveWs.version** — Not relevant for this resource - **FiveWs.witness** — Not relevant for this resource - **FiveWs.source** — Not relevant for this resource - **FiveWs.who** — Not relevant for this resource - **FiveWs.grade** — Not relevant for this resource - **FiveWs.planned** — Not relevant for this resource - **FiveWs.done** — Not relevant for this resource