March 15, 2023

by Anusha Tomar

Occasionally, CommonWell and Carequality participants respond to patient history requests with CDA documents respondents that have other binaries (e.g., PDFs, text, images) embedded within them. As of last week, we are extracting these embedded binaries and storing them to ODS.

We link non-XML binaries to their parent CDAs. DocumentReferences for non-XML binaries have a pointer to the parent document in the relatesTo field.

You can search for non-XML binaries using the contentType parameter on DocumentReference resource type, e.g.: DocumentReference?contenttype=application/pdf.

March 14, 2023

by Anusha Tomar

Patient history API calls will now validate the patient's address, including their postal code, before accepting a refresh request. Postal codes must be formatted as 5 digits (e.g., 02138) or 5+4 digits separated by a hyphen (e.g., 02138-1000).

March 3, 2023

by Brian Marentay

We are pleased to announce an update to our Patient History service that will improve the performance and stability of our medication history search.

There are no breaking changes or required actions to take advantage of this upgrade, and all /patient-history/ API endpoints remain supported.

You can read more about the Patient History API and how to get started accessing clinical data for your patient here.

February 17, 2023

by Amna Hashmi

We have released a search parameter that allows API users to find FHIR resources created by their Builder organization, thereby excluding third-party and Zus-created Lens resources 🥳. To use the first-party search parameter and benefit from the improved performance 💨, add firstparty=true to the URL.

GET https://api.zusapi.com/fhir/Patient?firstparty=true

February 2, 2023

by Anusha Tomar

Message statuses on the patient history API will no longer include the list of FHIR resources created by the underlying connectors. Payloads for this API were consistently too large to support a responsive synchronous experience.

Please reach out to the Zus team if this impacts an existing integration.

January 30, 2023

by Anusha Tomar

The patient-history/messages endpoint allows Builders to search across previously initiated Patient History jobs. We now order these results by most-recently-created first and support start-date and end-date as parameters to narrow results based on when the job was initiated.

January 19, 2023

by Brian Marentay

In order to ensure compliance with various clinical information networks, Zus builders are required to specify the name, NPI number, and role of a treating provider when making a /refresh/ request to the Patient History API.

Beginning today, the Patient History API will now perform a check against the CMS NPI registry to ensure the NPI number supplied in the practitioner_npi header is valid, and belongs to an individual provider (Organizational NPI numbers are not permitted on certain external networks queried by Zus). You will now receive immediate feedback on your initial request, eliminating errors further along in the process and ensuring we are able to deliver data from as many clinical networks as possible in completing your patient-history request.

Requirements for submitting a /refresh/ request to the Patient History now include:

  • The Patient resource to be queried for must include Name, DOB, Gender, and Address (telecom details recommended for best results)
  • Name, Role, and (individual) NPI number for the treating provider

January 13, 2023

by Brian Marentay

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.

January 13, 2022

by Anusha Tomar

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.