Let's dive into the basic architecture model of how your solution will integrate with Zus.
- A clinical application where users will view and interact with data about your patients.
- A backend engine that will orchestrate calls to the Zus API layer for doing things like:
- Creating patients
- Seeding data from Zus connected networks
- Writing new data back to Zus on patients
- Pulling data from Zus via FHIR for visualizing in your clinical application
- An API layer for managing requests from our customers
- A FHIR data store for housing information about your patients
- A set of connected networks which we leverage to pull data about your patients across healthcare systems. We do the hard work of converting documents to FHIR resources
- An authentication and authorization layer for securing requests and data in transit and at rest
- A Universal Patient Identifier (UPI) service to aggregate all the data we find on your patients around a single Master Patient Identifier (MPI)
- A Data Lens service to clean up the data we find across the networks, de-duplication for example
- An Enrichment service to normalize code sets across our connected networks
Below is an interaction diagram highlighting the interplay between your system and Zus
Updated about 1 month ago