待翻译：Build intelligent security for healthcare APIs with Amazon Bedrock

AI 服务暂时不可用，以下为来源正文，待恢复后补全翻译。

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, c [truncated for AI cost control]