Brugerdefinerede integrationer er en funktion i Provet Cloud, der gør det muligt at sende anmodninger til eksterne ressourcer inde fra Provet Cloud. Kontakt Provet Clouds support for at få adgang til funktionerne.
Brugerdefinerede integrationer administreres i Indstillinger → Integrationer → Brugerdefinerede integrationer.
Brug den blå knap '+Add' for at tilføje en integration; brug den hvide penneknap på tabelrækken for at redigere en integration.
-
Navn - Angiver etiketten på den knap, der er synlig i brugergrænsefladen.
-
Synlig side - Angiver, hvilken side knappen skal være synlig på. Hver brugerdefineret integration kan kun være synlig på én side, men den samme konfiguration kan duplikeres til flere brugerdefinerede integrationer.
-
Handling - Angiver, hvilken handling der skal udføres, når der klikkes på knappen.
-
Send HTTP-anmodning - En anmodning planlægges i baggrunden og sendes ved hjælp af Provet Clouds servere. Brugerne vil ikke se websiden, men kan se en meddelelse, når afsendelsen skrider frem. Anmodningen kommer fra Provet Clouds udgående IP-adresser, så modtagersiden skal være åben for anmodninger udefra.
-
Åbn i nyt vindue - Mål-URL'en åbnes i et nyt vindue/browserfane.
-
Åbn i sidepanel - Mål-URL'en indlejres i Provet Cloud ved at åbne et sidepanel oven på sideindholdet og vise siden som en iframe. Mål-URL'en skal understøtte indlejring (dvs.
X-Frame-Optionsheaderen skal være indstillet korrekt).
-
-
HTTP-metode - Angiver, om anmodningen skal sendes som en GET-anmodning, hvor nyttelasten leveres som parametre i forespørgselsstrengen, eller som en POST-anmodning, hvor nyttelasten leveres som formulardata.
-
URL - Mål-URL'en, komplet med skema.
-
Parameternavn - Navnet på den parameter, der bruges til at angive det aktuelle objekts ID.
-
Enabled - Giver mulighed for at aktivere og deaktivere en brugerdefineret integration. Brugerdefinerede integrationer kan også slettes, hvis der ikke længere er brug for dem.
-
Tilføj verifikationshash - Aktiverer en verifikationshash i payloaden, som kan bruges til at verificere, at anmodningen kommer fra den tilpassede integration.
-
Verifikationssalt - En delt hemmelighed, der bruges til at beregne verifikationshash, kun påkrævet, når verifikationshash er aktiveret.
Det er muligt at tilføje et brugerdefineret præfiks til parameterværdien ved at angive parameternavnet på en anden måde. Normalt vil en angivelse af parameternavnet som "id" resultere i en anmodning som https://example.com/?id=1. Men hvis der kræves et brugerdefineret præfiks foran den faktiske ID-værdi, kan parameternavnet f.eks. defineres som "id=client_", hvilket vil sende en anmodning https://example.com/?id=client_1.
Baggrundsanmodninger ('Send HTTP-anmodning') kan også få vilkårlige, statiske værdier, som tilføjes til anmodningerne, når de sendes. Dette kan f.eks. bruges til at inkludere Authorisation-headers i anmodninger.
Denne funktion er ikke implementeret for forgrundsanmodninger ('Åbn i et nyt vindue', 'Åbn i sidepanel'). Sendte overskrifter logges heller ikke.
Anmodninger, der sendes i baggrunden ('Send HTTP-anmodning'), registreres i en intern log til verifikations- og revisionsformål. Dette giver administratorer mulighed for at kontrollere, hvilken slags anmodninger der blev sendt af hvem og på hvilket tidspunkt, og inspicere den slags svar, som den tilpassede integration sendte tilbage.
Loggen over brugerdefinerede integrationer kan ses under Indstillinger → Integrationer → Brugerdefinerede integrationer → Log.
Logvisningen viser alle anmodninger, der er foretaget, begyndende med den seneste anmodning. Grundlæggende oplysninger om anmodningerne vises på listen, og man kan få adgang til flere oplysninger i detailvisningen ved at klikke på øjenknappen i højre side af hver række.
Der foretages ikke logning af forgrundsanmodninger ("Åbn i et nyt vindue", "Åbn i sidepanel"), da det er browseren, der står for disse anmodninger.
Når de er tilføjet, vil brugerdefinerede integrationer blive vist som knapper på deres målsider. Brugerdefinerede integrationsknapper kan let skelnes fra Provet Clouds knapper på grund af deres unikke brune udseende.
Hvis der kun er opsat én brugerdefineret integration på en side, vil den blive gengivet som en almindelig knap med navnet på den brugerdefinerede integration som etiket. Se den brune knap "Udløs brugerdefineret integration" på billedet nedenfor (klientsiden).
Hvis en side har flere brugerdefinerede integrationer knyttet til sig, vil de brugerdefinerede integrationer i stedet blive gengivet som en dropdown-menu, der igen bruger det samme brune udseende til at skelne dem fra hinanden. Menuindgangene bruger navnet på den brugerdefinerede integration som etiket, ligesom de enkelte knapper. Se billedet nedenfor for en illustration.
Brugerdefinerede integrationer sender ikke detaljerede oplysninger om den aktuelt synlige side. I stedet sender de kun det relevante objekt-ID (klient-ID, patient-ID, faktura-ID osv.), som kan forespørges fra Provet Cloud REST API, ligesom webhooks fungerer.
Brugerdefinerede integrationer indeholder ikke automatisk oplysninger om, hvilken side de er registreret på. Brugere skal enten bruge forskellige URL-slutpunkter til forskellige sider (for eksempel integration.com/client/ til brugerdefineret integration af klientsiden og integration.com/patient/ til brugerdefineret integration af patientsiden), eller hvis det ikke er muligt, forskellige parameternavne (for eksempel patient_id til integration af patientsiden og client_id til integration af klientsiden, hvis begge bruger den samme URL) og derefter skelne på integrationssiden efter, hvilken parameter der er inkluderet i anmodningen. Til baggrundsforespørgsler kan der også bruges brugerdefinerede overskrifter.
Der er heller ingen henvisning til det aktive Provet-id. Hvis du bygger en integration, der deles mellem flere Provet Cloud-instanser, anbefales det at tilføje endpoints for hvert Provet ID (for eksempel integration.com/1234/client/ og integration.com/4321/client/, hvis integrationen skal bruges af både Provet Cloud-instans 1234 og 4321). I dette tilfælde anbefales det også at bruge verifikationshashes for at sikre, at data kommer fra den rigtige instans, selv hvis der er en fejlkonfiguration med en brugerdefineret integrations-URL. Til baggrundsanmodninger kan der også bruges brugerdefinerede headere.
Hvis en brugerdefineret integration er defineret som en "Send HTTP-anmodning"-handling, vil et klik på knappen for brugerdefineret integration planlægge en anmodning, der skal sendes i baggrunden ved hjælp af Provet Clouds arbejdsservere. Afsendelsen sker asynkront, og selvom anmodningen normalt sendes stort set med det samme, kan der være en forsinkelse afhængigt af, hvor meget arbejde der er på serverne i øjeblikket. Anmodningen kommer fra Provet Clouds udgående IP-adresser.
Når anmodningen er ved at blive planlagt, vil brugeren se en informationsmeddelelse øverst på siden.
Hvis anmodningen bliver håndteret og afsluttet, uden at brugeren navigerer væk fra siden, kan de få vist en ekstra meddelelse, når de har afsluttet opgaven.
En succesmeddelelse vises, hvis anmodningen er sendt med succes, og integrationen svarer med en succesfuld HTTP-statuskode (mellem 200 og 299 inklusive).
Men hvis anmodningen af en eller anden grund mislykkes, vises en rød fejlmeddelelse med teksten "Integrationsanmodning mislykkedes" og en mere specifik fejlmeddelelse i parentes.
Mulige fejlmeddelelser i øjeblikket er:
-
Backend-fejl - Der opstod en ukendt fejl på Provet Clouds arbejdsservere, da anmodningen blev sendt. Dette kan være en fejl i Provet Clouds servere. Kontakt Provet Clouds support for at få yderligere oplysninger.
-
Forbindelsesfejl - Anmodningen til Provet Clouds servere om at planlægge afsendelsen gik ikke igennem. Dette kan være en fejl med brugerens forbindelse eller måske et problem med Provet Clouds servere.
-
Datafejl - Anmodningen til Provet Clouds servere om at planlægge afsendelsen indeholdt ugyldige data. Dette tyder på et problem i Provet Cloud.
-
Integrationsfejl - Anmodningen blev sendt med succes, men integrationen svarede med en ikke-succesfuld HTTP-statuskode (lavere end 200 eller højere end 299). Den brugerdefinerede integrationslog kan bruges til at bestemme årsagen, hvis fejlen er uventet.
Hvis en brugerdefineret integration er defineret som en "Åbn i nyt vindue"-handling, vil et klik på den brugerdefinerede integrationsknap åbne mål-URL'en i et nyt vindue, eller mere almindeligt i moderne browsere, i en ny fane. Den oprindelige Provet Cloud-side forbliver åben i sit oprindelige vindue/fane.
Hvis der bruges en GET-anmodningsmetode, kan brugerne se payload-oplysningerne i browserens adresselinje. Hvis brugerne ikke let skal kunne se de overførte payload-oplysninger, bør man overveje at bruge en POST-anmodning i stedet.
Hvis en brugerdefineret integration er defineret som en "Åbn i sidepanel"-handling, vil et klik på knappen for brugerdefineret integration hente mål-URL'en i browseren og vise den i en iframe -element i et sidepanel, der åbnes oven på den aktuelle side.
Mål-URL'en skal understøtte indlejring via sin X-Frame-Options-header.
Klienttilpassede integrationer vises på klientsiden i højre side, over afsnittet Noter, når du gennemser en af klientfanerne ('Klientoplysninger', 'Fakturering', 'Behandlinger' osv.). Det vil ikke blive vist på patientfanerne. Klient-id'et vil blive sendt som en parameter.
På samme måde vil patienttilpassede integrationer blive vist på patientsiden i højre side over afsnittet Noter, når man gennemser patientfaner ("Patientoplysninger", "Historik", "Målinger" osv.). Det vil ikke blive vist på klientfanerne. Patientens ID sendes som en parameter.
Tilpassede integrationer af fakturaer vises på fakturasider (inklusive tællersalg) i den nederste værktøjslinje. Faktura-id'et (ikke at forveksle med fakturanummer) sendes som en parameter.
Brugerdefinerede konsultationsintegrationer vises på konsultationssiden over afsnittet med generelle oplysninger, både for igangværende og afsluttede konsultationer. Konsultationens ID vil blive sendt som en parameter.
Brugerdefinerede integrationer af aftalekalenderen vil blive gengivet oven på aftalekalenderen. Den aktive kliniks lokations-ID sendes som en parameter.
På samme måde vil brugerdefinerede integrationer af vagtkalenderen blive vist oven på vagtkalenderen under valget af vagttype og vagtskabelon. Den aktive kliniks lokations-ID sendes som en parameter.
Brugerdefinerede integrationer til billeddiagnostik vises på henvisningssiden til billeddiagnostik i øverste og nederste værktøjslinje. ID'et for henvisningen til billeddiagnostik sendes som en parameter.
Hvis der er risiko for, at eksterne parter kan sende anmodninger til mål-URL'en, og det er nødvendigt at vide, hvilke anmodninger der kommer fra den tilpassede Provet Cloud-integration, kan verifikationshashes bruges som yderligere validering. Når det er aktiveret, tilføjes en ekstra parameter kaldet "verification" til anmodninger og er et MD5-hashdigest af tidsstemplet og verifikationssaltet.
For eksempel kan man skrive en funktion som denne for at kontrollere, at verifikationshash'en er gyldig i Python:
Når man bruger baggrundssending ('Send HTTP-anmodning'), genereres tidsstemplet, når anmodningen faktisk sendes. Men når man bruger forgrundssending ("Åbn i et nyt vindue"), genereres tidsstemplet, når en side, der indeholder den brugerdefinerede integrationsknap, indlæses. Dette gøres for at generere verifikationshash på serversiden og undgå at eksponere verifikationssaltet for brugerne. Udviklere af brugerdefinerede integrationer skal måske overveje, at brugerne kan bruge lidt tid på siden, før de klikker på knappen til brugerdefineret integration.
Provet Cloud giver mulighed for en begrænset mængde tovejskommunikation med brugerdefinerede integrationer, der åbnes i forgrunden ved hjælp af Window.postMessage() API. Vinduet/fanen, der åbnede den brugerdefinerede integration, er tilgængelig via window.opener -objektet, og dermed kan en besked sendes med window.opener.postMessage(message), hvor beskeden er en gyldig kommando, der genkendes af Provet Cloud.
I øjeblikket er den eneste gyldige kommando "reload", som vil genindlæse hele siden i det vindue/den fane, der åbnede den brugerdefinerede integration. Dette kan f.eks. være nyttigt, hvis den brugerdefinerede integration opdaterer Provet Cloud-data via REST API, og brugerne skal se de seneste ændringer, når de vender tilbage fra den brugerdefinerede integration.
Opdateret
Kommentarer
0 kommentarer
Log ind for at kommentere.