STU 3 Ballot

This page is part of the FHIR Specification (v1.6.0: STU 3 Ballot 4). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions

10.8 Resource ImagingManifest - Content

Imaging Integration Work GroupMaturity Level: 1Compartments: Device, Patient, Practitioner, RelatedPerson

A manifest of a set of DICOM Service-Object Pair Instances (SOP Instances). The referenced SOP Instances (images or other content) are for a single patient, and may be from one or more studies. The referenced SOP Instances may have been selected for a purpose, such as conference, or consult. Reflecting a range of sharing purposes, typical ImagingManifest resources may include all SOP Instances in a study (perhaps for sharing through a Health Information Exchange); key images from multiple studies (for reference by a referring or treating physician); both a multi-frame ultrasound instance ("cine" video clip) and a set of measurements taken from that instance (for inclusion in a teaching file); and so on.

10.8.1 Scope and Usage

This resource provides information on a selected set of imaging objects, along with information on how to retrieve those instances (either in native DICOM format, or in a rendered format, such as JPEG), or launch an image viewer. The ImagingManifest is used to make available information concerning images etc. that are intended to be exchanged into other clinical contexts such as diagnostic reports, Care Plans, etc.

ImagingManifest provides a FHIR transformation of a DICOM Key Object Selection file as profiled by the IHE’s XDS-I profile. Although ImagingManifest can address certain uses outside XDS-I (such as launching a viewer), it does not provide the full capabilities of a general DICOM Key Object Selection.

More than one ImagingManifest may reference instances from a particular DICOM study (and ImagingStudy). A particular ImagingManifest may reference instances from more than one DICOM study (and ImagingStudy). An ImagingManifest may reference all instances, or only selected instances from a study.

10.8.2 Boundaries and Relationships

In distinction to ImagingStudy, this resource is a set of specifically selected objects, potentially from multiple studies on the same patient. ImagingStudy is intended as the resource that identifies a single complete study in itself.

10.8.3 Background and Context

This resource corresponds to a subset of the DICOM Key Object Selection (KOS) SOP Class, and provides a FHIR access to the content of KOS SOP Instances. The content is closely based on the definitions of the equivalent DICOM constructs, and informed by usage patterns already established through DICOM implementation practices, including IHE KIN, TCE, and XDS-I profiles.

The DICOM access methods provide access using the rich controls of the DICOM access methodology indicated. A DICOM capable client may use these access methods to gain full access to the DICOM objects and header.

This resource is referenced by diagnosticreport

10.8.4 Resource Content

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. ImagingManifest DomainResourceKey Object Selection
... uid Σ0..1oidSOP Instance UID
... patient Σ1..1Reference(Patient)Patient of the selected objects
... authoringTime Σ0..1dateTimeTime when the selection of instances was made
... author Σ0..1Reference(Practitioner | Device | Organization | Patient | RelatedPerson)Author (human or machine)
... title Σ1..1CodeableConceptReason for selection
KOStitle (Required)
... description Σ0..1stringDescription text
... study Σ1..*BackboneElementStudy identity of the selected instances
.... uid Σ1..1oidStudy instance UID
.... imagingStudy Σ0..1Reference(ImagingStudy)Reference to ImagingStudy
.... baseLocation 0..*BackboneElementStudy access service endpoint
..... type 1..1CodingWADO-RS | WADO-URI | IID
dWebType (Extensible)
..... url 1..1uriStudy access URL
.... series Σ1..*BackboneElementSeries identity of the selected instances
..... uid Σ1..1oidSeries instance UID
..... baseLocation 0..*BackboneElementSeries access endpoint
...... type 1..1CodingWADO-RS | WADO-URI | IID
dWebType (Extensible)
...... url 1..1uriSeries access URL
..... instance Σ1..*BackboneElementThe selected instance
...... sopClass Σ1..1oidSOP class UID of instance
...... uid Σ1..1oidSelected instance UID

doco Documentation for this format

UML Diagram (Legend)

