For Healthcare Exchange Partners
This page explains, in plain language, how certificates are used when connecting to RosettaHealth systems and what we need from you to get connected quickly and securely.
You do not need to be a PKI expert to complete onboarding.
Why are you asking about certificates at all?
When healthcare systems exchange data directly (for example via IHE XDR/XDS or secure APIs), we use mutual TLS (mTLS) to ensure:
We know who is connecting
You know who you are connecting to
The connection cannot be impersonated or intercepted
Unlike websites, these connections are system-to-system, not browsers and users.
Why can’t we just use a normal public TLS certificate?
Public certificates (the kind browsers trust automatically) are no longer appropriate for system-to-system healthcare connections.
Starting in 2026, public Certificate Authorities will no longer issue certificates suitable for mTLS authentication. This change is driven by industry trust program updates and security best practices.
For healthcare exchange, certificates must come from a private Certificate Authority (CA).
What is a “private CA” in simple terms?
A private CA is just a service that issues certificates only for your organization (or your healthcare network), instead of for the entire public internet.
Think of it like:
A badge printer for your hospital or vendor systems
Not a public ID card that anyone can buy
Do we have to run our own CA?
No — and most organizations shouldn’t.
There are three acceptable approaches:
1. Use an industry or healthcare trust service (recommended)
Some organizations use established healthcare trust providers that already manage PKI governance, audits, and revocation.
This is often the fastest and lowest-risk option.
2. Use a managed cloud private CA (very common)
Many cloud-based EHR vendors use managed services such as AWS Private CA.
This works well as long as it is configured correctly (we provide a checklist to help).
3. Run your own CA (advanced)
Some large organizations operate their own CA infrastructure.
This is acceptable, but it requires:
Formal policies
Hardware security protection
Revocation and auditing
If you choose this path, we’ll ask a few more questions.
We’re working with RosettaHealth through a state HIE or customer — does that change anything?
Not really.
RosettaHealth often operates exchange infrastructure on behalf of our customers under a Business Associate Agreement (BAA). However:
You still own your certificates
You are still responsible for how they are issued and revoked
The trust requirements are the same regardless of who operates the exchange layer.
What are you actually checking during onboarding?
We’re not inspecting your crypto math or judging your tooling.
We’re checking for a few basic outcomes:
Do you control who can get certificates?
Are the certificate keys protected?
Can certificates be revoked if something goes wrong?
Is there a way to audit who issued what?
That’s it.
What do we need to provide?
To keep this simple, we use short checklists.
You’ll complete one of these depending on how you issue certificates:
Managed Cloud CA (AWS Private CA) checklist
Self-Managed CA checklist
Each checklist asks yes/no questions and where needed, a short explanation or URL.
You do not need to write a thesis.
Do we need to send you private keys?
Absolutely not. Never.
We will never ask for:
Private keys
Root CA keys
Access to your CA systems
We only need:
The issuing certificate(s)
Revocation URLs (CRL or OCSP)
Confirmation of how your CA is managed
What happens if we don’t meet a requirement?
Usually one of three things:
There’s a simple configuration fix (very common)
We agree on a short remediation plan
In rare cases, we can’t establish trust and can’t enable connectivity
Our goal is to get you connected, not to block you.
We don’t really have PKI experts — can you help?
Yes.
This is extremely common, especially outside of security teams.
We can:
Walk through the checklist with you
Explain what a question is really asking
Help confirm whether your cloud provider setup is sufficient
If you’re unsure, just say so — that’s normal.
Why is this necessary for healthcare?
Healthcare exchange has unique risks:
PHI exposure
System impersonation
Long-lived machine credentials
Regulatory audit expectations
These requirements exist to protect patients, providers, and networks, not to make onboarding harder.
Where do we start?
Decide how you issue certificates today
Complete the appropriate checklist
Send it back as part of onboarding
If you’re unsure which checklist applies, just ask — we’ll point you in the right direction.
Contact
If you have questions during onboarding, reach out to your RosettaHealth integration contact or security representative.
We’re happy to help.