Architecture documentMermaid source and SVG
Member Eligibility architecture views
Four architecture views of the Member Eligibility reference implementation — system context, container architecture, request sequence, and validated deployment — each with a full written alternative and Mermaid source.
- Architecture
- Systems integration
These four views document the architecture of the Member Eligibility reference implementation at different levels of detail. Each is maintained as Mermaid source, rendered to SVG at build time, and accompanied by a complete written alternative.
The four views
- System context — the Provider Relations user, the Salesforce application, the FastAPI eligibility service, and the synthetic data boundary.
- Container architecture — the deployable and logical containers on each side of the contract boundary and their responsibilities.
- Request sequence — the successful runtime path plus member-not-found and technical-failure branches, showing that the backend owns every eligibility decision.
- Validated deployment — the boundaries that were actually exercised in Version 1: Salesforce Cloud, HTTPS, and a local developer-machine backend. Invented production infrastructure is deliberately excluded.
How to use them
The views model a widely applicable integration shape: a thin enterprise client delegating a business decision to one authoritative service behind a contract. Reuse the decomposition, the labeling conventions, or the deliberate honesty of the deployment view — it documents what ran, not what a production system would look like.
Limitations
These are website adaptations of the source repository's architecture documentation, simplified for publication. They must not be extended with gateways, databases, cloud hosting, authentication, monitoring, or AI runtime components that Version 1 did not include.
Provenance
Source views live in the implementation repository, reviewed at commit 4ca20305 on 2026-08-08.
The views
This view shows the Provider Relations user, the Salesforce application, the Member Eligibility Service, and the synthetic data boundary.
Text alternative
A healthcare provider asks a Provider Relations representative to verify current eligibility. The representative enters a Member ID in the Salesforce Provider Relations application. Salesforce calls the FastAPI Member Eligibility Service through the contract-defined endpoint. The service reads synthetic member and coverage JSON, makes the eligibility decision, and returns the result to Salesforce. The representative communicates the result to the provider.
Boundary
Salesforce provides the user experience but does not determine eligibility. The FastAPI service owns the business decision. Workflow Insurance and all records shown are fictional.
This view shows the Salesforce, FastAPI, contract, and data containers and makes the business-rule boundary explicit.
Text alternative
The representative uses a Salesforce Lightning Web Component. The component calls an Apex controller, which delegates to an Apex integration service and Named Credential. That path calls the FastAPI eligibility endpoint. The FastAPI route delegates to the Eligibility Service, which owns all coverage-window rules and reads synthetic member and coverage data through separate repositories. The OpenAPI contract defines both sides of the integration. The returned outcome is displayed by Salesforce without re-evaluating it.
Key Decision
No eligibility business rule is duplicated in Salesforce. Replacing the JSON data source should affect repository implementation, not the Salesforce client or eligibility rules.
This view shows what happens after a representative submits a Member ID, including supported business and technical outcomes.
Text alternative
The Lightning Web Component validates the Member ID and calls the Apex controller. The controller delegates to the Apex integration service, which sends the contract request through a Named Credential to FastAPI. The Eligibility Service looks up the member. An unknown member returns a structured 404 that Salesforce displays as Member Not Found. For a known member, the service retrieves coverage, applies eligibility rules, and returns Eligible, Ineligible, or Unable to Determine. Invalid requests and technical failures are translated into user-safe errors.
Decision Point
The only eligibility decision occurs inside the FastAPI Eligibility Service. Salesforce transports the request and renders the returned result.
This view represents the environment used for the documented live validation. It is not a target production architecture.
Text alternative
The Provider Relations application, Lightning Web Component, Apex code, and Named Credential run in Salesforce Cloud. For the documented live validation, the Named Credential sent an HTTPS request through a temporary Cloudflare Tunnel to a FastAPI process on a developer machine. That local process ran the eligibility service, repositories, synthetic JSON data, and Swagger UI. The response returned through the same path and was displayed in Salesforce.
Explicit Exclusions
Version 1 has no persistent cloud backend, database, API gateway, load balancer, container platform, production authentication, centralized monitoring, or infrastructure as code. The temporary tunnel is validation scaffolding and must not appear as a production recommendation.
- Usage
- Published for reference use; see the source repository for license terms.