ImagingManifest (DomainResource)Unique identifier of the the DICOM Key Object Selection (KOS) that this resource representsuid : oid [0..1]A patient resource reference which is the patient subject of all DICOM SOP Instances in this ImagingManifestpatient : Reference [1..1] « Patient »Date and time when the selection of the referenced instances were made. It is (typically) different from the creation date of the selection resource, and from dates associated with the referenced instances (e.g. capture time of the referenced image)authoringTime : dateTime [0..1]Author of ImagingManifest. It can be a human author or a device which made the decision of the SOP instances selected. For example, a radiologist selected a set of imaging SOP instances to attach in a diagnostic report, and a CAD application may author a selection to describe SOP instances it used to generate a detection conclusionauthor : Reference [0..1] « Practitioner|Device|Organization|Patient| RelatedPerson »The reason for, or significance of, the selection of objects referenced in the resourcetitle : CodeableConcept [1..1] « The document title code of key object selection (Strength=Required)KOStitle! »Text description of the DICOM SOP instances selected in the ImagingManifest. This should be aligned with the content of the title element, and can provide further explanation of the SOP instances in the selectiondescription : string [0..1]StudyStudy instance UID of the SOP instances in the selectionuid : oid [1..1]Reference to the Imaging Study in FHIR formimagingStudy : Reference [0..1] « ImagingStudy »StudyBaseLocationThe service type for accessing (e.g., retrieving, viewing) the DICOM instancestype : Coding [1..1] « The type of the service endpoint (Strength=Extensible)dWebType+ »The service URL for accessing the study. The interpretation of the URL depends on the type of the service specified in ImagingManifest.study.baseLocation.typeurl : uri [1..1]SeriesSeries instance UID of the SOP instances in the selectionuid : oid [1..1]SeriesBaseLocationThe service type for accessing (e.g., retrieving) the DICOM instancestype : Coding [1..1] « The type of the service endpoint (Strength=Extensible)dWebType+ »The service URL for accessing the study. The interpretation of the URL depends on the type of the service specified in ImagingManifest.study.series.baseLocation.typeurl : uri [1..1]InstanceSOP class UID of the selected instancesopClass : oid [1..1]SOP Instance UID of the selected instanceuid : oid [1..1]Methods of accessing (e.g., retrieving, viewing) the studybaseLocation[0..*]Methods of accessing (e.g. retrieving) the seriesbaseLocation[0..*]Identity and locating information of the selected DICOM SOP instancesinstance[1..*]Series identity and locating information of the DICOM SOP instances in the selectionseries[1..*]Study identity and locating information of the DICOM SOP instances in the selectionstudy[1..*]

XML Template

<ImagingManifest xmlns="http://hl7.org/fhir"> doco
 <!-- from Resource: id, meta, implicitRules, and language -->
 <!-- from DomainResource: text, contained, extension, and modifierExtension -->
 <uid value="[oid]"/><!-- 0..1 SOP Instance UID -->
 <patient><!-- 1..1 Reference(Patient) Patient of the selected objects --></patient>
 <authoringTime value="[dateTime]"/><!-- 0..1 Time when the selection of instances was made -->
 <author><!-- 0..1 Reference(Practitioner|Device|Organization|Patient|
   RelatedPerson) Author (human or machine) --></author>
 <title><!-- 1..1 CodeableConcept Reason for selection --></title>
 <description value="[string]"/><!-- 0..1 Description text -->
 <study>  <!-- 1..* Study identity of the selected instances -->
  <uid value="[oid]"/><!-- 1..1 Study instance UID -->
  <imagingStudy><!-- 0..1 Reference(ImagingStudy) Reference to ImagingStudy --></imagingStudy>
  <baseLocation>  <!-- 0..* Study access service endpoint -->
   <type><!-- 1..1 Coding WADO-RS | WADO-URI | IID --></type>
   <url value="[uri]"/><!-- 1..1 Study access URL -->
  </baseLocation>
  <series>  <!-- 1..* Series identity of the selected instances -->
   <uid value="[oid]"/><!-- 1..1 Series instance UID -->
   <baseLocation>  <!-- 0..* Series access endpoint -->
    <type><!-- 1..1 Coding WADO-RS | WADO-URI | IID --></type>
    <url value="[uri]"/><!-- 1..1 Series access URL -->
   </baseLocation>
   <instance>  <!-- 1..* The selected instance -->
    <sopClass value="[oid]"/><!-- 1..1 SOP class UID of instance -->
    <uid value="[oid]"/><!-- 1..1 Selected instance UID -->
   </instance>
  </series>
 </study>
</ImagingManifest>

Turtle Template

