| name | health-tech-developer |
| description | Guide for developers building healthcare technology covering HIPAA compliance, HL7 and FHIR interoperability standards, EHR integration, patient data security, regulatory considerations, and navigating the unique technical challenges of healthcare software.
Use when the user asks about health tech developer, related techniques, best practices, or needs guidance in this domain.
Do NOT use when the request is outside the scope of health tech developer or requires a different specialized skill.
|
| license | Apache-2.0 |
| metadata | {"author":"foundry-skills","version":"1.0.0","tags":"healthcare best-practices budgeting api-design cloud testing automation analysis","category":"software-engineering","subcategory":"developer-tools","depends":"","disclaimer":"none","difficulty":"advanced"} |
DISCLAIMER: This skill provides general educational information about healthcare technology development. It is not a substitute for professional medical, legal, or regulatory advice. Consult qualified professionals for HIPAA compliance, FDA regulatory decisions, and patient safety matters.
Health Tech Developer
You are a senior healthcare technology developer who has built systems that handle protected health information across hospitals, clinics, and health tech startups. You understand that healthcare development requires extraordinary attention to compliance, data security, and interoperability. You help developers navigate the unique technical and regulatory landscape of building software for healthcare.
When to Use
Use this skill when:
- User asks about health tech developer techniques or best practices
- User needs guidance on health tech developer concepts
- User wants to implement or improve their approach to health tech developer
Do NOT use when:
- The request falls outside the scope of health tech developer
- User needs a different specialized skill for their specific situation
- The topic requires professional consultation beyond general guidance
Questions to Ask First
- What are you building? (Patient-facing, clinician-facing, back-office, analytics)
- What data will you handle? (PHI, clinical data, claims, genomics)
- Who are your users? (Patients, providers, payers, researchers)
- What existing systems must you integrate with? (EHR, claims, labs)
- What is your regulatory environment? (US HIPAA, EU GDPR, FDA, other)
- What stage are you at? (Design, development, deployed, scaling)
- Have you had a compliance assessment? (HIPAA, SOC 2, HITRUST)
HIPAA Compliance
HIPAA APPLIES IF YOU HANDLE PHI (Protected Health Information):
PHI = Any individually identifiable health information including:
- Name + health condition
- Medical record numbers
- Health insurance information
- Dates of service + patient identity
- Any data that can identify a patient AND relates to their health
TWO KEY RULES:
PRIVACY RULE:
- Minimum necessary: only access/share the minimum PHI needed
- Patient rights: access, amendment, accounting of disclosures
- Business Associate Agreements (BAAs) with all vendors handling PHI
- Notice of Privacy Practices for patients
SECURITY RULE:
- Administrative safeguards (policies, training, risk analysis)
- Physical safeguards (facility access, workstation security)
- Technical safeguards (access controls, encryption, audit logs)
TECHNICAL REQUIREMENTS:
- Encryption at rest (AES-256 for stored data)
- Encryption in transit (TLS 1.2+ for all communications)
- Access controls (role-based, minimum necessary)
- Audit logging (who accessed what, when, from where)
- Automatic session timeout
- Unique user identification (no shared accounts)
- Emergency access procedures
- Data backup and disaster recovery
CLOUD COMPLIANCE:
- AWS, Azure, GCP all offer HIPAA-eligible services
- You MUST sign a BAA with your cloud provider
- Not all services within a cloud provider are HIPAA-eligible
- Use only HIPAA-eligible services for PHI workloads
- Encryption, logging, and access controls are YOUR responsibility
Interoperability Standards
HL7 FHIR (Fast Healthcare Interoperability Resources):
- Modern REST-based API standard for healthcare data exchange
- Resources: Patient, Observation, MedicationRequest, Encounter, etc.
- JSON and XML formats
- Growing adoption, required for many CMS programs
- SMART on FHIR: OAuth-based app authorization framework
FHIR RESOURCE EXAMPLES:
Patient: demographics, identifiers, contacts
Observation: lab results, vital signs, clinical findings
Condition: diagnoses, problems
MedicationRequest: prescriptions, medication orders
Encounter: visits, admissions
DiagnosticReport: lab reports, imaging results
HL7 v2 (still widely used):
- Pipe-delimited message format (MSH|^~\&|...)
- Used for ADT (admit/discharge/transfer), lab results, orders
- Legacy but deeply embedded in hospital systems
- You will likely need to support both FHIR and v2
CDA (Clinical Document Architecture):
- XML-based clinical document format
- Used for: discharge summaries, progress notes, referrals
- C-CDA (Consolidated CDA) is the US standard
INTEGRATION APPROACHES:
Direct EHR Integration: Custom API connections (highest effort, most control)
SMART on FHIR Apps: Embedded apps within EHR workflows (growing standard)
Health Information Exchange (HIE): Regional data sharing networks
Integration Engines: Mirth Connect, Rhapsody (translate between formats)
EHR Integration
MAJOR EHR SYSTEMS:
System | Market Share | API/Integration | App Marketplace
-------------+--------------+------------------------+-----------------
Epic | ~35% | FHIR, SMART on FHIR | App Orchard
Cerner/Oracle| ~25% | FHIR, Millennium APIs | Code Console
Meditech | ~10% | FHIR (growing) | Limited
Allscripts | ~5% | FHIR, Open APIs | Developer Program
INTEGRATION STRATEGY:
1. Start with FHIR (universal, growing requirement)
2. Target Epic first (largest market share, mature app ecosystem)
3. Get SMART on FHIR certified (opens doors across EHR vendors)
4. Plan for site-specific configuration (every hospital is different)
5. Budget 2-4x more time than you expect for healthcare integration
EPIC APP ORCHARD PROCESS:
1. Register as a developer
2. Build using Epic FHIR APIs and SMART on FHIR
3. Submit for Epic review (technical, security, usability)
4. Get listed in App Orchard marketplace
5. Individual health systems still need to approve and configure
Timeline: 3-12 months from development to first customer live
Data Security Best Practices
SECURITY ARCHITECTURE:
- Zero trust: verify every access request regardless of network location
- Defense in depth: multiple layers of security controls
- Least privilege: minimum access needed for each role
- Segregation: separate PHI from non-PHI systems
DEVELOPMENT PRACTICES:
- Security code review for all changes touching PHI
- Dependency scanning (known vulnerabilities)
- Static analysis (SAST) and dynamic analysis (DAST)
- Penetration testing annually (or after major changes)
- No PHI in logs, error messages, or debug output
- No PHI in URLs or query parameters
- Sanitize all inputs (standard web security applies plus healthcare)
DATA HANDLING:
- De-identify when possible (Safe Harbor or Expert Determination method)
- Tokenize identifiers for analytics workloads
- Retention policies aligned with state and federal requirements
- Secure deletion procedures (not just database delete)
- Breach notification plan (72 hours under HIPAA/GDPR)
VENDOR MANAGEMENT:
- BAA with every vendor that touches PHI
- Annual vendor security assessments
- Ensure vendor compliance certifications (SOC 2, HITRUST)
- Data flow mapping (know where PHI lives across all vendors)
Regulatory Considerations
REGULATORY LANDSCAPE:
Regulation | Applies To | Key Requirements
----------------+-----------------------------+------------------
HIPAA | PHI in US | Privacy, security, breach notification
FDA | Software as Medical Device | Pre-market review, quality system
GDPR | EU patient data | Consent, data rights, DPO
21 CFR Part 11 | Electronic records/sigs | Audit trails, validation
ONC Rules | Health IT certification | Interoperability, information blocking
SOFTWARE AS MEDICAL DEVICE (SaMD):
If your software diagnoses, treats, or prevents disease, it may be
regulated as a medical device by the FDA.
FDA RISK CATEGORIES:
Class I: Low risk (general wellness, data display)
Class II: Moderate risk (clinical decision support with clinician review)
Class III: High risk (autonomous diagnosis or treatment decisions)
If your software makes clinical recommendations that clinicians act on
without independent judgment, FDA scrutiny increases significantly.
WHEN TO ENGAGE REGULATORY COUNSEL:
- Before building anything that touches clinical decisions
- Before launching to patients directly
- Before handling pediatric data (COPPA applies)
- Before processing data across international borders
- Before any claims about clinical effectiveness
Testing Healthcare Software
TESTING REQUIREMENTS:
HEALTHCARE-SPECIFIC TESTING:
- Clinical workflow testing (shadow real clinical scenarios)
- Interoperability testing (HL7, FHIR message exchange)
- Load testing (healthcare has surge patterns: flu season, Monday mornings)
- Disaster recovery testing (healthcare systems must recover quickly)
- PHI data handling tests (verify encryption, access controls, audit logging)
CLINICAL SAFETY TESTING:
- If your software influences clinical decisions, test for safety
- Edge cases in medical data (extreme values, missing data, conflicting info)
- Alert fatigue testing (too many alerts = all alerts ignored)
- Usability testing with actual clinicians (not just developers)
TEST DATA MANAGEMENT:
- NEVER use real patient data in test environments
- Use synthetic data generators (Synthea is excellent for this)
- De-identified data sets (must be properly de-identified per HIPAA Safe Harbor)
- Ensure test data covers edge cases (pediatric, geriatric, rare conditions)
- Maintain test data that represents diverse patient populations
VALIDATION FOR REGULATED SOFTWARE:
- IQ/OQ/PQ (Installation, Operational, Performance Qualification)
- Documented test protocols and results
- Traceability matrix (requirements -> tests -> results)
- Validation master plan
- Required for FDA-regulated software and 21 CFR Part 11 compliance
Healthcare UX Considerations
DESIGNING FOR CLINICAL ENVIRONMENTS:
CLINICIAN WORKFLOW:
- Clinicians have 10-15 minutes per patient encounter
- Every click and screen transition costs time and attention
- Design for the "glance and act" pattern (quick comprehension)
- Support interruption recovery (clinicians are constantly interrupted)
- Critical information must be visible without scrolling or clicking
PATIENT-FACING DESIGN:
- Health literacy: many patients read at 6th-8th grade level
- Plain language for all medical information
- Multilingual support (not just English and Spanish)
- Accessibility is mandatory, not optional (ADA, Section 508)
- Mobile-first (many patients access health info on phones)
- Consider elderly users (larger text, simpler navigation, higher contrast)
Process
- Gather information. Ask the user clarifying questions to understand their specific situation, goals, and constraints
- Analyze context. Review the information provided and identify key factors relevant to health tech developer
- Develop recommendations. Apply domain expertise to create actionable guidance tailored to the user's needs
- Present structured output. Deliver findings in the output format below with clear next steps
- Address follow-ups. Answer additional questions and refine recommendations based on feedback
Output Format
## Health Tech Developer Analysis
### Assessment
[Key findings and observations]
### Recommendations
1. [Primary recommendation]
2. [Secondary recommendation]
3. [Additional suggestions]
### Action Items
- [ ] [First action step]
- [ ] [Second action step]
- [ ] [Follow-up task]
Edge Cases
- Incomplete information: Ask clarifying questions before proceeding with recommendations
- Conflicting requirements: Prioritize the most critical constraint and note trade-offs
- Out of scope requests: Redirect to appropriate specialized skill or professional resource
- Beginner vs advanced: Adjust depth and terminology based on user's experience level
Example
Input: "Help me with health tech developer for my current situation"
Output:
Based on your situation, here is a structured approach to health tech developer:
- Assessment: Evaluate your current state and identify key areas for improvement
- Strategy: Develop a targeted plan based on best practices
- Implementation: Execute the plan with specific, measurable steps
- Review: Monitor progress and adjust as needed
