Managing multiple versions
summary
FHIR runs R2–R4 in production (about nine visible deployments) and conversion is brittle: a mapping language plus Java conversion libraries power transformations, with tests showing 100% forward conversion for Account and 77% for ActivityDefinition; back-conversions sometimes fail. Publication is driven by a machine-readable package-list.json. API versioning uses a MIME-type fire-version parameter, a $versions operation and a convert operation for server-side conversion. Persistence options: store raw, normalize to an internal version, or extract relational indexes; always store the resource version.
AI-written summary · about
chapters (23)
- 0:00Introduction
- 4:15Release history
- 5:43Versioning is expensive
- 7:06Versioning supporting multiple versions
- 7:38Converting between versions
- 8:45Transformation code
- 11:58Java conversion libraries
- 14:03Facades
- 15:47API Versioning
- 16:53Multiple Endpoints
- 18:10Multiple Versions
- 19:05Server Versions
- 20:00Client Versions
- 20:43Search Parameters
- 21:43Convert
- 22:40Fire Version
- 24:22Persistence
- 25:22Persistence options
- 28:21Documentation options
- 32:28QA
- 34:56Mapping language
- 35:56Mix multiple versions
- 40:56Avoiding the Andy pattern