@prefix fhir: <http://hl7.org/fhir/> .doco


[ a fhir:ImagingManifest;
  fhir:nodeRole fhir:treeRoot; # if this is the parser root

  # from Resource: .id, .meta, .implicitRules, and .language
  # from DomainResource: .text, .contained, .extension, and .modifierExtension
  fhir:ImagingManifest.uid [ oid ]; # 0..1 SOP Instance UID
  fhir:ImagingManifest.patient [ Reference(Patient) ]; # 1..1 Patient of the selected objects
  fhir:ImagingManifest.authoringTime [ dateTime ]; # 0..1 Time when the selection of instances was made
  fhir:ImagingManifest.author [ Reference(Practitioner|Device|Organization|Patient|RelatedPerson) ]; # 0..1 Author (human or machine)
  fhir:ImagingManifest.title [ CodeableConcept ]; # 1..1 Reason for selection
  fhir:ImagingManifest.description [ string ]; # 0..1 Description text
  fhir:ImagingManifest.study [ # 1..* Study identity of the selected instances
    fhir:ImagingManifest.study.uid [ oid ]; # 1..1 Study instance UID
    fhir:ImagingManifest.study.imagingStudy [ Reference(ImagingStudy) ]; # 0..1 Reference to ImagingStudy
    fhir:ImagingManifest.study.baseLocation [ # 0..* Study access service endpoint
      fhir:ImagingManifest.study.baseLocation.type [ Coding ]; # 1..1 WADO-RS | WADO-URI | IID
      fhir:ImagingManifest.study.baseLocation.url [ uri ]; # 1..1 Study access URL
    ], ...;
    fhir:ImagingManifest.study.series [ # 1..* Series identity of the selected instances
      fhir:ImagingManifest.study.series.uid [ oid ]; # 1..1 Series instance UID
      fhir:ImagingManifest.study.series.baseLocation [ # 0..* Series access endpoint
        fhir:ImagingManifest.study.series.baseLocation.type [ Coding ]; # 1..1 WADO-RS | WADO-URI | IID
        fhir:ImagingManifest.study.series.baseLocation.url [ uri ]; # 1..1 Series access URL
      ], ...;
      fhir:ImagingManifest.study.series.instance [ # 1..* The selected instance
        fhir:ImagingManifest.study.series.instance.sopClass [ oid ]; # 1..1 SOP class UID of instance
        fhir:ImagingManifest.study.series.instance.uid [ oid ]; # 1..1 Selected instance UID
      ], ...;
    ], ...;
  ], ...;
]

Changes since DSTU2

This resource did not exist in Release 2

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. ImagingManifest DomainResourceKey Object Selection
... uid Σ0..1oidSOP Instance UID
... patient Σ1..1Reference(Patient)Patient of the selected objects
... authoringTime Σ0..1dateTimeTime when the selection of instances was made
... author Σ0..1Reference(Practitioner | Device | Organization | Patient | RelatedPerson)Author (human or machine)
... title Σ1..1CodeableConceptReason for selection
KOStitle (Required)
... description Σ0..1stringDescription text
... study Σ1..*BackboneElementStudy identity of the selected instances
.... uid Σ1..1oidStudy instance UID
.... imagingStudy Σ0..1Reference(ImagingStudy)Reference to ImagingStudy
.... baseLocation 0..*BackboneElementStudy access service endpoint
..... type 1..1CodingWADO-RS | WADO-URI | IID
dWebType (Extensible)
..... url 1..1uriStudy access URL
.... series Σ1..*BackboneElementSeries identity of the selected instances
..... uid Σ1..1oidSeries instance UID
..... baseLocation 0..*BackboneElementSeries access endpoint
...... type 1..1CodingWADO-RS | WADO-URI | IID
dWebType (Extensible)
...... url 1..1uriSeries access URL
..... instance Σ1..*BackboneElementThe selected instance
...... sopClass Σ1..1oidSOP class UID of instance
...... uid Σ1..1oidSelected instance UID

doco Documentation for this format

UML Diagram (Legend)

