Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.omophub.com/llms.txt

Use this file to discover all available pages before exploring further.

This page explains what data flows through OMOPHub, what gets stored, and how the API handles authentication and privacy. It’s written for security reviewers, compliance officers, and developers evaluating OMOPHub for production use.

​
1. The Core Principle: No PHI

OMOPHub is a vocabulary lookup service. It receives medical terminology codes and concept identifiers. It does not receive, process, or store Protected Health Information (PHI). A typical API call looks like this: 
curl https://api.omophub.com/v1/concepts/201826 \
  -H "Authorization: Bearer oh_xxxxxxxxx"
The request contains an OMOP concept ID. The response contains vocabulary metadata - concept names, codes, domains, relationships. No patient identifiers, no clinical records, no dates of service, no free-text notes.
Do not include PHI in API requests. OMOPHub endpoints accept concept IDs, vocabulary codes, and search terms. If your workflow involves patient data, resolve the vocabulary codes before or after the patient-data processing step - never send patient-linked data to the API.

​
2. Authentication

All API access requires a Bearer token in the Authorization header: 
Authorization: Bearer oh_xxxxxxxxxxxxxxxxxxxx
API keys are:
  • Per-user - each key is tied to a specific account
  • Revocable - deactivate a key at any time from the dashboard
  • Scopeable - create separate keys for different environments (dev, staging, production)
API keys are transmitted over HTTPS (TLS 1.2+). All API endpoints enforce HTTPS - plain HTTP requests are rejected. The FHIR Terminology Service additionally accepts OAuth2 client_credentials via POST https://fhir.omophub.com/oauth2/token for Spring Security OAuth2 clients (HAPI FHIR JPA Starter, EHRbase). The token endpoint accepts both client_secret_basic and client_secret_post methods. See the FHIR Terminology Service authentication section for details.

​
3. What OMOPHub Stores

About you. Email address, account metadata, API key hashes (not plaintext keys), and usage metrics (call counts, endpoint distribution). This data is used for authentication, billing, and service improvement. About your requests. OMOPHub logs API request metadata for operational purposes: timestamp, endpoint path, response status, latency, and API key identifier. Request parameters (search terms, concept IDs, vocabulary filters) may be logged for debugging and service quality. These logs are retained for operational purposes and are not shared with third parties. About vocabulary content. OMOPHub hosts OHDSI ATHENA vocabulary data - concepts, relationships, and mappings. This is public reference data published by OHDSI, not customer data.

​
4. What OMOPHub Does NOT Store

  • Patient data or PHI
  • Clinical records or EHR data
  • IP addresses of end-users of your application
  • Your application’s source code or configuration
  • Custom mappings or transformation logic (those stay on your side - see Lean ETL Mapping Cache)

​
5. Encryption

  • In transit: All API traffic is encrypted via TLS 1.2 or higher
  • At rest: Data is encrypted using the hosting platform’s default encryption (AES-256)

​
6. Infrastructure

OMOPHub runs on Google Cloud Platform. The runtime surface is a managed container service with zero-downtime.

​
7. GDPR

OMOPHub processes limited personal data (email, usage metrics) under GDPR. The Privacy Policy and Data Use Agreement cover data-processing details. Users can request data export or deletion via omophub.com/contact.

​
8. Compliance Considerations

OMOPHub is a vocabulary reference service, not a clinical data processor. For most healthcare organizations:
  • HIPAA: Because OMOPHub does not receive PHI, it typically does not require a Business Associate Agreement (BAA). If your workflow architecture routes PHI through API calls (which it should not), contact us to discuss your specific setup.
  • SOC 2: Not currently certified. OMOPHub follows security best practices but has not undergone a formal SOC 2 audit.
  • GDPR: Compliant for the limited personal data processed (see §7 above).
If your organization requires a formal security review or vendor questionnaire, reach out via omophub.com/contact with your requirements.