Primary use refers to using health data for direct care, diagnosis, treatment, and related patient-facing purposes. Secondary use refers to broader reuse for research, policymaking, innovation, and other permitted non-care activities. The distinction matters because the lawful basis, access rules, governance expectations, and oversight obligations are not the same for each use case.
How primary and secondary use differ in EHDS
Primary use is the data use that supports the patient’s immediate care journey: diagnosis, treatment, follow-up, and other clinically necessary activity. Secondary use is separate reuse of electronic health data for purposes such as research, public health, policymaking, innovation, and other authorised non-care uses. EHDS treats those as different governance pathways because the purpose, access conditions, and oversight model are not the same.
That separation matters in practice because the same dataset can be lawful in one context and tightly restricted in another. A clinician or care team needs information that is relevant to care, while a secondary-use requester typically needs governed access under an approved purpose, with stronger controls around minimisation, transparency, and permitted reuse.
What changes in governance, access, and lawful basis
Under primary use, the central question is whether the data is needed to care for the individual and whether access is appropriate for the care role. Under secondary use, the central question becomes whether the reuse is permitted for a specified non-care purpose and whether the requester is operating under the EHDS rules for that purpose. That is why the control model shifts from clinical need and direct service delivery to purpose limitation, authorisation, and oversight.
For practitioners, this means the governance decision is not just “can we access the record?” but “for which use, under which rules, and with what restrictions?” A workflow that is acceptable for a treating provider may fail for analytics or research if the purpose, identity of the requester, or scope of access does not match the permitted secondary-use pathway.
For the privacy and security baseline behind this split, the distinction aligns with the broader data-governance expectations reflected in EU General Data Protection Regulation (GDPR), especially purpose limitation, security of processing, and privacy by design. The operational lesson is that purpose needs to be enforced as a control, not left as a policy statement.
Why the distinction matters for implementation and oversight
EHDS is not simply a label change for the same access pattern. Primary use is usually organised around direct care workflows, clinical accountability, and timely availability. Secondary use usually requires additional request handling, approval logic, logging, and dataset governance so that non-care users do not receive unconstrained access to identifiable health data.
That is also why data access boundaries matter technically, not only legally. If the same platform, API, or repository serves both uses, the system must keep the contexts separated so that a care user does not gain research-style reuse rights by accident, and a secondary-use user does not inherit direct-care access assumptions. The same principle is reinforced in identity and access controls for healthcare environments, including the operational realities covered in Healthcare Identity Security Guide.
Where organisations fail, it is usually because they treat “health data access” as one homogeneous control problem. In reality, the safest design is to separate the policy decision, the identity or role that requests access, and the dataset form that is exposed. That reduces the chance that a legitimate care use silently expands into a broader reuse case.
Risk and Threat Considerations
When primary and secondary use are blurred, health data can be overexposed, reused beyond its approved purpose, or handed to a requester with broader access than intended. The risk is not only regulatory, it is also operational: once a platform allows mixed-purpose access, it becomes harder to prove that each retrieval was appropriate for its stated use.
Failure mechanism: Misclassification of the request, weak role separation, or poor dataset partitioning lets a non-care user obtain care-path data, or lets care workflows consume data under secondary-use assumptions that were never intended for direct treatment.
Impact: The organisation can lose control over lawful basis, access scope, and auditability, which increases compliance exposure and can undermine trust in the EHDS implementation itself.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while GDPR and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| GDPR | Art.5 — Principles relating to processing of personal data | EHDS primary vs secondary use hinges on purpose limitation and lawful processing. |
| Art.25 — Data protection by design and by default | EHDS implementations need technical separation of care and reuse pathways. | |
| Art.32 — Security of processing | Different EHDS uses require access control, logging, and protection against misuse. | |
| Recommendation — Apply purpose limitation and data minimisation to separate care use from secondary reuse. Build use-specific access controls and defaults into the data platform. Protect health data with role-based access, logging, and appropriate safeguards. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | EHDS requires enforcement of different access rights for primary and secondary use. |
| AU-2 — Event Logging | Secondary use needs auditability of who accessed which health data and why. | |
| Recommendation — Enforce access rules that vary by use case and requester role. Log access events with purpose and requester context for review. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | EHDS distinction depends on separate access rules for care and reuse. |
| Recommendation — Define and enforce access rules by intended use and authorised role. | ||
Practitioner Guidance
What to verify: Verify that your EHDS workflow can distinguish the purpose of access before data is released, not after. If the same interface serves both care and reuse, confirm that the purpose flag, requester role, and dataset policy are all checked together.
Common mistake: Do not rely on “healthcare user” as a sufficient access category. A clinician, analyst, researcher, and policymaker may all touch the same underlying data, but they do not belong in the same access path or approval model.
Decision rule: If the data is being used to support a current patient’s care, treat it as primary use and optimise for necessary access and continuity. If the requested use is broader than care, treat it as secondary use and require the tighter governance path, even when the data source is the same.
Practitioner takeaway: The EHDS distinction is less about where the data came from than about what the requester is allowed to do with it. Strong implementations enforce that difference in workflow, authorisation, and audit evidence, not just in policy text.
Related resources from NHI Mgmt Group
- What is the difference between collecting data for public health and retaining data for future secondary use?
- What is the difference between attack surface management and NHI governance?
- What is the difference between reviewing human access and reviewing NHIs?
- What is the difference between role-based access and API key governance for NHI security?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
