[go: up one dir, main page]

FHIR Release 3 (STU)

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

10.4 Resource ImagingManifest - Content

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

A text description of the DICOM SOP instances selected in the ImagingManifest; or the reason for, or significance of, the selection.

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

NameFlagsCard.TypeDescription & Constraintsdoco
.. ImagingManifest DomainResourceKey Object Selection
Elements defined in Ancestors: id, meta, implicitRules, language, text, contained, extension, modifierExtension
... identifier Σ0..1IdentifierSOP 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)
... description Σ0..1stringDescription text
... study Σ1..*BackboneElementStudy identity of the selected instances
.... uid Σ1..1oidStudy instance UID
.... imagingStudy Σ0..1Reference(ImagingStudy)Reference to ImagingStudy
.... endpoint Σ0..*Reference(Endpoint)Study access service endpoint
.... series Σ1..*BackboneElementSeries identity of the selected instances
..... uid Σ1..1oidSeries instance UID
..... endpoint Σ0..*Reference(Endpoint)Series access endpoint
..... 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 DICOM Key Object Selection (KOS) that this resource representsidentifier : Identifier [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 Free text narrative description of the ImagingManifest. The value may be derived from the DICOM Standard Part 16, CID-7010 descriptions (e.g. Best in Set, Complete Study Content). Note that those values cover the wide range of uses of the DICOM Key Object Selection object, several of which are not supported by ImagingManifest. Specifically, there is no expected behavior associated with descriptions that suggest referenced images be removed or not useddescription : 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 The network service providing access (e.g., query, view, or retrieval) for the study. See implementation notes for information about using DICOM endpoints. A study-level endpoint applies to each series in the study, unless overridden by a series-level endpoint with the same Endpoint.typeendpoint : Reference [0..*] Endpoint SeriesSeries instance UID of the SOP instances in the selectionuid : oid [1..1]The network service providing access (e.g., query, view, or retrieval) for this series. See implementation notes for information about using DICOM endpoints. A series-level endpoint, if present, has precedence over a study-level endpoint with the same Endpoint.typeendpoint : Reference [0..*] Endpoint InstanceSOP class UID of the selected instancesopClass : oid [1..1]SOP Instance UID of the selected instanceuid : oid [1..1]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 -->
 <identifier><!-- 0..1 Identifier SOP Instance UID --></identifier>
 <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>
 <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>
  <endpoint><!-- 0..* Reference(Endpoint) Study access service endpoint --></endpoint>
  <series>  <!-- 1..* Series identity of the selected instances -->
   <uid value="[oid]"/><!-- 1..1 Series instance UID -->
   <endpoint><!-- 0..* Reference(Endpoint) Series access endpoint --></endpoint>
   <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.identifier [ Identifier ]; # 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.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.endpoint [ Reference(Endpoint) ], ... ; # 0..* Study access service endpoint
    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.endpoint [ Reference(Endpoint) ], ... ; # 0..* Series access endpoint
      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

This analysis is available as XML or JSON.

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. ImagingManifest DomainResourceKey Object Selection
Elements defined in Ancestors: id, meta, implicitRules, language, text, contained, extension, modifierExtension
... identifier Σ0..1IdentifierSOP 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)
... description Σ0..1stringDescription text
... study Σ1..*BackboneElementStudy identity of the selected instances
.... uid Σ1..1oidStudy instance UID
.... imagingStudy Σ0..1Reference(ImagingStudy)Reference to ImagingStudy
.... endpoint Σ0..*Reference(Endpoint)Study access service endpoint
.... series Σ1..*BackboneElementSeries identity of the selected instances
..... uid Σ1..1oidSeries instance UID
..... endpoint Σ0..*Reference(Endpoint)Series access endpoint
..... 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 DICOM Key Object Selection (KOS) that this resource representsidentifier : Identifier [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 Free text narrative description of the ImagingManifest. The value may be derived from the DICOM Standard Part 16, CID-7010 descriptions (e.g. Best in Set, Complete Study Content). Note that those values cover the wide range of uses of the DICOM Key Object Selection object, several of which are not supported by ImagingManifest. Specifically, there is no expected behavior associated with descriptions that suggest referenced images be removed or not useddescription : 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 The network service providing access (e.g., query, view, or retrieval) for the study. See implementation notes for information about using DICOM endpoints. A study-level endpoint applies to each series in the study, unless overridden by a series-level endpoint with the same Endpoint.typeendpoint : Reference [0..*] Endpoint SeriesSeries instance UID of the SOP instances in the selectionuid : oid [1..1]The network service providing access (e.g., query, view, or retrieval) for this series. See implementation notes for information about using DICOM endpoints. A series-level endpoint, if present, has precedence over a study-level endpoint with the same Endpoint.typeendpoint : Reference [0..*] Endpoint InstanceSOP class UID of the selected instancesopClass : oid [1..1]SOP Instance UID of the selected instanceuid : oid [1..1]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 -->
 <identifier><!-- 0..1 Identifier SOP Instance UID --></identifier>
 <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>
 <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>
  <endpoint><!-- 0..* Reference(Endpoint) Study access service endpoint --></endpoint>
  <series>  <!-- 1..* Series identity of the selected instances -->
   <uid value="[oid]"/><!-- 1..1 Series instance UID -->
   <endpoint><!-- 0..* Reference(Endpoint) Series access endpoint --></endpoint>
   <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.identifier [ Identifier ]; # 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.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.endpoint [ Reference(Endpoint) ], ... ; # 0..* Study access service endpoint
    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.endpoint [ Reference(Endpoint) ], ... ; # 0..* Series access endpoint
      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

This analysis is available as XML or JSON.

 

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

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

The ImagingManifest.study.endpoint elements and ImagingManifest.study.series.endpoint elements indicate network services that can be used to access the studies, series, or instances; for example, a DICOM WADO-RS server. An ImagingManifest.study.series.endpoint of a particular Endpoint.connectionType provides that service for that series, and all contained instances. An ImagingManifest.study.endpoint of a particularconnection type provides that service for all series in that study that do not have a specified Endpoint of that type, and their contained instances. That is, an ImagingManifest.study.series.endpoint overrides a ImagingManifest.study.endpoint of the same connection type. (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 may have different capabilities, protocols or requirements; and the specified Endpoint.url may require manipulation. For the details on use of imaging-related Endpoint connection types, See ImagingStudy Implementation Notes for details.

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 ProcedureRequest resource with the details of the request. The order is scheduled and assigned to cardiologist Dr. Art Skann, also at Local MultiClinic.

On the scheduled day of the exam, Joe arrives at the echo lab to meet with Dr. Skann and have the study done. Dr. Skann’s workstation shows the daily list of Task, and he follows the link to retrieve the ProcedureRequest. (He may follow the links through the referenced Patient resource to access Joe’s electronic medical record, but that is not the concern of this storyboard.)

The Task and ProcedureRequest 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.

NameTypeDescriptionExpressionIn Common
authorreferenceAuthor of the ImagingManifest (or a DICOM Key Object Selection which it represents)ImagingManifest.author
(Practitioner, Organization, Device, Patient, RelatedPerson)
authoring-timedateTime of the ImagingManifest (or a DICOM Key Object Selection which it represents) authoringImagingManifest.authoringTime
endpointreferenceThe endpoint for the study or seriesImagingManifest.study.endpoint | ImagingManifest.study.series.endpoint
(Endpoint)
identifiertokenUID of the ImagingManifest (or a DICOM Key Object Selection which it represents)ImagingManifest.identifier
imaging-studyreferenceImagingStudy resource selected in the ImagingManifest (or a DICOM Key Object Selection which it represents)ImagingManifest.study.imagingStudy
(ImagingStudy)
patientreferenceSubject of the ImagingManifest (or a DICOM Key Object Selection which it represents)ImagingManifest.patient
(Patient)
31 Resources
selected-studyuriStudy selected in the ImagingManifest (or a DICOM Key Object Selection which it represents)ImagingManifest.study.uid