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

Introduction


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 more than one round of Connectathon testing. 

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: TBD

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 (this is currently  in progress
  • Housing Instability and Quality
  • Transportation Access

Use Cases

1) Document SDOH Data Elements

Document SDOH data in conjunction with the patient encounter.

2) Track SDOH Interventions

Document and track SDOH related interventions to completion.

3) Aggregate SDOH Data Elements

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

Click here to download the Gravity Use Case Package

Timeline


Milestones


Category

Date

Deliverable

Notes

Cycle 12019.12.09Develop Base IG and Profiles for UC1v1 (IGV0.0.1)First round of development and testing

2019.12.12Gravity Community Feedback Community Feedback version (12/12/2019 - 1/15/2019

2019.12.01Marketing/Education WS: 

2020.01.05Connectathon WS: Generate SDOH Track Proposal and prepare track participantsInitial focus will be on Use Case I

2020.01.30IG Development: Continued IG Development UC1v2 (IGV0.0.2))IG Version for Feb Connectathon (0.1.0)

2020.02.2-

2020.02.03

HL7 Connectathon #1 - Syndey

Minimal unit testing for Use Case I



Marketing/Education WS: 


Connectathon WS: Generate SDOH Track Proposal and prepare track participants

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

2020.03.09 - 2020.03.13HIMSS SDOH demonstration, OrlandoMore Polished version of the Use Case I testing done in Sydney


Marketing/Education WS: 


Connectathon WS: Generate SDOH Track Proposal and prepare track participants

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

2020.04.01Governance WS: NIB for Sept Ballot

2020.05HL7 Connectathon #2 - San Antonio


Marketing/Education WS: 


Connectathon WS: Generate SDOH Track Proposal and prepare track participants


IG Development: Continued IG Development UC1v5, UC2v2 and UC3v2 (IGV0.0.5)Work on UC 2 begins in 2019,  UC3 begins in 2020

2020.6.01- 2020.07Governance WS:  Ballot Package Prep  (IGV5), WG Review and Voting

2020.08STU Ballot (STU R1.0.0)

2020.09HL7 Connectathon #3 - Baltimore, Maryland

IG Version (1.0.0)

Food Insecurity (Use Case 1,2,3)


2020.10Ballot Reconciliation

2020.12Publish SDOH-CC  (STU R1.0.1 for Food Insecurity

IG Version (1.1.0)

Submit reconciled ballot package to HL7 for publishing


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

TBDSubsequent Iterations for Transportation Barriers (STU R3)IG Version (3.0.0) 
Governance




Project Scope StatementSubmitted on October 4, 2019 Pending full approval


FHIR IG ProposalSubmitted on October 7, 2019 Pending approval


March 2020 Connectathon Track Plan; Report out on Accomplishments


Notice of Intent to Ballot for May Ballot – For Comment Ballot (Due 2020.XX.XX) 


May 2020 Connectathon Track Plan; Report out on Accomplishments


Notice of Intent to Ballot for September Ballot - STU Ballot (Due 2020.XX.XX)


Sept 2020 Connectathon Track Plan; Report out on Accomplishments


Approval of Ballot Reconciliation


Request to Publish STU R1 

Quick Links


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

Sponsor:

Patient Care


Co-Sponsors:

Vocabulary

Public Health

Status: Approved


FHIR IG Proposal: Proposal 

Status: Approved

May 2020 Connectathon

San Antonio, TX 

May 16-17


September 2020 Connectathon

Baltimore, MD

Sept 19-20

Ballot for Comment: May 2020


Ballot for STU: September 2020

Git Hub TBD



TBD

Other IGs to be Utilized


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

FHIR US Core

http://hl7.org/fhir/us/core/2019Sep/

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.

HL7 C-CDA

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.

SDC

http://build.fhir.org/ig/HL7/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.

SDC 

https://lhcforms.nlm.nih.gov/sdc

For FHIR R4

FHIR SDC SMART App

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.

CDex


Version (1.0.0) for FHIR R4

BSer

http://build.fhir.org/ig/HL7/bser/

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

http://hl7.org/fhir/uv/bulkdata/

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.

FOR FUTURE CONSIDERATION:

C-CDA on FHIR

https://build.fhir.org/ig/HL7/ccda-on-fhir-r4/

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.

eCR


FHIR IG Project Team Contacts


Name

Email 

Role

Lisa Nelson (Tech Lead)

Corey Smith

Matt Elrod

Lnelson@max.md

corey.smith@ama-assn.org

elrod@max.md

Project Facilitation

Mohit Saigal

Matt Menning

Mohit.Saigal@ama-assn.org

Matt.Menning@ama-assn.org

Resource Coordination

Lynette Elliott

Natasha Kreisle

lynette.elliott@emiadvisors.net

NKreisle@max.md

Project Support

Evelyn Gallego

Sarah DeSilvey

Donna Pertel

evelyn.gallego@emiadvisors.net

sarah.desilvey@med.uvm.edu

dpertel@eatright.org

Business Requirements
Monique Van BerkumMonique.VanBerkum@ama-assn.orgModeling Facilitator

Jim Shallaby

Cheng Liu

jshalaby@elimu.io

cliu@max.md

FHIR IG Technical Support

Linda Hyde

Rob Hausam

linda.hyde@emiadvisors.net

rrhausam@gmail.com

Vocabulary Facilitator
  • No labels