Building AI for Healthcare on AWS: Lessons from Satiswork
Lessons from building a production AI assistant with Amazon Bedrock, retrieval-augmented generation (RAG), PostgreSQL, and Amazon S3.
Introduction
Building an AI application for healthcare is different from building a general-purpose chatbot.
Healthcare professionals need more than fluent responses. They need information that is relevant to their work, answers that are grounded in appropriate context, and an application that respects the boundaries between different users and their data.
These requirements have shaped my work on Satiswork, an AI-powered practice management platform for healthcare professionals in Italy.
As Co-Founder and CTO, I've been working on bringing AI capabilities into a platform designed to support healthcare workflows. The application runs on Amazon EC2, uses Amazon Bedrock for AI capabilities, and combines retrieval-augmented generation (RAG) with PostgreSQL, Amazon S3, and application-level access controls.
In this article, I'll share the architectural choices behind this implementation, the engineering principles that matter when introducing AI into a healthcare application, and the challenges that remain as we continue developing the platform.
The goal isn't to present AI as a replacement for professional judgment. It's to explore how we can build AI-assisted workflows that are useful, context-aware, and designed with appropriate safeguards.
1. The architecture: Connecting AI with application data
At a high level, Satiswork brings together an application backend, persistent data storage, document storage, and an AI layer.
The core components currently used include:
- Amazon EC2: Hosts the application.
- Amazon Bedrock: Provides the AI model capabilities used by the application.
- PostgreSQL: Stores application data.
- Amazon S3: Provides object storage for application documents.
- Retrieval-augmented generation (RAG): Connects the AI response process with relevant retrieved context.
- Application-level access controls: Help enforce which information users are permitted to access.
The important architectural decision is that the AI model is only one component of a larger application. It operates within a system that already has application data, permissions, and business logic.
A simplified request flow
A typical AI-assisted workflow can be understood in the following conceptual stages:
- User request: A healthcare professional submits a request through the application.
- Application authorization: The application applies its access controls to determine what the user is allowed to access.
- Context retrieval: The RAG workflow retrieves relevant information for the task.
- AI generation: Amazon Bedrock is used to generate a response using the available context.
- Response delivery: The application returns the generated result to the user.
This describes the intended logical flow of the AI-assisted workflow, rather than a complete deployment diagram of every internal service or data-processing step.
The distinction matters because a language model should not become an alternative authorization layer. Access decisions need to be enforced by the application, not left to the model's interpretation of a prompt.
2. Why Amazon Bedrock?
Using Amazon Bedrock allows an application to integrate foundation models through an AWS-managed service rather than managing the underlying model-serving infrastructure directly.
For Satiswork, Bedrock provides the AI model capabilities used by the production application.
However, integrating a model API is only the starting point. The engineering challenge is deciding what information should be supplied to the model, how that information is retrieved, and how the resulting response is handled.
A model can produce a convincing answer that is incomplete or incorrect. In healthcare-related workflows, a convincing but unsupported answer is not good enough.
This is why I see the surrounding application architecture as just as important as the model itself.
The application must determine what context is appropriate, keep access controls outside the model, and provide a foundation for evaluating the quality of generated responses.
3. RAG: Giving the model relevant context
Retrieval-augmented generation combines information retrieval with language-model generation.
Instead of relying exclusively on what a model learned during training, a RAG workflow retrieves relevant information and makes that information available when generating a response.
At a conceptual level, the process is:
- Identify the information relevant to the user's request.
- Retrieve suitable context from the available information sources.
- Supply that context to the model.
- Generate a response based on the request and retrieved information.
Satiswork uses RAG in production as part of its AI capabilities.
This approach is useful because healthcare workflows can depend on information that is specific to a task, a professional context, or the data available within an application.
However, RAG is not a guarantee of correctness.
If retrieval returns irrelevant information, omits an important source, or provides outdated material, the model may still generate an unreliable response. Retrieval quality and response quality therefore need to be considered together.
It is also important to distinguish retrieval from authorization. A document being relevant to a question does not automatically mean that the user should be allowed to see it.
A production implementation needs to ensure that retrieval respects the application's access rules before information is passed to the model.
4. Data storage and access control
Satiswork uses PostgreSQL for application data and Amazon S3 for object storage.
These components serve different purposes within the application. PostgreSQL provides relational data storage, while S3 provides storage for objects such as documents.
Their presence alone does not establish that a system is secure. Security depends on how the components are configured and how the application controls access to them.
Application-level authorization
One important principle in an AI-enabled application is to preserve the same authorization boundaries that apply to ordinary application features.
For example, if a user cannot access a particular record through the application, an AI-assisted feature should not indirectly expose that record through retrieval or generated output.
This means considering access control throughout the request lifecycle, including:
- Which records and documents may be retrieved.
- Which information may be included in the model's context.
- Which generated results may be returned to a user.
- Whether sensitive information is unnecessarily retained in logs or other operational systems.
These are design and verification concerns, not properties that can be assumed simply because an application uses AWS services.
For healthcare applications, privacy and security also require attention to identity management, encryption, infrastructure configuration, data retention, monitoring, and applicable legal obligations.
The implementation described here uses application-level access controls. Specific encryption configurations, formal security assessments, and regulatory certifications should be documented separately rather than inferred from the technology stack.
5. Engineering lessons from production AI
Lesson 1: Treat the model as one component, not the whole application
An AI feature depends on much more than a prompt and a model API.
The surrounding application must handle authorization, data retrieval, errors, user experience, and the delivery of results. These responsibilities remain even when the model itself is managed by a cloud provider.
Keeping these concerns separate makes the system easier to reason about and creates clearer places to enforce safeguards.
Lesson 2: Context quality matters as much as generation
RAG can make model responses more relevant to a particular task, but its effectiveness depends on the quality of the retrieved information.
Retrieval should be evaluated independently from generation. Otherwise, it becomes difficult to distinguish a retrieval failure from a model-generation failure.
A useful next step is to build a representative evaluation dataset and measure whether the retrieval process returns the information needed to answer each query.
Lesson 3: Enforce permissions before sharing context with the model
A language model should not be responsible for deciding whether a user is authorized to access a record.
The application needs to establish the permitted context before invoking the model. Generated responses should also be considered when evaluating whether sensitive information could be exposed.
This principle is especially important when AI features are integrated into applications containing information associated with different users or healthcare practices.
Lesson 4: Production readiness requires more than a successful demonstration
A feature that works during a demonstration may still fail under real-world conditions.
Production AI systems need to account for missing context, retrieval failures, model errors, unexpected outputs, latency, and operating costs.
They also need ways to evaluate output quality over time. For healthcare-related use cases, the evaluation process should reflect the consequences of incorrect or unsupported responses rather than focusing only on whether an answer sounds natural.
Lesson 5: Cloud-managed AI does not remove application responsibility
Amazon Bedrock provides managed access to foundation models, but it does not automatically guarantee that an application is accurate, secure, or compliant.
Those outcomes depend on the complete implementation, including the application, data handling, model integration, monitoring, and operational processes.
The same principle applies to the other AWS services in the architecture: managed infrastructure can reduce operational burden, but it does not eliminate the need for sound engineering decisions.
6. Limitations and challenges
There are several important limitations to acknowledge when building AI-assisted healthcare workflows.
Hallucinations and unsupported answers. RAG can provide relevant context, but it cannot guarantee that every generated statement is correct. Responses need appropriate evaluation, and sensitive clinical decisions should remain subject to qualified professional judgment.
Incomplete retrieval. The system may fail to retrieve relevant information or may retrieve material that does not adequately support the response. Retrieval quality needs its own testing and monitoring.
Data privacy and authorization. Application-level access controls are an important part of the design, but they are not a complete security or compliance assessment. The entire data flow needs to be reviewed.
Cost and latency. Model usage, context size, retrieval operations, and application infrastructure all contribute to the overall cost and responsiveness of an AI feature. These trade-offs need to be measured against actual workloads.
Evaluation in real-world conditions. Testing a limited set of prompts is not sufficient to establish reliability across different tasks, users, and edge cases. Evaluation needs to become an ongoing engineering activity.
These are not problems that can be solved simply by selecting a more capable model. They require attention to the entire system.
7. What's next?
The current implementation provides a foundation for continued development. Several areas deserve further exploration.
Better evaluation and observability
A useful next step is to establish a structured evaluation process for retrieval quality, factual grounding, and response reliability.
This could include representative test cases, checks for unsupported claims, and monitoring of failure patterns. The aim would be to identify regressions as prompts, retrieval logic, or model configurations change.
Cost and latency optimization
As usage grows, measuring the cost and latency of individual AI workflows will become increasingly important.
Potential areas to investigate include context-size optimization, model selection, caching where appropriate, and reducing unnecessary model calls. Any optimization should be evaluated against response quality rather than cost alone.
Stronger privacy and security verification
Future work should continue examining authorization across retrieval and generation, data retention, logging, and the handling of sensitive information.
Security and regulatory requirements need to be assessed against the actual deployment and applicable obligations, not assumed from the use of particular cloud services.
More complex AI-assisted workflows
As the platform evolves, there is room to explore more complex workflows that combine retrieval, generation, and application operations.
Such workflows would require careful boundaries around which actions the system may perform, which actions require explicit user confirmation, and which decisions must remain under professional control.
These are areas for further development, not claims that autonomous clinical workflows are already deployed.
Conclusion
Building AI for healthcare is not simply a matter of connecting a language model to an application.
It requires integrating model capabilities with relevant information, application-level authorization, reliable data handling, and an engineering process that recognizes the limitations of generated output.
Satiswork currently uses Amazon EC2, Amazon Bedrock, PostgreSQL, Amazon S3, and production RAG capabilities as part of its AI-enabled platform. This provides a practical foundation for exploring how AI can support healthcare professionals while preserving the application controls around it.
The broader lesson is that responsible AI engineering depends on the complete system—not only the model.
For developers building AI applications on AWS, I believe the most valuable work lies in making these systems measurable, maintainable, and appropriately constrained as they move from experimentation into production.
I'm continuing to explore these challenges through Satiswork and look forward to sharing more technical lessons with the AWS community.
About the author
Gedion Daniel is a second-year AWS Community Builder and Co-Founder & CTO of Satiswork, an AI-powered practice management platform for healthcare professionals in Italy. His interests include cloud architecture, AI-enabled applications, and building practical software systems for real-world workflows.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article