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. 🎉

Builders can now feed real-time medication events into a patient's Zus Aggregate Profile (ZAP). Once a patient is enrolled in our medication events feed, Zus will automatically capture new prescription activity and create the appropriate FHIR resources within their profile. Important events like missed refills, new medications, and new prescribers will be flagged in an additional 'notification type' field, and builders can optionally configure a webhook to receive a message each time a given FHIR resource is created or updated.

For more information on how to get started, check out our guide on Patient Data Events.

New Resource Summarization tags! The Zus Lens team is in the process of enriching medication activity (MedicationStatement, MedicationAdministration, MedicationDispense, and MedicationRequest) resources as well as condition resources to make sure they are universally coded and categorized where possible.

For medication activity resources, once we have enriched them with appropriate coding, we synthesize a patient's historical medications down into a de-duplicated list of unique medications and create a new set of MedicationStatement resources with the tag: "https://zusapi.com/summary|Common"

For Active Medications, which parses the list down into just those medications which the patient may currently be taking, the tag will be: "https://zusapi.com/lens|ActiveMedications"

For condition resources, once we have enriched them appropriate coding, we de-duplicate the patient's conditions into a unique list and create a new set of condition resources with the tag: "https://zusapi.com/summary|Common"

For Chronic Conditions, which parses the list down into just those that are chronic, or potentially chronic diseases, the tag will be: "https://zusapi.com/lens|ChronicConditions"