Skip to content

Latest commit

 

History

History
44 lines (30 loc) · 2.15 KB

receive.md

File metadata and controls

44 lines (30 loc) · 2.15 KB

Universal Pipeline Receive Step

Receive is the first step a report goes through when entering the Universal Pipeline (UP). Despite its name, this step actually occurs in the ReportFunction.kt file.

How it works

There are two HTTP endpoints that will kick off this function: /reports and /waters. The UP can receive data in either HL7 or FHIR via these two endpoints.

Azure Function Access Key Security

Azure Function Access Key security is supported by the /reports endpoint. Static and unchanging API Keys can be defined in the Azure environment for the Reports function and sent to the client. This method is less secure than FHIR Auth Security and thus the /reports endpoint should only be used over the /waters endpoint in special circumstances where clients or particular integrations do not have the technical ability to use the FHIR Auth Security.

FHIR Auth Security

FHIR Auth Security (OAUth2.0) is supported by the /waters endpoint and is the recommended auth clients should use. See the authentication design note for details.

Validation

Currently, very basic validation of the received report occurs in the receive step, such as:

  • ensuring that the report is in a format the pipeline can process
  • checking for duplicates within a batched report and, if they are not allowed via the allowDuplicate param, rejecting the report
  • verifying the sender is valid and enabled

Processing

Once the request has been authenticated, authorized, and validated, the Reports function uploads the received report to the blob store and triggers the Convert step via the Azure queue.

Retries

There is no async processing for this step, so a sender will get an immediate response and is responsible for retrying the request in the event of any failure down the line.