FHIR Projects
summary
Company uses FHIR to standardize internal data models across acquisitions, centralizing clinical records and reducing duplicated schemas by mapping legacy feeds into FHIR resources. Engineering builds on open source and cloud FHIR servers (HappyFHIR, Azure API for FHIR, Google Healthcare), pushes transformed HL7/CDA/ETL output into FHIR stores or object storage, and reports connecting 300 health systems, processing millions of messages daily, with zero unexpected downtime for three years.
AI-written summary · about
chapters (12)
- 0:00Start
- 4:27A good interoperability standard needs to support read, write, push and subscription.
- 9:41De-politicizes parts of the product design process.
- 10:01What does a patient look like?
- 13:00Solid tooling that works out of the box at a low initial cost
- 14:15Relatively easy path to manage "enterprise" topics like ACLs and de-identification by restricting or removing sensitive resources.
- 15:08When FHIR Does "Work", you already support a lot of what it takes to support it.
- 20:18Lessons Learned
- 20:41If you don't understand how the FHIR modeling works, maybe you are wrong.
- 21:55How do you determine what insurance a patient has?
- 24:57Don't assume everyone knows the current state of EHRs/HIS in your vertical and what they can do.
- 26:03FHIR Delegates Identifier Management, so you will want to come up with rules of the road across products.
related talks
16mThe story of FHIR data exchange and storage combined
34mFHIR Projects
45mFHIR Resources for Clinical Research
20mFHIR SQL Builder
22mAI and ML for Centralized Patient Data Repositories
47mStoring data using FHIR - a good idea?
24mUnleashing the power of FHIR data with knowledge graphs
29mSQL on FHIR 2.0