1. OceanMD
  2. Intégrations
  3. Intégrations API

Intégrations API

Print Guide
S’abonner

Guide de configuration de l’intégration eOrientation HL7 FHIR

Premiers pas avec l’intégration

Les fournisseurs de services peuvent gérer les eOrientations Ocean dans leur dossier médical électronique (DMÉ) du patient ou leur système de gestion des clients (SGC) grâce à l’intégration avec Ocean. L’intégration permet :

  • aux eOrientations d’apparaître dans le DMÉ/SGC sans nécessiter d’activité initiale dans Ocean Portail
  • l’envoi des mises à jour de l’état de l’eOrientation (p. ex. acceptée, réservée, annulée) à Ocean (ce qui entraînera une notification au fournisseur et au patient)
  • l’envoi des mises à jour de la démographie principale du patient à Ocean
  • l’ajout de communications liées à l’orientation à l’orientation (p. ex. instructions au patient ou au fournisseur, pièces jointes)

Ocean prendra en charge deux versions de l’API FHIR eOrientation : v0.10.0 et v0.11.1. Il est fortement recommandé aux nouveaux intégrateurs d’utiliser la v0.11.1. Les intégrateurs existants qui s’étendent à de nouveaux sites peuvent continuer à utiliser la v0.10.0.

Recevoir des orientations d’Ocean

Le guide de configuration suivant vise à fournir aux développeurs de logiciels les étapes préliminaires nécessaires pour préparer un site Ocean à l’intégration avec un DMÉ/SGC. Des détails supplémentaires pour chaque étape sont fournis dans les articles d’assistance liés. L’achèvement de ces étapes permettra de tester la connectivité non authentifiée et la réception du bundle de ressources HL7 FHIR eOrientation d’Ocean.   

  1. Envoyez un courriel à Ocean Support avec le domaine de courriel que vous utiliserez lors du développement technique et des tests (p. ex. pour enregistrer de nouveaux utilisateurs, recevoir des notifications d’orientation, etc.). Veuillez indiquer le nom de votre entreprise et le commanditaire du projet d’intégration (p. ex. une organisation clinique ou juridictionnelle).
  2. Créer un compte utilisateur Ocean et un site sur test.cognisantmd.com
  3. Générez la clé de chiffrement partagée (SEK) du site.
  4. À partir du Menu, sélectionnez Admin puis sélectionnez Fonctionnalités du site. Activez l’option « Activer Cloud Connect Ocean ». Cela déclenchera une boîte de dialogue vous demandant de configurer Cloud Connect. Sélectionnez le bouton « Aller à Cloud Connect ».
  5. Dans Cloud Connect, sélectionnez « Enregistrer ma clé de chiffrement ». (N’accédez pas à l’option « Intégrer à mon DMÉ ».) Entrez la SEK du site et sélectionnez « Sauvegarder »
  6. Configurez le point de terminaison de l’API pour votre DMÉ/SGC - onglet HL7 FHIR eOrientation > Étape 1
  7. Configurez la liste d’annuaire de services pour votre site - réglez le paramètre « Cette liste acceptera-t-elle les eRequêtes? » sur « Oui, eOrientations & Consultation électronique », complétez les détails de base de la liste, ajoutez une offre de service de santé, et dans l’onglet « Activation », activez la case « Accepter les eRequêtes ».
  8. Établissez un lien entre la liste d’annuaire de services et le point de terminaison de l’API - onglet HL7 FHIR eOrientation > Étape 2.
  9. Ajoutez les adresses IP test.cognisantmd.com d’Ocean à votre liste d’autorisation.
  10. Si vous souhaitez qu’Ocean vous envoie des notifications par courriel lorsqu’il reçoit une réponse d’erreur de votre point de terminaison, à partir du Menu, sélectionnez Admin puis sélectionnez Compte du site. Dans le champ « Administrateur clinique / Contact de soutien Ocean », saisissez l’adresse courriel du ou des destinataires des notifications d’erreur.
  11. Créez un deuxième site (en accédant à Mon compte (menu en haut à droite) et en cliquant sur « Créer un nouveau site »). (Ceci afin que vous puissiez simuler l’acheminement réel d’une orientation envoyée vers et depuis un site Ocean vers le site du « fournisseur de services » pris en charge par votre intégration. Vous n’avez qu’à compléter).
  12. Dans le deuxième site (« expéditeur »), recherchez la liste d’annuaire du « fournisseur de services » (du premier site) dans le Healthmap Ocean et soumettez une eOrientation.
  13. Suivez ces instructions pour vous abonner à la section Mises à jour de l’intégration de l’API Ocean afin de recevoir des notifications critiques spécifiques aux incidents d’intégration.

Vous êtes maintenant prêt à recevoir des eOrientations! 

 

Traitement des bundles de messages HL7 FHIR eOrientation

  1. Pour en savoir plus sur les cas d’utilisation, le flux d’intégration, les méthodes et le profilage des ressources FHIR, veuillez consulter le Guide de mise en œuvre HL7 FHIR eOrientation Ontario v0.10.0 pour la v0.10.0. Pour en savoir plus sur la version bêta v0.11.1, veuillez consulter Ontario eOrientation - Consultation électronique Guide de mise en œuvre HL7 FHIR - Brouillon v0.11.1 
  2. Pour voir comment cela est mis en œuvre par Ocean, veuillez consulter notre documentation de l’API HL7 FHIR.
  3. Un complément important à cette documentation est notre article d’orientation sur la mise en œuvre de l’API HL7 FHIR eOrientation, qui décrit les concepts clés et les considérations dont vous devez tenir compte lors du développement de votre intégration.

 

Envoyer des mises à jour d’orientation à Ocean

Pour que le DMÉ/SGC puisse envoyer des mises à jour à Ocean, les étapes de configuration supplémentaires suivantes sont nécessaires. Les API HL7 FHIR qui prennent en charge le cycle de vie de la messagerie eOrientation sont décrites dans une documentation API distincte.

  1. Configurez les identifiants OAuth2 spécifiques au site pour communiquer avec Ocean - onglet HL7 FHIR eOrientation > Étape 3.

 

 

Guide de mise en œuvre de l'API eOrientation HL7 FHIR

Nous avons hâte de vous connecter!

Le but de cet article est d'accélérer vos activités de mise en œuvre d'eOrientation HL7 FHIR en partageant des conseils et des considérations recueillis à partir d'autres mises en œuvre d'eOrientation HL7 FHIR d'Ocean. Il est divisé en les sections suivantes :

  • Documentation d'authentification - liée à la mise en œuvre OAuth2 d'Ocean
  • Documentation API - liée à la mise en œuvre par Ocean du guide de mise en œuvre de l'eOrientation HL7 FHIR de l'Ontario
  • Mappage des données - conseils sur l'intention et l'utilisation de divers champs de ressources FHIR dans le contexte de la mise en œuvre d'Ocean
  • Considérations techniques - éléments à prendre en compte lors du développement de vos API
  • Mise en œuvre et tests - conseils pour évaluer le comportement d'intégration au sein d'Ocean

Cet article de support sera 'vivant' à mesure que des conseils supplémentaires seront recueillis. Il est suggéré de suivre ce guide afin de recevoir une notification lorsqu'il est mis à jour (voir : ‘Se tenir à jour avec les mises à jour des fonctionnalités d'Ocean’ ).

Ocean prendra en charge deux versions de l'API eOrientation FHIR : v0.10.0 et v0.11.1. Il est fortement recommandé aux nouveaux intégrateurs d'utiliser la v0.11.1. Les intégrateurs existants qui s'étendent à de nouveaux sites peuvent continuer à utiliser la v0.10.0.

Définitions utilisées dans cet article

  • Demandeur - l'individu (fournisseur ou patient) qui soumet une demande d'orientation.
  • Fournisseur de services - le service/organisation/fournisseur clinique ou communautaire qui reçoit une demande d'orientation pour fournir un service au patient
  • Cible RMS - le(s) système(s) en aval d'Ocean qui reçoit et agit sur une eOrientation.
  • ID de demande de service - cela correspond dans les messages FHIR à l'identificateur d'orientation d'Ocean
  • SiteID - l'identificateur d'Ocean pour le site mis en place par le fournisseur de services au sein d'Ocean pour envoyer et/ou recevoir (et gérer) des eOrientations
