HackMDSubscriptions in HTI-2 Proposal
References to FHIR Subscriptions
- 170.215 (h) (1) Reference to Backport IG
- 170.299 (h) (50) Incorporation Backport IG by Reference
Structure of Certification Criteria
- § 170.315(j): Defines core subscription capabilities
- § 170.315(g): Assigns capabilities to different system types
- (g)(10): Clinical
- (g)(20): Public health
- (g)(30): Health insurance and coverage
Core Subscription Capabilities
- 170.315 (j)(23): Subscriptions - server
- 170.315 (j)(24): Subscriptions - client
Server Capabilities
- Implement HL7 FHIR Subscriptions Framework
- Support Subscriptions R5 Backport IG v1.1.0
- Conform to "R4/B Topic-Based Subscription" profile
- Support R4 Topic-Based Subscription Server Capability Statement
- Send notifications to subscribed clients
Client Capabilities
- Implement HL7 FHIR Subscriptions Framework
- Support Subscriptions R5 Backport IG v1.1.0
- Conform to "R4/B Topic-Based Subscription" profile
- Support client capabilities for server requirements
- Receive subscription notifications
Subscription Topics and Parameters
-
USCDI change notifications: (emphasis added)
Support the ability for a client to subscribe to notifications filtered by a patient identifier and send notifications when any of the Resources specified in § 170.315(j)(23)(v)(B) are created or updated as applicable according to the standard in § 170.215(a) and implementation specification in § 170.215(h)(1).
-
Resource-specific Notifications
Support the ability for a client to subscribe to notifications filtered according to the conditions below and send notifications for the following Resource interactions according to the standard in § 170.215(a) and implementation specification in § 170.215(h)(1):
FHIR Resource Type: Filters
- AllergyIntolerance: “category,” “code”, and “patient”
- CarePlan: “category”, and “subject”
- CareTeam: “category”, and “subject”
- Condition: “category,” “code,” and “subject”
- Coverage: “beneficiary” and “type”
- DiagnosticReport: “category,” “code,” and “subject”
- DocumentReference: “subject” and “type”
- Encounter: “reasonCode,” “subject,” and “type”
- Goal: “category,” “description,” and “subject”
- Immunization: patient,” and “vaccineCode”
- MedicationDispense: “category,” “medication[x],” and “subject”
- MedicationRequest: “category,” “medication[x],” and “subject”
- Observation: “category,” “code,” and “subject”
- Patient: “identifier”
- Procedure: “category,” “code,” and “subject”
- QuestionnaireResponse: “subject”
- RelatedPerson: “patient”
- ServiceRequest: “category,” “code,” and “subject”
- Specimen: “patient” and “type”
Notification Requirements
- Support "id-only" Payload Types
- Use "REST-Hook" channel for notifications
Public Health Applications
-
Support subscriptions per Core Subscription Capabilities
-
PLUS Enable client subscriptions for:
- Encounter start (filtered by reasonCode and subject)
- Encounter end (filtered by reasonCode and subject)
- Additional requirements to support read and search for specific FHIR resources:
- Condition
- Encounter
- Location
- Observation
- Organization
- Patient
- PractitionerRole
Health Insurance and Coverage
Not the focus of this Argonaut Project
-
Support Subscription for “Pended Authorization Responses”
Support subscriptions as a client according to the requirements in § 170.315(j)(24) and at least one of the versions of the implementation specification adopted in § 170.215(j)(3) in order to support “pended authorization responses”.
- Refers to the Da Vinci PAS Implementation Guide
- Subscription to the Claim or Task Resource
Benefits of FHIR Subscriptions
- Real-time access to latest records
- Reduced network traffic and resource usage
- Improved public health reporting capabilities
- Standardized communication for triggering criteria
Implementation Considerations
- Maturity Level 3 (Trial Use)
- Minimal channel implementation (REST-hook)
- Starting with defined use cases and subset of topics
Next Steps
- Public comment period
- Potential refinements based on feedback
- Final rule implementation
Feedback on ONC's Proposed Subscription Requirements
1. Version Considerations for Topic-Based Subscriptions Backport
Current Proposal
ONC points to version 1.1 of the Topic-Based Subscriptions Backport IG.
Recommendation
While referencing version 1.1 is appropriate as it's the currently published version, ONC should consider adding support for version 1.2 via the Standards Version Advancement Process (SVAP) when it's published. This would allow for the incorporation of ongoing improvements and changes in the standard.
Rationale
The Topic-Based Subscriptions Backport IG is still evolving. Allowing for future version support through SVAP would ensure that implementers can leverage the most up-to-date and refined version of the standard as it becomes available.
2. Simplification of Subscription Topics
Current Proposal
The proposal distinguishes between "USCDI Change Notifications" and "Resource-specific notifications."
Recommendation
Simplify the approach by stating that a client should be able to subscribe to changes that occur in any of the patient-related USCDI resource types. This design would allow a single subscription to enable notifications for any subset of resource types, allowing clients to specify which resources thye care about using appropriate filters.
Rationale
The current distinction between USCDI Change Notifications and Resource-specific notifications is unclear and potentially confusing. A unified approach would simplify implementation and provide more flexibility for subscribers to define their notification needs.
3. Refinement of Subscription Filters
Current Proposal
The proposal includes subscription filters that are not currently required search parameters in US Core.
Recommendation
Start with a restricted set of filters that align with existing US Core required search parameters. This approach would lower the burden of initial implementation, while meeting the core needs of clinical and public health use cases.
Rationale
Aligning with existing US Core requirements would simplify implementation and reduce the risk of interoperability issues. As the simple approach proves successful, these requirements can be expanded in future iterations.
4. Simplification of Notification Triggers
Current Proposal
The proposal discusses FHIR interactions like create/update/delete as the triggers for notifications.
Recommendation
Start with a simpler, more implementable subset of triggers. Require servers to support triggering notifications when a resource changes status. This includes when a resource is first created or deleted, but it avoids the complexity of requiring every possible state change to trigger a notification. Specify that servers may support triggering on other updates, but do not yet require this functionality.
Rationale
This approach is easier to implement and provides a good starting point for notifications. It focuses on meaningful changes that are likely to be of interest to subscribers, and avoids many edge cases (e.g., a re-mapped code or an update to a display name).
5. Integration with US Core
Current Proposal
The proposal defines Subscription requirements separately from US Core.
Recommendation
ONC should support the development of Subscription guidance within US Core. Future regulations should then be more closely tied to this single source of truth.
Rationale
While there's a "chicken and egg" challenge in getting started, integrating Subscription requirements into US Core would provide a clearer, more cohesive set of standards for implementers. This would reduce confusion and potential conflicts between different sets of requirements.
Conclusion
These recommendations aim to simplify implementation, reduce burden on developers, and improve the overall effectiveness of the Subscription requirements. By focusing on a more straightforward initial approach, ONC can facilitate wider adoption and gather valuable real-world implementation experience. This experience can then inform future, more comprehensive requirements as the industry becomes more familiar with FHIR-based subscriptions.
