The philosophy behind FHIR is to build a base set of resources that do what?

• A. Be perfectly comprehensive
• B. Mirror HL7 v2 segments
• C. Support cloud-based messaging only
• D. Satisfy a Majority of Common Use Cases

Answer: (D)

The idea being tested is that FHIR aims to provide a practical, reusable core of resources that can cover most real-world needs. The base set is designed to address the majority of common use cases across different health care contexts, so systems can exchange data using a shared foundation and still be flexible enough to handle specialty needs through extensions and profiles.

Why this works well: by focusing on a robust but not all-encompassing set of resources, FHIR promotes interoperability and faster adoption. Teams can build against the common patterns they encounter in everyday interoperability—patients, encounters, observations, medications, and similar data—without being forced into a rigid, perfectly complete model that tries to predict every niche scenario. When a domain has additional requirements, it can be extended or profiled while preserving compatibility with the core resources.

This approach isn’t about mirroring HL7 v2 segments or limiting itself to cloud-based messaging. FHIR isn’t a one-to-one mapping from older HL7 formats, and it isn’t restricted to a single transport or deployment model. It’s designed to work across varied environments (EHRs, mobile apps, cloud services) using modern web technologies, with RESTful APIs and standardized resource definitions as the foundation.