Short Description

Test imaging-related resources and implementation guides

Long Description

The primary objective of this track is:

  • ImagingStudy resource use cases
    • Resource creation and updating
    • Resource hosting – image archive vs. EMR
      • Synchronization between the two
    • Integration between FHIR and DICOMweb

Secondary objective:

  • Review / discussion of in-progress Imaging ServiceRequest Profile IG

Type

Test resource use cases

Related Tracks?

FHIRcast (if running)

Call for participants

Imaging applications, imaging AI applications, EMR

Track Prerequisites

The focus of this track is the interaction between imaging systems and the EMR. Track participants should be familiar with at least some of:

  • FHIR image-related resources
  • DICOMweb

Track Lead(s)

Jonathan Whitby 

Track Lead Email(s)

Jonathan.Whitby@mi.medical.canon

Specification Information

Zulip stream

https://chat.fhir.org/#narrow/stream/316835-imaging/topic/connectathon-34

Track Kick off Call

10 AM Eastern

Recording: Connectathon 34 Imaging Track Kick Off-20230829_100442-Meeting Recording.mp4

Testing Scenario:

System roles

Role 1 Name: PACS / VNA / Enterprise Imaging Repository (Archive)

  • Host a DICOMweb endpoint to find and retrieve images
  • (Optional) Create ImagingStudy resources
    • Includes updating to support changes
  • (Optional) Host ImagingStudy resources
    • Includes search capabilities
  • (Optional) Host ImagingSelection resources
    • Includes search capabilities

Role 2 Name: ImagingStudy creator

  • Create ImagingStudy resources in response to DICOM studies being created
  • Update ImagingStudy resources in response to DICOM studies being updated
  • May be Archive (Role 1) or EMR (Role 3)

Role 3 Name: EMR

  • (Optional) Host ImagingStudy resources
    • Includes search capabilities
  • (Optional) Host ImagingSelection resources
    • Includes search capabilities
  • Host FHIR endpoint for image-related resources
    • e.g.
      • Observations relating to an ImagingStudy
      • Patients with one or more ImagingStudy resources
      • Service Requests relating to an ImagingStudy
      • Practitioner relating to referrer of ImagingStudy as this may have security implications 

Role 4 Name: Enterprise Image Viewer (Viewer)

  • Can search FHIR / DICOMweb endpoints for ImagingStudy and related resources
  • Can retrieve and display image instances and related resources

Scenario: ImagingStudy resource creation and management

  1. Action: DICOM study is created and stored in Archive
    • Archive accepts image via DIMSE or STOW
    • Archive shall have DICOMweb services for search/retrieval (QIDO/WADO) 
  2. Action: ImagingStudy resource is created
    • For each unique Study Instance UID in the Archive an ImagingStudy resource should exist
    • Associate ImagingStudy resources with existing Patient, ServiceRequest, Referrer etc. if they exist
    • Create related identifiers if related resources do not exist
      • If not done for Patient, as it is a required field, archive may refer to itself and Patient ID?
    • (detail to be added)
  3. Action: DICOM study is updated
    • A change is made to the study which affects the values of the created ImagingStudy resource
      • For example number of series was in original resource and the report SR is added
    • Archive stores updated objects
    • (detail to be added)
  4. Action: ImagingStudy resource is updated
    • Associate ImagingStudy resources with existing Patient, ServiceRequest, etc. if they exist
    • Create related identifiers if related resources do not exist
    • ImagingStudy resource is versioned to reflect the current state
    • (detail to be added)

Scenario: FHIR-enhanced Enterprise Viewer

  1. Action: EMR / Viewer searches for available imaging studies
    • Precondition: User is logged into EMR / Viewer
    • Success Criteria: The set of available imaging studies is displayed
    • Bonus point: All ImagingStudy search fields are tested
    • Test Script(s): FHIREnhancedViewerSearchParam.xml (test diagram here)
  2. Action: Viewer loads imaging study – directly or launched by EMR
    • Precondition: ImagingStudy contains a valid DICOMweb endpoint that corresponds to a participating Archive
    • Success Criteria: The Viewer requests the images from a DICOMweb Endpoint in the Imaging Study and then displays them
    • Bonus point: EMR / Viewer integration passes launch context from ImagingStudy, such as:
      • ImagingStudy _id / URL
      • DICOMweb endpoint
    • Test Script(s): FHIREnhancedViewerEndpointAccess.xml (test diagram here) 
  3. Action: EMR / Viewer displays related FHIR resources 
    • Precondition: EMR or Archive hosts FHIR resources that share context – Patient, ServiceRequest, Procedure, etc. – with ImagingStudy
    • Success Criteria: The EMR or Viewer displays associated FHIR resources
    • Test Script(s): FHIREnhancedViewerRelatedResources.xml (test diagram here)
  4. Action: EMR / Viewer searches for and displays FHIR resources associated with an Imaging Study
    • Precondition: EMR or Archive hosts FHIR resources that reference ImagingStudy resources
    • Success Criteria: The EMR or Viewer displays associated FHIR resources
    • Bonus points: Multiple resource types:
      • DiagnosticReport
      • Observation
      • Radiation Dose Summary
      • Ophthalmologic Observation
    • Test Script(s): FHIREnhancedViewerAssociatedResources.xml (test diagram here)
  5. Action: Imaging Result Creator stores additional DICOM instances via DICOMweb
    • Precondition: ImagingStudy contains a valid DICOMweb endpoint that corresponds to a participating Archive
    • Success Criteria: The DICOMweb storage request is accepted and the associated ImagingStudy is updated to reflect the additional instances

Security and Privacy Considerations:

  • Mutual TLS is recommended but not required
  • If testing EMR / EIV application launching is included, a shared authentication mechanism is recommended but not required