2023-05 Protocols for Uniform Data System Patient-Level Submission (UDS+)

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.

Type

Test an Implementation Guide

Related Tracks?

Call for participants

Certified EHR Vendors, HCCNs/PCAs (Health Center Controlled Networks/Primary Care Associations), population health vendors, 3^rd 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):

• UDSPLUS\UDS Plus Home Page - FHIR v4.0.1 (drajer.com)

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

• Uniform Data System (UDS) Training and Technical Assistance | Bureau of Primary Health Care (hrsa.gov)

Track Lead(s)

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 (drajer.com)

Inferno Test Suite found under Additional FHIR Tests:

Inferno on HealthIT.gov

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:

• 4/24 at 11 am ET RECORDING: UDS+ FHIR Connectathon_ Track Kick Off Call-20230424_110214-Meeting Recording.mp4

• 4/25 at 10 am ET RECORDING: UDS+ FHIR Connectathon_ Track Kick Off Call _2-20230425_100257-Meeting Recording.mp4

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.

Requirements/timeline:

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.

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!

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.