Versions Compared

Old Version 7

changes.mady.by.user Jonathan Whitby

Saved on

compared with

New Version Current

changes.mady.by.user Abderrazek Boufahja

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Page properties


Short Description

Test imaging-related resources and implementation guides.

Long Description

The objectives of this track are:

  • Test ImagingStudy resource core use cases
    • Integration between enterprise imaging and EMR
    • Combined image and document viewing
  • Test DICOM SR to FHIR Resource Mapping IG and ImagingSelection resource
  • Test Integration between FHIR and DICOMweb

Type

  • Test the design of a resource
  • Test a FHIR IG

Submitting Work Group/Project/Accelerator/Affiliate/Implementer Group  

Imaging Integration

Track Lead(s)

Jonathan Whitby - Jonathan.Whitby@mi.medical.canon (zulip), Abderrazek Boufahja - Abderrazek.BOUFAHJA@ge.com (zulip)

Track Lead Email(s)

Jonathan.Whitby@mi.medical.canon; Abderrazek.BOUFAHJA@ge.com

Related Tracks

FHIR Version

Current Build

Specification(s) this track uses

Resources:

Implementation Guides:

Artifacts of focus

Expected participants

Participants types:

  • PACS / VNA / Enterprise Imaging Repository applications
  • EMR applications
  • Enterprise Image Viewer applications

Zulip stream

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

Track Kick Off Call

Rescheduled – will be first session of Connectathon track: 10:00AM Eastern

Track Details

System roles

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

  • Host a DICOMweb endpoint to find and retrieve images
  • (Optional) Host a DICOMweb endpoint to store images
  • Provide a means of populating an ImagingStudy endpoint. At least one of:
    • Hosting ImagingStudy resources reflected available imaging studies
    • Calling create API against an externally-hosted FHIR ImagingStudy endpoint
    • Sending a FHIR message containing an ImagingStudy resource bundle
  • (Optional) Update ImagingStudy results based on DICOMweb store requests

Role 2 Name: EMR

  • Host or provide access to ImagingStudy resources
    • i.e. can host ImagingStudy resource populated based on Archive contents or search for Archive-hosted resources on demand
  • Host FHIR endpoint for image-related resources
  • (Optional) Can launch Enterprise Image Viewer

Role 3 Name: Enterprise Image Viewer (Viewer)

  • Can search FHIR / DICOMweb endpoints for imaging studies and related resources
  • Can retrieve and display imaging studies and related resources

Role 4 Name: Imaging Result Creator

  • Create and store imaging Observation resources
    • Extracted from a DICOM measurement report
  • (Optional) Create and store DICOM images and / or structured reports

Role 5 Name: Imaging Study Proxy

  • Host ImagingStudy resources
    • Populated based on contents of one or more archives
  • (Optional) Update ImagingStudy results based on DICOMweb store requests


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

Scenario: DICOM SR to FHIR Resource Mapping IG

  1. Action: Imaging Result Creator stores imaging observations in EMR / Archive
    • Precondition: Imaging observations created according to IG
    • Success Criteria: DICOM SR content stored as FHIR observations
    • Bonus Point: Associated ImagingSelection resources are created
    • Test Scripts: To be created
  2. Action: EMR / Viewer displays imaging observations 
    • Success Criteria: EMR / Viewer displays imaging observations
    • Bonus point: imaging observations displayed alongside associated ImagingStudy
    • Test Script: To be created DicomSrMappingCollection.xml (test diagram here)
  3. Action: Imaging Result Creator stores a DICOM TID1500 Measurement Report using DICOMweb
    • Success Criteria: Observations are created and stored in accordance with DICOM SR to FHIR Resource Mapping IG

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


...