利用 Amazon Bedrock 为医疗健康 API 构建智能安全防护

如果你负责管理 Fast Healthcare Interoperability Resources (FHIR) API，就必须在开放患者数据访问与严格的数据保护要求之间取得平衡。随着临床工作流不断演进，静态安全规则需要持续更新，而手动维护这些规则会造成合规缺口。借助 Amazon Bedrock——一项通过单一 API 提供基础模型（FM）访问能力的全托管服务——你可以为医疗健康 API 构建智能安全防护。该安全机制可监控访问模式、自动分类数据敏感性，并以自然语言生成合规报告。这种方法有助于减少文档工作量、降低手动维护规则的负担，并让安全监控能够适应临床工作流的变化。

本文将介绍如何使用 Amazon Bedrock 为 FHIR API 添加具备上下文感知能力的安全监控。首先，我们说明一种将安全监控与 FHIR API 请求路径分离的架构，使你能够在不影响 API 延迟的情况下加入行为分析。接着，我们将讲解如何利用 Amazon Bedrock 和 Structured Outputs 实现异常检测，从而捕获静态规则遗漏的访问模式。随后，我们将演示自动化数据敏感性分类，免除硬编码映射表的需求。最后，我们将展示如何用自然语言生成合规报告，以缩短审计准备时间。该解决方案使用 AWS Lambda、Amazon API Gateway、AWS HealthLake、Amazon EventBridge、Amazon Cognito、Amazon Bedrock Guardrails 和 Amazon Comprehend Medical。其中还包括一个配套代码示例，提供完整的 AWS CloudFormation 模板、五个 AWS Lambda 函数，以及可适配你所在环境的部署脚本。

前提条件

要部署此解决方案，你需要：

• 一个拥有管理员访问权限的有效 AWS 账户。
• 已安装并配置 AWS Command Line Interface（AWS CLI）v2（aws configure）。
• Amazon Bedrock 现在会自动授予对受支持模型的访问权限。请通过 Amazon Bedrock 模型访问权限页面确认相关模型在你的 AWS 区域中可用。
• 一个已经验证的电子邮件地址，用于接收 Amazon Simple Notification Service（Amazon SNS）安全告警通知。
• 如果你的 AWS 账户此前从未将 Amazon API Gateway 与 Amazon CloudWatch Logs 集成使用，则必须先在账户的 API Gateway 设置中配置 CloudWatch Logs 角色 ARN。否则，部署将因“CloudWatch Logs role ARN must be set in account settings.”而失败。具体说明请参阅 在 API Gateway 中设置 CloudWatch API 日志记录。
• 预计部署时间：10-15 分钟。预计月度成本因使用量而异。当前费率请参阅 Amazon Bedrock 定价页面。AWS HealthLake 的费用单独计算。

架构概览

你可以了解谁正在访问 FHIR 数据，以及这些访问行为是否正常。Amazon Bedrock 中的基础模型会根据用户的历史行为、角色以及所请求数据的敏感性评估每个请求。结果是一份可供你采取行动的、以通俗英语表述的风险评估。

现有的授权控制仍然保留。你将继续实施基于角色的访问控制（RBAC），并通过 AWS Lambda 授权器验证 JSON Web Token（JWT）——即用于证明用户身份的已签名令牌。在此基础上，你还可以获得能够捕获静态规则无法识别模式的行为分析能力。例如，某个用户在自身权限范围内访问数据，但访问量或访问时间异常，便会触发告警。

下图展示了安全监控如何独立于主 API 路径运行，因此不会为临床工作流增加延迟。

图 1：由 Amazon Bedrock 驱动的 FHIR API 安全监控系统架构

以下是“先请求、后分析”流程的工作方式。Amazon API Gateway 接收传入的 FHIR 请求，并执行限流和请求验证。AWS Lambda 授权器会验证 JWT，并检查存储于 Amazon DynamoDB 中的细粒度权限。

