Availity

L'intégration entre Corma et Availity aligne les utilisateurs Availity Essentials de votre organisation sur les collaborateurs qui travaillent chaque jour avec les assureurs santé (health plans). Availity présente Availity Essentials comme une plateforme sécurisée et multi-payeurs, où les prestataires de soins et les assureurs santé collaborent en échangeant des informations administratives et cliniques. Essentials est gratuit et financé par les assureurs santé : la question de gouvernance ne porte donc pas sur les sièges, mais sur les personnes qui détiennent encore un identifiant d'accès à ces informations.

À retenir

• Availity exige que chaque personne ait son propre compte, et ne facture pas les comptes utilisateurs sur Availity Essentials.
• La personne qui inscrit une organisation dans Availity Essentials en devient automatiquement l'administrateur principal (primary administrator).
• L'Organization Access Agreement d'Availity impose à l'Administrator de désactiver l'accès d'un salarié dès la fin de son contrat, sans délai.
• Chaque utilisateur d'Availity Essentials doit s'inscrire à l'authentification en deux étapes, et Availity bloque un compte après 60 jours ou plus sans connexion.

Qu'attend Availity de votre administrateur ?

Les obligations figurent dans un contrat. L'Organization Access Agreement d'Availity rend l'Administrator seul responsable de veiller à ce que chaque utilisateur dispose d'identifiants de connexion uniques, et de tenir une liste exacte et à jour de tous les utilisateurs. L'Administrator peut désactiver l'accès d'un utilisateur en ligne ou par demande écrite adressée à Availity, et l'organisation est responsable des pertes causées par tout tiers qui utilise les identifiants de connexion de ses utilisateurs. Les dispositions relatives à la loi HIPAA et aux Business Associates figurent dans une section distincte du même accord.

L'administrateur invite les utilisateurs un par un, en masse à partir d'une feuille de calcul, ou en copiant un utilisateur d'une autre organisation, et attribue les rôles selon la fonction occupée. Availity prévoit aussi des délégués de l'administrateur (administrator delegates) et un User Administrator. Availity purge périodiquement les utilisateurs inactifs, et un utilisateur purgé a besoin d'un nouvel identifiant utilisateur (user ID) fourni par son administrateur : la liste des utilisateurs dans Availity peut donc s'écarter de vos données RH. Le guide de l'API d'Availity ajoute que chaque application du Developer Portal reçoit un client ID et un client secret affiché une seule fois, et que les jetons d'accès durent cinq minutes.

Comment Corma encadre Availity

• Des départs désactivés à temps : un workflow de départ créé dans l'IT Workflow Builder, déclenché depuis votre SIRH, demande à l'administrateur Availity de révoquer l'accès de la personne le jour de son départ, comme l'exige l'accord.
• Utilisateurs et administrateurs en revue : les utilisateurs, les administrateurs et les délégués de l'administrateur Availity entrent dans des revues des accès automatisées, ce qui aide à tenir la liste exacte des utilisateurs que demande l'accord.
• Des applications développeur avec un propriétaire : les client IDs et les secrets du Developer Portal sont des identités non humaines, et chaque application a donc besoin d'un propriétaire désigné de votre côté.
• Les options payantes sous contrôle : un abonnement mensuel Essentials Plus, qui ajoute de nombreux payeurs non sponsors, figure dans la gestion des abonnements SaaS.

Questions fréquentes

Availity prend-il en charge le SSO et le SCIM ?

La FAQ d'Availity sur l'authentification en deux étapes mentionne des utilisateurs qui accèdent à Availity via l'authentification unique (Single Sign-On) et précise que le changement ne les concerne pas, mais les pages publiques d'Availity ne documentent ni configuration SAML ni provisionnement SCIM pour les organisations de prestataires de soins. Découvrez comment gérer l'offboarding des applications sans SCIM, SAML ni SSO.

Comment Corma se connecte-t-il à Availity ?

Le guide de l'API d'Availity liste des API d'éligibilité, de demandes de remboursement (claims) et d'autres API de santé, mais aucune API de gestion des utilisateurs : les agents navigateur de Corma gèrent donc les étapes liées aux utilisateurs dans Availity Essentials, dans une session de navigateur isolée, avec des identifiants issus de votre coffre-fort de mots de passe. Découvrez aussi comment Corma aide les équipes RH à automatiser l'onboarding et l'offboarding.

Où sont hébergées les données de Corma ?

Corma est hébergé sur AWS, avec des serveurs web et des bases de données situés dans des centres de données de l'Union européenne. Les données sont chiffrées en transit et au repos, et Corma est certifié ISO/IEC 27001:2022.

Vous voulez savoir quels identifiants Availity ont survécu au départ des personnes qui les détenaient ? Demandez une démo Corma.