Dpa Template

Data Processing Addendum (Template)

Note: This template is provided for informational purposes. Because Tessara’s architecture never accesses, processes, or stores Protected Health Information (PHI), a DPA is typically not required. This template is available for organizations whose procurement process requires a formal agreement regardless.

1. Introduction

This Data Processing Addendum (“DPA”) forms part of the Master Service Agreement between [Customer Name] (“Customer”) and [Tessara Legal Entity] (“Tessara”).

2. Architecture and Data Handling

Tessara’s architecture is fundamentally designed to prevent access to Protected Health Information (PHI):

  • Metadata-Only Probing: Tessara reads the FHIR API’s /metadata endpoint (CapabilityStatement), which contains structural information about supported resources and operations — not patient data.
  • No Payload Access: Tessara never accesses, intercepts, or processes API request/response payloads containing patient data.
  • Local Storage: The only data Tessara stores is structural metadata hashes and signed compliance verdicts in a local SQLite database on the Customer’s infrastructure.

3. Data Ownership

The Customer retains all rights, title, and interest in and to all data within their FHIR API infrastructure. Tessara acquires no rights in Customer data. Tessara’s analysis is limited to publicly available structural metadata (CapabilityStatement) and produces only conformance verdicts and structural hashes.

4. Security Controls

Tessara maintains the following security controls:

  • Cryptographic Integrity: SHA-256 Merkle hash trees for structural baseline integrity, canonicalized via RFC 8785 JCS.
  • Non-Repudiation: Ed25519 digital signatures on all conformance verdicts, creating a tamper-evident evidence chain.
  • Transport Security: TLS encryption for all HTTP probes to target APIs. Configurable TLS certificates for the dashboard API.
  • Access Control: API key and JWT-based authentication for the dashboard API. CORS origin restrictions enforced (wildcard origins rejected in production).
  • SSRF Defense: 3-layer protection (URL validation, DNS resolution check, private IP block list) on all outbound probes.

5. Regulatory Compliance

Tessara facilitates the Customer’s compliance with CMS-0057-F and FHIR R4 standards by providing continuous, automated verification of API structural conformance against mandated Implementation Guides.

6. Audit Rights

Customer shall have the right to conduct an annual audit of Tessara’s security controls and compliance with this DPA, provided such audit is conducted during normal business hours and with reasonable prior notice.

7. Dependency Transparency

Tessara has two external software dependencies, both under permissive open-source licenses:

  • github.com/spf13/cobra (Apache 2.0) — CLI framework
  • modernc.org/sqlite (BSD-3-Clause) — embedded database driver

A complete third-party license inventory is maintained in the THIRD-PARTY-LICENSES file.

Signatures:

Customer: ____________________ Name: __________________________ Date: __________________________

[Tessara Legal Entity]: ____________________ Name: __________________________ Date: __________________________

DRAFT — counsel review pending. This document is provided for procurement discussion. Final legal terms subject to attorney review and counterparty redlines.