Ilia Semenov

Roman Osenev

Serghei Gerasimov

Georgy Kopanitsa

2 Centrul Național de Cercetare Cognitivă, Universitatea ITMO, Saint-Petersburg 197101, Rusia

Dmitry Denisov

Yuriy Andreychuk

Abstract

1. Introducere

Această lucrare este o extensie a lucrărilor prezentate inițial la pHealth 2019— Conferința internațională 16 privind tehnologiile portabile, micro și nano pentru sănătatea personalizată [1].

Sistemele de asistare a deciziilor (DSS) sunt în prezent implementate pentru a rezolva o mare varietate de sarcini clinice și de mediu. Implementarea cu succes a unui sistem de susținere a deciziilor necesită strategii de planificare eficiente, o înțelegere comună a obiectivelor, performanței și utilizabilității sprijinirii deciziilor. Acest lucru poate crește acceptarea și face succesul proiectului general [2]. Sarcinile care pot fi rezolvate în mod eficient prin sistemele de sprijinire a deciziilor variază de la implementarea planurilor de acțiune în domeniul climei urbane [3] și sprijinul planificării drumurilor până la diagnosticarea bolilor rare [4].

Industria asistenței medicale devine din ce în ce mai mult o comunitate bazată pe cunoaștere, conectând diferiți furnizori, scăzând costurile administrative și îmbunătățind calitatea și continuitatea asistenței. Acest lucru creează provocări și oportunități pentru sistemele clinice de sprijinire a deciziilor (CDSS) care facilitează procedurile de îngrijire a sănătății în setările bazate pe cunoștințe [5]. Un CDSS este orice program de calculator conceput pentru a ajuta la luarea deciziilor clinice [6,7]. Această definiție demonstrează varietatea și evoluția suportului deciziei clinice de la aplicații mici, focalizate la platforme la scară largă capabile să stocheze și să gestioneze date medicale pentru a ajuta medicii și pacienții prin furnizarea de recomandări [8,9].

Pentru a oferi asistență eficientă la luarea deciziilor, este necesar să se integreze CDSS-urile în sistemele informaționale operate în mod curent de către profesioniștii din domeniul sănătății, cum ar fi sistemele de informații din spitale (SIS) sau de către pacienții care își desfășoară dosarele personale de sănătate (PHR) [10]. CDSS-urile ar trebui să poată utiliza semantica și contextul clinic al datelor care au fost importate din alte sisteme și depozite de date [11,12,13].

Interoperabilitatea semantică devine o problemă cheie atunci când vine vorba de comunicarea între sistemele informaționale eterogene [14]. Una dintre modalitățile de conectare a diferitelor sisteme de informații este de a construi o platformă care procesează date medicale bazate pe standard și oferă interfețe unificate. Utilizarea standardelor clinice de schimb de date, cum ar fi openEHR [15], CEN/ISO EN13606 [16,17,18], HL7 CDA [19] și resurse rapide de interoperabilitate a asistenței medicale (FHIR) [14] pot oferi interoperabilitate la nivel de date. Aceste standarde specifică structurile de date ale evidenței medicale electronice comune (EHR) [20] și sunt utilizate pe scară largă în sistemele de sprijin pentru deciziile clinice [21,22]. Unul dintre cele mai recente formate de specificații de date EHR este standardul FHIR care oferă elemente de date („resurse”) și o interfață de programare a aplicației (API) pentru a recupera și a face schimb de înregistrări electronice de sănătate [23].

Software-ul actual al ecosistemului medical poate fi caracterizat prin nevoile sale inovatoare ridicate, interacțiunile perturbatoare dintre sisteme și împiedicarea interoperabilității semantice [24]. Pentru a evita astfel de probleme, dezvoltatorii pot grupa aplicații software în unități funcționale mici, ușor de suportat, care pot fi schimbate la cerere fără a afecta alte bucăți de software. Această abordare este denumită în mod obișnuit arhitectură de microservicii [25].

