Data Ingestion Updates
This describes how data in perpetually updated from source systems into 1up's FHIR APIs either in real time or daily via the NiFi ETL tool.
1upHealth supports ongoing data updates to the FHIR server for data from health plans and health systems which are integrated via our ETL tool. This enable daily updates and periodic updates at a cadence determined by you and your solution architect. For customers, using 1up for CMS Patient Access API compliance, the minimum required cadence is 1 day for most of the member facing data, and 30 days for items like the Provider Directory.
Overall we will need 3 data sources
Original Data Sources (with updates and delete flags) - this is all the files sent during initial historic data loads, but provided on an ongoing basis with only new data
Member Sync File - this contains a cross-walk of all the canonical universal member ids plus alternate member ids which may change over time
Provider Directory (monthly) - the provider directory can be provided on a monthly basis. If you are using our tool which uses NPPES data, this file is only required to contain a full list of the NPIs. Otherwise your provider directory will be presented similar to your original data sources which are fully mapped based on your data.

The data format for ongoing updates MUST be exactly the same as the data format for the first time load and historical ingest. This helps ensure that the existing mappings will continue to work for new data updates.
Incremental files MUST contain all information necessary to transform data into a FHIR resource. If multiple files are required to be joined to create a FHIR resource (for example, if Patient FHIR resources are derived from two database extracts, patient_demographics.csv and patient_addresses.csv), then both files must be delivered in every incremental data delivery.

The only data which should be sent for updates are updates to historical data, new data, and deletes. Updates and new data should be sent in the exact same formats as the historical loads.
For deletes, each row of data should be accompanied by an additional column called delete and set the value to true

Member IDs may drift over time and change based on new plans or boomerang customers. This change in member IDs will need to be maintained on an ongoing basis. Along with the updates sent for the clinical and claims data, we will also need a cross walk file which indicates the various member ids for each individual human (heartbeat). This file should be in the following format:
Universal Member ID
Alternate Member ID
mem1
altid1
mem1
altid2
mem1
altid3
mem2
altid4
mem3
altid5
mem3
altid6

Data is required to be sent daily at minimum with the exception of Provider Directory data which can be sent once every 30 days. We will have triggers and flows that are set to look for that data daily from the SFTP or S3 buckets to ingest data once it's submitted. Once properly configured, this will not require manual intervention.
Copy link
On this page
Data Format
Data Updates and Deletes
Member Sync
Timeliness