Dépréciation de l’API ouverte Ocean eOrientation
Depuis le 3 novembre 2022, l’API ouverte Ocean eOrientation est dépréciée. Les systèmes tiers qui développent de nouvelles intégrations avec les eRequêtes Ocean (eOrientation et Consultation électronique) doivent utiliser les API FHIR d’Ocean.
Les API ouvertes d’Ocean permettent aux systèmes tiers de s’intégrer à Ocean afin que les fournisseurs puissent traiter les eOrientations 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 l’implémentation de votre intégration.
Séquence d’intégration 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 eOrientation a été créée dans Ocean.
Validation du webhook
- Le webhook exige que l’URL réponde à un challenge pour fonctionner correctement. Les tests avec un webhook qui n’est pas prêt à fournir le jeton de challenge dans la réponse échoueront à la validation. Ceci est indiqué par un symbole de point d’exclamation jaune à côté de l’URL.
- La vérification de validation n’exige pas que les en-têtes spécifiques à Ocean (sitenum, sitekey) soient présents dans la réponse, bien qu’ils ne causeront aucune erreur s’ils sont inclus. Pour information supplémentaire, veuillez consulter notre documentation API
Chiffrement du contenu
- Le code de chiffrement dans la documentation de l’API Ocean est un exemple qui illustre le bon déroulement du chiffrement et met en évidence la bibliothèque de chiffrement (CryptoJS) que nous utilisons et recommandons lors du travail en Javascript. Mais le schéma de chiffrement est simplement un chiffrement AES standard, donc vous pourrez absolument chiffrer/déchiffrer ces données dans d’autres langages. Par exemple, pour Ruby, vous pouvez utiliser le module OpenSSL de la bibliothèque standard pour exécuter les algorithmes AES afin de chiffrer et déchiffrer les données. Il existe probablement aussi d’autres gems externes AES/cryptographie que vous pouvez utiliser selon vos préférences.
- ***Lors de la récupération d’une eOrientation, il est recommandé d’utiliser le champ oneTimeKeyEncryptedWithSitePublicKey": (plutôt que le champ oneTimeKeyEncryptedWithTargetPublicKey") afin que votre système puisse également déchiffrer les eOrientations envoyées par les sites Ocean de vos clients (et pas seulement celles qui sont reçues par eux). Consultez la section « Comportement de l’API » de cet article pour plus d’information sur la réception d’une copie des eOrientations envoyées.
Mappage des données
- Le fichier au bas de cet article répertorie les éléments de données disponibles dans les contenus des API ouvertes.
- si le site permet plusieurs dates de rendez-vous pour une seule eOrientation, la liste d’eOrientation 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 d’eOrientation (Admin du site > Listes d'annuaires > Information sur la liste > section Détails du service) peut être configurée par l’Admin du site pour accepter et ajouter des étiquettes supplémentaires parmi les valeurs suivantes : rendez-vous 1 à 5, date de consultation, date de suivi, date de 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 eOrientation 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 eOrientation, l’API retournera 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 eOrientation accepte les valeurs d’état d’eOrientation suivantes dans le champ état : Accepté, Refusé, Confirmé, Annulé, Terminé, Imprimé, Incomplet, Envoyé. Le champ est optionnel et ne doit être rempli par le système tiers que lorsque la valeur d’état de l’eOrientation est différente de la mise à jour précédente envoyée à Ocean. Ocean retournera une erreur « L’eOrientation 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 d’eOrientation du système tiers est plus détaillé que celui d’Ocean, les mises à jour d’eOrientation doivent contenir l’information mise à jour pertinente sans valeur d’état à moins qu’elle ne modifie l’état de l’eOrientation dans Ocean.
- L’eOrientation est mise à jour à l’état « Réservé » en interne par Ocean dès qu’elle reçoit des données de rendez-vous du système tiers.
- Une fois qu’une eOrientation est à l’état « Terminé » ou « Annulé », elle ne peut pas revenir à un autre état via l’API.
- Ocean placera une eOrientation dans le dossier « À réviser » lorsqu’un destinataire reçoit un nouveau message (par exemple, le destinataire de l’eOrientation envoie un message à l’expéditeur avec des instructions de soins pour le patient). Lorsqu’un message est envoyé via 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 À réviser.