We're pleased to release the next generation of our Patient History service that will enable us with greater speed, stability, and scale in bringing you the clinical data that powers your Zus Aggregated Profile (ZAP).

Builders do not need to take any action to enjoy this upgrade, and all /patient-history/ API endpoints remain supported.

Note: Patient history jobs completed prior to 1/13/2020 will no longer be included in search results for thepatient-history/messages/ endpoint.

Calls to the Zus Operational Data Store, which includes our FHIR APIs, are now rate limited at 20 requests per second per IP. The FHIR APIs will return HTTP 429 responses to requests exceeding this limit.

We have developed a guide to configuring ZusHooks, which allow Builders to receive inbound HTTPS requests from Zus that contain information about data creation and update activity in the Zus FHIR Store. For more information, see: https://docs.zushealth.com/docs/subscriptions.

We have deprecated our beta FHIR Manager service, which allowed admin users to define and add custom fields to FHIR resources.

Builders can now use a single API endpoint to manage their care team users and associated FHIR Practitioner resources. With the new Practitioner User Upsert API endpoint, Builders can create & update users, create & update Practitioner resources, and link the two together.

Builders querying the ZAP can now access a small set of foundational resources (e.g., Practitioner, Organization, etc.) from other Builders outside of the Designated Record Set if they are referenced by Designated Record Set resources for a shared patient. For example, a care team user viewing a patient’s ZAP can see who ordered a MedicationRequest from another Builder, as represented by a reference to a Practitioner resource in the other Builder. However, the user cannot query directly for the Practitioner resource. The Practitioner resource is only accessible as part of a query for the MedicationRequest resource. Learn more here.

📖 Provenance resources now included in Data Marts

Builders can now analyze Provenance resources, which provide metadata about the context in which the information in a FHIR resource was obtained. They describe the author organization responsible for the information, thereby enabling the assessment of the quality, reliability, and trustworthiness of that data.

For example, suppose you want to identify which locations have most contributed data on your patient population. The query below will retrieve an ordered result set.

select
	location, -- where the activity occurred, if relevant 
  contained, -- additional information (i.e. address) about the contained location
  count(*) 
from provenance 
group by 1,2 
order by 3 desc ;

In addition to launching our new website 🎉, we've reorganized our documentation to better reflect our focus on the Zus Aggregated Profile, or ZAP, as Zus' core product. Furthermore, we've revised our Quickstart Guide to make it even easier for new users to quickly get up and running creating patients, seeding external data, and accessing that data, all via Zus APIs.

New documentation is up! Learn how Zus thinks about data enrichment and how you can access enriched and normalized terminology for condition and medication activity resources here: https://docs.zushealth.com/docs/data-enrichment

🎉 Builders can now get a comprehensive picture of a patient's health from all data sources on Zus with a single API call to the Zus Aggregated Profile (ZAP) in this alpha release. Data sources include third party partner networks via the Patient History API, other Builders on Zus treating the same patient, and Zus-summarized and de-duplicated (Lens) information. Use this information to power patient onboarding, care coordination, care planning, and other critical workflows. See our documentation to learn more about how to leverage the ZAP. 🎉