This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "PACS FHIR Profile Proposal"

From HL7Wiki
Jump to navigation Jump to search
(Created page with "{{subst::Template:FHIR Profile Proposal}}")
 
(PACS FHIR Profile proposal)
Line 14: Line 14:
  
  
−
=PutProposedProfileNameHere=
+
=DicomWadoRsImagingStudy=
  
 
<!-- Profile names should meet the following characteristics:
 
<!-- Profile names should meet the following characteristics:
Line 30: Line 30:
  
 
==Profile balloting plans==
 
==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==
 
==Profile Details==
Line 36: Line 38:
 
===Profiled Resource(s)===
 
===Profiled Resource(s)===
  
 +
The main resource to be profiled is:
 
<!--Put a link to the resource/datatype (or group of resources) that will be profiled here.-->
 
<!--Put a link to the resource/datatype (or group of resources) that will be profiled here.-->
−
* [[ParentResourceAddress|ResourceName]]
+
* [[http://hl7-fhir.github.io/imagingstudy.html ImagingStudy]]
 +
 
 +
The following resources are referenced from ImagingStudy and *may* be additionally profiled to support profiling of ImagingStudy.
 +
 
 +
* [[http://hl7-fhir.github.io/patient.html Patient]]
 +
* [[http://hl7-fhir.github.io/practitioner.html Practitioner]]
 +
* [[http://hl7-fhir.github.io/diagnosticorder.html DiagnosticOrder]]
 +
* [[http://hl7-fhir.github.io/procedure.html Procedure]]
 +
 
 +
The following resource is closely related to ImagingStudy and may also be profiled.
 +
 
 +
* [[http://hl7-fhir.github.io/imagingobjectselection.html ImagingObjectSelection]]
  
 
====Constraints to be Applied====
 
====Constraints to be Applied====
  
 
<!--Describe how the current resource will be constrained.-->
 
<!--Describe how the current resource will be constrained.-->
−
* Constraint 1
+
* Certain optional elements (e.g. ImagingStudy.url, ImagingStudy.series.number, ImagingStudy.series.instance.content) will be made required.
−
* Constraint 2
+
* Use of ImagingStudy.series.instance.content.data 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 to be Applied====
  
 
<!--Describe how the current resource will be extended.-->
 
<!--Describe how the current resource will be extended.-->
−
* Extension 1
+
* Extensions may be defined (e.g., WADO-RS conformance URL)
−
* Extension 2
 
  
 
===Example Scenarios===
 
===Example Scenarios===
  
 
<!-- Provide a listing of the types of scenarios to be represented in the examples produced for this Profile.  They should demonstrate the full scope of the Profile and allow exercising of the Profiles capabilities (full element coverage, inclusion & omission of optional elements, repeating and singleton repeating elements, etc.) -->
 
<!-- Provide a listing of the types of scenarios to be represented in the examples produced for this Profile.  They should demonstrate the full scope of the Profile and allow exercising of the Profiles capabilities (full element coverage, inclusion & omission of optional elements, repeating and singleton repeating elements, etc.) -->
 +
 +
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===
 
===Scope of coverage===
Line 67: Line 87:
 
As a rule, Profiles should encompass all of these aspects.
 
As a rule, Profiles should encompass all of these aspects.
 
-->
 
-->
 +
 +
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.
  
 
===Realm===
 
===Realm===
−
Please describe the realm to which this profile applies, or indicate that it is realm neutral.
+
This profile is realm neutral.
 +
 
  
 
==Ownership==
 
==Ownership==
Line 75: Line 101:
  
 
<!-- The name of the committee that is proposed to have responsibility for developing and maintaining the Profiles. -->
 
<!-- The name of the committee that is proposed to have responsibility for developing and maintaining the Profiles. -->
−
[[YourCommitteeName]]
+
[[Imaging Integration WG]]
  
 
===Contributing or Reviewing Work Groups===
 
===Contributing or Reviewing Work Groups===
 +
  
 
<!-- Additional work groups that may have an interest in contributing to, or reviewing  the content of the Profile (optional) -->
 
<!-- Additional work groups that may have an interest in contributing to, or reviewing  the content of the Profile (optional) -->
−
* Work Group Name
+
* None
−
* or link
 
−
* or "None"
 
  
 
===Expected implementations===
 
===Expected implementations===
  
 
<!--Key Profiles are justified by CCDA, for Profiles not deemed "key", what interest is there by implementers in using this particular Profile. Provide named implementations if possible - ideally provide multiple independent implementations. -->
 
<!--Key Profiles are justified by CCDA, for Profiles not deemed "key", what interest is there by implementers in using this particular Profile. Provide named implementations if possible - ideally provide multiple independent 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===
 
===gForge Users===
Line 92: Line 120:
 
<!-- Identify the userids who will require commit access to gForge to maintain the Profile.  (Ensure all users have registered for gForge.) -->
 
<!-- Identify the userids who will require commit access to gForge to maintain the Profile.  (Ensure all users have registered for gForge.) -->
  
 +
esilver
 +
john.moehrke
  
 
===FHIR Profile Development Project Insight ID===
 
===FHIR Profile Development Project Insight ID===
  
 
<!-- Please specify the id of your work group’s PSS for doing FHIR work.  (If submitted but not yet approved, just write “pending”.) The link to the PSS template can be found here: http://gforge.hl7.org/gf/download/docmanfileversion/6832/9398/HL7FHIR_DSTUballotPSS-20120529.doc -->
 
<!-- Please specify the id of your work group’s PSS for doing FHIR work.  (If submitted but not yet approved, just write “pending”.) The link to the PSS template can be found here: http://gforge.hl7.org/gf/download/docmanfileversion/6832/9398/HL7FHIR_DSTUballotPSS-20120529.doc -->
 +
 +
Not submitted yet.
  
 
==Plans==
 
==Plans==
 +
 
===Timelines===
 
===Timelines===
  
−
<!-- Indicate the target date for having the Profile complete from a committee perspective and ready for vetting and voting -->
+
* May 2016 WGM initial full committee review
−
*TargetDateForInternalReview
+
* September 2016 WGM ready for publication as draft.
 +
 
 +
<!-- Indicate the target date for having the Profile complete from a committee perspective and ready for vetting and voting -
 +
*TargetDateForInternalReview->
 +
 
 +
 
  
 
===Balloting Requirements===
 
===Balloting Requirements===
  
−
<!-- Indicate the intended method of balloting by choosing one of the options below, or propose alternative.  If Realm Specific or No Ballot indicate the amount of informal review required by the FHIR community.-->
+
<!-- Indicate the intended method of balloting by choosing one of the options below, or propose alternative.  If Realm Specific or No Ballot indicate the amount of informal review required by the FHIR community.
  
 
Choose one:
 
Choose one:
Line 112: Line 150:
 
*or Realm specific ballot
 
*or Realm specific ballot
 
*or No Ballot
 
*or No Ballot
 +
 +
-->
 +
 +
* Ballot with FHIR DSTU or Normative Edition, post DSTU 3.
  
 
<!-- Indicate the desired ballot date.-->
 
<!-- Indicate the desired ballot date.-->
 
Desired Ballot Date
 
Desired Ballot Date
−
*PutDesiredBallotDateHere
+
* Include Profile at FMM 1 in next ballot following DSTU 3.

Revision as of 23:06, 26 January 2016

OpenHotTopic.GIF

This page documents a Pending FHIR Resource Proposal



DicomWadoRsImagingStudy

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 ImagingStudy.series.instance.content.data 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.

Realm

This profile is realm neutral.


Ownership

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.

Plans

Timelines

  • 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.
Retrieved from "https://wiki.hl7.org/w/index.php?title=PACS_FHIR_Profile_Proposal&oldid=114139"