AI is moving quickly in healthcare, but security reviews still determine what makes it into production. If you’re evaluating AI tools for your integration team, you need clear answers about how customer data is handled, what controls are in place, and where the risks are. This FAQ is designed to help security and compliance teams understand how Rhapsody Axon works, what data it touches, and what controls are in place.
Select a topic below to jump directly to that section.
- What is Axon?
- What can Axon do inside my environment?
- How does Axon handle Protected Health Information (PHI)?
- What happens if someone accidentally enters PHI anyway?
- Is my data isolated from other customers?
- Does Axon use my data to train AI models?
- How is Axon infrastructure secured and data encrypted?
- Where is Axon data stored?
- How does Axon handle authentication and access control?
- Who can access customer data and system logs?
- How does Rhapsody test Axon for security vulnerabilities?
- How does Rhapsody respond to security incidents?
- What compliance certifications and governance frameworks apply to Axon?
- Are there any limitations users should know about?
What Is Axon?
Rhapsody Axon is an AI assistant embedded in Rhapsody and Corepoint, for engineers. It answers questions about FHIR, Hl7, message routing, and integration configuration. With its agentic capabilities, Axon can also take actions into the IDE on a user’s behalf. Each agentic tool is opt-in and requires explicit consent before Axon can access anything about a user’s environment.
Here’s what Axon is not: Axon is not a clinical decision support tool, not patient-facing, and not an FDA-regulated medical device. It is a productivity tool for the integration engineers who build and maintain the pipelines that carry patient data.
What can Axon do inside my environment?
With the recent agentic release, Axon can now read and modify Rhapsody configuration directly within the IDE. Agentic capabilities are fully opt-in. Axon won’t read your IDE configuration or take any action in your environment until a user explicitly grants consent, one tool at a time.
Here’s how it’s designed:
- Explicit consent, tool-by-tool. Every agentic tool is turned off by default. Users must individually enable each one, and each tool’s description states what data it accesses. Axon pulls only the specific context needed for the current query. There’s no bulk configuration access.
- Human-in-the-loop, always. Before taking any action, Axon describes exactly what it intends to do and waits for user confirmation. Users can refine or reject the plan before anything happens. Axon never checks in changes on the user’s behalf. The engineer must review and commit, just as with any manual edit.
- Access rights inheritance. When Axon acts on behalf of a user, it operates within that user’s existing Rhapsody access rights. It cannot do anything the user themselves is not authorized to do.
Agentic tools use MCP (Model Context Protocol), an open and auditable industry-standard protocol, not a proprietary interface. The communication layer between Axon and your IDE is well-documented and can be independently reviewed.
How does Axon handle Protected Health Information (PHI)?
Axon is not designed to process PHI. Users are explicitly prohibited from entering patient data. This obligation is baked into the Terms and Conditions that every user must accept before first use. The terms define Axon as a technical agent for integration work and prohibit users from entering PHI or personally identifiable information (PII).
What happens if someone accidentally enters PHI anyway?
Axon does not currently have automated PHI detection or input blocking. If PHI is entered into Axon, it will be logged and stored in Rhapsody’s internal systems as part of normal usage. The customer must notify Rhapsody Support immediately.
From there, Rhapsody has a documented, step-by-step removal process that covers every storage layer where that data may have landed:
- Interaction traces
- User feedback scores
- Workflow database backups
Every scrubbing operation is tracked with the following:
- Timestamps
- Affected record IDs
- Operator identity
- Confirmation deletion
Because healthcare engineers work daily with sample messages and synthetic test data that looks similar to real patient records, PHI detection is harder for integration tooling than it might first appear. A guardrail that can’t reliably distinguish real patient records from test payloads will either generate too many false positives or miss the real thing. Rhapsody is working to build this capability carefully and will communicate when it’s ready.
In the meantime, the right controls are organizational policy and user training. Users should ensure that they understand these restrictions before enabling Axon.
Is my data isolated from other customers?
One of the most common questions healthcare CISOs ask is whether interaction data gets mixed across customers or fed back into an AI model in ways they can’t control. With Axon, customer data is isolated by customer account and is not accessible to the AI model and/or other customers.
Axon collects two categories of data when it’s in use:
- Technical telemetry — IDE version, session duration, feature usage, and error rates. Standard observability data used for troubleshooting and product quality.
- Interaction data — The queries your engineers type, the full prompts sent to the model, AI responses, any IDE configuration context read by opt-in agentic tools, and associated metadata.
Both are stored within Rhapsody-controlled AWS infrastructure, accessible only to authorized Rhapsody staff on a least-privileged, need-to-know basis. Critically, the interaction trace store is write-only and never read back into the model loop. This ensures one user’s data physically cannot surface in another user’s response. Each user’s sessions are isolated by user ID.
Does Axon use my data to train AI models?
This is one of the first questions security and governance teams ask. The answer is straightforward: No. Axon does not use your data to train any AI models.
Rhapsody doesn’t build or own a model. Axon runs on third-party large language models accessed through Amazon Bedrock, AWS’s managed AI inference service. Amazon Bedrock’s published security policy states directly: When you tune a foundation model, we base it on a private copy of that model. This means your data is not shared with model providers and is not used to improve the base models.
Rhapsody uses query and interaction data to improve its knowledge base content, prompt engineering, and retrieval logic, not to train models. The underlying model never sees your data in a way that modifies how it behaves for anyone else.
How is Axon infrastructure secured and data encrypted?
Axon is hosted in secure and certified AWS data center in the United States. Hosted servers are patched on a monthly cadence or as required for operating system and platform-level updates. Open-source libraries are continuously monitored for published security vulnerabilities (CVEs); patches addressing critical or high-severity issues are deployed outside the normal cycle when necessary. Patches are not applied automatically. They are reviewed and deployed by Rhapsody’s engineering team.
All Axon data is encrypted at rest and in transit using industry-standard protocols:
- At rest: Files stored in Amazon S3 and Axon chat traces stored in Elastic File System (EFS) are both encrypted with AES-256.
- In transit: All client-to-Axon communication uses HTTPS. S3 and EFS traffic use HTTPS/TLS. TLS 1.2 or higher is enforced for all inbound connections. Insecure protocols and weak cipher suites are disabled.
- Key management: Encryption keys are generated, stored, and rotated through AWS Key Management Service (KMS), backed by Hardware Security Modules (HSMs). Access is restricted to authorized Rhapsody personnel under role-based least-privileged controls.
The Axon service uses a certificate issued for *.axon.rhapsody.health via AWS Certificate Manager with a 13-month lifetime. No self-signed certificates are used.
Where is Axon data stored?
All data resides in AWS US-East-2. Some inference requests may route to other US AWS regions, but no Axon data is stored outside the United States. Axon has a single sub processor (AWS), and no other third party touches customer data in Rhapsody’s infrastructure.
How does Axon handle authentication and access control?
Axon authenticates users through Rhapsody’s OneLogin instance. Every user must log in before they can use Axon, whether accessing via the IDE, the web interface, or the OneLogin landing page. Federation with a customer’s own identity provider is not currently supported.
Authentication on calls to the MCP tools is handled via an OAuth 2.0 Bearer token supplied by the IDE. Authorization on the Axon platform is broadly controlled by RBAC within OneLogin and Permit.io policies.
Administrators have two levels of access control:
- IDE-level disable: An administrative setting in the IDE turns Axon off for all users in your organization within the IDE.
- Full access block: Organizations that need to prevent all access, including the web interface and OneLogin landing page, can request a domain-level block through their Rhapsody account team.
Axon Chat is available by default, but every interaction is user initiated. Users must actively launch a chat before any prompts or data are sent.
Who can access customer data and system logs?
Axon generates logs across several layers:
- System-level activity logging exists across all infrastructure components via CloudWatch. AWS CloudWatch receives log streams from every component in the stack: the Axon UI, the Axon API, Langfuse (the AI observability platform), the Langfuse Aurora PostgreSQL database, and Amazon Bedrock. This gives you a system-level activity trail across the infrastructure.
- Langfuse Interaction traces provide a record of what queries were made and what responses were generated. interaction traces capture the full trace of every conversation round — user query, constructed prompt, tool calls, model response — written to AWS Aurora PostgreSQL. This store is write-only (never read back into the model loop) and is used for quality and safety monitoring.
- Session history (trace data) is stored separately in its own Clickhouse database (EFS, AES-256 encrypted. Logs can be traced back to specific users, sessions, and timestamps.
- User feedback scores (thumbs-up/thumbs-down) are also stored in Langfuse and linked to traces.
- All storage is within Rhapsody-controlled infrastructure in AWS US-East-2. Customers cannot access these logs directly. They must request extracts through their Rhapsody account team. Rhapsody staff access to logs is governed by least-privileged, role-based controls.
How does Rhapsody test Axon for security vulnerabilities?
Axon’s development referenced the OWASP Top 10 for LLM Applications, which specifically calls out prompt injection as a key risk. The primary structural mitigations are RAG grounding, meaning Axon’s responses are anchored to curated Rhapsody documentation, not the open web. Mandatory human review is required before any agentic change is committed.
Infrastructure patching runs on a monthly cadence for OS and platform updates. Open-source libraries are continuously monitored for CVEs, with critical and high-severity patches deployed outside the normal cycle when needed. All AI changes go through a staging environment before production, and staging never uses production or customer data.
Rhapsody maintains evaluation datasets covering key query categories to benchmark response quality and catch regressions before and after model or knowledge base changes. User feedback (thumbs-up/thumbs-down) flags specific interactions for quality review.
How does Rhapsody respond to security incidents?
Rhapsody provides 24×7 monitoring and incident response for the Rhapsody Cloud environment. The run-time monitoring Cloud Native Application Security Platform (CNAPP) used provides complete visibility of customer cloud deployments allowing us to detect and respond to security events in real-time. Incidents escalate from the Rhapsody Security Operations Team to senior engineering, security leadership, and compliance management based on severity. The process is governed by Rhapsody’s Incident Response SOP. Customers are notified consistent with contractual commitments.
What compliance certifications and governance frameworks apply to Axon?
Rhapsody is trusted by over 1,900 healthcare organizations worldwide in part because of its long-standing commitment to security and compliance. Rhapsody certifications include ISO 27001: 2022, HITRUST e1, UK Cyber Essentials Plus and SOC 2 Type II report. Rhapsody is also certified under the EU-US and UK-US Data Privacy Framework.
Axon is built within that same governed environment and is compliant with Rhapsody’s security standards and contractual commitments. Current AI governance relies on OWASP Top 10 for LLM guidance, continuous observability monitoring, human-in-the-loop requirements, and Rhapsody’s documented Gen AI policy.
Documentation available for governance reviews:
- Data Privacy and Security FAQ: Primary self-serve resource covering data collection, model usage, encryption, PHI handling, and customer controls.
- Data flow diagram: Available from your Rhapsody account team.
- Terms and Conditions: Available from your Rhapsody account team.
- Amazon Bedrock Security and Compliance policy: Publicly available at aws.amazon.com/bedrock/security-compliance.
- Rhapsody Trust and Compliance Center: Available at rhapsody.health/trust-center.
Are there any limitations users should know about?
Transparency is an important part of security. Here are the capabilities planned or currently in development, along with the controls available today:
- PHI detection and input guardrails: In active development. Organizational policy and user training are the current primary controls.
- Data residency outside the United States: On the longer-term roadmap. Customers with strict in-country requirements in APAC or EMEA should factor this in.
- Automated SIEM integration for audit logs: Not yet available. Audit log extracts can be requested from your Rhapsody account team. In the meantime, organizations should rely on monitoring, human-in-the-loop requirements, and Rhapsody’s documented generative AI governance policy.
- Customer identity provider federation: Not currently supported. Authentication is via Rhapsody’s OneLogin instance.
Now that your due diligence is done, let’s talk.
Healthcare interoperability demands trust. Rhapsody built Axon to help integration teams work faster without compromising security or governance. If you have questions, your Rhapsody account team can provide architecture diagrams, Terms and Conditions, and any documentation needed for your security review.
Ready to spend less time searching for answers and more time building? Discover how Rhapsody Axon helps healthcare integration teams build faster with AI embedded directly into Rhapsody and Corepoint.
