Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 210 Next »


The Gravity Project creates and maintains a consensus-building community to expand available Core Social Determinant of Health (SDOH) Data for Interoperability and accelerate standards-based information exchange by using HL7 FHIR. Gravity Project is part of the HL7 FHIR Accelerator Program.

Many of the recent innovations at scale in this area begin with the strategic collection of SDOH data. As examples, the Centers for Medicare & Medicaid Services Innovation Center (CMS Innovation Center) Comprehensive Primary Care Plus Model requires providers to assess patients’ social risks; and the CMS Innovation Center’s Accountable Health Communities Model developed a social risk assessment tool to help identify and address social risks across clinical and community-based settings. However, presently there is no consensus on the coding and standards-based modeling to facilitate the data uses envisioned for SDOH information. The Gravity Project is addressing the question of how to record and document SDOH information in the clinical care setting, across the four primary activities of care (screening, assessment/diagnosis, care planning, and treatment). Initially, the project focuses on three of the many different domains that form social determinants of health: Food Insecurity, Housing Instability and Quality, and Transportation Access.

The FHIR IG work for Gravity will include several iterative builds of the SDOH-CC IG, multiple rounds of Connectathon testing, and periodic updates to summarize this work for the Community. General education about FHIR IG development and HL7 ballot participation will be provided to build awareness and develop skills relevant for participation in standards development at the Community level.

Quick Links

Implementation GuidesSponsoring Work GroupsGovernance DocumentsConnectathon InformationPotential Connectathon ParticipantsBallot InformationReference ImplementationsTesting and Validation Tools

SDOHCC Master and Temporary Code List v0.0.3

Approved SDOHCC FHIR IG Build Errors/Warnings


Patient Care



Public Health

Status: Approved 2019.11.18

FHIR IG Proposal: Proposal 

Status: Approved 2019.10.30

Sydney 2020 HL7 Connectathon 23

Sydney, Australia


May 2020 HL7 Connectathon 24


May 2020 MiHIN Interopathon


Sept 2020 HL7 Connectathon 25

Baltimore, MD


Ballot for STU: 2020.09

Git Hub TBD

Interventions Framework

Form Creator Demonstration

If you have any questions, please contact Gravity Technical Director, Lisa Nelson at

Project Scope Statement

For details on the approved scope for the Gravity Project SDOH Data Element FHIR IG, read the HL7 PSS.

Project Insight Number: 1567

Project Deliverables

The Gravity Project will incrementally develop one (1) FHIR IG covering the following three primary use cases listed in the table below.  The three SDOH domains these use cases focus on are as follows:

  • Food Insecurity (In-progress)
  • Housing Instability and Quality
  • Transportation Access

Use Cases

1) Document SDOH Data Elements in the Clinical Care Setting

Document SDOH data in conjunction with the patient encounter.

2) Track SDOH Intervention Referrals to Completion

Document and track SDOH related intervention referrals to completion.

3) Aggregate SDOH Data Elements for Secondary Use (QRPH)

Gather and aggregate SDOH data for uses beyond the point of care (e.g.,quality, research, and population/public health)

Note: Out of Scope for the 2020 SDOH-CC FHIR IG.

Click here to download the Gravity Use Case Package

Roadmap Timelines (updated 2020.05.04)

Milestones (updated 2020.05.07)

CE = Community Engagement


CT = Connectathon Testing






Cycle 1CE2019.12.09

Develop Base IG and Profiles for UC1v1 (IGV0.0.1)

Initial pass at key SDOH-specific profiles for UC1.

First round of development and testing

CE2019.12.12Gravity Community Feedback Community Feedback version (12/12/2019 - 1/15/2019)

CE2019.12.12Marketing/Education WS: Overview of FHIR IG Development in Gravity Community Meeting

CT2020.01.05Generate SDOH Track Proposal and prepare track participants (Sydney)Initial focus will be on Use Case I

CE2020.01.08Deadline for initial Community Feedback (e-mail comments to feedback questions listed in Notes to Reviewers and Balloters chapter of the IG.


IG Development: Continued IG Development UC1v2 (IGV0.0.2))

Refinement of V0.0.1 with emerging content ready enough for early testing at Sydney Connectathon

IG Version for Feb Connectathon (0.1.0)

NOTE:  UC3 Removed from Scope




HL7 Connectathon 23 - Sydney, Australia

Minimal unit testing for Use Case I

CT2020.02.26Connectathon Participants Preparation Call

CT2020.03.04Connectathon Participants Preparation Call

CT2020.03.09 - 2020.03.13HIMSS SDOH demonstration, Orlando, FL – CANCELLEDMore Polished version of the Use Case I testing done in Sydney


