One of the questions we get most often from clinical research teams evaluating CliniNote is some version of: "Are you HIPAA compliant?" The honest answer requires a bit of unpacking, because the question conflates two different things: the legal framework HIPAA establishes for covered entities, and the data handling practices that responsible clinical software vendors should follow regardless of their technical HIPAA status.
Let us be direct about what HIPAA actually requires and where CliniNote sits in relation to it, because the clinical software market has enough overclaiming on this topic that researchers deserve a clear explanation from any vendor they are considering.
What HIPAA does and does not cover
HIPAA applies to covered entities: healthcare providers that conduct electronic transactions, health plans, and healthcare clearinghouses. It also applies to business associates of covered entities through the BAA mechanism. If a hospital uses CliniNote to process note data from their patient records, the hospital is a covered entity and CliniNote is a business associate under HIPAA, and a BAA is required and available.
What HIPAA does not do is certify or audit vendor software. There is no "HIPAA certification" for software products. When a vendor claims to be "HIPAA certified," they are either referring to an unofficial audit by a third-party compliance consultant, or they are using the phrase inaccurately. The Office for Civil Rights (OCR), which enforces HIPAA, does not issue software certifications. A well-designed software system can be HIPAA-compliant in the sense of meeting the Security Rule's required and addressable safeguards. Claiming to be "HIPAA certified" as a marketing statement is not the same thing.
We say we are "designed with HIPAA controls in mind" because that is accurate. We implement the administrative, physical, and technical safeguards described in the Security Rule. We execute BAAs with covered entities. We do not claim a certification that does not exist for the purpose of sounding more trustworthy. If you encounter a vendor who does, that is worth asking about in detail.
Where GDPR overlaps and diverges
CliniNote is a Polish company operating under EU jurisdiction, which means patient data processed through our systems is subject to GDPR. For EU clinical research teams, this is the primary regulatory frame, not HIPAA. For US-based researchers working with de-identified data, the applicable regulation is typically neither HIPAA nor GDPR but rather the standards for the specific de-identification method (Safe Harbor or Expert Determination under the HIPAA Privacy Rule).
GDPR Article 9 covers special categories of personal data, which explicitly include health data and genetic data. Processing of health data requires explicit consent or a recognized legal basis for processing, and the rights of data subjects (access, erasure, portability) apply. Our data processing agreements for EU customers address these requirements. For research processing under Article 9(2)(j), specific conditions apply, and we work with institutional research teams to confirm the appropriate legal basis before processing begins.
The practical point for clinical research teams is that the regulatory question for research data is jurisdiction-dependent, data-state-dependent (identifiable versus de-identified), and use-dependent (clinical care versus research). No single claim about compliance status answers all of these dimensions at once. When a team asks "are you compliant," the productive follow-up is: with which framework, for which data state, for which use case, and what documentation does your institution require?
The de-identification question and its complexity
Most clinical research teams working with EHR notes handle the patient privacy problem by de-identifying data before sending it to any third-party tool. The two recognized de-identification methods under HIPAA are Safe Harbor (removal of 18 specific identifier types) and Expert Determination (statistical certification by a qualified expert that re-identification risk is very small).
De-identified data is not PHI under HIPAA and therefore does not trigger HIPAA's BAA requirements for downstream vendors. This is the standard approach for research use of EHR data, and it is how most research teams we work with operate: they run de-identification through their institution's certified de-identification tooling before exporting to CliniNote.
The complication is that clinical NLP depends on entity mentions in text that include names, dates, and location references. Safe Harbor de-identification removes dates of service, birth dates, and geographic identifiers below the state level, but clinical NLP pipelines that depend on accurate date extraction may lose significant functionality on notes that have been Safe Harbor de-identified. The dates that NLP needs for temporal reasoning may be the same dates that Safe Harbor de-identification removes. Expert Determination methods that preserve more clinical information while certifying de-identification are technically preferable for NLP use, but require more work to execute and may not be available through standard institutional de-identification infrastructure.
We tell teams this tradeoff directly rather than claiming our systems work equally well on all de-identified data regardless of the de-identification method applied. Temporal extraction quality will be reduced on Safe Harbor de-identified data. If temporal analysis is critical to the research question, the team needs to plan for that in the de-identification approach.
What our actual data controls look like
Separate from the regulatory framing, here is what we actually implement. Data uploaded to CliniNote is encrypted at rest using AES-256. Data in transit uses TLS 1.3 with certificate pinning for API connections. Organization-level data isolation means that a research team's uploaded notes are never accessible to another organization's extraction jobs. We maintain no cross-organization data stores for note content.
Extraction jobs process notes in an isolated environment. The input notes and the extraction outputs are associated with the specific job and project, not with a persistent patient record in our system. We do not retain raw note text beyond the session unless the user explicitly creates a saved project. Job outputs, including extracted entities and confidence scores, are stored at the project level under the user's account and are exportable and deletable by the account administrator.
We do not use patient data uploaded to CliniNote to train, fine-tune, or improve our extraction models. This is a commitment we hold as a product policy, not a regulatory requirement. The reason is that using research data for model training without explicit researcher consent would be a breach of the research team's obligation to their IRB and institutional data governance framework. The training data for our models comes from publicly available de-identified clinical corpora and annotated data sets prepared specifically for that purpose.
Where this leaves clinical research teams practically
For a team evaluating CliniNote for a research project, the data governance questions to resolve before starting are: what is the de-identification status of the data, does your institution require a BAA or DPA with tools used for research data processing, and what is the IRB-approved data handling plan for this project. We provide standard BAA language for covered-entity relationships and DPA language for GDPR-covered processing. We can participate in institutional security review processes. We can answer specific questions about our infrastructure and data handling for institutional review boards.
What we will not do is claim certifications that do not exist to make this process faster. A BAA is a legal agreement, not a badge. Data residency in the EU (Frankfurt region for EU data) is an architectural fact, not a marketing claim. The controls we implement are real, documented, and available for institutional review. That is what responsible data design looks like for a clinical tool that is not a covered entity itself, and it is the posture we think any team should expect from vendors in this space.
