Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Announcements

...

  1. SAVE THE DATE: SDOH CC FHIR IG Public Meetings will be scheduled for October 2020.

  2. The HL7® FHIR Virtual Connectathon occurred from September 9th to 11th

    1. Thank you to all who have participated in the HL7 FHIR Virtual Connectathon from September 9th to 11th. On Thursday, September 17th 5:00 pm - 5:30 pm EST, the Gravity Project Technical Director will present a post-connectathon debrief. 

    2. View the connecathon track recordings and presentations here.

  3. Click here to view the SDOH-CC Master and Temporary Code List.

...

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

SDOH Clinical Care 0.0.1 - CI Build

Sponsor:

Patient Care


Co-Sponsors:

Vocabulary

Public Health

Status: Approved 2019.11.18


FHIR IG Proposal: Proposal 

Status: Approved 2019.10.30

Sydney 2020 HL7 Connectathon 23

Sydney, Australia

2020.02.01-02


May 2020 HL7 Connectathon 24

2020.05.13-15


May 2020 MiHIN Interopathon

2020.05.28-29


Sept 2020 HL7 Connectathon 25 - Virtual 2020.09.9-11

Ballot for STU: 20202021.0901

Git Hub TBD



Interventions Framework


Form Creator Demonstration

...

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:

...

capture and exchange of multiple SDOH domains across the four clinical activities of screening, diagnosis (health concerns), goals, and interventions. 

  • Phase I Domains (2019-2020)
    • Food Insecurity
    • Housing Instability and Quality
    • Transportation Access
    • Financial Strain
    • Demographics (education, employment, veteran status)
  • Phase II Domains (2021)
    • Social Isolation
    • Stress
    • Environmental Safety
    • Violence


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 Click here to download the Gravity Use Case Package

Roadmap Timelines (updated 2020.09.18)

...

Image Removed

Milestones (updated 2020.05.26)

...

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

...

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

...

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

...

View HL7 2020 Balloting and Publishing Schedule

FHIR R4 Implementation Guide and Artifacts

 (updated 2020.05.07)

...

US Core Organization

...

$process-message operation for screening Task

...

MessageBundle for screening task

...

SDOH-CC List of Patients for screening task

...

US Core Observation for Screening Result

...

BSer MessageBundle for SDOH Referral Task

...

BSer MessageHeader for SDOH Update Referral Task

...

Approved SDOHCC FHIR IG Errors and Warnings

...

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

...

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

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

...

Other IGs to be Utilized

...

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.

...

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)

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.

...

FHIR SDC SMART App

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.

...

Da Vinci Clinical Data Exchange

CDex

http://hl7.org/fhir/us/davinci-cdex/2019Jun/

...

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

(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.

...

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.

...

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.

Structured Data Capture (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.

FHIR SDC SMART App

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.