IG Development: Continued IG Development UC1v3 (IGV0.0.3)

Improvements on V0.0.2 based on learning from Sydney Connectathon and additional profiles and guidance that continues to be developed.

CT2020.03.25Connectathon Participants Preparation CallPMEHR documenting SDOH information in a clinical care encounter

CE2020.03.26Marketing/Education WS: Overview of FHIR IG Development in Gravity Community Meeting

CT2020.04.01Connectathon Participants Preparation CallClinical Data R/R interactions with PMEHR

CT2020.04.03Generate SDOH Track Proposal and prepare track participants for San Antonio, TX Connectathon 

CT2020.04.15Connectathon Participants Preparation CallReview of OAuth 2.0 implementation considerations; Options for the “patient participant” role


IG Development: Continued IG Development UC1v4, UC2v1 (IGV0.0.4)

First version that includes profiles and guidance regarding use of BSeR for UC2

CT2020.04.29Connectathon Participants Preparation CallParticipation Logistics-what to expect, Final Questions


FHIR IG Scope change to focus solely on Resource content profiles.  Specifying data exchange mechanisms between actors removed from scope.

Approach will be to let the implementer community lead by showing their choice for support of push- or pull-based information exchange mechanisms.  SDOH-CC IG will serve to ensure content payloads are standardized regardless which exchange paradigm prevails.

Decision made based on two critical issues: 1. CDex IG undergoing major revisions during Ballot Reconciliation with plan to drop the "push mechanism" previously specified.  2. No intention for EHR vendors to support FHIR API POST interactions.  

CT2020.05.13-15HL7 Connectathon 24 - VirtualAlso participating in Care Collaboration Track to contribute insight on how to include patient screening and other SDOH data elements gathered during a clinical encounter.

CT2020.05.28 -2020.05.29MiHIN Interopathon - Virtual


Continued IG Development UC1v5, and UC2v2  (IGV0.0.5)

Improvements on V0.0.4 based on learning from San Antonio Connectathon and additional profiles and guidance that continues to be developed.

Work on UC 2 begins in 2019,  UC3 begins in 2020

FIG2020.05.30GO NO GO Decision on inclusion of UC2 in September Ballot

G2020.06.15Governance WS: NIB for Sept Ballot must be completedStart securing approvals on 2020.07.01

FIG2020.6.01- 2020.07.30Ballot Package Prep  (IGV5), WG Review and Voting

CT2020.07Generate SDOH Track Proposal and prepare track participants for Baltimore, MD Connectathon

FIG2020.08.01Sponsor WG approves FHIR IG content submitted to ballot

CE2020.08.06Marketing/Education WS: Overview of FHIR IG Development in Gravity Community Meeting

FIG2020.08.13FHIR IG content determined is included in September HL7 Ballot V0.1.0




 September HL7 Ballot

Community reviews and submits formal comments on V0.1.0

CT2020.09HL7 Connectathon 25 - Baltimore, MD

IG Version (0.1.0)

Food Insecurity (Use Case 1,2)

FIG2020.09Improvements on V0.1.1 based on learning from Baltimore Connectathon and additional profiles and guidance that continues to be developed.

FIG2020.10Ballot Reconciliation

FIG2020.12FHIR IG with Ballot dispositions applied.   (v1.0.2 - v1.0.n)

FIG2020.12Publish SDOH-CC STU1 V1.0.0 for Food Insecurity

IG Version (1.0.0)

Submit reconciled ballot package to HL7 for publishing

CTTBDSubsequent iterations for Housing Instability and Quality (STU R2)IG Version (2.0.0)

CTTBDSubsequent Iterations for Transportation Barriers (STU R3)IG Version (3.0.0) 
Cycle 1 Governance

G2019.11.18Project Scope StatementSubmitted on 2019.10.04 #1576 Fully Approved on 2019.11.18

G2019.10.30FHIR IG ProposalSubmitted on 2019.10.17 Approve by FMG on 2019.10.30



Project briefing for Sponsoring WG (Patient Care)

Workgroup Update provided on  

G2020.01.14Project briefing for Co-Sponsoring WG (Vocabulary)

Workgroup Update provided on 

G2020.01.14Project briefing for Co-Sponsoring WG (Public Health)

Workgroup Update provided on 

March 2020 Sydney Connectathon Track Plan; Report out on Accomplishments

Track Plan completed on  

Project briefing at WG Meeting for Sponsoring and Co-sponsoring WGs (Patient Care, Vocabulary, Public Health)

Notice of Intent to Ballot for September Ballot - STU Ballot (Due 2020.07.01)


Project briefing for Sponsoring WG (Patient Care)

