HIPAA Healthcare Backend Developer Needed for Secure OpenAI API Integration

I am an emergency physician who has built a functioning clinical documentation web application called ED Scribe. The front end is already built and working well. This is not a request to redesign or rebuild the application. I am looking for an experienced healthcare/cloud security developer to build and deploy a small, secure backend that will allow ED Scribe to send clinical text to the OpenAI API in an architecture suitable for HIPAA-regulated use. I am specifically looking for someone with real experience deploying healthcare applications involving PHI, BAAs, HIPAA-eligible cloud infrastructure, secure API design, and OpenAI or similar LLM APIs. Please do not apply if your experience is primarily general web development without healthcare/HIPAA infrastructure experience. Current Architecture ED Scribe is a React/TypeScript application built using Lovable. Patient encounter working data currently stays in: React state browser localStorage There is intentionally no cloud patient database. Account/authentication/subscription information may exist in the application's backend, but patient encounters should remain completely separate from account data. Currently, two AI functions transmit clinical text: Generate ED Note Generate disposition documentation, including discharge instructions/admission handoff Those calls currently follow approximately: Browser → Supabase/Lovable Edge Function → Lovable AI Gateway → Google Gemini I want this clinical-data pathway removed. Desired Architecture The final clinical data pathway should be: ED Scribe browser ↓ Secure backend API controlled by me ↓ OpenAI API using my organization's BAA-covered API account ↓ Secure backend ↓ ED Scribe browser Generated clinical documentation should return to the browser and continue to be stored locally. Important design goal I do not want to create a cloud repository of patient encounters. The backend should function primarily as a secure, stateless processing layer. One request comes in, one OpenAI request is made, the generated documentation is returned, and the clinical request/response is not intentionally persisted by our infrastructure.Scope of Work 1. Recommend and configure HIPAA-capable hosting Recommend an appropriate platform such as AWS, Azure, or Google Cloud. The hosting environment must: support HIPAA workloads allow execution of an appropriate BAA use appropriate encryption securely manage secrets support access controls/IAM allow PHI-safe logging configuration provide HTTPS/TLS be maintainable by a small SaaS business Please explain your recommendation before deployment. I am looking for a relatively simple architecture, not unnecessary enterprise complexity. 2. Build the ED Scribe API Create a secure endpoint similar to: POST /api/generate-ed-note It should accept: generation type clinical summary random request identifier Supported generation types will initially include: ED note generation discharge instructions admission handoff The endpoint should validate inputs and reject unsupported request types. 3. Integrate OpenAI server-side OpenAI API calls must occur only from the backend. The OpenAI API key must never appear in: browser code React frontend client-side environment variables localStorage Git repository browser network responses Use server-side secret management. The OpenAI model should be configurable without changing application code. I intend to use an OpenAI organization/project covered by an executed BAA and appropriately provisioned for HIPAA-eligible API use. The backend should use an appropriate HIPAA-eligible OpenAI API endpoint/configuration. Where appropriate, requests should use: store: false The clinical workflow should be stateless. Do not use persistent conversations, threads, vector stores, files, web search, MCP, or other unnecessary services for patient encounters. 4. Prevent PHI logging This is a critical requirement. Clinical request and response contents should not appear in ordinary application logs. Do not log: patient summaries generated notes HPI MDM diagnoses discharge instructions admission handoffs names MRNs DOBs clinical narratives request bodies response bodies Operational logging may include appropriate metadata such as: timestamp random request ID response status latency model token usage generic/sanitized error category Raw provider errors should not be logged if they could echo PHI. Cloud-provider request/body logging must also be reviewed and configured appropriately. 5. Authentication and authorization The backend must not simply expose a public OpenAI proxy. Implement secure authentication so only authorized ED Scribe users can make generation requests. ED Scribe already has user registration/login and subscription functionality. The developer should integrate the secure backend with the existing authentication system where practical. The backend should be able to verify: authenticated user authorization to use ED Scribe Do not use patient information as part of authentication. Do not rely on CORS alone for security. 6. Standard API protections Implement appropriate: HTTPS/TLS authentication authorization input validation payload-size limits rate limiting CORS restrictions secure secret storage sanitized error messages server-side security controls dependency/security configuration Production errors must not expose stack traces or secrets. 7. Preserve the existing application This project should make minimal changes to the working ED Scribe front end. Do not redesign: user interface clinical workflow patient navigation note structure procedure workflow EKG workflow disposition workflow payment page registration system The current clinical prompts are important and should initially be transferred to the new OpenAI pathway as faithfully as possible. This project is primarily a transport/security/backend migration, not a clinical prompt redesign. 8. Remove the existing clinical AI pathway After the new backend is functioning, clinical text should no longer pass through: Lovable AI Lovable AI Gateway Google Gemini the existing Supabase/Lovable generate-ed-note Edge Function unapproved analytics or telemetry services There should be no fallback to the old AI pathway. If the approved backend is unavailable, ED Scribe should fail closed and keep the clinical information local. 9. Preserve local-first patient data architecture Do not move patient encounters into a cloud database. Patient working data should continue to remain in the browser unless transmission to OpenAI is necessary for the requested generation operation. Do not create: cloud patient histories saved encounter databases cloud note backups synchronized patient lists Account/subscription information and patient encounter information should remain separate data domains. Security / Data Flow Audit Required At completion, I want a written technical report answering: Exactly what clinical information leaves the browser? Which hostname/service receives it? Does any clinical text reach Lovable? Does any clinical text reach Supabase infrastructure? Does any clinical text reach Google/Gemini? Does any clinical text appear in application logs? Could clinical text appear in cloud-provider logs? Does any analytics/telemetry platform receive clinical data? Where is the OpenAI API key stored? Can the browser ever access the OpenAI API key? Is any clinical request/response intentionally stored server-side? What OpenAI endpoint/features are being used? How is the backend authenticated? How is authorization enforced? How are secrets managed? What services involved in processing/transmitting PHI require BAAs? Are there any remaining HIPAA/security issues you believe should be addressed before production use? I also want an architecture diagram of the final data flow. Deliverables At completion I should receive: deployed secure backend working ED Scribe → backend → OpenAI integration backend source code infrastructure/configuration documentation deployment instructions list of cloud services being used list of required BAAs/service agreements explanation of secret management authentication documentation logging configuration security/data-flow audit architecture diagram basic operational instructions instructions for rotating the OpenAI API key instructions for updating the OpenAI model estimated ongoing monthly infrastructure cost The infrastructure and accounts should ultimately be owned and controlled by me/my company, not permanently hosted inside the developer's personal accounts. Required Experience Strong preference will be given to applicants with demonstrated experience in several of the following: HIPAA-regulated healthcare software PHI handling Business Associate Agreements AWS/Azure/Google Cloud HIPAA architecture OpenAI API healthcare AI/LLM applications React/TypeScript API authentication IAM secure secret management secure logging SaaS security Stripe/Supabase familiarity healthcare cybersecurity HIPAA experience is much more important to me than fancy UI development. Important I am not asking a developer to certify that ED Scribe is legally "HIPAA compliant." I understand that compliance also involves contracts, policies, BAAs, organizational safeguards, risk assessments, and legal review. I am hiring you to build and document the technical architecture necessary to support HIPAA-regulated use and to identify remaining technical compliance issues. Screening Questions Please answer all of these when applying: Tell me about a healthcare application you have personally built or deployed that handled PHI. What was your role? Which cloud provider would you recommend for this project and why? Have you configured AWS, Azure, or Google Cloud specifically for HIPAA workloads and worked with BAAs? Have you integrated the OpenAI API or another major LLM into a healthcare application handling PHI? How would you prevent clinical request/response bodies from appearing in application or cloud-provider logs? How would you authenticate requests from the ED Scribe React application without exposing backend secrets? Would you maintain the existing localStorage patient architecture or recommend changing it? Why? Please briefly describe the architecture you would propose for this project. What would you expect the approximate ongoing infrastructure cost to be for a small initial user base? What do you estimate for project cost and completion time? Please begin your proposal with the words ED SCRIBE so I know you read the entire posting.