随后，AWS HealthLake 作为符合 HIPAA 资格的全托管 FHIR R4 数据存储，提供 FHIR 数据。FHIR 处理器 AWS Lambda 函数会捕获访问详情，并通过 Amazon EventBridge 将其路由至三个异步 AWS Lambda 函数：异常分析器、敏感性分类器和合规报告器。每个函数都会通过 Amazon Bedrock Guardrails 资源调用 Amazon Bedrock，该资源会对提示词和响应中的受保护健康信息（PHI）进行匿名化。异常分析器还会在写入审计日志前使用 Amazon Comprehend Medical 对 PHI 进行脱敏。Amazon CloudWatch 会在整个流程中捕获结构化日志，以形成审计轨迹。

你可以从完全异步的分析中获益。Amazon EventBridge 会在 FHIR 响应已经返回给客户端后，将访问事件路由至分析器 AWS Lambda 函数。你的 API 延迟不会受到影响，同时仍能获得持续的安全监控。

如果分析器暂时不可用，FHIR API 仍会正常提供请求服务。监控层不会阻塞临床工作流。

HIPAA 防护措施

该解决方案实施多层 PHI 保护措施，以防止受保护健康信息通过监控管道泄露：

• Amazon Bedrock Guardrails： AWS CloudFormation 模板会部署一个 AWS::Bedrock::Guardrail 资源。它可检测并匿名化发送到 Amazon Bedrock 的提示词和模型响应中的个人身份信息（PII）实体，包括姓名、社会保障号码、地址、电话号码和病历号。社会保障号码和护照号码会被完全阻止，而非匿名化处理。
• Amazon Comprehend Medical： 在将 Amazon Bedrock 响应写入 Amazon CloudWatch Logs 前，异常分析器会通过 Amazon Comprehend Medical 中的 DetectPHI API 处理文本。检测到的 PHI 实体会替换为类型标签，例如 [NAME]、[DATE]，从而使审计日志可用于合规审查，同时不包含实际患者数据。
• IP 泛化： 异常分析器的提示词绝不会向 Amazon Bedrock 发送原始 IP 地址。相反，它会基于 RFC 1918 地址段将来源分类为“内部”或“外部”，从而避免 PII 进入模型上下文。
• 无 PHI 告警： 当异常分析器触发 Amazon SNS 告警时，通知仅包含经过哈希处理的参考 ID 和风险等级。安全团队可使用该参考 ID 从审计日志中获取完整详情，这有助于防止电子邮件通知包含 PHI。
• Structured Outputs： 本解决方案中的 Amazon Bedrock 调用使用带有 JSON schema 和枚举值约束字段的 Structured Outputs（字段仅限于一组固定的有效值）。这减少了对自由文本的解析需求，并有助于确认模型响应符合可预测的格式，从而降低意外 PHI 出现在下游处理中的风险。
• 已清理的错误消息： FHIR API 错误响应会向客户端返回通用消息，而不是内部异常详情；后者可能会无意中包含来自 AWS HealthLake 响应的患者数据。

使用 Amazon Bedrock 进行异常检测

通过分析不同临床用户群体的行为模式，你可以识别基于规则的系统容易遗漏的复杂访问异常。分析器 AWS Lambda 函数是该架构的核心。每次 API 调用都会生成一个访问事件，基础模型会根据用户角色、访问历史和请求性质评估该事件。

设想一名医生通常会在工作时间访问 5-15 条患者记录。如果同一名医生在凌晨 3 点下载了 500 条记录，静态规则就需要为每一种角色和时间组合显式设定阈值。借助 Amazon Bedrock，你可以评估完整上下文，并获得带有通俗英语解释的风险评估。

临床用户群体十分多样，包括医生、护士、计费人员、研究人员和第三方集成。每个群体都有不同的正常访问模式，并且这些模式会随时间变化。运行回顾性研究的研究人员可能在单次会话中合法访问数千条记录。基础模型会通过检查用户角色、请求性质以及访问是否遵循正常认证模式，将这种情况与未授权访问区分开来。

异常检测会为每位用户构建行为基线，而不是应用面向全体用户的阈值。这种方法可降低系统性标记夜班临床医生、国际研究人员或常规在标准工作时间外工作的值班医生之合法访问模式的风险。

