STU3 Candidate
DiagnosticsThis page is part of the FHIR Specification (v1.8.0: STU 3 Draft). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions 
| Imaging Integration Work Group | Maturity Level: 1 | Compartments: 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.
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.
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.
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
Structure
| Name | Flags | Card. | Type | Description & Constraints |
|---|---|---|---|---|
  ImagingManifest | DomainResource | Key Object Selection | ||
  uid | Σ | 0..1 | oid | SOP Instance UID |
 patient | Σ | 1..1 | Reference(Patient) | Patient of the selected objects |
| authoringTime | Σ | 0..1 | dateTime | Time when the selection of instances was made |
| author | Σ | 0..1 | Reference(Practitioner | Device | Organization | Patient | RelatedPerson) | Author (human or machine) |
 title | Σ | 1..1 | CodeableConcept | Reason for selection KOStitle (Required) |
| description | Σ | 0..1 | string | Description text |
  study | Σ | 1..* | BackboneElement | Study identity of the selected instances |
 uid | Σ | 1..1 | oid | Study instance UID |
| imagingStudy | Σ | 0..1 | Reference(ImagingStudy) | Reference to ImagingStudy |
| baseLocation | 0..* | BackboneElement | Study access service endpoint | |
 type | 1..1 | Coding | WADO-RS | WADO-URI | IID dWebType (Extensible) | |
