The question isn’t whether OpenAI’s models are capable enough for healthcare data work. They are. The question is how to use them responsibly in an environment where a compliance error has serious consequences — for patients, for your organisation, and potentially for your career.
After evaluating and deploying GPT-4 in limited capacities within health data workflows, here are the lessons I’d pass on to any data engineer considering the same.
First: The Compliance Question
Before any technical evaluation, answer this: can your data touch OpenAI’s API at all?
For Canadian government health data — which is what I work with at CIHI — the answer is generally no. PIPEDA, provincial health information acts, and data sharing agreements with health authorities typically prohibit sending identifiable or potentially re-identifiable data to third-party cloud services outside Canada. OpenAI’s infrastructure is US-based.
This doesn’t make OpenAI useless for healthcare data work. It means you need to be precise about what goes through the API.
What is safe to send:
- Anonymised, aggregated statistics
- Code, schemas, and documentation (no actual data)
- Synthetic data generated for testing
- Plain text descriptions of data structures
What is not safe to send:
- Any record-level health data
- Data that could be re-identified even if “de-identified”
- Data covered by specific data sharing agreements
If you’re in financial services, similar restrictions often apply under OSFI guidelines and data residency requirements.
The Use Cases That Work
Code Generation for ETL Logic
This is where GPT-4 consistently delivers. I describe the transformation I need in plain English — “take this DataFrame with diagnosis codes and patient IDs, join it with the procedure lookup table, calculate the total procedure count per patient per fiscal year, and output a summary grouped by province” — and GPT-4 produces working PySpark code that I review, test, and refine.
The key discipline: I describe the schema and logic using column names and structure only. No actual data values.
Test Data Generation
GPT-4 is excellent at generating realistic synthetic datasets that conform to a schema. For healthcare, this means generating fake-but-realistic patient records that look like real data but have no connection to actual individuals. This is enormously valuable for:
- Unit testing pipelines without touching production data
- Demonstrating pipelines to stakeholders
- Performance testing without data access complexity
Error Message Analysis
Production PySpark jobs produce cryptic error messages, especially with complex DAG failures. Pasting the stack trace into GPT-4 and asking “what is likely causing this and how do I fix it” almost always produces a useful starting point.
What Requires Careful Design
RAG on Health Documentation
There’s a legitimate use case for building a retrieval-augmented system over healthcare documentation — coding manuals, ICD-10 guides, CIHI data dictionaries — to help analysts query standards quickly. This is valuable and doesn’t require any patient data to flow through the API.
The design requirements are strict: the knowledge base must contain only public or appropriately licensed documentation, all queries must be logged for audit, and the system must make clear it’s an AI assistant, not authoritative clinical guidance.
Automated Report Drafting
GPT-4 can draft plain-language summaries of statistical results, which is genuinely useful for producing accessible reports for non-technical government clients. You pass in aggregate numbers (no individual records) and get back readable prose.
The safeguard required: all AI-drafted content must be reviewed and approved by a human before it leaves the organisation. This is non-negotiable in any regulated context.
The Architecture Principle
The architecture principle that makes OpenAI safe to use in healthcare contexts is simple: the model should never see a record about a real person.
All the valuable use cases — code generation, synthetic data, documentation, error analysis, report drafting — work entirely with schemas, code, aggregates, and synthetic data. The actual patient records stay in your secure environment.
Design your workflows with that constraint as a hard requirement, not a guideline, and GPT-4 becomes a genuinely powerful tool for health data engineering.
My Current Stack
For reference, here’s how I actually use AI tools in my data engineering work:
- Claude: Primary tool for code review, compliance documentation, and complex explanation tasks
- GPT-4: Primary tool for code generation, test data creation, and error analysis
- Local LLMs (Ollama + Mistral): For any task where data context is needed — running entirely within the secure environment
That last point is important. Local LLMs eliminate the compliance concern entirely and are more capable than they were 18 months ago. For a healthcare organisation serious about AI-assisted development, a local deployment is worth the infrastructure investment.