不同调用方类型具有不同的风险特征。SMART on FHIR 应用、患者门户和健康信息交换（HIE）连接各自具有不同的预期行为。访问事件包含 OAuth client_id，因此分析器能够维护应用特定的基线，并根据集成类型应用差异化风险评分。

组织还可以通过值班安排、急诊科启动状态或医疗团队分配等临床上下文进一步丰富访问事件。例如，在大规模伤亡事件期间，医生于凌晨 3 点访问 500 条记录，不应触发与平常夜间相同的风险评估。提示词设计可在相关信息可用时纳入这些额外上下文。

此实现采用故障开放（fail-open）方法。故障开放意味着，如果分析器发生错误，它会记录失败情况，但不会阻止原始 API 请求。我们选择这一方式而不是故障关闭（fail-closed）方法——后者会在发生错误时阻止请求——因为分析器中断不应给临床工作流带来可用性问题。在监控层恢复期间，FHIR API 会继续正常处理请求。

异常分析器使用带有 Structured Outputs 的 Amazon Bedrock Converse API，强制执行包含枚举值约束风险等级（LOW、MEDIUM、HIGH）的 JSON schema。Amazon Bedrock Guardrails 资源会对提示词和响应中的 PHI 进行匿名化，Amazon Comprehend Medical 会在审计记录前对 PHI 进行脱敏。对于 HIGH 风险事件，Amazon SNS 会发送仅含哈希参考 ID 的无 PHI 告警。完整实现请参阅配套代码示例中的 anomaly_analyzer/handler.py。

数据敏感性分类

FHIR 资源的敏感性各不相同。心理健康 Observation 的敏感性高于常规血压读数。某些临床数据类型，例如物质滥用治疗记录，可能需要根据适用法规采取额外保护措施。请注意，敏感性分类可为访问决策提供依据，但不能替代同意管理；同意管理应依据你的组织政策实施。

你可以使用 Amazon Bedrock 对 FHIR 资源进行敏感性分级，而无需硬编码映射表。当资源在 AWS HealthLake 中创建或更新时，Amazon EventBridge 规则会触发分类函数。该函数会将资源元数据发送至 Amazon Bedrock，由其评估资源类型、临床代码和类别，随后分配以下敏感性级别之一：PUBLIC、INTERNAL、CONFIDENTIAL 或 RESTRICTED。

例如，Amazon Bedrock 会将逻辑观察标识符名称和代码（LOINC）为血糖的 Observation（2345-7）分类为 INTERNAL；它会将 HIV 检测结果代码对应的 Observation（7018-2）分类为 RESTRICTED。模型会根据代码的临床含义作出这种区分。当出现新的代码系统或资源类别时，分类无需修改代码即可适应。

Amazon DynamoDB 会将分类结果与资源 ID 一同存储。当用户请求该资源时，AWS Lambda 授权器会在授权访问前检查用户的许可级别是否与资源分类相匹配。这使你能够在标准 RBAC 之上构建一个动态、内容感知的授权层。

对于分类任务，你可以使用 Amazon Bedrock 上 Anthropic 的 Claude Haiku 4.5 基础模型（FM），以保持较低延迟和较低成本。对于准确性比速度更重要的复杂访问模式分析，则使用 Amazon Bedrock 上 Anthropic 的 Claude Sonnet 4.5 FM。对于每月处理 100,000 次 FHIR API 调用的组织，Amazon Bedrock 成本预计处于数十美元范围内，具体取决于提示词长度和模型选择。有关当前按 Token 计费的价格，请参阅 Amazon Bedrock 定价页面。你可以在 AWS Billing and Cost Management 控制台中监控用量和成本。

敏感性

If you manage Fast Healthcare Interoperability Resources (FHIR) APIs, you must balance open patient data access with strict data protection requirements. Static security rules require constant updates as clinical workflows evolve, and maintaining them manually creates compliance gaps. With Amazon Bedrock, a fully managed service that provides access to foundation models (FMs) through a single API, you can build intelligent security for your healthcare APIs. This security monitors access patterns, classifies data sensitivity automatically, and generates compliance reports in natural language. This approach can help reduce documentation effort, reduce manual rule maintenance, and adapt your security monitoring as clinical workflows change.

