This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Subscription FHIR Resource Proposal"
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: | + | 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: | + | [[Category:Approved FHIR Resource Proposal]] |
Latest revision as of 20:33, 8 April 2015
Contents
- 1 Subscription
- 1.1 Owning committee name
- 1.2 Contributing or Reviewing Work Groups
- 1.3 FHIR Resource Development Project Insight ID
- 1.4 Scope of coverage
- 1.5 RIM scope
- 1.6 Resource appropriateness
- 1.7 Expected implementations
- 1.8 Content sources
- 1.9 Example Scenarios
- 1.10 Resource Relationships
- 1.11 Timelines
- 1.12 gForge Users
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