ImagingManifest (DomainResource)Unique identifier of the the DICOM Key Object Selection (KOS) that this resource representsuid : oid [0..1]A patient resource reference which is the patient subject of all DICOM SOP Instances in this ImagingManifestpatient : Reference [1..1] « Patient »Date and time when the selection of the referenced instances were made. It is (typically) different from the creation date of the selection resource, and from dates associated with the referenced instances (e.g. capture time of the referenced image)authoringTime : dateTime [0..1]Author of ImagingManifest. It can be a human author or a device which made the decision of the SOP instances selected. For example, a radiologist selected a set of imaging SOP instances to attach in a diagnostic report, and a CAD application may author a selection to describe SOP instances it used to generate a detection conclusionauthor : Reference [0..1] « Practitioner|Device|Organization|Patient| RelatedPerson »The reason for, or significance of, the selection of objects referenced in the resourcetitle : CodeableConcept [1..1] « The document title code of key object selection (Strength=Required)KOStitle! »Text description of the DICOM SOP instances selected in the ImagingManifest. This should be aligned with the content of the title element, and can provide further explanation of the SOP instances in the selectiondescription : string [0..1]StudyStudy instance UID of the SOP instances in the selectionuid : oid [1..1]Reference to the Imaging Study in FHIR formimagingStudy : Reference [0..1] « ImagingStudy »StudyBaseLocationThe service type for accessing (e.g., retrieving, viewing) the DICOM instancestype : Coding [1..1] « The type of the service endpoint (Strength=Extensible)dWebType+ »The service URL for accessing the study. The interpretation of the URL depends on the type of the service specified in ImagingManifest.study.baseLocation.typeurl : uri [1..1]SeriesSeries instance UID of the SOP instances in the selectionuid : oid [1..1]SeriesBaseLocationThe service type for accessing (e.g., retrieving) the DICOM instancestype : Coding [1..1] « The type of the service endpoint (Strength=Extensible)dWebType+ »The service URL for accessing the study. The interpretation of the URL depends on the type of the service specified in ImagingManifest.study.series.baseLocation.typeurl : uri [1..1]InstanceSOP class UID of the selected instancesopClass : oid [1..1]SOP Instance UID of the selected instanceuid : oid [1..1]Methods of accessing (e.g., retrieving, viewing) the studybaseLocation[0..*]Methods of accessing (e.g. retrieving) the seriesbaseLocation[0..*]Identity and locating information of the selected DICOM SOP instancesinstance[1..*]Series identity and locating information of the DICOM SOP instances in the selectionseries[1..*]Study identity and locating information of the DICOM SOP instances in the selectionstudy[1..*]

XML Template

<ImagingManifest xmlns="http://hl7.org/fhir"> doco
 <!-- from Resource: id, meta, implicitRules, and language -->
 <!-- from DomainResource: text, contained, extension, and modifierExtension -->
 <uid value="[oid]"/><!-- 0..1 SOP Instance UID -->
 <patient><!-- 1..1 Reference(Patient) Patient of the selected objects --></patient>
 <authoringTime value="[dateTime]"/><!-- 0..1 Time when the selection of instances was made -->
 <author><!-- 0..1 Reference(Practitioner|Device|Organization|Patient|
   RelatedPerson) Author (human or machine) --></author>
 <title><!-- 1..1 CodeableConcept Reason for selection --></title>
 <description value="[string]"/><!-- 0..1 Description text -->
 <study>  <!-- 1..* Study identity of the selected instances -->
  <uid value="[oid]"/><!-- 1..1 Study instance UID -->
  <imagingStudy><!-- 0..1 Reference(ImagingStudy) Reference to ImagingStudy --></imagingStudy>
  <baseLocation>  <!-- 0..* Study access service endpoint -->
   <type><!-- 1..1 Coding WADO-RS | WADO-URI | IID --></type>
   <url value="[uri]"/><!-- 1..1 Study access URL -->
  </baseLocation>
  <series>  <!-- 1..* Series identity of the selected instances -->
   <uid value="[oid]"/><!-- 1..1 Series instance UID -->
   <baseLocation>  <!-- 0..* Series access endpoint -->
    <type><!-- 1..1 Coding WADO-RS | WADO-URI | IID --></type>
    <url value="[uri]"/><!-- 1..1 Series access URL -->
   </baseLocation>
   <instance>  <!-- 1..* The selected instance -->
    <sopClass value="[oid]"/><!-- 1..1 SOP class UID of instance -->
    <uid value="[oid]"/><!-- 1..1 Selected instance UID -->
   </instance>
  </series>
 </study>