In this post, you learn how to add context-aware security monitoring to FHIR APIs using Amazon Bedrock. First, we explain the architecture that separates security monitoring from the FHIR API request path, so you can add behavioral analysis without affecting API latency. Then we walk through implementing anomaly detection with Amazon Bedrock and Structured Outputs, with the ability to catch access patterns that static rules miss. Next, we demonstrate automated data sensitivity classification, which removes the need for hardcoded mapping tables. Finally, we show how to generate compliance reports in natural language, reducing audit preparation time. The solution uses AWS Lambda, Amazon API Gateway, AWS HealthLake, Amazon EventBridge, Amazon Cognito, Amazon Bedrock Guardrails, and Amazon Comprehend Medical. It includes an accompanying code sample with a complete AWS CloudFormation template, five AWS Lambda functions, and deployment scripts you can adapt for your environment.

Prerequisites

To deploy this solution, you need:

• An active AWS account with administrative access.
• AWS Command Line Interface (AWS CLI) v2 installed and configured (aws configure).
• Amazon Bedrock now grants access to supported models automatically. Verify that the models are available in your AWS Region by checking the Amazon Bedrock model access page.
• A verified email address for Amazon Simple Notification Service (Amazon SNS) security alert notifications.
• If your AWS account has never used Amazon API Gateway with Amazon CloudWatch Logs integration, you must first set a CloudWatch Logs role ARN in your account’s API Gateway settings. Without this, the deployment fails with “CloudWatch Logs role ARN must be set in account settings.” See Set up CloudWatch API logging in API Gateway for instructions.
• Estimated deployment time: 10-15 minutes. Estimated monthly cost varies based on usage. See the Amazon Bedrock pricing page for current rates. AWS HealthLake charges are separate.

Overview of the architecture

You get visibility into who accesses FHIR data and whether that access looks normal. The foundation models in Amazon Bedrock evaluate each request against the user’s historical behavior, role, and the sensitivity of the requested data. The result is a risk assessment in plain English that you can act on.

Your existing authorization controls stay in place. You continue to enforce role-based access control (RBAC) and validate JSON Web Tokens (JWTs), the signed tokens that prove a user’s identity, through an AWS Lambda authorizer. On top of that, you gain behavioral analysis that catches patterns a static rule cannot. For example, a user accessing data within their permissions but at an unusual volume or time of day triggers an alert.

The following diagram shows how security monitoring runs separately from the main API path, so it doesn’t add latency to clinical workflows.

Figure 1: Architecture of an Amazon Bedrock powered FHIR API security monitoring system

Here’s how the request-then-analyze flow works. Amazon API Gateway receives incoming FHIR requests and enforces throttling and request validation. An AWS Lambda authorizer validates the JWT and checks fine-grained permissions stored in Amazon DynamoDB.

AWS HealthLake then serves the FHIR data as a HIPAA-eligible, fully managed FHIR R4 data store. The FHIR processor AWS Lambda function captures access details and routes them through Amazon EventBridge to three asynchronous AWS Lambda functions: an anomaly analyzer, a sensitivity classifier, and a compliance reporter. Each function invokes Amazon Bedrock through an Amazon Bedrock Guardrails resource that anonymizes protected health information (PHI) in both prompts and responses. The anomaly analyzer additionally uses Amazon Comprehend Medical to redact PHI before writing to audit logs. Amazon CloudWatch captures structured logs throughout this flow for audit trails.

You benefit from fully asynchronous analysis. Amazon EventBridge routes the access event to the analyzer AWS Lambda function after the FHIR response has already returned to the client. Your API latency stays unaffected while you get continuous security monitoring.

If the analyzer is temporarily unavailable, the FHIR API continues serving requests normally. The monitoring layer doesn’t block clinical workflows.

HIPAA safeguards

The solution implements multiple layers of PHI protection to prevent protected health information from leaking through the monitoring pipeline:

• Amazon Bedrock Guardrails – An AWS::Bedrock::Guardrail resource is deployed with the AWS CloudFormation template. It detects and anonymizes personally identifiable information (PII) entities (names, Social Security numbers, addresses, phone numbers, medical record numbers) in both prompts sent to Amazon Bedrock and model responses. SSNs and passport numbers are blocked entirely rather than anonymized.
• Amazon Comprehend Medical – Before writing an Amazon Bedrock response to Amazon CloudWatch Logs, the anomaly analyzer passes the text through the DetectPHI API in Amazon Comprehend Medical. Detected PHI entities are replaced with type tags (for example, [NAME], [DATE]) so that audit logs remain useful for compliance review without containing actual patient data.
• IP generalization – The anomaly analyzer prompt never sends raw IP addresses to Amazon Bedrock. Instead, it classifies the source as “internal” or “external” based on RFC 1918 ranges, preventing PII from entering the model context.
• PHI-free alerts – When the anomaly analyzer triggers an Amazon SNS alert, the notification contains only a hashed reference ID and the risk level. The security team retrieves full details from the audit log using the reference ID, which helps prevent email notifications from containing PHI.
• Structured Outputs – Amazon Bedrock calls in this solution use Structured Outputs with JSON schemas and enum-constrained fields (fields limited to a fixed set of valid values). This reduces free-text parsing and helps confirm that model responses conform to a predictable format, reducing the risk of unexpected PHI appearing in downstream processing.
• Sanitized error messages – FHIR API error responses return generic messages to the client rather than internal exception details, which could inadvertently include patient data from AWS HealthLake responses.

Anomaly detection with Amazon Bedrock

You can detect sophisticated access anomalies that rule-based systems miss by analyzing behavioral patterns across diverse clinical user populations. The analyzer AWS Lambda function is the core of this architecture. Every API call generates an access event, and the foundation model evaluates that event against the user’s role, access history, and the nature of the request.

Consider a doctor who normally accesses 5-15 patient records during business hours. If that same doctor downloads 500 records at 3 AM, a static rule would need explicit thresholds for every role and time combination. With Amazon Bedrock, you evaluate the full context and get a risk assessment with a plain-English explanation.

Clinical user populations are diverse: physicians, nurses, billing staff, researchers, and third-party integrations. Each group has different normal access patterns, and those patterns shift over time. A researcher running a retrospective study might legitimately access thousands of records in a single session. The foundation model distinguishes that from unauthorized access by examining the user’s role, the nature of the request, and whether the access followed normal authentication patterns.

The anomaly detection builds per-user behavioral baselines rather than applying population-level thresholds. This approach reduces the risk of systematically flagging legitimate access patterns from night-shift clinicians, international researchers, or on-call physicians who routinely operate outside standard business hours.

Different caller types carry different risk profiles. SMART on FHIR applications, patient portals, and Health Information Exchange (HIE) connections each have distinct expected behaviors. The access event includes the OAuth client_id, so the analyzer can maintain app-specific baselines and apply differentiated risk scoring based on the integration type.

Organizations can further enrich access events with clinical context such as on-call schedules, emergency department activation status, or care team assignments. For example, a doctor accessing 500 records at 3 AM during a mass casualty event should not trigger the same risk assessment as the same pattern on a routine night. The prompt design accommodates this additional context when available.

This implementation uses a fail-open approach. Fail-open means that if the analyzer encounters an error, it logs the failure but doesn’t block the original API request. We chose this over a fail-closed approach (which would block requests on error) because an analyzer outage shouldn’t create availability issues for clinical workflows. The FHIR API continues serving requests normally while the monitoring layer recovers.

The anomaly analyzer uses the Amazon Bedrock Converse API with Structured Outputs to enforce a JSON schema with enum-constrained risk levels (LOW, MEDIUM, HIGH). An Amazon Bedrock Guardrails resource anonymizes PHI in prompts and responses, and Amazon Comprehend Medical redacts PHI before audit logging. For HIGH-risk events, Amazon SNS sends a PHI-free alert containing only a hashed reference ID. See anomaly_analyzer/handler.py in the accompanying code sample for the complete implementation.

Data sensitivity classification

FHIR resources vary in sensitivity. A mental health Observation carries more sensitivity than a routine blood pressure reading. Certain clinical data types, such as substance abuse treatment records, might require additional safeguards based on applicable regulations. Note that sensitivity classification informs access decisions but doesn’t replace consent management, which should be implemented according to your organization’s policies.

