Access Requirements

Accessing Patient Information

Purpose of Use

To ensure that only relevant parties have access to a patient's protected health information (PHI), a querying entity must specify a reason, or Purpose of Use. The national networks that power the Zus Grid are predominantly designed to support the treatment of patients. In order to demonstrate that, querying parties are expected to assert their treatment relationship:

• Their Purpose of Use
• The ID and name of the querying organization
• The ID and name of the clinician with the treatment relationship

When you are searching for medical history using the Zus API, you'll include that information in the headers of your API requests:

Reciprocity and Responding to Queries

Most major networks powering the Grid require "data reciprocity". Under this principle, builders are required to contribute unique clinical data resulting from any treatment event back to the network. When using the Zus, builders must share unique clinical data back so that Zus can respond to incoming requests on the builders' behalf.

Examples for how builders might contribute unique clinical data back to the network include:

• Writing data from an EHR
  • Example: Developing a bidirectional data feed between Zus and an EHR
  • Example: Posting a CCDA into Zus after each clinical encounter
• Writing data collected outside of the EHR back into Zus
  • Example: Contributing Zus form responses