One Medical FHIR Implementation Guide - Local Development build (v0.1.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Home

Official URL: https://fhir-ig.onemedical.io/ImplementationGuide/om-fhir-ig				Version: 0.1.0
Draft as of 2026-04-10				Computable Name: omfhirig

Welcome! This site is One Medical's offical FHIR Implementation Guide (IG).

This Implementation Guide outlines how to use FHIR at One Medical, with detailed data definitions, known as profiles, for particular resources. This site assumes a baseline familiarity with FHIR.

The artifacts in this IG are normative.

FAQ

How is this site updated?

This site is updated from this repository,which uses tooling provided by HL7, the organization that manages FHIR. To make updates to this site, please submit pull requests to that repository.

I found an error in the site, how do I report it?

To report an error with the content of this site, please reach out to the CDP team on slack at #sps-fhir-services.

Are there any design docs for this site?

You can find the design documents for how this site works here.

What are "profiles"?

This site holds a number of "profiles," which define the rules for particular FHIR resource types.

For example, a FHIR profile of a Resource is a StructureDefinition, which is a special resource used for defining a constrained view of a particular resource. For example, the US Core Condition profile is a constrained version of the base FHIR Condition, with more specific requirements for which fields and coded values must be present, as well as more detailed per-field definitions.

These profiles can inherit from each other – for example, we can create a “One Medical HeathKit blood pressure” profile that inherits from a “One Medical Blood Pressure” profile, which inherits from the Base FHIR blood pressure profile. There can be more than one profile for a given resource type. For example, both the Pediatric Head Occipital-frontal Circumference Percentile Profile and Pulse Oximetry Profile are Observations, but represent different classes of data. Only a single team may own a given profile, but many teams may own profiles from within the same resource type.

These profiles are used in the CDP’s validation (they are how we define how fields should be validated). These profiles are also used to generate this site, which will serve as the data dictionary for other developers and analytics teams.

Profied resources can be queried using the meta search parameter and represented as part of a resource’s metadata. They must be explicitly specified at the time of write.