You can classify FHIR resources by sensitivity level without hardcoded mapping tables using Amazon Bedrock. When a resource is created or updated in AWS HealthLake, an Amazon EventBridge rule triggers a classification function. That function sends the resource metadata to Amazon Bedrock, which evaluates the resource type, clinical codes, and category. It then assigns a sensitivity level: PUBLIC, INTERNAL, CONFIDENTIAL, or RESTRICTED.

For example, Amazon Bedrock classifies an Observation with a Logical Observation Identifiers Names and Codes (LOINC) code for blood glucose (2345-7) as INTERNAL. It classifies an Observation with a code for HIV test results (7018-2) as RESTRICTED. The model makes this distinction based on the clinical meaning of the codes. When new code systems or resource categories appear, the classification adapts without code changes.

Amazon DynamoDB stores the classification alongside the resource ID. When a user requests that resource, the AWS Lambda authorizer checks whether the user’s clearance level matches the resource’s classification before granting access. This gives you a dynamic, content-aware authorization layer on top of the standard RBAC.

For classification tasks, you use Anthropic’s Claude Haiku 4.5 foundation model (FM) on Amazon Bedrock, which keeps latency low and costs minimal. For the more complex access pattern analysis where accuracy matters more than speed, you use Anthropic’s Claude Sonnet 4.5 FM on Amazon Bedrock. For an organization processing 100,000 FHIR API calls per month, expect Amazon Bedrock costs in the range of tens of dollars, depending on prompt length and model selection. For current per-token pricing, see the Amazon Bedrock pricing page. You can monitor usage and costs in the AWS Billing and Cost Management console.

The sensitivity classifier uses Structured Outputs with a fixed set of valid values (PUBLIC, INTERNAL, CONFIDENTIAL, RESTRICTED) to guarantee a valid classification. If classification fails, the function defaults to CONFIDENTIAL (fail-secure). See sensitivity_classifier/handler.py in the accompanying code sample.

Compliance reporting

Healthcare audits require documentation of who accessed what data, when, and why. Security teams typically spend days aggregating logs, cross-referencing user activity, and writing narrative summaries. You can transform raw access logs into readable compliance reports automatically using Amazon Bedrock.

A scheduled AWS Lambda function runs monthly using Amazon EventBridge Scheduler. It retrieves the access logs for the reporting period and sends them to Amazon Bedrock with instructions to generate a compliance summary. The output includes total request counts by resource type, unique user activity broken down by role, flagged access events and their resolutions, and recommendations for improving security posture.

The prompt instructs the foundation model to organize the report by security control category (administrative, physical, and technical). This structure helps security teams review findings systematically. Each flagged event includes the original risk assessment, the resolution status, and a timeline of actions taken.

This approach automates the manual steps of log aggregation, cross-referencing, and narrative writing, reducing the time compliance teams spend on each report.

The compliance reporter uses Structured Outputs with a schema that maps each section to a security control category. Reports are saved to Amazon Simple Storage Service (Amazon S3) with AWS Key Management Service (AWS KMS) encryption and archived to Amazon S3 Glacier after one year. See compliance_reporter/handler.py in the accompanying code sample.

Cleaning up

To avoid ongoing charges, delete the resources created by this solution when you are finished testing. Run the cleanup script from the accompanying code sample: ./src/scripts/cleanup.sh dev us-east-1. This removes the AWS CloudFormation-managed resources including the API Gateway REST API, all five AWS Lambda functions, both Amazon DynamoDB tables, the Amazon EventBridge event bus and rules, the Amazon Cognito user pool, the Amazon SNS topic, the Amazon S3 compliance reports bucket, and the Amazon CloudWatch log groups. If you created an AWS HealthLake datastore separately for end-to-end testing, delete it manually. AWS HealthLake charges approximately $0.694 per hour (~$500/month) while active.

Conclusion

You now have a proof-of-concept security monitoring pattern that adapts to your environment as access patterns change. In this post, you learned how to detect anomalous access patterns, classify data sensitivity levels automatically, and generate security audit reports in natural language using Amazon Bedrock foundation models.

