Zus releases the Active Medication Lens 🔍.

Sure, you got a lot of medication history for your patients, but what meds are they currently taking? The Active Medication Lens de-duplicates a patient's medications after enriching the medication activity resources with RxNorm mappings and then applies logic based on the status and last activity date and produces unique MedicationStatements for each medication that the patient may currently be taking. These MedicationStatement resources can be accessed just like any other, but are tagged for easy identification (_tag=https://zusapi.com/lens|ActiveMedications). Perfect for a patient onboarding form or a patient profile.

We've introduced a host of new features and enhancements in our FHIRplace application to make browsing FHIR resources in Zus easier than ever. Read on to learn more about what we've been up to this quarter.

Render CDA documents directly to understand source data at a glance

Clinical documents retrieved when populating a patient's history are stored as Binary resources in our FHIR store. When viewing binary resources containing CDA XML (the standard format for clinical document exchange) in FHIRplace, toggle the "Parsed" slider to view the fully rendered document.

View all resources linked to a given patient

When viewing a Patient resource, navigate to the "Show Everything" tab to see a complete list of resources associated with the patient.

Compare resources

Select any two resources and click the compare button to view a side-by-side comparison of differences.

Create new resources

When viewing any list of resources, click the New button to add a new resource of this type

Table improvements

• Customize visible columns
• Additional sort/filter options
• Paste an identifier to quickly jump to a resource

📈 Builders can now export their data in Zus's Operational Data Store (ODS) in a transformed, columnar format to a SQL-compliant database for bulk analytic querying. Supported databases include Snowflake and BigQuery. For more information, see: https://docs.zushealth.com/docs/data-marts

With our new /patient-history endpoint, builders can initiate a search across clinical networks for all elements of a patient's medical history - from clinical encounters to prescription refills - with a single request.

View the complete specification here or download our Postman Collection

🚧

The medical-history and medication-history endpoints will be deprecated in the future, as responses from the /patient-history endpoint will include data from these sources) , please contact Zus for any assistance in updating request endpoints.

Builders can now grant access to their data in Zus to other Builders they have formal business relationships with (e.g., business associate agreement). For example, if you are a business associate and you want your customers to use Zus as part of your service offering to them, you can use Cross-Builder Grants to manage your customers' users and patient data in Zus on their behalf.

Builders can now allow end-users of their applications to interact with Zus APIs without requiring an additional login step. For more information, see: this tutorial in our User Authentication page.

Users can now interact with APIs in the Zus sandbox outside of Postman by logging in directly through this documentation site. Please read on for more details.

After completing their initial set up and authentication, users can now get an API access token without having to go through Postman. Simply log in with an email and password using the "Log In" button in the top right corner of this page, and the access token will automatically appear in the Authentication "Bearer" field in the "Try It" module for all supported endpoints in the API Reference page (example).

Builders can now subscribe to data creation and update activity in Zus's Operational Data Store (ODS). For more information, see: https://docs.zushealth.com/docs/subscriptions.

The latest Auth Service API is now the only Auth Service API available. The legacy Auth Service API has been removed, so users can no longer interact with the legacy API by setting the Content-Type API header to application/legacy+5-9-2022.

If you have any questions or concerns about the new Auth Service API, please complete this support ticket form and select "Account log-in/authentication" for the question "What portion of the Zus Developer Sandbox does your support ticket relate to?"

We are excited to release the new, default Auth Service API with capabilities closely aligned with the latest JSON v1.0 API spec. Please read on for details on breaking changes and legacy Auth Service API deprecation timeline.

The new Auth Service API is now the default. Users can opt out of the new Auth Service API to use the legacy API by setting the Content-Type API header to application/legacy+5-9-2022 until May 9, 2022, when the legacy Auth Service API will be deprecated.

The Auth Service API now includes pagination and expanded filtering capabilities for all endpoints, as well as a new “include” parameter for getting information about related objects. Auth Service API objects now consist of attributes and relationships, resulting in breaking changes (see below).

If you have any questions or concerns about the new Auth Service API, please complete this support ticket form and select "Account log-in/authentication" for the question "What portion of the Zus Developer Sandbox does your support ticket relate to?"

Breaking changes:

• The IdentityRoleLink object is no longer available, as users can be assigned to roles directly through the POST User endpoint.
• Casing changes
  • Object field names are camel case (e.g., RoleID instead of role_id)
  • URL terms are kebab case (e.g., app-clients instead of appclients)
• Model structure changes for all object models: fields other than type or id are now modeled as attributes of the object or relationships to the object. Example:

{
  "type": "auth/users",
  "id": <UUID>,
  "attributes": {
    "email": <string>,
    "name": <string>,
    "userType": <string>
  }, 
  "relationships": {
    "role": {
      "data": { "type": "auth/roles", "id": <UUID> }
    }, 
    "practitioner": {
      "data": { "type": "fhir/practitioner", "id": <UUID> }
    }
  }
}