The Gravity Project is a consensus-based HL7 FHIR Accelerator that defines the data elements, value sets, and implementation guide clinical and public health teams need to document and exchange social determinants of health data consistently across systems. It is not a piece of software you install. It is the shared vocabulary and technical specification that EHRs, referral platforms, and community-based organizations use so a housing instability screening result means the same thing everywhere it travels.
If you are standing up an SDOH program or trying to fix a referral pipeline that leaks data at every handoff, start with these three resources:
- Gravity Project — Overview — the project’s mission, governance structure, and participant base.
- HL7 FHIR SDOH Clinical Care Implementation Guide — the technical build site with profiles, examples, and resource mappings.
- VSAC (Value Set Authority Center) — where Gravity-stewarded value sets and codes live for terminology binding.
This guide is written for implementers, program directors, and informatics leads who need to move from “we collect SDOH data” to “we can prove what happened after the referral.” If you want to see how these standards translate into an actual working referral system, there’s a short note near the end pointing to a demo.
Key Takeaways
Standardized SDOH data, built on Gravity Project artifacts, is what makes closed-loop referral tracking measurable instead of anecdotal.
| Point | Details |
|---|---|
| Start with the IG, not a summary | Reference the SDOH Clinical Care Implementation Guide directly for profiles and examples before building any mapping. |
| Pull codes from VSAC, not local copies | Use the exact OIDs published in VSAC and track the bi-annual June 30/December 31 update cycle. |
| Map consent alongside data exchange | Document consent workflows in parallel with technical mapping to avoid compliance gaps at referral handoff. |
| Prioritize two or three domains first | Start pilots with food, housing, or transportation before expanding to every SDOH domain. |
| See standards in a working platform | EquiLoop applies Gravity-aligned data structures to closed-loop referrals; book a 30-minute walkthrough at Calendly. |
Table of Contents
- What Is the Gravity Project SDOH Framework Trying to Solve?
- How Is the Gravity Project Organized? Workstreams and Governance
- What Are the Core Gravity Project Artifacts Implementers Should Know?
- How Do Gravity Standards Map to Clinical Workflows?
- What Does an Implementation Checklist Look Like?
- Why Does Standardization Actually Change Referral Outcomes?
- How Do You Keep Up With New Gravity Project Releases?
- How Can Your Organization Contribute to the Gravity Project?
- Where Standards Meet a Working Referral System
- Frequently Asked Questions
- Sources
What Is the Gravity Project SDOH Framework Trying to Solve?
Before the Gravity Project, SDOH data capture was a patchwork. One clinic used a custom housing question, another used PRAPARE, a third built its own free-text field. None of it exchanged cleanly, and none of it aggregated for reporting. The Gravity Project exists to fix that by producing a common set of terms, codes, and FHIR profiles that any vendor or open-source platform can implement.
The project is a collaborative, consensus-driven HL7 FHIR Accelerator that has convened more than 2,000 participants, ranging from EHR vendors and payers to community-based organizations and public health departments. That scale matters. A standard built by one vendor gets adopted by that vendor’s customers. A standard built by 2,000 stakeholders across the healthcare and social services ecosystem gets adopted industry-wide, which is the entire point of health equity initiatives that depend on data actually moving between organizations that don’t share a system of record.
How Is the Gravity Project Organized? Workstreams and Governance
Gravity’s output comes from three workstreams, each with a distinct job.
- Terminology workstream defines the actual data elements, codes, and value sets, from what counts as a “food insecurity screening positive” to how a housing instability referral outcome gets coded. This work surfaces in VSAC.
- Technical workstream builds the SDOH Clinical Care Implementation Guide itself, the FHIR profiles, resource mappings, and exchange patterns that let systems talk to each other.
- Implementation workstream tests those standards in real deployments, running pilots and Connectathons to find where the theory breaks against actual EHR workflows.
Governance runs on consensus, not vendor mandate. Participation happens through open HL7 processes: working group calls, Confluence documentation, GitHub issue tracking, and formal HL7 ballots where proposed changes get reviewed by the community before adoption. If you want to track where a specific value set or profile decision came from, the Confluence use case pages are usually the first place to look, followed by the GitHub repository for the IG source itself.
Meeting notes, ballot schedules, and community calls are published through HL7’s standard channels. If your organization is planning to build against Gravity artifacts, someone on your technical team should be watching these channels before you write a single line of mapping code. Standards move, and building against a stale version of a value set is one of the most common ways implementations break later.
What Are the Core Gravity Project Artifacts Implementers Should Know?
Three artifacts matter more than anything else in day-to-day implementation work.
The SDOH Clinical Care Implementation Guide (SDOH CC IG) is the technical backbone. It defines FHIR profiles for representing screening responses, conditions, goals, and referrals, and it documents how to support exchange including closed-loop referral tracking and aggregation for reporting. This is the document your integration engineers should have open while building mappings, not a summary of it.
Value sets in VSAC are where the actual codes live. Gravity Project stewardship means the terminology workstream maintains and publishes value sets for the priority SDOH domains: housing instability, food insecurity, transportation access, utility needs, and interpersonal safety, among others. Each value set carries an OID your systems reference directly rather than hardcoding local codes. Accessing them requires a free NLM VSAC account, and updates follow a fixed cadence, which matters more than it sounds like it should.
USCDI+ alignment is the piece most teams underestimate until a reporting deadline forces the issue. USCDI+ defines prioritized data elements for national interoperability, and Gravity aligns its domain-level value sets to USCDI or USCDI+ extensions specifically so that data aggregated across programs, payers, and public health departments can actually be compared. If your program is building toward multi-site reporting or eventual submission to a state or federal aggregation effort, checking USCDI+ bindings before finalizing your data model saves a rebuild later.
For system-to-system exchange, point your canonical references at the IG build pages and the VSAC entries directly, not at a local copy someone made two versions ago. A stale mirror is how two systems that both claim to be “Gravity-compliant” still fail to exchange cleanly.
Pro Tip: Bookmark the IG’s own changelog page rather than relying on your vendor’s release notes. Vendors sometimes lag behind IG updates by a full release cycle, and you want to know that gap exists before a value set mismatch shows up in production.
How Do Gravity Standards Map to Clinical Workflows?
Gravity organizes SDOH data across four clinical activities: screening, assessment or diagnosis, goal setting, and intervention or referral. Each step has a corresponding FHIR resource pattern, and understanding the mapping is what turns an abstract standard into a working data pipeline.
- Screening uses
QuestionnaireandQuestionnaireResponseresources to capture the raw screening tool responses, whether that’s a housing stability question or a transportation access item. - Assessment/diagnosis converts a positive screen into a coded finding using
ObservationorConditionresources, so “screened positive for food insecurity” becomes a structured, queryable data point rather than a note buried in free text. - Goal setting uses
GoalandCarePlanresources to document what the care team and the individual agree needs to happen next. - Intervention and referral relies on
ServiceRequest,Task, andCommunicationresources to track the actual referral, from the moment it’s sent to a community partner through delivery and resolution.
The Gravity use case package prioritizes three domains first: food security, housing stability, and transportation access. These three show up disproportionately in pilot data because they tend to have the clearest referral pathways to existing community resources, which makes them a reasonable starting point if you’re scoping a first implementation rather than trying to boil the ocean across every SDOH domain at once.
A simplified text version of the flow looks like this: screening tool administered → QuestionnaireResponse captured → positive result codes to Observation → CarePlan/Goal created → ServiceRequest sent to community partner → Task/Communication tracks status → outcome documented back to the record. Each arrow in that chain is a place where consent documentation needs to travel with the data, particularly once a referral crosses from a clinical system into a community-based organization that is not bound by the same data-sharing agreements. Skipping consent mapping is one of the more common ways an otherwise well-built pipeline runs into a compliance wall mid-pilot.
What Does an Implementation Checklist Look Like?
Moving from planning to a working pilot follows a fairly consistent sequence, regardless of organization size.
- Scope your priority domains. Pick two or three SDOH domains to start, typically food, housing, or transportation, rather than trying to implement every Gravity value set on day one.
- Select and pin your value sets. Pull the specific VSAC OIDs for your chosen domains and document the version you’re building against.
- Map EHR fields to IG profiles. Align your existing screening tool fields to the corresponding Questionnaire, Observation, and Goal profiles in the SDOH CC IG.
- Test in a sandbox environment. Run sample data through a FHIR test kit before touching production data.
- Set up pilot partner agreements. Confirm which community organizations will receive referrals and how consent will be documented on both ends.
- Check performance and reporting. Confirm your aggregation layer can actually query against the USCDI±aligned fields you’ve mapped.
The most common pitfalls cluster around a few predictable spots. Teams ignore the VSAC bi-annual version cycle and end up with mismatched codes between their intake system and their reporting layer. Teams build the technical exchange but skip consent workflow mapping, which surfaces as a legal or trust problem months later. Closed-loop referral tracking gets built halfway, capturing that a referral was sent but never confirming it was accepted or resolved. Local code mappings drift from the canonical VSAC entries because someone hardcoded a value set locally instead of referencing the source. And stakeholder onboarding gets rushed, so community partners receiving referrals were never trained on what a status update actually requires from them.
Pro Tip: Run every IG version update through a sandbox environment with an automated FHIR test kit before touching production, even for what looks like a minor point release. Value set updates twice a year sound routine until an OID silently shifts underneath a mapping your team built eighteen months ago.
Why Does Standardization Actually Change Referral Outcomes?
Standardization is what turns referral tracking from anecdotal into measurable. Without a common data model, a program can report how many screenings it conducted, but not what happened to the people who screened positive. Lack of standardization at the screening stage is precisely what prevents reliable outcome measurement further downstream, because there’s no consistent way to trace a referral from creation to resolution across systems that don’t share a data model.
In practice, pilots that pair Gravity standards with real operational workflows report meaningfully higher closed-loop completion than programs relying on manual tracking or spreadsheets. One rural health hub deployment running a multi-partner ecosystem, including both clinical and social services referrals, screened a large number of individuals, delivered tens of thousands of services, and closed the loop on the vast majority of referrals.¹
It’s the difference between “we referred 500 families to housing assistance” and “we referred 500 families, 470 were accepted by the partner, and 410 resulted in a documented outcome.”
For pilots aiming at similar results, the operational checklist looks like this: capture standardized data at intake, route referrals through a system that tracks acceptance and delivery rather than just sending a fax or email, and build your outcome reporting against the same coded fields from day one rather than retrofitting it later. If you want to see what a standards-aligned closed-loop workflow looks like in practice, a 30-minute walkthrough is available at Calendly.
¹ Rural health hub deployment with a multi-partner ecosystem. Includes both clinical and social services referrals.
How Do You Keep Up With New Gravity Project Releases?
Three channels carry every meaningful update: the HL7 IG registry and build site, VSAC value-set publications, and the Gravity Project’s Confluence and GitHub spaces for notes and pending ballots.
VSAC value sets follow a bi-annual update cadence, refreshed on June 30 and December 31 each year. That schedule directly affects OIDs and version numbers your systems reference, which means a mapping that worked cleanly in May can throw an error in July if nobody synced the update. Teams that treat this as a fire drill twice a year tend to fare better than teams that discover it by accident in production.
A few practical habits keep systems in sync without much overhead:
- Pin specific IG and value-set versions in production rather than pointing at “latest.”
- Test every update in a sandbox environment before promoting it.
- Maintain a release checklist tied to your existing procurement and change-control cycles, so a value-set refresh isn’t a surprise that bypasses normal review.
How Can Your Organization Contribute to the Gravity Project?
Participation is open, and there are several concrete entry points depending on how much time your organization can commit.
- Attend a working group call or Connectathon to see how proposed changes get discussed before they reach ballot.
- File an issue or pull request on GitHub if you’ve found a gap in a profile or a value set that doesn’t cover a real-world scenario your program encountered.
- Submit a value-set or terminology request through the Confluence and HL7 processes if your domain needs a code that doesn’t currently exist.
- Sign up for mailing lists and project calendars to stay ahead of ballot cycles rather than reacting after the fact.
- Propose a pilot if your organization wants to test a new use case and contribute real-world implementation data back to the Implementation workstream.
Expect governance to move at the pace of consensus, which is slower than a single vendor shipping a feature, but it’s also why a Gravity-aligned mapping tends to hold up across more systems than a proprietary one built in isolation. If your team is exploring how digital health platforms fit into this broader interoperability picture, Chameleon’s overview of digital health solutions is a useful companion read on where vendor-agnostic frameworks like Gravity fit into modern care delivery.
Where Standards Meet a Working Referral System
Reading the IG and pinning the right VSAC value sets gets you a data model. It doesn’t get you a working referral system that tracks whether a housing referral actually resulted in stable housing. That gap, between standards on paper and standards in production, is where most SDOH programs stall.
EquiLoop is built around that gap. It’s a closed-loop referral and care coordination platform designed to align with Gravity Project data structures rather than invent its own taxonomy: SDOH screening intake mapped to standard value sets, referral routing to clinical and community partners, follow-up and status tracking through to resolution, outcomes dashboards, and funder-ready reporting.
Configuration happens around the partner network and reporting requirements your organization already has, not a generic template. EquiLoop is built to work alongside your existing EHR and systems of record, not replace them, which matters if your program has already invested in a screening tool or case management system you don’t want to abandon. Capabilities include SDOH screening and intake, referral routing to community-based organizations, follow-up tracking through to closed-loop resolution, and funder-ready outcomes reporting built on the same closed-loop logic described above.
Book time directly at calendly.com/wellcheck/demo-discuss, or start by reviewing how EquiLoop’s workflow works end to end.
Frequently Asked Questions
Is the Gravity Project a piece of software we install?
No. It’s a specification, a set of data elements, value sets, and FHIR profiles that EHRs and referral platforms implement. Your organization still needs a system, whether an EHR module or a dedicated platform like EquiLoop, that actually applies these standards to real screening and referral workflows.
Do we need a paid account to access Gravity value sets?
You need a free NLM VSAC account to browse and download the value sets Gravity stewards. There’s no cost to access them, but your team should plan for the bi-annual update cycle so your systems don’t drift out of sync with the published codes.
How does Gravity Project SDOH work relate to USCDI+?
Gravity aligns its domain-level value sets to USCDI and USCDI+ extensions specifically so data captured under Gravity standards can be aggregated and reported at a national level. If your program plans to report to a state or federal aggregation effort, check the USCDI+ bindings before finalizing your data model.
What’s the fastest way to pilot Gravity standards without a full IT rebuild?
Scope one or two priority domains, most programs start with food insecurity or housing instability, pin the relevant VSAC value sets, and test in a sandbox before touching production. A platform already built around Gravity’s data structures, like EquiLoop, shortens this path considerably compared to building the mapping layer from scratch.
Where do we ask questions or propose changes to a Gravity value set?
Start with the project’s Confluence pages and GitHub repository, then follow HL7’s formal ballot process if you’re proposing a structural change. Working group calls are the fastest way to get informal feedback before submitting anything formally.
Sources
- Gravity Project — Overview
- SDOH and the Gravity Project – SDOH Clinical Care v3.0.0
- Gravity Use Case Package – Gravity Project – Confluence
- USCDI+