Project briefing for Co-Sponsoring WG (Vocabulary)

Project briefing for Co-Sponsoring WG (Public Health)

May 2020 HL7 Connectathon Track Plan; Report out on AccomplishmentsWeek of May 18th

Project briefing at WG Meeting for Sponsoring and Co-sponsoring WGs (Patient Care, Vocabulary, Public Health)

Approval to Ballot from Sponsoring WG: Patient Care


Project briefing for Sponsoring WG (Patient Care)

Project briefing for Co-Sponsoring WG (Vocabulary)

Project briefing for Co-Sponsoring WG (Public Health)

Sept 2020 Baltimore Connectathon Track Plan; Report out on Accomplishments

Project briefing at WG Meeting for Sponsoring and Co-sponsoring WGs (Patient Care, Vocabulary, Public Health)

Approval of Ballot Reconciliation

Approval of Request to Publish STU R1 from Sponsoring WG: Patient Care

View HL7 2020 Balloting and Publishing Schedule

FHIR R4 Implementation Guide and Artifacts

 (updated 2020.05.07)

Implementation Guide Narrative ExplanationsXX
Patient Stories and Persona InformationXX
Use Case DocumentationXX

Use Case 1Use Case 2
Resources, Profiles, Operations, Examples, Validation ScriptsScreeningEncounterRequestResponse
US Core PatientXXXX
US Core PractitionerXXXX
US Core PractitionerRoleXXXX

US Core Organization

US Core Location XXXX
US Core Encounter for a patient visit/encounter

$process-message operation for screening Task


MessageBundle for screening task


MessageHeader for screening taskremovedremoved

Task for screening taskremovedremoved

CDex CommunicationRequestremovedremoved

CDex Communicationremovedremoved

MessageHeader for update screening taskremovedremoved

SDC QuestionnaireXX

SDOH-CC List of Patients for screening task


SDOH-CC Consent for sharing questionnaire response informationXX

SDC QuestionnaireResponseXX

US Core Observation for Screening Result


Document Bundle for encounter summary and care plan documents or referral note and referral feedback documentsremovedremoved

C-CDA on FHIR Composition for encounter summary and care plan documents or referral note and referral feedback documentsremovedremoved

DocumentReference for keeping track of received documentsremovedremoved

Binary for holding a copy of a received documentremovedremoved

SDOH-CC Observation for food insecurity clinical observation

SDOH-CC Condition for food insecurity diagnosis

SDOH-CC Goal for food insecurity goal

SDOH-CC Procedure for food insecurity services (performed and requested)

SDOH-CC ServiceRequest to do a referral (ServiceRequest) for services to address SDOH needs 

SDOH-CC CarePlan to show how SDOH information relates to each other
Description only

CDex MessageBundle for Communications

CDex MessageHeader for solicited communication request

CDex MessageHeader for solicited communication response

BSer $process-message operation for SDOH Referral Task


BSer MessageBundle for SDOH Referral Task

BSer MessageHeader for SDOH Initiate Referral Task


BSer MessageHeader for SDOH Update Referral Task

BSeR ServiceRequest Activity Status

Clinical Statements -  multiple Profiles that describe how to represent individual data elements used in referral note and referral feedback documents


CapabilityStatement - Patient Appremovedremoved

CapabilityStatement - Screening Appremovedremoved

CapabilityStatement - Screening Requesterremovedremoved

CapabilityStatement - Clinical Data Sourceremovedremoved

CapabilityStatement - Clinical Data Requesterremovedremoved

CapabilityStatement - Referral Requester

CapabilityStatement - Referral Responder

CapabilityStatement - Services Directory

Resource Instance ExamplesXXXX
Messaging ExamplesInformative examples on Confluence onlyInformative examples on Confluence onlyInformative examples on Confluence onlyInformative examples on Confluence only
Validation Scriptsremovedremoved * Due to CDex changingremovedremoved

Approved SDOHCC FHIR IG Errors and Warnings

IG versionError/WarningNotes
v0.0.1N/AEarly efforts are not complete enough to expect error-free builds with IG Publisher.
v0.0.2N/AEarly efforts are not complete enough to expect error-free builds with IG Publisher.
v0.0.3Current unresolved Build Errors for v0.0.3First version where expectation is an error-free build with IG Publisher. 199 total errors. 181 errors are approved at this time. 18 errors need to be resolved

Slicing Information

error-The link '' for "Table of Contents" cannot be resolved17 errors

error- The link '' for "" cannot be resolved148 errors 

error- The link 'Patient/patientExample1' for "Patient/patientExample1" cannot be resolved5 errors

