Mechanics of FHIR in Reporting and Referrals
summary
A working platform distributes trigger code value sets and reporting rules as a FHIR Subscription using PlanDefinition artifacts so EHRs can auto-create an electronic initial case report (EICR) when triggers match; major EHR vendors commit to the flow, a central service applies confirmatory rules, and messages use a message bundle / Task resource workflow that can travel over Direct or REST. Implementations include CDA↔FHIR transforms, hyper-segmented referral profiles (six profiles in the first ballot), and a rules engine that decides jurisdiction and timing.
AI-written summary · about
chapters (11)
- 0:00Intro
- 1:05Surveillance
- 4:58Background
- 8:02Provider Burden
- 17:16Consumable Standards
- 26:15FHIR Messaging
- 30:18FHIR Messaging Improvements
- 31:39Data harmonization
- 33:38Bidirectional services referral
- 35:10Reporting guidance distribution
- 43:45Questions
related talks
49mReferrals and orders: How to ask for stuff in FHIR
36mLeveraging FHIR Capabilities to Enable Patient Access and Provider Directory APIs
39mFHIR to reduce burden and solve prior authorization challenges
41mThe role of HL7® FHIR® in patient cost transparency
20mClaims on FHIR
33mHealthcare Interoperability : From Buzzword to APIs
44mFHIR Mapping Language
49mFHIR Bulk Data API and what's new in v2