HRSA 2023 Uniform Data System (UDS) Patient Level Submission (PLS) (UDS+) FHIR IG
1.0.1 - STU1 Release 1 - Standard for Trial-Use
This page is part of the HRSA Uniform Data System (UDS) Patient Level Submission (PLS) (UDS+ or uds-plus) FHIR IG (v1.0.1: STU1) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version in its permanent home (it will always be available at this URL). For a full list of available versions, see the Directory of published versions
Page standards status: Trial-use |
This section provides implementation details for reporting the data elements identified in UDS+ Data Elements to HRSA.
The UDS+ program requires the Health Centers/HCCN’s along with their EHR vendors need to be on-boarded to the UDS+ program to connect to the Data Receiver and submit the data. To initiate this process interested Health Centers and HCCN’s and their EHR vendors can contact the HRSA support team using the BPHC Contact Form. Some of the important activities performed as part of on-boarding include
This section provides details of the Step 9, Step 10a and Step 10b to be used by the Data Submitter and Data Receiver to successfully submit or re-submit a UDS+ report.
The diagram below details out the interactions between the Data Submitter and the Data Receiver for Step 9. This is following the FHIR Bulk Data Access/FHIR Async pattern.
For more information and examples on authentication mechanisms, refer to SMART on FHIR IG Backend Services.
When $import is invoked by the Data Submitter and a manifest file is submitted the following codes are returned routinely.
There could be scenarios where the Data Submitters may receive other 4xx or 5xx HTTP error codes.
For details on the request and response examples please refer to RequestResponseExamples.
Since the submission starts a FHIR async pattern request, the submitter has to poll for the status of the submission as the submissions is imported asynchronously. In order to poll for the status of the submission, the submitter has to parse the HTTTP Response Headers and extract the Content-Location header which contains the URL used for polling the status of the submission.
The following is a summary of the protocols used for authentication and authorization specified at SMART on FHIR IG Backend Services.
The Data Submitter clients (Health Centers) will be registered in the Authorization Server as part of the on-boarding process. There is no dynamic registration capability that is allowed.
Asymmetric Keys (public and private keys) are used for authentication. Clients MUST be capable of protecting their private keys.
RFC 5246 - TLS 1.2 is used to protect all transactions.
Authorization Server supports RS384 or ES384 signature algorithms per RFC7518
Authorization Server and Data Submitters MUST support Json Web Key Set per RFC7517
Authorization Servers and Data Submitters MUST support JSON Web Tokens per RFC7519 and RFC7523
Authorization Server MUST support a .well-known/smart-configuration metadata for conformance
Data Submitters MUST submit the JWT assertions per the RFC7521
Data Submitters MUST include the scopes to post the manifest file to the Data Receiver
Data Submitters SHOULD follow best practices and use links which are signed and expire to prevent malicious actors from downloading the data. Best practice includes auto-generation of the links and auto expiration and requiring tokens to be echoed back for access.
Data Submitters and Data Receivers MUST maintain audit logs for each submission and its corresponding responses.
The diagram below details out the interactions between the Data Submitter and the Data Receiver for Step 10a and Step 10b. This is following the FHIR Bulk Data Access/FHIR Async pattern.
When GET /
There could be scenarios where the Data Submitters may receive other 4xx or 5xx HTTP error codes.
Data Submitters should always process the HTTP Response body to identify the specific errors which are returned as OperationOutcome resources.
For details on the request and response examples please refer to RequestResponseExamples.
When Data Submitters invoke the Content-Location URL for the status of the submission, the X-Progress header can also be used to check on the overall status. The typcial values that the X-Progress Header contains are :
For details on the request and response examples please refer to RequestResponseExamples.
EHRs which are playing the role of both Data Source and Data Submitter may provide a button or some kind of capability to the Health Center user to kick of the reporting cycle.
The first version of the IG prescribes the de-identification process as simply removing all identifiable elements in the profiles. This can be accomplished by translating the incoming US Core compliant profile into a UDS Plus De-identified resource profile.
The following tables are expected to be reported through UDS+ FHIR APIs.
The following tables are expected to be reported using the existing UDS reporting mechanisms as they are not directly related to the patient’s clinical data.
Feedback Requested
The FHIR APIs, FHIR Resources and FHIR profiles to be used are specified as part of the IG, creation of a Parameters Resource profile to specify Tables 5, 8A, 9D and 9E is possible. We would like feedback on this approach as this would essentially make it possible to accept all existing UDS data using FHIR APIs.
Implementers should follow the UDS Manual to identify the patient’s zip code and insurance which includes
* Reporting the most recent zip code on file
* Using "Other zip code" for people with no US address
* Patients' last insurance from the last visit of the year
For Table 3A, the age calculation should be based on December 31st of the previous year as per the UDS Manual.
When race is captured, but no ethnicity is captured, it should be defaulted “Not Hispanic or Latino”
The income reported should have been captured within 12 months of the last visit for the pateint.
The income has to be translated to percentages as per Federal Poverty Guidelines.
Quality Measure computation and reporting is a complex task and may involve multiple systems and human interventions to compute the measures properly. The quality reporting eco-system is rapidly evolving to utilize existing standards such as HL7 FHIR Measure Report (Individual and Summary), HL7 QRDA Category III (Summary or Aggregate), HL7 QRDA Category I (Individual) to automate reporting and processing of the reports. However computation of the Measure Reports or what data to be included in the individual report is still not automated widely in the industry. HRSA recognizes this state of the industry where Quality Measure standards will continue to evolve and hence prescribes submitting de-identified information for Table 6B and Table 7 using the UDS+ profiles.
The Patients for each measure will be qualified and tagged using the initial patient population criteria for the measure. When a Patient is qualified for multiple measures, they will be tagged using the Patient Reporting Parameters profile.
The Health Centers are expected to work with their Data Sources (e.g., EHR vendors) to extract the data required for the computation of the different measures as identified in the UDS+ Data Elements and FHIR Mapping. These resources when extracted from the EHR will contain identifiable data and has to be de-identified before submitting to HRSA. Once HRSA receives the data, quality measure computation will be performed using the submitted data.
To help the implementers, the following table shows examples of FHIR resources that contain identifiable information and their corresponding de-identified versions of the resources. These are examples and not specific requirements.
FHIR Resource | FHIR Resource with identifiable data | De-Identified version of FHIR Resource | De-Identification Notes |
Patient | US Core Patient instance with identifiable information |
UDS+ Patient instance which is de-identified |
Notice the zip code representation to meet the HHS Safe Harbor guidance for de-identification. Only 3 digit zip codes are allowed. |
Patient | US Core Patient instance living in a zip code with small population |
UDS+ Patient instance which is de-identified |
Notice the zip code representation to meet the HHS Safe Harbor guidance for de-identification. The zip code is masked completely. |
Condition | US Core Condition instance with patient name. |
UDS+ Condition instance which is de-identified |
Notice the patient reference is pointing to the de-identified patient and the name is removed, onset, recorded asserted dates are abstracted to a precision of year and the month and day and times are removed.Also the note element has been removed as it is not a "SUPPORTED" element in UDS+ diagnosis profile. |
Encounter | US Core Encounter instance with patient name. |
UDS+ Encounter instance which is de-identified |
Notice the patient reference is pointing to the de-identified patient and the name is removed, meta.lastupdated and period dates are abstracted to a precision of year and the month and day and times are removed. |