</ImagingManifest>

Turtle Template

@prefix fhir: <http://hl7.org/fhir/> .doco


[ a fhir:ImagingManifest;
  fhir:nodeRole fhir:treeRoot; # if this is the parser root

  # from Resource: .id, .meta, .implicitRules, and .language
  # from DomainResource: .text, .contained, .extension, and .modifierExtension
  fhir:ImagingManifest.uid [ oid ]; # 0..1 SOP Instance UID
  fhir:ImagingManifest.patient [ Reference(Patient) ]; # 1..1 Patient of the selected objects
  fhir:ImagingManifest.authoringTime [ dateTime ]; # 0..1 Time when the selection of instances was made
  fhir:ImagingManifest.author [ Reference(Practitioner|Device|Organization|Patient|RelatedPerson) ]; # 0..1 Author (human or machine)
  fhir:ImagingManifest.title [ CodeableConcept ]; # 1..1 Reason for selection
  fhir:ImagingManifest.description [ string ]; # 0..1 Description text
  fhir:ImagingManifest.study [ # 1..* Study identity of the selected instances
    fhir:ImagingManifest.study.uid [ oid ]; # 1..1 Study instance UID
    fhir:ImagingManifest.study.imagingStudy [ Reference(ImagingStudy) ]; # 0..1 Reference to ImagingStudy
    fhir:ImagingManifest.study.baseLocation [ # 0..* Study access service endpoint
      fhir:ImagingManifest.study.baseLocation.type [ Coding ]; # 1..1 WADO-RS | WADO-URI | IID
      fhir:ImagingManifest.study.baseLocation.url [ uri ]; # 1..1 Study access URL
    ], ...;
    fhir:ImagingManifest.study.series [ # 1..* Series identity of the selected instances
      fhir:ImagingManifest.study.series.uid [ oid ]; # 1..1 Series instance UID
      fhir:ImagingManifest.study.series.baseLocation [ # 0..* Series access endpoint
        fhir:ImagingManifest.study.series.baseLocation.type [ Coding ]; # 1..1 WADO-RS | WADO-URI | IID
        fhir:ImagingManifest.study.series.baseLocation.url [ uri ]; # 1..1 Series access URL
      ], ...;
      fhir:ImagingManifest.study.series.instance [ # 1..* The selected instance
        fhir:ImagingManifest.study.series.instance.sopClass [ oid ]; # 1..1 SOP class UID of instance
        fhir:ImagingManifest.study.series.instance.uid [ oid ]; # 1..1 Selected instance UID
      ], ...;
    ], ...;
  ], ...;
]

Changes since DSTU2

This resource did not exist in Release 2

 

Alternate definitions: Master Definition (XML, JSON), XML Schema/Schematron (for ) + JSON Schema, ShEx (for Turtle)

10.8.4.1 Terminology Bindings

PathDefinitionTypeReference
ImagingManifest.title The document title code of key object selectionRequiredKOStitle
ImagingManifest.study.baseLocation.type
ImagingManifest.study.series.baseLocation.type
The type of the service endpointExtensibledWebType

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

UID values follow the FHIR convention of expressing UIDs as URNs. For example, the DICOM Study Instance UID of 1.2.250.1.59.40211.12345678.678910 is expressed as “urn:oid:1.2.250.1.59.40211.12345678.678910”.

ImagingManifest.study.baseLocation and ImagingManifest.study.series.baseLocation can each list multiple methods to retrieve the study, series or instances. If a study-level baseLocation of a particular type is present, it shall be applicable to all listed series and instances in the study, unless overridden by a series-level baseLocation of that type. (Series-level locations can be provided because all series of a study are not guaranteed to be on the same server. For the identified retrieval mechanisms, the services supporting instance-level retrieval do not differ from the series-level services, thus instance-level baseLocation is not defined.)

The form, requirements, and necessary manipulation of the baseLocation.url depend on service identified in baseLocation.type:

10.8.4.2.1 WADO-URI

WADO-URI: baseLocation.url shall contain the scheme, authority, and path. Neither the 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 baseLocation.url.

