This wiki has undergone a migration to Confluence found Here

PACS FHIR Profile Proposal

From HL7Wiki
Revision as of 23:06, 26 January 2016 by Esilver (talk | contribs) (PACS FHIR Profile proposal)
Jump to navigation Jump to search


Profile balloting plans

This profile will outline the best practice and provide a baseline for use of Imaging Study (and related resources) when the images are stored on a PACS or VNA imaging system with WADO-RS capabilities.

Inclusion in the core specification will lead to the broadest adoption, however we are open to discussion of this as a separate Implementation Guide.

Profile Details

Profiled Resource(s)

The main resource to be profiled is:

The following resources are referenced from ImagingStudy and *may* be additionally profiled to support profiling of ImagingStudy.

The following resource is closely related to ImagingStudy and may also be profiled.

Constraints to be Applied

  • Certain optional elements (e.g. ImagingStudy.url, ImagingStudy.series.number, ImagingStudy.series.instance.content) will be made required.
  • Use of will be prohibited (this constraint may be made into a separate profile to provide more flexibility for implementors)
  • Specific ImagingStudy.series.instance.content.title values may be documented to distinguish of URLs for thumbnails, full resolution, etc.

Extensions to be Applied

  • Extensions may be defined (e.g., WADO-RS conformance URL)

Example Scenarios

ImagingStudy was defined with a primary, but not exclusive use case of accessing imaging stored in a PACS or VNA (collectively, image archives). This profile is designed to narrow the profile so that it exactly targets that use case. A chief issue addressed is that ImagingStudy as designed is allowed to contain the actual image binaries inline. Individual images can be several megabytes, and studies can contain thousands of images. The profile will prohibit inline inclusion of the images; a consumer can narrow their search to only ImagingStudies claiming this profile and be assured that the size of the returned resource is "reasonable".

In the base ImagingStudy resource, even if inline binary image data is not used, the urls are permitted to resolve to static files, WADO-URI or other endpoints. This profile will indicate to the consumer that the urls are to WADO-RS endpoints, and therefore can expect certain behaviors. WADO-RS (and WADO-URI) endpoints can provide images in consumer-friendly formats as well as native DICOM format; embedded binaries or linked static files are likely to only a single format.

Example: a user wants to view images from a study on their mobile device. The device is capable only of displaying consumer image formats (e.g. JPG). If the application requests all ImagingStudy objects for a particular patient from the FHIR server, it may be overwhelmed by the size of the response, or unable to display referenced DICOM format images. By requesting only ImagingStudy object meeting this profile, the application knows that it will be able to retrieve the individual images, as needed, in a handled format.

Scope of coverage

This Profile is agnostic to human/non-human/non-patient subjects (to the degree the underlying Resource is) This Profile is largely agnostic to the discipline in which imaging is used. However, to the degree that some disciplines primarily use non-DICOM image capture (e.g. consumer cameras) and that those images could stored in an ImagingStudy resource, the profile will exclude those uses. But, given that making this distinction is exactly the use case for the profile, it is a reasonable limit on the scope. This Profile does not distinguish between delivery environments. However, similar to discipline considerations, DICOM imaging backed by an archive will be encountered in certain delivery environments (primarily hospitals and imaging centers) more than others. The profile will benefit those environments more than others. This Profile does not distinguish locales, and the DICOM imaging it supports is used world-wide.


This profile is realm neutral.


Owning committee name

Imaging Integration WG

Contributing or Reviewing Work Groups

  • None

Expected implementations

  • DICOM archive vendors that create ImagingStudy resources will likely implement the profile
  • FHIR servers vendors may require this profile on created ImagingStudy resources to manage the size of the submitted resources
  • Vendors of FHIR-forward applications which display imaging date will likely use this profile to control the size of queried resources and to have guarantees of behavior for the image url endpoints.

gForge Users

esilver john.moehrke

FHIR Profile Development Project Insight ID

Not submitted yet.



  • May 2016 WGM initial full committee review
  • September 2016 WGM ready for publication as draft.

  • Ballot with FHIR DSTU or Normative Edition, post DSTU 3.

Desired Ballot Date

  • Include Profile at FMM 1 in next ballot following DSTU 3.