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

Difference between revisions of "Subscription FHIR Resource Proposal"

From HL7Wiki
Jump to navigation Jump to search
 
Line 3: Line 3:
 
<div style="float: left;">[[Image:OpenHotTopic.GIF|35px| ]]</div>
 
<div style="float: left;">[[Image:OpenHotTopic.GIF|35px| ]]</div>
 
<div style="background:#F0F0F0">
 
<div style="background:#F0F0F0">
This page documents a [[:category:Pending FHIR Resource Proposal|Pending]] [[:category:FHIR Resource Proposal|FHIR Resource Proposal]]
+
This page documents a [[:category:Approved FHIR Resource Proposal|Approved]] [[:category:FHIR Resource Proposal|FHIR Resource Proposal]]
 
</div>
 
</div>
 
</div>
 
</div>
 
[[Category:FHIR Resource Proposal]]
 
[[Category:FHIR Resource Proposal]]
[[Category:Pending FHIR Resource Proposal]]
+
[[Category:Approved FHIR Resource Proposal]]
  
  

Latest revision as of 20:33, 8 April 2015



Subscription

Owning committee name

FHIR Project Team

Contributing or Reviewing Work Groups

  • MnM

FHIR Resource Development Project Insight ID

Whichever one FHIR works under

Scope of coverage

To allow a client to create a push based subscription on a server so that they get notified of any resources that meet a particular criteria

this is a technical infrastructure resource not directly related to healthcare

  • subject: N/A
  • disciplines: N/A
  • delivery: N/A
  • Locale: N/A

RIM scope

Not in scope of the RIM

Resource appropriateness

  • The API provides a pull based subscription service through the history operations.
  • this works well, but is network intensive. It's fine for server:server interactions, but not suitable for client/server, especially if the client is a mobile one
  • clients need to be able create, track and retire subscriptions
  • There are 13 elements in the candidate resource. a few additional ones are under discussion

Other possible related resources

  • Message Header - is used for exchanging resources using the messaging paradigm. If we define a protocol for push subscriptions using the messaging paradigm, it would use message header
  • Query - the query resource specifies a query. This resource may or may not use the query resource for the actual query that expresses the subscription criteira

Expected implementations

  • most servers will need to implement this to support client based subscriptions

Content sources

[Josh's original proposal]: considered prior art


Example Scenarios

  • a client asks to be notified any time a new bilirubin result greater than some defined threshold is reported
  • a client asks to be notified any time new information on a patient is provided

Resource Relationships

  • there are no anticipated relationships

Timelines

  • a draft has been defined
  • implementation testing is ongoing
  • this will be ready for QA/DSTU2

gForge Users

Grahame/Core team