Référentiels Ameli
25/10/2017
L'assurance maladie innove dans le domaine des données ouvertes et participe à des hackathons pour trouver des nouveaux usages, et c'est une bonne nouvelle. Cependant, le mécanisme de fourniture aux établissements de santé des données de référence conditionnant leur codage de l'activité (T2A) et donc leur financement mériterait également de bénéficier d'innovations. Analyse et Propositions.
Depuis 2008, le Financement des établissements de santé - Financement - Ministère des Affaires sociales et de la Santé se fait sur la base de l’activité des professionnels de santé. Cette activité relative aux patients hospitalisés doit être codée selon la nomenclature CCAM. En plus de cette activité exprimée en actes CCAM, s’ajoute la délivrance de produits médicaux et pharmaceutiques au coût élevé. Ces délivrances sont exprimées en utilisant les nomenclatures LPP et UCD.
Ainsi, et pour simplifier grandement, on s’intéressera aux 3 nomenclatures : CCAM, LPP, UCD qui permettent de déclarer l’activité des professionnels de santé réalisée sur des patients hospitalisés et servant de base pour une partie du financement de l’hôpital (plusieurs millions d’euros par an).
Ces trois référentiels sont fournis par l’assurance maladie, accessibles sur le site ameli.fr :
- médicaments codés en Unité Commune de Dispensation : UCD
- Liste des Produits et Prestations : LPP
- Classification Commune des Actes Médicaux : CCAM
Par ailleurs, ces nomenclatures sont en perpétuelle évolution, au gré de l’intégration de nouveaux actes et du changement de tarification de remboursement d’un produit. Ainsi, les versions des nomenclatures sont les suivantes au 25/10/2017 :
- UCD : version 381
- LPP : version 466
- CCAM : version 49
En se basant sur l’historique du référentiel LPP est disponible, on peut alors visualiser la répartition des versions par an :
Les mises à jour sont donc nombreuses, il est primordial pour les SIH d’intégrer ces référentiels de façon simple et efficace afin de permettre le bon codage de l’activité réalisée et ainsi de bénéficier des recettes issues du remboursement de l'assurance maladie.
Il faudrait alors que chaque nomenclature soit :
- accessible de façon simple, au travers d’une ressource HTTP par exemple ;
- dans un format ouvert, structuré ;
- accompagné d’un mécanisme d’information de la mise à disposition d’une nouvelle version.
Accessibilité des référentiels
L’assurance maladie fournit trois pages web, une par référentiel. L’organisation de ces pages est propre à chaque référentiel, il n’y a pas d’homogénéité dans la présentation de l’information.
De plus, les données sont fournies dans des formats et des regroupements hétérogènes :
Nomenclature | format | Nom du fichier |
---|---|---|
CCAM | fichiers au format NX et dbf en plusieurs parties et zippés | nom du fichier avec numéro de version et numéro de partie |
UCD | plusieurs fichiers dbf | nom du fichier avec numéro de version et date |
LPP | une seule archive zip contenant plusieurs dbf | nom du fichier avec numéro de version |
Les traitements pour chacune des nomenclatures, même si elles sont délivrées par la même entité (l’assurance maladie), sont différents.
Formats des données
Les formats proposés par l’assurance maladie sont de deux types :
- format texte complexe : format NX. Ce type de format, très utilisé à l’époque des gros systèmes, contient des lignes de valeurs. La structure des données est spécifique, chaque valeur possède une longueur fixe. Pour lire ces données, il est alors nécessaire d’implémenter un analyseur spécifique en se basant sur les 139 pages du document le décrivant. Dans un SIH, plusieurs logiciels permettent de coder l’activité, en fonction de sa spécialité. Chaque logiciel doit donc prendre en charge le code spécifique pour intégrer ces données, ce qui est naturellement générateur de coûts et d’erreurs potentielles.
- format dbf : format dbase. Ce format est propriétaire (par opposition au format libre). Il nécessite une utilisation de la suite office (libre office ou MS office) ou des outils dbase pour pouvoir le lire. Peu de librairies dans les langages classiques sont disponibles, ce qui ne facilite pas son adoption.
Information sur la disponibilité d’une nouvelle version
Le site ameli ne met aucun dispositif permettant de savoir qu’une nouvelle version d’un référentiel est publiée :
- ni alerte par mail ;
- ni flux d’information type RSS/Atom ;
- ni service web à interroger.
Dans cette configuration, comment automatiser le téléchargement et la mise à jour des données dans le SIH ? La structure des informations proposées étant différente selon les nomenclatures, les mécanismes de détection et de mise à jour sont donc dépendants de chaque nomenclature, pourtant fournis tous les trois par l’assurance maladie !
Voici quel peut être le processus de détection et de prise en compte automatique des nomenclatures. L’idée générale est d’essayer de prédire le nommage des versions nouvelles et d’essayer de la télécharger lorsque c’est possible. Dans tous les cas, il est nécessaire de conserver dans son système le dernier numéro de version traité.
CCAM
La version de la CCAM n’est pas systématiquement une valeur entière incrémentée et
prédictive. Nous avons en effet des progressions simples v33, v34, v35, v36, etc.
entrecoupées de valeurs v37.01, v39.10, v42.5. Il est donc impossible de tenter de deviner
la présence d’une future version en faisant version actuelle + 1
.
L’accès aux fichiers dbf n’est donc pas prédictible, mais une
possibilité est :
- lire la page : http://www.ameli.fr/accueil-de-la-ccam/telechargement/index.php et la parser avec un passeur HTML flexible type Beautiful Soup (https://www.crummy.com/software/BeautifulSoup/) ;
- chercher les liens de type
http://www.ameli.fr/fileadmin/user_upload/documents/CCAM<XXXX>_DBF_PART<Y>.zip
dont la version est postérieure à la dernière version téléchargée ; - télécharger tous ces zip et essayer de reconstruire une archive zip unique, afin enfin d’extraire les données ;
- lire et exploiter les données du fichier dbf.
UCD
La version des données UCD est linaire, est incrémentée de 1 à chaque fois. Cependant le fichier dbf fournissant les données contient dans son nom, en plus de la version, la date de mise à disposition. Le fichier est accessible via l’URL
http://www.codage.ext.cnamts.fr/f_mediam/fo/bdm_it/ucd_total_00337_20161104.dbf
L’accès aux fichiers dbf n’est donc pas prédictible.
Par contre, une archive zip est présente et son nom est prédictible, par exemple :
http://www.codage.ext.cnamts.fr/f_mediam/fo/bdm_it/UCD_TOT_00337.zip
Une possibilité est alors :
- essayer de télécharger
http://www.codage.ext.cnamts.fr/f_mediam/fo/bdm_it/UCD_TOT_<XXXXX>.zip
en se basant sur la dernière version prise en compte et en incrémentant cette version de 1 ; - une fois cette archive téléchargée, il faut l’extraire et utiliser les fichiers .dbf qu’elle contient.
LPP
La version des données LPP est linéaire, comme pour celle des UCD. Les données au format .dbf sont contenues dans un fichier zip qui ne contient que le numéro de version. L’accès au nouveau fichier zip est donc prédictible.
Une possibilité est donc :
- essayer de détecter si le fichier
http://www.codage.ext.cnamts.fr/f_mediam/fo/tips/LPP<XXX>.zip
est disponible en se basant sur la dernière version prise en compte et en incrémentant cette version de 1 - une fois l’archive téléchargée, extraire et utiliser les fichiers .dbf qu’elle contient.
Propositions
Ces données de référence font partie des jeux de valeurs qui permettent aux différents établissements de santé de fonctionner puisqu’elles conditionnent leur financement. L’Assurance Maladie, fournisseur de ces données, a par ailleurs entamée une démarche open data, sur laquelle elle communique régulièrement, notamment lors de hackhathons. La simplification des formats, des moyens d’accès à ces référentiels est donc une étape nécessaire et peu complexe à mon sens.
Ainsi la proposition d’évolution serait la suivante :
- publication des données sur data.gouv.fr ;
- utilisation de l’API étalab pour accéder à ces données. L’utilisation de cette API serait une avancée fondamentale car elle permettrait aux logiciels d’avoir un support informatique concernant les meta-données des jeux de valeurs, avec des dates de mises à jour, des URL définies informatiquement (et non plus déduite avec plus ou moins de chance). Voir un exemple d'utilisation de cette API pour les données Finess ;
- changement du format des données : le changement peut être plus ou moins ambitieux
- mécanisme de diffusion de l'information lorsqu'une nouvelle version est disponible : mail, flux ATOM/RSS, API de consultation, etc.