Hi Thomas Wood,
Welcome to Microsoft Q&A,
Today, I would not treat PDF file inputs containing PHI as HIPAA-covered in Azure OpenAI.
For HIPAA workloads, the conservative and documented pattern is still:
"Extract the text from the PDF in a HIPAA-eligible service, then send only text to Azure OpenAI under your BAA."
In the new Responses API, PDF support is implemented via models that have vision capabilities. The official docs say:
“Models with vision capabilities support PDF input… To help models interpret PDF content, both the extracted text and an image of each page are included in the model’s context… Only models that support both text and image inputs can accept PDF files as input.”
So even though you pass a “PDF file”, under the hood it’s text + rendered page images, which falls into the vision path, not just the classic text-only path.
Text inputs under a BAA → HIPAA-eligible
Image/vision / audio-streaming modalities → not explicitly in HIPAA scope yet
Since PDFs via the Responses API are processed as text + page images, they currently look much closer to the “image/vision PHI” scenario than the plain text scenario.
When you upload the PDF via the Files API:
- The file is stored, processed, and then referenced by ID in the Responses call.
- Deleting the file afterwards is good security hygiene, but:
- It does not change whether that feature is formally in HIPAA scope.
- It does not guarantee that all derived artifacts (logs, abuse-monitoring traces, derived images) are instantly wiped.
HIPAA eligibility is tied to whether the service + feature is in the in-scope list under Microsoft’s BAA, not only to your deletion behavior.
Please upvote and accept the answer if it helps!!