Documentation d'authentification
  • Pour définir les informations d'identification OAuth2 dans l'Ocean Portail, vous devez avoir la clé de chiffrement partagée (SEK) du site (voir l'étape 2 dans l'article suivant : Guide de configuration de l'intégration HL7 FHIR eOrientation). Si vous ne l'avez pas déjà, l'administrateur du site Ocean peut vous la fournir ou elle peut être récupérée à partir de Cloud Connect. Consultez le guide suivant pour des informations supplémentaires Récupération d'une clé de chiffrement partagée perdue / oubliée
  • L'URL pour la demande de jeton porteur OAuth2 dans l'environnement de test d'Ocean est 
    https://test.cognisantmd.com/svc/oauth2/token
    (la documentation du serveur d'autorisation OAuth 2.0 se réfère à l'environnement de production).
  • Ocean renvoie les codes d'erreur de réponse standard 401/403 pour les erreurs liées à l'autorisation lors de l'accès à nos points de terminaison sécurisés via OAuth2.
  • Si vous êtes bloqué lors de l'échange de jetons OAuth2, cela peut être réinitialisé par l'administrateur du site. Ils peuvent accéder à la page Admin du site > Informations d'identification du site > Page des informations d'identification OAuth et cliquer sur l'icône de cadenas.
Documentation de l'API

Guide de mise en œuvre de l'eOrientation en Ontario :

  • Les API FHIR de l'eOrientation d'Ocean sont conformes à la version v0.10.0 du Guide de mise en œuvre de l'eOrientation en Ontario.
  • Il existe une version plus récente (v0.10.1) qui introduit des 'changements majeurs' (c'est-à-dire non rétrocompatibles) dans l'ensemble de valeurs MessageEventCode, qui ne sont pas pris en charge par Ocean pour le moment.

Section Profils et Opérations :

  • Le guide de mise en œuvre de l'eOrientation en Ontario comprend une section Profils et Opérations qui inclut des liens vers la documentation de profilage spécifique pour chaque ressource FHIR utilisée dans la spécification.
  • Chaque profil indique pour chaque champ s'il est requis, la cardinalité requise, les valeurs enum acceptées si applicable, les invariants spécifiques, et toute autre information pertinente associée.
    • Exemple : Le champ telecom sur la ressource Patient est requis, et les sous-champs system, value, et use sont requis, mais pas les sous-champs rank ou period.

Extension FHIR d'Ocean

  • L'implémentation d'Ocean utilise trois extensions FHIR.
    1. "http://ehealthontario.ca/fhir/StructureDefinition/ext-id-message-header" dans la ressource MessageHeader
    2. "http://ehealthontario.ca/fhir/StructureDefinition/ext-id-health-card-version-code" dans la ressource Patient
      • Les deux premiers sont spécifiés dans le profilage des ressources v0.10.0.
    3. "https://ocean.cognisantmd.com/svc/fhir/v1/CodeSystem/ontario-clinical-wait-time-codes" dans la ressource Appointment des messages notify-add-appointment et notify-update-appointment. 
      • Le troisième (pour les temps d'attente) a été ajouté pour répondre aux besoins du Programme de services électroniques de l'Ontario.

Calcul du temps d'attente :

  • Ocean calcule les temps d'attente pour chaque Directory Listing d'orientation et les affiche dans l'Ocean Healthmap.
  • L'extension FHIR pour les temps d'attente doit être envoyée dans la ressource Appointment pour qu'Ocean mette à jour le temps d'attente en conséquence.
    • Exemple : Lorsqu'une date de rendez-vous est soumise avec l'extension définie sur "wait-1", Ocean utilisera cette date comme la date de la première consultation avec le fournisseur de services de santé dans les calculs de temps d'attente.
      • L'extension doit être définie sur "wait-1a" si le rendez-vous est l'évaluation de dépistage initiale plutôt que la consultation réelle.

Gestion des réponses/erreurs

  • Les messages réussis renverront un code de réponse 200, indiquant qu'Ocean a bien reçue et traitée l'orientation.
  • Les messages qu'Ocean ne peut pas traiter pour quelque raison que ce soit (données incorrectes, données manquantes, JSON non analysable, etc.) renverront un code de réponse 40X/50X avec une Ressource FHIR OperationOutcome comme corps qui contiendra une description de l'erreur. Il inclut une section 'issues' où le serveur présentera des informations de débogage lisibles par l'homme pour aider à déterminer la raison pour laquelle l'erreur a été émise.
    • Ces informations peuvent être n'importe quoi, des erreurs d'analyse JSON, des erreurs de validation de spécification (champs requis manquants ou utilisation de mauvais types de données), des erreurs de logique métier (par exemple, essayer de mettre à jour une orientation qui n'existe pas) et des exceptions de traitement interne de notre côté (généralement des bogues).
    • Avec ces informations et la réponse d'erreur, il y a généralement suffisamment d'éléments pour essayer de trouver efficacement le problème sous-jacent.

Ressource de Tâche :

  • Ocean n'envoie pas de ressource de Tâche dans aucun de ses messages. La ressource de Tâche est uniquement envoyée par le système cible RMS pour indiquer comment la demande de service originale a été traitée par RMS Target. La documentation de l'API inclut des exemples de la ressource de Tâche dans les événements de message entrants envoyés à Ocean par le RMS Target.

Champs Démographiques :

  • Ocean ignorera tous les champs démographiques vides envoyés dans le message 'mise à jour-demande-de-service' du RMS Target (plutôt que de remplacer/supprimer la valeur existante).

Adresses des Patients :

  • Si le RMS Target envoie à Ocean deux adresses FHIR de Patient, Ocean stockera les deux mais n'affichera que la première dans la charge utile.
  • Si plus de deux adresses sont envoyées, Ocean ignorera toutes sauf les deux premières.

Jeton OAuth2 :

  • Le jeton OAuth2 envoyé par le RMS Target fournit à Ocean les informations nécessaires pour déterminer à quel site appartient le message (puisque chaque modèle de jeton est spécifique à un site). C'est pourquoi l'ID du site Ocean n'a pas besoin d'être transmis dans la charge utile.

RefID :

  • Le RefID est utilisé par Ocean pour déterminer à quelle eOrientation spécifique se réfère la charge utile au sein du site Ocean.

Ressources de Rôle de Praticien :

  • Le lot contiendra deux ressources PractitionerRole, l'une décrivant le demandeur et l'autre décrivant le fournisseur de services.
  • Les liens dans le ServiceRequest/MessageHeader établissent quelle ressource est connectée à chaque praticien.
  • Les identificateurs de numéro de facturation basés sur notre modèle de données Clinicien ont été intégrés dans nos ressources FHIR Practitioner au sein des API sortantes. Pour garantir une solution complète, cette mise à jour a maintenant été étendue au traitement des API entrantes. En conséquence, la définition des numéros de facturation sur les objets cliniciens lors de l'arrivée des praticiens FHIR est désormais prise en charge de manière transparente.
  • Certaines orientations et consultations Ocean impliquent un autre acteur (par exemple, secrétaire médical, résident) qui soumet la demande au nom du clinicien. Dans ce cas, il y a un autorisateur de demande et un soumetteur de demande. La charge utile FHIR inclura une troisième ressource Practitioner et PractitionerRole dans le lot pour le soumetteur, (ainsi que l'autorisateur et le spécialiste). Voici des exemples de la façon dont les informations du soumetteur et de l'autorisateur seront renseignées dans la charge utile :
     

    MessageHeader.sender

    ServiceRequest.requester

    MessageHeader.author
    Assistant médecin PA envoyant une orientation sous le médecin Dr. D PA Dr. D Dr. D
    Résident R envoyant une orientation sous le médecin Dr. D R Dr. D Dr. D
    Infirmière praticienne IP envoyant une orientation (commandant une IRM) sous le médecin autorisant Dr. Digley IP Dr. D Dr. D
    Secrétaire médical MOA envoyant une orientation en tant que délégué sous Dr. D MOA Dr. D Dr. D

Identificateur du référent :

  • L'identificateur du référent n'est pas garanti d'être unique. Cela est dû au fait que le référent peut avoir créé l'orientation sans se connecter à un compte utilisateur Ocean (par exemple, directement depuis le Ocean Healthmap), donc Ocean peut ne pas être en mesure d'assigner un identificateur unique.

DocumentReference :

  • Chaque lot ServiceRequest inclura un DocumentReference pour récupérer une copie PDF de l'eOrientation Ocean.
  • Si le demandeur inclut des pièces jointes dans l'eOrientation, celles-ci seront ajoutées au lot en tant que ressources DocumentReference distinctes. Dans ce cas, la copie PDF de l'eOrientation sera toujours la première ressource DocumentResource incluse dans le lot.

Type de contenu de la pièce jointe :

  • Selon la spécification HL7 FHIR eOrientation, il n'est pas obligatoire de préciser le type de contenu/MIME d'une pièce jointe à l'eOrientation.

  • Ocean le fournira si c'est connu, mais les systèmes récepteurs ne doivent pas supposer qu'il sera toujours disponible ou qu'il s'agira d'un type de contenu spécifique (par exemple, PDF), car les demandeurs peuvent inclure d'autres pièces jointes (par exemple, des images).

Récupération du résumé de l'orientation et des pièces jointes :

Limites de taille des pièces jointes :

  • Les API d'Ocean acceptent des tailles de fichier/pièce jointe allant jusqu'à 10 Mo par fichier et jusqu'à un maximum de 50 Mo de pièces jointes à une orientation.
  • Ocean renverra une réponse d'erreur au point de terminaison d'envoi si les pièces jointes dépassent ces limites.
  • Les systèmes d'intégration sont responsables de notifier leurs utilisateurs en cas d'erreur (par exemple, afficher un avertissement à l'utilisateur que les pièces jointes ont dépassé les limites acceptables).

Mode Test :

  • Les cibles d'orientation Ocean ont la possibilité de définir leur directory listing (sous l'onglet 'Activation' de la liste) en 'Mode Test'. Cela signifie que toutes les orientations définies sur cette liste seront traitées comme des patients fictifs.
  • Pour indiquer qu'une charge utile FHIR correspond à une orientation de test, Ocean ajoutera la propriété  meta.security = HTEST à chaque ressource du lot.
Cartographie des données

Démographie obligatoire pour les eOrientations dans Ocean :

      • Ocean envoie les données démographiques de base des fournisseurs pour chaque eOrientation :
  • Les données démographiques suivantes sont obligatoires pour soumettre une eOrientation dans Ocean et doivent être présentes dans la ressource Patient :
    • Prénom(s)
    • Nom de famille (Nom de famille)
    • Date de naissance (DOB)
    • Adresse (champ de rue)
    • Ville
    • Un champ de contact basé sur le téléphone (mobile, fax ou professionnel).

Gestion des valeurs nulles :

  • Ocean n'envoie pas de 'valeur nulle' lorsque le champ n'a pas été rempli.

Champ Sexe :

  • L'objet Patient standard FHIR R4 prend en charge les quatre valeurs AdministrativeGender suivantes pour sa valeur "sexe" : "masculin", "féminin", "autre" et "inconnu". Par conséquent, Ocean utilise "inconnu" lorsque la valeur fournie dans la section "Sexe" est laissée vide, "masculin" et "féminin" lorsque ces choix sont sélectionnés, et "autre" lorsque toute autre valeur est fournie. Les fournisseurs de services peuvent inclure des valeurs plus flexibles ou spécifiques selon les besoins cliniques en utilisant le corps du formulaire de demande de service.

Champ HN-Province et Identificateur HN :

  • Ocean vérifie si le champ HN-province est rempli avec un code alpha provincial standard à deux lettres (par exemple ON, PE). Si c'est le cas, l'identificateur JHN aura un système de nommage comme

    https://fhir.infoway-inforoute.ca/NamingSystem/ca-XX-patient-hcn où XX est le code alpha à deux lettres et le champ d'utilisation sur l'identificateur sera défini sur OFFICIEL.

Saisie des systèmes d'identificateurs :

  • Les utilisateurs sont invités à entrer le nom du système d'identificateurs dans le champ province lorsqu'ils soumettent un numéro d'identification autre qu'un numéro d'assurance maladie provincial. Par exemple, ils entreront "ID militaire" dans le champ HN-province et le numéro d'identification dans le champ assurance maladie. Ocean fournira la valeur entrée dans le champ HN-province comme identificateur de santé secondaire et définira le champ d'utilisation de l'identificateur JHN avec SECONDAIRE.
  • Ocean ne valide pas que le numéro d'identification soumis appartient au système d'identification (par exemple, il ne vérifie pas la somme de contrôle des numéros d'assurance maladie provinciaux).

Catégories de services de santé :

  • Les catégories de services de santé utilisées pour identifier les services offerts pour chaque directory listing sont mappées à SNOMED CT et LOINC.
  • Une liste maîtresse des catégories et des mappages est disponible en bas de cet article (fournie en PDF et .xlsx).

Données du formulaire d'orientation :

  • Le corps du formulaire d'orientation (par exemple, Allergies, Antécédents médicaux, et toute question que le fournisseur de services cliniques ajoute à son formulaire d'orientation Ocean) sera envoyé dans la ressource QuestionnaireResponse en tant que paire clé-valeur de nom.
  • Ocean ne contrôle ni ne contraint les noms de clés créés par le fournisseur de services. Par conséquent, si vous avez l'intention de mapper les réponses de champs spécifiques du formulaire d'orientation dans les champs cibles RMS, vous devrez vous coordonner avec le fournisseur de services sur les noms de clés.   (Cela est défini dans le champ de légende de la question, qui est décrit dans l'onglet Général de l'article suivant : Guide de l'éditeur de formulaire électronique - Ajouter un élément.) 

État du cycle de vie de l'eOrientation :

  • Le tableau ci-dessous illustre les états du cycle de vie de l'eOrientation qui peuvent être communiqués par le RMS Target à Ocean et l'état interne correspondant de l'eOrientation Ocean. 
  • L'état est communiqué par Ocean dans le champ État de la ressource ServiceRequest et est mis à jour par le RMS Target dans le champ État de la ressource Task.

Ressource Patient :

Dates de Rendez-vous :

  • Si le site permet plusieurs dates de rendez-vous pour une seule orientation, la liste d'orientation devrait 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'orientation (Admin du site > Directory Listings > Informations sur la liste > section Détails du service) peut être configurée par l'Admin du site pour ajouter des étiquettes supplémentaires à partir des valeurs suivantes : rendez-vous 1 - 5, date de consultation, date de suivi, date de première visite, date de procédure, date de chirurgie.
  • Il est fortement recommandé que seules ces valeurs soient utilisées dans le champ Appointment.appointmentType.text lors de la création et de la mise à jour d'un rendez-vous à l'aide des messages API.
  • De plus, pour des raisons sémantiques, les seules étiquettes Ocean qui peuvent être utilisées pour stocker l'attente 2 sont Date de procédure et Date de chirurgie.

État de réservation dans Ocean :

  • La référence est mise à jour à un état "Réservé" dans Ocean (ce qui correspond au dossier 'Réservé Non Confirmé' dans l'Ocean Portail) une fois qu'elle reçoit les données de rendez-vous du RMS dans l'événement de message 'add-notify-appointment'.
  • La référence peut être déplacée directement à l'état 'Confirmé' dans Ocean (ce qui correspond au dossier 'Réservation Confirmée' dans l'Ocean Portail) si une ressource Patient est référencée dans le champ Appointment.participant.actor et que le appointment.participant.status est réglé sur accepté . 
    • Note : Si une référence passe directement de l'état Nouveau ou Accepté à l'état Réservation Confirmée, Ocean n'enverra pas un courriel au patient lui demandant de confirmer son rendez-vous.

Instructions pour le courriel de rendez-vous du patient :

  • Les instructions pour le courriel de notification de rendez-vous du patient (par exemple, les instructions de préparation) peuvent être incluses dans le champ Appointment.patientInstruction de l'événement de message 'notify-add-appointment'.

Spécification du moyen de rendez-vous :

  • Le moyen de rendez-vous (vidéo, téléphone) peut être spécifié dans le champ Location.type qui est référencé par le champ Appointment.participant.actor :
    • Si le moyen est inconnu/non spécifié ou connu pour être en personne :
      Inclure un participant contenant un acteur avec le code "LOC", affichage "Emplacement de la clinique" et une référence à la ressource Location de l'annonce.
    • Si le rendez-vous est basé sur le téléphone :
      Inclure un participant contenant un acteur avec le code "LOC", affichage "Visite Téléphonique" et une référence "Location/X" à un emplacement avec l'ID X dans le Bundle. Régler les télécommunications de l'emplacement pour correspondre au numéro de téléphone de l'annonce.
    • Si le rendez-vous est une visite à domicile :
      Inclure un participant contenant un acteur avec le code "HH", affichage "Emplacement du Patient" et une référence "Location/X" à un emplacement avec l'ID X dans le Bundle. Régler l'adresse de l'emplacement pour correspondre à l'adresse du patient si elle est disponible.
    • Si le rendez-vous est à un emplacement alternatif :
      Inclure un participant contenant un acteur avec le code "LOC", affichage "Emplacement Alternatif de la Clinique" et une référence "Location/X" à un emplacement avec l'ID X dans le Bundle.  La ressource Location doit contenir une adresse et sa description doit correspondre à la description de l'emplacement alternatif (par exemple, "Emplacement de Visite de Clinique Alternative : ___"   (NOTE : l'exemple de ressource Location fourni dans le fichier zip en bas de la page sera mis à jour pour inclure l'adresse alternative)

Appel API pour les données de rendez-vous :

  • 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 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.

Champ Task.status :

  • Le message de mise à jour de l'état de notification est utilisé pour transmettre à Ocean les valeurs d'état de référence suivantes dans le champ Task.status : 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 modifie l'état de la référence Ocean. 
  • Lors de l'envoi de la ressource Task pour mettre à jour l'état de la référence, une raison explicative du changement d'état (par exemple, pourquoi la référence a été refusée) peut être ajoutée en utilisant la propriété Task.businessStatus.text.

ID de Service Externe :

  • L'"ID de service externe" dans le listing du répertoire (onglet 'Enablement') est utilisé comme "id" unique pour le HealthcareService. L'administrateur du site peut définir l'ID de Service Externe comme un ensemble unique de chiffres pouvant être utilisé pour identifier le listing dans l'intégration.
Considérations techniques
  • Ocean prend en charge à la fois IPv4 et IPv6
  • Ocean enverra l'ensemble du bundle/ressources ServiceRequest chaque fois qu'il y a une mise à jour de l'un des champs de l'orientation. La liste des modifications est fournie dans le MessageHeader.reason qui peut servir d'« indices » pour que la cible RMS évalue ce qui a changé. Il appartient à la cible RMS de décider quelles mises à jour nécessitent une mise à jour interne et/ou une notification au fournisseur de services.
  • Les événements de mise à jour sont suivis dans notre journal d'audit et déclencheront une notification de 'mise à jour'. Il est sûr d'ignorer les notifications avec le MessageHeader.reason = EVENT_LOGGED.
  • Il n'est pas nécessaire d'avoir une réponse synchrone à la transmission pour le message ServiceRequest entrant autre qu'une réponse HTTP 200 pour indiquer que le message a été reçu avec succès. La prochaine mise à jour d'état asynchrone envoyée à Ocean peut fournir un état plus spécifique pour l'orientation lorsqu'elle est traitée par la cible RMS.
  • Si vous utilisez un seul point de terminaison pour recevoir des bundles ServiceRequest pour plusieurs sites Ocean, vous pouvez identifier qui est le destinataire prévu en examinant le ServiceRequest / Performer / PractitionerRole / Identificateur, qui contiendra l'ID du site.  
  • L'ID du ServiceRequest doit être renseigné dans la section meta->profile du MessageHeader. Cela est requis pour qu'Ocean puisse identifier les messages entrants comme conformes à la spécification Ontario HL7 FHIR eReferral v0.10.0 afin qu'ils puissent être traités en conséquence.
  • De même, lorsque la cible RMS devient « active » avec l'intégration, toutes les orientations électroniques préexistantes qui existent dans le site Ocean ne seront pas envoyées à la cible RMS tant qu'elles ne seront pas mises à jour (ce qui déclenchera Ocean pour envoyer une notification webhook).
  • Ocean maintient un journal de tous les envois de messages qui peut être utilisé pour déterminer quels messages ont été manqués. Ils peuvent être « forcés » manuellement à être renvoyés à la cible RMS en effectuant une mise à jour de l'orientation dans l'Ocean Portail.
Implémentation & Test
  • À mesure qu'une orientation est mise à jour dans Ocean, elle se déplacera entre divers 'dossiers' dans le tableau de bord eOrientation. C'est une façon de voir que la mise à jour de l'état envoyée à Ocean a été traitée.
  • Le journal des événements pour chaque orientation peut être consulté en ouvrant le record de l'orientation et en sélectionnant 'Voir le journal des événements' à partir du menu 'Action' en haut à droite. Cela peut aider à déterminer si l'orientation est mise à jour comme prévu.
  • Lorsque les API Ocean détectent un taux d'erreur d'appel de plus de 5 % lors des 20 premières tentatives, elles désactiveront automatiquement l'API. Elle peut être réactivée en retournant dans Menu Admin > Intégrations, en ouvrant la configuration d'intégration pertinente et en l'enregistrant.
  • Les sites d'orientation Ocean peuvent offrir aux patients un formulaire de site web d'auto-orientation ainsi que la liste eOrientation dans l'Ocean Healthmap.
  • Si cela est activé, ces auto-orientations déclencheront une notification webhook avec un ensemble ServiceRequest.
  • Ils peuvent être distingués des orientations initiées par le fournisseur de services car ServiceRequest.requester fera référence à une ressource Patient plutôt qu'à une ressource PractitionerRole.
  • Les intégrateurs devraient confirmer avec les parties prenantes commerciales du site s'ils souhaitent que les auto-orientations des patients soient traitées de la même manière que les orientations initiées par le fournisseur de services (par exemple, peuvent-ils créer une nouvelle orientation dans le RMS Target/POS ou devraient-ils seulement le faire une fois qu'elles ont été 'acceptées' dans l'Ocean Portail).

Activation des intégrations Ocean

Les sections ci-dessous décrivent les étapes nécessaires pour activer différents types d’intégrations entre Ocean et vos autres systèmes d’information d’entreprise afin d’automatiser et de rationaliser les flux d’information :

  • API HL7 FHIR eOrientation pour recevoir des orientations et envoyer des mises à jour à Ocean en utilisant le format HL7 FHIR R4
  • API ouvertes eOrientation d’Ocean pour recevoir des notifications d’orientation, récupérer des orientations et envoyer des mises à jour à Ocean
  • API ouvertes d’engagement du patient d’Ocean pour créer des eFormulaires Ocean spécifiques au patient et les récupérer une fois qu’ils sont complétés.
  • Un lancement du système d’orientation pour rediriger vers un site Web externe afin de compléter une orientation qui a été initiée dans Ocean.
  • Une source de données externe pour récupérer des données à partir d’un point de terminaison externe à intégrer dans un eFormulaire Ocean.
  • CDS Hooks externes pour s’intégrer à des systèmes externes de soutien à la décision clinique.
HL7 FHIR eOrientation Open API eOrientation Open API eFormulaires Lancement du système d’orientation Source de données externe CDS Hooks externes

Étape 1 : Configuration d’un point de terminaison Webhook

  • À partir du page des paramètres d’administration, cliquez sur Intégrations> "Enregistrer une intégration."
  • Cliquez sur l’option eOrientations pour le type d’intégration.
  • Pour le Type de charge utile , sélectionnez l’option FHIR.
  • Donnez un nom à l’intégration et collez dans le champ URL de la requête l’URL à laquelle Ocean enverra les charges utiles FHIR.
  • Sélectionnez le schéma d’authentification qu’Ocean utilisera pour s’authentifier avec le point de terminaison de votre système et saisissez les paramètres pertinents.
  • Sélectionnez les événements pour lesquels Ocean doit notifier votre système et les actions pouvant être effectuées une fois l’orientation envoyée.
 

Étape 2 : Lier la liste d’annuaire de service à une intégration

  • À partir du page des paramètres d’administration, cliquez sur Listes d'annuaires, puis cliquez sur 'Modifier' pour la liste concernée. Dans l’onglet "Informations sur la liste", assurez-vous que le paramètre "Cette liste acceptera-t-elle les eRequêtes?" est réglé sur "Oui, eOrientations et/ou Consultation électronique".
  • Dans l’onglet "Activation", les intégrations spécifiées pour le site Ocean seront listées dans le champ Intégrations. Sélectionnez celle qui doit être liée à cette liste d’annuaire. Entrez la même valeur dans le champ ID du service externe .
  

Votre site Ocean est maintenant prêt à envoyer des eOrientations à votre système point de service en utilisant les API HL7 FHIR eOrientation.

 

Étape 3 : Générer des identifiants OAuth Ocean

Les systèmes doivent envoyer à Ocean un identifiant client et un secret propres au site afin de recevoir un ou plusieurs jetons OAuth pouvant être utilisés pour soumettre des mises à jour d’orientation pour ce site Ocean. Pour générer l’identifiant client et le secret :

  • À partir du page des paramètres d’administration, cliquez sur Gérer les identifiants > bouton Gérer les identifiants OAuth.
  • Ajoutez un nom significatif et cliquez sur le bouton "Ajouter un nouvel identifiant".
  

Votre site Ocean est maintenant prêt à recevoir des eOrientations de votre système point de service en utilisant les API HL7 FHIR eOrientation.

Configuration des paramètres et des autorisations pour les intégrations API

Prérequis

Ocean offre une grande flexibilité pour effectuer des mises à jour à la eOrientation et recevoir des notifications tout au long du cycle de vie de la eOrientation. Cela peut introduire de la complexité dans une intégration API eOrientation entre Ocean et un système en aval. Cet article décrit ces notifications, paramètres et permissions afin que les intégrateurs puissent évaluer ceux qui peuvent être pris en charge par leur intégration.

  • Les notifications, paramètres et permissions se trouvent sur la page Admin > Intégrations > eOrientation.
  • Après avoir sélectionné « eOrientation », la fenêtre de configuration complète apparaîtra.

Nom de l’intégration

  • Le nom de l’intégration est utilisé pour identifier l’intégration lors de son association à une ou plusieurs Listes d'annuaires.
  • Il est également utilisé pour identifier l’intégration si le site a plusieurs intégrations configurées.

  • Note : La liste des intégrations inclut également des icônes d’état de l’intégration. Un hexagone jaune ou rouge apparaissant à droite du nom de l’intégration indique qu’Ocean ne peut pas communiquer avec succès avec le point de terminaison.

    En survolant l’icône avec votre curseur, vous obtiendrez des détails supplémentaires sur le code de réponse d’erreur reçu par Ocean.

Point de terminaison Webhook

  • Utilisé pour préciser où Ocean enverra les notifications webhook eOrientation à mesure que la demande est mise à jour dans Ocean Portail.
  • Si le Type de charge utile est défini sur Open API, Ocean vérifiera automatiquement si l’URL saisie dans ce champ est valide. Si elle est Non valide, un hexagone jaune apparaîtra.

Type de charge utile

Ocean propose deux ensembles d’API pour l’intégration eOrientation : les Open API et les HL7 FHIR API. Ce paramètre permet de sélectionner l’ensemble d’API qu’Ocean utilisera pour communiquer avec votre système.  

Note : Les deux ensembles d’API ne sont pas équivalents en termes d’événements pris en charge, de structures de données ou de mécanismes de sécurité. Comme les API FHIR sont basées sur des normes et plus largement adoptées, il est conseillé aux intégrateurs de les utiliser, sauf raison spécifique d’utiliser les Open API, comme le lancement contextuel d’un système.

Lancement contextuel du système

  • Certains destinataires de demandes exigent qu’un autre système soit lancé pendant ou après la création d’une eOrientation.

  • L’onglet « Lancement du système d’orientation » dans l’article « Activer les intégrations Ocean » décrit comment configurer un lancement de système d’orientation.

    Note : Cette fonctionnalité est disponible uniquement pour certains acheminements. Veuillez soumettre un billet de soutien pour vérifier si elle s’applique à votre intégration.

Notifications par courriel

  • Lorsque des mises à jour eOrientation sont effectuées dans Ocean Portail, Ocean envoie des notifications par courriel. Celles-ci sont décrites dans l’article d’assistance « Où sont envoyés les courriels de notification de consultation électronique et/ou eOrientation ? ».
  • Par Défaut, les mises à jour effectuées via les API ne déclencheront pas de notifications par courriel aux participants à la demande. Si elles sont Activée, Ocean enverra une notification par courriel aux participants appropriés.

Paramètres de soumission

  • Par Défaut, tous les formulaires d’orientation incluent un bouton « Ajouter la pièce jointe » pour télécharger des fichiers.
  • L’activation de la case « Empêcher les expéditeurs d’orientation d’inclure des pièces jointes » masque le bouton sur toute demande initiée vers des Listes d'annuaires configurées avec cette intégration. Ceci est utile si le système en aval ne souhaite pas stocker ou gérer les Pièces jointes.

Permissions

Développez chaque paramètre ci-dessous pour obtenir de l’Information supplémentaire concernant la fonctionnalité.

Effectuer les mises à jour d’état suivantes dans Ocean : Accepter, Diviser, Compléter, Marquer incomplet, Accepter la réponse, Annuler
  • Par défaut, un site avec une intégration API aura les boutons d’action liés à ces mises à jour d’état cachés dans la page d’eOrientation.
  • Ces mises à jour d’état sont similaires à celles prises en charge par les API, donc le site doit déterminer s’il souhaite qu’elles soient activées afin que les utilisateurs Ocean puissent également gérer l’eOrientation dans Ocean Portail.
Envoyer des messages à partir de la page du record d’eOrientation
  • La messagerie dans l’eOrientation permet à l’expéditeur et au spécialiste de communiquer au sujet de l’eOrientation. Par exemple, le spécialiste peut demander de l’information supplémentaire avant d’accepter l’eOrientation ou l’expéditeur peut s’informer du traitement auprès du spécialiste.
  • Par défaut, Ocean désactive le panneau de messagerie pour les expéditeurs et les destinataires, de sorte qu’ils n’ont pas accès à la saisie ou à l’envoi de messages sur les eOrientations envoyées à une Listes d'annuaires configurée avec une intégration API.
  • Cette permission doit être activée si l’intégration prend en charge la messagerie ou si la messagerie n’a pas besoin d’être stockée dans le système en aval. Qu’elle soit activée ou non, les messages peuvent toujours être envoyés via l’intégration API.
Ajouter des pièces jointes aux messages dans la page du record d’eOrientation
  • Certains sites avec une intégration API qui prennent en charge la messagerie ne prennent pas en charge le stockage et la gestion des pièces jointes.
  • Par défaut, la fonction « Ajouter la pièce jointe » est cachée à moins qu’elle ne soit activée, ce qui empêche les utilisateurs du Portail d’ajouter des pièces jointes à un message.
Ajouter des notes sur la page du record d’eOrientation
  • Les utilisateurs Ocean peuvent ajouter des notes à l’eOrientation pour aider les autres utilisateurs à comprendre comment l’eOrientation est traitée.
  • Lorsqu’une intégration API est en place, cette fonction est désactivée par défaut. Le système en aval peut prendre en charge une fonction Notes en interne ou ne souhaite pas recevoir de mises à jour liées aux notes.
Mettre à jour la démographie du patient dans la page du record d’eOrientation
  • La démographie du patient peut être mise à jour dans Ocean Portail après l’envoi initial de l’eOrientation. Cela peut ajouter de la complexité pour un système en aval intégré en ce qui concerne la gestion des records (scénarios de fusion/défusion de patients).
  • Par défaut, la fonction de mise à jour est cachée pour les eOrientations associées à une Listes d'annuaires ayant une intégration API, ce qui masque le bouton de modification à côté de la démographie du patient pour les expéditeurs et les destinataires, de sorte qu’ils n’ont pas accès à la modification de la démographie sur les eOrientations envoyées à une Listes d'annuaires configurée avec cette intégration.
Annuler l’eOrientation
  • Les expéditeurs d’eOrientation peuvent annuler l’eOrientation dans Ocean Portail (par exemple, le patient n’a plus besoin du service). Cette fonction est désactivée pour les sites avec une intégration API car elle ajoute de la complexité à la gestion de l’eOrientation dans le système en aval intégré.
  • Si activée, Ocean enverra une notification webhook lorsque l’eOrientation aura été annulée dans le Portail.
Transférer l’eOrientation à un autre site dans Ocean Portail
  • Les eOrientations peuvent être transférées d’un site Ocean à un autre. Par exemple, un site de réception centralisée transférera une eOrientation à un fournisseur de services.
  • Cette fonction est désactivée par défaut (l’option « Transférer » est cachée dans le Menu d'action pour les spécialistes) pour les sites avec une intégration API, car elle ajoute de la complexité à la gestion de l’eOrientation dans le système en aval intégré.
  • Lorsqu’elle est activée, les spécialistes peuvent transférer manuellement l’eOrientation dans Ocean Portail; il n’y a actuellement aucun support API pour le transfert. (Note : Les expéditeurs ne peuvent pas transférer les eOrientations.)
Mettre à jour le résumé du formulaire d’eOrientation
  • La section du résumé du formulaire d’eOrientation contient le contenu du formulaire d’eOrientation qui a été soumis par l’expéditeur.
  • Par défaut, lorsqu’une intégration API est présente, Ocean masque le bouton de modification à côté du résumé du formulaire d’eOrientation pour les expéditeurs, de sorte qu’ils n’ont pas accès à la modification du formulaire sur les eOrientations envoyées à une Listes d'annuaires configurée avec cette intégration.
  • Lorsqu’elle est activée, Ocean enverra des mises à jour du contenu de l’eOrientation via l’API chaque fois que le résumé du formulaire d’eOrientation aura été mis à jour.

Comportement de l’API

Permettre l’envoi d’une copie de l’eOrientation à ce point de terminaison lorsqu’une nouvelle eOrientation est envoyée à partir de ce site

Lorsqu’une eOrientation est envoyée à partir d’un site ayant une intégration API et que le paramètre « Publier une copie de l’eOrientation (toutes les intégrations) et toutes les mises à jour d’état ultérieures (FHIR v0.11 seulement) à ce point de terminaison lorsqu’une nouvelle eOrientation est envoyée à partir de ce site » est activé, Ocean enverra une copie de l’eOrientation au système de l’expéditeur (il s’agit de l’événement de message FHIR notify-add-service-request et de l’événement de message Open API notify-upstream-service-request).

Cela élimine le besoin pour l’expéditeur de copier-coller manuellement ou de télécharger un PDF du résumé de l’eOrientation dans son système.

Les intégrations utilisant FHIR v11 recevront toutes les mises à jour d’état en amont ultérieures (y compris les rendez-vous et les communications) à ce point de terminaison lorsqu’une nouvelle eOrientation est envoyée à partir de ce site.

Utiliser cette intégration pour les Listes d'annuaires créées par API

Cette option applique l’intégration sélectionnée comme point de terminaison par défaut pour les Listes d'annuaires créées à l’aide de l’API HealthcareService. Elle ne s’applique pas aux Listes d'annuaires créées manuellement.

Lorsque les messages d'API échouent : Logique de réessai de l'API Ocean et dépannage

Qu'est-ce que c'est

Alors qu'il existe de nombreux avantages aux API RESTful, un inconvénient est qu'en cas d'appel infructueux, il n'y a par défaut aucun souvenir de la tentative échouée. Pour les intégrations d'API système-système, en particulier dans le domaine de la santé, cela peut être dangereux car cela pourrait entraîner une perte d'informations et des perturbations des processus entre les systèmes.

Pour remédier à ce problème, Ocean dispose d'une capacité de réessai automatisée intégrée pour toutes les intégrations d'API Ocean directes et basées sur FHIR. Ce service Ocean renverra toutes les notifications de webhook qui ne reçoivent pas un code de statut de classe 20X (par exemple 200, 201) une fois par heure pendant jusqu'à quatre jours.

Comment ça fonctionne

Ce service sera exploité à partir du module Ocean Cloud Connect. Cloud Connect gère une file d'attente de toutes les notifications de webhook qui y sont acheminées jusqu'à ce qu'elles réussissent ou expirent.

  • Les appels réussis sont retirés de la file d'attente.
    • Le premier appel d'API infructueux déclenchera une alerte par e-mail contenant le nom de l'intégration et le message d'erreur rencontré par Ocean, qui sera envoyé par e-mail à l'adresse e-mail du 'Administrateur clinique / Contact de support Ocean' spécifiée dans les paramètres du compte du site.
    • Ocean réessayera l'appel à l'endpoint plusieurs fois dans la première heure. En cas d'échec, Ocean réessaiera une fois par heure.
    • Toutes les 24 heures, Ocean enverra une alerte par e-mail au 'Administrateur clinique / Contact de support Ocean' pour les informer que les problèmes ne sont toujours pas résolus.
    • Si l'événement d'API en échec est envoyé avec succès pendant la période de réessai, les alertes par e-mail quotidiennes cesseront.
    • Au bout de 96 heures, Ocean abandonnera les tentatives de joindre l'endpoint. Cependant, Ocean continuera d'envoyer des e-mails quotidiens au 'Administrateur clinique / Contact de support Ocean' tant que l'intégration n'aura pas envoyé un événement réussi.
    • Une fois que l'intégration reçoit et accepte un message réussi d'Ocean, ou si les paramètres d'intégration sont sauvegardés à nouveau dans Ocean après la fin des tentatives de réessai, les notifications par e-mail quotidiennes cesseront.

Ce que vous devez faire

  • Assurez-vous que l'adresse électronique (ou les adresses électroniques) de la ou des personnes les plus responsables de l'intégration est/sont incluses dans le champ 'Administrateur clinique / Personne-ressource de soutien Ocean' du site Ocean. Il peut s'agir du gestionnaire informatique de la clinique et/ou du point de contact du fournisseur; ils n'ont pas besoin d'être un utilisateur sur le site Ocean.
    • Plusieurs adresses électroniques peuvent être spécifiées dans le champ - il suffit de séparer chaque adresse électronique par une virgule.
  • Lorsqu'une alerte par courriel est reçue de la part d'Ocean, cela indique généralement un problème avec le point de terminaison du système récepteur, pas avec Ocean. La première étape à suivre est d'examiner la santé du point de terminaison du système récepteur avant de contacter l'équipe de soutien d'OceanMD.
  • Les problèmes courants rencontrés comprennent:
    • Certificats expirés.
    • Temps d'arrêt du système non planifié.
    • Le point de terminaison du système récepteur ne sait pas comment traiter le message qu'il a reçu.
  • Si de l'aide est nécessaire ou s'il semble s'agir d'un problème lié à Ocean, veuillez soumettre un rapport d'incident à l'équipe de soutien OceanMD. Dans votre rapport, assurez-vous d'inclure:
    • Numéro du site Ocean
    • Environnement Ocean (par exemple, test.cognisantmd.com, staging.cognisantmd.com ou ocean.cognisantmd.com)
    • Une description de l'enquête effectuée jusqu'à présent pour évaluer tout problème avec le point de terminaison récepteur.
    • Une capture d'écran complète de l'alerte par courriel Ocean incluant la date et l'heure de réception du courriel.

Guide de configuration de l'intégration de l'engagement du Patient FHIR

Des outils d'engagement des patients tels que la réservation en ligne, la messagerie aux patients, les rappels aux patients, les formulaires de site Web, l'utilisation de bornes et de tablettes, y compris les complétions de formulaires, peuvent être intégrés à votre DMÉ en utilisant l'intégration de l'API FHIR.

Prérequis pour l'intégration

Configuration de l'intégration de l'engagement des patients avec Ocean

Ces étapes comprennent les étapes préliminaires requises pour configurer votre site Ocean pour l'intégration de l'engagement des patients avec un DMÉ.

  1. Compléter l'enquête d'inscription des nouveaux intégrateurs
  2. Envoyer un courriel à l'assistance Ocean avec le domaine de courriel que vous utiliserez lors du développement technique et des tests (par exemple, pour enregistrer de nouveaux utilisateurs, vous connecter au portail Ocean, etc.).
  3. Une fois qu'Ocean confirme que l'Étape 2 est complète, créer un compte utilisateur Ocean et un site sur test.cognisantmd.com
  4. Générer la Clé de chiffrement partagée (SEK) du site
  5. Dans le Menu, sélectionner Admin puis sélectionner Fonctionnalités du site. Activer l'option 'Activer Ocean Cloud Connect'. Cela déclenchera une boîte de dialogue vous indiquant de configurer Cloud Connect. Sélectionner le bouton 'Aller à Cloud Connect'.
  6. Dans Cloud Connect, sélectionner 'Intégrer mon DMÉ'. Entrer la SEK du site et sélectionner 'Sauvegarder et continuer'
  7. Sélectionner 'DMÉ basé sur FHIR' comme type de DMÉ avec lequel vous intégrez
  8. Entrer vos identifiants de DMÉ basé sur FHIR - Cette étape a des prérequis qui sont décrits dans la section des Exigences de haut niveau
  9. Une fois les exigences complétées, sélectionner 'Se connecter au DMÉ FHIR'. Si réussi, un message "Vous vous êtes authentifié avec succès auprès d'un DMÉ FHIR!" apparaîtra, 'Sauvegarder et continuer'
  10. Configurer vos paramètres Cloud Connect en spécifiant (1) combien de jours de calendrier synchroniser, (2) quels fournisseurs synchroniser, et (3) toute configuration de fournisseur sans rendez-vous (Ces configurations sont expliquées dans cet article). Cliquer sur 'Sauvegarder'. 
  11. La configuration de Cloud Connect est maintenant terminée. 
  12. Connectez-vous à votre Portail Ocean en utilisant vos identifiants de compte utilisateur Ocean
  13. Ouvrir le 'Menu' dans le coin supérieur gauche et cliquer sur 'Admin', accéder à 'Fonctionnalités du site' sous Fonctionnalités supplémentaires
  14. Activer la case à cocher 'Activer Ocean Cloud Connect' si ce n'est pas déjà activé. 

Vous avez maintenant configuré avec succès votre Portail Ocean pour l'intégration de l'engagement des patients!

 

Aperçu du lancement de l'application Ocean SMART (Lancement contextuel SMART sur FHIR de DSÉ)

Introduction

Ocean utilise la norme de l'industrie Lancement d'application SMART pour prendre en charge la connexion unique (SSO) et le lancement contextuel du patient à partir d'un dossier de santé électronique (DSÉ) ou d'un autre système de santé.

Authentification unique
  • Le cadre de lancement SMART permet à une personne authentifiée utilisant un système de santé tiers de confiance d'ouvrir une application ou une page spécifique dans Ocean sans avoir à se connecter manuellement à Ocean. Au lieu de cela, les informations d'identification de l'EHR de l'utilisateur peuvent être utilisées pour se connecter de manière sécurisée et automatique en tant qu'utilisateur Ocean correspondant.
  • Ocean respecte la norme Open ID Connect pour garantir que ce processus d'authentification unique est sécurisé.
Exigences

Pour se connecter à Ocean, les systèmes de lancement doivent :

  • Mettre en œuvre et prendre en charge la séquence de lancement SMART "EHR" en tant que "Serveur FHIR de DSÉ / Serveur d'autorisation de DSÉ" (Ocean est l'« Application » dans ce contexte).
  • Fournir des points de terminaison OAuth 2.0 pour le lancement SMART.
  • Respecter le protocole Open ID Connect en tant que système de lancement dans le cadre du protocole :
    • Fournir un accès public au point de terminaison : [le-serveur-fhir]/.well-known/openid-configuration.
      • (Ocean accède à ce point de terminaison dans le cadre du protocole Open ID, pour s'assurer qu'il peut valider la signature JWT du lanceur à l'aide de la clé publique spécifiée dans la "jwks_uri" de la configuration).
    • Signer le jeton JWT avec l'algorithme ES256 ou RS256.
  • Être capable de lancer un navigateur web moderne (intégré ou via un lien d'application de bureau).
    • Le navigateur web doit prendre en charge l'utilisation par Ocean des cookies de session HTTPS typiques et de localStorage pour les URL suivantes :
  • S'assurer que les utilisateurs du système ont accès à au moins une URL de lancement configurable pour Ocean. Ces URL doivent pouvoir accueillir des noms de chemin variables en fonction de facteurs tels que le site Ocean, l'action Ocean prévue et d'autres paramètres pertinents.
    • Une liste complète des paramètres d'« action » pour le lancement SMART dans Ocean peut être trouvée dans l'article Guide de mise en œuvre SMART on FHIR.
    • Des exemples d'URL de lancement SMART dans Ocean incluent :
      • Visualisation du patient dans la carte de santé d'Ocean - https://ocean.cognisantmd.com/sso/smart/auth?siteNum=1234&action=viewMap
      • Ouverture du "Tableau de bord du patient Ocean" - https://ocean.cognisantmd.com/sso/smart/auth?siteNum=2000&action=dashboard

Les systèmes doivent également :

  • Fournir la valeur encodée en Base64 de la Clé de Chiffrement Partagée du site Ocean en tant que valeur pour un attribut "oceanSharedEncryptionKey" dans le jeton d'accès au lancement SMART.
    • Ce paramètre élimine le besoin pour les utilisateurs d'entrer manuellement la Clé de Chiffrement Partagée de leur site dans leur navigateur web pour chaque lancement contextuel. Bien qu'il puisse être omis si une clinique préconfigure les navigateurs web des utilisateurs en stockant la Clé de Chiffrement Partagée dans le "localStorage" du navigateur, il est généralement obligatoire. Les navigateurs basés à l'hôpital ne conservent souvent pas le localStorage à travers les sessions utilisateur en raison de considérations de confidentialité.
    • Plus d'informations sur les fournisseurs de lancement SMART sont fournies ici
Lancement contextuel du patient
  • En plus de la SSO, le lancement SMART peut facultativement transmettre des informations à Ocean qui sont liées au patient actuellement sélectionné dans le DSÉ. Les informations sur le patient comprennent le numéro MRN du DSÉ, le nom, le numéro d'assurance maladie, le sexe, la date de naissance, les coordonnées et d'autres informations cliniques disponibles.
  • Ocean lit ces informations sur le patient, avec l'autorisation du DSÉ, en demandant des "scopes" pour lire les données des points de terminaison FHIR du DSÉ.
  • Certains cas d'utilisation pour le lancement contextuel du patient comprennent :
    • Ouvrir le "Tableau de bord du patient d'Ocean" pour voir un résumé des informations d'Ocean liées à ce patient, y compris les eRéférences actives, les eConseils, les résultats de questionnaires, etc. Le tableau de bord sert également de point de lancement pratique pour effectuer d'autres actions, telles que l'initiation d'une référence.
    • Visualiser le patient dans la Carte de santé d'Ocean.
    • Créer une nouvelle eRéférence préremplie avec les informations démographiques et cliniques du patient basées sur le dossier du DSÉ.
    • Utiliser Ocean pour envoyer un lien de message sécurisé ou un questionnaire directement à partir du dossier du DSÉ.
Exigences d'intégration pour le lancement contextuel du patient dans les systèmes Ocean

De plus, pour prendre en charge le lancement contextuel du patient, les systèmes doivent respecter les exigences suivantes :

  • Prise en charge de FHIR R4 pour le point de terminaison Patient.read :
    • L'intégration doit inclure la prise en charge du point de terminaison Patient.read dans le contexte de lancement de l'application SMART, en suivant les normes FHIR R4.
  • Inclure le paramètre "patient" dans le jeton d'accès au lancement SMART :
    • Assurer la fourniture d'un paramètre "patient" dans le jeton d'accès au lancement SMART pour permettre des lancements contextuels du patient sans heurts.
  • Respect des conventions FHIR pour le stockage des RPS :
    • Respecter les conventions FHIR établies pour le stockage des RPS pertinents utilisés par Ocean. Cela inclut l'utilisation de l'identificateur de numéro d'assurance maladie "JHN" et de l'identificateur de code de version pour les patients de l'Ontario.
  • Facultatif : Prise en charge de l'opération FHIR R4 /Patient/[id]/$everything :
    • Prendre éventuellement en charge l'opération FHIR R4 /[/Patient/[id]/$everything pour préremplir les médicaments, les allergies, les antécédents médicaux et les pièces jointes du dossier.
Séquence d'événements pour les utilisateurs
    1. Un utilisateur est connecté au système DSÉ.
    2. L'utilisateur clique sur un bouton de lancement "Ocean" dans l'interface utilisateur du DSÉ.
    3. Le bouton de lancement ouvre Ocean dans un nouvel onglet ou une nouvelle fenêtre du navigateur web. Le lanceur fournit à Ocean une URL contenant les informations de base de lancement (basées sur le protocole SMART).
    4. Ensuite, en arrière-plan :
      • Ocean utilise les informations de lancement pour demander des informations d'authentification au DSÉ en utilisant le protocole OAuth 2.0.
      • En réponse, le DSÉ fournit à Ocean un jeton d'accès, qui fournit à Ocean des informations de base concernant l'utilisateur actuel du DSÉ et le patient actuel.
      • Ocean vérifie si l'utilisateur du DSÉ a déjà été lié à un compte Ocean.
    5. Si l'utilisateur n'a pas encore lié son compte DSÉ à Ocean, une invite de connexion s'affiche :
    6. Une fois le compte lié, à partir de ce moment-là, la connexion unique est automatique.
    7. Ensuite, si un patient a été spécifié, Ocean demande au DSÉ des informations sur le patient actuel (en utilisant les API FHIR du DSÉ).
    8. Enfin, Ocean redirige vers la page demandée dans Ocean. Cette page peut être soit une destination spécifique au patient, comme le tableau de bord patient Ocean, soit une destination générale comme le Portail Ocean, en fonction de l'"action" demandée par l'URL de lancement du bouton de lancement SMART.

Le diagramme de séquence ci-dessous illustre les interactions en arrière-plan entre les systèmes qui se produisent pour permettre la connexion unique et le lancement contextuel SMART d'Ocean (un fichier PDF est disponible en bas de cet article).

Autorisation

Pour des raisons de sécurité, tous les serveurs du système de santé qui souhaitent utiliser un lancement SMART dans Ocean doivent être privément autorisés par les administrateurs d'OceanMD.

Veuillez envoyer les valeurs suivantes à l'adresse e-mail de support d'Ocean 'support@oceanmd.com' afin que nous puissions créer l'entrée d'autorisation pour votre système de lancement :

  1. L'URL du serveur :
    • Fournie en tant que paramètre "iss" initial lors du lancement SMART. Cette valeur doit également correspondre au serveur API FHIR.
  2. ID client :
    • L'ID client unique et imprévisible pour Ocean, tel qu'assigné aléatoirement par le serveur de lancement. (Il s'agit du paramètre d'URL fourni par Ocean lors de la redirection SMART initiale vers le point de terminaison d'autorisation du lanceur.)
  3. Point de terminaison d'autorisation :
    • Le point de terminaison "/authorize" OAuth 2.0.
  4. Point de terminaison de jeton :
    • Le point de terminaison "/token" OAuth 2.0.
  5. URL de l'émetteur de jeton :
    • La valeur "iss" fournie dans l'ensemble de revendications JWT signé, dans la valeur id_token du jeton d'autorisation.
  6. L'URL et le corps de réponse pour le ".../.well-known/smart-configuration" accessible publiquement (si pris en charge).
  7. L'URL et le corps de réponse pour le ".../.well-known/openid-configuration" accessible publiquement.

À l'exception de l'ID client, toutes ces valeurs devraient être disponibles dans le point de terminaison .well-known/openid-configuration du serveur DSÉ et/ou le point de terminaison de métadonnées FHIR.

Pour des raisons de sécurité, Ocean effectue une validation stricte du jeton JWT pour respecter les précautions de l'Open ID Connect. (Si un aspect quelconque du jeton JWT ne passe pas le protocole, Ocean tente de fournir un message d'erreur utile pour le dépannage.)

Guide de mise en œuvre de SMART on FHIR

Information utile sur la mise en œuvre de SMART avec Ocean

Cette vidéo offre un aperçu de la manière dont HL7 SMART on FHIR peut être utilisé pour se lancer dans Ocean, ainsi que des conseils pour commencer une implémentation sur un serveur SMART. Cet article accélérera davantage vos activités de mise en œuvre en partageant des conseils et des considérations recueillis auprès d'autres implémenteurs. Il est divisé en sections suivantes :

  • Considérations de configuration - Éléments importants à prendre en compte pour préparer la 'poignée de main' entre les systèmes.
  • Plongée plus profonde dans le flux de séquence - Détails supplémentaires sur les données échangées entre les systèmes et comment elles sont utilisées.
  • Conseils pour l'opération $everything - Détail des avantages de la nouvelle opération /Patient/[id]/$everything et conseils pour les configurations d'intégration du lancement SMART.
  • Contexte FHIR - Informations supplémentaires sur le contexte FHIR avec le lancement SMART.
  • Réception automatique d'une copie de la référence - Utilisation des API et des configurations Ocean pour recevoir automatiquement une copie de la référence qui vient d'être envoyée depuis le lancement SMART.
  • Partage de l'identifiant de référence POS avec Ocean - Détails concernant l'identifiant de référence interne du serveur POS/FHIR et comment Ocean peut le renvoyer au système POS.
  • Paramètres d''action' de lancement SMART - Liste de tous les paramètres d''action' pour le lancement SMART dans Ocean.

Cet article de support sera 'vivant' à mesure que des conseils supplémentaires seront recueillis. Il est recommandé de le 'suivre' afin de recevoir une notification lorsqu'il est mis à jour.

Définitions utilisées dans cet article

  • Demandeur - l'individu (fournisseur ou patient) qui soumet une demande de référence.
  • Fournisseur de services - le service/l'organisation/fournisseur clinique ou communautaire qui reçoit une demande de référence pour fournir un service au patient.
  • Point de service (POS) - le système de gestion des dossiers des patients utilisé par le demandeur (par ex. DMÉ, DME, système de gestion de cas, CRM).
  • Serveur SMART - le composant logiciel utilisé par le POS pour permettre le lancement contextuel dans Ocean.
  • Authentification unique (SSO) - la capacité d'accéder à son compte utilisateur Ocean sans avoir à saisir manuellement son nom d'utilisateur et son mot de passe.
  • Lancement contextuel - la capacité d'accéder à Ocean en utilisant SSO, ainsi que d'avoir le patient qui est 'en contexte' dans le POS être 'mis en contexte' dans Ocean sans que le fournisseur ait à rechercher manuellement ce patient et/ou à saisir les données de ce patient.
  • ID client - un identificateur émis par le serveur SMART à Ocean pour le reconnaître en tant qu'application SMART.
  • ID site - l'identificateur d'Ocean pour le site configuré par le fournisseur de services dans Ocean pour envoyer et/ou recevoir (et gérer) des eRéférences.

Liste de vérification de configuration

  • Fournir à l'équipe Ocean les points de terminaison du serveur SMART afin qu'ils puissent être ajoutés à la liste blanche Ocean (voir la section Liste blanche ici).
  • L'identifiant du client (utilisé aux étapes 3, 4, 11) est fourni par le serveur SMART à Ocean lors de la configuration de l'intégration. Ocean le stocke et le renvoie lors de son lancement.
    • Ocean a seulement besoin d'un identifiant de client par URL de serveur SMART. Le même identifiant de client peut être utilisé pour plusieurs organisations avec des sites Ocean, tant qu'ils sont hébergés dans le même environnement (par exemple, un système de point de vente SaaS).
  • S'assurer que le cadre de développement permet la personnalisation du jeton d'accès et des jetons d'identifiant. Certains cadres, tels que Javaspring et .NET, permettent de contrôler les flux, mais d'autres sont moins personnalisables.

Approfondissement de la séquence de flux

  • L'identifiant du patient (étapes 8, 9, 15, 16) est l'identificateur utilisé pour identifier de manière unique le patient dans le point de vente. Il n'est pas nécessaire de suivre un format d'identifiant prescrit (par exemple, le GUID à l'étape 16 est un exemple).
    • Ocean utilise uniquement l'identifiant du patient comme clé au point de terminaison FHIR Patient.read pour récupérer la ressource Patient.
  • Idéalement, la ressource Patient.read du point de vente/serveur SMART fournira toutes les données requises pour pré-remplir la section Information du patient de l'eRéférence Ocean. Cependant, Ocean ne rejettera pas une ressource Patient peu renseignée ; il exploitera les données disponibles (et le demandeur de la référence devra remplir manuellement les champs manquants).
  • À l'inverse, Ocean ignorera toute donnée démographique supplémentaire reçue dans la ressource Patient qui n'est pas nécessaire pour compléter la section Information du patient de l'eRéférence.
  • Le champ sub dans la charge utile du jeton d'identifiant JWT (étape 9) contient l'identifiant unique du point de vente/serveur SMART pour l'utilisateur. Ocean effectuera une recherche basée sur les champs démographiques dans le jeton d'identifiant pour identifier un utilisateur Ocean correspondant, puis stockera un lien dans le compte Ocean de l'utilisateur vers l'ID utilisateur du point de vente pour permettre la connexion unique.
  • Le lien ID utilisateur du point de vente-ID utilisateur Ocean n'est pas affecté si l'utilisateur modifie son mot de passe du point de vente ou toute autre donnée démographique autre que l'ID utilisateur lui-même.
  • Ocean ne peut être lancé que via SMART dans un nouvel onglet de navigateur ; il ne se lancera pas dans un iFrame.

Conseils pour l'opération $everything

  • Ocean analyse tous les pièces jointes qu'il reçoit via le point de terminaison $everything.
  • L'opération /Patient/[id]/$everything est une nouvelle alternative au point de terminaison Patient.read. Elle fournit à Ocean des informations supplémentaires importantes pour le lancement contextuel.
  • Les implémenteurs peuvent configurer dans leur intégration de lancement SMART si Ocean doit utiliser Patient.read ou l'opération plus complète $everything lors du lancement contextuel.
  • En particulier, l'opération $everything permet à Ocean de lire les informations du patient suivantes dans le but de pré-remplir les formulaires Ocean :
    • Médicaments
    • Allergies
      • Liste des problèmes
    • Antécédents médicaux passés
    • Antécédents médicaux de sa famille
    • Pièces jointes du dossier (présélectionnées)
    • Observations/Vitales/Valeurs de laboratoire
    • Immunisations
  • Ocean traitera les ressources FHIR suivantes lorsqu'elles sont incluses dans le bundle $everything :
    • Déclaration de médication
    • Intolérance aux allergies
    • Conditions (pour les vitales et les valeurs de laboratoire)
    • Rendez-vous
    • Observation
    • Référence de document (pour les pièces jointes du dossier pré-sélectionnées)
    • Immunisation
  • Veuillez consulter ce guide pour des informations supplémentaires.

Spécification des valeurs de NIP et d'assurance maladie à pré-remplir

  • Dans un scénario où la ressource Patient a plusieurs propriétés d'identificateur correspondant à différents numéros de dossier médical (NIP), Ocean a introduit un paramètre de requête de lancement SMART pour indiquer à Ocean quelle valeur de NIP pré-remplir :
    • mrnText correspond au Identifier.type.text que Ocean recherchera pour obtenir la valeur de NIP correspondante.
  • De même, les serveurs SMART utilisent différents systèmes pour spécifier l'identificateur correspondant au numéro de carte d'assurance maladie (NAM). Afin d'indiquer à Ocean quel identificateur utiliser pour pré-remplir le champ NAM Ocean :
    • jhnSystem équivaut à la valeur du système de la propriété d'identificateur que Ocean recherchera pour obtenir la valeur de NAM correspondante. Par exemple, les sites Epic ajouteraient ce qui suit à leur chaîne de lancement : &jhnSystem=https%3A%2F%2Fopen%2Eepic%2Ecom%2FFHIR%2FStructureDefinition%2FPayerMemberId
  • Ocean effectuera une correspondance exacte (en excluant les "guillemets") et reviendra à la valeur par défaut si aucune correspondance n'est trouvée. Les caractères spéciaux peuvent être encodés.

Contexte FHIR

  • Lors de l'initiation d'un lancement SMART pour une demande de service (par exemple, eRéférence, eCommande ou eConseil), les implémenteurs peuvent inclure l'identifiant de l'enregistrement de demande de service préliminaire de leur système de lancement dans le fhirContext SMART.
  • Si fourni, Ocean stocke cet identifiant avec la demande de service et l'inclut dans la liste des identifiants pour les messages FHIR ultérieurs liés à la demande de service.
  • Cette fonctionnalité facilite le lien entre l'enregistrement de demande de service préliminaire dans le DSÉ (communément appelé "référence ou consultation en attente") et la messagerie FHIR en backend de la demande de service.
  • Le fhirContext est inclus dans le jeton de réponse, aux côtés de l'access_token.
  • Il doit faire partie du JSON du jeton, formaté comme un tableau, comme ceci : [{"reference": "ServiceRequest/{serviceRequestId}"}].
  • Pour plus d'informations sur le contexte FHIR, consultez l'article officiel sur les scopes et le contexte de lancement SMART.
  • Exemple d'un jeton de contexte de lancement 
    {
  "access_token": "{access_token à utiliser pour les appels API FHIR ultérieurs}",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "{refresh_token ; ignoré par Ocean}",
  "scope": "{scopes accordés ; devrait généralement correspondre à la demande ",
  "patient": "{identifiant du patient, ou omis s'il n'y a pas de patient dans le contexte}",
  "encounter": "{identifiant de l'interaction, ignoré par Ocean}"
  "id_token": {
    %% JWT valide signé avec des valeurs encodées compatibles OIDC 
    "sub": "{uuid de l'utilisateur}",
    "iss": "{URL de l'émetteur du jeton}",
    "aud": "{client_id}",
    "exp": {date/heure d'expiration par exemple, 1679028255},
    "iat": {date/heure d'émission par exemple, 1679024655},
    "nonce": "{GUID de nonce ; facultatif ; doit correspondre à celui d'Ocean s'il est fourni}"
  },
  "intent": "action={oceanAction}&resource={oceanResource}", %% facultatif
  "tenant": "UUID opaque de l'organisation ; ignoré par Ocean", %% facultatif
  "fhirContext": "[{"reference": "ServiceRequest/{serviceRequestId}"}]"
}

Le diagramme de séquence ci-dessous illustre les interactions en backend entre les systèmes qui se produisent pour permettre la connexion unique SMART d'Ocean et le lancement contextuel. (un fichier PDF est disponible en bas de cet article).

Recevoir une copie de la référence automatiquement

  • Le demandeur peut vouloir une copie de la référence dans le dossier du patient dans le DSÉ. Ce processus de copie peut être effectué manuellement en copiant et collant depuis Ocean.
  • Alternativement, l'automatisation est possible si le système serveur POS/SMART implémente soit l'API FHIR eRéférence d'Ocean pour recevoir de nouvelles eRéférences, soit l'API Open eRéférence d'Ocean pour récupérer des eRéférences. Dans ce cas, Ocean enverra une notification webhook au point de terminaison spécifié, avec un événement de message FHIR de notify-add-service-request (pour l'API FHIR eRéférence) ou notify-upstream-service-request (pour l'API Open).

Partager l'identifiant de la référence POS avec Ocean

  • Il est possible d'envoyer à Ocean l'identifiant de référence interne du serveur POS/FHIR afin qu'il puisse être inclus dans la charge utile de l'eRéférence FHIR renvoyée par Ocean. Ceci est utile pour les systèmes POS qui créent une référence interne avant de se lancer dans Ocean et qui souhaitent fusionner la charge utile avec cette référence interne.
  • L'identifiant de référence interne peut être envoyé dans le paramètre fhirContext de l'access token pour transmettre la référence de substitution du lanceur SMART (par exemple [{reference: “ServiceRequest/123”}]).  Ocean utilisera l'URL iss initiale du serveur fournie par le DMÉ au lancement et la combinera avec le fhirContext.
    En concaténant les deux valeurs ci-dessus, cela produira un URI globalement unique pour ServiceRequest.identifier.value = https://chr.telus.com/fhir/ServiceRequest/123
  • En plus de l'identifiant de référence d'Ocean, cet identifiant de référence POS apparaîtra dans la propriété d'identifiant de ServiceRequest avec la valeur ServiceRequest.identifier.system = urn:ietf:rfc:3986

Paramètres d'Action de Lancement SMART / Intention FHIR

Le tableau ci-dessous décrit la liste de tous les paramètres d'Action pour le lancement SMART dans Ocean.

Paramètre action Paramètre resource (si utilisé) Description
viewMap S.O. Lance l'utilisateur dans Healthmap Ocean
viewHealthServices La Catégorie de Service de Santé pertinente (par ex. SERVICES DE CARDIOLOGIE) Lance l'utilisateur dans Healthmap Ocean filtré pour un service de santé spécifique
searchHealthMap Un mot-clé ou une phrase de recherche simple (par ex. "pression artérielle"). Les caractères non alphanumériques doivent être encodés en URL (par ex. avec un "%20" à la place d'un espace). Lance l'utilisateur dans Healthmap Ocean et effectue une recherche pour le mot-clé pertinent
referDirect La valeur de référence de l'inscription dans l'annuaire Lance l'utilisateur directement dans Healthmap Ocean à l'inscription dans l'annuaire spécifiée comme la 'resource'
portal S.O. Lance l'utilisateur dans le Portail Ocean
sendMessage Optionnel - L'identificateur du modèle de message Initie un nouveau message au patient avec le modèle de message spécifié ou celui par défaut s'il n'y en a pas de spécifié
addForm S.O. Permet à l'utilisateur de rechercher et mettre en file d'attente des eFormulaires Ocean pour que le patient les complète
viewServiceRequest La valeur de référence pour la demande de service pertinente (eRéférence/eConseil/eCommande) Lance l'utilisateur directement dans une demande de service spécifique.
viewReferralFavourite L'identificateur de l'élément favori. Lance l'utilisateur directement dans une référence pour l'Offre de l'inscription dans l'annuaire dans la liste des favoris spécifiée comme la 'resource'
debug S.O. Reste sur la page de lancement à des fins de dépannage. Peut également être de la forme debug:[action] (comme debug:addForm) pour des informations plus spécifiques.
[vide] S.O.

Lorsque le paramètre Action est laissé vide ou omis, l'utilisateur est lancé dans la Vue Résumé du Patient pour le patient DMÉ actuel par défaut.

Si aucun patient n'est fourni dans le contexte de lancement, l'utilisateur est simplement redirigé vers le Portail Ocean.

Guide de mise en œuvre de l’API Open eOrientation

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.   

 

Ocean_eForm_Completion_API_sequence-eReferral__1_.png

 

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. 

Ouvrir le guide de mise en œuvre de l'API d'engagement des patients

 

Les API ouvertes d'Ocean permettent aux systèmes tiers de s'intégrer à Ocean afin que les fournisseurs puissent envoyer des eFormulaires Ocean aux patients et que les eFormulaires complétés soient automatiquement téléchargés dans leur système ou application préférés. En plus de la documentation des API ouvertes, nous avons rassemblé les conseils d'implémentation suivants pour accélérer votre intégration.

 

Séquence d'intégration des eFormulaires d'engagement des patients

Le diagramme de séquence ci-dessous illustre la séquence d'interaction entre Ocean et un système tiers pour générer des liens web spécifiques aux patients pouvant être intégrés dans le service de messagerie sécurisé du système tiers. Le patient accédera au lien web pour compléter les eFormulaires Ocean, après quoi Ocean notifiera le système tiers pour collecter les formulaires complétés.

 

Ocean_eForm_Completion_API_sequence.jpg