error- The link 'Encounter/encounterExample1' for "Encounter/encounterExample1" cannot be resolved.

error- The link 'Encounter/encounterExample2' for "Encounter/encounterExample2" cannot be resolved

The link 'Encounter/encounterExample3' for "Encounter/encounterExample3" cannot be resolved

4 errors

error- The link 'Practitioner/practitionerExample1' for "Practitioner/practitionerExample1" cannot be resolved

The link 'Practitioner/practitionerExample2' for "Practitioner/practitionerExample2" cannot be resolved

3 errors

The link 'StructureDefinition-SDOHCC-Procedure-FoodInsecurity-1.sch' for "Schematron" cannot be resolved4 errors
v0.0.4StructureDefinition.baseDefinition warning US FHIR Usage rules require that all profiles on CarePlan derive from the core US profile

The link 'StructureDefinition-SDOHCC-Procedure-FoodInsecurity-1.sch' for "Schematron" cannot be resolved

The link 'StructureDefinition-SDOHCC-Observation-FoodInsecurity-1.sch' for "Schematron" cannot be resolved

The link 'StructureDefinition-SDOHCC-Goal-FoodInsecurity-1.sch' for "Schematron" cannot be resolved

The link 'StructureDefinition-SDOHCC-Condition-FoodInsecurity-1.sch' for "Schematron" cannot be resolved

The resource should declare it's jurisdiction to match the package id (, jurisdiction = urn:iso:std:iso:3166:-2#US)

Other IGs to be Utilized

Implementation GuideDescription and intended use (Note that many extensions are defined within these IGs)


Version (3.1.0) - FHIR R4

The US Core Implementation Guide is based on FHIR Version R4 and defines the minimum conformance requirements for accessing patient data. The Argonaut pilot implementations, ONC 2015 Edition Common Clinical Data Set (CCDS), and the latest proposed ONC U.S. Core Data for Interoperability (USCDI) provided the requirements for this guide. The prior Argonaut search and vocabulary requirements, based on FHIR DSTU2, are updated in this guide to support FHIR Version R4. These profiles are the foundation for future US Realm FHIR implementation guides. In addition to Argonaut, they are used by DAF-Research, QI-Core, and CIMI. Under the guidance of HL7 and the HL7 US Realm Steering Committee, the content will expand in future versions to meet the needs specific to the US Realm.

These requirements were originally developed, balloted, and published in FHIR DSTU2 as part of the Office of the National Coordinator for Health Information Technology (ONC) sponsored Data Access Framework (DAF) project. For more information on how DAF became US Core see the US Core change notes.


Version 2.1 - widely adopted standard for exchange of patient encounter information.

Consolidated CDA (C-CDA) specifies several relevant document types used currently by EHR systems to exchange clinical encounter information. These documents express a collection of information that tells the patient's story at a point in time when an encounter occurred or provides the patient's medical history over a span of time.  The documents are expressed using the HL7 Clinical Document Architecture standard which is compatible and can be used in conjunction with FHIR.  For systems that do not yet support FHIR document creation, exchange of patient data using C-CDA standard documents may be a viable option. C-CDA document can be shared as attachments within FHIR exchange mechanisms.  FHIR also supports robust document registry and repository capabilities appropriate for exchanging information in all types of document formats.

Structured Data Capture (SDC)

Version  for FHIR R4

Questionnaires and forms permeate healthcare. They are used to capture administrative data, claims data, clinical information, research information, for public health reporting - every type of data that is manipulated by healthcare systems. They provide a user-friendly mechanism for capturing data in a consistent way. In FHIR, forms are represented using the Questionnaire resource and completed forms are represented using the QuestionnaireResponse resource. The base FHIR specification defines these resources but doesn't provide much guidance around how they should be used, nor does it set minimal expectations for interoperation. This implementation guide provides a set of guidance around the use of Questionnaire and QuestionnaireResponse. Specifically, it provides answers to - and conformance expectations around - questions such as:

  • What are the minimum capabilities a system should have to properly support FHIR-based forms?
  • How do I present questions in a table?
  • I want help text to appear in red - how do I do that?
  • What's the mechanism to calculate and display a score for a completed form?
  • I don't want to expose the logic of the questionnaire to other systems, but I still want to support form completion. How do I do that using FHIR?
  • Some of the data in this form already exists in the patient's record. How can I save the time (and prevent the transcription errors) associated with re-entering it into a form?
  • Once a form's complete, I want to import the data into other FHIR resources - is there an easy way to do that?

The implementation guide is structured to allow implementers to pick and choose the capabilities they need and combine them as necessary.