| url | 1..1 | uri | Study access URL | |
| series | Σ | 1..* | BackboneElement | Series identity of the selected instances |
| uid | Σ | 1..1 | oid | Series instance UID |
| baseLocation | 0..* | BackboneElement | Series access endpoint | |
| type | 1..1 | Coding | WADO-RS | WADO-URI | IID dWebType (Extensible) | |
| url | 1..1 | uri | Series access URL | |
| instance | Σ | 1..* | BackboneElement | The selected instance |
| sopClass | Σ | 1..1 | oid | SOP class UID of instance |
| uid | Σ | 1..1 | oid | Selected instance UID |
| Documentation for this format | ||||
UML Diagram (Legend)
XML Template
<ImagingManifest xmlns="http://hl7.org/fhir"><!-- 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>
JSON Template
{
"resourceType" : "ImagingManifest",
// from Resource: id, meta, implicitRules, and language
// from DomainResource: text, contained, extension, and modifierExtension
"uid" : "<oid>", // SOP Instance UID
"patient" : { Reference(Patient) }, // R! Patient of the selected objects
"authoringTime" : "<dateTime>", // Time when the selection of instances was made
"author" : { Reference(Practitioner|Device|Organization|Patient|
RelatedPerson) }, // Author (human or machine)
"title" : { CodeableConcept }, // R! Reason for selection
"description" : "<string>", // Description text
"study" : [{ // R! Study identity of the selected instances
"uid" : "<oid>", // R! Study instance UID
"imagingStudy" : { Reference(ImagingStudy) }, // Reference to ImagingStudy
"baseLocation" : [{ // Study access service endpoint
"type" : { Coding }, // R! WADO-RS | WADO-URI | IID
"url" : "<uri>" // R! Study access URL
}],
"series" : [{ // R! Series identity of the selected instances
"uid" : "<oid>", // R! Series instance UID
"baseLocation" : [{ // Series access endpoint
"type" : { Coding }, // R! WADO-RS | WADO-URI | IID
"url" : "<uri>" // R! Series access URL
}],
"instance" : [{ // R! The selected instance
"sopClass" : "<oid>", // R! SOP class UID of instance
"uid" : "<oid>" // R! Selected instance UID
}]
}]
}]
}
Turtle Template
@prefix fhir: <http://hl7.org/fhir/> .
Changes since DSTU2
This resource did not exist in Release 2
Structure
| Name | Flags | Card. | Type | Description & Constraints |
|---|---|---|---|---|
| ImagingManifest | DomainResource | Key Object Selection | ||
| uid | Σ | 0..1 | oid | SOP Instance UID |
| patient | Σ | 1..1 | Reference(Patient) | Patient of the selected objects |
| authoringTime | Σ | 0..1 | dateTime | Time when the selection of instances was made |
| author | Σ | 0..1 | Reference(Practitioner | Device | Organization | Patient | RelatedPerson) | Author (human or machine) |
| title | Σ | 1..1 | CodeableConcept | Reason for selection KOStitle (Required) |
| description | Σ | 0..1 | string | Description text |
| study | Σ | 1..* | BackboneElement | Study identity of the selected instances |
| uid | Σ | 1..1 | oid | Study instance UID |
| imagingStudy | Σ | 0..1 | Reference(ImagingStudy) | Reference to ImagingStudy |
| baseLocation | 0..* | BackboneElement | Study access service endpoint | |
| type | 1..1 | Coding | WADO-RS | WADO-URI | IID dWebType (Extensible) | |
| url | 1..1 | uri | Study access URL | |
| series | Σ | 1..* | BackboneElement | Series identity of the selected instances |
| uid | Σ | 1..1 | oid | Series instance UID |
| baseLocation | 0..* | BackboneElement | Series access endpoint | |
| type | 1..1 | Coding | WADO-RS | WADO-URI | IID dWebType (Extensible) | |
| url | 1..1 | uri | Series access URL | |
| instance | Σ | 1..* | BackboneElement | The selected instance |
| sopClass | Σ | 1..1 | oid | SOP class UID of instance |
| uid | Σ | 1..1 | oid | Selected instance UID |
| Documentation for this format | ||||
XML Template
<ImagingManifest xmlns="http://hl7.org/fhir">
JSON Template
{
"resourceType" : "ImagingManifest",
// from Resource: id, meta, implicitRules, and language
// from DomainResource: text, contained, extension, and modifierExtension
"uid" : "<oid>", // SOP Instance UID
"patient" : { Reference(Patient) }, // R! Patient of the selected objects
"authoringTime" : "<dateTime>", // Time when the selection of instances was made
"author" : { Reference(Practitioner|Device|Organization|Patient|
RelatedPerson) }, // Author (human or machine)
"title" : { CodeableConcept }, // R! Reason for selection
"description" : "<string>", // Description text
"study" : [{ // R! Study identity of the selected instances
"uid" : "<oid>", // R! Study instance UID
"imagingStudy" : { Reference(ImagingStudy) }, // Reference to ImagingStudy
"baseLocation" : [{ // Study access service endpoint
"type" : { Coding }, // R! WADO-RS | WADO-URI | IID
"url" : "<uri>" // R! Study access URL
}],
"series" : [{ // R! Series identity of the selected instances
"uid" : "<oid>", // R! Series instance UID
"baseLocation" : [{ // Series access endpoint
"type" : { Coding }, // R! WADO-RS | WADO-URI | IID
"url" : "<uri>" // R! Series access URL
}],
"instance" : [{ // R! The selected instance
"sopClass" : "<oid>", // R! SOP class UID of instance
"uid" : "<oid>" // R! Selected instance UID
}]
}]
}]
}
Turtle Template
@prefix fhir: <http://hl7.org/fhir/> .
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), JSON-LD (for RDF as JSON-LD),
| Path | Definition | Type | Reference |
|---|---|---|---|
| ImagingManifest.title | The document title code of key object selection | Required | KOStitle |
| ImagingManifest.study.baseLocation.type ImagingManifest.study.series.baseLocation.type | The type of the service endpoint | Extensible | dWebType |
A referenced DICOM SOP instance could be:
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:
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®ion=0,0,0.5,1
For further details on DICOM WADO-URI capabilities including additional rendering parameters,
see DICOM PS 3.18 .
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 .
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 .
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.
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.
Search parameters for this resource. The common parameters also apply. See Searching for more information about searching in REST, messaging, and services.
| Name | Type | Description | Paths | In Common |
| author | reference | Author of key DICOM object selection | ImagingManifest.author (Practitioner, Organization, Device, Patient, RelatedPerson) | |
| authoring-time | date | Time of key DICOM object selection authoring | ImagingManifest.authoringTime | |
| identifier | uri | UID of key DICOM object selection | ImagingManifest.uid | |
| patient | reference | Subject of key DICOM object selection | ImagingManifest.patient (Patient) | 31 Resources |
| selected-study | uri | Study selected in key DICOM object selection | ImagingManifest.study.uid | |
| title | token | Title of key DICOM object selection | ImagingManifest.title |
© HL7.org 2011+. FHIR STU3 Candidate (v1.8.0-10521) generated on Tue, Dec 6, 2016 12:26+1100. QA Page
Links: Search |
Version History |
Table of Contents |
Compare to DSTU2 |
|
Propose a change