Dépréciation de l'API ouverte d'eOrientation Ocean
À partir du 3 novembre 2022, l'API ouverte d'eOrientation Ocean est dépréciée. Les systèmes tiers qui développent de nouvelles intégrations avec les eDemandes Ocean (eOrientation et consultations électroniques) devraient utiliser les API FHIR d'Ocean.
Les API ouvertes d'Ocean permettent aux systèmes tiers de s'intégrer avec Ocean afin que les fournisseurs puissent traiter les orientations dans leur système ou application préféré. En plus de la documentation de l'API ouverte, nous avons rassemblé les directives de mise en œuvre suivantes pour accélérer la mise en œuvre de votre intégration.
Séquence d'intégration d'eOrientation
Le diagramme de séquence ci-dessous illustre la séquence d'interaction entre Ocean et un système tiers après qu'une orientation a été créée dans Ocean.
Validation du Webhook
- Le webhook nécessite que l'URL réponde à un défi pour qu'il fonctionne correctement. Tester avec un webhook qui n'est pas prêt à fournir le jeton de défi dans la réponse échouera à la validation. Cela est indiqué par un symbole de point d'exclamation jaune à côté de l'URL.
- La vérification de validation ne nécessite pas les en-têtes spécifiques à Ocean (sitenum, sitekey) dans la réponse, bien qu'ils ne causeront pas d'erreurs s'ils sont inclus. Pour des informations supplémentaires, veuillez consulter nos documents API
Chiffrement de la charge utile
- Le code de cryptage dans la documentation de l'API Ocean est un exemple qui illustre le flux de cryptage correct et met en évidence la bibliothèque de cryptage (CryptoJS) que nous utilisons et recommandons lors de l'utilisation de Javascript. Mais le schéma de cryptage est simplement un cryptage AES standard, vous pourrez donc absolument crypter/décrypter ces données dans d'autres langages. Par exemple, pour Ruby, vous pouvez utiliser le module OpenSSL dans la bibliothèque standard pour exécuter les chiffrements AES afin de crypter et décrypter les données. Il existe probablement aussi d'autres gems AES/cryptographie externes que vous pouvez utiliser si vous avez une préférence.
- ***Lors de la récupération d'une recommandation, il est recommandé d'utiliser le oneTimeKeyEncryptedWithSitePublicKey": champ (plutôt que le champ oneTimeKeyEncryptedWithTargetPublicKey") afin que votre système puisse également décrypter les recommandations qui sont envoyées par les sites Ocean de vos clients (et pas seulement celles qui sont reçues par celui-ci). Voir la section "Comportement de l'API" de cet article pour plus d'informations sur la réception d'une copie des recommandations envoyées.
Mappage des données
- Le fichier en bas de cet article répertorie les éléments de données disponibles dans les charges utiles de l'API ouverte.
- si le site autorise plusieurs dates de rendez-vous pour une seule recommandation, la liste des recommandations doit avoir plusieurs étiquettes configurées. Par défaut, Ocean n'active qu'une seule étiquette pour chaque liste nommée “Rendez-vous”. Chaque liste de recommandations (Admin du site > Directory Listings > Informations sur la liste > section Détails du service) peut être configurée par l'Admin du site pour accepter l'ajout d'étiquettes supplémentaires à partir des valeurs suivantes : rendez-vous 1 - 5, date de consultation, date de suivi, date de la première visite, date de la procédure, date de la chirurgie.
- Si un appel API est envoyé avec des données de rendez-vous sans étiquette, alors Ocean assignera la première étiquette de rendez-vous qui n'a pas été utilisée dans cette référence pour ce rendez-vous. Si un deuxième rendez-vous est envoyé sans étiquette et que toutes les étiquettes de rendez-vous ont déjà été assignées pour cette référence, l'API renverra une erreur. Alternativement, les données de rendez-vous peuvent être envoyées avec une étiquette de rendez-vous, mais elle doit correspondre à l'une des étiquettes configurées pour ce site.
- L'API POST Mise à jour d'une référence accepte les valeurs d'état de référence suivantes dans le champ état : Accepté, Refusé, Confirmé, Annulé, Terminé, Imprimé, Incomplet, Envoyé. Le champ est facultatif et ne doit être rempli par le Système Tiers que lorsque la valeur de l'état de la référence est différente de la mise à jour précédente envoyée à Ocean. Ocean renverra une erreur de "La référence est déjà dans l'état demandé" si deux mises à jour sont envoyées avec la même valeur d'état. Ainsi, si l'ensemble interne des états de référence du Système Tiers est plus granulaire que celui d'Ocean, les mises à jour de référence doivent contenir les informations mises à jour pertinentes sans valeur d'état à moins qu'elle ne change l'état de la référence Ocean.
- La référence est mise à jour à un état "Réservé" en interne par Ocean une fois qu'elle reçoit des données de rendez-vous du Système Tiers.
- Une fois qu'une référence est dans l'état de référence "Terminé" ou "Annulé", elle ne peut pas revenir à un autre état de référence via l'API.
- Ocean placera une référence dans le dossier 'Besoin de révision' lorsqu'un destinataire reçoit un nouveau message (par exemple, le destinataire de la référence envoie un message dans la référence à l'expéditeur avec des instructions de soins pour le patient). Lorsqu'un message est envoyé en utilisant le point de terminaison 'Ajouter un message' (URL ci-dessous), le TargetSiteNum doit être rempli avec le numéro de site du fournisseur qui doit réviser le message afin qu'il soit 'signalé' pour inclusion dans le dossier Besoin de révision.