For example, a native DICOM PS3.10 instance file can be retrieved (if consistent with the Accept header) by performing a GET on a URL constructed from a baseLocation.url of “https://pacs.hospital.org/wado-uri”, the study.uid value of “urn:oid:1.2.250.1.59.40211.12345678.678910”, study.series.uid value of “urn:oid:1.2.250.1.59.40211.789001276.14556172.67789”, and study.series.instance.uid value of “urn:oid:1.2.250.1.59.40211.2678810.87991027.899772.2”:


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.8.4.2.2 WADO-RS

WADO-RS: baseLocation.url shall contain the scheme, authority, and path of the service. Sub-services, such as study, shall not be specified. The path shall not contain a trailing slash.

The DICOM WADO-RS (Web Access to DICOM Objects, RESTful mode) service uses a RESTful approach to instance retrieval. This service allows for retrieval of native DICOM SOP instances, or instances “rendered” into other formats, including JPEG and MPEG. The media type of a response is specified by the request Accept header (preferred); or, by the accept query parameters. Supported media types depend on the 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 query to retrieve a DICOM instance is constructed by appending the appropriate sub-resource paths to baseLocation.url.

For example, a native DICOM PS3.10 instance file can be retrieved (if consistent with the Accept header) by performing a GET on a URL constructed from a baseLocation.url of “https://pacs.hospital.org/wado-rs”, the study.uid value of “urn:oid:1.2.250.1.59.40211.12345678.678910”, study.series.uid value of “urn:oid:1.2.250.1.59.40211.789001276.14556172.67789”, and study.series.instance.uid value of “urn:oid: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

Query parameters on the "rendered" sub-resource can control other aspects of the rendering including: the rendered dimensions, the quality (compression ratio), the region of interest to render, the brightness/contrast (window center/width) adjustments, and whether to “burn” patient or study demographics into the rendered result. Specific frames of a multi-frame instance may be retrieved using the frames sub-resource.

For example, provided the Accept header indicates a preference for image/jpeg, the example above can be extended with parameters that cause a JPEG thumbnail (100 columns by 100 rows) of a region extending from the top-left corner of the original image, across 1000 and down 3000 pixels, to be retrieved (additional sub-resource and parameters emphasized):


https://pacs.hospital.org/wado-rs/studies/1.2.250.1.59.40211.12345678.678910/series/1.2.250.1.59.40211.789001276.14556172.67789/instances/1.2.250.1.59.40211.2678810.87991027.899772.2/rendered?viewport=100,100,0,0,1000,3000

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

10.8.4.2.3 IID

IID: baseLocation.url shall contain the scheme, authority, and path. Neither the 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 baseLocation.type should be used only at the study level. As well 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 baseLocation.url.

For example, given a baseLocation.url of https://pacs.hospital.org/IHEInvokeImageDisplay, 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:


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 .

10.8.4.3 Use Case

10.8.4.3.1 EHR access to imaging studies

Amy, a family physician, is accessing a cross-enterprise document registry that contains radiology objects (IHE Radiology XDS-I ), to discover studies for her patient, Alex. Her EHR client makes a FHIR call for all ImagingManifest objects available for Alex. In the response, she is able to get study identifiers for each study that has been published to the registry. 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 ImagingManifest. In each result, there is a reference to the ImagingStudy FHIR object which can provide more information about each study.

10.8.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 DiagnosticRequest 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 DiagnosticRequest. (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 DiagnosticRequest 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 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 resource, and inserts the referenced key images into the report.

Dr. Down meets again with Joe, and they review the results of the stress test. Joe has a question about the findings that the key images in the report do not show, so Dr. Down uses the Local MultiClinic EMR to query the PACS for the full ImagingStudy resource, and uses the references there to open an image display for the full study. Joe agrees to proceed to catheterization, and Dr. Down sends a referral to the Ginormous University Hospital cath department, and triggers the PACS to share the echo study through the Metropolitan Health Information Exchange.

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

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

NameTypeDescriptionPaths
authorreferenceAuthor of key DICOM object selectionImagingManifest.author
(Practitioner, Organization, Device, Patient, RelatedPerson)
authoring-timedateTime of key DICOM object selection authoringImagingManifest.authoringTime
identifieruriUID of key DICOM object selectionImagingManifest.uid
patientreferenceSubject of key DICOM object selectionImagingManifest.patient
(Patient)
selected-studyuriStudy selected in key DICOM object selectionImagingManifest.study.uid
titletokenTitle of key DICOM object selectionImagingManifest.title