BFF Layer

What it does

DrugIntentBFF is the backend-for-frontend service sitting between RxDrugIntent-Surface (UI) and RxDrugIntent-MP-Core (core API). Per the project's architecture overview, it is the UI Orchestrator: it backs the MP UI, aggregates responses from downstream services into UI-friendly shapes, and performs validation before data reaches the browser — so the UI never has to fan out to multiple backend services itself.

Where it sits in the microservice layer

The BFF is one of five microservices described in the CLIC architecture. The others it works alongside:

Service	Role
Drug Intent BFF (this service)	Backs the MP UI; aggregates responses in UI-friendly shapes; performs validation
Core Service	Orchestrates overall workflow; coordinates calls to other services
Formulary Service	Fetches formulary data from FSOT
Maintenance/Timer Service	Handles cleanup — draft state expiry, cache expiry
Downstream Push Services	Encapsulates integration with RxClaim CAT API and Taskmaster

It is not yet confirmed in collected sources whether these are separate deployables/repos or logical modules inside RxDrugIntent-MP-Core — only DrugIntentBFF and RxDrugIntent-MP-Core exist as distinct repos in the current 6-repo inventory.

How it works

No endpoint list or request/response contract is available from the collected README itself — that gap remains. However, the low-level design document describes a UI-facing REST API that matches the BFF's role as the service the Surface app talks to directly:

• Base path: /api/v1/drug-intent, versioned with a /v1 prefix (backward-compatible changes only)

Method	Path	Purpose
GET	/api/v1/drug-intent/{id}	Fetch single drug intent
GET	/api/v1/drug-intents	List with pagination (clientId, status, page, size, sort)
POST	/api/v1/drug-intent	Create new drug intent (emits audit event)
PUT	/api/v1/drug-intent/{id}	Full update with optimistic locking
PATCH	/api/v1/drug-intent/{id}/status	Status transition (ACTIVE/INACTIVE/SUBMITTED)
DELETE	/api/v1/drug-intent/{id}	Soft delete (flag + audit trace)
POST	/api/v1/drug-intent/{id}/formf	Append FormF edit record

Note: the LLD documents this API at the "PBR Drug Intent Micro Product" level, not against a specific repo — it is inferred (not confirmed) that this is the BFF's exposed surface given its UI Orchestrator role, since RxDrugIntent-MP-Core's own README gives no endpoint detail to compare against.

Security & auth

• Auth: AuthPass-issued JWT bearer tokens (RFC 6750), 15-minute TTL with refresh flow
• Authorization: owner-only modification; admin scope is read-only via a separate admin API
• Input validation: strict server-side schema validation; unknown fields rejected
• Rate limiting: 100 requests/min per IP
• Security headers: CSP (no inline scripts), HSTS, X-Content-Type-Options, Referrer-Policy

Non-functional targets

Requirement	Target
API latency	P95 < 150ms
Availability	99.9% monthly

Observability

• Structured JSON logs (level, userId, requestId, endpoint, latency, outcome — PII redacted)
• Metrics: API latency (p50/p95/p99), error rate
• Distributed tracing via OpenTelemetry/Splunk across frontend fetch → backend routes → DB calls

Known gaps / open questions

• The README still contains only a repo title and one-line description — the endpoint/security/NFR detail above comes from the product-level LLD and project document, not from the BFF repo itself, and has not been confirmed against actual BFF code or an OpenAPI spec.
• Whether the BFF calls RxDrugIntent-MP-Core for every request or short-circuits some reads (e.g., cached formulary lookups) is not documented.
• No sequence diagrams exist yet for multi-step flows (e.g., Form F submission → BFF → Core → DOSE handoff).

Technical reference

Detail	Value
Repo	DrugIntentBFF
Build	Maven (pom.xml)
Calls	RxDrugIntent-MP-Core, Formulary Service (FSOT)
Called by	RxDrugIntent-Surface
Base path	/api/v1/drug-intent (inferred — see note above)
Auth	AuthPass JWT bearer, 15-min TTL + refresh
Rate limit	100 req/min per IP