| name | fhir-migration |
| description | Migration du stockage Patient/Practitioner vers HAPI FHIR. Utiliser quand l'utilisateur demande d'implémenter l'architecture hybride FHIR, créer des mappers FHIR, ou intégrer avec HAPI FHIR. |
| allowed-tools | Read, Glob, Grep, Edit, Write, Bash(poetry:*), Bash(git:*) |
Migration HAPI FHIR - core-africare-identity
Ce skill guide la migration du service core-africare-identity vers une architecture hybride avec HAPI FHIR comme source de vérité pour les données démographiques.
Architecture Cible
Client → API (Pydantic) → Service Layer → HAPI FHIR (Patient/Practitioner)
↓
PostgreSQL (métadonnées GDPR)
- HAPI FHIR: Source de vérité pour données démographiques (Patient, Practitioner)
- PostgreSQL: Métadonnées GDPR locales (soft_deleted_at, correlation_hash, etc.)
- Keycloak: Authentification et gestion des utilisateurs
Composants à Implémenter
1. Infrastructure FHIR
| Fichier | Description |
|---|---|
app/infrastructure/fhir/__init__.py |
Exports du module |
app/infrastructure/fhir/client.py |
Client HTTP async pour HAPI FHIR |
app/infrastructure/fhir/config.py |
Configuration FHIR (URL, timeout) |
app/infrastructure/fhir/identifiers.py |
Systèmes d'identifiants FHIR |
app/infrastructure/fhir/exceptions.py |
Exceptions FHIR typées |
Voir CLIENT-SETUP.md pour les détails d'implémentation.
2. Mappers Pydantic ↔ FHIR
| Fichier | Description |
|---|---|
app/infrastructure/fhir/mappers/__init__.py |
Exports des mappers |
app/infrastructure/fhir/mappers/patient_mapper.py |
PatientCreate ↔ FHIR Patient |
app/infrastructure/fhir/mappers/professional_mapper.py |
ProfessionalCreate ↔ FHIR Practitioner |
Voir MAPPERS.md pour les templates de mappers.
3. Modèles GDPR Locaux
| Fichier | Description |
|---|---|
app/models/gdpr_metadata.py |
PatientGdprMetadata, ProfessionalGdprMetadata |
Voir GDPR-MODELS.md pour les modèles SQLAlchemy.
4. Service Layer Orchestration
Modifier les services existants pour orchestrer HAPI FHIR + PostgreSQL.
Voir SERVICE-LAYER.md pour le pattern d'orchestration.
Workflow de Migration
Phase 1: Infrastructure (Prérequis)
# 1. Ajouter dépendances
poetry add "fhir.resources>=7.0.0" "httpx>=0.27.0"
# 2. Créer structure répertoires
mkdir -p app/infrastructure/fhir/mappers
touch app/infrastructure/fhir/__init__.py
touch app/infrastructure/fhir/mappers/__init__.py
Phase 2: Client FHIR
- Créer
app/infrastructure/fhir/config.py- Configuration - Créer
app/infrastructure/fhir/identifiers.py- Systèmes d'identifiants - Créer
app/infrastructure/fhir/exceptions.py- Exceptions - Créer
app/infrastructure/fhir/client.py- Client HTTP async
Phase 3: Mappers
- Créer
app/infrastructure/fhir/mappers/patient_mapper.py - Créer
app/infrastructure/fhir/mappers/professional_mapper.py - Ajouter tests dans
tests/unit/test_fhir_mappers.py
Phase 4: Modèles GDPR
- Créer
app/models/gdpr_metadata.pyavec PatientGdprMetadata - Créer migration Alembic:
make migrate MESSAGE="Add GDPR metadata tables" - Appliquer migration:
make migrate-up
Phase 5: Orchestration Services
- Modifier
app/services/patient_service.pypour utiliser FHIR + PostgreSQL - Modifier
app/services/professional_service.py - Mettre à jour les endpoints API
Phase 6: Suppression Legacy
- Marquer tables
patients/professionalscomme deprecated - Créer migration de suppression
- Nettoyer les imports
Variables d'Environnement
# HAPI FHIR
HAPI_FHIR_BASE_URL=http://localhost:8090/fhir
HAPI_FHIR_TIMEOUT=30
# Optionnel: Auth FHIR
HAPI_FHIR_AUTH_TOKEN=
Tests
# Tests unitaires mappers
poetry run pytest tests/unit/test_fhir_mappers.py -v
# Tests intégration FHIR (nécessite HAPI FHIR local)
make test-services-up
poetry run pytest tests/integration/test_fhir_client.py -v
make test-services-down
Ressources
- Client Setup - Configuration client FHIR
- Mappers - Templates de mappers Pydantic ↔ FHIR
- GDPR Models - Modèles SQLAlchemy pour métadonnées
- Service Layer - Pattern d'orchestration
- FHIR R4 Spec - Spécification FHIR
Checklist Migration
- Dépendances installées (fhir.resources, httpx)
- Client FHIR créé et testé
- Mappers Patient et Professional créés
- Modèles GDPR créés avec migration
- Services refactorisés pour orchestration
- Tests unitaires et intégration passent
- Tables legacy supprimées
- Documentation mise à jour