Specificarea interfețelor standard, CDS Hooks (https://cds-hooks.org), oferă un model bazat pe hook pentru invocarea automată a funcțiilor CDSS în cadrul fluxurilor de lucru clinice de rutină [26]. Această specificație acceptă nativ HL7 FHIR R4 pentru a simplifica fluxul de date, permițând integrarea ușoară a serviciilor HIS și CDSS.

Experiența arată că majoritatea CDSS-urilor sunt implementări independente axate pe o afecțiune clinică sau un flux de lucru [27,28,29]. Cu toate acestea, lipsește încă implementarea unor platforme sofisticate de sprijinire a deciziilor clinice care sunt capabile să ofere un spectru complet de funcționalități de sprijinire a deciziilor clinice diferitelor sisteme de informații medicale. Există o nevoie persistentă de platforme eficiente și de înaltă calitate, care să unifice proiectarea, dezvoltarea, prezentarea, implementarea, evaluarea și întreținerea tuturor tipurilor de capacități de sprijin al deciziilor clinice pentru clinicieni, pacienți [30] și alte părți interesate [31]. Avansăm experiențele existente în implementarea platformelor CDS [32] prin adăugarea de interfețe și structuri de date bazate pe standard pentru a oferi caracteristici de sprijin decizional diferitelor ecosisteme de îngrijire a sănătății.

Scopul acestei cercetări este de a dezvolta o platformă de microservicii bazată pe FHIR care integrează SIS și CDSS într-un spațiu informațional unificat.

2. Metode

2.1. Arhitectura platformei

Structural, o platformă CDSS a fost dezvoltată ca un set de servicii separate, adică noduri distribuite în grupuri. Microserviciile comunică între ele asincron folosind protocolul de comunicare REST.

2.2. Servicii

Toate serviciile funcționează prin contracte publice reprezentate în format FHIR JSON, oferind identificatorul unic de resurse (URI) al resurselor. Serviciile utilizează două modele de interacțiune: apel de procedură la distanță (RPC) și interacțiune bazată pe evenimente. Jurnalele sunt trimise către serviciul central de jurnal cu un ID de tranzacție unic.

Un model al serviciilor este prezentat în Figura 1. Endpoint-urile Business API permit trimiterea de cereri specifice serviciului, de exemplu, pentru a returna artefacte sau terminologii specifice din baza de cunoștințe.

unei

Modelul general al serviciului platformei. API: interfață de programare a aplicației.

Punctul final al evenimentului API (de exemplu, HTTP/eveniment) permite unui serviciu extern să trimită cereri de evenimente. Deci, serviciul cunoaște starea altor servicii de pe platformă.

Punctul final API Health Check (de exemplu, HTTP/sănătate) returnează starea de sănătate a serviciului către gestionarul său pentru a oferi monitorizare continuă. Handler-ul punctului final API efectuează diferite verificări, cum ar fi

starea conexiunilor la serviciile de infrastructură utilizate de instanța de serviciu;

starea gazdei, de exemplu, spațiul pe disc;

Business Logic este partea principală a serviciului care este responsabilă pentru implementarea caracteristicii serviciului este conceput pentru, de exemplu, logica încărcării faptelor din baza de date într-un motor de inferență.

Magazinul de evenimente și Magazinul de logici pentru afaceri sunt responsabile pentru gestionarea și salvarea datelor legate de procesul corespunzător al serviciului.

Clientul pentru alte servicii este responsabil pentru comunicarea activă cu alte servicii ale platformei, de exemplu, prin trimiterea evenimentelor și a rezultatelor muncii.

Fiecare serviciu are un ciclu de lansare independent, astfel încât interfețele publice acceptă versiunile pentru a asigura o funcționare consecventă a sistemului.

2.3. Modelare clinică

Platforma CDSS necesită proiectarea unui set de profiluri FHIR adecvate pentru suportul decizional. Am folosit Forge (https://fhir.furore.com/forge/), editorul oficial de profil HL7 ® FHIR ®, o aplicație desktop pentru modelarea și validarea profilurilor. Am folosit coduri de identificare a observației logice Nume și coduri (LOINC) [33] și coduri Nomenclatura sistematizată a medicinii - Termeni clinici (SNOMED CT) [34] pentru a defini semantica conceptelor medicale.

Un „pacient” a fost folosit ca resursă principală a platformei. Pentru a asigura interoperabilitatea semantică, platforma acceptă următoarele resurse FHIR R4 [35] ca date de intrare și ieșire: