Short Description

Testing the (Uniform Data System) UDS+ FHIR IG which participating health center organizations can use to automate the de-identification and formatting of the data into a submission, conforming to UDS manual and FHIR implementation guide defined profiles and protocols.

Long Description

This FHIR IG is designed as part of an ONC / HRSA (United States Core Data for Interoperability) USCDI+ modernization initiative to support the identification and establishment of domain or program-specific datasets that will operate as extensions, beyond the core data in the USCDI, to allow FHIR use to:

  • Define the data needed in a UDS submission, relying on existing FHIR operations, resources, profiles, and implementation guides.
  • Practice how this data can be collected and organized through FHIR APIs
  • Align with CDC, ONC, and CMS, e.g., harmonizing with digital quality measure reporting efforts.
  • Transform the collected data into content suitable for a UDS submission.
  • Identify potential additional data quality and warehousing needs.


Test an Implementation Guide

Related Tracks?

Call for participants

Certified EHR Vendors, HCCNs/PCAs (Health Center Controlled Networks/Primary Care Associations), population health vendors, 3rd party aggregators, and companies offering (Uniform Data System) UDS+ submission expertise.

Track Prerequisites

Read the IG specification (version 0.3.0 was released 4/5/23):

Reference the UDS Manual, Tables, and other partner references, as needed for CPTs and additional guidance (note: 2022 is available, but 2023 is in progress):

Track Lead(s)

David Finney & Rachel Fried 

Track Lead Email(s) ; 

Specification Information

This will be the first Connectathon for this Implementation Guide.

UDSPLUS\UDS Plus Home Page - FHIR v4.0.1 (

Inferno Test Suite found under Additional FHIR Tests:

Inferno on

Zulip stream

With a few folks new to Connectathons joining us, you may have to register for a Zulip account.  You should be able to self-register to join our Zulip thread once you've registered to join:

(669) #Protocols for Uniform Data System Patient Level Submission - FHIR Community - Zulip

Track Kick off Call(s)

Calendar holds have been sent / will be sent to those who email Rachel confirming their registered team members:

Testing Scenario:

Expectations: These do not need to be perfect, and incomplete data sets, tables, is fine to test for this.  However, it must be fake/synthetic data, and no live / real patient data is allowed.

Reference Implementation End Points: To be confirmed 

System roles: To be confirmed (the UDS+ Team will likely act as Data Receiver for this initial test, and we do not have requirements for HOW participants create steps 1-8, only that a manifest file is created).

Important Note: the actors can be combined or split, depending on how a health center’s IT system is configured (example scenario: one Certified EHR technology might act as Data Source, Trust Service Provider, and Data Submitter).  The Data Receiver is not a role that a connection participant can take on.

Copied from Sections 3 and 5 of UDS+ FHIR IG version 0.2.0:

Data Source Requirements

Data Sources The Data Source is a software system that is used to capture and store the patients electronic medical record which contains information such as patient demographics, medications, procedures, allergies, diagnosis, problems etc. Examples of Data Sources include EHRs, Data Warehouses etc. The Data Source is responsible for providing interfaces to extract patient data.

This section identifies the different requirements for Data Source (e.g., EHRs) systems supporting the Health Centers.

  • The Data Source SHALL support the [FHIR Base URL]/Group/[id]/$export as per the Bulk Data Access IG.
  • The Data Source SHALL support the resources and profiles identified in the Data Source Capability Statement
  • The Data Source SHALL support the [FHIR Base URL]/Group/[id]/$export using the _since parameter as per the Bulk Data Access IG.
  • The Data Source SHALL support the [FHIR Base URL]/Group/[id]/$export using the _type parameter as per the Bulk Data Access IG.
  • The Data Source SHALL support the SMART on FHIR Backend Services Authorization as outlined in the previous sections.
Data Submitter Requirements

Data Submitter The Data Submitter system is responsible for extracting the data for the patients whose data need to be submitted to HRSA, de-identify the data and then notify about the readiness of the data to the Data Receiver.

This section identifies the different requirements for Data Submitter system supporting the Health Centers.

  • The Data Submitter SHALL support the scheduling of timers to kick off health center reporting based on HRSA guidance.
  • The Data Submitter SHALL implement the client requirements per the Bulk Data Access IG to start the export of the data from the Data Source.
  • The Data Submitter SHALL implement the monitoring of the export request per the Bulk Data Access IG.
  • Once the export is completed, the Data Submitter SHALL download the exported data for de-identification.
  • The Data Submitter SHALL retain the patient linkages between the identifiable data and de-identified data.
  • The Data Submitter SHALL de-identify the exported data using the Trust Service Provider services and then create the links for HRSA to download the data.
  • The Data Submitter SHALL validate the data for conformance to the IG.
  • The Data Submitter SHALL implement the following security protocols to protect the links being shared with HRSA.
  • The Data Submitter SHALL notify the HRSA Data Receiver when the data is ready using the $import
Trust Service Provider Requirements

Trust Service Provider The Trust Service Provider actor provides an API for de-identifying the patient data and creating the necessary linkages across the resources.

This section identifies the different requirements for UDS+ Trust Service Provider that can be used for de-identification.

  • The Trust Service Provider SHALL support the de-identify operation for each type of resource per the Capability Statement.
  • The Trust Service Provider SHALL create an identifier that is retained internally to link between identifiable and de-identifiable data.
  • The Trust Service Provider SHALL remove all identifiable data using the profiles specified in this IG and create NDJSON data based on the IG profiles.

Data Receiver Requirements
Data Receiver The Data Receiver is the HRSA organization. The data receiver is responsible for receiving the health center data, validate it and transform it for consumption by HRSA systems.

This section identifies the different requirements for Data Receiver systems hosted by HRSA.

  • The Data Receiver SHALL implement the $importoperation to receive notification of completed export for each health center.
  • The Data Receiver SHALL download the NDJSON formatted, de-identified data from the health center using the links provided by the Data Submitter following the protocol specified in the manifest file.

The Data Receiver SHALL validate the received NDJSON data according to the IG profiles.

4/24/23 Updated Scenarios:

Scenario: User wishes to test an Import Manifest

Action: User hits “Run Tests” on the Data Submitter Tests page, and inserts their manifest into the pop-up. The input can be either an http location of the manifest, or a json of the manifest itself.
Precondition: If using a location as the input, ensure that the data can be accessed without authentication
Success Criteria #1: The manifest submitted (via either format) is in a json format that can be converted into a FHIR resource
Success Criteria #2:  Validation that the manifest resource conforms to the IG’s Manifest Structure Definition.
Success Criteria #3: The manifest contains valid locations for the data it references.
Success Criteria #4: The data retrieved from the manifest conforms to their respective Structure definitions.
Success Criteria #5: The manifest labeled the data it pointed to with a title representing the correct resource type.

Scenario: User wishes to test an individual resource

Action: User hits “Run Tests” on the Individual Resource Tests page, and inserts a single resource per resource type into their respective input slots in the pop-up. Users can submit a resource for as many or as few types as they want. Resources can be submitted as an http location or as a json of the resource itself.
Precondition: If using a location as the input, ensure that the data can be accessed without authentication
Success Criteria #1: (per resource type) The resource submitted is in a json format that can be converted into a fhir resource
Success Criteria #2: (per resource type) Validation that the resource conforms to the IG’s Structure Definition of the given resource type.

Security and Privacy Considerations:

Must confirm to the Implementation Guide and UDS Manual.


Goal for UDS+ testing and piloting (proof of concept) is June 2023.  This includes UDS+ FHIR IG version 0.3.X and 2023 UDS Manual publishing (likely late May 2023).

Submission deadline for patient level data collected in (calendar year) CY23 using FHIR (and/or EHB upload) is February 15, 2024.

Potential Participants

If an organization intends to participate in our track, the Track Lead is collecting organization names and main/secondary point of contact in this list.  We may add additional details later.

NOTE: Certain organizations may be observing only, but we welcome all kinds of participation due to many vendors and groups supporting health centers nationally!

Organizationmain Point of Contactsecondary Point of Contact in this listendpointAnything we should know about script or manifest file?

Details we should know about test data: 

Do you have test patients (fake data only!) in a sharable FHIR bundle for test, UAT, or dev?

UDS+ team: HRSA and ONC

ONC team and contractors (Leap Orbit, Drajer)

Rachel Fried (Track Lead)Nagesh "Dragon" Bashyam (IG SME), Lucas T (Test Scripts SME), and David F (Track Lead)To be determined if/which server for testing, besides the Inferno Test Kit.  More to come on environ build and reference implementation!Check out version 0.3.0 of the UDS+ FHIR Implementation Guide with an example manifest file!We are working on the Test Scripts to enable tests like: read in a manifest and validate it or parse through the manifest for its contents.  Participants should have a test patient manifest ready for us to test against, and we welcome emailed questions.


Kevin D.N/A

NextGenWesley C.Pedro M.

SCPHCA (South Carolina Primary Health Care Association) and Health Centers:

  • Rural Health Services – 2 attendees (Brandi W and Charity W)
  • Plexus Health – 2 attendees (Dr. S. Barre. and Amanda C.)
  • CareSouth Carolina – 1 attendee (Weston O.)
  • Tandem Health SC - 1 attendee (Tina R.)
  • Foothills (Observer only) (Mark)
Chandra B.TBC

SCPHCA has invited additional volunteer testers from 3 health centers.  Mix of CERHTs (athenahealth, eCW mostly) and IT systems (homegrown, pop health vendors, etc.).
TBC: eClinicalWorksTushar M.TBC

TBC: EpicVassil P.TBC

Rachel will likely sit with the 7 or so less-technical observers at a second table, while the 8 or so technical folks give it a go. NOTE: Virtual attendance is ONLY the kick off calls, and discussion over email.  There is not truly a virtual opportunity at the Connectathon, since it is a loud, large in-person room (we cannot feasibly open a conference line).

Observer only list (tentative) (some virtual, some in-person):

  • HRSA (Satish G.) (in-person)
  • ONC (Matt R., Leliveld "Lee" E.) (in-person)
  • Athenahealth (Andrea K., Cat N.)
  • OCHIN (Michelle K., Duane E.)
  • WPHCA (Wisconsin Primary Health Care Association) (Mitch S. and Parker G.)
  • CGM (CompuGroup Medical): Aprima / eMDs (Laurel H.)
  • BridgeIT Solutions (Melissa R.) (virtual kick offs only)
  • Greenway Health (Lance B.) (virtual kick offs only)
  • Meditab (Tejas P.) (virtual kick offs only)
  • additional invitees may just attend our kickoff calls in listen-only mode.


  1. Comments/Feedback from the KOC (4.24.23) to discuss further at the Connectathon:

    • Quality measures going to be tested?
      • We will likely create samples for testing of certain QA measures (not all, but some).
      • Additional feedback on which folks have examples of can be displayed here later.
    •   Is there a target date for a non-draft QICore standard (QICore is still in draft format)?  
      • There are published versions of QICore, and we are pointing to 4.0.0 currently.  We discussed potentially pointing to 4.1.1, which is the latest.  We can discuss this further.
    • HRSA indicated that the target for the sandbox availability was the end of February.  So, is this actually a sandbox of the actual submission or just a test box of eventual functionality?
      • The sandbox being made available at the Connectathon is an initial test box of eventual functionality.  The HRSA sandbox is being set up now, and we do not have a firm availability date yet, but it is coming soon.
    • After the manifest is submitted is there any security involved with the data receiver going to get the hosted files?

    • Does this Draft (QI-CORE IG) as of (4.24.23) mean that the standard is not "finalized"?  What is 'capital S' Standard v standard?

      • Many of the implementation guides are iterative and will change.  This includes the USCDI (US Core) IG, the QI Core IG, and the UDS+ FHIR IG.  We will be changing the IG after the Connectathon to better reflect the reality of what's occurring on the ground (user-centric design).  Therefore, we welcome any and all insight and feedback, due to the many unique health centers and IT set-ups.  We'd love to hear your thoughts based on your organization's progress on FHIR, QI Core, USCDI, eCQMs/dCQMs, etc.

    • Participants noted confusion about the potential de-id(entification)/re-id(entification) situation.  Concerns were noted on the potential for 're-identification' due to the guidance on an 'identifier'.
      • This concern has been discussed based on the IG version 0.2.0, but we would love to discuss additionally based on the added Safe Harbor HHS suggestions in the IG version 0.3.0.
  2. If you are looking at this page after the 5/11/23 UTC Member meeting, please note that the information above was created pre-Connectathon, and a lot of feedback was received during the 5/6/23-5/7/23 weekend that will likely make it's way into the UDS+ FHIR IG, Inferno Test Suite, and (coming soon) UDS+ sandbox.  We thank you for your patience, understanding, and as usual, any feedback via the BPHC Contact Form: BPHC Contact Form (