This open-source app uses the LHC-Forms form rendering widget to manage FHIR Questionnaire and QuestionnaireResponse resources. It provides partial (and growing) support for the Structured Data Capture (SDC) profile. The app is designed to be launched from an EHR system using SMART on FHIR to connect to the EHR's FHIR server. When you select "Try App" below, you will first go to a patient selector, and then to the app, the idea being that in an EHR environment, the patient would already be chosen before the app is used to fill out a form for the patient.

The app supports both STU3 and R4 versions of FHIR; the "Try App" button will connect you to an R4 FHIR server.

Da Vinci Clinical Data Exchange


Version (1.0.0) for FHIR R4

The CDex implementation guide defines combinations of exchange methods (push, pull, etc. ), specific payloads (Documents, Bundles, and Individual Resources), search criteria, conformance, provenance, and other relevant requirements to support the exchange of clinical information between provider and other providers and/or payers. The goal is to identify, document and constrain specific exchange patterns so that providers and payers can reliably exchange information for patient care (including coordination of care), risk adjustment, quality reporting, identifying that requested services are necessary and appropriate (e.g. should be covered by the payer) and other uses that may be documented as part of this effort. Clinical data payloads will include C-CDA, C-CDA on FHIR, compositions, bundles, and discrete resources conforming to the US Core specification.

Ultimately this IG is expected to support multiple versions of FHIR (DSTU2/Argonaught, STU3, and R4), but the current version of this IG only supports for FHIR R4.

Bidirectional Services eReferrals


Version (0.2.0) for FHIR R3

The Bidirectional Services eReferrals (BSeR) FHIR IG provides guidance on STU3 FHIR Resources and US Core IG profiles for use in exchanging a referral request and specific program data from a clinical provider to a typically extra-clinical program service provider, such as a diabetes prevention program, a smoking quitline, or a hypertension management training program. And provides for the return of feedback information from the service program to the referring provider.

This IG includes definition of the BSer Consent Profile which may be used to share information sharing consent information gathered from the patient.

FHIR Bulk Data Access

Version (1.0.0) for FHIR 4.0

Providers and organizations accountable for managing the health of populations often need to efficiently access large volumes of information on a group of individuals. For example, a health system may want to periodically retrieve updated clinical data from an EHR to a research database, a provider may want to send clinical data on a roster of patients to their ACO to calculate quality measures, or an EHR may want to access claims data to close gaps in care. In most cases, access to these bulk-data exports is pre-authorized between the data holder and the data requester. The data exchange involves extracting a specific subset of fields from the source system, mapping the fields into a structured file format like CSV, and persisting the files in a server from which the requester can then download them into the target system. This multi-step process increases the cost of integration projects and can act as a counter-incentive to data liquidity.

Existing FHIR APIs work well for accessing small amounts of data, but large exports can require hundreds of thousands of requests. This implementation guide defines a standardized, FHIR based approach for exporting bulk data from a FHIR server to a pre-authorized client.



Version (1.1.0) for FHIR R4

Consolidated CDA (C-CDA) is one of the most widely implemented implementation guides for CDA and covers a significant scope of clinical care. Its target of the ‘common/essential’ elements of healthcare is closely aligned with FHIR’s focus on the ‘80%’. There is significant interest in industry and government in the ability to interoperate between CDA and FHIR and C-CDA is a logical starting point. Implementers and regulators have both expressed an interest in the ability to map between FHIR and C-CDA.

This Implementation Guide (IG) defines a series of FHIR profiles on the Composition resource to represent the various document types in C-CDA. This release does not directly map every C-CDA template to FHIR profiles, rather tries to accomplish the C-CDA use case using Composition resource profiles created under this project (the equivalent of Level 2 CDA documents), and begins by linking to the profiles created under the US Core project for any coded entries that would normally be included in C-CDA sections. To have a simpler, more streamlined standard that reuses existing work and focuses on the 80% that implementers actually need in production systems, the resources of US Core represents a portion of the 80% needed for coded entries for coded entries of CCD, Care Plan & Discharge Summary).

The Composition profiles in this IG do not require coded data in any section. This is a departure from C-CDA, which requires coded data for Problems, Results, Medications, etc. This departure is intentional, as the C-CDA requirement for one or more coded entries in these sections resulted in some very complicated workarounds using nullFlavors to handle the fact that sometimes a patient is not on any medications, or has no current problems. In general, FHIR takes the approach that if something is nullable, it should simply be optional to ease the burden on implementers, thus C-CDA on FHIR does not require any coded entries, but rather uses the “required if known” approach, meaning that if an implementer’s system has data for a section that requires data under Meaningful Use, they need to send it, but if they have no data there is no need for a null entry.


  • No labels