Data handling and security
Keep credentials on your server and clinical data within the intended workflow.
Store and transmit credentials safely
Use HTTPS for hosted API requests. Store tokens in a server secret manager and expose them only to the integration process that needs them. Never embed a key in a website, mobile app, URL or shared configuration example. Documentation has no token input or live API explorer.
Choose minimal scopes, set an appropriate expiry, rotate keys and revoke access when an integration or a person that knew the token is offboarded. Clinic-owned keys keep working when their issuer logs out or leaves the clinic, until expiry or revocation.
Enforce your own access boundary
A key can read data across its clinic within its scopes. Your application must authorize its own users before displaying that information. Do not forward the Bearer key to a browser as a shortcut for application authorization.
Avoid unnecessary persistence. If your workflow stores clinical data, apply its access controls, retention and deletion policies to the copy. The API does not establish a retention policy for your system.
Redact logs and support requests
Record only operational metadata needed to diagnose the integration: operation, status, finite error code and request ID. Do not log authorization headers, raw response bodies, patient identifiers or names, clinical values or documents. Review HTTP tracing, error reporting and reverse-proxy defaults as well as application logs.
Understand the data’s meaning
Only approved results are published, with final stored observations. Decimal strings retain precision. Stored reference ranges and statuses are not recalculated current normality or an immutable snapshot. Read approved results and observations before mapping fields into a report.