If you’re evaluating this approach, start by reviewing the architecture diagram and code sample in this post. Explore the Amazon Bedrock User Guide to understand foundation model capabilities, and review the AWS HealthLake User Guide to assess how FHIR R4 data management fits your environment.

If you’re ready to deploy, follow these steps:

• Run aws configure to set your AWS credentials and target AWS Region (for example, us-east-1). Verify that Anthropic’s Claude Sonnet 4.5 and Anthropic’s Claude Haiku 4.5 are available in your target Region.
• Run the deployment script: ./src/scripts/deploy.sh your-email@example.com dev us-east-1. This packages the Lambda code, uploads it to Amazon S3, and deploys the AWS CloudFormation stack with the required infrastructure (Amazon API Gateway, AWS Lambda functions, Amazon DynamoDB tables, Amazon EventBridge rules, Amazon Cognito, Amazon SNS, Amazon S3, and the Amazon Bedrock Guardrails resource). Check your email and confirm the Amazon SNS subscription.
• Customize the prompts in the anomaly analyzer and sensitivity classifier AWS Lambda functions to match the organization’s risk tolerance, clinical roles, and data sensitivity definitions.
• (Optional) Create an AWS HealthLake datastore for end-to-end testing. Note that AWS HealthLake charges approximately $0.694 per hour, so create it only when actively testing and delete it promptly. Then send test events through Amazon EventBridge and verify the end-to-end flow by checking Amazon CloudWatch Logs for each Lambda function.

After deployment, test the anomaly detection by sending FHIR API requests with varying patterns:

• Simulate an unusual access pattern by requesting a high volume of records outside normal hours. Send a GET request to your API Gateway endpoint for 500 Patient resources using a valid JWT token. The anomaly analyzer should flag this as MEDIUM or HIGH risk.
• Simulate a normal access pattern by requesting a small number of records during business hours. The analyzer should assign a LOW risk level.
• Simulate a cross-role access attempt where a billing user requests clinical data such as laboratory Observations. This tests whether the model identifies role-resource mismatches.

After each test, check the Amazon CloudWatch Logs for the anomaly analyzer Lambda function and verify that Amazon SNS delivered alerts for HIGH-risk events. The README in the accompanying code sample includes the specific API endpoints and curl commands for each test scenario.

If you already run FHIR APIs in production, you can integrate this monitoring layer alongside existing Amazon API Gateway and AWS Lambda authorizers without modifying the request path. Add the asynchronous Amazon EventBridge-to-Bedrock flow as a parallel monitoring channel and tune the prompts to reflect the organization’s specific role definitions and risk profiles.

To extend the solution further, consider integrating the Amazon SNS alerts with existing security information and event management (SIEM) tools for centralized monitoring. You can also add prompt templates for common healthcare scenarios such as research data access reviews, emergency break-the-glass overrides, and bulk data export risk assessments. You can also tune the prompts to reflect organization-specific risk profiles, or scale the architecture for high-volume environments by adjusting the AWS Lambda concurrency settings and Amazon DynamoDB throughput.

For deeper guidance, see the Amazon Bedrock User Guide, the AWS HealthLake User Guide, the Amazon API Gateway Developer Guide, and the Amazon CloudWatch User Guide.

Share your experiences and questions in the comments. Contact an AWS Representative to discuss your healthcare security implementation.

Further reading

---

About the authors

Durgesh Nath

Durgesh is a Senior Technical Account Manager at AWS and an AWS Golden Jacket recipient – one of the highest honors in the AWS partner and technical community. With over 19 years of experience building and scaling technology across diverse domains, he works across cloud strategy, security, and Generative AI. With deep expertise in cloud security and a growing focus on AI-driven innovation, Durgesh brings both the technical depth and strategic perspective that enterprise customers rely on to accelerate their AWS journey.

Derrick Swamy

Derrick is a Senior Solutions Architect at AWS, supporting Healthcare segment customers with a focus on Security and Generative AI services. With a background spanning both Professional Services and Solutions Architecture, Derrick brings deep technical expertise and a passion for solving complex problems at the intersection of cloud, security, and AI. He actively supports the Security community and is at the forefront of exploring new frontiers with generative AI technology.