1 Wprowadzenie

Perfuse przenosi komunikaty kliniczne między systemami, które nie zostały zaprojektowane do komunikowania się ze sobą. Laboratorium wysyła wyniki w HL7 v2; system zarządzania praktyką oczekuje ich z innymi pozycjami pól, innym identyfikatorem pacjenta i potwierdzeniem w ciągu pięciu sekund. Coś musi siedzieć pośrodku, a tym czymś jest silnik integracji.

Ten podręcznik opisuje, co robi Perfuse, każdą opcję, którą akceptuje, i — gdzie decyzja nie jest oczywista — dlaczego działa w taki sposób.

1.1 Do czego służy Perfuse

Jeden interfejs między dwoma systemami klinicznymi jest zwykle wyceniany w dziesiątkach tysięcy, z piętnastoma do dwudziestu procent więcej każdego roku w utrzymaniu. Większość tego kosztu nie jest pracą; jest to, że praca wymaga kogoś, kto ma doświadczenie w HL7, a większość praktyk nie zatrudnia takiej osoby.

Perfuse został zbudowany na założeniu, że osoba konfigrująca go ma problem do rozwiązania i nie ma wcześniejszego doświadczenia w HL7. To założenie jest widoczne w konkretnych miejscach:

• Wszystko jest konfigurowalne z interfejsu webowego. Funkcja dostępna tylko z terminala lub pliku edytowanego ręcznie jest traktowana jako wada, a nie wybór projektowy.
• Komunikaty mogą być śledzone krok po kroku, pokazując, co każdy krok odczytał, co zmienił, co pominął i dlaczego.
• Można generować ruch testowy, który odpowiada kształtowi rzeczywistego źródła bez zawierania jego danych.
• Kanał może być proponowany na podstawie jednego przykładowego komunikatu, z jawnym oświadczeniem, co próbka nie może powiedzieć.
• Przed zastąpieniem istniejącego silnika, jego wyjście i wyjście Perfuse mogą być porównane komunikat po komunikacie, z różnicami pogrupowanymi według pola.

1.2 Co się w nim znajduje

Wszystko poniżej jest w jednym pliku binarnym. Każda linia nazwuje rozdział, który ją opisuje.

• Formaty. HL7 v2, FHIR R4, R4B i R5, DICOM, X12 (837, 835, 270/271, 276/277, 834, 278, 275), C-CDA i CDA, HL7 v3, NCPDP Telecommunication i SCRIPT, SMART Health Links i Cards, rozdzielone i surowe. Zobacz formaty wiadomości.
• Konnektory. 28 typów źródeł i 32 typy miejsc przeznaczenia, w tym MLLP, pliki, SFTP, bazy danych, DICOM, Kafka, AMQP 1.0, MQTT, IBM MQ oraz magazyn i komunikacja AWS, Azure i Google Cloud. Zobacz dokumentację źródła i dokumentację miejsca przeznaczenia.
• Zmiana wiadomości. Filtry, jedenaście deklaratywnych kroków transformacji, JavaScript (w tym dialekt Mirth) i Lua, współdzielone tabele mapowania i zestawy kodu oraz sugestie mapowania. Zobacz filtrowanie i transformacja.
• Dostarczanie ich. Trwała, uporządkowana kolejka na miejsce przeznaczenia, ponowienia, martwe litery, które zachowują wiadomość, oraz potwierdzenia wysyłane po dostarczeniu. Zobacz dostarczanie i potwierdzenia.
• Obserwowanie działania. Pulpity nawigacyjne, pulpity nawigacyjne zespołu, mapa przepływu, jedenaście rodzajów alertów, metryki, śledzenie oraz magazyn wiadomości, który znajduje wiadomości pacjenta we wszystkich formatach. Zobacz alertowanie, magazyn wiadomości oraz debugowanie.
• Zmiana aktywnej interfejsu w sposób bezpieczny. Tryb cienia, umowy dotyczące kanałów, testy kanałów i porównanie silników. Zobacz testowanie.
• Opuszczanie Mirth. Kanały Mirth, Open Integration Engine i BridgeLink wyjaśnione, przetłumaczone i wyeksportowane z powrotem. Zobacz migracja.
• Płatnicy i zdrowie publiczne. Cztery API CMS-0057, Da Vinci CRD, DTR, PAS, PDex i Plan-Net, CARIN Blue Button, opcjonalna usługa decyzyjna, eCR i ELR. Da Vinci CRD, DTR i PAS odpowiadają na obie swoje wersje 2.2.x i 2.1.0. Zobacz CMS-0057.
• Kto może co zrobić. SAML, OpenID Connect, LDAP, passkeys, SCIM, mutual TLS, sześć ról, grupy kanałów z rolą w każdej, najemcy, serwer autoryzacji SMART, TEFCA i UDAP oraz rejestr audytowy. Zobacz bezpieczeństwo.
• Uruchamianie go. Jeden plik binarny dla systemów Linux, macOS i Windows, jako usługa, z widokiem floty na kilka serwerów. Zobacz operacje, interfejs sieciowy, wiersz poleceń oraz opcje serwera.

1.3 Standardy i wersje

Która wersja każdego standardu jest implementowana przez Perfuse i w jaki sposób to sprawdzono. „Sprawdzono” to nazwa zewnętrznego narzędzia lub odniesienia, które oceniło wynik; jeśli nic zewnętrznego nie oceniło go, to tak się stwierdza. Wyniki pochodzą z danych testowych, a nie z witryny produkcyjnej.

1.3.1 Wiadomości i dokumenty

1.3.2 Przewodniki implementacji FHIR

1.3.3 Profile narodowe i europejskie

Sprawdzono przez konwersję opublikowanych lub wymyślonych wiadomości HL7 v2 i walidację każdego zasobu; pełne wyniki i powody każdego niepowodzenia znajdują się w folderze conformance/national repozytorium.

Żadne z powyższych nie jest certyfikacją. Perfuse nie został certyfikowany przez ONC, CMS, gematik, Nictiz, NHS England lub kogokolwiek innego.

1.4 Co zastępuje

Perfuse pokrywa obszar zajmowany przez Mirth Connect i może importować eksporty kanałów Mirth bezpośrednio. Rozdział o migracji opisuje, co przekłada się czysto, co wymaga decyzji oraz jak udowodnić, że wynik pasuje przed przełączeniem.

Różnice, które mają znaczenie w codziennym użyciu, to debugowanie i cisza. W Mirth, widzenie, co transformer zrobił z komunikatem, zwykle oznacza ponowne wdrożenie kanału z dodanym logowaniem. W Perfuse, każdy zarejestrowany komunikat może być odtworzony przez bieżącą konfigurację i zbadany krok po kroku, bez dotykania uruchomionego kanału. I tam, gdzie alert Mirth na „brak ruchu” jest stałym progiem, który jest bezużyteczny w przypadku każdego karmienia, które jest ciche w nocy, Perfuse uczy się, jaki wygląda normalny tydzień dla każdego karmienia, i alertuje przeciwko temu.

1.5 Jak czytać ten podręcznik

Pierwsze rozdziały są pojęciowe i warto je przeczytać w kolejności: kanały, przepływ komunikatów, a następnie transformacja. Wszystko, co następuje, może być czytane według potrzeby.

Rozdziały odniesienia znajdujące się pod koniec listują każdy klucz konfiguracyjny, jego typ, czy jest wymagany oraz jego wartość domyślną. Rozdziały te są generowane z kodu źródłowego, więc nie mogą opisywać opcji, które nie istnieją, ani pomijać tych, które istnieją. Jeśli klucz pojawia się w pliku konfiguracyjnym, ale nie w indeksie, to nie jest to klucz Perfuse.

1.6 Konwencje

Konfiguracja jest w formacie YAML. Większość kluczy jest w postaci snake_case w sieci — max_message_size, idle_timeout — i ten podręcznik zawsze podaje postać sieciową, ponieważ to jest to, co wpisujesz. Istnieje jeden długoletni wyjątek, dataType w kanale, który jest w postaci camelCase; jest on opisany w ten sposób w odniesieniu do kanału i akceptowany tylko w tym sposobie pisania.

Odwołania do pól w HL7 używają zwykłej notacji: PID-5 jest piątym polem segmentu PID, PID-5.1 jego pierwszym składnikiem, a PID-3(2) drugą powtórką trzeciego pola. Ścieżka napisana bez powtórki adresuje każdą powtórkę (patrz ścieżki).

Czas trwania jest zapisany jako liczba i jednostka — 30s, 5m, 2h. Goła liczba nie jest czasem trwania i zostanie odrzucona, zamiast próby jej odgadnięcia.

2 Wprowadzenie

Perfuse jest pojedynczym plikiem wykonywalnym z wbudowanym interfejsem sieciowym. Nie ma serwera aplikacji do zainstalowania, nie ma bazy danych do przygotowania i nie ma oddzielnego konsoli administracyjnej.

2.1 Uruchamianie

perfuse serve -channels ./channels -db ./perfuse.db -addr 0.0.0.0:8443 \
  -tls-cert ./cert.pem -tls-key ./key.pem

-channels to katalog plików YAML, po jednym dla każdego kanału. -db to plik SQLite zawierający zapisane wiadomości, użytkowników i historię inspekcji; jest tworzony, jeśli nie istnieje.

Podczas pierwszego uruchomienia bez skonfigurowanych użytkowników, tworzone jest konto administratora i jego hasło jest zapisywane w dzienniku raz. Hasło to nie może być później odzyskane.

2.2 Pierwszy kanał

Kanał potrzebuje nazwy, źródła i co najmniej jednego miejsca docelowego. Najmniejszy użyteczny kanał odbiera HL7 za pośrednictwem MLLP i zapisuje każdą wiadomość w pliku:

name: first-feed
dataType: hl7
source:
  type: mllp
  listen: "0.0.0.0:6661"
destinations:
  - name: to-disk
    type: file
    file:
      root: /var/spool/perfuse
      dir: incoming

Zapisz to jako channels/first-feed.yaml i zostanie on automatycznie wykryty bez potrzeby ponownego uruchomienia.

Trzy rzeczy dotyczące tego pliku są warte zauważenia, ponieważ są one kształtem każdego kanału:

• Blok źródłowy jest płaski dla MLLP. listen znajduje się bezpośrednio w source, a nie wewnątrz bloku source.mllp. Transporty, które wymagają więcej niż adres — HTTP, SOAP, DICOM — mają swój własny podblok, a te są wymienione w odniesieniu do źródła.
• Miejsce docelowe pliku wymaga zarówno root, jak i dir. root jest granicą, przeciwko której ścieżki są rozwiązywane i nie mogą z niej uciec; dir to miejsce, w którym wiadomości lądują w jego obrębie.
• Nie ma transformacji i nie ma filtra. Oba są opcjonalne, a kanał z żadnym z nich po prostu przekazuje wiadomości.

2.3 Tworzenie kanału z interfejsu

Wszystko powyższe można zrobić z interfejsu sieciowego zamiast, i dla pierwszego kanału jest to lepsza droga, ponieważ formularz nie pozwoli Ci wyprodukować pliku, który nie zostanie załadowany.

Budowniczy oferuje trzy sposoby wejścia:

1. Z wiadomości, którą ktoś Ci wysłał. Wklej próbkę, którą laboratorium lub dostawca wysłał pocztą elektroniczną. Perfuse czyta ją i proponuje kanał, wraz z trzema oddzielnymi listami: to, co próbka pokazuje, to, co zostało zgadnięte, i to, czego żadna próbka nie może powiedzieć. To jest opisane w testowaniu.
2. Z czegoś, co już działa. Zestaw kompletnych kanałów, które potrzebują tylko wypełnionych adresów.
3. Z niczego. Pusty formularz. Dostępny, ale jest to najwolniejszy z trzech i najłatwiejszy do popełnienia błędu.

2.4 Weryfikowanie, czy działa przed podłączeniem czegokolwiek

Dwie rzeczy można zrobić przed istnieniem systemu wysyłającego.

Wyślij wiadomość ręcznie z interfejsu — nadawca wiadomości akceptuje wklejany tekst i raportuje, co się z nią stało, w tym, które miejsca docelowe ją zaakceptowały i co każda transformacja zrobiła.

Lub wygeneruj ruch testowy. Jeśli kanał obsłużył jakiekolwiek wiadomości, Perfuse może nauczyć się ich kształtu i wyprodukować więcej wiadomości podobnych do nich, w tych samych proporcjach, bez żadnej oryginalnej zawartości. Zobacz testowanie.

2.5 Co dalej

• Kanały wyjaśnia, co to jest kanał i jak jego części współgrają.
• Przepływ wiadomości śledzi jedną wiadomość od przybycia do dostarczenia, co jest najszybszym sposobem zrozumienia, gdzie umieścić zmianę.
• Alarmowanie jest warte ustawienia przed uruchomieniem kanału, zamiast po pierwszym incydencie.

3 Interfejs sieciowy

Perfuse jest zbudowany na założeniu, że wszystko można zrobić z poziomu przeglądarki, a funkcja, która może być dostępna tylko przez edycję pliku, jest traktowana jako wada. Ten rozdział jest przewodnikiem po tym, co znajduje się za każdą częścią nawigacji, zorganizowanym w sposób, w jaki jest zorganizowany interfejs: według pytania, które zadajesz.

Pasek nawigacyjny zawiera Pulpit nawigacyjny i Kanały bezpośrednio, ponieważ to tam zaczynają się i kończą większość sesji. Wszystko inne jest pogrupowane, a grupy są nazwane według pytań, a nie według podsystemów — nie idziesz do „podsystemu audytu”, idziesz i dowiadujesz się, kto co zmienił.

3.1 Czytanie nagłówka

Pięć rzeczy w nagłówku jest łatwo przeoczyć.

Każdy widok ma adres. Pasek adresu podąża za widokiem — #/channels, #/messages, #/settings — więc przeładowanie powoduje powrót do niego, zakładka otwiera go, link wysłany do kolegi ląduje na nim, a przycisk wstecz przechodzi między widokami, zamiast opuszczać konsolę. Adres nazywający widok powyżej Twojej roli otwiera pulpity nawigacyjne zamiast.

Wyszukiwanie, lub ⌘K. Wyszukuje w kanałach, ustawieniach, wiadomościach i podręczniku, co oznacza, że zwykle jest szybsze niż nawigowanie — szczególnie w przypadku ustawienia, którego nazwę pół pamietasz.

Motyw. Trzy z nich: Midnight, Dark i Light. Midnight to prawie czarny i jest tym, czego zwykle potrzebuje wyświetlacz na ścianie w pomieszczeniu serwerowni; Dark to miękki neutralny szary; Light to dla laptopa obok okna. Wybór jest przechowywany w przeglądarce, a nie w stosunku do konta, ponieważ motyw jest właściwością miejsca, w którym ktoś siedzi, a nie kim są — ten sam operator chce Midnight na ścianie i Light w pociągu. Własna preferencja maszyny jest konsultowana raz, aby wybrać rozsądną wartość domyślną pierwszy raz.

Język. Konsola jest dostępna w języku angielskim (UK lub US porządek dat), niemieckim, francuskim, niderlandzkim, hiszpańskim, włoskim, portugalskim, polskim, szwedzkim, duńskim, norweskim lub fińskim, z datami i liczbami zapisanymi w sposób właściwy dla danego obszaru językowego. Wybór jest przechowywany w przeglądarce, a język przeglądarki jest używany do momentu wybrania innego. Tłumaczenia zostały wykonane przez maszynę i nie zostały jeszcze sprawdzone przez native speakerów; angielski jest językiem referencyjnym, a wybór języka informuje o tym. Kod, komunikaty, ładunki, nazwy kanałów i wszystko, co jest wpisywane, nigdy nie są tłumaczone. Podręcznik jest publikowany w tych samych językach pod adresem https://perfuse.health/manual/<language>/ (własna Dokumentacja tego serwera jest w języku angielskim).

Podręcznik. Dokument, który czytasz, obsługiwany przez uruchomiony serwer. Jest to ten sam plik, który binarny może zapisać na dysku, więc zawsze opisuje wersję przed Tobą, a nie najnowszy wydany.

3.2 Monitor — czy działa i co się stało

3.2.1 Pulpit nawigacyjny

Stan każdego kanału, przepływność i wszystko, co jest obecnie nie tak. To jest ekran, który powinien być otwarty.

3.2.2 Wiadomości

Każda wiadomość, która przybyła, w co została przekształcona, na każde miejsce przeznaczenia i co się z nią stało. Można wyszukiwać, w tym za pomocą wyrażenia filtrującego, więc „pokaż mi te od tego nadawcy, które zostały odrzucone” jest zapytaniem, a nie popołudniem.

Wiadomość można odtworzyć stąd i ponownie przetworzyć za pomocą *bieżącej* konfiguracji, a nie tej, która była aktywna w czasie, kiedy to zepsuło — co jest sposobem potwierdzenia, że naprawa działa przeciwko ruchowi, który ją złamał. Zobacz sklep wiadomości, aby dowiedzieć się, co jest przechowywane i przez jaki czas.

3.2.3 Kolejka

Co czeka na dostarczenie i dlaczego. Kolejka, która nie jest opróżniana, jest najbardziej przydatnym wczesnym ostrzeżeniem, jakie produkuje silnik integracji, i warto ją sparować z regułą alarmową, aby nikt nie musiał obserwować. Zobacz dostarczanie.

3.2.4 Alerty

Co się wydarzyło i jakie są reguły. Reguły są edytowane tutaj, a nie w pliku. Zobacz alarmowanie.

3.2.5 Mierniki

Przepływność, opóźnienia i wskaźniki błędów w czasie. Przydatne do pytań o pojemność i, częściej, do pakietów zarządu — co jest powodem, dla którego logo witryny pojawia się na nim, jeśli zostało przesłane.

3.2.6 SQL na FHIR

Widoki SQL na FHIR: wybierz przykład lub zapisany widok, lub napisz jeden, uruchom go na FHIR sklepie serwera (wszyscy pacjenci lub jeden) lub nad zasobami wklejanymi, zobacz wiersze z ich typami i pobierz CSV, NDJSON lub Parquet. Zapisz zachowuje go dla FHIR punktu końcowego $sql-run. Zobacz formaty wiadomości.

3.2.7 Miary jakości

Cyfrowe miary jakości: wybierz przykład lub Miarę w FHIR sklepie, lub napisz jeden z kryteriami FHIRPath. Wybierz okres pomiaru i raport (podsumowanie, podsumowanie z listami pacjentów lub jeden pacjent) i ocenij go nad FHIR sklepem lub wklejanymi zasobami. Ekran pokazuje liczbę każdej populacji i pacjentów, wynik i warstwy. Pobierz MeasureReport zapisuje FHIR wynik, a Zapisz do FHIR sklepu zachowuje Miarę dla Measure/$evaluate-measure. Miary w CQL są odrzucane: Perfuse nie ma silnika CQL. Zobacz cyfrowe miary jakości.

3.2.8 Mapa przepływu

Obraz tego, jak wiadomości naprawdę się poruszają: które źródła karmią które kanały, a które miejsca docelowe osiągają.

Jego wartość nie jest dekoracją. Każda własność gromadzi kanał, o którym nikt nie pamięta, i miejsce docelowe, o którym nikt nie zdawał sobie sprawy, że wciąż otrzymuje, i oba są widoczne tutaj w sposób, w jaki nie są widoczne na liście plików kanałów.

3.2.9 Pulpity zespołowe

Pulpit nawigacyjny dla każdego rodzaju osoby, która obserwuje interfejsy: Operacje, Połączenia, Analityk interfejsu, Upoważnienie, Obrazowanie, Cykl przychodu, Laboratoryjne, Prywatność i bezpieczeństwo, a także zwykły podsumowanie departamentu. Kafelki pokazują liczby, stany i czasy, nigdy wiadomości lub pacjenta, więc pulpit nawigacyjny może być wysłany do menedżera lub wyświetlony na ekranie bez zwiększania liczby osób, które mają dostęp do danych pacjentów.

Każda osoba otwiera pulpit swojej grupy katalogowej lub roli. -dashboards dashboards.yaml mapuje je:

groups: {PACS-Admins: imaging, Network-Team: connections}
roles: {viewer: manager}

Grupa wygrywa nad rolą, a każdy niezgodny otwiera się na Operacje. Układ kafelków ukrywa i ponownie układa kafelki, wybór kanału filtruje je, a Zapisz jako mój widok zachowuje go jako własny pulpit nawigacyjny do momentu Reset.

Eksport do Grafana pobiera pulpit nawigacyjny jako JSON Grafana za pomocą /metrics, z zmienną źródła danych i filtrem kanału, dla wszystkich, którzy potrzebują więcej niż lekka konfiguracja. Każdy kafelek bez metryki za nim zostaje pominięty, a opis eksportu nazwa ich.

Kafelka Połączenia sprawdza każde sieciowe miejsce docelowe w warstwach. Wyszukuje nazwę, otwiera połączenie TCP, ukończa TLS, gdzie jest używany, i czyta ostatnią dostawę i awarię z rzeczywistego ruchu. Każda awaria mówi, co to znaczy, na przykład „odrzucony: silnik partnera jest prawdopodobnie zatrzymany”, „przekroczony limit czasu: zapora sieciowa lub tunel VPN, który jest wyłączony” lub „certyfikat z urzędu, którego ten serwer nie ufa”. Nic nie jest wysyłane do partnera, z jednym wyjątkiem: rejestr immunizacji, który nie miał ruchu przez siedem dni, jest pytany o CDC connectivityTest, który niczego nie wysyła. Z -vpn tunnels.yaml kafelka Tunele VPN obok niego czyta stan każdego partnera tunelu z AWS Site-to-Site VPN, połączenia bramy VPN Azure lub strongSwan na tym hoście, więc limit czasu może być odróżniony od tunelu, który jest wyłączony. Porównuje również obie strony IKE i ustawienia IPsec, ponieważ chmura raportuje nasze, a plik wymienia ich, i mówi, gdzie nie mogą się zgodzić. Arkusz połączenia pobiera ustawienia partnera obok siebie jako Markdown, aby je wysłać; nigdy nie zawiera współdzielonego klucza. Dane, które pulpit nawigacyjny potrzebuje, które jeszcze nie są rejestrowane, są wymienione pod Nie mierzone jeszcze zamiast rysowania pustych kafelków.

Pulpity departamentowe obliczają własne dane na serwerze, a każdy z nich mówi, jakie okno i źródło obejmuje:

• Upoważnienie: żądania PAS podjęte w ciągu 72 godzin (przyspieszone) lub 7 dni (standardowe), podjęte z opóźnieniem, oczekujące i przeterminowane teraz, z medianą czasu podejmowania decyzji. Również jak usługi, o które zostało poproszone, zostały odpowiednio potraktowane (zaakceptowane, zmodyfikowane, odrzucone, wstrzymane), jak każda z nich stoi teraz, przez 30 dni.
• Obrazowanie: obiekty otrzymane przez C-STORE na modality, i te, które nie zostały dostarczone. Również opóźnienie trasowania na kanał (mediana i 95. percentyl), zapytania C-FIND i awarie na kanał zapytania, oraz raporty obrazowania (ORU, którego OBR-24 jest sekcją obrazowania, lub MDM), które nie dotarły do każdego miejsca docelowego.
• Cykl przychodu: 999 zestawów transakcji zaakceptowanych, zaakceptowanych z błędami i odrzuconych, oraz 277CA roszczeń zaakceptowanych i odrzuconych (A3, A4, A6, A7, A8). Również 835 roszczeń dopasowanych według numeru konta pacjenta do 837 wysłanych przez ten serwer, oraz najczęstsze powody odrzucenia.
• Laboratoryjne: czas dostarczenia wyników, od otrzymania do potwierdzenia ostatniego miejsca docelowego, oraz wyniki krytyczne (OBX-8 HH, LL, AA, > lub <), które nie dotarły do każdego miejsca docelowego.
• Prywatność i bezpieczeństwo: kto otworzył wiadomości, wyszukał pacjentów lub przeczytał upoważnienia w konsoli przez 7 dni, z rejestru audytu (otwarcie wiadomości jest rejestrowane jako message.read). Również każdy aktywny token API i kiedy był ostatnio użyty; token, który nie był używany przez 90 dni, jest oznaczony.

3.2.10 Udostępnianie tego, co zawiera naprawdę kanał

Profiluj ten kanał raportuje, co naprawdę przychodzi: które wydarzenia wyzwalające, które pola są wypełnione i jak często, jakie kształty mają wartości, oraz które kody nadawca naprawdę używa. Ostatni z nich jest zwykle najbardziej przydatnym pojedynczym faktem w nim.

Profil może być pobrany i wysłany do kogoś innego. Potrzebuje nazwy i — wymagane — które system wyprodukował kanał, ponieważ pytanie, które obcy pyta o udostępniony profil, brzmi, czy opisuje ich system, a pole opcjonalne sprawiłoby, że „Nieznany” byłby najczęstszą odpowiedzią w każdej udostępnionej kolekcji.

Nie zawiera danych pacjentów, i jest to sprawdzane, a nie założone. Profil jest statystyczny: liczby, stawki, długości, kształty. Wartości są przechowywane tylko dla pól, które standard definiuje jako tabele kodów, ponieważ wartość tabeli kodów nie jest identyfikująca. Wartości identyfikatorów są nigdy nie wymienione.

Dwie rzeczy wynikają z tego, że jest to obietnica, a nie nadzieja. Serwer odbudowuje profil z przechowywanych wiadomości podczas eksportu, zamiast wysyłać ten, który jest na Twoim ekranie — więc to, co opuszcza budynek, zostało zmontowane przez profiler, który ma test potwierdzający tę właściwość, a nie przez przeglądarkę. A eksport odmawia całkowicie, jeśli profil kiedykolwiek wymienia wartości dla pola, które nie jest tabelą kodów, nazywając pole, ale nie wartości.

Profil, który przychodzi z innego miejsca, jest sprawdzany w ten sam sposób podczas importu, z innego powodu: został wyprodukowany przez kogoś, kogo staranność jest nieznana, a pokazywanie identyfikatorów pacjentów byłoby ujawnieniem przez ten serwer. Importowanie go nie zmienia nic — profil opisuje kanał, a to, co z nim zrobić, to oddzielna decyzja.

3.3 Kompiluj — zmień to, co robi kanał, i przetestuj to przed uruchomieniem

3.3.1 Kanały

Budowniczy kanałów. Źródła, miejsca docelowe, filtry, transformacje, skrypty i testy, z wygenerowanym YAML wyświetlanym obok formularza podczas pracy — więc plik nigdy nie jest tajemnicą, a każdy, kto woli plik, może czytać wraz z nim.

Zobacz kanały, aby dowiedzieć się, z czego składają się części, oraz transformacja, aby dowiedzieć się, co robią kroki.

3.3.2 Skrypty

Stacja robocza dla skryptów, oddzielna od budowniczego, ponieważ pisanie skryptu i podłączanie skryptu to różne czynności.

Wszystkie siedem slotów jest oferowanych — filtr, transformatory, preprocesor, postprocesor, zapisywacz, cykl życia i czytelnik — i wybór odpowiedniego slotu ma znaczenie, ponieważ slot decyduje o tym, co skrypt otrzymuje i co ma zwrócić. Sprawdzanie skryptu jako niewłaściwego typu nie jest obejściem; kompiluje ono inną rzecz.

Dostępne są JavaScript, Lua i WebAssembly. Zobacz transformacja.

3.3.3 Umowy

Oczekiwania dotyczące wyglądu kanału, utworzone i sprawdzone tutaj, a także z perfuse contract. Zobacz wiersz polecenia.

3.3.4 Tabele

Tabele odniesienia i zestawy kodów: mapowania, które przekształcają kody jednego systemu w kody innego. Edytowalne tutaj, aby dodanie kodu nie było wdrożeniem.

3.3.5 Maper AI

Proponuje mapowania pól z oceną ufności dla każdego, i wstrzymuje się od zgadywania. Pomimo nazwy nie używa modelu językowego i nie wykonuje połączenia sieciowego: sugestie pochodzą z reguł, nazw pól i zawartości próbki, na tym serwerze. Proponuje również kanał z jednej próbki wiadomości i stwierdza wyraźnie, czego próbka nie może mu powiedzieć. Ta druga część jest częścią, która czyni ją godną zaufania — propozycja, która wygląda na kompletną, zachęca do uwierzenia w rzeczy, których wiadomość nigdy nie powiedziała.

3.3.6 Place zabaw

Miejsce do testowania wiadomości i transformacji. Wklej wiadomość, zastosuj kroki, zobacz wynik.

Nic nie jest wysyłane nigdzie po załadowaniu strony, co jest powodem, dla którego istnieje w tej formie: jest bezpieczne wklejanie czegoś rzeczywistego, z zastrzeżeniem, że pozostaje w przeglądarce.

3.3.7 Cień

Uruchamia ruch przez kandydującą konfigurację obok żywej i raportuje różnice, aby zmiana mogła być udowodniona przed zaufaniem. Ten sam pomysł co perfuse compare, zastosowany do zmiany, a nie do migracji. Zobacz testowanie.

3.4 Wymiana — standardy, których ten serwer używa do komunikacji z innymi organizacjami

3.4.1 Laboratorium FHIR

Przekonwertuj HL7 v2 na FHIR, zwaliduj zasób i zbadaj wynik. Próbki obejmują przyjęcia, wyniki laboratoryjne, spotkania, notatki kliniczne, szczepienia i wizytę, która może być zgłoszona. Walidacja obejmuje US Core, który jest profilem, przeciwko któremu amerykańskie regulacje są pisane, więc to odpowiada na pytanie „czy to, co do nas wysłano, jest naprawdę zgodne” bez przyjęcia czegokolwiek.

Raport przypadku zdrowia publicznego tworzy eCR eICR, który destination case reporting wysyła dla wiadomości. Pokazuje, jaki kod wyzwolenia sprawił, że wizyta była zgłaszana, co raport musiał oznaczyć jako brakujące, i sam dokument. Wiadomość z niczym niezgłaszanym otrzymuje powód zamiast tego. Nic nie jest wysyłane stąd.

3.4.2 Subskrypcje

Subskrypcje FHIR oraz czy ich powiadomienia są dostarczane: zdarzenia, zaakceptowane, oczekujące oraz ostatni powód odrzucenia. Subskrypcje są tworzone przez klientów FHIR za pomocą interfejsu API FHIR, a nie z tej strony, i poświadczenia, które podali serwerowi, nigdy nie są wyświetlane. Zobacz formaty wiadomości.

3.4.3 Dokumenty

Dokumenty kliniczne — CDA i drukowalna forma dokumentu. Przydatne, gdy wymieniany obiekt jest podsumowaniem wypisu, a nie wiadomością.

3.4.4 Udostępnianie dokumentów

Rejestr i repozytorium IHE XDS.b uruchomione z -xds: ile dokumentów, pacjentów i zestawów przesłanych zawiera i ile zostało zastąpionych; adresy repozytorium, rejestru, bramy XCA i MHD; wyszukiwanie dokumentów pacjenta w tym rejestrze lub innym (rejestr ITI-18 lub brama ITI-38, z tokenem dla niego); oraz publikowanie dokumentu CDA ręcznie, z typem placówki i ustawieniami praktyki, które dokument nie mówi. Zobacz formaty wiadomości.

3.4.5 Bezpośrednie

Bezpośrednia komunikacja zabezpieczona. Adresy Direct tego serwera wyświetlają każdy adres, który kanał wysyła lub otrzymuje, wraz z certyfikatem, datą wygaśnięcia, zaufanymi kotwicami oraz wszelkimi błędami (brakujący plik, wygasły certyfikat). Książka adresowa przechowuje korespondentów oraz certyfikaty, do których ich poczta jest szyfrowana: wklej jeden z ich HISP lub Zapisz z certyfikatem z DNS; certyfikat, który nie jest dla adresu lub jego domeny, jest odrzucany. Znajdź certyfikat w DNS pyta bez zapisywania. Zobacz formaty wiadomości.

3.4.6 Łącza zdrowotne

SMART Health Links i Karty, dla *Zabij klipboard* CMS. Odbierz link SMART Health odczytuje link lub kod QR, który pacjent pokazuje podczas zapisu, weryfikuje karty zdrowia w środku i wysyła dalej do kanału. Udostępnij rekord wizyty tworzy link, który jest hostowany przez ten serwer, opcjonalnie z kodem dostępu, oraz kod QR dla pacjenta; Użyj podsumowania pacjenta wypełnia je podsumowaniem pacjenta z Międzynarodowego podsumowania pacjenta z magazynu FHIR tego serwera. Linki hostowane przez ten serwer wyświetlają je wraz z częstotliwością, z jaką każdy z nich został pobrany, datą wygaśnięcia oraz liczbą pozostałych prób kodu dostępu, oraz odwołuje jeden. Weryfikuj kartę SMART Health sprawdza podpis i wystawcę karty we własnym zakresie. Zobacz CMS-0057 dla opcji serwera, których potrzebuje.

3.4.7 Obrazowanie

Archiwum, które ten serwer przechowuje podczas uruchamiania z -dicomweb-archive: liczby badań, serii, przypadków i używanego miejsca, adres DICOMweb oraz blok danych dla widoku OHIF, oraz wyszukiwanie badań według nazwy pacjenta, identyfikatora, numeru przyjęcia i daty utworzonego przy użyciu tego samego żądania QIDO-RS, jakiego używa widok. Badanie otwiera się do serii i przypadków, a przypadki pobierane są jako pliki DICOM. Nic nie jest renderowane: Perfuse przenosi obrazy, a widok je wyświetla. Bez archiwum ekran wyświetla informację, jak je włączyć. Zobacz DICOMweb.

3.4.8 TEFCA

Ślad audytowy dla wymiany za pośrednictwem Kwalifikowanej Sieci Informacji o Zdrowiu oraz reguły celu użycia, które ją regulują.

Dwa transporty, które znajdują się w różnych fazach, a ekran wyświetla, który z nich jest który. Jeden flaga obejmujący oba byłby błędny w którąkolwiek stronę, w którą był zaokrąglony.

Zaimplementowano ułatwiony FHIR, który nigdy nie komunikował się z prawdziwą QHIN. Postępuje zgodnie z procedurą operacyjną Sequoia Project obowiązującą od 8 marca 2026: odkryj metadane partnera UDAP, zweryfikuj je, zarejestruj się dynamicznie, uzyskaj token dostępu zawierający cel użycia oraz wykonaj zapytanie. UDAP jest infrastrukturą kluczy publicznych nad OAuth 2.0 — społeczność zaufania wydaje certyfikaty X.509 swoim członkom, a członek uwierzytelnia się, podpisując JWT za pomocą klucza prywatnego i dołączając łańcuch certyfikatów.

Warstwa zabezpieczeń jest weryfikowana w stosunku do implementacji kogoś innego, co jest jedyną weryfikacją, która ma tu jakiekolwiek znaczenie. Rejestracja podpisana przez tę wersję została wysłana do żywej serwera referencyjnego i odrzucona z unapproved_software_statement — Untrusted: Certificate is not a member of community. Aby wyprodukować tę odpowiedź, serwer odkodował żądanie, sparsował oświadczenie oprogramowania jako JWT, sprawdził jego podpis, przeanalizował łańcuch certyfikatów i podjął decyzję o członkostwie. To jest różnica między zostaniem odrzuconym u drzwi a otrzymaniem nieczytelnej wiadomości.

To, co pozostaje, nie może być wykonane stąd. Certyfikat, który dowodzi członkostwa w społeczności, pochodzi z procesu QHIN onboarding i nie jest czymś, co produkuje oprogramowanie. Dopóki nie istnieje, żadna wymiana z prawdziwym partnerem nie zostanie ukończona.

W jaki sposób kanał pyta. Miejsce docelowe typu tefca pyta o zestaw partnerów FHIR w ustawieniach Ustawienia, TEFCA (tefca.partnerFHIRBase) dla każdego pacjenta w wiadomości: przez identyfikator, gdy wiadomość go posiada (PID-3 lub identyfikator pacjenta FHIR), w przeciwnym razie przez nazwisko z datą urodzenia, a nigdy samą nazwę, ponieważ błędne dopasowanie nazwy zwraca rekord kogoś innego bez błędu. Miejsce docelowe ustawia cel użycia (leczenie, płatność, operacje, zdrowie publiczne, dostęp indywidualny); cel, którego uczestnik nie deklaruje, jest odrzucany przed wysłaniem czegokolwiek. Cele są przekazywane jako kody celu wymiany TEFCA (T-TRTMNT, T-PYMNT, T-HCO, T-PH, T-IAS, system urn:oid:2.16.840.1.113883.3.7204.1.5.2.1), lub z tefca.purposeCodes: hl7 jako kody celu użycia HL7 dla społeczności, które je używają. Znaleziony pakiet jest odpowiedzią miejsca docelowego i może być przekazany do innego kanału za pomocą results_to. Każde zapytanie, w tym odrzucone, jest rejestrowane w śladzie na tym ekranie, który nazywa partnera.

Cała ścieżka, od odkrycia do tokenu, który serwer FHIR partnera akceptuje, jest testowana w stosunku do serwera referencyjnego udap-dotnet (patrz weryfikacja).

Starszy exchange QHIN-to-QHIN zbudowany na profilach IHE nie jest zaimplementowany. Próba jest odrzucana z błędem, który tak mówi, a odrzucenie jest rejestrowane jako niepowodzenie. To jest celowe, a nie oczekujące na porządne rozwiązanie: zablokowana wymiana zgłaszająca sukces umieściłaby wpisy w śladzie audytowym dla wymian, które nigdy nie miały miejsca, a ślad, który nie zgadza się z tym, co się wydarzyło, jest gorszy niż żaden, ponieważ ślad jest tym, co jest wierzone.

Na przestrzeni całego, punkty końcowe używane do wymiany pochodzą z podpisanej części metadanych partnera, a nie z ciała dokumentu. Weryfikacja podpisu, a następnie odczytanie punktów końcowych z niepodpisanej kopii byłaby skomplikowanym sposobem zaufania sieci: atakujący, który może przepisać odpowiedź, pozostawia element podpisany, wskazuje punkt tokenu na własny serwer i zbiera asercje klienta od wszystkich, którzy sprawdzili podpis i potem zignorowali to, co obejmował.

Pakiet kotwicy zaufania jest wymagany, a jego brak jest odrzucany podczas uruchamiania. Sprawdzenie podpisanego metadanych partnera przeciwko certyfikatowi, który przybył wraz z nim, dowodzi tylko tego, że jedna strona utworzyła oba — błąd, który został popełniony wcześniej w SAML, gdzie weryfikator wolał certyfikat osadzony i uwierzytelnił atakującego jako administratora, podczas gdy wszystkie testy przeszły pomyślnie. Dołącz pośrednie do pakietu: serwer UDAP musi wysłać tylko swój certyfikat liścia, a publiczny serwer referencyjny robi dokładnie to.

3.5 Płatnicy — roszczenia, uprzednie autoryzacje, leki i reguły płatnika CMS

3.5.1 Roszczenia i autoryzacje

Utwórz załącznik roszczenia X12 275 w formie 006020, którą CMS-0053-F przyjmuje, z wklejonej C-CDA lub przesłanego pliku PDF, TIFF lub JPEG, i zobacz, jak jest odczytywany. Przeczytaj 275 i pobierz dokument wewnątrz. Przekonwertuj decyzję X12 278 na odpowiedź Da Vinci PAS ClaimResponse. Nic na tej stronie nie jest przechowywane ani wysyłane. Zobacz formaty wiadomości, aby dowiedzieć się, z czego jest zbudowany 275 i co nie robi.

3.5.2 Leki

Formularz leków załadowany z -formulary oraz dwa standardy NCPDP odpowiedzi z niego. Formularz wyświetla plany i leki wraz z poziomem i wymaganiami, oraz gdzie znajdują się publiczne API Da Vinci US Drug Formulary i punkty końcowe NCPDP. Sprawdź cenę (RTPB) ustala cenę leku dla członka jako żądanie Real-Time Prescription Benefit wystawcy: status pokrycia, ograniczenia w słowach z kodami, udział członka i planu, oraz tańsze alternatywy. Autoryzacja wcześniej (ePA) wysyła inicjację SCRIPT do własnego punktu końcowego serwera, wyświetla zestaw pytań jako formularz, wysyła odpowiedzi i wyświetla decyzję; poniżej, każdy przypadek z informacjami o stanie i czy wystawca został poinformowany, odpowiedzi przypadku, przycisk do ponownego wysłania niewysłanej decyzji oraz liczby leków, które proponuje CMS-0062-P. Zobacz CMS-0057.

3.5.3 CMS-0057

Strona płatnika reguły interoperacyjności i uprzedniej autoryzacji CMS, jako pięć narzędzi:

• Cztery API: czy Patient Access, Provider Access, Payer-to-Payer i Prior Authorization są gotowe w tej instancji,

oraz co jeszcze potrzebują każde z nich.

• Kolejka do sprawdzenia: żądania PAS oczekujące na osobę, najwcześniej terminowe jako pierwsze, z dokumentami wysłanymi dla każdego; zatwierdź, odrzuć lub

poświadczyć mniej jednostek. Zobacz kolejkę do sprawdzenia.

• Roszczenia do CARIN BB: 837 i 835 przekonwertowane na pakiety CARIN Blue Button.
• Autoryzacja wstępna do PDex: odpowiedź PAS przekonwertowana na autoryzację wstępną PDex.
• Mierniki autoryzacji wstępnej: roczna publiczna strona mierników autoryzacji wstępnej, podglądana z CSV decyzji.

Przekonwertowane dane nie są przechowywane ani wysyłane.

3.5.4 Sieć wyrównana z CMS

Gotowość do ram interoperacyjności CMS: każdy z 26 kryteriów, pogrupowanych tak, jak je grupuje CMS, z tym, co Perfuse zapewnia, czy jest włączone, ustawienie, które je włącza, oraz co należy do organizacji. Liczby na górze filtrowania listy. Zobacz CMS-0057.

3.6 Administruj — kto może co zrobić i jak jest skonfigurowany ten serwer

3.6.1 Użytkownicy

Konta, role (monitor, viewer, operator, editor, admin) i grupy kanałów. Każda osoba ma grupy kanałów edytowane w miejscu na liście; pusty oznacza każdy kanał, a lab=editor, adt daje inną rolę w jednej grupie. Administrator ograniczony do niektórych grup widzi tylko osoby z tych grup. Nagłówek pokazuje Twoje własne grupy obok Twojej roli, gdy masz jakąś. Zobacz bezpieczeństwo.

Poświadczenia maszynowe są również tutaj. Token jest dla maszyny, a nie dla osoby: nie wygasa i nie jest wpływany przez nikogo, kto się wyloguje, co jest potrzebne serwerowi, który sonduje swojego sąsiada. Przechowuje się tylko skrót, więc token jest wyświetlany tylko raz, gdy jest tworzony i nie może być odzyskany — skradziony zestaw danych nie daje żadnego użytecznego tokenu. Nadaj mu najniższą rolę, która robi to, co potrzebne.

Z włączonym MCP, sekcja ta wyświetla również adres, do którego łączy się agent AI, konfigurację klienta do skopiowania i każde narzędzie z rolą, której potrzebuje; wydanie tokenu z Pozwól agentowi AI działać z nim daje mu zakres mcp:write. Zobacz bezpieczeństwo.

3.6.2 Najemcy

Na serwerze współdzielonym, lista operatora platformy organizacji: każda z nich ma liczbę kanałów i przechowywanej wielkości obok limitów (kanały, wiadomości na minutę, przechowywanie), które są ustawiane w miejscu. Wyświetlane tylko dla roli platformy. Zobacz bezpieczeństwo dla informacji o tym, co robi każdy limit.

3.6.3 Certyfikaty

Certyfikaty TLS w użyciu i kiedy wygasają. Daty wygaśnięcia są punktem: certyfikat, który wygasł w niedzielę, jest klasą awarii, która jest całkowicie możliwa do uniknięcia i rutynowo nie jest unikana.

3.6.4 Aktywność

Kto zmienił co i kiedy. Każda zmiana konfiguracji jest rejestrowana, co pozwala odpowiedzieć na pytanie "zaczęło się to dziać we wtorek".

3.6.5 Ochrona danych

Żądania osoby zgodnie z RODO i brytyjskim RODO, przechowywanie danych, rejestry kasowania, przechowywanie i rejestr działań przetwarzania; tylko administratorzy. Zobacz ochronę danych.

3.6.6 Flota

Każda instancja Perfuse na jednej stronie.

Mirth sprzedaje to jako odrębny produkt; tutaj jest to plik konfiguracyjny i token tylko do odczytu. Powód, dla którego warto go posiadać, jest wąski i ważny: zablokowany serwer nie wygląda jak cichy. Pulpit jednej instancji nie może powiedzieć, że drugi serwer przestał raportować, a widok floty również nie.

3.6.7 Migruj

Upuść eksport kanału Mirth lub OIE i zobacz, ile Twoich kanałów działałoby tutaj bez zmian. Ta sama analiza, co perfuse explain i perfuse translate, bez potrzeby terminala. Zobacz migrację.

3.6.8 Ustawienia

Każde ustawienie serwera, z kontrolką dla każdego — w tym te, które tradycyjnie znajdują się tylko w pliku. Każde z nich wskazuje, czy zaczyna obowiązywać natychmiast, czy wymaga ponownego uruchomienia, oraz czy zostało ustawione jawnie, czy pozostaje na wartości domyślnej.

Ustawienia obejmują każdą opcję perfuse serve, która włącza funkcję: punkt końcowy FHIR i jego wersję, API płatników, PAS i reguły CRD, mostek X12 278, eCR, serwer autoryzacji SMART, TLS i podpisywanie, metryki, flotę i VPN. Są one pogrupowane jako FHIR, Płatnicy, Zdrowie publiczne, SMART, Bezpieczeństwo itd. Każda z nich jest również wyświetlana z flagą, do której odpowiada.

Uruchamianie ponownie z konsoli. Ustawienie oznaczone jako *Wymaga ponownego uruchomienia* jest zapisywane natychmiast, ale odczytywane tylko podczas uruchamiania serwera. Podczas gdy jakiekolwiek z nich czekają, baner na górze Ustawień wyświetla je wraz z przyciskiem Uruchom ponownie serwer (edycja logowania i pliki ustawień oferują ten sam przycisk po zapisie). Pyta najpierw, ponieważ każdy kanał zatrzymuje się na kilka sekund: każdy kończy wiadomość, którą obsługuje, tak jak robi to podczas zatrzymywania usługi, a nadawcy ponownie wysyłają wszystko, co przychodzi tymczasem. Konsola następnie czeka, aż serwer odpowie ponownie i odczyta ustawienia na nowo. Tylko administrator może uruchomić ponownie, a każde ponowne uruchomienie jest rejestrowane w dzienniku aktywności jako server.restart.

W systemie Linux i macOS proces zastępuje się świeżą kopią tego samego programu i argumentów, zachowując identyfikator procesu, więc systemd, launchd lub środowisko uruchomieniowe kontenera nie zauważa niczego. W systemie Windows serwer uruchamia się ponownie w tym samym procesie, który zachowuje usługę systemu Windows pod menedżerem usług. Jeśli serwer nie odpowiedział po dwóch minutach, konsola mówi o tym; powodem jest log serwera.

Flagi i plik ustawień. Pierwszy raz, gdy serwer uruchamia się, flagi, które otrzymał, są zapisywane w pliku ustawień. Od tego momentu plik ma pierwszeństwo przed flagami, więc zmiana ustawienia jest wykonywana w konsoli (lub w pliku), a nie przez edycję polecenia usługi. Flagę, której plik jeszcze nie wymienia, zapisuje się, gdy serwer uruchamia się z nią. Usunięcie flagi z polecenia w późniejszym czasie nie wyłącza jej funkcjonalności: należy ją wyłączyć w Ustawieniach.

SNMP ma panel poniżej ustawień: czy agent odpowiada i na jakim adresie, sieci, które obsługuje, ile alertów trap zostało wysłanych lub nie powiodło się, oraz Pobierz MIB dla bieżącego OID. Wartości są ustawiane w Monitorowaniu, SNMP.

Marka jest również tutaj: witryna może ustawić nazwę produktu, hasło, kolor akcentu i przesłać logo. Logo pojawia się następnie w nagłówku, na stronie logowania, na pulpicie i na ekranach raportowania. Jeśli nie zostanie przesłane logo, nic nie zostanie podmienione — niezmarkowana instalacja pozostaje niezmarkowana, zamiast nabyć dekorację.

3.7 Co oznaczają kolory

Cztery rejestry, a każdy mówi coś innego. Różnica jest warta podkreślenia, ponieważ jest to różnica między ekranem, który można przeczytać na pierwszy rzut oka, a tym, na którym wszystko konkurowało o uwagę.

Zwykły tekst jest faktem dotyczącym sposobu, w jaki działa Perfuse. Większość interfejsu. Nic nie jest pokolorowane, aby powiedzieć, że jest ważne.

Zielony oznacza, że coś się powiodło właśnie teraz, dzięki czemuś, co zrobiłeś. Pojawia się po akcji i nie utrzymuje się.

Bursztynowy jest ostrzeżeniem: wartym wiedzy przed podjęciem działania, a nie błędem. Funkcja, która nie jest włączona, ustawienie, którego zmiany są audytowane, konwersja, która przybliża raczej niż odtwarza, transport, który Perfuse obsługuje, ale nie może w pełni zweryfikować. Bursztynowy jest kolorem "przeczytaj to, zanim kontynuujesz".

Czerwony oznacza, że coś jest nie tak w tym momencie. Wartość, która została odrzucona, żądanie, które nie powiodło się, certyfikat, który wygasł, krytyczny alert, który jest uruchomiony. Nic innego nie używa go.

Dlatego ostatnia reguła jest taka, że ekran nie otwiera się na czerwono. Czerwony jest jedynym kolorem, który niesie instrukcję — zatrzymaj się, i może to być coś, co zrobiłeś — a ekran, który wydaje go na dekorację, nie ma nic do powiedzenia, gdy wprowadzony tekst jest naprawdę niepoprawny. Nie zawsze tak było: ekran użytkownika kiedyś otwierał się z "serwer wysłał odpowiedź, której nie można było odczytać" na każdej instalacji, która nie skonfigurowała passkey, a ekran ustawień oznaczał wartości audytowane tym samym kolorem, co odrzucony. Test w web/src/RedMeansWrong.test.ts teraz kończy się niepowodzeniem, jeśli fraza opisująca coś nieobecnego lub przybliżonego jest podana w stylu czerwonym.

Wewnątrz pola kodu słownictwo jest inne. Tam czerwony jest typem tokenu — nazwą segmentu HL7, elementem XML — i nie niesie żadnego osądu w ogóle.

4 Kanały

Kanał jest jednym przepływem wiadomości: skąd pochodzą, opcjonalne zmiany i jeden lub więcej miejsc, do których trafiają. Jest to jednostka konfiguracji, jednostka monitorowania i jednostka wdrożenia. Wszystko inne w Perfuse istnieje, aby służyć kanałom.

4.1 Anatomia

Plik kanału składa się z następujących części, w kolejności, w jakiej są stosowane:

Oprócz tego istnieją części, które mają zastosowanie do całego kanału: scripts, shadow, contract, tables, attachments, group i enabled. Każda z nich jest opisana w dokumentacji kanału.

4.2 Jedno źródło, wiele miejsc docelowych

Ta asymetria jest zamierzona i warto ją zrozumieć na początku, ponieważ jest to najczęstsze źródło nieporozumień, gdy przychodzi się z innego silnika.

Kanał ma dokładnie jedno źródło. Jeśli wiadomości pochodzą z dwóch miejsc, to są to dwa kanały. Próba wyrażenia tego jako jeden kanał powoduje utworzenie konfiguracji, w której awaria w którymkolwiek transporcie wygląda tak samo z zewnątrz, a ruch z dwóch kanałów jest mieszany w statystykach — więc spadek w jednym jest ukryty przez drugi.

Kanał ma dowolną liczbę miejsc docelowych, a są one niezależne. Awaria jednego nie powoduje zatrzymania innych, a każde ma własną kolejkę, własną politykę ponawiania i własny rekord dostarczania. Wiadomość, która dotarła do trzech z czterech miejsc docelowych, jest rejestrowana jako dokładnie taka, a nie jako sukces lub porażka.

4.3 Miejsca docelowe nie tworzą łańcucha

Każde miejsce docelowe otrzymuje wiadomość w postaci, w jakiej była po przekształceniach kanału. Miejsce docelowe nie otrzymuje wyjścia z poprzedniego miejsca docelowego.

To ma znaczenie, gdy miejsce docelowe ma własne przekształcenia, co może się zdarzyć. Przekształcenia te są stosowane tylko do kopii tego miejsca docelowego. Częstym błędem jest umieszczenie zmiany w pierwszym miejscu docelowym i oczekiwanie, że drugie je zobaczy.

Jeśli naprawdę potrzebujesz łańcucha — wyjście jednego przepływu zasilającego inny — użyj miejsca docelowego kanału, które wysyła do innego kanału o nazwie. To jest jawne, pojawia się w historii wiadomości jako dwa kanały i może być monitorowane jako dwie rzeczy, co ukryty łańcuch nie może.

4.4 Nazewnictwo

Nazwa jest tożsamością kanału wszędzie: w pliku, w magazynie wiadomości, w alertach, w rejestrze inspekcji i w adresie URL. Zmiana jej nie jest przemianowaniem; jest to nowy kanał, a historia starego kanału pozostaje pod starym nazwą.

group jest oddzielnym elementem i służy do organizowania interfejsu. Grupa nie ma wpływu na zachowanie, a grupowanie kanałów nie powoduje, że dzielą one coś.

4.5 Włączanie i wyłączanie

enabled: false zatrzymuje uruchomienie kanału bez jego usunięcia. Jego konfiguracja, historia i statystyki pozostają.

Wyłączony kanał nie jest wstrzymany. Jego źródło nie nasłuchuje, więc nadawca próbujący połączyć się otrzymuje odmowę połączenia, a nie zawieszone połączenie. Dla MLLP jest to prawidłowe zachowanie — nadawca będzie buforował i ponawiał — ale oznacza to, że log błędów nadawcy wypełni się, więc wyłączony kanał nie jest zamiennikiem zaaranżowania przerwy z kimś, kto wysyła.

4.6 Gdzie znajdują się kanały

Jeden plik YAML na kanał, w katalogu podanym przez -channels. Nazwa pliku nie jest nazwą kanału; klucz name jest. Zalecane jest trzymanie ich takich samych, a nic nie egzekwuje tego.

Pliki są odczytywane ponownie bez restartu. Plik, który nie jest w stanie sparsować, jest zgłaszany, a poprzednio załadowana wersja nadal działa, więc błąd składniowy nie może wyłączyć działającego kanału.

4.7 Szyfrowanie własnego nasłuchiwania kanału

Kanał, który nasłuchuje na porcie, jest własnym serwerem, a jego TLS jest oddzielony od TLS w interfejsie sieciowym Perfuse. Ustawienie jednego nie ustawia drugiego. Dla źródła HTTP ustawienia znajdują się pod TLS i limity w źródle.

Włączenie TLS wymaga podania certyfikatu i klucza prywatnego. Wymaganie certyfikatu klienta powoduje, że staje się to mutualne TLS: nadawca musi przedstawić certyfikat podpisany przez wskazaną władzę, co jest uwierzytelnieniem, więc odbiornik z włączoną funkcją nie potrzebuje również współdzielonego tokenu — choć posiadanie obu nie jest błędem.

Władza jest pytana tylko raz, gdy certyfikat klienta jest wymagany, i jest pomijana w pliku do tego czasu. Kanał nazywający władzę, która nie jest konsultowana, wygląda tak, jakby nadawcy byli weryfikowani, gdy tak nie jest.

Odbiornik MLLP ma te same ustawienia pod Szyfruj ten odbiornik, z jedną różnicą wartą wymienienia: w MLLP certyfikat klienta jest jedyną dostępną metodą uwierzytelnienia. Nie ma tokenu ani nagłówka, więc odbiornik bez niego akceptuje wiadomości z dowolnego hosta, który może dotrzeć do portu.

Dwa limity znajdują się obok niego. Przestań czytać po określonym czasie, ponieważ nadawca, który otwiera połączenie i przestaje pisać, w przeciwnym razie utrzymuje połączenie otwarte. I największa zaakceptowana wiadomość, w bajtach, ponieważ zero oznacza brak limitu, a limit jest wtedy pamięcią — nadawca, który publikuje gigabajt, jest odrzucany, zamiast być pochłonięty.

4.8 Walidacja

Kanał jest sprawdzany, gdy się ładuje, a sprawdzenia są odmowami, a nie ostrzeżeniami, gdzie alternatywą byłoby uruchomienie kanału, który działa i robi coś złego.

Przykłady rzeczy, które są odrzucane bezwzględnie: miejsce przeznaczenia bez typu, transformacja odnosząca się do ścieżki, która nie może istnieć w deklarowanym typie danych, tryb potwierdzenia, którego transport źródłowy nie może dostarczyć, i recepta na leki z listy II z powtórzeniami.

Różnica, którą Perfuse próbuje utrzymać, polega na tym, że wszystko, co mogłoby wyprodukować wiarygodnie wyglądający błędny wynik, jest odrzucane, a wszystko, co jest po prostu niezwykłe, jest dozwolone i zgłaszane. Kanał, który nie może być błędny, jest bardziej wartościowy niż kanał, który się uruchamia.

5 Przepływ wiadomości

Ten rozdział opisuje jedną wiadomość od momentu jej przybycia do momentu jej dostarczenia lub poddania się. Zrozumienie tego porządku jest najszybszym sposobem, aby dowiedzieć się, gdzie zmiana należy, i dlaczego coś nie dzieje się.

5.1 Kolejność zdarzeń

1. Arrival. The source accepts the bytes. For a stream transport this includes de-framing — finding where one message ends and the next begins.
2. Parse. The bytes become a tree according to the channel's dataType. A message that cannot be parsed stops here and is recorded as a parse failure.
3. Record. The message is written to the message store as received, before anything modifies it. This is what makes replay and reprocessing possible.
4. Filter. If the channel has a filter, it decides whether to accept the message. A rejected message is recorded as filtered, which is a normal outcome and not an error.
5. Transform. The channel's transformations run in order, each against the result of the last.
6. Fan out. Each destination gets a copy of the transformed message, applies its own transformations if it has any, and delivers.
7. Record the outcome. Per destination: delivered, queued, failed, or filtered.
8. Acknowledge. If the source expects an acknowledgement, it is generated and sent. By default this happens here, after delivery — see below.

5.2 Kiedy potwierdzenie jest wysyłane

To jest najważniejsze ustawienie w kanale, ponieważ decyduje, co nadawca jest obiecywany. To jest ack.when, i ma dwie wartości.

on_delivery jest domyślnym. Potwierdzenie jest wysyłane tylko po tym, jak każde włączone miejsce przeznaczenia zaakceptuje wiadomość. Pozytywne potwierdzenie oznacza zatem, że dane faktycznie dotarły gdzieś, co jest najsilniejszym twierdzeniem, które silnik w środku może uczciwie złożyć.

on_receipt potwierdza, jak tylko wiadomość jest sparsowana i umieszczona w kolejce, zanim jakiekolwiek miejsce przeznaczenia zostanie zapisane.

Perfuse domyślnie używa on_delivery, ponieważ obiecywanie dostarczenia i potem utraty wiadomości jest gorsze niż opóźnienie. Pod on_receipt wiadomość, która została potwierdzona, może nadal zostać utracona, jeśli proces umrze z zadaniami w kolejce — nadawca uważa, że jest dostarczona, nic w górę nie prześle jej ponownie, a jedynym zapisem, że istniała, jest w sklepie Perfuse.

5.3 Kiedy wybrać on_receipt

Przypadek dla niego jest rzeczywisty i dotyczy limitów czasu. Nadawca MLLP, który nie otrzyma potwierdzenia w ciągu kilku sekund, zwykle wysyła ponownie, więc powolne miejsce przeznaczenia pod on_delivery powoduje duplikaty zamiast opóźnień. Jeśli jedno miejsce przeznaczenia jest powolnym archiwum lub systemem, który jest regularnie niedostępny, on_delivery łączy limit czasu nadawcy z najgorszym przypadkiem tego miejsca przeznaczenia.

Wymiana jest jawna: on_receipt przenosi ryzyko z duplikatów na utratę. Wybranie go oznacza zaakceptowanie, że potwierdzona wiadomość może być utracona w przypadku awarii, i warto ją łączyć z alertowaniem głębokości kolejki, aby zauważyć, że kolejka, która przestała się wylewać. Zobacz alertowanie.

5.4 Gdzie wiadomość jest rejestrowana

Przed filtrem, a zatem przed jakąkolwiek transformacją. Trzy konsekwencje:

• Wiadomość odrzucona przez filtr jest nadal w magazynie. Można zobaczyć, co dotarło i potwierdzić, że filtr działał poprawnie.
• Ponowna odtwarzanie i przetwarzanie zawsze rozpoczyna się od tego, co rzeczywiście dotarło, a nie od częściowo przekształconej wersji.
• Zmiana transformacji może być przetestowana na rzeczywistym ruchu historycznym, ponieważ oryginał jest nadal dostępny. Zobacz testowanie.

Przekształcona forma jest również rejestrowana, dla każdego miejsca docelowego, obok wyniku. Magazyn zawiera więc to, co dotarło, co zostało wysłane i co się stało — co jest potrzebne do śledztwa.

5.5 Awaria na każdym etapie

Istotna asymetria: błąd parsowania jest trwały, a błąd dostarczania zwykle nie. Ponowne próby dostarczania nieprawidłowej wiadomości nigdy nie pomogą, więc nie są ponawiane. Ponowne próby niedostępnego miejsca docelowego zwykle pomogą, więc są ponawiane.

5.6 Kolejność

W ramach jednego miejsca docelowego, wiadomości są dostarczane w kolejności, w jakiej dotarły, a wiadomość, która kończy się niepowodzeniem i wchodzi do kolejki, zachowuje swoje miejsce — późniejsze wiadomości czekają za nią, zamiast ją wyprzedzać.

Jest to odpowiedni domyślny ustawienia dla danych klinicznych, gdzie przyjęcie, po którym następuje wypisanie, dostarczane w złej kolejności jest gorsze niż oba są spóźnione. Oznacza to również, że jedna zatruta wiadomość może zablokować kolejkę, co jest powodem, dla którego warto ostrzegać o głębokości kolejki.

Pomiędzy miejscami docelowymi nie ma gwarancji kolejności, ponieważ są one niezależne. Dwa miejsca docelowe nie muszą otrzymywać tej samej wiadomości w tym samym czasie, a szybkie miejsce może być kilka wiadomości przed wolnym miejscem.

5.7 Współbieżność

Źródło może obsługiwać kilka połączeń jednocześnie, ograniczonych przez max_connections. Wiadomości z różnych połączeń są przetwarzane współbieżnie.

Oznacza to, że kolejność przyjścia dwóch wiadomości wysłanych jednocześnie przez dwa połączenia nie jest określona i nie może być — naprawdę dotarły w tym samym czasie. Nadawca, który potrzebuje kolejności, musi użyć jednego połączenia, co robi prawie każdy z nich.

6 Przekształcenie

Przekształcenia zmieniają wiadomość. Są to lista, są wykonywane w kolejności, a każdy z nich widzi wynik poprzedniego.

Przekształcenia Perfuse są deklaratywne: każdy krok nazwuje operację i pole, do którego się odnosi. Nie ma języka skryptowego w zwykłej ścieżce. Jest to celowe ograniczenie, a uzasadnienie znajduje się w why not a script poniżej.

6.1 Kroki

Każdy krok akceptuje również description, które pojawia się w śladzie i w interfejsie, oraz when, które czyni krok warunkowym.

Krok jest zapisany jako nazwa operacji z własnym blokiem:

transformations:
  - description: Our record number, not theirs
    set:
      path: PID-3.4
      value: RIVERSIDE
  - copy:
      from: PID-19
      to: PID-3.1
      default: UNKNOWN
  - map:
      path: PID-8
      table:
        M: Male
        F: Female

6.2 Wyczyszczenie, usunięcie i różnica

clear pozostawia pole obecne i puste. remove usuwa je całkowicie.

Dla HL7 ta różnica jest realna i dochodzi do odbiorcy. Puste pole mówi „mam to pole i nie ma wartości”. Nieobecne pole nie mówi nic w ogóle. Niektóre systemy odbiorcze traktują pierwsze jako polecenie, aby wykasować przechowywaną wartość, a drugie jako polecenie, aby ją pozostawić — co jest różnicą między usunięciem zarejestrowanej alergii pacjenta a niezmienieniem jej.

Jeśli nie wiesz, które odbiorca chce, zapytaj. Odgadnięcie ma pięćdziesięcioprocentową szansę na ciche zniszczenie danych po drugiej stronie.

6.3 Warunki

when przyjmuje wyrażenie i krok jest wykonywany tylko wtedy, gdy jest ono prawdziwe:

  - when: MSH-9.2 == "A08"
    set:
      path: EVN-1
      value: A08

Krok, którego warunek jest fałszywy, jest rejestrowany jako pominięty, a to jest raportowane oddzielnie od kroku, który został wykonany i nie zmienił niczego. Ta różnica jest celem debugera krokowego i jest opisana w debugowaniu: fałszywy warunek i brak pola wyglądają identycznie z zewnątrz i oznaczają przeciwne rzeczy.

6.4 Ścieżki

Ścieżka adresuje pole: PID-5 jest piątym polem PID, PID-5.1 jego pierwszym składnikiem, PID-3(2) drugą powtórką PID-3, a OBX(3)-5 piątym polem trzeciego segmentu OBX.

Dwie zachowania warte poznania:

• set tworzy ścieżkę, którą adresuje, w tym strukturę pośrednią. Jest to wygodne i oznacza, że set nigdy nie może udowodnić, że pole było nieobecne — po kroku ono istnieje. Aby przetestować, co się dzieje, gdy pole jest nieobecne, użyj copy ze ścieżki, która tam nie jest.
• Ścieżka bez indeksu adresuje każdą powtórkę i każde wystąpienie, tak jak w filtrze (gdzie PID-3.5 == "SS" jest prawdziwe, gdy jakakolwiek powtórka jest). Na komunikacie z pięcioma segmentami OBX, set na OBX-5 zmienia wszystkie pięć, a set na PID-3.4 ponownie nazwuje każdy identyfikator w PID-3, w tym numer narodowy. Aby zmienić jeden, podaj jego indeks: PID-3(1).4, OBX(2)-5.

6.5 Błędy

Większość kroków nie ma nic, co mogłoby zawieść. Ustawienie wartości, wyczyszczenie pola lub skopiowanie z nieobecnego pola ze standardową wartością są wszystkie zdefiniowane dla każdego wejścia.

date jest wyjątkiem, ponieważ wartość, która nie jest datą, którą rozpoznaje, nie ma poprawnej konwersji. Przyjmuje on_error:

• fail — domyślnie. Wiadomość zatrzymuje się i jest rejestrowana jako awaria transformacji.
• keep — pozostaw oryginalną wartość bez zmian.
• clear — wyczyść pole.

Domyślnie jest fail, ponieważ znacznik czasu, który niekonwertuje się cicho, jest gorszy niż wiadomość, która nie dotarła. Data w niewłaściwym formacie nadal wygląda jak data, więc przechodzi walidację odbiorcy i ląduje w rekordzie jako niewłaściwy dzień.

keep jest uzasadnione, gdy odbiorca toleruje oba formaty, a gdy jest używany, ślad oznacza zmianę jako zamierzoną, więc nie czyta się jak krok, który awaryjnie zamilkł.

6.6 Kolejność ma znaczenie, a ślad ją pokazuje

Każdy krok widzi dane wyjściowe poprzedniego kroku. Dwa konsekwencje, które łapią ludzi:

• map po case widzi wartość przekonwertowaną przez case, więc klucze jego tabeli muszą odpowiadać przekonwertowanej formie. Tabela M/F po kroku z małymi literami nie pasuje do niczego, w milczeniu, ponieważ wartość nie w tabeli pozostaje niezmieniona.
• copy z pola, które późniejszy krok usuwa, nadal działa, ponieważ został uruchomiony jako pierwszy. Odwrotność nie działa.

Oba są widoczne w widoku krokowym, który pokazuje całą wiadomość po każdym kroku, a nie tylko zmianę. Zobacz debugowanie.

6.7 Sugestie mapowań i to, co z nimi zrobić

AI Mapper proponuje mapowania między zestawem pól źródłowych a zestawem docelowych. Jego definicją jest to, że odstępuje: poniżej progu ufności wstrzymuje się od zgadywania, ponieważ pewne błędne mapowanie w systemie klinicznym jest gorsze niż brak mapowania w ogóle.

6.7.1 Daj mu coś, o czym może być pewny

Nazwa sama w sobie jest słabym dowodem, nawet gdy dokładnie się zgadza. PatientMRN przeciw PatientMRN uzyskuje wynik 68, który odstępuje przy domyślnym progu 70.

Silnik wie, co oznacza ścieżka HL7 — powie Ci PID-7 is Date/Time of Birth i oceni Twoją nazwę pola względem tego, a nie względem ciągu PID-7, który nie ma wspólnych znaków z niczym. Lokalnie zdefiniowany segment Z oznacza wszystko, co zdecydowało Twoje miejsce, więc nic nie jest twierdzone o tym.

To daje mapowanie w większości. Aby je dokończyć, dostarcz obie połowy:

• Przykładowe wartości dla pola źródłowego, po znaku równości: ZPI-1 = MRN00412, MRN00998
• Rodzaj wartości, jaki docelowe pole zawiera, w ten sam sposób: PID-3.1 = mrn. Rodzaje to mrn, npi, ssn, phone, date i email.

Z tymi danymi silnik może zobaczyć, że wartości zgadzają się z rodzajem docelowym, a sugestia opiera się na czymś więcej niż tylko nazwie.

6.7.2 Zatwierdzenie jest jednym przyporządkowaniem na raz

Każda sugestia ma własną skrzynkę zatwierdzeń. Nie ma „zaakceptuj wszystko powyżej 80%”, celowo: silnik już wykorzystał ufność, aby zdecydować, czy zaproponować przyporządkowanie, a co pozostaje, to sąd o tym polu w tym kanale. Liczba nie jest tym sądem.

Wstrzymanie się nie może być zatwierdzone w ogóle. Nie ma skrzynki, nawet wyłączonej, a ekran mówi, że silnik nie wie. Jeśli znasz odpowiedź, mapuj ją ręcznie — to inny akt niż zgadzanie się z sugestią.

Sugestia poniżej Twojego progu jest wyświetlana bez skrzynki, oznaczona jako poniżej niej. Warto przeczytać — bliskie przyporządkowanie jest często tym, którego chcesz, a ukrywanie go pozostawiłoby Cię w niepewności, czy silnik brał je pod uwagę — ale nie do zatwierdzenia, ponieważ Twój próg jest linią, którą narysowałeś.

6.7.3 Dwie rzeczy do zrobienia z tym, co zatwierdziłeś

Dodaj je do kanału zmienia każde przyporządkowanie w krok kopiowania. Działa to tylko wtedy, gdy źródłem jest ścieżka w wiadomości, taka jak ZPI-1, ponieważ krok kopiuje z jednego miejsca w wiadomości do innego. Kroki są umieszczane w pliku kanału i zaczynają obowiązywać, gdy zostanie ponownie załadowany — nic nie zmienia się w ruchu do tego czasu. Opis każdego kroku rejestruje ufność, z jaką został on zaproponowany, i to, że osoba go zatwierdziła, co sprawia, że jest on rozliczalny sześć miesięcy później.

Pobierz jako przepis jest odpowiedzią na bardziej powszechny przypadek: przyporządkowanie z nazwy kolumny, klucza JSON lub nazwy pola producenta. Są to prawdziwe przyporządkowania, a kanał nie może odczytać takiego pola bezpośrednio, więc krok nie może go wyrazić. Przepis rejestruje je jako zatwierdzone i może być udostępniony.

6.8 Dlaczego nie skrypt

Mirth umieszcza transformator JavaScript w centrum każdego kanału i jest to najbardziej elastyczny projekt dostępny. Perfuse oferuje skryptowanie — zobacz klucz scripts w odniesieniu do kanału — ale nie robi tego zwykłej ścieżki, z trzech powodów, które wynikają z tego, co się nie udaje w praktyce.

Declaratywny krok może być inspekcjony. Perfuse może powiedzieć, że krok odczytuje PID-5 i zapisuje PID-8, zanim go uruchomi, i może więc pokazać ślad na poziomie pola, ostrzec, że krok adresuje ścieżkę, której deklarowany typ danych nie może zawierać, i wygenerować powtórkę na krok.

Declaratywny krok może być rozważany przez interfejs. Budowniczy może zaoferować pola, które istnieją w ruchu tego kanału, a zmiana kroku może być sprawdzona z prawdziwymi historycznymi wiadomościami przed zapisaniem.

I declaratywny krok nie może zrobić czegoś niezwiązanego z wiadomością. Skrypt może wywołać sieć, odczytać system plików lub zależeć od czasu dnia. Gdy kanał, który działał przez dwa lata, zaczyna produkować błędne dane wyjściowe, przyczyna leżąca poza wiadomością jest najtrudniejszym przypadkiem do zdiagnozowania, a usunięcie tej możliwości jest warte więcej niż elastyczność, którą to kosztuje.

Gdzie prawdziwa transformacja nie może być wyrażona deklaratywnie, użyj skryptu i zaakceptuj, że ślad pokaże go jako jeden nieprzezroczysty krok.

6.9 Co skrypt jest dozwolony do zrobienia

Skrypt jest odmówiony wszystkiego poza wiadomością, chyba że jest udzielony, a udzielenia są w sekcji Skrypty budowniczego. To jest celowo inaczej niż Mirth, który daje każdemu skryptowi wszystkie — więc tam, transformator może cicho zacząć odczytywać system plików po kopiowaniu i wklejeniu.

Istnieją trzy.

Odczyt i zapis plików wymaga od Ciebie podania katalogów, których może używać, a kanał udzielający dostępu do plików bez nich jest odrzucany podczas ładowania. To wymaganie jest całą różnicą między dostępem do plików a nieograniczonym dostępem do plików: udzielenie mu bez katalogów kiedyś dotarło do całego systemu plików, w tym bazy danych Perfuse, która zawiera hasła haseł, hasło konta usługi LDAP i tajemnicę klienta OIDC. Tworzenie kanału wymaga tylko roli edytora, więc eskalacja została ukończona w momencie, gdy administrator uruchomił kanał.

Zapytanie bazy danych używa połączeń skonfigurowanych na kanale. Skrypt z tym może odczytać wszystko, co te poświadczenia mogą.

Route messages to other channels pozwala skryptowi wysłać wiadomość do innego kanału, co jest sposobem, w jaki pętla między dwoma kanałami staje się możliwa.

Udzielenie możliwości kanałowi bez skryptów nie robi nic, a wygenerowany plik pomija cały blok w tym przypadku.

6.10 Obsługa daty, która nie odpowiada jej formatowi

Krok daty konwertuje z jednego formatu na inny, a interesującym pytaniem jest to, co się dzieje, gdy wartość nie odpowiada formatowi, który twierdzi, że ma.

Domyślnie jest to zatrzymanie wiadomości, i jest to odpowiedni domyślny: sygnatura czasowa, która cicho nie przekonwertowała, jest akceptowana w dół i potem źle odczytana, co jest gorsze niż wiadomość, która głośno nie powiodła się i siedzi tam, gdzie ktoś może ją zobaczyć.

Pozostawienie wartości takiej, jaka jest przechodzi ją w oryginalnym formacie. Poniżej widzi dwie formaty w jednym polu, co jest awarią, której krok istniał, aby ją zapobiec — ale jest to odpowiedni wybór, gdzie pole jest opcjonalne i partner wysyła je niekonsekwentnie.

Opróżnienie pola jest uczciwe i lepsze niż błędny format, ale odbiorca, który wymaga pola, odrzuca wiadomość zamiast.

6.11 Języki skryptowe

Trzy są akceptowane, a który wybrać zależy głównie od tego, czy migrujemy. Wartość jest umieszczona w kluczu language skryptu:

JavaScript jest domyślny, a skrypt bez oznaczenia jest traktowany jako JavaScript. Jest tutaj z powodu obowiązku zgodności, a nie preferencji: skrypty Mirth są napisane w JavaScript i witryna przechodząca ma tysiące linii kodu. Obejmuje to obsługę E4X, dawnej rozszerzenia języka, które skrypty Mirth używają do XML i które musi być przetłumaczone, zanim cokolwiek będzie mogło być sparsowane.

Lua (lua) jest lepszym wyborem dla każdego, kto nie migruje. Mniejsza środowisko uruchomieniowe, brak łańcucha prototypów do nadużywania i tabele indeksowane liczbami całkowitymi, które lepiej odpowiadają adresowaniu segmentów i pól niż tabele JavaScript. Jego standardowa biblioteka jest wystarczająco mała, aby ją wyliczyć, co sprawia, że piaskownica jest łatwiejsza do zaufania.

WebAssembly (wasm) nie jest językiem, ale skompilowanym modułem, a pole wymaga bajtów pliku .wasm zamiast źródła. Użyj go, gdy transformacja już istnieje w skompilowanym języku lub gdy jest wystarczająco ciężka, aby koszt czasu uruchomieniowego miał znaczenie.

Jego kontrakt jest celowo najprostszym dostępnym: moduł odczytuje wiadomość ze standardowego wejścia i zapisuje wynik na standardowym wyjściu. Bajty wejściowe, bajty wyjściowe — co każdy łańcuch narzędziowy już robi, i co ktoś testujący moduł na własnej linii poleceń już ma. Alternatywą był eksportowany moduł nad pamięcią liniową, który jest szybszy i wymaga, aby każdy autor modułu zgodził się co do alokacji, kodowania ciągów i zwalniania pamięci; dla czegoś, co jest uruchamiane raz na wiadomość, ten handel nie jest wart.

Cokolwiek moduł zapisuje na standardowym wyjściu błędu staje się liniami logowania, więc może wyjaśnić się w sposób, w jaki skrypt wywołuje logger.

6.11.1 Co oznacza wyjście

Reguły są takie same dla wszystkich trzech języków, a nie nowe dla każdego środowiska uruchomieniowego, więc widoczne zachowanie skryptu — co może zobaczyć, co może zrobić, jak długo może potrwać, co oznacza werdykt filtru — jest zdefiniowane raz.

Dla transformatora, preprocesora lub pisarza puste wyjście oznacza, że wiadomość nie została zmieniona. Spadanie z końca skryptu pozostawia wiadomość w spokoju; traktowanie braku wyjścia jako „wiadomość jest teraz pusta” spowodowałoby odrzucenie ruchu z technicznego powodu.

Moduły WebAssembly są skompilowane, gdy kanał jest ładowany, a nie przy pierwszej wiadomości. Skompilowanie nie jest bezpłatne — moduł zbudowany z języka, który przywozi własne środowisko uruchomieniowe, może zająć setki milisekund — i płacenie za to w czasie ładowania oznacza, że pierwsza wiadomość przez kanał nie jest tajemniczo wolniejsza niż reszta.

6.12 Współdzielone tabele mapowania

Inna połowa tego samego problemu: kody płci i klasy pacjenta są tłumaczone identycznie we wszystkich kanałach, które ich dotykają, a tabela wewnątrz kanału jest tabelą tylko dla tego kanału.

# codes.codeset.yaml
tables:
  - name: sex-to-lab
    describes: the hospital's sex codes into the numeric codes the lab expects
    decided_by: Dave, during the 2019 migration
    decided_on: 2019-04-11
    source: the lab's interface specification, version 3
    entries:
      - from: M
        to: "1"
      - from: U
        to: "9"
        why: the lab has no 'unknown', and 9 is its 'not stated'

# in the channel
tables:
  - codes.codeset.yaml
transformations:
  - map:
      path: PID-8
      use: sex-to-lab

Pochodzenie jest punktem. Większość tego, co utrudnia utrzymanie interfejsu, polega na tym, że nikt nie wie, *dlaczego* mapowanie jest w taki, a nie inny sposób, a osoba, która wiedziała, odeszła. Mapowanie z powodem może być dyskutowane; bez powodu staje się czymś, czego nikt nie odważy się zmienić i usunąć.

Tabele są tworzone i zmieniane w Buduj → Tabele, a także w pliku. Zapisywanie tabeli, która jest w mocy, restartuje uruchomione kanały, które ładują jej plik, więc następny komunikat używa jej; wersja robocza nie restartuje niczego.

6.12.1 Wersje i daty obowiązywania

Tabela może przechowywać kilka edycji pod jedną nazwą, z których każda ma swój własny version. Edycja, którą używa komunikat, jest wybierana, gdy komunikat przychodzi: spośród zatwierdzonych edycji, których daty obejmują ten dzień (UTC), ta, która zaczęła się najpóźniej. Zatem zmiana kodu uzgodniona na pierwszy dzień następnego miesiąca jest wprowadzana teraz i samoczynnie wchodzi w życie.

tables:
  - name: sex-to-lab
    version: "3"
    effective_from: 2026-11-01   # optional; empty means from the start
    effective_until: 2027-10-31  # optional; the last day it applies
    source_system: urn:local:hospital-sex
    target_system: http://terminology.hl7.org/CodeSystem/v2-0001
    entries: [...]

• status jest approved (domyślnie), draft (używany przez nic) lub retired

(przechowywany dla zapisu, używany przez nic).

• Dwie edycje jednej nazwy z tą samą wersją lub dwie zatwierdzone edycje

rozpoczynające się tego samego dnia, są odrzucane podczas ładowania pliku.

• Zapisywanie nowej wersji bez daty rozpoczęcia, podczas gdy inna jest zatwierdzona,

datuje ją od dziś, więc zastępuje tę, która obowiązuje. Ta, która sama zaczęła się dzisiaj, jest wycofana, ponieważ dwie edycje rozpoczynające się tego samego dnia nie pozostawiają żadnej reguły.

• Własne default i strict kroku mapowania są używane, gdy krok je ustawia;

w przeciwnym razie używane są te z tabeli.

• Na ekranie Tabel, Pokaż wersje wyświetla każdą edycję z jej statusem,

kim ją zapisano i kim zatwierdzono, a Porównaj z wersją obowiązującą pokazuje, co edycja dodaje, usuwa i zmienia.

6.12.2 Potwierdzenie

Z Ustawienia → Dane → Tabele mapowania „Zmiany w tabeli mapowania wymagają zatwierdzenia przez drugą osobę” (data.tableApproval) włączone, każde zapisywanie jest wersją roboczą, a osoba, która ją zapisuje, nie może jej zatwierdzić: ktoś inny to robi, opcjonalnie podając dzień, w którym wchodzi w życie. Zatwierdzona edycja nie może być edytowana na miejscu; Nowa wersja z tej kopiuj ją do następnej wersji. Zatwierdzenie, wycofanie i usunięcie wersji roboczej są zapisywane w rejestrze inspekcji, a zatwierdzenie restartuje uruchomione kanały, które ładują plik.

6.12.3 Wartości bez mapy

Każda wartość, której szukał krok mapowania i nie znalazł, jest liczbana, per tabela, z kanałami, przez które przeszła, i kiedy została po raz pierwszy i ostatni raz zobaczona. Ekran Tabele wyświetla je, najczęstsze jako pierwsze. Mapuj otwiera tabelę z tą wartością już dodaną jako wiersz; Odrzuć usuwa ją, aż do momentu, iedy zostanie ponownie zobaczona. Wartości dłuższe niż 64 znaki nie są rejestrowane (nie są kodami), a lista zachowuje to, co zostało zobaczone w okresie przechowywania wiadomości. Lista jest przechowywana w terminology.db obok głównej bazy danych.

6.12.4 Systemy kodów

Opublikowane systemy kodów mogą być importowane z plików ich wydawców, pod Systemy kodów na ekranie Tabele (administratorzy) lub z POST /api/terminology/import?format=… i plikiem jako treścią:

Żaden nie jest dostarczany z Perfuse: LOINC, SNOMED CT, RxNorm i CPT mają własne licencje, a ekran prosi importera o potwierdzenie, że organizacja posiada je (zarejestrowane z importem). Zimportowane kody są używane na trzy sposoby:

• tabela nazywająca source_system lub target_system ma swoje wpisy sprawdzane

podczas zapisywania, a kody, które nie są w systemie, są wymienione w edycji;

• Znajdź kod wyszukuje według kodu lub słów w nazwie;
• serwer FHIR odpowiada CodeSystem/$lookup i CodeSystem/$validate-code

dla nich (patrz opcje serwera FHIR). Kody ICD-10-CM są akceptowane z lub bez kropki.

Edycje i klasyfikacje narodowe. Edycja SNOMED CT jest importowana z całości pakietu RF2: pojęcia ze swoim rzeczywistym statusem, każdy aktywny opis i zestawy odniesień językowych. Edycja jest znaleziona z pakietu (narodowy moduł z największą liczbą pojęć; edition ją nazywa zamiast) i staje się identyfikatorem wersji URI. language wybiera, którego preferowany termin jest wyświetlany dla każdego pojęcia (sv, da, nl, de, fr, en-GB, en-US ...; angielski w przeciwnym razie), a każdy językowy preferowany termin i w pełni określona nazwa są przechowywane jako nazwy: $lookup zwraca je, a displayLanguage wybiera jeden (de-CH cofa się do de). Edycje nazwane przez Perfuse (Międzynarodowa, Wielka Brytania, Niemcy, Holandia, Szwecja, Dania, Belgia, Irlandia, Norwegia, Szwajcaria, Estonia, Hiszpania) są wymienione przez GET /api/terminology/editions, identyfikatory modułów nie są sprawdzane przeciwko opublikowanemu źródłu oznaczonego jako takie; każda inna edycja jest również importowana, nazwana przez swój moduł.

Pliki ClaML są odczytywane w kodowaniach UTF-8, ISO-8859-1, ISO-8859-15 lub Windows-1252, zgodnie z deklaracją XML. Tytuł każdej kategorii jest jej preferowaną rubryką (zawierającą zakodowane terminy); modyfikator (piąty znak w przypadku miejsca złamania, na przykład) tworzy dodatkowe kody z tytułem modyfikatora po tytule kategorii, chyba że kategoria wyklucza go; blocks=true importuje rozdziały i bloki. Kolumny w tabeli ICD-11 są wyszukiwane według nazwy, ponieważ ich kolejność uległa zmianie między wersjami, a myślniki wskazujące na poziom są usuwane z tytułów. Plik z ogranicznikiem wymaga delimiter (,, ;, | lub tab), encoding (utf-8, iso-8859-1, iso-8859-15, windows-1252) oraz noHeader=true, a kolumny są następnie numerowane od 1. Konsola oferuje ustawienia dla plików UK ICD-10 5th Edition i OPCS-4 (TRUD), francuskiej tabeli etykiet CIM-10 FR (ATIH) oraz eksportu ICD-10-BE; wydawcy tych plików nie zawsze dokumentują ich kolumny, dlatego należy je sprawdzić w nagłówku pliku.

Daty obowiązywania. effective=YYYY-MM-DD importuje wersję, która obowiązuje od tego dnia (na przykład ICD-10-GM co roku 1 stycznia): do tego czasu wyszukiwanie, które nie określa wersji, zwraca wersję już obowiązującą, a ekran wyświetla datę.

ICD-11 od WHO. Z zarejestrowanym klientem w icd.who.int (Ustawienia → Dane → Systemy kodów, serve -icd11-client-id i -icd11-client-secret; -icd11-release, domyślnie 2025-01), kody ICD-11, które nie są importowane, są wyszukiwane w API WHO ICD (codeinfo, a następnie tytuł encji) i przechowywane przez dzień. Postkoordynowany kod (NC72.2&XK9K) jest sprawdzany w całości, więc kombinacja ICD-11, której nie zezwala, jest odrzucana, a jego nazwy wyświetlania każdej części ("Złamanie szyjki kości udowej (prawa)").

ICD-11 bez wysyłania kodów. WHO publikuje to samo API jako kontener (whoicd/icd-api, bezpłatnie, Intel i Arm). Uruchom go w swojej sieci i podaj jego adres (serve -icd11-url http://icd-api.local, lub Adres API ICD w tych samych ustawieniach); nie jest wymagany klient, a żaden kod nie opuszcza Twojej sieci. Przetestowane z tym kontenerem (wersja 2.6.0, wydanie 2025-01 w języku angielskim i francuskim).

7 Filtrowanie

Filtr decyduje, które wiadomości akceptuje kanał. Jest to jeden wyrażenie na kanale, oceniany po przetworzeniu i zarejestrowaniu wiadomości, przed jakąkolwiek transformacją.

filter: MSH-9.1 == "ADT" && MSH-9.2 in ("A01", "A03", "A08")

Wiadomość, którą filtr odrzuca, jest rejestrowana z wynikiem filtered. Jest to normalny wynik, a nie błąd, i nie wywołuje alertu ani nie powoduje negatywnej potwierdzenia.

7.1 Filtrowany nie jest tym samym co nieudany

Ta różnica jest warta podkreślenia, ponieważ łączenie ich może ukryć prawdziisty problem.

Filtrowana wiadomość została poprawnie odrzucona: nie była przeznaczona dla tego kanału. Nieudana wiadomość była taka, którą ten kanał powinien był obsłużyć, ale nie mógł. Jeśli obie były rejestrowane w ten sam sposób, kanał, który zaczyna filtrować każdą wiadomość, wyglądałby dokładnie jak kanał, który filtruje większość swojego ruchu, co jest normalnym stanem wielu kanałów.

Dlatego statystyki liczą je oddzielnie, reguły alertów traktują je inaczej, a interfejs wyświetla je w różnych kolorach. Wzrost liczby filtrowanych wiadomości może oznaczać, że nadawca zaczął wysyłać coś nowego; wzrost liczby nieudanych wiadomości oznacza, że coś jest nie tak.

7.2 Co filtr może odczytać

Dowolne pole w sparsowanej wiadomości, przy użyciu tych samych ścieżek, których używają transformacje. Filtrowanie odbywa się przed transformacjami, więc filtr widzi wiadomość tak, jak przybyła — a nie tak, jak zostanie wysłana.

To kolejność jest celowa. Filtrowanie, które czyta wartości po transformacji, decydowałoby o przyjęciu wiadomości na podstawie zmian wprowadzonych pod założeniem, że została przyjęta, co jest sprzeczne i powoduje, że kanały zachowują się w zależności od kolejności dwóch rzeczy, które wydają się niezależne.

7.3 Wyrażenia

Porównania: ==, !=, a dla liczb <, <=, >, >=.

Członkostwo: in ("A01", "A03"), co jest jaśniejsze niż łańcuch || i jest formą, którą produkuje konstruktor.

Połączenie: &&, || i nawiasy. Negacja z !.

Niewystępowanie: ścieżka, która nie jest obecna, jest niezgodna z dowolną wartością, w tym z pustym łańcuchem. Aby jawnie przetestować niewystępowanie, porównaj z absent. Ma to znaczenie, ponieważ brak pola i puste pole są różne, jak opisano w transformation, a filtr, który traktuje je w ten sam sposób, zaakceptuje wiadomości, które zostały napisane, aby je wykluczyć.

7.4 Błąd w filtrze jest odmową

Jeśli filtr sam w sobie nie może być oceniony — sformatowane wyrażenie, które przeszło walidację, lub porównanie, które nie może być wykonane — wiadomość jest odrzucona, a błąd jest rejestrowany przeciwko niej.

Odrzucenie zamiast akceptacji jest bezpieczniejsze z dwóch, ale żadne z nich nie jest dobre, a wynik jest rejestrowany oddzielnie od zwykłej odmowy filtru, aby mógł być zaalarmowany. Filtrowanie, które kończy się błędem na każdej wiadomości, cicho upuszcza cały strumień, i nie powinno wyglądać jak filtr, który działa.

7.5 Filtruj na źródle, gdzie możesz

Filtr działa po tym, jak wiadomość przekroczyła sieć i została sparsowana. Niektóre źródła mogą filtrować wcześniej i taniej:

• Źródło brokera przyjmuje selector, który filtruje na brokerze. Wiadomości, których ten kanał nie chce, nie przekraczają sieci w ogóle. Na wspólnej kolejce jest to różnica między odczytaniem stu wiadomości dziennie a stu tysiącami.
• Zapytanie źródła bazy danych decyduje, co zwraca.
• Wzorzec źródła pliku decyduje, które pliki są pobierane.

Filtrowanie na źródle jest decyzją wydajnościową, a nie poprawnościową, i ma jeden koszt: wiadomość, która została zfiltrowana na brokerze, nigdy nie jest rejestrowana przez Perfuse, więc nie pojawia się w magazynie wiadomości i nie może być zinspekcjonowana później. Jeśli potrzebujesz udowodnić, co nadawca wysłał, zrób to tutaj, a nie tam.

7.6 Testowanie filtru

Filtr może być sprawdzony z prawdziwym historycznym ruchem przed zapisaniem. Interfejs raportuje, ile z ostatnich N zarejestrowanych wiadomości filtr zaakceptuje, odrzuci i wywoła błąd — co jest najszybszym sposobem, aby dowiedzieć się, że wyrażenie, które wygląda dobrze, nic nie akceptuje.

Ślad również pokazuje, dla każdej wiadomości, które pola filtr odczytał i jakie wartości znalazł. Filtrowanie, które niespodziewanie odrzuca wszystko, zwykle czyta ścieżkę, która nie istnieje w tym strumieniu, a ślad ją nazywa.

8 Formaty wiadomości

Typ kanału dataType decyduje, jak bajty są przekształcane w wiadomość. Ma wpływ na analizę, znaczenie ścieżek, sposób zapisu wiadomości oraz które przekształcenia są ważne.

8.1 HL7 v2

Domyślny, a większość przykładów w tej dokumentacji używa go. Segmenty zakończone znakiem powrotu karetki, pola przez |, składniki przez ^, powtórzenia przez ~.

Dwie rzeczy dotyczące kodowania są warte poznania, ponieważ powodują błędy bez ostrzeżeń.

Rozdzielacze nie są stałe. Zadeklarowane są w MSH-1 i MSH-2 każdej wiadomości, a Perfuse odczytuje je stamtąd, zamiast przyjmować pipe. Nadawca, który używa innego separatora pól, parsuje poprawnie.

Konsekwencją jest to, że wiadomość, której separatory zostały zastąpione — najczęściej przez procesor tekstu lub klienta poczty elektronicznej zastępujący wyglądem typograficznym — jest analizowana idealnie w pola, które są wszystkie błędne. Nic nie powoduje błędu. To jest powód, dla którego próbka czytnika opisana w testing raportuje, który znak separatora znaleziono, i odmawia wyrażenia zaufania, gdy jest to niezwykłe.

8.2 HL7 v3 i CDA

XML zamiast rozdzielanego. Ścieżki są ścieżkami elementów i atrybutów zamiast pozycji pól.

W v3 wartość jest prawie zawsze atrybutem, a nie tekstem elementu. Porównanie, które czyta tylko tekst elementu, zgłasza, że dwa dokumenty są identyczne, gdy data urodzenia, płeć i każdy identyfikator się różnią. Porównanie Perfuse czyta oba, i to jest powód: alternatywa powoduje błędy bez ostrzeżeń.

Opcje hl7v3 są w odniesieniu do formatu.

8.3 X12

Segmenty zakończone konwencjonalnie przez ~, z rozdzielaczami zadeklarowanymi w segmencie ISA. Podobnie jak HL7, są one odczytywane z wiadomości, a nie założone.

Struktura X12 składa się z kopert w kopertach — wymiany, grupy funkcjonalnej, zestawu transakcyjnego — i jednej wymiany może zawierać wiele transakcji.

Domyślnie interchange jest jedną wiadomością. Cały plik otrzymuje jeden rekord, jeden wynik i jeden wiersz w interfejsie, niezależnie od ilu transakcji zawiera.

8.3.1 X12 XML Mirth

Mirth Connect i Open Integration Engine wyświetlają X12 jako XML: korzeń X12Transaction (lub EDIMessage, gdy dane wejściowe nie zaczynają się od ISA) przenoszący separatory jako atrybuty i jeden element na segment i element nazwany ISA.01, NM1.03.1 itd. Kanały i odbiornicy zbudowane dla Mirth odczytują i zapisują tę postać. Perfuse również odczytuje i zapisuje tę samą postać:

• x12: { arrives_as: xml } on an X12 channel takes that XML in and handles it as the X12 it stands for (the builder's It arrives as choice);
• x12_as: xml on a destination sends the X12 on as that XML (the builder's Send it as Mirth's X12 XML);
• perfuse x12 xml [file] and perfuse x12 from-xml [file] convert at the command line.

Format został napisany z obserwowanego wyjścia i opublikowanego formatu Open Integration Engine 4.6, i jest sprawdzany w stosunku do niego: 25 wygenerowanych wymian i 4 przechowywane przykłady wychodzą bajt po bajcie tak, jak OIE je zapisuje, i z powrotem (patrz weryfikacja). DOCTYPE jest odrzucany, jak w każdym XML, który Perfuse odczytuje.

8.3.2 Dzielenie interchange

Ustawienie split powoduje, że każdy zestaw transakcyjny staje się wiadomością samą w sobie, z własnym rekordem, własnymi metrykami i własnym wierszem. Operator szukający jednego roszczenia znajdzie wtedy jednego roszczenia, a nie pliku czterystu.

Jest wyłączone domyślnie, ponieważ włączenie go mnoży wszystko w dół strumienia — liczbę wiadomości, wiersze, progi alarmowe — a próg dostosowany do plików, który nagle liczy roszczenia, nie będzie już oznaczał tego, co poprzednio. To powinno być decyzją, którą ktoś podjął, a nie domyślnym ustawieniem, które odziedziczył.

8.3.3 Gdy liczby nie sumują się

X12 deklaruje własne liczby — ile segmentów, ile transakcji — a klucz envelope mówi, co zrobić, gdy nie zgadzają się one z tym, co jest rzeczywiście obecne. Te liczby są jedynym mechanizmem, który X12 ma do wykrywania, że połowa pliku roszczeń przybyła.

warn istnieje dla realnej sytuacji: oprogramowanie niektórych partnerów generowało błędne liczby przez lata w inaczej kompletnych plikach, a witryna, która musi przetwarzać te pliki, potrzebuje sposobu, aby to powiedzieć głośno w konfiguracji, zamiast wyłączać walidację w całości.

8.3.4 Transakcje Perfuse odczytuje jako dane strukturalne

Dowolna wymiana X12 może być trasowana, filtrowana i adresowana według ścieżki. Transakcje te są dodatkowo analizowane na pola o nazwach, więc kanał może zapytać, co płatnik zdecydował, zamiast pytać, który element znajduje się na pozycji czwartej.

Perfuse tworzy również 270 zapytanie o uprawnienia i 276 zapytanie o status roszczenia, w Payers → Claims & auth lub za pomocą POST /api/x12/eligibility/build i /api/x12/claimstatus/build. Oba są wersjami HIPAA 5010 (005010X279A1, 005010X212), odczytywane i sprawdzane przed wyświetleniem, a żadne z nich nie jest wysyłane z tej strony: dostarczanie jednego z nich jest zadaniem kanału, gdzie określany jest partner handlowy i jego poświadczenia.

8.3.5 Kwalifikowalność i reguła zawartości danych CAQH CORE

271 to lista segmentów EB, z których każdy reprezentuje pojedynczy fakt: aktywne ubezpieczenie, opłata w wysokości 25 dolarów za rodzaj usługi 30 w sieci lub 800 dolarów indywidualnego dedykowanego wydatku. Czytelnik łączy je w odpowiedź, jakiej oczekuje recepcja - "aktywne ubezpieczenie w ramach Gold PPO 2000; opłata w sieci 25 dolarów; indywidualny dedykowany wydatek w sieci 800 dolarów" - i określa odrzucenie (segment AAA) słowami, wraz z tym, co płatnik mówi, co należy zrobić dalej.

Perfuse sprawdza również odpowiedź względem reguły dotyczącej zawartości danych o uprawnieniach i korzyściach CAQH CORE: dla zapytania o ubezpieczenie planu zdrowotnego (rodzaj usługi 30), aktywna odpowiedź powinna zawierać daty planu, nazwę planu, opłatę, ubezpieczenie, dedykowany wydatek i pozostały dedykowany wydatek zarówno w sieci, jak i poza nią, oraz podstawowe rodzaje usług (1, 33, 35, 47, 48, 50, 86, 88, 98, AL, MH, UC). Każdy z nich jest wymieniony jako spełniony lub brakujący. Jest to interpretacja reguły przez Perfuse, przydatna do odpowiedzi na pytanie „dlaczego ten płatnik nigdy nie mówi nam o dedykowanym wydatku?” - nie jest to certyfikacja CORE, którą przeprowadzają autoryzowani dostawcy testów CAQH.

8.3.6 Wcześniejsza autoryzacja

Perfuse implementuje wcześniejszą autoryzację dwa razy, celowo.

Strona FHIR to to, co CMS-0057-F wymaga od płatników do udostępnienia do 1 stycznia 2027. 278 to to, co płatnicy akceptują dzisiaj, a reguła nie zastępuje go — Da Vinci PAS jest w praktyce mapowaniem na tę transakcję, ponieważ 278 to to, co mówi system zarządzania wykorzystaniem. Silnik czytający tylko połowę FHIR może rozmawiać z systemami, które będą istnieć, a nie z tymi, które istnieją.

Odpowiedź 278 zawiera numer autoryzacji, i to jest pole, dla którego cała transakcja istnieje. Bez niego usługa certyfikowana nie jest rozliczalna: roszczenie wchodzi bez numeru autoryzacji i jest odrzucone z powodu braku jednego, co czyta się w dół jako odrzucenie kliniczne.

Odrzucenie i odmowa rozpatrzenia nie są tym samym

Jest to najdroższe pomylenie w transakcji, a Perfuse raportuje obie oddzielnie.

Oba są odczytywane jako „niezatwierdzone” przez każdego, kto skanuje, a poprawne działania są przeciwne. Odwoływanie się od czegoś, co nikt nie rozstrzygnął, nie daje nic; ponowne przesyłanie odrzucenia powoduje to samo odrzucenie. Parsed outcome określa, co się stało — denied wobec not-considered — a AAA04 zawiera własne zalecenie płatnika, czy wniosek jest w ogóle odzyskiwalny.

Częściowa certyfikacja jest zgłaszana jako partially-certified, a nie jako złożona do zatwierdzenia. Istnieje numer autoryzacji do rozliczenia, więc jest uznawana za zatwierdzoną, ale ilość zatwierdzona nie jest taka sama jak ilość wnioskowana — a praktyka rezerwująca sześć sesji przeciwko trzem zatwierdzonym odkrywa to podczas czwartego roszczenia.

Kod akcji, którego Perfuse nie rozpoznaje, jest zgłaszany jako unknown, a nie jako oczekujący. Oczekujący jest odczytywany jako „czekaj”, a czekanie jest niewłaściwą akcją dla większości tego, czym może być nieznany kod.

Kanał może trasować decyzję bezpośrednio:

filter: HCR-1 == "A3"

Konwertowanie między dwoma

Perfuse konwertuje sparsowaną 278 w Da Vinci PAS ClaimResponse i raportuje każdy osąd, który konwersja wymagała, zamiast tylko wyniku. Konwersja postępuje zgodnie z trzema regułami:

• Żadna decyzja nie zostaje ulepszona. Częściowa certyfikacja pozostaje częściowa, a wniosek, który płatnik odmówił rozpatrzyć, nie staje się odrzuceniem. Oba przypadki są dostępne w oczywistym mapowaniu i oba są błędne w drodze kosztownej.
• Nic nie jest wymyślone, aby wypełnić wymagane pole. Zatwierdzone zdarzenie bez numeru autoryzacji jest raportowane jako takie, a nie otrzymuje wiarygodnego numeru — sfabrykowany numer powoduje roszczenie, które później zostaje odrzucone z powodu, którego nikt nie może śledzić.
• Decyzja przenoszona tylko na poziomie linii jest używana. Płatnik odpowiadający na poziomie usługi może pozostawić zdarzenie bez własnej decyzji; odczytanie tylko na poziomie zdarzenia spowodowałoby, że zostanie ono zgłoszone jako oczekujące, a praktyka czeka na odpowiedź, którą już ma, podczas gdy wygasa zatwierdzenie. Gdzie linie się nie zgadzają, wygrywa najmniej korzystna, ponieważ zdarzenie z odrzuconą linią nie jest zatwierdzeniem.

Zmniejszenie do słownictwa trzech stanów — zatwierdzone, odrzucone, oczekujące — jest dostępne i wyraźne o tym, co odrzuca. Zmniejszenie odmowy do rozpatrzenia daje „odrzucone” i mówi słowami, że właściwą akcją jest poprawiona ponowna zgłoszenie, a nie apelacja.

Sprawdzono przeciwko PAS 2.2.1, a nie tylko przeciwko sobie

The ClaimResponse jest ukształtowany do profilu Da Vinci PAS 2.2.1 i został sprawdzony z oficjalnym walidatorem HL7 załadowanym z opublikowanym pakietem PAS. Pierwsza wersja została sprawdzona tylko przez własne testy Perfuse, a walidator odrzucił ją z sześcioma do ośmiu błędami na zasób. Każdy z nich to coś, co punkt końcowy PAS płatnika również odrzucił:

Poprawiony wynik jest ważny bez błędów dla certyfikacji, odrzucenia i oczekiwania. Ostrzeżenia, które pozostają, to walidator mówiący, że nie może załadować systemów kodów X12, które X12 licencjonuje. Numer autoryzacji jest przenoszony w reviewAction.number, gdzie własny przykład przewodnika umieszcza go, i w preAuthRef, gdy odpowiedź ma tylko jeden.

Walidator nie jest częścią make check, ponieważ potrzebuje Javy i pobrania przewodnika oraz jego zależności. To, co znalazł, jest przechowywane przez test: każda reguła, którą egzekwował, jest potwierdzona, więc zmiana, która ponownie wprowadza jeden z tych błędów, kończy się niepowodzeniem.

The Claims & auth view konwertuje wklejony 278 i pokazuje decyzje, notatki i zasób.

8.3.7 Załączniki i dlaczego wymagają specjalnego przetwarzania

CMS-0053-F czyni 275 standardem HIPAA dla załączników do roszczeń, z wymaganą zgodnością do 26 maja 2028 r. Przenosi dokument — notatkę operacyjną, raport obrazowy, zeskanowany formularz — powiązany z roszczeniem, które wspiera.

The 277 jest drugą połową tej samej rozmowy. Płatnik otrzymuje roszczenie, decyduje, że potrzebuje dokumentacji, i wysyła 277 z prośbą o nią; dostawca odpowiada 275.

Kanał może trasować na kodzie statusu bezpośrednio, ponieważ STC01 jest złożonym i jego drugi składnik to status. Napisany w postaci kanonicznej, ponieważ składnik jest adresowany kropką, a dwie notacje nie mogą być mieszane — STC-1.2 to element 1, składnik 2:

filter: STC-1.2 in ("227", "233", "252", "287")

To są kody, które niezmiennie oznaczają, że dokument jest wymagany. Kategoria statusu w STC-1.1 jest celowo nie używana sama: R4 oznacza wniosek o dokumentację w niektórych przewodnikach implementacyjnych i „przekazany gdzie indziej” w innych, więc filtr na samej kategorii umieściłby ostateczne roszczenia w kolejce do śledzenia.

Dwa identyfikatory decydują, czy załącznik jest kiedykolwiek skojarzony ze swoim roszczeniem, a oba są raportowane: numer kontroli załącznika, który dostawca umieścił na oryginalnym roszczeniu, aby powiedzieć, że dokumentacja nastąpi, i numer śledzenia, który odpowiada prośbie płatnika. Załącznik, który przychodzi z żadnym z nich, jest plikowany i nigdy nie jest połączony z niczym, podczas gdy roszczenie się starzeje.

Formularz 006020, który jest tym, który reguła przyjmuje

CMS-0053-F przyjmuje wersję 006020, a jego 275 różni się od formularza 005010 w dwóch istotnych sposobach.

• Payload jest w BDS, a nie BIN. BDS01 nazwuje filtr, ASC lub B64. BDS02 to długość, a BDS03 to dane.
• Payload jest encją MIME, z nagłówkami mówiącymi, co to jest dokument, i ciałem base64. Z B64 sama encja jest również base64.

Perfuse rozpakowuje encję i raportuje dokument wewnątrz niej, wraz z jego typem zawartości i nazwą pliku. Raportowane bajty są dokładnie tymi, które nadawca zawinął. Encja, która nie może być rozpakowana, pozostawia surowy ładunek w miejscu, z notatką mówiącą, dlaczego.

Budowanie 275. Perfuse również buduje załączniki 006020X314: jeden niespodziewany, który towarzyszy roszczeniu, lub odpowiedź na żądanie płatnika 277. Różnica polega na BGN01 02 przeciwko 11, oraz na tym, czy TRN02 zawiera PWK06 roszczenia, czy TRN02 277. Każda zbudowana wymiana jest ponownie analizowana przed jej zwróceniem, a odpowiedź mówi, czy dokument wewnątrz jest tym, który wszedł.

Struktura pochodzi z dwóch opublikowanych przewodników towarzyszących dla 006020X314: przewodnika CMS esMD i UnitedHealthcare. Nie pochodzi z raportu technicznego X12, który X12 udostępnia na podstawie licencji, a który ten projekt nie posiada.

• Gdzie dwa przewodniki są zgodne, Perfuse ich przestrzega.
• Gdzie się różnią, zadowala oba, jeśli jest to możliwe. CAT02 jest HL dla dokumentu HL7, który używa esMD, i IA dla obrazu, który używa UnitedHealthcare.
• W przeciwnym razie wysyła tylko opcjonalny segment, gdy jest mu podany: identyfikator roszczenia esMD REF*X1 i data usługi UnitedHealthcare DTP*472.

Nie ma walidacji przeciwko raportowi technicznemu. Przewodnik partnera rządzi.

8.3.8 Podpisy elektroniczne na załącznikach

CMS-0053-F również przyjmuje standard podpisu, w 45 CFR 162.2002(e): Przewodnik implementacji HL7 dla CDA Release 2, Podpisy cyfrowe i delegowanie praw, Release 1. Stosuje się do podpisów umieszczonych na informacjach o załączniku, gdy są one wysyłane w transakcji załącznika HIPAA, od 26 maja 2028 r. Płatnik nie może żądać więcej, niż przewiduje przewodnik.

Perfuse podpisał C-CDA w ten sposób na swojej drodze do 275, i sprawdza podpisy na każdym C-CDA w 275, który czyta.

• Co jest podpisywane. Cały dokument, z wyjątkiem jego legalAuthenticator i authenticator uczestników, tak aby każdy późniejszy sygnatariusz pozostawił wcześniejsze podpisy nienaruszone. Podpis mówi o tym za pomocą filtru XPath 2.0, który może być oceniony przez każdą bibliotekę podpisu XML.
• Gdzie on idzie. Base64 w sdtc:signatureText na podpisanym uczestniku, z jednowierszowym opisem w postaci zwykłego tekstu. Sygnatariusz jest prawnym autoryzatorem dokumentu, jeśli ma niesygnowanego, w przeciwnym razie nowego authenticator.
• Co on stwierdza. Certyfikat sygnatariusza, czas w UTC, rola z taksonomii dostawców NUCC i cel z ASTM E1762. Cel domyślnie jest *Podpis autora* dla prawnego autoryzatora i *Podpis współautora* w przeciwnym razie, jak w przykładzie przewodnika.
• Jak długo on trwa. Przewodnik prosi o XAdES-X-L, który zawiera wszystko, czego płatnik potrzebuje do weryfikacji podpisu po latach, bez konieczności dostępu do sieci. Jest to ścieżka certyfikacji, odpowiedź OCSP lub CRL od urzędu certyfikacji, oraz dwa znaczniki czasu od władzy znaczników czasu. Perfuse pobiera dane odwołania z adresów w certyfikacie i znaczniki czasu z -tsa-url.

Jeśli jakakolwiek z tych rzeczy jest niedostępna, podpis jest nadal tworzony i obowiązuje. Wynik nazwuje formę XAdES, której osiągnął, i mówi, co go powstrzymało przed osiągnięciem X-L: na przykład certyfikat samopodpisany (brak urzędu certyfikacji do zapytania) lub brak władzy znaczników czasu.

Klucz to -signing-cert i -signing-key. Umieść certyfikaty urzędu certyfikacji po certyfikacie sygnatariusza w tym samym pliku, aby ścieżka podróżowała z podpisem. Dla podpisu, który ma znaczenie, jak DSDR, certyfikat powinien nazwać klinicystę, z jego NPI, zamiast serwera. Podpisywanie jest akcją administracyjną, jak podpisywanie każdego dokumentu.

Przewodnik nie nazwał przestrzeni nazw dla własnych elementów. Perfuse umieszcza digitalSignature, authorizedSigner i SignaturePurpose w urn:hl7-org:sdtc. Podaje również cel jako typ zobowiązania XAdES z OID ASTM, który narzędzia XAdES rozumieją. Delegowanie praw, gdzie delegat podpisał się z asercją SAML od upoważnionego sygnatariusza, nie jest produkowane, a otrzymany jest zgłaszany jako niezweryfikowany.

Numer NPI dostawcy jest sprawdzany pod kątem cyfry kontrolnej. Płatnik dopasowuje załącznik do roszczenia częściowo na podstawie tego numeru, a błędnie wpisany numer pozostawia załącznik niedopasowany, podczas gdy roszczenie jest odrzucane z powodu braku dokumentacji.

Widok Roszczenia & auth tworzy 275 z wklejonego C-CDA lub przesłanego pliku, opcjonalnie podpisanego C-CDA, i czyta jeden z powrotem z wynikami każdego podpisu. Nic na tej stronie nie wysyła niczego: wymiana jest zwracana do dostarczenia przez kanał, który jest miejscem, gdzie należy partner, poświadczenia i ślad audytowy.

8.3.9 Segmenty binarne

Segment BIN zawiera surowe bajty, a surowe bajty zawierają separatory. Każdy inny segment X12 kończy się na terminatorze segmentu, więc zwykły parser znajduje segmenty, wyszukując jeden bajt; załącznik nie może być znaleziony w ten sposób. PDF zawierający ~ zostałby podzielony na kawałki, a każdy kawałek jest segmentem strukturalnie poprawnym — więc dokument jest obcięty, każdy segment po nim jest nieprawidłowo wyrównany, i nic nie zgłasza błędu.

Perfuse czyta liczbę bajtów, którą deklaruje segment, i pobiera dokładnie tyle bajtów. Dwa konsekwencje warte poznania:

• Oświadczona długość, która nie odpowiada danych, jest odrzucona, z podaniem obu liczb. Istotne pytanie brzmi, czy liczba nadawcy była błędna, czy plik został obcięty podczas transmisji, a odpowiedź można uzyskać tylko z dwóch liczb.
• BDS, segment binarny 006020, przechowuje swoją liczbę w BDS02 i swoje dane w BDS03. Został odrzucony, dopóki nie można było potwierdzić tego z opublikowanego źródła, a nie tylko z pamięci, i obecnie dwie źródła potwierdzają to: tabela BDS w przewodniku CMS esMD i przewodnik UnitedHealthcare.

Własny przewodnik esMD deklaruje 16 bajtów dla tego samego ładunku 53-bajtowego, który jego tabela poprawnie liczy jako 53. Perfuse odmawia tego przykładu, jak powinien. Test zawiera zarówno przykład z tabeli, jak i błąd w przykładzie, więc zmiana w którąkolwiek stronę jest zauważalna.

8.4 FHIR

8.4.1 W czym staje się komunikat HL7 v2

Typ komunikatu decyduje o tym, co jest produkowane, a każda konwersja raportuje podejmowane oceny jako notatki obok paczki.

Wszystko inne produkuje Pacjenta i ostrzeżenie z nazwą typu, który nie został zamapowany.

Rezerwacja. Rezerwacja, ponowna rezerwacja, anulowanie i brak pojawienia się wszystkie lądują na tym samym spotkaniu. Jego tożsamość pochodzi z własnych numerów spotkania w SCH-1 i SCH-2, a nie z komunikatu, więc anulowanie aktualizuje rezerwację. Alternatywą byłoby drugie, anulowane spotkanie obok żywego, co pokazuje, że pacjent zarezerwował się na slot, który nie istnieje.

• Status. Status wypełnienia w SCH-25 decyduje o tym, a zdarzenie wyzwalające jest używane tylko wtedy, gdy jest pusty.
• Zablokowane sloty. Zablokowany slot nie jest spotkaniem z pacjentem i nie produkuje nic.
• Czas rozpoczęcia. Jest odczytywany z AIS, AIG, AIL lub AIP najpierw, a potem SCH-11, ponieważ wersja 2.5 przeniosła go i karmienia nie wszystkie przeniosły się z nim.
• Czas trwania. Czas trwania w jednostce, której Perfuse nie rozpoznaje, jest pomijany, a nie zgadywany.

Dokumenty. Notatki tekstowe (TX, FT, ST) zachowują swoje przerwy wiersza, w tym puste wiersze, ponieważ pusta powtórka w notatce jest przerwą akapitu.

• Osadzone dokumenty. Osadzony PDF, TIFF lub JPEG (ED) jest przenoszony bajt po bajcie. Base64, który nie jest prawidłowym base64, jest odrzucany, a nie przekazywany dalej.
• Typy. Typ dokumentu w TXA-2 jest zachowany tak, jak został wysłany, a tam, gdzie istnieje wyraźny odpowiednik, nadawany jest kod LOINC, który używa US Core.
• Podpisywanie. Notatka, której nikt nie podpisał, jest preliminary, a T11 sprawia, że dokument jest entered-in-error.
• Brak treści. Powiadomienie bez treści (T01, T03 i inne nieparzyste zdarzenia) nie produkuje DocumentReference. FHIR wymaga treści, a pusty załącznik wyglądałby jak notatka, mówiąc nic.

To jest to, o co prosi ramowa struktura interoperacyjności CMS 14: notatki z wykresu i dokumenty kliniczne zwracane jako załączniki FHIR.

Szczepienia. Dawka jest nigdy zgłaszana jako podana, gdy komunikat mówi inaczej.

• Odrzucane dawki. Odrzucana lub niepodana dawka (RXA-20 RE lub NA) jest not-done, z powodem z RXA-18.
• Usunięcia. Usunięta dawka (RXA-21 D) jest entered-in-error.
• Rekordy historyczne. Rekord przepisany z innego miejsca (RXA-9 inny niż 00) nie jest źródłem pierwotnym.
• Nieznane ilości. Ilość 999 oznacza nieznane, a nie 999.
• Trasy i miejsca. Każda dawka przyjmuje trasę i miejsce z RXR po niej, więc wiadomość z dwiema dawkami nie daje drugiej dawki trasy pierwszej.

Niewygodny wprowadzany. Każdy z nich jest zgłaszany w notatkach, a nie decyduje się o tym w ciszy:

• Identifikatory. PID-2 i PID-4, wycofane po wersji 2.7, ale nadal wysyłane, są traktowane jak PID-3. CX.7 i CX.8 stają się

Identifier.period. Władza przydzielająca z ISO OID (AUSHIC&2.16.840.1.113883.3.879&ISO) staje się urn:oid:. Kod typu spoza tabeli HL7 0203 jest przechowywany jako tekst, a nie jest oznaczony jako taki.

• Scalania. MRG podczas zdarzenia scalania (A40 i jego rodzina) wysyła również wycofany rekord, nieaktywny, z Patient.link w obie strony.

W przypadku innego zdarzenia, takiego jak A08, nic nie jest scalane, a ostrzeżenie informuje, że poprzedni identyfikator jest nadal aktywny.

• Czas. Czas urodzenia w PID-7 przechodzi do rozszerzenia patient-birthTime. Sygnatura czasowa bez przesunięcia przyjmuje skonfigurowaną

strefę czasową, w przeciwnym razie przesunięcie na MSH-7 (v2 zakłada czas lokalny nadawcy), w przeciwnym razie UTC. Czas urodzenia jest wyjątkiem: bez przesunięcia z którychkolwiek z trzech jest pomijany, zamiast być oznaczony jako UTC, ponieważ błędne przesunięcie może przenieść urodzenie na inny dzień. birthDate jest przechowywany, a ostrzeżenie informuje, że czas został pominięty i że ustawienie strefy czasowej dla kanału go zachowuje.

• Wyniki. Powtórzenia wyniku tekstu są łączone z przerwami linii. Wynik ED lub zakodowany, którego wartość jest wyraźnie Base64, staje

się DocumentReference, na które Observation wskazuje w derivedFrom, ponieważ Observation R4 nie ma wartości załącznika. Porównanie SN = jest pomijane jako zbędne; <> zachowuje tekst, ponieważ żadna ilość nie może powiedzieć „nie równa się”.

• Wizyty. A08 z datą wypisu (PV1-45) jest zakończonym spotkaniem. Brak lub nieznana klasa pacjenta jest smakiem null UNK,

ponieważ R4 wymaga klasy.

• Z segmenty są nazwane w ostrzeżeniu, ponieważ nie ma standardowej mapy dla nich.

• Nazwy. Gdy nadawca dzieli nazwę rodzinną (XPN.1, XCN.2) na części - przydomek i nazwę, własną i partnera, tak jak wysyłane są nazwy holenderskie i flamandzkie - family jest to cała nazwa, a części trafiają do rozszerzeń nazwy rodziny HL7 (humanname-own-prefix, -own-name, -partner-prefix, -partner-name).
• Procedury. PR1 staje się procedurą o statusie unknown, ponieważ ADT nie mówi, czy została wykonana, czy zaplanowana; anestezjolog (PR1-8) i chirurg (PR1-11) są wykonawcami z rolami SNOMED CT. Kod OPS również otrzymuje kategorię SNOMED CT ze swojego rozdziału, za pomocą mapy OPS-SNOMED-Category HL7 Deutschland, którą wymaga ISiK.

8.4.2 To, co dodaje witryna: skrypt bundle

Narodowy profil często chce tego, czego nie ma wiadomość HL7 v2: numer IK szpitala lub kod ODS, jaki poziom kontaktu jest odwiedziny (ISiK), czy dana nazwa jest imieniem, czy inicjałem (holenderski nl-core). Perfuse nie zgaduje tych informacji. Skrypt bundle_script miejsca docelowego fhir to miejsce, w którym strona może je dodać: JavaScript uruchamiany na każdym przekonwertowanym zestawie, jako bundle, przed jego walidacją i wysłaniem. To, co skrypt pozostawia, jest tym, co jest wysyłane, sprawdzane jak każda konwersja, a skrypt, który wyrzuca wyjątek, powoduje niepowodzenie wiadomości, tak jak każdy inny transformator. Konsola ma to pod *Dodaj to, co twoje systemy wiedzą* miejsca docelowego.

destinations:
  - name: kis
    type: fhir
    fhir:
      url: https://fhir.klinikum.example/fhir
      version: "4.0.1"
      identifier_systems: {KLINIKUM-MUSTERSTADT: "https://fhir.klinikum-musterstadt.example/sid/patientennummer"}
      bundle_script: |
        bundle.entry.forEach(function (e) {
          if (e.resource.resourceType === "Organization" && e.resource.name === "KLINIKUM-MUSTERSTADT") {
            e.resource.identifier = [{system: "http://fhir.de/sid/arge-ik/iknr", value: "260326822"}];
          }
        });

perfuse fhir convert -bundle-script FILE runs the same script, so a site can try it on its own messages first. Two worked examples are in the repository: examples/isik/bundle-script.js (IKNR, Kontaktebene, MR-typed patient number, Diagnosetyp) and examples/nictiz/bundle-script.js (first names and initials). With them the invented German and Dutch messages in conformance/national go from 18 to 42 of 47 resources valid against ISiK and from 12 to 18 of 24 against nl-core; what is left is in the messages or the terminology server, and is listed there.

Bundle przechodzi przez model Perfuse w drodze powrotnej, więc zmiany skryptu są sprawdzane i zapisywane w wersji FHIR miejsca docelowego. Członkowie, których model nie ma pola, są przechowywani tak, jak je skrypt napisał, wewnątrz typów danych również.

8.4.3 US Core 9.0.0 i USCDI v6

-us-core (i claim_us_core na miejscu docelowym fhir) umieszcza profil US Core w meta.profile, ale tylko w przypadku zasobu, który został sprawdzony pod kątem tego profilu i uznany za zgodny. Zasób, który nie spełnia wymagań, jest nadal konwertowany i wysyłany bez roszczenia, a uwaga podaje powód, taki jak „US Core wymaga typu spotkania, a to Spotkanie nie ma”. Kontrole są przepisywane z US Core 9.0.0, wersji zatwierdzonej przez proces ONC 2026 Standards Version Advancement Process dla USCDI v6. Obejmują one Pacjenta, Spotkanie, laboratoryjne Observation i DiagnosticReport, Specimen, Pracownika, Organizację, Lokalizację, Szczepienie, DocumentReference, spotkanie-diagnoza Condition i AllergyIntolerance.

To, co konwerter przenosi, według klasy danych USCDI v6:

Nie są przenoszone, ponieważ wiadomości v2 tego typu nie zawierają ich, lub Perfuse nie mapuje ich: Lekarstwa, Procedury, Cele i Preferencje, Oceny Stanu Zdrowia, Plan Opieki, Rodzinna Historia Medyczna, Urządzenia Medyczne (UDI), Informacje o Ubezpieczeniu Zdrowotnym, WSkaźniki Witale jako odrębny profil oraz Pochodzenie.

8.4.4 R4 w obie strony

Serwer FHIR deklarujący R4 akceptuje R4. Nie było to prawdą w przypadku Spotkań aż do tej wersji. Serwer konwertował to, co służył, do R4, ale czytał to, co otrzymywał, jakby było już w jego wewnętrznej formie, więc R4 Spotkanie zostało odrzucone z kodem 400. Tak samo było z każdym pakietem, jaki wyprodukowała własna konwersja ADT Perfuse, ponieważ każdy z nich zawiera Encounter.class, który R4 zapisuje jako pojedyncze kodowanie.

Zostało to znalezione pierwszy raz, gdy coś opublikowało przekonwertowane ADT do własnego serwera R4 Perfuse. Test teraz robi to dla każdego typu wiadomości, który został zamapowany, a inny sprawdza, czy wszystko, co zostało napisane jako R4, jest odczytywane bez zmian.

8.4.5 Międzynarodowy Podsumowanie Pacjenta

GET /fhir/Patient/{id}/$summary, lub GET /fhir/Patient/$summary?identifier=system|value, zwraca Międzynarodowe Podsumowanie Pacjenta (HL7 IPS 2.0.0): pakiet FHIR document zawierający Composition, który wylicza aktywne problemy pacjenta, alergie, leki, szczepienia, wyniki, parametry życiowe, procedury, urządzenia, choroby przeszłe, wywiad rodzinny i plany opieki, każdy z czytelną narracją. Jest to krótki rekord, który klinicyista, który nie spotkał się z pacjentem, czyta jako pierwszy, a także podsumowanie, które Europejska Przestrzeń Danych Zdrowia wymienia między krajami od 2029 roku.

Zostało ono zbudowane z tego, co przechowuje sklep FHIR, i nic nie zostało wymyślone:

• Rekordy oznaczone jako entered-in-error są pomijane.
• Rozwiązany stan jest umieszczany w sekcji chorób przeszłych, a nie problemów.
• Zamówienie leku, które zostało zatrzymane lub ukończone, jest traktowane jako historia, a nie jako bieżące leczenie.
• Trzy sekcje wymagane przez IPS (problemy, alergie, leki) są zawsze obecne. Jeśli sekcja jest pusta, zawiera zakodowany powód unavailable i informuje, że serwer nie posiada informacji, „co nie oznacza, że ich nie ma”. Pusta lista alergii nigdy nie powinna być interpretowana jako „nieznane alergie”.
• Praktycy, organizacje, leki i lokalizacje, na które powołują się wpisy, są uwzględnione, aby dokument mógł być czytany samodzielnie.

Access follows $everything: a token limited to one patient gets a 403 for another, and an identifier that matches two patients is refused rather than guessed. Only the IPS profile is built; asking for another profile is refused. The document Perfuse produces from its test records validates against the IPS 2.0.0 Bundle profile with the HL7 validator, with no errors. A record built from real feeds can still fail where the feed's own codes do (a display name the code system does not use, for example), because the summary passes the data on as it was received.

Exchange → Health links → Share wypełnia treść podsumowaniem pacjenta: wpisz identyfikator FHIR pacjenta i wybierz Użyj jego podsumowania pacjenta, a następnie przeczytaj je i utwórz link. Budowanie jest rejestrowane jako fhir.summary.

8.4.6 Podsumowania transferu dla opieki poacute (PACIO)

Gdy pacjent opuszcza szpital i udaje się do domu opieki, oddziału rehabilitacji lub opieki zdrowotnej w domu, elektroniczna dokumentacja medyczna (EHR) szpitala wysyła dokument C-CDA: podsumowanie przeniesienia, podsumowanie wypisu lub CCD. Perfuse konwertuje ten dokument w podsumowanie przeniesienia zgodnie z przewodnikiem PACIO Transitions of Care (hl7.fhir.us.pacio-toc 1.0.0): jeden pakiet FHIR R4 document, zawierający US Core 8.0.1, który system odbiorczy może zarchiwizować bez konieczności odczytywania XML przez nikogo.

• Każda z piętnastu sekcji przewodnika jest obecna, każda z własnym tekstem, w kolejności przewodnika: dyrektywy dotyczące zaawansowanej opieki, alergie, zdrowie behawioralne, stan funkcjonalny, szczepienia, instrukcje po wyjściu, urządzenia medyczne, leki, plan opieki, problemy, procedury, powód skierowania, wyniki, historia społeczna i wskaźniki życiowe.
• Sekcja, której dokument nie miał, jest uznawana za brakującą, nigdy nie wypełnioną. Wychodzi pusta, z zakodowanym powodem unavailable i zdaniem "Dokument wysyłający nie miał ... sekcji". Pusta sekcja alergii nie może być odczytywana jako "nieznane alergie".
• Sekcja przenoszona jako sam tekst zachowuje swój tekst i nie otrzymuje wpisów. Proza nie jest konwertowana na dane zakodowane. Stan funkcjonalny, zdrowie behawioralne (sekcja statusu psychicznego C-CDA), dyrektywy dotyczące zaawansowanej opieki, urządzenia medyczne, plan opieki, instrukcje po wyjściu, powód skierowania i historia społeczna są wysyłane w ten sposób dzisiaj; notatki mówią o tym dla każdej.
• Zakodowane wpisy stają się zasobami według tych samych reguł, co zwykła konwersja: alergie (US Core AllergyIntolerance), problemy i rozpoznanie po wyjściu (US Core Condition, lista problemów lub rozpoznanie w trakcie spotkania), procedury, szczepienia, wyniki, wskaźniki życiowe i leki jako lista leków PACIO MedicationStatements (104204-3, lista leków po wyjściu, z sekcji leków po wyjściu; 104202-7, lista aktywnych leków, w przeciwnym razie).
• Wskaźniki życiowe w postaci FHIR. Ciśnienie skurczowe i rozkurczowe pobrane razem stają się jednym panelem ciśnienia krwi (85354-9) z dwoma składnikami, a bardziej szczegółowy kod (waga ciała zmierzona, 3141-9) również niesie kod, który profile wskaźników życiowych FHIR naprawiają (29463-7), obok oryginalnego.
• Kto i skąd. Autor dokumentu staje się autorem Kompozycji (pracownikiem służby zdrowia, z NPI, gdy jego cyfra kontrolna jest ważna), jego opiekun staje się organizacją opiekującą, jego ogarniające spotkanie staje się pobytem, który podsumowanie zamyka. Dokument bez osoby jako autora lub bez opiekuna jest odrzucany: przewodnik wymaga obu, a Perfuse nie umieści nazwy na rekordzie klinicznym, którego nikt nie dał.
• Negacja zachowuje swoje znaczenie. "Nieznane alergie" (negowana alergia na jakąkolwiek substancję) jest wysyłana jako SNOMED CT 716186003; negowana alergia na jeden lek jest odrzucana, ponieważ FHIR nie może jej powiedzieć, a zasób powiedziałby coś przeciwnego; negowany problem jest refuted.

Trzy sposoby, aby to zrobić:

• Kanał: miejsce docelowe cda z write: transfer publikuje podsumowanie transferu każdego dokumentu na punkt końcowy Bundle serwera FHIR (url), lub zapisuje <document>.transfer.json do dir. W budowniczym kanału: Emituj › Podsumowanie transferu PACIO.
• Wiersz polecenia: perfuse fhir transfer [-authority OID=URI] [-out dir] <document.xml>....
• Konsola: Dokumenty, włącz Również utwórz podsumowanie transferu PACIO, i przeczytaj dokument.

Sprawdzono z oficjalnym walidatorem FHIR przeciwko profilowi Bundle TOC 1.0.0, przykładom C-CDA (podsumowaniu transferu, podsumowaniu wyjścia i CCD) HL7. Jeden błąd, który zgłasza, jest w przewodniku: każdy znak życiowy odpowiada zarówno jego simple-observation, jak i vital-signs Bundle entry slices, więc nie może być uniknięty przez żadnego nadawcę. Nie wykonano jeszcze: przekształcenie sekcji tylko tekstowych (status funkcjonalny, status psychiczny, plan opieki, urządzenia) w zasoby zakodowane i dokumentu TOC DocumentReference przewodnika, który indeksuje przechowywane podsumowanie transferu.

8.4.7 Subskrypcje

Z -fhir-subscriptions punkt końcowy FHIR wysyła powiadomienia, gdy utworzono lub zmieniono spotkanie lub wizytę. Postępuje zgodnie z FHIR Subscriptions R5 Backport IG dla R4, który jest używany przez CMS Interoperability Framework criterion 15 i TEFCA's FHIR roadmap do powiadomień o spotkaniach i wizytach.

Klient tworzy Subscription z nazwą tematu i opcjonalnym filtrem, takim jak Encounter?patient=Patient/123. Tematy są wymienione w oświadczeniu o możliwościach:

Filtr, który nazywa cokolwiek innego, jest odrzucany, a nie ignorowany. Zignorowany filtr to subskrypcja, która powiadamia o każdym pacjencie, gdy klient poprosił o jednego.

Właściwości, wokół których zbudowana jest implementacja:

• Potwierdzona zmiana nigdy nie jest zgubionym powiadomieniem. Powiadomienie jest rejestrowane w tej samej transakcji bazy danych, co zmiana, którą opisuje, i jest dostarczane stamtąd, więc przetrwa ponowne uruchomienie. Test zapisuje spotkanie, uruchamia nowy serwer na tej samej bazie danych i sprawdza, czy powiadomienie przychodzi.
• Powiadomienia przychodzą w porządku, a luki są widoczne. Zdarzenie 2 nie jest wysyłane przed zaakceptowaniem zdarzenia 1, a każde powiadomienie zawiera bieżący numer, więc odbiorca może powiedzieć, kiedy coś przegapił.
• Serwer decyduje, kiedy subskrypcja jest aktywna. Nowa subskrypcja jest requested, i staje się active tylko wtedy, gdy punkt końcowy zaakceptuje potwierdzenie. Klient, który prosi o active, otrzymuje requested. Odrzucone potwierdzenie jest ponawiane cztery razy w ciągu około piętnastu sekund, zanim subskrypcja stanie się error: wychodzi w momencie, gdy subskrypcja jest przechowywana, często zanim klient, który ją utworzył, zacznie nasłuchiwać.
• Pełne powiadomienie o zasobie zawiera wersję, która uległa zmianie. Powiadomienie o wypisie zawiera wypis, a nie to, czym stało się spotkanie do momentu, gdy dostarczenie się powiodło.
• Awaria jest ograniczona. Odrzucona dostawa jest ponawiana z rosnącym opóźnieniem. Po dziesięciu kolejnych awariach subskrypcja przechodzi w stan error: późniejsze zmiany są liczone, ale nie są kolejne, a aktualizacja subskrypcji wznawia dostawę od najstarszego zatrzymanego powiadomienia. Liczba wskazuje wtedy, ile powiadomień zostało przegapionych.

To, co klient może zmusić serwer do zrobienia, jest ograniczone celowo:

• Punkty końcowe muszą być https, chyba że operator przekazuje -fhir-subscriptions-allow-http, co jest przeznaczone dla odbiornika testowego.
• Polityka wychodząca jest stosowana, gdy subskrypcja jest tworzona, ponownie przy każdej dostawie i na adresie, do którego każde połączenie faktycznie się łączy (więc nazwa, która zmienia to, do czego się odnosi między sprawdzeniem a połączeniem, nadal jest odrzucana); przekierowania nie są śledzone.
• Ładunek domyślnie jest id-only, co informuje, co się zmieniło, i pozwala odbiorcy pobrać go przy użyciu własnych poświadczeń.
• Nic, co odbiorca wysyła z powrotem, nie jest pokazywane nikomu, tylko jego kod stanu.

Jest wyłączone, chyba że zostanie poproszone, ponieważ raz włączone, klient FHIR może zmusić ten serwer do wysłania danych pacjenta do adresu URL wybranego przez klienta. Wymaga punktu końcowego R4, który akceptuje zapisy, i odmawia uruchomienia w przeciwnym razie.

Nie zaimplementowane, więc nikt nie musi się dowiedzieć, próbując:

• kanały inne niż rest-hook
• sygnały serca
• powiadomienia o usunięciu
• operacje $status i $events

Widok Subskrypcje pokazuje temat subskrypcji, filtr i punkt końcowy, ile zdarzeń miało miejsce, ile zostało zaakceptowanych i ile czeka, oraz ostatni powód, dla którego zostało odrzucone. Wartości nagłówka i ciąg zapytania punktu końcowego są wyłączone, ponieważ to tam żyją poświadczenia subskrybenta.

8.5 Standard telekomunikacyjny NCPDP

Roszczenia aptek. Nagłówek o stałej szerokości, po którym następują zmienne segmenty.

Dwa istotne szczegóły, oba łatwe do popełnienia błędu i wytwarzające prawdopodobne wyniki:

Nagłówek ma dokładnie 56 bajtów i jest o stałej szerokości. Krótki nagłówek nie może być wykryty samą długością, ponieważ obcięty nagłówek wraz z następującymi po nim segmentami nadal przekracza 56 bajtów. Wykrywanie odbywa się przez to, że poprawny nagłówek nigdy nie zawiera bajtu separatora, więc nagłówek jest skanowany w celu jego wykrycia, a wiadomość, która go zawiera, jest odrzucana z liczbą bajtów, o które jest za krótka.

0x1E i 0x1C są markerami początku grupy i pola, a nie separatorami. Traktowanie ich jako separatorów przesuwa każde pole o jedną pozycję w lewo, a większość wynikających z tego wartości pozostaje prawdopodobna — ilość ląduje tam, gdzie oczekiwano zaopatrzenia na dzień, a oba są liczbami.

8.6 NCPDP SCRIPT

E-prescriptions, w XML. Wewnętrzny pakiet nazywa się eprescribe, ponieważ script został zajęty przez silnik JavaScript.

Głównym problemem bezpieczeństwa jest flaga zastąpienia, a czyta się ją odwrotnie od intuicji: w sieci 0 oznacza, że zastąpienie jest dopuszczalne, a 1 oznacza wydanie zgodnie z zapisem.

Brak flagi zastąpienia jest odrzucany, a nie ustawiany domyślnie. Obie możliwe wartości domyślne docierają do pacjenta — jedna może wydać generyk, gdzie lekarz wymagał marki, a druga uniemożliwia zastąpienie, na które zezwolił lekarz — więc nie ma bezpiecznego założenia, a wiadomość zostaje zatrzymana.

Przepis na lek z listy II z uzupełnieniami jest odrzucany, a konstruktor nie wygeneruje go.

Odrzucenia i ostrzeżenia są przechowywane jako oddzielne listy, a nie jako jedna lista oznaczona stopniem nasilenia, ponieważ czytelnik, który musi sprawdzić pole stopnia nasilenia, aby wiedzieć, czy wiadomość została wysłana, ostatecznie nie sprawdzi go.

Elektroniczna uprzednia autoryzacja (PAInitiationRequest, PARequest, PAAppealRequest, PACancelRequest) i Real-Time Prescription Benefit są obsługiwane przez stronę płatnika pod /ncpdp/script i /ncpdp/rtpb, z formularza leków; zobacz CMS-0057.

8.7 DICOM

Obrazowanie. Perfuse może otrzymywać obiekty DICOM, wysyłać zapytania do zdalnego archiwum i przechowywać je w archiwum, za pomocą klasycznych usług sieciowych DICOM lub za pośrednictwem DICOMweb, i może utrzymywać własne archiwum dla programów do wyświetlania.

DICOM nie jest formatem wiadomości w tym samym sensie, co inne — obiekty są duże, a użycie rąk wskazuje więcej niż analiza ładunku. Tytuły called_ae i calling_ae są najczęstszą przyczyną, dla której pierwsze połączenie nie powiedzie się, a awaria wygląda jak problem sieciowy, a nie konfiguracyjny.

8.7.1 Co akceptuje nasłuchujący C-STORE

Otwarty, nasłuchujący DICOM akceptuje wszystko od każdego, kto może dotrzeć do portu. Cztery ustawienia pod To, co ten nasłuchujący akceptuje, zawężają to, a pierwsze z nich jest tym, które warto zrozumieć.

Tylko akceptuj te tytuły AE wywołujące jest ograniczeniem. *Wywołany* tytuł AE — ten obok adresu — jest nazwą, którą nadaje nadawca, więc identyfikuje ten nasłuchujący, a nie nadawcę, i nie jest ograniczeniem. Każdy, kto może dotrzeć do portu, może użyć poprawnego tytułu AE wywołanego, ponieważ jest on opublikowany dla nich. Bez listy dozwolonych nadawców każdy host w sieci może wysłać obrazy do kanału klinicznego.

Tylko akceptuj te klasy SOP i tylko akceptuj te składnie transferu przyjmują oddzielone przecinkami identyfikatory UID. Pusty akceptuje każdy rodzaj obiektu i negocjuje każde kompresję, jaką oferuje nadawca, co obejmuje rodzaje, których nie mogą obsłużyć miejsca docelowe tego kanału. Odrzucanie na poziomie stowarzyszenia jest bardziej czytelne dla nadawcy niż akceptowanie obiektu i awaria po późniejszym.

Największy obiekt akceptowany jest w bajtach, a zero oznacza brak ograniczenia. Całościowe obrazy i długie serie sięgają gigabajtów, więc ograniczenie jest gdzie indziej w pamięci.

8.7.2 DICOMweb

DICOMweb to DICOM nad HTTP: QIDO-RS wyszukuje, WADO-RS i WADO-URI pobierają, a STOW-RS przechowuje. Przeglądarki, takie jak OHIF, obsługują tylko DICOMweb, podobnie jak usługi chmury do obrazowania (Google Cloud Healthcare, Azure Health Data Services, AWS HealthImaging). Perfuse wykorzystuje go w trzech miejscach.

Archiwum obrazowania. Uruchom serwer z -dicomweb-archive DIR (Ustawienia › Dane › Archiwum obrazowania) i będzie on przechowywał obiekty w tym folderze, indeksowane w SQLite, i udostępniał je pod /dicomweb na adresie konsoli: QIDO-RS na poziomie badania, serii i instancji, WADO-RS dla obiektów, metadanych, klatek i danych masowych, WADO-URI pod /dicomweb/wado, oraz STOW-RS. Odczyt wymaga roli widza, a przechowywanie roli operatora, z sesją lub tokenem API; każdy odczyt i przechowywanie są rejestrowane w Aktywności jako dicomweb.read lub dicomweb.store. Konto ograniczone do najemcy lub grup kanałów jest odrzucane, ponieważ archiwum należy do całego serwera. Obiekty są przechowywane dokładnie tak, jak zostały odebrane, więc to, co widz otrzymuje, jest identyczne z tym, co zostało przechowywane. Klatki są zwracane w składni transferu, w której zostały przechowywane; żądanie, które wymagałoby transkodowania, odpowiada 406 zamiast przekonwertowanego obrazu.

Wyszukiwanie według atrybutu, którego archiwum nie indeksuje, odpowiada 400 zamiast ignorowania warunku i zwracania większej liczby badań, niż zostało poproszone. Indeksowane: nazwa pacjenta (wzorce, i dopasowanie nieostre z fuzzymatching=true), identyfikator pacjenta, data urodzenia, płeć, data i godzina badania (zakresy), numer akcesji, identyfikator badania, opis, lekarz kierujący, badanie, seria i SOP instance UIDs (listy), modalność, część ciała, numer serii i opis, SOP class, numer instancji, wiersze, kolumny i liczba klatek.

Źródło. type: dicomweb nasłuchuje STOW-RS, pod /dicom-web/studies domyślnie (ścieżka, którą używają Orthanc i dcm4chee), i wysyła każdy obiekt przez kanał jako wiadomość DICOM. Kanał wymaga dataType: dicom. Ustaw token noszący lub nazwę użytkownika i hasło: bez nich każdy, kto może dotrzeć do portu, może wysyłać obrazy do kanału. Odpowiedź wylicza każdy obiekt jako przechowywany lub nieudany, z powodem niepowodzenia DICOM, aby nadawca wiedział, które obiekty należy wysłać ponownie.

name: imaging-from-viewers
dataType: dicom
source:
  type: dicomweb
  dicomweb:
    listen: 0.0.0.0:8043
    token: ${STOW_TOKEN}
    tls: { enabled: true, cert_file: /etc/perfuse/imaging.crt, key_file: /etc/perfuse/imaging.key }
destinations:
  - name: archive
    type: dicomweb
    dicomweb:
      url: https://perfuse.example/dicomweb
      token: ${ARCHIVE_TOKEN}

Punkt docelowy znajduje się w dostawie, pod archiwami DICOMweb.

Wskazywanie OHIF na archiwum

Użyj źródła danych DICOMweb z qidoRoot i wadoRoot ustawionymi na adres archiwum (ekran Obrazowanie wyświetla go, wraz z całym blokiem źródła danych do skopiowania), wadoUriRoot na adres archiwum, po którym następuje /wado, imageRendering i thumbnailRendering na wadors, oraz supportsFuzzyMatching ustawiony na true. Widz na innym pochodzeniu wymaga tego pochodzenia w -dicomweb-cors (Dozwolone pochodzenia przeglądarki, które mogą wywołać ją), a jego żądania wymagają tokenu API w nagłówku Authorization, ponieważ przeglądarka na innym pochodzeniu nie wysyła ciasteczka sesji konsoli. Udostępnianie OHIF z tego samego pochodzenia za pomocą serwera proxy odwrotnego unika obu.

Przetestowane z Orthanc z wtyczką DICOMweb, w obu kierunkach: miejsce przeznaczenia przechowuje w Orthanc, a klient DICOMweb Orthanc wyszukuje archiwum Perfuse i pobiera badanie identyczne z tym, które zostało przechowywane. OHIF 3 wyświetla badania archiwum i wyświetla ich klatki z ustawieniami powyżej. OHIF i kilku innych klientów wysyła type= niezacytowane w nagłówkach Accept i Content-Type, co nie jest dozwolone przez RFC 2045; Perfuse akceptuje to.

8.8 IHE udostępnianie dokumentów: XDS.b, XCA, XDR, MHD, PIXm i PDQm

Dokumenty kliniczne udostępniane między organizacjami w sposób, w jaki robią to wymiany informacji o zdrowiu, Carequality i eHealth Exchange: repozytorium zawiera je, rejestr indeksuje ich metadane, a społeczność odpowiada na zapytania innych społeczności za pośrednictwem bramy. Uruchom serwer z -xds REPOSITORY-OID (Ustawienia › Dane › Udostępnianie dokumentów) i jest to wszystko trzy, w bazie danych tego serwera, pod następującymi adresami, z których każdy akceptuje token API jako token nośnika (rola widza do zapytania i pobrania, rola operatora do przesłania; większość domen powiązań dodaje wzajemne TLS na przedzie):

Transakcje SOAP są SOAP 1.2 z WS-Addressing i MTOM/XOP, gdzie dokumenty podróżują (dokument w linii jako base64 jest również akceptowany). Nieudana transakcja jest odpowiedzią na RejestrResponse z kodami błędów IHE, a nie błędem SOAP: XDSDuplicateUniqueIdInRegistry, XDSNonIdenticalHash, XDSPatientIdDoesNotMatch, XDSMissingDocument, XDSRegistryMetadataError (z polem, które jest brakujące), XDSStoredQueryMissingParam, XDSUnknownStoredQuery, XDSUnknownRepositoryId, XDSUnknownCommunity i UnresolvedReferenceException. Zastąpienie (RPLC, XFRM_RPLC) deprecjonuje dokument, który zastępuje, który następnie odpowiada tylko na zapytania dotyczące zdezaktualizowanych dokumentów; APND, XFRM i signs są przechowywane jako stowarzyszenia. Hash i rozmiar są obliczane przez repozytorium i sprawdzane w stosunku do tego, co podaje przesłanie. Dokumenty i metadane na żądanie (ITI-57) nie są obsługiwane, a przesłanie, które o nie prosi, jest odrzucane z powodem.

MHD to ten sam rejestr w FHIR: dokument dostarczony za pośrednictwem MHD jest znaleziony przez ITI-18 i za pośrednictwem XCA, a jeden dostarczony za pośrednictwem XDS.b jest znaleziony przez ITI-67. Identyfikator DocumentReference to identyfikator UUID wpisu, jego masterIdentifier to unikalny identyfikator, a adres załącznika to adres ITI-68 dokumentu. Pacjenci są rozwiązywani w identyfikatorze domeny powiązania z magazynu FHIR: pierwszy identyfikator, którego system to urn:oid:, lub pacjent przeniesiony w Bundle. PIXm odpowiada na każdy inny identyfikator pacjenta z tym podanym (sourceIdentifier=system|value, zawężony przez targetSystem), a 404 dla tego, którego nie zna; PDQm wyszukuje przez identyfikator, nazwę, datę urodzenia, płeć, adres i łącze.

Publikowanie. Destynacja xds kanału publikuje każdy dokument kliniczny, jaki otrzymuje, dokument CDA lub jeden przeniesiony w wiadomości HL7 v2, do dowolnego repozytorium XDS.b z ITI-41. Metadane są odczytywane z dokumentu: pacjent (identyfikator w patient_domain, władza przydzielająca domeny powiązania), tytuł, typ (jako typeCode i, chyba że ustawiony, classCode), czas tworzenia i usługi, autor, poufność, język i format (C-CDA 2.1 lub 1.1 strukturalna treść, XDS-SD lub mimeTypeSufficient, z jego szablonami); i uzupełnione o to, czego dokument nie mówi: identyfikator nadawcy source_id, facility_type i practice_setting każdego rejestru wymagają. Odpowiedź rejestru RegistryResponse decyduje o dostawie: niepowodzenie lub błąd w PartialSuccess to nieudana dostawa z kodami błędów rejestru.

destinations:
  - name: hie
    type: xds
    xds:
      url: https://hie.example/xds/repository
      source_id: 1.2.840.114350.1.13.99
      patient_domain: 1.2.840.114350.1.13.99.2.7.5.737384.14
      facility_type: { code: "225732001", scheme: 2.16.840.1.113883.6.96, display: Community hospital }
      practice_setting: { code: "394802001", scheme: 2.16.840.1.113883.6.96, display: General medicine }
      tls: { enabled: true, cert_file: /etc/perfuse/hie.crt, key_file: /etc/perfuse/hie.key }

XDR. Dodaj direct_from (Twój adres Direct) i direct_to (adresy odbiorców) i to samo miejsce docelowe wysyła XDR jako transport Direct, jak opisano w *XDR i XDM dla Direct Messaging* projektu Direct: blok adresowania Direct (urn:direct:addressing) w nagłówku SOAP nazwuje nadawcę i odbiorców, a intendedRecipient podania nazwuje każdego odbiorcę (||^^Internet^address). Wskaż url na punkt końcowy XDR odbiorcy lub HISP, który akceptuje XDR. XDR podróżuje przez TLS, zwykle z certyfikatem klienta (tls), i nie jest S/MIME. Źródło direct również akceptuje XDR (patrz poniżej Direct).

    xds:
      url: https://xdr.hisp.example/xdr
      source_id: 1.2.840.114350.1.13.99
      patient_domain: 1.2.840.114350.1.13.99.2.7.5.737384.14
      facility_type: { code: "225732001", scheme: 2.16.840.1.113883.6.96, display: Community hospital }
      practice_setting: { code: "394802001", scheme: 2.16.840.1.113883.6.96, display: General medicine }
      direct_from: referrals@direct.hospital.example
      direct_to: ["intake@direct.clinic.example"]
      tls: { enabled: true, cert_file: /etc/perfuse/xdr.crt, key_file: /etc/perfuse/xdr.key }

PIX i PDQ w wersji 3 HL7. Z indeksem pacjentów włączonym (-mpi), /pixv3 jest menedżerem PIX, a /pdqv3 jest dostawcą PDQ przez SOAP 1.2, dla szpitali i wymian, które nadal mówią profile v3 IHE. Źródło karmi pacjentów z ITI-44 (dodany rekord PRPA_IN201301UV02, zmodyfikowany PRPA_IN201302UV02, rozwiązany duplikat PRPA_IN201304UV02): pierwszy identyfikator pacjenta jest jego rekordem, inne i te w asOtherIDs są identyfikatorami, które niesie, a scalenie zagnieżdża identyfikator poprzedniego rekordu w przeżywającego, jak HL7 v2 A40. ITI-45 (PRPA_IN201309UV02) odpowiada innymi identyfikatorami osoby posiadającej jeden, zawężone przez dataSource, w Patient.id; zapytany identyfikator wraca tylko w powtarzającym się zapytaniu. ITI-47 (PRPA_IN201305UV02) dopasowuje dane demograficzne (nazwę, płeć, czas urodzenia, identyfikator, adres, łącze) z własnym dopasowaniem indeksu, minimumDegreeMatch jako wynik na 100, otherIDsScopingOrganization ograniczający domeny, i initialQuantity paginujący odpowiedź: reszta przychodzi z QUQI_IN000003UV01 przez dziesięć minut, lub jest odrzucany przez anulowanie. Odpowiedzi podążają za przypadkami transakcji: nieznany pacjent lub domena to AE z błędem 204 i lokalizacją parametru, znany pacjent z niczym w domenach zapytanych jest NF. v3 nazywa władzę tylko OID, więc identyfikator, którego system jest adresem URL bez OID za nim (niektóre numery krajowe) jest pomijany w odpowiedziach v3 i przekazywany przez FHIR; ustaw system identyfikatora przedsiębiorstwa na OID (urn:oid:..., w ustawieniach indeksu) dla EUID i opiekuna, aby się pojawić. Rola widza zapytuje, a rola operatora karmi; każda transakcja jest audytowana z identyfikatorem, a nie nazwą. Płaszczka v3 wysłana jako application/xml jest odpowiedzią tego samego rodzaju, co jest przydatne do testowania ręcznego.

Wymiana › Udostępnianie dokumentów pokazuje, co rejestr zawiera i gdzie jest on osiągalny, znajduje dokumenty pacjenta w tym rejestrze lub innym (rejestr ITI-18 lub brama ITI-38), pobiera jeden i publikuje dokument CDA ręcznie z metadanymi, które dałaby mu destynacja.

Weryfikowany przeciwko NIST XDS Toolkit 7.13.0, referencyjnej implementacji IHE: Perfuse's ITI-41, ITI-18 i ITI-43 przeciwko symulatorowi Rejestru/Magazynu (zaakceptowany bez błędów walidacji, dokument pobrany jest identyczny), oraz symulatorowi Bramy Inicjującej, który wysyła zapytania i pobiera z Perfuse's Responding Gateway za pośrednictwem XCA, bez błędów w logu. Każda wiadomość SOAP, którą Perfuse zapisuje, waliduje się przeciwko schematom ebXML Registry 3.0 i XDS.b, oraz MHD DocumentReference i SubmissionSet przeciwko IHE MHD 4.2.2 z walidatorem HL7 FHIR. XDR z xds miejsca docelowego z blokiem adresowania Direct został zaakceptowany przez symulator Odbiorcy Dokumentu narzędzia, którego walidacja metadanych znalazła jedną wadę opisaną w docs/verification.md, oraz przez walidator XDR ONC SITE, checklistę Direct XDR (h)(2) testów certyfikacji. Odpowiedzi PIX i PDQ v3 walidują się przeciwko schematom HL7 V3 IHE (NE2008 multicacheschemas), oraz własne przykładowe wiadomości IHE (karmienie ITI-44, scalanie, zapytanie ITI-45, zapytanie ITI-47, kontynuacja i anulowanie) są odpowiedzią zgodnie z opublikowanymi odpowiedziami. Nie sprawdzono jeszcze przeciwko niezależnej implementacji PIX lub PDQ v3, Gazelle lub Connectathon.

8.9 Bezpośrednia komunikacja zabezpieczona

Direct to sposób, w jaki amerykańscy dostawcy usług medycznych wysyłają sobie nawzajem skierowania, podsumowania i wyniki za pomocą bezpiecznej poczty e-mail: każda wiadomość jest podpisana certyfikatem nadawcy i zaszyfrowana do odbiorcy (S/MIME), oraz podróżuje między Dostawcami Usług Informacji o Zdrowiu (HISP), którzy wydają adresy i gwarantują ich autentyczność. Perfuse jest systemem krawędziowym obok Twojego HISP, a nie HISP: HISP wydaje Twój adres, jego certyfikat i klucz, oraz przechowujesz pakiet zaufania (taki jak DirectTrust). Perfuse przestrzega Direct Applicability Statement for Secure Health Transport 1.2, Implementation Guide for Delivery Notification, IHE XDM (ITI TF-1 Annex 15) dla dokumentów z metadanymi, Certificate Discovery for Direct Project Implementation Guide (DNS i LDAP), oraz XDR i XDM dla Direct Messaging.

Sending. A direct destination signs each message as your address (SHA-256, RSA), encrypts it to every recipient's certificate and your own (AES-256-CBC, RSA key transport), and submits it to the HISP by SMTP with STARTTLS required. The message travels as an attachment named by its content (document.xml, message.hl7, resource.json), or, with xdm: true, a CDA document travels as an IHE XDM package (IHE_XDM/SUBSET01/METADATA.XML with the document and its hash and size, plus INDEX.HTM and README.TXT) that receiving EHRs import with its metadata. Recipient certificates come from the Direct address book (below), then from DNS, where Direct publishes them as CERT records (RFC 4398): under the address with its @ made a dot, else under its domain; then from the recipient domain's LDAP directory, which its _ldap._tcp SRV record names (or ldap: host:port; ldap: off never asks one): each naming context is searched anonymously for an entry whose mail is the address, then the domain, and its userSMIMECertificate or userCertificate read. A certificate is used only when it is for the address or its domain, has not expired, and chains to one of your anchors, fetching any intermediate issuer its Authority Information Access extension names; and it is refused when its issuer's revocation list (from its CRL distribution point, signed by that issuer) lists it. A list that cannot be fetched does not stop delivery. A recipient with no such certificate is a failed delivery, never plain e-mail. to and subject take field references such as {PV1-8.1}, and request_mdn asks the recipient for a delivery notification.

destinations:
  - name: referrals
    type: direct
    direct:
      address: referrals@direct.hospital.example
      cert_file: /etc/perfuse/direct/referrals.crt   # with its chain after it
      key_file: /etc/perfuse/direct/referrals.key
      anchors_file: /etc/perfuse/direct/anchors.pem
      to: ["intake@direct.clinic.example"]
      subject: "Referral for {PID-5.1}"
      text: "Please see the attached summary."
      xdm: true
      xdm_source_id: 1.2.840.114350.1.13.99
      smtp_host: smtp.hisp.example:587
      username: referrals
      password: ${DIRECT_HISP_PASSWORD}
      request_mdn: true

Odbieranie. Źródło direct to serwer SMTP, do którego HISP dostarcza pocztę na Twój adres. Akceptuje tylko pocztę na ten adres (wszystko inne jest odrzucane na poziomie RCPT), wymaga STARTTLS, gdy podano certyfikat, i otwiera każdą wiadomość przed jej odczytaniem: odszyfrowuje ją przy użyciu Twojego klucza, weryfikuje podpis przy użyciu Twoich kotwic i sprawdza, czy certyfikat podpisujący jest dla adresu Nadawcy lub jego domeny. Wiadomość, która nie jest zaszyfrowana S/MIME, jest podpisana przez nadawcę, którego nie ufasz, lub jest podpisana certyfikatem dla kogoś innego, jest odrzucana na poziomie DATA z powodem, więc HISP ją zachowuje i zgłasza ją do nadawcy; Perfuse nigdy nie akceptuje tego, co później odrzuca. Dokumenty pakietu XDM stają się wiadomościami (sprawdzanymi pod kątem sum kontrolnych w metadanych); w przeciwnym razie każza załącznik staje się wiadomością, lub tekst, gdy nie ma załączników. Z ustawionym smtp_host każda odebrana wiadomość jest odpowiedziana sygnowaną, zaszyfrowaną notyfikacją "przetworzona" (MDN), a notyfikacje przychodzące dla tego, co wysłano, są rejestrowane.

source:
  type: direct
  direct:
    address: intake@direct.clinic.example
    cert_file: /etc/perfuse/direct/intake.crt
    key_file: /etc/perfuse/direct/intake.key
    anchors_file: /etc/perfuse/direct/anchors.pem
    listen: 0.0.0.0:2525
    tls_cert: /etc/perfuse/tls/server.crt
    tls_key: /etc/perfuse/tls/server.key
    smtp_host: smtp.hisp.example:587

Z skrzynki pocztowej HISP. HISP, który zatrzymuje pocztę zamiast ją dostarczać, daje adresowi skrzynkę pocztową IMAP: imap odczytuje ją (TLS lub STARTTLS, każde sondowanie to nowa sesja), otwiera każdą wiadomość jak powyżej, przenosi to, co zostało pobrane, do move_to (lub kasuje je) i to, co nie mogło być otwarte, do error_folder, tak aby nic nie było odczytywane dwukrotnie. listen może być wtedy pominięty. HISP, którego serwer pocztowy ma certyfikat prywatny, jest ufały z tls.ca_file (jego certyfikat lub certyfikat jego autoryzacji) i tls.server_name; weryfikacja nie może być wyłączona.

    imap:
      host: imap.hisp.example
      username: intake@direct.clinic.example
      password: ${DIRECT_MAILBOX_PASSWORD}
      move_to: Processed

XDR. xdr przyjmuje XDR w /xdr na własnym adresie HTTPS, tak jak HISP wysyła Direct przekonwertowane na SOAP lub partner wysyła punkt do punktu: żądanie ITI-41 Provide and Register, którego dokumenty stają się komunikatami. Przesyłanie, którego blok adresowania Direct nazwał inny adres, jest odrzucane, a jeden, który kanał nie przyjmuje, jest odpowiedzią z niepowodzeniem Rejestru, mówiącą, dlaczego. client_ca_file wymaga certyfikatu klienta od tych władz. XDR jest chroniony przez TLS, a nie S/MIME, więc źródło, które przyjmuje tylko XDR, potrzebuje adresu, ale nie jego certyfikatu, klucza ani kotwic. Każdy dokument staje się komunikatem dataType kanału: dokumenty CDA wymagają raw (przekazywane tak, jak są) lub hl7v3, ponieważ domyślny, hl7, oczekuje HL7 v2 i odmawia im.

    xdr:
      listen: 0.0.0.0:8445
      tls_cert: /etc/perfuse/tls/server.crt
      tls_key: /etc/perfuse/tls/server.key
      client_ca_file: /etc/perfuse/direct/hisp-clients.pem

Wymiana › Direct wyświetla adresy Direct, które Twoje kanały wysyłają i otrzymują, wraz z certyfikatami, datą wygaśnięcia i kotwicami; przechowuje książkę adresową korespondentów (imię, organizacja, notatki i certyfikat, wklejone z ich HISP lub znalezione w DNS lub LDAP, oraz odrzucone, gdy nie jest dla tego adresu lub domeny); oraz wyszukuje certyfikaty adresu w DNS lub LDAP bez zapisywania ich. Książka jest katalogiem direct-certs obok bazy danych, jeden plik PEM na adres lub domenę, który destynacja odczytuje, chyba że określa własny recipient_certs_dir.

Weryfikowany przeciwko OpenSSL 4.0 cms i smime w obu kierunkach: to, co Perfuse podpisywuje i szyfruje, OpenSSL weryfikuje i odszyfruje (PKCS#1 v1.5 i OAEP transport klucza), a Perfuse otwiera to, co OpenSSL podpisywuje i szyfruje (AES-128 i AES-256). Wiadomość utworzona z openssl smime i dostarczona przez SMTP jest otrzymywana, otwierana i zapisywana przez kanał, a ta, którą Perfuse wysyła do innego przez zastępczego HISP, który odpowiada z MDN, którą nadawca otwiera. Certyfikaty są znalezione w OpenLDAP 2.4 (związane z adresem i domeną, napisane przez własne ldapadd OpenLDAP); wiadomość Direct jest odczytywana z skrzynki pocztowej IMAP GreenMail i otwierana, a ta, która nie jest Direct, jest przenoszona do folderu błędów; XDR z miejsca docelowego xds jest pobierany przez źródło direct i odrzucany, gdy jest adresowany do kogoś innego, i akceptowany przez NIST XDS Toolkit's Document Recipient i ONC SITE's XDR validator; SITE's Direct XDR Edge Test Tool wysłał obie swoje minimalne i pełne wiadomości metadanych do źródła direct, które je pobrało. Przeciwko narzędziu Direct Certificate Discovery Tool ONC, miejsce docelowe Direct wybiera odpowiedni certyfikat lub żaden, we wszystkich 18 przypadkach odkrycia (D1 do D18: wygasłe, odwołane i wydane AIA certyfikaty, priorytet i waga SRV, niedostępny katalog). Źródło Direct odczytuje wiadomość z własnego HISP SITE (Apache James) przez IMAP z STARTTLS. Jeszcze nie przetestowane: wymiana SMTP z HISP SITE (AWS zatrzymuje pocztę wychodzącą na porcie 25 dla nowych kont) lub z akredytowanym HISP.

8.10 SQL na widokach FHIR

ViewDefinition (HL7 SQL na FHIR v2) zamienia każdy zasób FHIR jednego typu w wiersze nazwanych kolumn, każda kolumna jest wyrażeniem FHIRPath, aby dane FHIR mogły być odczytywane jako tabele przez DuckDB, Athena, Spark, magazyn danych lub arkusz kalkulacyjny. Perfuse uruchamia je za pomocą własnego silnika FHIRPath: column, zagnieżdżone select, forEach, forEachOrNull, repeat i unionAll, where, constant (każdy typ wartości[x]), kolumny collection, %rowIndex oraz klucze łączenia getResourceKey() i getReferenceKey(type).

{
  "resourceType": "ViewDefinition",
  "name": "blood_pressure",
  "resource": "Observation",
  "constant": [{ "name": "systolic", "valueCode": "8480-6" }],
  "where": [{ "path": "code.coding.exists(system = 'http://loinc.org' and code = '85354-9')" }],
  "select": [{ "column": [
    { "name": "id", "path": "getResourceKey()", "type": "id" },
    { "name": "patient_id", "path": "subject.getReferenceKey(Patient)", "type": "id" },
    { "name": "systolic", "path": "component.where(code.coding.code = %systolic).value.ofType(Quantity).value.first()", "type": "decimal" }
  ]}]
}

Monitor › SQL na FHIR uruchamia widok nad magazynem FHIR tego serwera (jeden pacjent lub wszyscy) lub nad zasobami wklejanymi (NDJSON z eksportu wsadowego, Bundle, tablica JSON), wyświetla wiersze i pobiera je jako CSV, NDJSON lub Parquet. Rozpoczyna się od pięciu przykładowych widoków (dane demograficzne pacjenta, obserwacje z wartością, ciśnienie krwi, stany, spotkania) i zapisuje widoki do katalogu views obok bazy danych, jeden plik JSON każdy.

Punkt końcowy FHIR odpowiada na specyfikację $sql-run na poziomie systemu, za pomocą GET lub POST, dla ViewDefinition podanego w linii (subjectResource), przez subjectReference (ViewDefinition/<name>, zapisany widok) lub przez subjectCanonical (zapisany widok url), z _format (csv, ndjson (domyślnie), json lub parquet), header, patient, _since, _limit i resource, aby uruchomić nad zasobami wysłanymi z żądaniem zamiast magazynu. Jest to odczyt: token SMART potrzebuje zakresu odczytu dla typu zasobu widoku, token związany z jednym pacjentem otrzymuje tylko wiersze tego pacjenta, a zakresy szczegółowe zawężają zasoby odczytywane, tak jak robi to wyszukiwanie. Więcej niż milion wierszy wymaga _limit, patient lub _since.

perfuse sof -view v.json [-format csv|ndjson|json|parquet] [-o out] files... uruchamia widok nad plikami FHIR bez serwera: pliki NDJSON eksportu wsadowego, Bundles lub tablice.

perfuse sof -view blood_pressure.json -format parquet -o bp.parquet export/Observation.ndjson
duckdb -c "SELECT patient_id, avg(systolic) FROM 'bp.parquet' GROUP BY 1"

Pliki Parquet mają jedną grupę wierszy i nieściskane strony PLAIN; wartości logiczne są BOOLEAN, typy całkowite INT64, dziesiętne DOUBLE, a wszystko inne to łańcuchy UTF-8 (kolumna kolekcji jako jej JSON).

Weryfikowane z oficjalnym zestawem testowym SQL na FHIR (144 testy repozytorium sql-on-fhir.js tests/, uruchamianych przy każdym budowaniu: wszystkie przechodzą), a dane wyjściowe Parquet odczytywane z powrotem przez DuckDB 1.5.6 z odpowiednimi typami i wartościami. Nieobsługiwane: SQLQuery i SQLView Libraries (SQL nad tabelami widoków), $sql-export, _format=fhir oraz parametry source i group; każdy z nich jest odrzucany z powodem.

8.11 Cyfrowe miary jakości

Cyfrowa miara jakości liczy pacjentów w każdej populacji FHIR Measure w okresie pomiaru (początkowa populacja, mianownik, wykluczenia mianownika i wyjątki, licznik, wykluczenia licznika) i ocenia wynik. Odpowiedź jest FHIR MeasureReport, ukształtowana zgodnie z wytycznymi Da Vinci Data Exchange for Quality Measures (DEQM). To jest kierunek, w którym idą programy eCQM CMS i cyfrowe HEDIS NCQA.

W Perfuse kryteria populacji są FHIRPath ("language": "text/fhirpath"), uruchamiane przez ten sam silnik co SQL on FHIR. Każde kryterium jest oceniane raz na pacjenta. Jego punkt centralny jest to Bundle rekordu pacjenta (kompartament Pacjenta), i ma następujące zmienne: %subject (Pacjent), %periodStart i %periodEnd (okres, jako daty) i %"Measurement Period". Kryterium daje true lub false; pojedyncza wartość, która istnieje, jest uważana za true.

{
  "code": { "coding": [{ "system": "http://terminology.hl7.org/CodeSystem/measure-population", "code": "numerator" }] },
  "criteria": {
    "language": "text/fhirpath",
    "expression": "entry.resource.ofType(Observation).where(code.coding.where(system = 'http://loinc.org' and code = '4548-4').exists() and effective.ofType(dateTime) >= %periodStart and effective.ofType(dateTime) <= %periodEnd).exists()"
  }
}

Populacje zagnieżdżają się zgodnie z specyfikacją Measure. Pacjent jest w mianowniku tylko wtedy, gdy jest w początkowej populacji. Wykluczenie mianownika usuwa pacjenta przed oceną licznika. Wyjątek mianownika liczy się tylko dla pacjenta niebędącego w liczniku. Wynik proporcji to (licznik − wykluczenia licznika) / (mianownik − wykluczenia − wyjątki); wynik dla stosunku to licznik / mianownik; kohorta ma liczbę i nie ma wyniku. Podział kryteriów jednego poziomu dzieli każdą populację według ich wartości (płeć, na przykład).

Perfuse nie ma silnika CQL. Opublikowane CMS eCQMs i cyfrowe miary HEDIS są napisane w CQL, więc nie mogą być uruchomione tak, jak są. Miara, której kryteria są CQL, jest odrzucana z tym powodem. Napisz logikę jako FHIRPath zamiast tego. Odrzucane w ten sam sposób są oceny zmiennych ciągłych, stratyfikatory wieloskładnikowe i tematy Group lub Practitioner.

Monitor › Miary jakości ocenia miarę nad magazynem FHIR tego serwera lub nad wklejonymi zasobami, za okres. Oferuje trzy raporty: podsumowanie, podsumowanie z pacjentami w każdej populacji lub jeden pacjent. Ekran wyświetla populacje, wynik i straty, oraz pobiera MeasureReport. Rozpoczyna się od trzech przykładów: ciśnienie krwi pod kontrolą, diabetes z testem HbA1c i pacjenci widziani w okresie. Są to przykłady ilustracyjne, napisane dla tego podręcznika, i nie są miarami eCQM CMS ani HEDIS. Zapisz do magazynu FHIR sprawdza Miarę i zapisuje ją jako zasób Measure.

Punkt końcowy FHIR odpowiada na Measure/[id]/$evaluate-measure i Measure/$evaluate-measure?measure=<url>, za pomocą GET lub POST zasobu Parameters. Parametry:

• periodStart i periodEnd: wymagane. Data oznacza cały dzień.
• reportType: summary, subject lub subject-list.
• subject: Patient/<id>.
• reporter: Organization/<id>. Gdy jest nieobecny, raport zawiera Organization nazwany przez serve -measure-reporter.
• measure: Miara wysłana w linii, jako parametr POST.

Raport jest zwracany, a nie przechowywany. Operacja jest odczytem, więc token SMART potrzebuje dostępu do odczytu Measure i Patient. Token związany z jednym pacjentem otrzymuje indywidualny raport o tym pacjencie i żadnym innym.

perfuse measure -measure m.json -period-start 2026-01-01 -period-end 2026-12-31 [-type summary|subject|subject-list] [-subject Patient/ID] [-o out] files... ocenia miarę nad plikami FHIR (NDJSON, Bundles, tablice) bez serwera. -measure example:example-bp-control uruchamia przykład dostarczony z systemem, a -examples wyświetla listę dostępnych przykładów.

Zweryfikowane. Walidator HL7 FHIR sprawdza dostarczone Miary przeciwko FHIR R4, bez błędów. Sprawdza również raport podsumowania, indywidualny i lista podmiotów MeasureReport przeciwko profilom DEQM 5.0.0, również bez błędów. Niezweryfikowane: równoważność z opublikowanymi eCQM, ponieważ żadne z nich nie mogą być uruchomione tutaj bez CQL.

8.12 Indeks pacjentów (MPI)

Główny indeks pacjentów łączy rekordy przechowywane przez każdy system dla osoby (numer pacjenta w szpitalu, numer w klinice, numer w laboratorium) w jeden identyfikator przedsiębiorstwa, EUID. Jest wyłączony, dopóki ktoś nie zdecyduje się go utworzyć, ponieważ jest to tabela nazw pacjentów, dat urodzenia i identyfikatorów: włącz Ustawienia → Dane → Indeks pacjentów (lub serve -mpi) i zrestartuj. Znajduje się w mpi.db obok głównej bazy danych.

Karmienie go. Dodaj miejsce docelowe typu mpi (Indeks pacjentów w budowniczym) do kanałów, które przenoszą rejestracje. Czyta PID każdej wiadomości HL7 v2 lub pacjenta FHIR na kanale surowym. Własny identyfikator rekordu jest powtórzeniem PID-3 typu MR (id_type go zmienia); inne, oraz PID-19, stają się jego innymi identyfikatorami. Władza przydzielająca z uniwersalnym identyfikatorem (PID-3.4.2 z typem ISO) staje się urn:oid:...; ta z przestrzenią nazw jest mapowana przez authorities, lub staje się urn:perfuse:aa:<namespace>. A40, A34, A18 lub A39 łączy osobę posiadającą identyfikator MRG-1 z osobą posiadającą PID-3 (no_merge je ignoruje).

destinations:
  - name: index
    type: mpi
    mpi:
      authorities: { HOSP: "urn:oid:1.2.840.114350.1.13.1" }

Dopasowywanie. Nowy rekord jest łączony w tej kolejności:

1. Zaufane identyfikatory. Rekord dzielący identyfikator z systemem wymienionym jako zaufany (identyfikator narodowy, numer przedsiębiorstwa) jest tą samą osobą, bez oceny. Nigdy nie wymieniaj systemu, który jest współdzielony przez rodzinę, takiego jak numer subskrybenta płatnika.
2. Ocena. W przeciwnym razie osoby, których rekordy mogą się pokrywać, są znalezione przez blokowanie (ten sam dźwięk nazwy rodziny i rok urodzenia, ta sama data urodzenia, lub ten sam numer telefonu) i oceniane z wagami Fellegi-Suntera nad nazwą rodziny i imieniem (Jaro-Winkler i Soundex, akcenty i znaki ignorowane, nazwy zamienione zauważone), datą urodzenia (zamieniony dzień i miesiąc to częściowa zgodność), płcią, kodem pocztowym, numerem telefonu i adresem. Tylko pola, które oba rekordy posiadają, są brane pod uwagę. Ocena jest dowodem znalezionym jako udział w możliwym dowodzie. Blokowanie używa pięciu kluczy, aby jeden błąd nie ukrywał osoby: dźwięk nazwy rodziny i rok urodzenia, data urodzenia, numer telefonu, dźwięki obu nazw (w dowolnej kolejności), oraz kod pocztowy z dźwiękiem nazwy.
3. Decyzja. Domyślnie nic nie łączy się na podstawie oceny sama. Rekord oceniony na poziomie lub powyżej progu przeglądu (60%) staje się nową osobą, a możliwe dopasowanie czeka w kolejce przeglądu; te na poziomie lub powyżej progu automatycznego (90%) z nazwą rodziny i datą urodzenia obu zgodnych są oznaczone jako *pewne*. Łączenie dwóch osób w jedną (nałożenie) umieszcza wyniki jednego pacjenta w wykresie innego pacjenta, więc automatyczne łączenie jest przełącznikiem, który administrator włącza (Łącz pewne dopasowania bez pytania nikogo), gdy kolejka pokazała, że pewne są prawidłowe. Z włączonym, pewne dopasowanie łączy się, gdy żadna inna osoba nie uzyska tak wysokiej oceny. Poniżej progu przeglądu rekord jest nową osobą.

Numery narodowe. Numer NHS (i Szkocji CHI oraz numer opieki zdrowotnej i pielęgnacji w Irlandii Północnej), numer PPSN i IHI w Irlandii, numer KVNR w Niemczech, numer SVNR w Austrii, numer AHV w Szwajcarii, numer BSN w Holandii, numer rejestru narodowego w Belgii, numer matricule w Luksemburgu, numer INS we Francji (NIR i NIA), numer codice fiscale we Włoszech, numer DNI/NIE i CIP-SNS w Hiszpanii, numer SNS w Portugalii, numery osobiste w krajach nordyckich (Szwecja, Dania, Norwegia z numerem D, Finlandia, Islandia), numery bałtyckie, numer PESEL w Polsce, numery urodzenia w Czechach i na Słowacji, oraz numery węgierskie, rumuńskie, bułgarskie, chorwackie, słoweńskie i greckie są znane indeksowi. Każdy jest przechowywany w jeden sposób: pod systemem schematu, bez spacji i kropek, więc numer NHS wysłany jako urn:oid:2.16.840.1.113883.2.1.4.1|999 000 0018 przez jeden system i jako https://fhir.nhs.uk/Id/nhs-number|9990000018 przez inny system jest jednym identyfikatorem. Powtórzenie PID-3 wiadomości HL7 v2, którego typ identyfikatora jest NN i trzyliterowy kod kraju (NNDEU, NNNLD), jest odczytywane jako główny numer tego kraju, a typ NH z władzy NHS jako numer NHS. Każdy numer jest testowany na poprawność: jeden, który nie przejdzie testu, jest przechowywany w rekordzie, zgłaszany (zamaskowany) w odpowiedzi i nigdy nie jest używany do łączenia lub wyszukiwania, ponieważ błędny cyfra zwykle tworzy numer innej osoby. Numer CPR w Danii jest sprawdzany tylko pod kątem daty, ponieważ numery wydane od 2007 roku nie muszą przechodzić starego testu modułu 11.

Lista ustawień wyświetla każdy schemat wraz z jego formatem, sprawdzeniem i systemem, w którym jest przechowywany. Systemy pobrane z krajowych przewodników FHIR (UK Core, fhir.de, Nictiz, CH Core, ANS, HL7 Italia, MedCom, szwedzki, norweski i fiński rejestr OID) są oznaczone jako takie; pozostałe są domyślnymi wartościami, które można zmienić na wartości krajowe, co może być wykonane przez stronę dla każdego schematu (stara wartość jest nadal rozpoznawana). Zaufanie do schematu jest jednym kliknięciem. Krajowe numery są wyświetlane w pełni edytorom i powyżej domyślnie oraz maskowane (ostatnie kilka znaków) dla wszystkich innych; Kto widzi numery w pełni zmienia to, w dół do widzów lub w górę do administratorów tylko. Gdzie prawo kraju ogranicza użycie numeru (francuski Référentiel INS, irlandzki PPSN, belgijski numer rejestru narodowego, niemiecki §290 SGB V), ustawienia mówią o tym. GET /api/mpi/schemes wyświetla schematy, a POST /api/mpi/check sprawdza jeden numer bez zapisywania go. FHIR $match i PIXm odpowiadają na autoryzowane żądania klientów z numerami w pełni.

Data zapisana w formacie dzień-miesiąc lub miesiąc-dzień (08/15/1972) jest zachowywana w takiej postaci i nie jest dopasowywana do formatu rok-pierwszy: porządki amerykański i europejski nie zgadzają się, a zgadywanie połączyłoby nieodpowiednie osoby.

Ekran indeksu pacjenta (Build) wyświetla liczby, znajduje osoby po nazwie, numerze, EUID lub dacie urodzenia i otwiera każdą osobę: ich rekordy, każdy identyfikator oraz historia tego, co się z nimi stało i kto to zrobił. Edytorzy decydują o przeglądach (Ta sama osoba łączy je; Różne osoby trzyma je oddzielnie na zawsze), przenoszą rekord do innej osoby, usuwają rekord (Nie ta osoba), a łączą dwie osoby. Administratorzy ustawiają progi, zaufane systemy identyfikatorów, numery krajowe i system EUID. Każde wyszukiwanie i odczyt osoby są zapisywane w rejestrze audytu.

Odpowiadanie innym. POST /fhir/Patient/$match (operacja FHIR, jak IHE PDQm ITI-119 ją używa) przyjmuje Pacjenta i zwraca osoby, które mogą być nim, najlepsze jako pierwsze, każdy Pacjent, którego id jest EUID, z każdym identyfikatorem, search.score, oraz rozszerzeniem stopnia dopasowania (certain, probable, possible); onlyCertainMatches i count są honorowane. PIXm (/mhd/Patient/$ihe-pix, ITI-83) odpowiada z indeksu: każdy identyfikator każdego rekordu połączonego z osobą, oraz EUID. Tak robią również PIX i PDQ w HL7 v3 (/pixv3, /pdqv3; zobacz dokumenty IHE), które również je zasilają.

Interfejs API to /api/mpi (podsumowanie i wyszukiwanie), /api/mpi/persons/{euid}, /api/mpi/find, /api/mpi/reviews, /api/mpi/records (rejestr, link, unlink), /api/mpi/merge i /api/mpi/settings.

Wagi. Domyślne wagi Fellegi-Sunter pochodzą z literatury o łączeniu rekordów dla danych rejestracji szpitalnej. Oszacuj z naszych rekordów (w ustawieniach, administratorzy; POST /api/mpi/estimate) dopasowuje je do indeksu strony z oczekiwaną maksymalizacją, bez potrzeby przeglądanych par: m (zgodność wśród prawdziwych dopasowań) z par, które blokada łączy, u (zgodność przypadkowa) z 20 000 par losowo wybranych, ponieważ pary zablokowane zgadzają się w nazwach i datach przez konstrukcję. Oszacowanie jest wyświetlane obok używanych wag i nie zmienia nic, dopóki nie jest użyte i zapisane. Pole porównywane na zbyt małej liczbie par zachowuje swoją domyślną wartość. Dopasowanie zakłada, że pola są niezależne od klasy, co nie jest całkowicie prawdą, więc traktuj dużą zmianę z podejrzeniem.

Pomierzone. Na zestawie danych FEBRL 3 (5 000 syntetycznych rekordów 2 000 osób, duplikaty z błędami pisarskimi, pola zamienione, brakujące wartości i pseudonimy; PERFUSE_TEST_FEBRL), zarejestrowane w kolejności pliku z przeglądającym odpowiadającym na każdą parę w kolejce poprawnie:

Żaden rekord nie był nigdy połączony z niewłaściwą osobą, a żadna z 2 000 nowych osób nie była niepotrzebnie umieszczona w kolejce. Pominięte osoby różnią się prawie we wszystkich polach (data urodzenia i adres oba źle wpisane, na przykład) i mają wynik poniżej progu przeglądu. FEBRL jest syntetyczny i ma niewiele osób o tym samym imieniu; rzeczywisty indeks ma ich więcej, więc jego kolejka przeglądu będzie dłuższa, a te liczby są dolną granicą staranności, a nie obietnicą.

8.13 Ograniczone

CSV i jego krewniacy. Opcje znajdują się na źródle w budowniczym, a odniesienie do formatu listuje klucze plików.

Ścieżki adresują kolumny. Nazwana kolumna jest dostępna, gdy wiersz nagłówka jest deklarowany lub nazwy są podane; w przeciwnym razie kolumny są pozycyjne.

8.13.1 Nazwanie kolumn

Istnieją dwa sposoby, a są one wykluczające się. Albo pierwszy wiersz pliku nazywa je — pierwszy wiersz nazywa kolumny — albo sami je wymieniasz, w porządku. Deklarowanie nagłówka oznacza, że wiersz nie jest traktowany jako dane.

Jeśli żadna z nich nie jest ustawiona, kolumny mogą być adresowane tylko przez pozycję, więc filtr napisany przeciwko nazwie nie ma nic do dopasowania. Włączenie nagłówka usuwa listę nazw zamiast zachować obie: z nagłówkiem nazwy pochodzą z pliku, więc lista pozostawiona z tyłu byłaby ignorowana, a kanał, który czyta tak, jakby wybrał nazwy, gdy plik wybrał je, jest trudniejszy do debugowania niż ten, który odmawia.

8.13.2 Co widzi filtr lub skrypt

Jeden dokument ograniczony staje się wieloma wiadomościami, więc trzeba to stwierdzić, zanim napiszesz którykolwiek z nich.

Z dzieleniem włączonym, wszystko działa na wiersz. Declaratywne kroki, filtr i skrypt transformatywny widzą jeden wiersz, a ścieżka oznacza *ten* wiersz kolumny. Filtr, który odrzuca wiersz, odrzuca tylko ten wiersz, a otrzymana liczba jest wierszami, a nie dokumentami.

Z dzieleniem wyłączonym, wiadomość jest cały dokument i zapis, który przekracza wiersze, jest odrzucany, a nie stosowany do pierwszego. To odrzucenie jest celowe: ciche zapisywanie do wiersza jeden jest zachowaniem, które produkuje plik, który wygląda na przekształcony i nie jest.

8.13.3 Trzy, które zmieniają to, co uważa się za błąd

Akceptuj wiersze z niewłaściwą liczbą kolumn jest wyłączone domyślnie. Wiersz z zbyt wieloma lub zbyt małymi kolumnami jest wtedy błędem, co jest tym, co łapie plik, którego kształt zmienił się bez ostrzeżenia. Włączenie go akceptuje wiersz i pozostawia brakujące kolumny puste.

Przytnij spacje wokół każdej wartości naprawia powszechny przypadek wartości wypełnionej do szerokości kolumny. Pozostaw to wyłączone, gdzie spacje końcowe są istotne, co zdarza się czasem w identyfikatorze.

Zachowaj puste linie jako wiersze jest wyłączone domyślnie i zwykle powinno być. Włączone, pusta linia staje się wierszem pustych kolumn, co ma znaczenie tylko wtedy, gdy liczba musi dokładnie odpowiadać plikowi.

8.14 Surowy

Żadnego parsowania. Wiadomość to bajty.

Użyj tego, gdy zawartość nie jest czymś, co Perfuse rozumie i nie potrzebuje: PDF przenoszony między systemami, format własny, już utworzony dokument przekazywany niezmieniony.

Koszt to to, że nic, co zależy od struktury, nie działa — żadna transformacja na poziomie pola, żaden filtr na polu, żadne porównanie na poziomie pola w sprawdzaniu parzystości. Kanał surowy jest rurą i szczerze mówi o tym, że jest nią.

8.15 Wybór

Jeśli wiadomość jest w wersji HL7 v2, użyj hl7, nawet jeśli masz zamiar przekazać ją bez zmian. Analiza daje Ci ślad, statystyki na poziomie pól, możliwość filtrowania później oraz możliwość porównywania. Użycie raw na treści, którą można przeanalizować, nie daje nic i powoduje utratę wszystkich tych funkcjonalności.

Użyj raw, gdy analiza zakończyłaby się niepowodzeniem lub byłaby nieprawdziwa w odniesieniu do zawartości.

8.16 SMART Łącza zdrowotne i karty

CMS *Kill the Clipboard* prosi dostawców o zaakceptowanie rekordów pacjenta z kodu QR podczas rejestracji i o przekazanie rekordu wizyty w ten sam sposób. Kod QR zawiera SMART Health Link (shlink:/...): adres, 256-bitowy klucz i opcjonalnie etykietę, datę wygaśnięcia i flagę hasła. Wymiana → Linki zdrowotne odczytuje jeden.

Odbieranie. Wklej link lub zeskanuj go za pomocą kamery, gdzie przeglądarka może (Chrome i Edge). Perfuse pobiera manifest, odszyfrowuje każdy plik za pomocą klucza z linku, podsumowuje każdy pakiet FHIR - kim jest pacjent, ile zasobów każdego rodzaju - i sprawdza każdą SMART Health Card w środku przeciwko opublikowanemu kluczowi wydawcy. *Dostarcz do kanału* przekazuje zawartość FHIR do kanału jako wiadomość, co pozwala jej dotrzeć do EHR. Pobieranie jest ograniczone do polityki wyprowadzania na czas połączenia, odmawia się plain HTTP, a odpowiedź serwera, który nie jest serwerem manifestu, nigdy nie jest wyświetlana, ponieważ adres pochodzi z obcego kodu QR.

Udostępnianie. *Udostępnij* szyfruje pakiet FHIR, hostuje go i wyświetla link oraz jego kod QR raz. Serwer zachowuje ciphertext, a nie klucz - nie może otworzyć tego, co hostuje, i nie może pokazać linku ponownie. Hasło jest hashowane; dziesięć błędnych haseł wyłącza link. Linki wygasają po 30 dniach domyślnie, mogą być unieważnione i wyświetlają, jak często i przez kogo były pobierane. Uruchom serwer z -public-url ustawionym na adres https, który telefon pacjenta może osiągnąć; adres URL manifestu, który buduje, musi pasować do specyfikacji 128 znaków.

Weryfikacja karty. *Weryfikuj karte* przyjmuje numeryczny shc:/ QR (jeden fragment lub kilka), plik .smart-health-card lub JWS i stwierdza, czy podpis pasuje do klucza wystawcy.

8.17 UN/EDIFACT

dataType: edifact odczytuje wymiany UN/EDIFACT (ISO 9735): ORDERS, INVOIC, DESADV, IFTSTA i resztę, w tym europejskie wiadomości dotyczące ochrony zdrowia i laboratoryjne. Ciąg znaków ostrzegawczych usługi (UNA) jest honorowany, wraz z znakiem zwalniania i, dla wersji składni 4, separatorem powtarzania; grupy funkcjonalne (UNG/UNE) są opcjonalne. Wymiana jest dostarczana dokładnie tak, jak ją napisał nadawca.

name: supplier-orders
dataType: edifact
edifact:
  envelope: require      # require (default), warn, or ignore
  split: false           # true: one interchange per message
  acknowledge: contrl    # none (default) or contrl
filter: 'UNB-2.1 == "5412345000013"'
source:
  type: as2              # or http, sftp, file, email ...
  # ...
destinations:
  - name: orders
    type: file
    dir: /data/orders
    filter: 'UNH-2.1 == "ORDERS"'

Koperta. Liczba segmentów UNT i odniesienie, liczba wiadomości UNE i odniesienie, oraz liczba i odniesienie UNZ są porównywane z tym, co zawiera wymiana. Z require, domyślnie, niezgodność odmawia wymiany (jest to sposób, w jaki przerwany transfer jest wyświetlany); warn akceptuje ją i rejestruje ostrzeżenie; ignore nie sprawdza.

Ścieżki, dla filtrów kanału i miejsca przeznaczenia, liczą elementy i składniki od 1 w kolejności, w jakiej segment jest zapisywany, tak jak przewodniki implementacyjne je numerują: BGM-2 (numer dokumentu), BGM-1.1, NAD(2)-2.1 (strona drugiego NAD), LIN-3(2).1 (powtórzenie), UNB-2.1 (nadawca), UNH-2.1 (typ wiadomości). Ścieżka bez wystąpienia adresuje każdy z nich.

Dzielenie dostarcza jedną wymianę na wiadomość, każdą z oryginalnym UNB (i nagłówkiem grupy) i trailerami, które liczą jeden, więc zamówienie może być filtrowane, wyszukiwane i ponawiane samodzielnie. Filtry miejsca przeznaczenia widzą każdy kawałek. Miejsce przeznaczenia pliku nazywa pliki według typu wiadomości (ORDERS_INVOIC-20261017.edi), a ${control_id} jest odniesieniem do wymiany.

STER. KONTROLNY. Z acknowledge: contrl, nadawca wysyłający za pomocą HTTP otrzymuje odpowiedź z składnią CONTRL i raportem usługi: akcja UCI 7 kiedy wymiana została odczytana i dostarczona, 4 kiedy została odrzucona lub nie mogła być dostarczona (wtedy HTTP 400 lub 502). Nie można jej łączyć z split, ponieważ CONTRL odpowiada na całą wymianę. Przy użyciu AS2 potwierdzenie odbioru przez partnera jest potwierdzeniem.

Nie jest oferowane: katalogi wiadomości (które segmenty ORDERS D.96A zezwalają), więc struktura jest sprawdzana, a nie zawartość; transformacje, które przepisują dokument partnera; oraz skrypty filtrujące lub transformatory (preprocesor jest uruchamiany przed parsowaniem). Sprawdzono w stosunku do pydifact 0.1.8, niezależnego parsera, w obu kierunkach.

9 Potwierdzenia

Potwierdzenie informuje nadawcę, co się stało. Dla HL7 v2 za pośrednictwem MLLP jest to wiadomość ACK; nadawca nie wyśle następnej wiadomości, dopóki nie dotrze, i zwykle ponownie wyśle, jeśli nie dotrze.

Błędne potwierdzenia są najczęstszym sposobem, w jaki integracja cicho traci dane, ponieważ nadawca, który jest potwierdzany, nie ma powodu do skargi.

9.1 Czas

Opisane w przepływie wiadomości, a podsumowanie jest: ack.when jest on_delivery domyślnie, co oznacza, że potwierdzenie jest wysyłane tylko po tym, jak każde włączone miejsce przeznaczenia zaakceptuje wiadomość. on_receipt wysyła je tak szybko, jak tylko wiadomość jest przeanalizowana i umieszczona w kolejce.

9.2 Co Perfuse wysyła

AA, gdy wiadomość została zaakceptowana, AE, gdy została odrzucona z powodu, o którym nadawca mógł coś zrobić, i AR, gdy została odrzucona z powodu, o którym nadawca nie mógł nic zrobić.

Różnica między AE a AR polega na tym, kto musi coś zrobić. AE oznacza, że wiadomość miała problem - pole, które nie mogło być przeanalizowane jako data, brakujący wymagany segment - i nadawca może to poprawić i ponownie wysłać. AR oznacza, że Perfuse nie mógł zaakceptować go niezależnie od zawartości, co zwykle oznacza problem z konfiguracją lub dostępnością na tym końcu. Nadawca, który ponownie wysyła po AR, otrzyma tę samą odpowiedź.

9.3 Identyfikacja tego silnika

ack.application i ack.facility wypełniają MSH-3 i MSH-4 potwierdzenia.

Gdy oba są puste, potwierdzenie jest lustrzanym odbiciem oryginalnego odbiorcy — używa tego samego, co wiadomość przychodząca miała w MSH-5 i MSH-6. To jest to, czego większość nadawców oczekuje, i jest to ustawienie domyślne z tego powodu.

Ustaw je explicite, gdy nadawca je waliduje, lub gdy wiele instancji Perfuse obsługuje ten sam kanał i musisz wiedzieć, który z nich odpowiedział.

9.4 Zdarzenie wyzwalające

ack.include_trigger_event wysyła ACK^A01 zamiast gołego ACK.

Niektórzy odbiorcy wymagają tego, a inni odrzucają, co jest powodem, dla którego jest to opcja explicite bez domyślnego ustawienia. Jeśli nadawca odmawia twoich potwierdzeń i treść wygląda dobrze, to jest pierwsza rzecz do sprawdzenia.

9.5 Negatywne potwierdzenia nie są niepowodzeniami do ukrycia

Potwierdzenie negatywne (NACK) traktowane jako sukces jest jednym z najbardziej szkodliwych błędów konfiguracyjnych i jest na tyle powszechne, aby je nazwać. Zdarza się to, gdy destination wysyła z powrotem negatywne potwierdzenie, a strona nadawcza rejestruje *transmisję* jako pomyślną, ponieważ bajty wyszły i coś wróciło.

Perfuse odczytuje potwierdzenie, które otrzymuje od destination MLLP, i rejestruje wynik odpowiednio. AE lub AR z systemu podrzędnego jest awarią dostarczenia, jest powtarzany zgodnie z zasadą destination, i liczy się do współczynnika awarii, który wyzwala alarmy.

9.6 Limit czasu

Czekanie na potwierdzenie jest ograniczone. Gdy nie przychodzi ono na czas, dostarczenie jest awarią i jest umieszczane w kolejce do powtórzenia.

Limit czasu nie jest taki sam jak odrzucenie i jest rejestrowany inaczej. Odrzucenie oznacza, że druga strona rozważyła wiadomość i ją odrzuciła; limit czasu oznacza, że nie wiesz, czy została przetworzona. Ta różnica decyduje o tym, czy powtórzenie jest bezpieczne: powtarzanie po odrzuceniu jest bezcelowe, a powtarzanie po limicie czasu naraża na duplikat. Perfuse powtarza po limicie czasu, ponieważ brakująca wiadomość kliniczna jest zwykle gorszy niż duplikat, a system odbiorczy jest zwykle w stanie wykryć powtarzany identyfikator kontrolny wiadomości.

Czy ten handel jest odpowiedni dla danego kanału, jest sądem, i jest warte podjęcia celowo dla wszystkiego, gdzie duplikat ma konsekwencje kliniczne — zamówienie, podanie leku — zamiast akceptowania domyślnego ustawienia cicho.

9.7 Źródła, które nie potwierdzają

Nie każdy transport ma ten pojęcie. Źródło pliku nie ma gdzie wysłać potwierdzenia; źródło brokera potwierdza do brokera, a nie do oryginalnego nadawcy; źródło HTTP odpowiada kodem statusu.

Gdzie źródło nie może dostarczyć trybu potwierdzenia, o który prosi kanał, kanał jest odrzucany podczas ładowania, zamiast zaczynania i cicho nie potwierdzania. Kanał, który uważa, że potwierdza, a nie potwierdza, jest gorszy niż ten, który nie zaczyna.

9.8 Potwierdzenia X12

Wszystko powyżej dotyczy HL7 v2. X12 ma własne potwierdzenia, i w przeciwieństwie do v2 są wyłączone domyślnie: puste ustawienie oznacza brak.

To ustawienie domyślne jest bezpieczne, ponieważ partner handlowy, który nie oczekuje potwierdzenia i otrzymuje je, może traktować je jako niespodziewane połączenie. Klucz acknowledge na kanale X12 przyjmuje jedną z czterech wartości:

Które potwierdzenie wysłać, jest właściwością relacji partnerskiej handlowej, a nie wiadomości, co jest powodem, dla którego musi być skonfigurowane i nie może być wnioskowane. 999 zastępuje 997 dla transakcji HIPAA, ale wiele partnerów — starsze połączenia płatników — jest ustawionych do oczekiwania 997 i będzie traktować 999 jako nierozpoznany plik.

9.9 Potwierdzenia HL7 v3

Kanał HL7 v3 wysyła potwierdzenie domyślnie, co jest przeciwieństwem X12 i warte zauważenia.

Powodem jest transport, a nie standard: interakcja v3 zwykle przychodzi przez połączenie synchroniczne, przy czym aplikacja wysyłająca czeka na odpowiedź, a nadawca, który nie otrzymuje nic, zwykle ponawia próbę. To jest sposób, w jaki pacjent zostaje zarejestrowany trzykrotnie.

Wyłączenie jest możliwe i musi być wykonane jawnie — „nie ustawiono” i „ustawiono na false” są celowo różne, więc domyślna wartość pozostaje, chyba że ktoś powiedział inaczej.

10 Dostarczanie, kolejkowanie i ponawianie

Miejsce docelowe, do którego nie można się połączyć, jest przypadkiem normalnym, a nie wyjątkiem. Systemy są uruchamiane ponownie, sieci przestają działać, a silnik interfejsu szpitala jest niedostępny podczas własnego okna konserwacji. Dostarczanie jest oparte na tym.

10.1 Kolejka na miejsce docelowe

Każde miejsce docelowe ma swoją własną kolejkę. Miejsce docelowe, które ulega awarii, nie wpływa na inne, a każde z nich ma własną głębokość, wiek i stan ponawiania.

Kolejkowanie odbywa się na podstawie miejsca docelowego, a nie kanału, ponieważ awaria dotyczy miejsca docelowego. Kolejka na poziomie kanału utrudniłaby dostarczanie do trzech działających systemów, ponieważ czwarty jest wyłączony, a obie sytuacje — jedno niedostępne miejsce docelowe, wszystkie cztery niedostępne — wyglądałyby tak samo w statystykach.

10.2 Ustawienia kolejki

queue on a destination:

Dwa ostatnie elementy były nieobecne w tej tabeli i w konstruktorze, a są to para, która zapobiega wypełnieniu dysku. Kolejka bez nich rośnie, aż system plików jest pełny, a awaria ta pojawia się jako coś niezwiązanego z awarią — niepowodzenie zapisu w innym miejscu — zamiast jako problem z kolejką.

Czas oczekiwania rośnie między próbami aż do max_backoff. Rosnący, a nie stały, ponieważ miejsce docelowe, które jest wyłączone, zwykle jest wyłączone na kilka minut, a nie sekund, a ponawianie prób co sekundę przez dziesięć minut powoduje kilkaset wpisów w dzienniku, które zakopują ten, który się liczy.

10.3 Zachowanie kolejności

W ramach miejsca docelowego wiadomości są dostarczane w kolejności przybycia, a wiadomość, która nie powiedzie się, zachowuje swoje miejsce. Późniejsze wiadomości czekają za nią, zamiast ją wyprzedzać.

Jest to odpowiedni domyślny ustawienie dla danych klinicznych — przyjęcie i wypisanie zastosowane w złej kolejności jest gorsze niż oba są spóźnione — i ma konsekwencję wartą zrozumienia: jedna wiadomość, która zawsze kończy się niepowodzeniem, zatrzymuje wszystko, co jest za nią.

Dlatego głębokość kolejki i wiek kolejki są oddzielnymi warunkami alarmowymi. Głęboka kolejka, która się wypuszcza, jest zajętym systemem. Kolejka, której najstarsza wiadomość stale się starzeje, jest zablokowana, a rodzaje alertów queue-depth, queue-age i queue-stuck odróżniają je.

10.4 Gdy kolejkowanie jest wyłączone

Z queue.enabled ustawionym na false, nieudane dostarczanie jest po prostu nieudanym dostarczaniem. Zostaje ono zarejestrowane i nie jest ponawiane.

Jest to odpowiedni wybór, gdy spóźnione dane są gorsze niż brak danych — wyświetlanie w czasie rzeczywistym, system powiadomień, wszystko, gdzie wiadomość dostarczona czterdzieści minut po zdarzeniu byłaby myląca, a nie po prostu opóźniona.

Jest to zły wybór dla wszystkiego, co trafia do rekordu, gdzie wiadomość jest równie ważna godzinę później.

10.5 Ponawianie a kolejkowanie

Istnieją dwa mechanizmy i działają one na różnych poziomach.

retry w miejscu docelowym określa natychmiastowe próby w ramach jednego dostarczania — połączenie, które kończy się niepowodzeniem, jest ponawiane po krótkiej przerwie, bez opuszczania ścieżki dostarczania. To obsługuje przejściowe awarie: przerwane połączenie, chwilowa odmowa.

queue określa, co się dzieje, gdy te natychmiastowe próby są wyczerpane. Wiadomość opuszcza ścieżkę dostarczania i jest ponawiana później według dłuższego harmonogramu.

Oba istnieją, ponieważ awarie są różne. Reset połączenia na pierwszej próbie zwykle znika na drugiej, a przechodzenie przez kolejkę dla niego dodałoby kilka minut opóźnienia do awarii, która trwała kilka milisekund. Miejsce docelowe, które zostało wyłączone na konserwację, nie wróci w ciągu trzech natychmiastowych prób, a uderzanie w nie jest bezcelowe.

10.6 Co HTTP endpoint uważa za dostarczone

Punkt końcowy HTTP ma trzy ustawienia, które decydują, czy wiadomość jest traktowana jako wysłana, a wszystkie trzy znajdują się w punkcie końcowym w konstruktorze.

Kody stanu, które oznaczają dostarczenie. Pusty oznacza dowolny kod 2xx. Niektóre punkty końcowe odpowiadają 202 Accepted dla czegoś, co jeszcze nie zostało przetworzone, a niektóre odpowiadają 200 z błędem w treści — to drugie jest tym, do czego służy *Traktuj jako nieudane, jeśli odpowiedź zawiera*.

Postępuj zgodnie z przekierowaniami. Wyłączone domyślnie i celowo. Przekierowanie może wskazywać na inny host, więc postępowanie zgodnie z nim wysyła wiadomość w miejsce, które nikt nie skonfigurował, i zgłasza sukces.

Token nośnika. Wysłany jako nagłówek Authorization. Zostaje przechowywany z kanałem i nigdy nie jest ponownie wyświetlany, więc pozostawienie pola pustego podczas edytowania istniejącego kanału zachowuje token już zapisany, zamiast go czyścić.

10.7 Nazwanie i przycinanie folderu archiwum

Miejsce przeznaczenia pliku domyślnie dołącza do jednego pliku na dzień i typ wiadomości (20261012-ADT_A01.hl7), ramki MLLP, więc plik odtwarza się za pomocą perfuse send. Cztery ustawienia w miejscu przeznaczenia zmieniają to.

Nazwa pliku (file_name) tworzy jeden plik na wiadomość, nazwany z ${date}, ${timestamp}, ${control_id}, ${message_type} i ${destination}. Nazwa, która jest już zajęta (ten sam identyfikator kontrolny dwa razy), otrzymuje unikalny sufiks zamiast nadpisywać wiadomość tam.

Dołącz (append: true) zapisuje każdą wiadomość do pliku Nazwa pliku, który nazwuje, więc ${date}.hl7 to jeden plik na dzień dla każdego typu.

Sufiks podczas zapisu (temp_suffix, jeden plik na wiadomość tylko) domyślnie .part i jest usuwany przez przemianowanie, gdy plik jest kompletny. Każdy, kto zbiera te pliki, nie powinien pobierać niekompletnego pliku, a przemianowanie w folderze jest atomowe. Zmień to tylko wtedy, gdy kolektor filtruje na innym rozszerzeniu.

Usuń po (retain_hours) przycina pliki w folderze starsze niż podana liczba godzin, sprawdzana co najwyżej co dziesięć minut, gdy przychodzą wiadomości. Tylko zwykłe pliki bezpośrednio w folderze są usuwane, nigdy podfolder. Pusty lub zero zachowuje je na zawsze, co jest domyślnym ustawieniem i jest decyzją, a nie zaniedbaniem — ale archiwum, które nikt nie przycina, wypełnia dysk, a pełny dysk zatrzymuje kanał, a nie archiwizację.

10.8 Wysyłanie do serwera FHIR

Trzy ustawienia decydują, ile jest sprawdzane przed wysłaniem paczki.

Oświadczenie o zgodności z US Core dodaje profil do każdego zasobu. Oświadczaj to tylko wtedy, gdy zasób zawiera to, co profil wymaga, ponieważ odbiorca może sprawdzić poprawność oświadczenia i odrzucić paczkę, która w przeciwnym razie zostałaby zaakceptowana.

Sprawdź poprawność przed wysłaniem sprawdza każdy zasób tutaj, zamiast uczyć się od odbiorcy. Odrzucenie na drugim końcu mówi ci mniej, później i często tylko w logu, którego nie możesz przeczytać.

Traktuj ostrzeżenia jako odrzucenia ma wpływ tylko wtedy, gdy walidacja jest włączona, a kontrola jest niedostępna, dopóki nie jest. Jest wystarczająco surowy, aby zatrzymać paczkę, którą odbiorca zaakceptowałby, więc należy ją umieścić na kanale, który jest wprowadzany, a nie w służbie.

10.8.1 Usługi FHIR hostowane

Blok fhir punktu końcowego auth loguje się do usług hostowanych, gdzie wklejony token nośnika przestaje działać w ciągu godziny:

fhir:
  url: https://healthlake.us-east-1.amazonaws.com/datastore/<id>/r4/
  auth: {type: aws, access_key_id: ${AWS_ACCESS_KEY_ID}, secret_access_key: ${AWS_SECRET_ACCESS_KEY}}

aws podpisać każde żądanie dla AWS HealthLake z wersją 4 podpisu, z regionem odczytanym z adresu URL. azure otrzymuje token Microsoft Entra ID dla Azure Health Data Services z tenant_id, client_id i client_secret - rejestracji aplikacji posiadającej rolę FHIR Data Contributor - z adresem URL usługi FHIR jako jego odbiorcą. client_credentials robi to samo przeciwko dowolnemu adresowi URL tokenu OAuth 2.0 token_url. Tokeny są ponownie wykorzystywane, aż do minute przed ich wygaśnięciem. Te same opcje znajdują się pod Logowanie do hostowanej usługi w konstruktorze kanału.

10.8.2 Raportowanie przypadków zdrowia publicznego

Zaznacz Raportuj warunki raportowania do zdrowia publicznego na miejscu przeznaczenia FHIR, a wyśle raporty przypadków zamiast pakietów. Każda wiadomość jest sprawdzana pod kątem kodu wyzwania warunku raportowania: diagnozy, badania laboratoryjnego lub zakodowanego wyniku. Jeśli go ma, wiadomość staje się HL7 eCR 2.1.2 eICR, zawinięta w wiadomość eCR i opublikowana w adresie URL $process-message. Jeśli go nie ma, nic nie jest wysłane i nic nie zawodzi; miejsce przeznaczenia liczy ją jako nieraportowaną.

fhir:
  url: https://ecr.agency.example/fhir
  ecr:
    rctc: /etc/perfuse/rctc.json
    source: https://fhir.springfield-general.example/fhir
    facility: {name: Springfield General Hospital, phone: +1-217-555-0100, city: Springfield, state: IL}

rctc to Kod wyzwalacza warunków raportowania, jako zestaw wartości FHIR lub pakiet eRSD. Wymaga licencji UMLS, więc nie jest dołączony; bez niego krótki przykładowy wbudowany jest używany, tylko do testowania. source to miejsce, w którym agencja wysyła swoją odpowiedź na raportowanie. Obiekt jest wymagany, ponieważ eCR prosi o jego numer telefonu i adres, a wiadomość w wersji 2 nie ma ich.

Raport mówi, co wiadomość nie miała, zamiast wymyślać to, i każda luka jest rejestrowana. Wypróbuj wiadomość w panelu Raport przypadku zdrowia publicznego laboratorium FHIR, zanim wskazujesz żywy kanał na agencję.

10.8.3 Wyniki laboratoryjne do zdrowia publicznego: ELR

perfuse elr -config elr.yaml results.hl7 przekształca wyniki laboratoryjne w wiadomości ELR HL7 2.5.1, które otrzymują departamenty zdrowia stanu, po jednej dla każdej wiadomości z wynikiem raportowalnym i tylko dla zamówień, które je zawierają: pełna morfologia krwi obok pozytywnego testu SARS-CoV-2 nie jest sprawą zdrowia publicznego. Kody wyzwalacza są takie same, jak raportowanie przypadków, RCTC, które ładujesz lub wbudowany przykład.

ELR nazywa każdego po OID lub numerze CLIA, który nie jest przekazywany przez źródło i odbiorcę, więc pochodzą one z pliku:

sending_application: {namespace: Perfuse, id: 2.16.840.1.113883.19.5.9, type: ISO}
sending_facility: {namespace: Springfield Lab, id: 2.16.840.1.113883.19.5, type: ISO}
receiving_application: {namespace: ELR, id: 2.16.840.1.113883.19.6.1, type: ISO}
receiving_facility: {namespace: State DOH, id: 2.16.840.1.113883.19.6, type: ISO}
processing: T
ordering_facility: {name: Springfield Clinic, phone: "+1 217 555 0100", line: 1 Main St, city: Springfield, state: IL, postalCode: "62701"}
performing_lab: {name: Springfield Lab, line: 2 Lab Rd, city: Springfield, state: IL, postalCode: "62701"}
performing_lab_clia: 14D0000000
placer_authority: {namespace: SPRINGFIELD-EHR, id: 2.16.840.1.113883.19.5.1, type: ISO}
filler_authority: {namespace: SPRINGFIELD-LAB, id: 2.16.840.1.113883.19.5.2, type: ISO}

Zamawiający obiekt, wykonujący laboratorium i władze przypisujące są używane tylko wtedy, gdy wiadomość laboratoryjna je pomija, a każde użycie jest notatką. To, co tylko laboratorium wie, nigdy nie jest wypełnione: wynik bez typu próbki idzie ze pustym SPM-4 i notatką, mówiącą o tym, ponieważ zgadywana próbka w raporcie do zdrowia publicznego jest gorsza niż luka, o której stan może zapytać. Zaczynaj z processing: T, podczas gdy zespół onboardingu stanu testuje kanał.

To, co laboratorium otrzymało poprawnie, jest przechowywane tak, jak zostało wysłane. Zamówienie podrzędne (panel wrażliwości lub test refleksyjny, którego OBR-29 nazwa rodzica i który nie ma własnego ORC) jest wysyłane bez zmian, bez ORC lub próbki, a podrzędny bez własnego wyniku raportowanego jest wysyłany z wynikiem rodzica, ponieważ wrażliwość nie ma znaczenia bez kultury, do której należy. Notatka po PID pozostaje z pacjentem, a ORC-14, numer telefonu do kontaktu, jest kopiowany z OBR-17, gdy laboratorium umieściło go tam. Wszystkie 28 przykładowych wiadomości opublikowanych przez ONC dla narzędzia certyfikacji ELR są ważne i nie zawierają błędów.

MSH-2 jest zapisywany jako ^~\&#, pięć znaków wymaganych przez erratę ELR Release 1 i sprawdzanych przez narzędzie certyfikacji ONC. Jeśli przewodnik Twojego stanu pokazuje starsze cztery, dodaj encoding_characters: "^~\\&" do pliku.

Aby wysłać je z kanału zamiast z linii poleceń, podaj miejsce docelowe, które osiąga stan, z blokiem elr nazywającym ten sam plik. Każdy wynik laboratoryjny jest przekształcany podczas wysyłania, a ten, który nie ma nic raportowanego, nie jest wysyłany w ogóle, co jest uznawane za dostarczone, a nie nieudane: stan poprosił o wyniki raportowane tylko.

destinations:
  - name: state-elr
    type: mllp                 # or http, sftp, file: whatever the state's onboarding team gives you
    address: elr.health.state.example:6661
    tls: {enabled: true}
    elr:
      config: elr.yaml         # beside this channel file
      rctc: rctc.json          # optional; the built-in sample is for testing only

Blok ten ma zastosowanie na kanale HL7 v2, do miejsc docelowych, które dostarczają samą wiadomość (mllp, http, tcp, plik, sftp, ftp, S3, Azure Blob, soap, brokerzy wiadomości lub inny kanał); kanał odmawia załadowania w przeciwnym razie, a gdy plik jest nieobecny lub nie zawiera ustawień wysyłającego zakładu, odbierającej aplikacji lub odbierającego zakładu. Notatki są zapisywane w dzienniku z kontrolnym ID wiadomości.

Plik ELR jest towarzyszem kanału, a nie kanałem: perfuse check i ekran kanałów pomijają go, zamiast raportować kanał, który nie może być załadowany. W budowniczym kanału te same dwie ustawienia są pod miejscem docelowym, w Raporcie laboratoryjnym (ELR 2.5.1); pole kodu wyzwalacza otwiera się po nazwaniu pliku ELR, a zapisywanie odmawia pliku, który nie jest obok kanału.

10.8.4 Archiva DICOMweb

type: dicomweb przechowuje każdy obiekt za pomocą STOW-RS: Orthanc, dcm4chee, chmury usług obrazowania lub własne archiwum serwera Perfuse. Podaj korzeń usługi (https://pacs.example/dicom-web); /studies jest dodawany, a adres URL, który już kończy się na /studies, jest odrzucany, zamiast wysyłać do /studies/studies. Uwierzytelnij się za pomocą token (token nośnika) lub username i password; headers dodaje inne, takie jak nagłówek projektu usługi chmury. Kanał wymaga dataType: dicom.

Odpowiedź serwera decyduje o wyniku, a nie sam kod stanu. Obiekt, którego odpowiedź wymienia jako nieudany, jest nieudaną dostawą z powodem niepowodzenia DICOM, a tak samo jest w przypadku 202, który nie wymienia nic jako przechowywane: serwer przyjął żądanie i nie zachował nic z niego. Limit czasu domyślnie wynosi dwie minuty, ponieważ duży zestaw jest powolny.

10.8.5 Repozytoria dokumentów (IHE XDS.b)

type: xds publikuje każdy dokument kliniczny w repozytorium XDS.b za pomocą ITI-41 Provide and Register: dokument CDA lub dokument przenoszony przez wiadomość HL7 v2 (MDM, ORU). Metadane pochodzą z dokumentu i ustawień miejsca docelowego (source_id, patient_domain, facility_type, practice_setting), a odpowiedź repozytorium RegistryResponse decyduje o dostawie. Zobacz dokument udostępniania IHE.

10.8.6 Rejestry szczepień

Każdy rejestr immunizacji w Stanach Zjednoczonych (IIS) akceptuje wiadomości HL7 2.5.1 na tym samym interfejsie SOAP, który CDC opublikował w 2011 roku (przestrzeń nazw urn:cdc:iisb:2011). Ma dwie operacje: connectivityTest, która udowadnia punkt końcowy, i submitSingleMessage, która przenosi wiadomość. VXU^V04 zgłasza zastrzyk i wraca jako ACK; QBP^Q11 prosi o historię i prognozę pacjenta i wraca jako RSP^K11.

Wybierz Rejestr szczepień (usługa internetowa CDC IIS) jako usługę miejsca docelowego SOAP lub napisz profile: cdc-iis:

destinations:
  - name: state-registry
    type: soap
    soap:
      profile: cdc-iis
      url: https://iis.state.example/iis-ws/cdc
      username: clinic-submitter       # the registry account for this submitter
      password: "..."
      facility_id: FAC-1234            # optional in the WSDL; many registries require it
    queue: {enabled: true}

Perfuse tworzy kopertę, więc nie ma ciała do zapisania. Nazwa użytkownika i hasło są umieszczane wewnątrz żądania, gdzie CDC WSDL je umieszcza, a nie w uwierzytelnianiu HTTP. Wersja to SOAP 1.2, powiązanie WSDL, chyba że ustawisz version: "1.1" dla rejestru, którego przewodnik tego wymaga. Gdzie rejestr wymaga certyfikatu klienta, ustaw tls miejsca docelowego, jak dla każdego połączenia HTTPS.

Potwierdzenie rejestru decyduje o tym, czy wiadomość została dostarczona, a nie status HTTP. Rejestr odpowiada odrzuconemu zastrzykowi z kodem HTTP 200 i AR w środku, więc miejsce docelowe, które ufa statusowi, zgłosi utraconą immunizację jako dostarczoną.

warnings_are_errors: true (Traktuj ostrzeżenia jako niepowodzenia) powoduje, że każde AE czeka na osobę. Odpowiedź, którą skrypty odpowiedzi i wywołujący HTTP oczekujący na kanale czytają, jest wiadomością HL7 rejestru: ACK lub RSP z historią i prognozą. examples/iis zawiera trzy kanały do rozpoczęcia: VXU z EHR przez MLLP, zapytania QBP przez HTTP i lokalne miejsce docelowe dla rejestru.

Pulpit Połączenia prosi rejestr o connectivityTest, gdy nic nie zostało wysłane przez siedem dni. Ta operacja istnieje do tego celu i nie wysyła nic, więc jest to jedyne sprawdzenie na poziomie aplikacji, które Perfuse wykonuje. Udowadnia adres, TLS i powiązanie SOAP, a nie nazwę użytkownika i hasło; tylko rzeczywiste wysłanie testuje je.

Źródło SOAP może odpowiedzieć w ten sam sposób: Odpowiedz jako rejestr immunizacji, lub profile: cdc-iis na źródle. Odbija connectivityTest, pobiera wiadomość z submitSingleMessage, zwraca potwierdzenie kanału w return i służy CDC WSDL w ?wsdl. Nazwa użytkownika i hasło, gdy są ustawione, są sprawdzane przeciwko tym w żądaniu, a niepoprawna para otrzymuje SecurityFault WSDL. Wiadomość, którą kanał odrzuca, wraca jako NAK, nigdy jako błąd, jak mówi przewodnik CDC. Użyj go jako podwójnego testu lub aby otrzymać zgłoszenia w sposób, w jaki robi to rejestr.

Niewyjaśnione: stanowe części procesu onboardingu. Każdy rejestr ma swój własny punkt końcowy, proces konta i lokalny profil przewodnika 2.5.1 (wymagane pola RXA i OBX, kwalifikowalność VFC, kody odmowy). Są to treści wiadomości, które kształtują transformacje kanału; nie ma wbudowanego punktu końcowego stanu. Perfuse został przetestowany przeciwko sobie i przeciwko zarejestrowanym odpowiedziom rejestru, a nie przeciwko żywemu rejestrowi stanu.

10.9 Gdy transport mówi tak, a wiadomość nie dotarła

"Czy to dotarło" to często nie jest pytanie, na które transport może odpowiedzieć. Odbiornik MLLP zwraca potwierdzenie aplikacji, którego znaczenie jest w jego tekście. Odbiornik HTTP zwraca 200 z dokumentem błędu. W obu przypadkach transport się powiódł, a wiadomość nie dotarła.

Zbadaj odpowiedź na miejscu przeznaczenia przyjmuje skrypt danej odpowiedzi odbiorcy. Zwróć false lub wyrzuć, a dostawa zostanie oznaczona jako niepowodzenie — co oznacza, że zostanie ponowione, umieszczone w kolejce i pojawi się w liczbie niepowodzeń zamiast być cicho liczone jako dostarczone.

Jest oferowany tylko na miejscach przeznaczenia, które otrzymują odpowiedź. Na tym, które nie mogą, jest odrzucany podczas ładowania, a nie pozostawiony, aby nigdy nie działał.

10.10 Co oznacza wynik dostawy

Są rejestrowane na każdym miejscu przeznaczenia na każdą wiadomość, więc wiadomość, która dotarła do trzech z czterech miejsc przeznaczenia, jest rejestrowana jako dokładnie taka. Nie ma poziomu kanału "powodzenie", ponieważ nie miałoby znaczenia.

10.11 Wolna dostawa

Miejsce przeznaczenia, które akceptuje wiadomości, ale zajmuje dużo czasu, jest odrębnym problemem od tego, które nie powiodło się, i jest łatwo przeoczyć, ponieważ każdy wynik jest powodzeniem.

Istnieje rodzaj alertu slow-delivery dla tego. Warto go ustawić na wszystkim, gdzie potwierdzenie nadawcy czeka na dostawę, ponieważ miejsce przeznaczenia, którego czas odpowiedzi cicho podwoił, w końcu przekroczy limit czasu nadawcy i zacznie produkować ponowne wysyłanie — i w tym momencie objaw pojawia się w górę, w systemie, który możesz nie administrować.

10.12 Pisanie do bazy danych

type: database uruchamia instrukcję na każdą wiadomość z wartościami połączonymi z wiadomości.

Znaczniki są własnymi sterowników — $1 dla postgres, ? dla mysql i sqlite, @p1 dla sqlserver — i Perfuse nie przebudowuje ich. To jest celowe: warstwa tłumacząca, która źle uzna znacznik, związałaby nazwę pacjenta z niewłaściwą kolumną, a wynik wyglądałby jak prawidłowe dane, a nie błąd.

Instrukcja napisana w niewłaściwym dialekcie jest odrzucana, gdy jest zapisywana, nazywając styl, jaki sterownik chce. Przed tym sprawdzeniem błąd pojawił się jako syntax error at or near "," z serwera, gdy przychodziła wiadomość, co nazywa instrukcję, którą napisałeś, i wysyła cię szukać literówki zamiast w dialekcie.

destinations:
  - name: warehouse
    type: database
    database:
      driver: postgres
      dsn: ${WAREHOUSE_DSN}
      statement: INSERT INTO messages (mrn, family_name, birth_date) VALUES ($1, $2, $3)
      params:
        - PID-3.1
        - PID-5.1
        - PID-7

Zacytowany parametr jest stałą, a nie ścieżką, co jest tym, jak kanał zapisuje swoją własną nazwę lub kod systemu źródłowego obok danych wiadomości.

Wartości są zawsze wiązane jako parametry. Odwołanie ${...} w instrukcji jest odrzucane: nazwa zawierająca apostrof złamie instrukcję, a wartość wrogiego wartości ją przebuduje.

10.13 Wysyłanie do surowego gniazda

type: tcp zapisuje do gniazda z wybranym przez Ciebie formatowaniem, co jest tym, czego zwykle oczekuje urządzenie lub instrument laboratoryjny. MLLP jest jednym z kilku formatowań; ten cel oferuje pozostałe.

destinations:
  - name: instrument
    type: tcp
    tcp:
      address: instrument.lab:9100
      framing: delimited
      delimiter: \r
      expect_reply: true
      timeout: 30s

Formatowanie nie ma domyślnej wartości, celowo. Zapisywanie z niewłaściwym formatowaniem nie powoduje błędu. Na drugim końcu odbierane są wiadomości podzielone w niewłaściwych miejscach lub oczekuje się terminatora, który nigdy nie przychodzi, a objaw pojawia się w systemie odbierającym, a nie tutaj.

Akceptowane są tylko ustawienia używane przez wybrane formatowanie. Długość rekordu w strumieniu rozdzielanym jest odrzucana, a nie ignorowana, ponieważ ustawienie, które jest ignorowane w milczeniu, jest ustawieniem, które ktoś uważa za obowiązujące.

expect_reply zmienia to, co jest dostarczane. Bez niego, sukces oznacza, że bajty dotarły do bufora wysyłania systemu operacyjnego — co peer, który awaryjnie zakończył się chwilę później, nigdy nie odczytał.

10.14 Amazon S3, SQS i SNS

Kanał może odczytywać z kolejki SQS lub prefiksu kosza S3, a następnie dostarczać do SQS, SNS lub S3. Wszystkie pięć są podpisywane przez HTTP bez użycia zestawu SDK AWS w binarnym, a wszystkie pięć przyjmują te same ustawienia dostępu: region, access_key_id, secret_access_key (zapisz ${AWS_SECRET_ACCESS_KEY}, aby odczytać środowisko), opcjonalny session_token oraz endpoint dla LocalStack, MinIO lub punktu końcowego VPC. W Kanałach → Nowy kanał wybierz *Odczytujemy z kolejki Amazon SQS*, *Zbieramy obiekty z kosza Amazon S3* lub typy miejsc przeznaczenia SQS, SNS i S3.

Nic nie jest potwierdzone do AWS, dopóki kanał nie obsłuży go. Wiadomość SQS jest kasowana później i w przeciwnym razie pojawia się ponownie, gdy upływa jej limit czasu widoczności, więc polityka ponownego przesyłania kolejki jest tym, co przenosi ją do kolejki martwych list, jeśli nie powiedzie się. Obiekt S3 przechodzi do processed/ później lub do error/, jeśli nie można go obsłużyć, więc jeden zły plik nie zatrzymuje reszty.

W kolejce FIFO lub temacie wiadomości są grupowane według pacjenta domyślnie - SQS zachowuje kolejność wewnątrz grupy i nigdzie indziej - oraz usunięte zduplikowane według treści, więc ponowne próby nie są dostarczane dwa razy.

Archiwum S3 można zapisać bezpośrednio na Glacier z storage_class, oraz jako JSON lines dla Amazon Athena z format: ndjson; perfuse athena drukuje tabelę. Dokumentacja zawiera wszystkie ustawienia.

10.15 AMQP 1.0 i Azure

AMQP 1.0 to co Azure Service Bus i Event Hubs mówią, a RabbitMQ 4, ActiveMQ i Artemis obok innych protokołów. Źródło amqp odbiera z kolejki lub subskrypcji i akceptuje każdą wiadomość tylko wtedy, gdy kanał ją obsłużył; ta, która nie mogła być obsłużona, jest wydana jako nieudana dostawa, więc broker ponownie ją dostarcza i, po przekroczeniu limitu kolejki, umieszcza ją w martwej liście. Miejsce przeznaczenia amqp zgłasza powodzenie tylko wtedy, gdy broker akceptuje wiadomość. Dla Service Bus: addr to <namespace>.servicebus.windows.net:5671 z tls, username to nazwa zasad dostępu współdzielonego, password to jego klucz, a address to nazwa kolejki lub <topic>/subscriptions/<name>, aby otrzymać.

Azure Blob Storage: azure_blob destination zapisuje blob na wiadomość w wybranym poziomie dostępu - Hot, Cool, Cold lub Archive - oraz azure_blob source pobiera blob z prefiksu, przenosząc je do processed/ lub error/ tak jak source S3. Preferowany jest token SAS ograniczony do kontenera zamiast klucza konta.

10.16 MQTT

Źródło mqtt subskrybuje filtr tematu (+ pasuje do jednego poziomu, # do każdego poziomu poniżej) na dowolnym brokerze MQTT 3.1.1: Mosquitto, EMQX, HiveMQ, AWS IoT Core, Azure Event Grid. Przy QoS 1, domyślnie, każda wiadomość jest potwierdzana tylko wtedy, gdy kanał ją obsłużył. MQTT nie ma sposobu, aby odmówić pojedynczej wiadomości, więc ta, która nie mogła być obsłużona, pozostaje niepotwierdzona, a połączenie jest ponownie nawiązane; broker zachowuje sesję pod identyfikatorem klienta (perfuse-<channel>, chyba że client_id mówi inaczej) i wysyła ją ponownie, jako pierwszą w kolejce. QoS 0 jest co najwyżej raz: wszystko, co jest wysyłane, gdy Perfuse jest wyłączony, jest tracone. Miejsce przeznaczenia mqtt publikuje i, przy QoS 1, zgłasza powodzenie, gdy broker otrzyma wiadomość.

source:
  type: mqtt
  mqtt:
    addr: broker.hospital.local:8883
    topic: hl7/+/adt
    username: perfuse
    password: ${MQTT_PASSWORD}
    tls: {enabled: true, ca_file: /etc/perfuse/broker-ca.pem}

AWS IoT Core chce certyfikat klienta: podaj tls.cert_file i tls.key_file.

10.17 IBM MQ

ibm_mq odczytuje i zapisuje kolejki IBM MQ za pomocą interfejsu API REST (mqweb), który IBM MQ 9.1.5 i późniejsze wersje dostarczają na każdej platformie, w tym z/OS, więc nie jest instalowany żaden klient MQ obok Perfuse. Użytkownik potrzebuje roli MQWebUser i uprawnień do umieszczania, pobierania i przeglądania kolejki. Źródło przegląda pierwszą wiadomość, przekazuje ją do kanału i usuwa ją według jej identyfikatora wiadomości tylko wtedy, gdy została obsłużona; wiadomość, która nie powiedzie się, pozostaje pierwsza w kolejce. Uruchom jeden czytnik na kolejkę. Miejsce przeznaczenia umieszcza trwałe wiadomości (chyba że non_persistent), z identyfikatorem kontrolnym HL7 jako identyfikatorem korelacji.

destinations:
  - name: to-mainframe
    type: ibm_mq
    ibm_mq:
      url: https://mq.hospital.local:9443
      queue_manager: QM1
      queue: HL7.ADT.OUT
      username: perfuse
      password: ${IBM_MQ_PASSWORD}
      tls: {enabled: true, ca_file: /etc/perfuse/mq-ca.pem}

api_version to v3 dla MQ 9.3 i późniejszych (domyślnie), v2 dla 9.1.5 do 9.2. Menedżer kolejki z kanałem AMQP może być również osiągnięty za pomocą łącznika amqp.

10.18 Google Cloud Pub/Sub i Cloud Storage

Source pubsub ściąga z subskrypcji i potwierdza każdą wiadomość raz, gdy została obsłużona; ta, która nie powiodła się, jest zwrócona natychmiast (jej termin potwierdzenia jest ustawiony na zero), wraz z resztą partii, więc Pub/Sub dostarcza ją ponownie i, poza zasadą dead-letter subskrypcji, dead-letteruje ją. Destination pubsub publikuje z typem wiadomości HL7 i id kontrolnym jako atrybuty; order_by: patient ustawia klucz porządkujący z PID-3.1, więc subskrypcja z porządkiem wiadomości utrzymuje wiadomości każdego pacjenta w porządku.

Destination gcs zapisuje obiekt na wiadomość, nazwany jak klucz S3, w wybranej klasie magazynowania (STANDARD, NEARLINE, COLDLINE, ARCHIVE). Source gcs pobiera obiekty z prefiksu i przenosi je do processed/ lub error/ tak jak source S3.

Oba logują się jako konto usługi: credentials_file to jego klucz JSON. Pozostaw go pusty na Google Cloud (maszyna wirtualna, GKE lub Cloud Run), aby użyć konta usługi dołączonego tam. endpoint określa emulator (emulator Pub/Sub, fake-gcs-server), który nie wymaga poświadczeń.

source:
  type: pubsub
  pubsub:
    project: hospital-integration
    subscription: adt-to-perfuse
    credentials_file: /etc/perfuse/gcp-key.json

10.19 Odczytywanie skrzynki pocztowej (IMAP i POP3)

Source email odczytuje skrzynkę pocztową i przekształca to, co znajduje, w wiadomości: każde załączniki (take: attachments, domyślnie, wąskie za pomocą wzorców attachment_names), tekst emaila (take: body) lub cały email (take: raw) dla skryptu do rozmontowania. Laboratoria, centra obrazowania i małe praktyki nadal wysyłają wyniki w ten sposób.

Każda kontrola loguje się, odczytuje najstarszą nieprzeczytaną pocztę i wylogowuje się. Przez IMAP poczta jest pobierana bez oznaczenia jej jako przeczytanej, przekazywana do kanału i tylko wtedy, gdy każda wiadomość z niej została zaakceptowana, jest przenoszona do move_to (Przetworzona), oznaczona jako przeczytana (after_read: flag) lub usunięta. Poczta, która nie powiodła się lub która nie została pobrana (nadawca spoza allowed_senders, brak załącznika pasującego do attachment_names, większa niż max_message_size), przechodzi do error_folder (Błąd) z powodem w logu. Obie foldery są tworzone, gdy są nieobecne. POP3 nie ma folderów ani flag, więc kasuje: kasowania są zatwierdzane przez QUIT na końcu kontroli, więc sesja, która się rozłącza, nie kasuje niczego i przetworzona poczta może być odczytana ponownie (nigdy nie tracona). Poczta POP3, która nie jest pobrana, pozostaje na serwerze i jest zgłaszana raz.

Logowanie jest hasłem (${MAIL_PASSWORD}; hasło aplikacji dla Gmail) lub OAuth 2.0 za pomocą SASL XOAUTH2, które Microsoft 365 wymaga (już wyłączyło logowanie hasłem) i Gmail preferuje:

source:
  type: email
  email:
    host: outlook.office365.com        # imap.gmail.com, pop.gmail.com, or your server
    username: results-feed@hospital.example
    oauth:
      provider: microsoft              # microsoft, google or custom (with token_url)
      tenant: hospital.onmicrosoft.com
      client_id: 00000000-0000-0000-0000-000000000000
      client_secret: ${MAIL_CLIENT_SECRET}
    attachment_names: ["*.hl7"]
    allowed_senders: [lab.example, results@partner.example]

Z client_secret i bez refresh_token używany jest dostęp app-only do Microsoft 365 (grant client-credentials, zakres https://outlook.office365.com/.default): administrator rejestruje aplikację, przyznaje jej IMAP.AccessAsApp i ogranicza ją do jednej skrzynki pocztowej za pomocą głównego serwisu Exchange. Z refresh_token (zgoda osoby) używany jest delegowany zakres IMAP.AccessAsUser.All lub POP.AccessAsUser.All, a obrócony token odświeżania jest przechowywany przez cały okres istnienia procesu. Gmail potrzebuje refresh_token: Google nie oferuje dostępu app-only do skrzynki pocztowej.

allowed_senders przyjmuje adresy i domeny. Linia From w emailu może być sfałszowana, więc zatrzymuje przypadkową i zbędną pocztę, nie atakując; karmienie, które musi być zaufane, należy umieścić w Direct (S/MIME podpisane), SFTP lub VPN. security to tls (993 lub 995, domyślnie), starttls (143 lub 110) lub none, które jest dozwolone tylko do localhost. Kontrole są oddalone o co najmniej 10 sekund (60 domyślnie), ponieważ usługi pocztowe ograniczają konta, które sprawdzają częściej.

Przetestowany przeciwko GreenMail 2.1.3 (IMAPS, IMAP, POP3S i POP3: odmowa logowania z błędnym hasłem, pobieranie bez oznaczenia jako przeczytanej, MOVE, flaga, usunięcie, odmowa zbyt dużej poczty przed jej odczytaniem) i przeciwko IMAP Gmail z hasłem aplikacji (utwórz folder, dołącz, pobierz, MOVE, usunięcie). OAuth został przetestowany przeciwko punktowi końcowemu tokena tylko: nie przeciwko Microsoft ani Google.

10.20 AS2

AS2 (RFC 4130) to jest sposób, w jaki wiele płatników, instytucji rozliczeniowych i dostawców wymieniają dane EDI: żądanie HTTP POST, którego treść jest podpisywana certyfikatem nadawcy i szyfrowana dla odbiorcy, a w odpowiedzi otrzymuje się potwierdzenie (MDN) zawierające skrót tego, co dotarło. S/MIME jest tym samym kodem, który wykorzystuje bezpośrednia wiadomość. Obydwie strony znajdują się w konstruktorze kanału: Partnerzy handlowi wysyłają nam EDI za pośrednictwem AS2 jako źródło, Partner handlowy za pośrednictwem AS2 jako miejsce docelowe.

# receive: partners post here
source:
  type: as2
  as2:
    listen: ":4080"            # path /as2 by default
    id: HOSPITAL-AS2           # our AS2 identifier (AS2-To)
    cert_file: as2/ours.crt    # partners encrypt to this
    key_file: as2/ours.key     # and receipts are signed with it
    tls: { enabled: true, cert_file: tls.crt, key_file: tls.key }
    partners:
      - id: PAYER-AS2
        cert_file: as2/payer.crt
dataType: x12

# send
destinations:
  - name: payer
    type: as2
    as2:
      url: https://as2.payer.example/as2
      from: HOSPITAL-AS2
      to: PAYER-AS2
      cert_file: as2/ours.crt
      key_file: as2/ours.key
      partner_cert_file: as2/payer.crt
      file_name: "${control_id}.x12"

Odbieranie. Wiadomość do dowolnego innego AS2-To lub od nadawcy niebędącego w partners jest odrzucana z kodem 403 i bez potwierdzenia. Wiadomość partnera musi być podpisana i zaszyfrowana, chyba że jego wpis ustawia allow_unsigned lub allow_unencrypted. Ładunek jest odszyfrowywany, sprawdzana jest jego sygnatura w stosunku do certyfikatu partnera (partnerzy zwykle wymieniają się certyfikatami wygenerowanymi samodzielnie, co jest w porządku: certyfikat jest zaufaniem), a następnie przekazywany do kanału zgodnie z jego formatem wiadomości. Partner otrzymuje potwierdzenie, o które poprosił: w odpowiedzi lub opublikowane na adresie URL Receipt-Delivery-Option; podpisane, gdy poprosił o podpisane. Wiadomość, która nie powiedzie się, otrzymuje potwierdzenie z podaniem powodu (decryption-failed, authentication-failed, insufficient-message-security, unexpected-processing-error).

Wysyłanie. Każda wiadomość jest podpisywana (SHA-256) i zaszyfrowana (AES-256-CBC). Z receipt: sync, domyślnie, jest uważana za dostarczoną tylko wtedy, gdy potwierdzenie jest weryfikowane w stosunku do partner_cert_file, mówi processed i zawiera ten sam skrót (MIC) co to, co zostało wysłane; wszystko inne jest nieudaną dostawą i jest powtarzane. receipt: async prosi o potwierdzenie na receipt_url, które musi być źródłem AS2 na tym serwerze, który wymienia partnera: wiadomość jest uważana za dostarczoną, gdy partner zaakceptuje żądanie, a potwierdzenie, które później się nie zgadza, jest rejestrowane jako błąd. receipt: none prosi o nic. unsigned, unencrypted i unsigned_receipt łagodzą każdą część dla umowy, która tak mówi; username i password dodają uwierzytelnianie podstawowe HTTP dla bram, które je wymagają. Typ zawartości jest taki sam jak format kanału (application/edi-x12 dla X12), chyba że content_type ustawia inny.

Triple DES, AES-128 i AES-192 są odczytywane tak samo jak AES-256, ponieważ partnerzy nadal je wysyłają, a także jest odczytywany strumieniowy BER (nieokreślone długości) napisany przez bramki Java.

Kompresja (RFC 5402). Zaszyfrowana wiadomość jest odczytywana w dowolny sposób, w jaki została zbudowana: skompresowana przed podpisaniem lub szyfrowaniem, lub cała podpisywana wiadomość jest skompresowana. Skrót potwierdzenia (MIC) jest zgodny z RFC: nad tym, co zostało podpisane, gdy jest podpisane, nad zawartością nieskompresowaną, gdy nie jest podpisane. Wiadomość, która rozwinie się ponad dziesięć razy większą niż max_message_size źródła, jest odrzucana z decompression-failed, aby kilka kilobajtów nie mogło zażądać gigabajtów pamięci. Miejsce docelowe kompresuje z compress: true, przed podpisaniem i szyfrowaniem, jak to robią większość bramek; najpierw pytaj partnera.

Wiadomość wysłana dwukrotnie. Partner, który nigdy nie otrzymał naszego potwierdzenia, wysyła wiadomość ponownie z tym samym Message-ID (RFC 4130 sekcja 7.5). Źródło pamięta każde Message-ID partnera dla duplicate_window (domyślnie 720h, 30 dni; co najmniej godzina) i odpowiada na ponowne wysłanie potwierdzeniem processed bez ponownego przekazywania go. Zapis jest przechowywany w bazie danych, aby restart nie zapomniał go. Wiadomość, której przetwarzanie nie powiodło się, nie jest pamiętana, więc powtórne wysłanie partnera jest przetwarzane. Kopie, które przychodzą w tym samym momencie, czekają na siebie nawzajem, a tylko pierwsza jest przekazywana dalej. Jeśli zapis nie może być odczytany, wiadomość jest odrzucana z unexpected-processing-error i partner powtarza ją później, zamiast ryzykować drugą kopię. Wiadomość bez Message-ID nie może być rozpoznana i jest rejestrowana jako taka.

Interoperacyjność jest testowana z pyas2lib 1.4.3 w obu kierunkach, z Triple DES i AES-256, skompresowanymi i nie, z synchronicznymi potwierdzeniami podpisami włącznie.

10.21 OpenPGP

Płatnicy, instytucje rozliczeniowe i agencje państwowe często przyjmują i wysyłają pliki tylko za pomocą OpenPGP. Blok pgp w źródle otwiera to, co przychodzi; jeden w miejscu docelowym chroni to, co wychodzi. Obydwa są w konstruktorze kanału: Wiadomości zaszyfrowane Open PGP pod źródłem, Zaszyfruj za pomocą OpenPGP na każdym miejscu docelowym.

source:
  type: sftp
  sftp: { host: sftp.payer.example, user: hospital, key_file: keys/id_ed25519, dir: outbound }
  pgp:
    decrypt_with: keys/our-secret.asc      # our secret key, armored or binary
    passphrase: ${PGP_PASSPHRASE}
    verify_with: [keys/payer.asc]          # the senders' public keys
    require_signature: true
destinations:
  - name: claims
    type: sftp
    sftp: { host: sftp.payer.example, user: hospital, key_file: keys/id_ed25519, dir: inbound,
            file_name: "${date}-${control_id}.x12.pgp" }
    pgp:
      encrypt_to: [keys/payer.asc]
      sign_with: keys/our-secret.asc
      passphrase: ${PGP_PASSPHRASE}

Pliki z kluczami są odczytywane względem pliku kanału i są odczytywane i odblokowane, gdy kanał jest ładowany: brakujący klucz lub błędne hasło zatrzymuje kanał tam, a nie na pierwszym pliku.

• W źródle, cały plik, obiekt, załącznik poczty elektronicznej lub treść żądania jest otwierana najpierw, a następnie dzielona na wiadomości, więc partia zaszyfrowana jako jeden plik działa. Ta, która nie może być otwarta, jest odrzucana: źródło pliku przenosi je do folderu błędów, nadawca HTTP jest odpowiedzią 400 z powodem. require_signature odrzuca wiadomość, która nie jest podpisana przez jeden z verify_with; allow_unencrypted akceptuje tę, która jest tylko podpisana; pass_plain pozwala wiadomości, która nie jest w ogóle PGP, na przejście niezmienionej, dla folderu, który otrzymuje oba.
• W miejscu docelowym, to, co miało być dostarczone, jest szyfrowane (do któregokolwiek z encrypt_to) i podpisane (z sign_with), po każdym innym kroku. Plik, SFTP, FTP, S3, Azure Blob lub GCS miejsce docelowe nadal nazywa plik z wiadomością niezaszyfrowaną, aby ${control_id} działał, a każde ramowanie jest wewnątrz szyfrowania. armor: true zapisuje tekst .asc zamiast binarnego; no_compress wyłącza kompresję; file_name to nazwa przenoszona wewnątrz wiadomości.

Wiadomości są zapisywane z AES-256 w formacie RFC 4880 starszych odbiorców i nowszy format RFC 9580 jest odczytywany. Kryptografia to ProtonMail/go-crypto; Perfuse nie implementuje żadnej prymitywnej. Interoperacyjność jest testowana z GnuPG w obu kierunkach: gpg odszyfrowuje i weryfikuje to, co Perfuse zapisuje, a Perfuse otwiera i weryfikuje to, co gpg zapisuje.

10.22 Dostarczanie do innego kanału

Miejsce docelowe kanału przekazuje wiadomość do innego kanału według nazwy. Kanał odbierający traktuje ją jak każde inne przybycie: zapisuje ją, filtruje, przekształca i rozdziela.

To jest obsługiwany sposób budowania łańcucha. Jest to celowo widoczne — dwa kanały, dwa zestawy statystyk, dwa wpisy w historii wiadomości — ponieważ ukryty łańcuch wewnątrz jednego kanału to łańcuch, którego nikt nie może monitorować.

Wiadomość jest przekazywana w pamięci zamiast przez sieć, więc nie ma ramki, potwierdzenia ani limitu czasu między dwoma.

10.23 Co się dzieje, gdy proces jest zabity

Pierwsze pytanie, które zadaje każdy, kto uruchomił silnik interfejsu, i to, na które rzadko otrzymuje się odpowiedź, ponieważ uczciwa odpowiedź jest zwykle zawstydzająca.

Zostało ono udzielone przez zabicie procesu za pomocą SIGKILL w trakcie partii — co wygląda jak awaria zasilania, zabójstwo z powodu braku pamięci i reset hypervisora — i zliczono, co przetrwało w porównaniu z tym, co zostało obiecane.

Właściwość poddawana testowi nie jest „nic nie zostaje utracone”. Nie jest to osiągalne i twierdzenie, że tak jest, byłoby kłamstwem. Jest to węższa obietnica, na którą naprawdę liczy nadawca: wiadomość, która została potwierdzona pozytywnie, jest wiadomością, która dotarła.

Z ack.when: on_delivery, które jest domyślne, każde miejsce docelowe jest zapisywane przed wysłaniem potwierdzenia, więc AA jest oświadczeniem dotyczącym miejsca docelowego, a nie kolejki. Wiadomość zabita przed jej potwierdzeniem może zostać utracona, i jest to poprawne: nadawca nie został obiecany nic i wyśle ją ponownie.

10.23.1 Potwierdzanie przy dostarczeniu

Pięć przebiegów, zakończonych po 5, 25, 40, 75 i 110 wiadomościach z 120.

Obietnica dotrzymana na każdym punkcie zabójstwa, i nic nie zostało zdublowane. Dublowanie byłoby akceptowalne, a utrata nie: ponownie wysłany A08 to niedogodność, którą odbiorcy absorbują, a wynik laboratoryjny, który milcząco nigdy nie dotarł, jest zdarzeniem zagrażającym bezpieczeństwu pacjenta.

10.23.2 Potwierdzanie przy odbiorze

on_receipt odpowiada tak szybko, jak tylko wiadomość jest umieszczona w kolejce, zanim jakiekolwiek miejsce docelowe zostanie zapisane. Rozdział ten zawsze mówił, że potwierdzona wiadomość może nadal zostać utracona w ten sposób. Oto rozmiar tego.

Podstawowo wszystko, co jest w locie. Ustawienie nie jest wadą, i istnieją kanały, w których jest to właściwy wybór, ale powinno być wybrane ze świadomością, że awaria odrzuca to, co zostało potwierdzone i nie zostało jeszcze zapisane, i że jest to prawie cały wybuch.

Nic nie odzyskano po ponownym uruchomieniu, ponieważ perfuse run nie ma trwałego magazynu. Miejsce docelowe, które nie może stracić wiadomości podczas awarii, wymaga queue.enabled, które wymaga bazy danych dostarczanej przez perfuse serve — i perfuse run teraz odmawia takiego kanału, zamiast rozpocząć go bez kolejki.

10.23.3 Nadawca, który umiera w połowie wiadomości

Najniebezpieczniejszy z tych błędów, ponieważ przycięte wiadomości HL7 zwykle nadal są analizowane. Segregmenty przed przycięciem są kompletne i dobrze sformułowane, więc odbiorca nie ma możliwości wiedzy, że PID i PV1 dotarły, a segmenty OBX zawierające wyniki nie dotarły.

Ramka została otwarta, sześć dziesiątych wiadomości wysłano, a połączenie zostało zresetowane zamiast zamknięte. Częściowa wiadomość nie została dostarczona, nasłuchiwacz przetrwał, a dobrze sformatowana wiadomość wysłana natychmiast po niej została zaakceptowana normalnie, więc fragment nie został przeniesiony do następnej wiadomości.

Log połączenia raportuje teraz, ile bajtów niekompletnej ramki zostało porzuconych, dla każdego trybu awarii, a nie tylko dla czystego zamknięcia. Wcześniej awaryjny nadawca, zabity proces i wyciągnięty kabel wszystkie rejestrowały messages=0 i nic więcej, co nie może odróżnić pustej kontroli zdrowia od wyniku laboratoryjnego wyrzuconego dziewięć dziesiątych drogi.

10.23.4 Pełny dysk

Wykrywany jest wyczerpanie miejsca i rejestrowany, a nie połykany. Dwie rzeczy o tym są warte poznania.

Nadawca nie otrzymuje natychmiastowej odrzucenia. Dostarczanie jest powtarzane zgodnie z normalnym harmonogramem — jeden sekund, dwa, cztery, osiem — a negatywne potwierdzenie przychodzi około piętnaście sekund później. Nadawca, którego własne limit czasu jest krótsze niż to, widzi zablokowane połączenie, a nie AE, i stwierdzi, że sieć jest winna, a nie dysk.

A także wolumin zgłaszający zero wolnych bajtów może nadal akceptować małe operacje dołączania przez jakiś czas, because dodanie kilkuset bajtów do pliku, którego ostatni blok ma miejsce, nie wymaga nowej alokacji. Pierwszy błąd zapisu występuje później niż moment, w którym dysk został wypełniony.

10.23.5 Co nie zostało przetestowane

Miejsce docelowe katalogu traci uprawnienie do zapisu. Nie mogło być wstrzyknięte za pomocą chmod: silnik trzyma plik wyjściowy otwarty, a zmiana trybu pliku nie wpływa na opisany wcześniej plik. Prawidłowe przetestowanie wymaga ponownego zamontowania wolumenu w trybie tylko do odczytu lub usunięcia go spod procesu, co nie zostało zrobione. Jest tutaj nazwane, a nie pominięte, ponieważ luka, o której nikt nie wspomina, brzmi jak luka, której nikt nie szukał.

11 Alarmowanie

Nic poza Perfuse nie powie ci, że kanał przestał działać. Nadawca jest potwierdzany i jest zadowolony; odbiorca nie ma sposobu, aby wiedzieć, że wiadomość została wysłana. Alarmowanie jest jedyną rzeczą, która stoi między złamanym interfejsem a kimś, kto zauważy to tygodnie później.

11.1 Rodzaje alarmów

Ostatnie cztery monitorują dostęp do danych pacjentów i są opisane poniżej.

11.2 Milczenie jest najtrudniejszą rzeczą do wykrycia

Kanał, który przestał otrzymywać dane, nie generuje błędów. Nie ma nic do policzenia. Dlatego też istnieje no-traffic i dlatego nie jest wystarczający sam w sobie.

no-traffic jest stałym progiem: alarmuj, jeśli nic nie przychodzi przez, powiedzmy, dwie godziny. W przypadku kanału, który nigdy nie milknie, działa to. W przypadku kanału laboratoryjnego kliniki jest to bezużyteczne — kanał jest cichy każdej nocy i przez cały weekend, więc próg dwugodzinny powoduje alarm o 1 nad ranem każdej nocy, a próg wystarczająco długi, aby przetrwać weekend, nie zauważy awarii we wtorek rano do wtorkowego popołudnia.

Nie ma jednej liczby, która spełnia oba warunki. To nie jest problem dostrojenia; to jest to, że pytanie „czy ten kanał przestał działać” nie może być odpowiedzią przez stałą, gdy normalne zachowanie kanału zmienia się o czynnik sto w ciągu tygodnia.

11.3 Wykrywanie rytmu

below-rhythm porównuje bieżący ruch z tym, co normalnie robi ten kanał w tej godzinie tego dnia tygodnia.

Perfuse uczy się każdego kanału z własnej zapisanej historii: 168 godzinnych wiadomości, od poniedziałku, tak aby tydzień roboczy był ciągły. Dla każdej wiadomości przechowuje medianę, niski i wysoki poziom, podłogę i liczbę obserwacji, na których się opiera.

Próg jest udziałem normalnym, domyślnie 0.8 (80 procent w konsoli) — alert, gdy ruch spada poniżej czterech piątych tego, co jest normalne dla tej godziny.

11.3.1 Mediana, a nie średnia

Jednorazowy wypływ 40 000 wiadomości przeciwko normalnym 300 przenosi średnią wystarczająco daleko, aby kanał mógł całkowicie umilknąć bez spadku poniżej niej. Mediana nie jest poruszona przez jedną niezwykłą godzinę, co jest właśnie potrzebne.

11.3.2 Podłoga jest percentylem, a nie minimum

Czy rytm kanału jest wystarczająco niezawodny, aby alarmować, decyduje o tym jego dolny koniec, a nie górny. Alarm braku wystrzeliwuje, gdy ruch jest *niski*, więc tylko dolny koniec może powiedzieć, czy wyprodukuje fałszywe pozytywy. Wczesna wersja tego porównywała górny koniec z medianą i myliła się w obie strony jednocześnie: zdyskwalifikowała idealnie stabilny kanał na miesiąc po jednym wypłynięciu i przeszła przez kanał, który naprawdę miał wahania między dwiema a dziewięcioma setkami wiadomości w tej samej godzinie, ponieważ jego górny koniec był tylko trzykrotnie wyższy od mediany.

Podłoga jest dwudziestym percentylem, a nie minimum, ponieważ minimum jest ciągnięte do zera przez jedną święto. I percentyl nie jest interpolowany — każda liczba w alarmie o 2 nad ranem powinna być liczbą, którą kanał rzeczywiście wyprodukował, a nie średnią z dwóch liczb, których nie wyprodukował.

11.3.3 Powie, gdy nie może powiedzieć

Kanał bez historii w ogóle jest pomijany, zamiast traktowany jako kanał, który przestał działać. Nowy kanał nie powinien wyglądać jak uszkodzony.

Gdzie historia jest zbyt cienka lub zbyt kapryśna, aby wspierać osąd, reguła odmawia wystrzału, zamiast zgadywać. „Nie mogę szczerze powiedzieć” to pierwszorzędna odpowiedź tutaj i jest preferowana zamiast alarmu, który jest prawidłowy nieco częściej niż przypadkowo.

Godziny nieobecne w oknie uczenia są rejestrowane jako prawdziwe zera, a nie jako brakujące dane. Połowa sygnału w kanale kliniki to *kiedy jest on słusznie cichy*, i traktowanie tych godzin jako nieznanych wyrzuciłoby to.

11.4 Ustawianie alarmów

Z interfejsu, pod Alertami, na kanał lub we wszystkich. Każda reguła ma rodzaj, próg i miejsce, w którym wysyłać alert. Reguły są zapisywane w alerts.yaml obok bazy danych (lub pliku -alerts nazwanym) i obowiązują natychmiast; do pierwszego zapisu mają zastosowanie reguły wbudowane. Plik można również edytować ręcznie: zmiana jest pobierana w ciągu trzydziestu sekund, a plik, który nie może być już wczytany, jest zgłaszany w logu, a reguły w mocy są utrzymywane.

Warto to zrobić przed uruchomieniem kanału, a nie po pierwszym incydencie. Konkretne zestawy, które warto mieć na każdym kanale klinicznym:

1. below-rhythm — kanał umilkł, gdy nie powinien być cichy.
2. error-rate — wiadomości przychodzą i nie powiodło się.
3. queue-age — coś jest zakleszczone, a nie po prostu zajęte.
4. channel-down — kanał nie działa w ogóle.

Pierwszy to ten, który złapie awarię, której nikt inny nie zgłosi.

11.5 Monitorowanie dostępu do danych pacjentów

Naruszenie zwykle nie ogłasza się. Wygląda to jak kanał przenoszący więcej niż zwykle, ruch o trzeciej w nocy na kanale, który działa tylko w godzinach biurowych, nowy adresat, lub jeden osoba otwierająca pacjenta po pacjencie. Perfuse monitoruje te cztery, włączone domyślnie (serve -watch-access=false wyłącza je), i zgłasza to, co widzi za pomocą reguł alertów powyżej, więc jest ono konfigurowane, potwierdzone i dostarczane jak każdy inny alert.

• Wysyp (phi-volume). Każdy kanał jest porównywany ze swoją własną historią o tej samej godzinie dnia, więc zajęta poranka nie jest nowością. Próg jest wielokrotnością zwykłej stawki, trzy domyślnie. Wysyp zwykle jest zaległością, która jest uwalniana po awarii, i jest to również to, jak wyglądają rekordy, które są wyodrębniane za pomocą kanału.
• Ruch nocny na kanale dziennym (phi-after-hours). Kanał jest uważany za dzienny, gdy mniej niż 2 procent tego, co przeniósł, wypadło poza godziny 07:00-19:00, w strefie czasowej serwera.
• Nowy adresat (phi-new-destination). Adres jest tym, co nazwano miejscem docelowym: host i port, URL, folder. Przemianowanie miejsca docelowego nie jest nowością; wskazywanie go na nowy host jest. Adresy, do których każdy kanał wysyłał, są przechowywane w access-watch.json obok bazy danych, więc zmiana miejsca docelowego podczas gdy serwer był wyłączony jest nadal zgłaszana.
• Odczyty wsadowe (phi-bulk-reads). Liczone z śladu audytu: wiadomości otwarte, pacjenci wyszukani lub wyszukani (PDQm, PIXm, wyszukiwanie tożsamości), dokumenty i obrazy odczytane (XDS, MHD, DICOMweb), uprzednie autoryzacje odczytane, podsumowania i widoki uruchomione. Odczytanie tego samego rekordu ponownie nie jest liczone dwukrotnie. Próg jest to, ile różnych rekordów w ciągu minuty, dziesięć domyślnie, przez jednego konta z jednego adresu.

Nic nie jest oceniane dla kanału, dopóki nie przeszedł 200 wiadomości, ponieważ "niezwykłe" nie oznacza nic bez wzorca. Wzorzec jest uczony z ostatnich dwóch tygodni magazynu wiadomości, gdy serwer się uruchamia, więc ponowne uruchomienie nie sprawia, że każdy kanał staje się nowy. Wszystko, co jest widoczne, jest przechowywane przez piętnaście minut, a następnie alert samoczynnie się czyści.

Tylko obserwuje i raportuje. Nigdy nie zatrzymuje wiadomości ani nie odmawia odczytu: są to heurystyki, a kanał zatrzymany z powodu błędnej oceny jest problemem klinicznym. Każdy alert mówi, co zostało zobaczone i co może być niewinne, ponieważ większość z nich będzie niewinna.

Administratorzy widzą, co monitor nauczył się na ekranie Alertów, pod Obserwacja dostępu do danych pacjentów: wzorzec każdego kanału (nadal uczony, tylko w dzień lub w dzień i w nocy), ile miejsc docelowych on zna, i wszystko, co zostało zobaczone w ciągu ostatnich piętnastu minut, w tym to, co jest poniżej progu reguły.

11.6 Gdzie idą alarmy

Alerty mogą być wysyłane jako JSON do webhook (-alert-webhook: Slack, Teams, Mattermost, PagerDuty, Alertmanager lub wszystko, co akceptuje POST), wysyłane jako pułapki SNMPv2 do menedżerów SNMP (-snmp-traps, zobacz SNMP), lub zapisywane do logu dla kolektora. Nie ma własnej dostawy poczty elektronicznej: skieruj webhook do przekaziciela, jeśli alerty muszą przyjść jako e-mail.

Alarm, który jest tylko zapisany w logu, który nikt nie czyta, nie jest alarmem. Jeśli Perfuse jest jedyną rzeczą, która zauważy zatrzymany kanał, alarm musi dotrzeć do osoby.

12 Magazyn wiadomości

Każda wiadomość otrzymana przez Perfuse jest rejestrowana, w postaci oryginalnej, zanim zostanie zmodyfikowana. Zostaje również zapisane, co zostało wysłane do każdego miejsca przeznaczenia i co się z tym stało. Magazyn jest plikiem SQLite określonym przez -db.

12.1 Co jest przechowywane

Dla każdej wiadomości: surowe bajty, jak przybyły, kiedy przybyły, jaki kanał, sparsowany typ wiadomości i zdarzenie wyzwalające, oraz wynik filtrowania.

Dla każdego miejsca przeznaczenia dla każdej wiadomości: bajty, które zostały wysłane, wynik, czas potrzebny do wykonania, oraz ewentualne błędy lub negatywne potwierdzenia otrzymane.

To jest kształt, jaki wymaga śledztwo. „Co oni do nas wysłali”, „co my im wysłaliśmy” i „co oni powiedzieli o tym” to trzy różne pytania i każde z nich jest zadawane.

12.2 Wyszukiwanie

Przez kanał, przez zakres czasu, przez wynik, przez typ wiadomości i zdarzenie wyzwalające, oraz przez wartość pola.

Wyszukiwanie pól działa na sparsowanej wiadomości, więc wyszukiwanie numeru rekordu znajduje go wszędzie tam, gdzie to pole istnieje w wiadomości, zamiast dopasowywać cyfry gdziekolwiek w tekście. Wyszukiwanie tekstowe 12345 w wiadomości zawierającej ilość 12345 znajduje wiadomość, która nie ma nic wspólnego z pacjentem, którego szukamy.

12.3 Ponowne odtwarzanie i ponowne przetwarzanie

Ponieważ oryginał jest zachowany, wiadomość może być ponownie przetworzona z bieżącą konfiguracją.

Ślad pobiera zarejestrowaną wiadomość i pokazuje, co kanał zrobiłby z nią teraz, bez wysyłania niczego. Opisano w debugowaniu.

Ponowne przetworzenie naprawdę ponownie uruchamia ją, w tym dostarczanie. To jest to, co naprawia partię wiadomości, które nie powiodły się, ponieważ miejsce przeznaczenia było nieprawidłowo skonfigurowane: popraw konfigurację, wybierz dotknięte wiadomości, ponownie przetwórz.

12.4 Przestarzałość

Ślad starej wiadomości względem bieżącej konfiguracji odpowiada na hipotetyczne: co by się *stało* teraz. To jest zwykle to, czego chcesz, ale nie zawsze — jeśli badasz, co poszło nie tak w zeszłym tygodniu, kanał może ulec zmianie od tego czasu.

Perfuse wykrywa to i mówi o tym. Ślad wiadomości, która przybyła przed ostatnim edytowaniem kanału, jest oznaczony jako taki, aby odpowiedź nie była mylona z odtworzeniem tego, co naprawdę się stało.

12.5 Przechowywanie

Magazyn rośnie. cleanup.periodDays kontroluje, jak długo wiadomości są przechowywane.

Dwie rzeczy do rozważenia. Wiadomości kliniczne mogą podlegać wymogom przechowywania, które są dłuższe niż cokolwiek, co byś wybrał z powodów operacyjnych, a magazyn nie jest systemem ewidencji — system odbiorczy jest. Kopia Perfuse istnieje w celu diagnozowania i ponownego przetwarzania, a oba te potrzeby maleją gwałtownie po kilku tygodniach.

Okres przechowywania również decyduje o tym, ile danych historia ma do dyspozycji learner rytmu. Zobacz alerting: krótszy okres przechowywania niż kilka tygodni powoduje, że nie jest w stanie odróżnić cichej niedzieli od zatrzymanego źródła.

12.6 Magazyn zawiera dane kliniczne

Jest to część Perfuse, która zawiera informacje o pacjentach i powinna być traktowana jako taka: przechowywana na zaszyfrowanym nośniku, zabezpieczona jako dane kliniczne i kontrolowana pod względem dostępu. Zobacz bezpieczeństwo.

Wygenerowane wiadomości testowe opisane w testowaniu istnieją częściowo po to, aby te dane nie musiały opuścić środowiska, aby odtworzyć problem w innym miejscu.

13 Debugowanie

Pytanie jest prawie zawsze takie same: ta wiadomość przychodzi, coś poszło nie tak, gdzie się zmieniła? Perfuse odpowiada na nie, odtwarzając nagraną wiadomość za pomocą bieżącej konfiguracji i pokazując każdy krok.

Nic nie jest wysyłane podczas śledzenia. Kanał działa niezakłócony, a nie jest wymagane ponowne wdrożenie.

13.1 Śledzenie wiadomości

Wybierz dowolną nagraną wiadomość i śledź ją. Wynik pokazuje, w kolejności:

• Co filtr przeczytał. Które pola sprawdził i jakie wartości znalazł. Filtrowanie odrzucające wszystko zwykle czyta ścieżkę, która nie istnieje w tym kanale, i ta nazwa jest podana.
• Każdą transformację. Co zmieniło, z czego na co.
• Co każde miejsce przeznaczenia zdecydowało. Czy zaakceptowałoby wiadomość i dlaczego nie, jeśli nie zaakceptowałoby.
• Wynik. Wiadomość, tak jak każde miejsce przeznaczenia ją wysyłałoby.

13.2 Krok po kroku

Widok krokowy uruchamia każdą transformację oddzielnie i robie zdjęcie całej wiadomości po każdej z nich. Ponumerowana belka kroków, pokolorowana według tego, co się stało, i wiadomość, jaka była w każdym punkcie.

Cała wiadomość, a nie tylko zmiana, ponieważ zmiana często nie jest tam, gdzie jest problem — krok, który poprawnie zmodyfikował pole, na wiadomości, na której wcześniejszy krok już wcześniej wstawił coś nie takiego, wygląda idealnie poprawnie w izolacji.

13.3 Cztery rezultaty i różnica, która ma znaczenie

no-effect i skipped są raportowane oddzielnie, a to jest punkt całej funkcji.

Z zewnątrz są identyczne: wiadomość jest taka sama po obu. Oznaczają przeciwne rzeczy. skipped oznacza, że warunek działał zgodnie z tym, co zostało napisane, a ta wiadomość nie była jedną, do której się stosował — zwykle poprawnie. no-effect oznacza, że krok został uruchomiony i nie znalazł nic do zrobienia, co zwykle oznacza, że jest skierowany do pola, które nie istnieje.

Silnik, który raportuje oba jako "nic się nie stało" pozostawia cię niezdolnym do rozróżnienia działającego warunku od złamanego ścieżki, a to jest najczęstszy błąd transformacji.

13.4 Testowanie zmiany przed jej zapisaniem

Budowniczy może uruchomić kandydującą konfigurację na nagranych danych ruchu i raportować, co byłoby inne. To jest najbezpieczniejszy sposób, aby zmienić żywy kanał: zrób edycję, zobacz, co robi ostatnim kilkuset prawdziwym wiadomościom, a następnie zapisz.

To jest również sposób, aby dowiedzieć się, że zmiana, która wygląda oczywiście poprawnie, wpływa na wiadomości, o których nie myślałeś — krok warunkowy na jednym zdarzeniu wyzwalającym, na kanale, który okazuje się przenosić cztery.

13.5 Co śledzenie nie może ci powiedzieć

Uruchamia bieżącą konfigurację. Jeśli kanał został edytowany od czasu przyjścia wiadomości, śledzenie jest hipotetyczne, a nie odtworzeniem, i Perfuse oznacza to w ten sposób, zamiast pozwolić, aby ta różnica przeszła niezauważona.

Nie ćwiczy również transportu. Śledzenie pokazuje, co byłoby wysłane, a nie czy miejsce przeznaczenia zaakceptowałoby ją — wiadomość, która jest poprawna, a miejsce przeznaczenia, które odmawia połączeń, produkują czyste śledzenie i nieudane dostarczenie. Te są widoczne w rekordzie dostarczenia zamiast.

13.6 Skrypty

Skrypt jest jednym nieprzezroczystym krokiem w śledzeniu. Perfuse może pokazać, co weszło i co wyszło, i nie może pokazać, co się stało pomiędzy lub które pola zostały przeczytane.

Jest to konkretny koszt korzystania ze skryptu zamiast deklaracyjnych kroków i jest wart rozważenia przy wyborze. Zobacz transformacja.

14 Testowanie

Standardowa rada dotycząca testowania interfejsu jest taka, aby zbudować przykładowe wiadomości, które odzwierciedlają twoje własne środowisko — twoje laboratoryjne kody, twoją mieszankę przypadków, twoje zwyczaje nadawcy — i aby usunąć dane pacjenta ręcznie. To jest powolne, a robienie tego niekompletnie jest normalnym wynikiem.

Perfuse oferuje trzy rzeczy zamiast: wygenerowany ruch, który pasuje do kształtu kanału bez jego zawartości, kanał zaproponowany z próbki, którą ktoś ci wysłał, i porównanie z silnikiem, który zastępujesz.

14.1 Wygenerowany testowy ruch

Jeśli kanał obsłużył wiadomości, Perfuse może wygenerować więcej wiadomości podobnych do nich.

Co jest wiernym odwzorowaniem:

• Wyzwalanie zdarzeń w proporcjach rzeczywiście obserwowanych, z co najmniej jednym z każdego, aby rzadkie zdarzenie nadal występowało.
• Pola wypełniane z częstotliwością, z jaką są one rzeczywiście wypełniane — więc przypadku, w którym pole jest *nieobecne*, jest testowane, co jest przypadkiem, który powoduje błędy.
• Powtórzenia tam, gdzie występują powtórzenia, struktura złożona tam, gdzie występuje.
• Kody pobrane z tabel kodów rzeczywiście widzianych.

Co nie jest wiernym odwzorowaniem, a jest to stwierdzone zamiast zakładane: spójność kliniczna. Wygenerowany pacjent ma niezwiązany numer rekordu, ciąg znaków w kształcie nazwy i diagnozę bez żadnego związku z obserwacją. Te wiadomości ćwiczą interfejs. Nie są one zestawem testowym do walidacji logiki klinicznej i nie mogą być używane do tego celu.

14.1.1 Dlaczego nie zawiera on rzeczywistych danych

Argument jest strukturalny, a nie twierdzenie o wysiłku. Jedynym wejściem generatora jest profil ruchu kanału, a profil zawiera wskaźniki wypełnienia, kształty, długości, liczbę powtórzeń i częstotliwość segmentów. Nie zawiera on wartości.

Jedynym wyjątkiem są pola tabel kodów, a kod nie identyfikuje nikogo.

Jest to silniejsza gwarancja niż anonimizacja rzeczywistych wiadomości, która jest procesem, który może być wykonany niekompletnie i zwykle jest. Tutaj nie ma ścieżki, przez którą nazwa mogłaby dotrzeć do wyjścia, ponieważ nazwa nigdy nie była w wejściu.

Każda wygenerowana wiadomość jest parsowana przed jej zwróceniem — nieparsowalny korpus spowodowałby, że ktoś szukałby błędu w swoim interfejsie, który jest w rzeczywistości błędem generatora — i każda z nich jest oznaczona T w MSH-11, z celowo syntetyczną aplikacją nadawcy i obiektu.

14.2 Tworzenie kanału z próbki

Wklej wiadomość, którą laboratorium, szpital lub dostawca wysłał Ci e-mailem, a Perfuse proponuje kanał dla niej. Nic nie musi być uruchomione wcześniej.

Obsługuje to, co ludzie rzeczywiście wklejają: kilka wiadomości w jednym bloku, dowolne zakończenie linii, ramki MLLP, które przetrwały kopiowanie, oraz notatkę pokrywającą wiadomość. Odrzucenie próbki, ponieważ przybyła z zakończeniami linii systemu Windows, byłoby przeszkodą, a nie sprawdzaniem.

14.2.1 Trzy listy

Propozycja jest dostarczana z tym, co próbka pokazuje, co zostało odgadnięte, oraz tym, czego próbka nie może powiedzieć — trzy oddzielne listy, równo ważone w interfejsie.

Są one oddzielne, ponieważ czytelnik, który nie może powiedzieć, które jest którym, musi zweryfikować wszystko lub zaufać wszystkiemu, a oba są gorsze niż wiedza, gdzie szukać.

Z jednej wiadomości granice są nazwane konkretnie, a nie ogólnie: które pola są opcjonalne, które segmenty się powtarzają, które kody istnieją poza tymi, które są tutaj, czy nadawca kiedykolwiek wysyła inne zdarzenie wyzwalające. Ogólna ostrożność jest słowem, które ludzie przeskakują.

Pewność jest słowem — niska, umiarkowana, rozsądna — nigdy procent. Procent sugeruje obliczenie, a to jest sąd o tym, ile próbek istnieje.

Z-segmenty są wskazywane przez nazwę, ponieważ lokalny segment jest tym, o czym nie wspomina specyfikacja, a najczęstszym powodem, dla którego kanał zbudowany z szablonu standardowego nie działa.

14.2.2 Ostrzeżenie o separatorze

Jeśli separator pól próbki nie jest zwykłym |, to pojawia się najpierw, a pewność spada do niskiej.

Powodem jest prawdziwa niezauważalna awaria. HL7 pobiera separator pól z samej wiadomości, więc próbka, której pionowe kreski zostały zastąpione przez typograficzne podobieństwa — co robi procesor tekstu — parsuje się idealnie w pola, które są wszystkie błędne. Nic nie błędnie nigdzie.

Odrzucenie takiej próbki byłoby błędne, ponieważ nadawca może słusznie używać innego separatora. Zatem jest on oznaczony, znak jest nazwany, a prosi się o załącznik w postaci zwykłego tekstu.

14.3 Porównywanie z dawnym silnikiem

Przed przeniesieniem strumienia na żywo, pytanie brzmi, czy Perfuse wytwarza taki sam wynik jak rzecz, która działała przez lata. Żadna ilość jakości projektu nie odpowiada na to. Zobacz migrację.

14.4 Weryfikacja względem rzeczywistych implementacji, w kontenerach

Trzy testy są uruchamiane przeciwko rzeczywistym implementacjom, a nie przeciwko własnej wizji protokołu Perfuse. Znajdują się one poza make check, ponieważ wymagają środowiska kontenerowego, a test, który wymaga Dockera, jest testem, który ludzie przestają uruchamiać.

scripts/interop-up.sh uruchamia je wszystkie i wypisuje, co każdy z nich odblokowuje.

Każdy z nich pomija zamiast zawodzić, gdy kontener jest nieobecny, więc make check przechodzi na maszynie bez Dockera.

Dlaczego jest to oddzielone od reszty zestawu. Każdy inny test tych funkcji miał obie połowy napisane tutaj: dokument, który ten kod podpisał, odczytany przez kod, który go podpisał. To jest zgodność z samym sobą, i jest warta mniej, niż się wydaje.

Kanoniczny SAML jest przypadkiem, który udowadnia punkt. Nosił tysiąc linii testów, pięć z nich specjalnie o kanoniczalizacji, i wszystkie one przeszły, podczas gdy żaden prawdziwy dostawca tożsamości nie mógłby nigdy podpisać nikogo — kanoniczna forma, którą sygnatura obejmuje, była obliczana z pominięciem prefiksów przestrzeni nazw, i jedynym sposobem, aby to znaleźć, było podanie dokumentu Perfuse, który nie został napisany.

Dwa z ośmiu testów znaleźli wady, a trzeci spowodował prawdziwą poprawę. Trzy nie znaleźli nic złego. To proporcja jest argumentem za utrzymaniem wszystkich z nich: test, który przechodzi, powiedział coś, czego w przeciwnym razie nie wiedzielibyśmy, i nie było sposobu, aby to przewidzieć, które z nich będą.

Jeden wzorzec wart nazwania, ponieważ pojawił się w obu wadach: akceptacja nie jest weryfikacją. HAPI zaakceptował uszkodzony system identyfikatora i zapisywał go; wada pojawiła się dopiero podczas odczytywania zasobu. Odbiorca, który toleruje coś, nie jest dowodem, że jest to prawidłowe, tylko że ten odbiorca był łagodny.

Dwa przechwycone asercje są zatwierdzone, w internal/saml/testdata/keycloak-assertion.xml i entra-response.xml, z testami nad oboma — aby ten konkretny regres został złapany bez kontenera.

Oba są potrzebne, a nie jeden jest zapasowy. Keycloak prefiksuje swoje asercje i sygnatury, Entra nie, i to są dwa przeciwne przypadki w kanoniczalizacji — co jest dokładnie tam, gdzie wada była. Test asercji każdego dokumentu nadal obejmuje swój własny przypadek, ponieważ zastępczy przechwyt, który mógłby być prefiksowany, cicho połowicznie zmniejszyłby pokrycie bez zawodzenia czegokolwiek. Ogólna lekcja nie uogólnia się tak tanio: dla wszystkiego innego kontener jest sprawdzany.

14.5 Diagnozowanie testu, który zawodzi raz i nigdy więcej

Test, który zawodzi w pełnym uruchomieniu i przechodzi samodzielnie szesnaście razy, nie jest testem niestabilnym. To jest test, który dzielił coś z uruchomieniem, i sposób, aby to znaleźć, to zmierzyć tę wspólną rzecz, a nie test.

Dwa instrumenty istnieją do tego, i oba są przeznaczone do uruchomienia obok pełnego zestawu:

./scripts/e2e-watchdog.sh /tmp/watchdog.log     # the HTTP server and the shared session
./scripts/e2e-mllp-probe.py /tmp/mllp.log       # the fixture channel's listener

Każdy odkrywa porty uruchomienia z własnego pliku stanu ustawień i próbkuje co 500 milisekund, aż serwer wyjdzie. Zapisują każdą próbkę, a nie tylko błędy, co czyni je użytecznymi: błąd pojawia się w uruchomieniu, w którym nic nie zawiodło, więc wada, która pojawia się raz na trzy uruchomienia, staje się mierzalna w każdym

Ustaw PERFUSE_E2E_KEEP=1, aby zachować katalog tymczasowy, który zawiera bazę danych w stanie, w jakim została pozostawiona, oraz log serwera dla całego przebiegu. Log serwera jest zwykle odpowiedzią. W jednym z badanych przypadków zarejestrował on zatrzymanie kanału i ponowne podłączenie jego nasłuchiwania 421 milisekund później, a odmowa połączenia sondy znalazła się w tym oknie.

Przeczytaj ślad zamiast error-context.md, który był pusty więcej niż jeden raz, gdzie ślad zawierał prawdziwą wiadomość.

Skopiuj artefakty przed ponownym uruchomieniem czegokolwiek. Pomyślny przebieg czyści test-results, więc ślad niepowodzenia, które badasz, znika w momencie, gdy próbujesz go odtworzyć. Gdy raz zostanie utracony, pytanie, które miałoby odpowiedzieć, nie może być już odpowiedziane.

Zatrzymaj kontenery interop najpierw. Zatrzymaj je przed pełnym uruchomieniem przeglądarki i uruchom je za pomocą ./scripts/interop-up.sh później, jeśli nadal są potrzebne.

Osiem kontenerów zajmuje około 9,8 GB pamięci, a na maszynie bez znacznie więcej niż tego pozostaje za mało dla procesów Chromium, node i łańcucha narzędzi Go razem. To, co produkuje, nie jest błędem braku pamięci, ale renderowaniem, które przestaje być planowane: jeden zarejestrowany ślad pokazuje przerwę 60,2 sekundy bez ramki, podczas której Playwright czekał, aż przycisk stanie się "widoczny, włączony i stabilny" i nie mógł uzyskać dwóch kolejnych klatek animacji do porównania. Serwer był zdrowy przez cały czas, najwolniejsze żądanie w całym przebiegu wynosiło 154 milisekundy.

To niepowodzenie jest czytane jako wada w teście, który akurat był uruchomiony. Warto wiedzieć, jaki jest jego kształt: każde żądanie szybkie, strona wizualnie zamarznięta, pętla ponawiania nigdy nie osiąga drugiej iteracji, a całość przechodzi w izolacji.

Tylko jeden przebieg na raz. Suite udostępnia jeden serwer, jedną sesję zalogowaną w web/e2e/.auth/admin.json i jeden plik stanu nazywający proces serwera. Żadne z nich nie jest na przebieg, więc drugi przebieg rozpoczynający się podczas pierwszego nadpisuje plik stanu, a którykolwiek demontaż zakończy się pierwszy, zabija serwer drugiego przebiegu i kasuje jego sesję.

To, co wygląda jak nic niepodobne do przyczyny. Wyprodukowało przebieg 279 niepowodzeń, których pierwsza wiadomość była ENOENT: no such file or directory, open './e2e/.auth/admin.json', przebieg, który zakończył się wcześnie, zgłaszając 217 przejść, i dwa testy niepowodzące z bind: address already in use — żadne z nich nie sugerują dwóch przebiegów walczących. Suite teraz pobiera blokadę i odmawia rozpoczęcia, nazywając proces, który ją trzyma. Blokada pozostawiona przez przerwany przebieg jest przejęta zamiast blokowania na zawsze, ponieważ środek bezpieczeństwa, który blokuje suite, jest tym, co ktoś kasuje wraz z bezpieczeństwem.

Powiązana pułapka, teraz naprawiona: dwa specyfikatory nazwały swoje porty nasłuchiwania wprost, więc serwer pozostawiony przez przerwany przebieg sprawił, że nie powiodły się one w czymś, z czym nie miały nic wspólnego. Porty są teraz pytane o system operacyjny.

Nie odpowiedz na to powtórzeniami. Test, który przechodzi podczas drugiej próby, znalazł prawdziwy wyścig i ukrył go, a playwright.config.ts ustawia retries: 0 z tego powodu.

Jedna ostrożność: próbkowanie co 100 milisekund spowodowało uruchomienie dwudziestu procesów na sekundę, wydłużyło przebieg o połowę, i spowodowało niepowodzenie dwóch testów na limitach czasu, które nie miały z nimi nic wspólnego. Narzędzie, które zmienia to, co mierzy, produkuje wyniki dotyczące samego siebie.

14.6 Co jeszcze potrzebuje prawdziwej infrastruktury

Kilka części Perfuse jest zaimplementowanych i nigdy nie było wykonywanych przeciwko prawdziwej rzeczy. Są one wymienione tutaj, zamiast pozostawione do odkrycia:

• SMB przeciwko prawdziwej udziale Windows — kod protokołu jest kompletny i przetestowany pod kątem bezpieczeństwa ścieżki i obsługi argumentów, ale żaden test nie otwiera gniazda do serwera dołączonego do domeny.
• Prawdziwy port szeregowy.
• Importer Mirth przeciwko XML, który wyprodukował prawdziwy Mirth. Przetestowany przeciwko Mirth 4.5.2 w kontenerze, a znalezienie było o tym repozytorium: jedyna migracja fixture tutaj została napisana ręcznie, a Mirth nie załaduje jej — przechowuje kanał jako nieprawidłowy i odrzuca każde połączenie. To, co zostało ustalone, to to, że atrybuty version prawdziwego Mirth zapisują na każdym elemencie, parsują do tego samego kanału, więc nie są niebezpieczeństwem; to, co nie jest ustalone, to wszystko inne, co zawiera prawdziwy eksport.
• SAML przeciwko komercyjnemu dostawcy tożsamości. Keycloak jest zweryfikowany; jeden dostawca dowodzi, że implementacja odpowiada jednej firmie.
• NCPDP roszczenie przez prawdziwą przełącznicę apteki.
• Wiadomość SCRIPT przez Surescripts, gdzie certyfikacja jest procesem komercyjnym, a nie technicznym.

Funkcje w tym rozdziale i następnym istnieją, aby mogliście zbierać własne dowody, zamiast brać czyjeś słowo.

14.7 Pomierzone przeciwko publicznym korpusom zgodności

Suite testowa, której fixture zostały napisane tutaj, dowodzi zgodności z samym sobą. To są inne ludzie danych.

14.7.1 FHIR R4, własne przykłady specyfikacji

Wszystkie 2,912 plików przykładowych opublikowanych ze specyfikacją FHIR R4 — każdy przykład, jaki autorzy standardu napisali.

Żaden zasób nie został zwalidowany niepoprawnie. Każdy błąd jest jawnym odmówieniem nazwania typu, którego nie można odczytać — 672 ValueSet, 80 ConceptMap i jeden Parameters. Walidator, który cicho przechodzi to, czego nie rozumie, jest gorszy niż ten, który mówi o tym.

Korpus znalazł wadę, co jest powodem uruchomienia go. Walidacja paczki wydrukowała „Walidacja paczki z pliku nie jest jeszcze obsługiwana” i kontynuowała. Było to fałszywe w obu kierunkach: pakiety, których wpisy przypadkowo były typami, które parser mógł trzymać, już były walidowane, a pakiet, który był naprawdę niepoprawny, wyprodukował tę samą linię, nic nie policzył i zakończył się zerem — w tym pod -strict, które istnieje, aby to mogło bramkę budowy. Czterdzieści dwie własne pakiety specyfikacji były pomijane.

Pakiety są teraz walidowane wpis po wpisie, z trzema wynikami trzymanymi osobno: wpis, który jest niepoprawny, nie powiedzie się i nazwie pole, wpis typu, którego ten build nie może odczytać, jest liczony jako pominięty i zgłaszany, a pakiet, który nie zawiera żadnych treści zasobu, nie jest żaden. Ten sam korpus przeszedł od 2,100 sprawdzonych zasobów do 13,723.

14.7.2 HL7 v2, korpus testowy HAPI

Nakładki wiadomości z HAPI, referencyjnej implementacji Java HL7 v2 — celowo niewygodny materiał, w tym uuencoded ładunki, ucieczki separatorów i powtarzające się grupy.

59 wiadomości, 59 przeanalizowanych, żadna odrzucona. Siedem typów wiadomości w korpusie, które każdy system opisuje jako jedną rzecz, co jest celem istnienia perfuse profile.

14.7.3 Co nie zostało uruchomione

DICOM przeciwko publicznemu zestawowi zgodności, oraz X12 przeciwko opublikowanemu korpusowi. Żadne z nich nie zostało wykonane i nie powinno być wnioskowane z dwóch powyższych.

15 Migracja z Mirth

Potrzeba dwóch rzeczy, aby zastąpić działający silnik: kanały muszą zostać przeniesione, a ktoś musi być w stanie pokazać, że zastąpienie produkuje ten sam wynik. Perfuse robi to pierwsze, importując własne eksporty Mirth, a drugie, porównując dwa silniki na własnym ruchu.

Wszystko w tym rozdziale ma równie zastosowanie do Open Integration Engine i BridgeLink. Mirth Connect przestał być open source na wersji 4.6 w marcu 2025; OIE (hostowany przez Eclipse Foundation) i BridgeLink (Innovar Healthcare) są forkami, które kontynuują linię open-source, a oba zapisują te same formaty eksportu. Importer jest testowany przeciwko wszystkim trzem poniżej.

15.1 Importowanie kanałów

Perfuse odczytuje każdy eksport, który te silniki zapisują:

Wskazać perfuse translate na dowolny z nich lub upuścić jeden na Administruj → Migrate:

perfuse translate -o ./channels server-backup.xml

Biblioteka szablonów kodu staje się lib/<library>.js obok kanałów, a każdy kanał, dla którego Mirth włączył tę bibliotekę, otrzymuje scripts.include: [lib/<library>.js] — dzięki temu transformer wywołujący funkcję witryny, taką jak formatMRN(), nadal ją znajduje. Kanał, dla którego biblioteka nie była włączona, nie ją dołącza, ponieważ jego skrypty nie mogły jej zobaczyć w Mirth. Fragmenty kodu przeciągane i upuszczane są pomijane: Mirth wkleja je tylko ręcznie do kroku, więc nie są to kod, który działa samodzielnie. W przeglądarce import kanału najpierw zapisuje biblioteki, które on zawiera.

Pisarz kanału nazywa kanał, do którego dostarcza, według identyfikatora. W grupie lub kopii zapasowej cel jest w tym samym dokumencie, więc staje się miejscem przeznaczenia channel nazywającym ten kanał; z eksportu jednego kanału jest on zgłaszany, abyś mógł go wypełnić. Skrypty globalne serwera nie mają odpowiednika w Perfuse i są zgłaszane, a nie pomijane.

Raport mówi, dla każdego kanału, czy został on przetłumaczony czysto, przetłumaczony z ostrzeżeniami, czy nie mógł być odczytany.

Nagłówek jest ułamkiem z jego mianownikiem — „37 z 40 gotowych” — ponieważ „37 gotowych” nie mówi nic o tym, co jeszcze musisz zrobić.

Kanał, który nie mógł być odczytany, jest innym problemem niż ten, który nie mógł być przetłumaczony. Pierwszy oznacza, że sam XML nie został sparsowany i jest zwykle eksportem trunwowanym lub częściowym; drugi oznacza, że zawartość kanału ma coś, czego nie ma odpowiednik w Perfuse. Import rozdziela je.

15.2 Co się tłumaczy i co wymaga decyzji

Źródła, miejsca docelowe, filtry i zwykłe kroki transformacji są tłumaczone bezpośrednio. Konnectory, które się tłumaczą: TCP/MLLP (i surowy TCP z ramką), HTTP, Plik, Baza danych, JavaScript, DICOM, Usługa internetowa (SOAP), SMTP i Czytelnik/Pisarz kanału. JMS i Pisarz dokumentu nie są tłumaczone i są zgłaszane jako blokery.

Krok Mapper, który ustawia zmienną, wkłada ją do mapy, którą jego zakres nazywa — channelMap domyślnie — dokładnie tak, jak robi to Mirth, więc późniejsze kroki, które ją czytają za pomocą $('name'), ją znajdują.

Transformery JavaScript nie są, ogólnie. Kanały Mirth często zawierają znaczny kod w transformerze, a nie ma automatycznego przekształcenia z dowolnego JavaScript w deklaracyjne kroki. Importer zgłasza je, zamiast próbować tłumaczenia, które mogłoby być subtelnie błędne: źle przetłumaczony transformer jest gorszy niż ten, który jest oznaczony dla człowieka, ponieważ będzie działał.

Gdzie skrypt naprawdę musi pozostać skryptem, Perfuse może go uruchomić — zobacz klucz scripts w dokumencie kanału — przy koszcie śladu na poziomie kroku opisanym w debugowaniu

15.3 Przeciwko czemu tester importu został przetestowany

Pięć silników, z których każdy tworzy własne dokumenty: Mirth 4.5.2, OIE 4.5.2, 4.6.0 i 4.7.0, oraz BridgeLink 26.9.0. scripts/mirth-engine-corpus.sh kompiluje mały program przeciwko własnym bibliotekom każdego silnika i ma własny serializator, który zapisuje trzy zwykłe kanały — kanał MLLP z maperem, skrypt wywołujący bibliotekę szablonów kodu i filtr; kanał HTTP do bazy danych; kanał plikowy z MLLP — plus bibliotekę i grupę kanałów. Ładuje je do uruchomionego silnika i pobiera własną kopię zapasową serwera silnika. Wyniki są zatwierdzane pod internal/mirth/testdata/engines/, a zestaw testowy utrzymuje importer dla każdego z nich na każdym budowaniu: każda kopia zapasowa jest odczytywana, tłumaczona, ładowana, a kanał ADT jest uruchamiany z dwoma komunikatami w celu sprawdzenia, czy biblioteka wypełnia numer rekordu, a filtr odrzuca wynik.

Własne eksporty Perfuse idą w przeciwnym kierunku — kanały Perfuse importowane do każdego uruchomionego silnika i sprawdzane, czy silnik nie przechowuje ich jako nieprawidłowe. Wszystkie pięć akceptują każdy transport, który Perfuse eksportuje. Open Integration Engine 4.7.0 dodał dwa ustawienia HTTP bez odpowiednika tutaj: nadawca HTTP związany z wybranym adresem lokalnym jest zgłaszany jako ostrzeżenie, a limit nagłówka żądania odbiornika HTTP tylko wtedy, gdy jest powyżej 1 MB, które Perfuse akceptuje.

Pierwsze uruchomienie przeciwko temu korpusowi ujawniło cztery wady, wszystkie naprawione: tłumacz odrzucał źródła HTTP i plikowe jako „tylko MLLP jest obsługiwane” długo po tym, jak Perfuse miał oba; odczytywał adres nadawcy HTTP z pola, którego żaden z silników nie zapisuje; tłumaczył rozmiar bufora gniazda Mirth jako limit wiadomości 64 KB; a zmienna mapera stała się globalną zmienną JavaScript, której $('mrn') nigdy nie widział, więc biblioteka wypełniała pusty ciąg.

Jedno-kanałowa konfiguracja, która rozpoczęła to, została również wyeksportowana przez Mirth 4.5.2, napisaną przez samego Mirtha, a nie napisaną tutaj. Ta różnica dała jej miejsce: jedyna konfiguracja w tym repozytorium była kiedyś napisana ręcznie, a prawdziwy Mirth nie załaduje jej — API akceptuje POST, a następnie przechowuje kanał jako This channel is invalid. Verify all required extensions are loaded correctly, z każdym connectorem miejsca docelowego odrzuconym.

Pisanie go ręcznie nigdy nie było możliwe, a powód jest wart poznania, jeśli produkujesz własne eksporty. Serializator Mirth ignoruje elementy, których nie rozpoznaje, więc błędna nazwa elementu nie powoduje błędu — po prostu konektor nie jest tam później. Nie ma nic do odczytania i nic do skorygowania.

scripts/mirth-author-channel.sh tworzy jeden przy użyciu własnych klas modelu Mirth i jego własnego serializatora, a następnie wysyła go do uruchomionego serwera i kończy się niepowodzeniem, jeśli serwer odrzuca go. Importer Perfuse odczytuje wynik: nazwa, transport źródłowy i miejsca docelowe wszystkie przetrwają.

15.4 Udowodnienie, że pasuje

To jest część, która decyduje, czy migracja nastąpi, i potrzebuje dowodów, a nie zaufania.

Perfuse porównuje swój własny wynik z wynikiem starego silnika, wiadomość po wiadomości, w Twoim ruchu. Co potrzebuje, to pary: wiadomość, tak jak przybyła, i wiadomość, którą stary silnik wyprodukował z niej. Oba są w własnym magazynie wiadomości Mirth i mogą być wyeksportowane z przeglądarki wiadomości.

15.4.1 Cztery liczby, a nie wskaźnik zaliczenia

Są to cztery liczby, ponieważ oznaczają cztery różne rzeczy i łączenie ich ukrywa te, które wymagają decyzji.

Identyczny oznacza dokładnie taki sam, a nie równoważny. Słabszy test pozwoliłby na różnice w kolejności segmentów lub separatorach końcowych, a to są właśnie te, które system zewnętrzny odrzuca.

Różnice kosmetyczne są liczone oddzielnie, a nie są włączane do kolumny dobrej. Rzeczywiście nie niosą informacji, więc traktowanie ich jako niepowodzeń zakopie prawdziwe ustalenia pod tysiącami niczego — ale nie są identyczne, i odbiorca wykonujący własną ścisłą analizę może się nie zgodzić.

„Nie może być uruchomiony” jest oddzielony od „różni się”, ponieważ jest to zwykle luka konfiguracyjna, którą importer nie mógł wypełnić, a nie decyzja mapowania. Jeśli wszystko jest w tej kolumnie, wyrok tak mówi i mówi, abyś popatrzył na konfigurację przed przeczytaniem czegokolwiek innego.

15.4.2 Różnice są grupowane według pola

Przebieg pięćdziesięciu tysięcy wiadomości, który zgłasza cztery tysiące różnic, powiedział ci nic, czego możesz użyć. Ten sam przebieg, który zgłasza, że PID-8 różni się w każdej wiadomości, ponieważ stary silnik napisał Male, gdzie Perfuse pisze M, powiedział ci dokładnie jedną rzecz do podjęcia decyzji.

Więc każde znalezienie jest polem z liczbą, i mówi, czy różnica jest systematyczna — ta sama para wartości za każdym razem — czy czy zawartość pola różni się.

Ta różnica jest najbardziej użyteczną rzeczą w raporcie. Jedna odrębna para wartości w czterech tysiącach wiadomości to jedna decyzja mapowania. Cztery tysiące odrębnych par to różnica zawartości, co jest innym i znacznie gorszym problemem, i nie mogą one wyglądać tak samo.

Znalezienia są uporządkowane według liczby wiadomości, które dotyczą, więc największa pojedyncza przyczyna jest pierwsza.

15.4.3 Wyrok nie zaokrągla

Podaje dokładne liczby: 49 993 z 50 000, a nie „ponad 99%”. Te siedem są cały punkt biegu.

Zostało napisane, aby można było je cytować w wniosku o zmianę, ponieważ to tam kończy się numer.

15.5 Zalecana sekwencja

1. Importuj kanały i rozwiąż wszystkie problemy zgłoszone jako nieczytelne.
2. Dla każdego kanału przejrzyj ostrzeżenia. Większość z nich to skrypty.
3. Eksportuj kilka tysięcy par wiadomości z Mirth dla najbardziej zajętego kanału i uruchom porównanie.
4. Pracuj przez wyniki. Systematyczne są to jedne decyzje.
5. Uruchom ponownie, aż jedynymi różnicami będą te, które uznałeś za poprawne.
6. Uruchom Perfuse w trybie cieniowym obok Mirth na żywej transmisji, dostarczając nigdzie i porównując ponownie przez okres, który obejmuje weekend i koniec miesiąca.
7. Przełącz jeden kanał, a nie wszystkie.

15.6 Co działa tylko na oprogramowaniu jednego dostawcy

Ekran migracji odpowiada na drugie pytanie, i warto je zadać, zanim będziesz miał jakiekolwiek zdanie na temat Perfuse: ile Twojej logiki integracji może działać tylko na oprogramowaniu, które posiadasz.

Każdy kanał otrzymuje wyrok Przenośność, z tego samego skanu, który produkuje notatki migracyjne. Działa przeciwko eksportowi kanału, więc nie wymaga niczego zainstalowanego i nie zmienia niczego.

15.6.1 Różnica jest cały punkt

Większość Java w skryptach Mirth nie jest zablokowana. SimpleDateFormat, HashMap, Apache Commons — wszystko to działa wokół silnika JavaScript z 2009 roku, wszystko to zwykłe, wszystko to z bezpośrednimi odpowiednikami. Kanał z trzema stoma takimi odniesieniami jest w pełni przenośny, a narzędzie, które zgłaszało „300 odniesień do Javy, jesteś uwięziony” kłamałoby ci.

Zablokowanie jest specyficznie połączone z wywołaniami, które potrzebują serwera dostawcy: com.mirth.connect.* i jars dostawcy. Pięć z nich i jesteś uwięziony. Pięćset innych i jesteś wolny.

Więc wyrok zaczyna się od liczby, która ma znaczenie, i mówi w tym samym zdaniu, że większa liczba nie jest tym. Gdzie są wywołania dostawcy, są one wymienione przez nazwę — liczba jest twierdzeniem, a lista jest czymś, co twój własny inżynier może sprawdzić.

Trzecia kategoria jest trzymana oddzielnie: możliwość, która istnieje, ale nie z skryptu. Uruchomienie kanału z JavaScript nie ma odpowiednika tutaj, i istnieje punkt końcowy API, który robi dokładnie to samo. Nazywanie tego zablokowaniem byłoby przesadą.

15.6.2 Wywołania Javy, które działają niezmienione

Najczęstsze z tych klas Java są uruchamiane tak, jak są napisane. Perfuse nie ma środowiska uruchomieniowego Java, więc są to klasy JavaScript z tymi samymi nazwami i metodami, wystarczającymi dla sposobu, w jaki skrypty kanałów je wykorzystują; importPackage(java.util) i importClass(...) wprowadzają je do zakresu ich krótkimi nazwami, jak w Rhino (własne Date, Map, Set, Math, String i Boolean JavaScript nigdy nie są zastępowane: te Java są nadal dostępne przez pełne nazwy). Raport migracji liczy każde z tych wywołań jako już obsługiwane.

Zachowują się jak Java tam, gdzie skrypty od nich zależą: Integer.parseInt("x") rzuca NumberFormatException, String.replaceAll i split przyjmują wyrażenia regularne, podczas gdy replace jest literalne, mapy kluczy ciągów według wartości, TreeMap i TreeSet iterują w porządku, a SimpleDateFormat.parse zwraca datę, na której getTime() działa. Metoda, którą skrypt wywołuje, a odpowiednik jej nie ma, kończy się niepowodzeniem w tej linii, nazywając ją; każda inna klasa Java kończy się niepowodzeniem według nazwy, jak poprzednio. BigDecimal jest tutaj podwójnym, więc nie zachowuje dokładnej arytmetyki dziesiętnej Java: sprawdź skrypty, które z niej korzystają dla pieniędzy.

15.6.3 Zewnętrzne skrypty są zgłaszane jako nieznane

Krok, który uruchamia zewnętrzny plik skryptu, odnosi się do ścieżki na starej serwerze, a plik nie jest w eksporcie. Nic nie można powiedzieć o tym, co zawiera, więc jest on liczony jako nieznany, a nie założony w którąkolwiek stronę. Pobierz te pliki, zanim wnioskujesz cokolwiek — w obie strony.

15.6.4 Własne zablokowanie Perfuse, stwierdzone w tym samym oddechu

Ten rozdział byłby nieuczciwy bez tego.

Perfuse jest Apache 2.0, co jest nieodwołalne dla kodu już wydanego. Możesz rozgałęzić to, co istnieje dzisiaj, i nikt nie może wycofać tego. Kanały są plikami YAML, a skrypty są zwykłym JavaScript, więc nie ma powierzchni własnościowej, którą można by nazwać — smak Mirth Java zależności jest strukturalnie niedostępny tutaj, co jest miejscem, w którym ograniczenie jest prawdziwie cechą.

Co to nie obiecuje: że przyszła wersja pozostaje otwarta, że usługa hostowana istnieje w cenie, którą lubisz, lub że migracja z Perfuse nic nie kosztuje. Przenoszenie warstwy integracji oznacza ponowne testowanie każdego kanału przeciwko rzeczywistemu ruchowi. To, co wybierasz, to czy artefakty, które budujesz, są czytelne i przenośne, oraz czy wyjście zależy od licencji, którą kontroluje ktoś inny.

15.6.5 Konfigurowanie kroku 6

Sekcja Cień rozpoczyna porównanie. Wybierz kanał, który jest uruchomiony, wybierz kandydata do porównania z listy i uruchom.

Trzy rzeczy o tym są warte wiedzy, zanim będziesz polegał na tych liczbach.

Kandydat jest wybierany z listy, a nie wpisywany. Nazwa cienia określa plik kanału, a nazwa, która nie rozwiązuje problemu, powoduje, że kanał *live* jest nieprawidłowy — Perfuse odmawia kanału w całości, gdy coś, na co się odnosi, jest złamane. Tak więc literówka nie powoduje ostrzeżenia, ale sprawia, że uruchomiony kanał znika.

Udział jest procentem. Zmniejszaj go tylko na zajętym kanale i wiedz, co to kosztuje: próbkowanie redukuje pracę i zaufanie w tej samej proporcji, a wiadomość, która pokazałaby różnicę, jest niezwykła.

Pola do zignorowania są zwykle potrzebne. Kanał, który stawia znacznik czasu lub numer sekwencyjny, różni się w każdej wiadomości, co powoduje, że wskaźnik różnic wynosi 100% i nie mówi nic. MSH-7 i MSH-10 są typową parą.

Porównanie jest zapisywane w pliku kanału natychmiast po jego uruchomieniu i zaczyna obserwować, gdy kanał zostanie ponownie załadowany — ekran mówi o tym, zamiast twierdzić, że już działa. Zatrzymanie porównania pozostawia kanał kandydujący na miejscu, ponieważ kandydat jest tym, co ma zostać uruchomione.

Krok 6 jest tym, którego nie można skrócić. Różnice, które mają znaczenie, zwykle występują w ruchu, który pojawia się tylko okazjonalnie — rzadkie zdarzenie wyzwalające, miesięczna partia, nadawca, który zachowuje się inaczej o północy — a próbka pobrana w ciągu popołudnia nie będzie ich zawierać.

15.7 Powrót w drugą stronę

Kanał można wyeksportować jako plik kanału Mirth z przeglądarki: Kanały, a następnie Do Mirth na kanale, który chcesz.

Istnieje to, ponieważ zastrzeżenie dotyczące zastąpienia działającego silnika rzadko dotyczy tego, czy zastąpienie jest dobre. Chodzi o to, co się stanie, jeśli decyzja okaże się błędna, a eksport, który wraca tą samą drogą, jest najtańszą odpowiedzią na to.

Przeczytaj, co mówi dialog, zanim weźmiesz plik. Format Mirth nie ma miejsca na filtr Perfuse, łańcuch transformacji, umowę ani porównanie cienia, więc wyeksportowany kanał robi mniej niż ten, z którego pochodzi. Transporty i ich adresy są przekonwertowane; logika nie. Każda strata jest wymieniona z nazwy przed zaoferowaniem pliku, a ten sam wykaz trafia do opisu kanału, aby osoba, która go importuje, również to zobaczyła.

Kanał, którego Mirth nie może wyrazić, jest odrzucany zamiast przybliżany. Punkt docelowy S3 nie ma odpowiednika w Mirth, a kanał, który został zaimportowany czysto, dostarczając w inne miejsce niż wiadro, byłby gorszy niż w ogóle nie ma pliku. Odmowa wymienia punkt docelowy, który jest winny.

Definicje łączników nie są pisane na podstawie odczytu formatu Mirth. scripts/mirth-dump-connector-templates.sh ma własny serializator Mirth, który produkuje wartości domyślne dla każdej klasy łączników, a Perfuse zastępuje wartości w tych dokumentach — odmawiając każdej ustawienia, której szablon nie zawiera już. To ma znaczenie ze względu na to, jak Mirth odpowiada na kanał, który nie może być sparsowany: nie odmawia importu. Zamiast tego przechowuje kanał, którego opis został zastąpiony przez „Ten kanał jest nieprawidłowy. Sprawdź, czy wszystkie wymagane rozszerzenia są załadowane poprawnie” i którego punkty docelowe zostały dyskretnie odrzucone. Eksportownik sprawdzony względem własnego wyjścia, a nie względem serwera, przechodzi każdy test, podczas gdy produkuje dokumenty, które są wyrzucane, co jest dokładnie tym, co się tu stało, zanim eksporty zostały wypróbowane na uruchomionym Mirth.

To, co przekracza dzisiaj: MLLP i TCP w obie strony, HTTP w obie strony, odczyt i zapis plików, odczyt i zapis baz danych, DICOM w obie strony, a także punkty docelowe SMTP, SOAP i JavaScript. Każda para jest weryfikowana przez importowanie do prawdziwego Mirth 4.5.2 i sprawdzenie, czy serwer nie zamienił cicho kanału.

16 CMS-0057 dla płatników

Ostateczne przepisy CMS dotyczące interoperacyjności i uprzedniej autoryzacji (CMS-0057-F) wymagają od płatników objętych tymi przepisami — organizacji Medicare Advantage, programów Medicaid i CHIP stanowych oraz ich planów ubezpieczeniowych, a także wydawców QHP na federalnych giełdach — uruchomienia czterech interfejsów API FHIR od 1 stycznia 2027 r. oraz opublikowania metryk uprzedniej autoryzacji na ich publicznej stronie internetowej co roku od 2026 r.

Perfuse zapewnia cztery interfejsy API na swoim punkcie końcowym FHIR oraz konwersje, które je wypełniają: rozliczone roszczenia jako CARIN Blue Button, uprzednie autoryzacje jako Da Vinci PDex, a roczne metryki w układzie szablonu CMS. Widok CMS-0057, pod Exchange, mówi, który z czterech ten egzemplarz może odpowiedzieć i co każdy z nich jeszcze potrzebuje, oraz wykonuje wszystkie trzy konwersje w przeglądarce.

Leki są poza zakresem przez cały czas, tak jak w przepisach dotyczących uprzedniej autoryzacji: nie ma roszczeń farmaceutycznych, nie ma formularza, a wiersz metryk nazywający lek jest odrzucany zamiast zliczany.

16.1 Cztery interfejsy API

Interfejs API Patient Access nie wymaga własnej operacji: jest to zwykłe odczytywanie i wyszukiwanie punktu końcowego FHIR, zabezpieczone przez SMART, z zasobami CARIN i PDex w sklepie. Wyszukiwanie ExplanationOfBenefit obsługuje parametry o nazwach CARIN — patient, identifier, type, service-date, billable-period-start, provider, insurer, coverage — a Coverage obsługuje subscriber-id, identifier i payor.

16.1.1 Dwie wersje przewodników: 2.1.0 i 2.2.x

CMS-0057-F zaleca CRD, DTR i PAS 2.0.1 i 2.1.0. Wersje 2.0.1 opierają się na US Core 3.1.1, które wygasło 1 stycznia 2026 r., więc 2.1.0 jest wersją, którą system EHR zbudowany zgodnie z tą regułą najprawdopodobniej obsługuje; najnowsze to CRD 2.2.1, DTR 2.2.0 i PAS 2.2.1. Perfuse odpowiada na obie. Określa, którą wersję mówiący używa, najpierw najbardziej szczegółową:

1. z żądania: rozszerzenie CDS Hooks CRD davinci-crd.requestedVersion ("2.1"), lub wersja na profilu Da Vinci, który wejście DTR lub PAS twierdzi (profile-pas-request-bundle|2.1.0);
2. z rejestracji mówiącego: davinci_version: "2.1" na kliencie SMART (-smart-clients) lub kliencie CDS (-cds-clients);
3. z serwera: serve -davinci-version 2.1; domyślnie jest to 2.2.

clients:
  - issuer: https://ehr.example.org
    jwks_url: https://ehr.example.org/.well-known/jwks.json
    davinci_version: "2.1"

Każda odpowiedź jest ustalona i przechowywana w formie 2.2.x i przepisywana dla wywołującego 2.1.0, tak jak jest wysyłana, więc reguły, kolejka przeglądu, link X12 278 oraz metryki są takie same dla obu. Przepisanie obejmuje różnice w sposobie zapisu wersji: CRD 2.1.0 nie ma indeterminate (Perfuse mówi warunkowe, z powodem) i nie ma kategorii w szczegółach pokrycia; DTR 2.1.0 nazywa pakiet PackageBundle i pozostawia QuestionnaireResponse aplikacji; PAS 2.1.0 odpowiada na $inquire z jednym Bundle i nie ma rozszerzeń recenzenta i transmisji. Pełna lista oraz sprawdzenie przeciwko każdej przewodnikowi 2.1.0 jest w conformance/davinci21. Powiadomienie PAS postępuje zgodnie z -davinci-version, ponieważ subskrypcja nie określa, jaką wersję odczytuje jej właściciel.

16.2 Wymagania i dokumentacja dotyczące ubezpieczenia: CRD i DTR

Interfejs API upoważnienia wcześniej jest w praktyce trzema przewodnikami Da Vinci razem. CRD mówi klinicystom, podczas gdy zamówienie jest jeszcze wersją roboczą, czy jest objęte, czy wymaga upoważnienia wcześniej i jakie dokumenty są wymagane. DTR przekazuje EHR kwestionariusz, który gromadzi te dokumenty. PAS składa wniosek i zwraca decyzję. Perfuse obsługuje wszystkie trzy jako płatnik.

-crd-rules rules.yaml obsługuje CRD za pomocą CDS Hooks w /cds-services: wszystkie sześć haków CRD, order-sign, order-select, order-dispatch, appointment-book, encounter-start i encounter-discharge, każdy z prefetchem dla aktywnego pokrycia pacjenta. Dwa haki spotkania również prefetchują spotkanie i odpowiadają na spotkanie samo w sobie, dopasowane do jego typu i typu usługi, tak jak appointment-book odpowiada na spotkanie. Reguły są polityką płatnika, przechowywaną w pliku, ponieważ zmieniają się bez wydania oprogramowania:

payer: Springfield Health Plan
rules:
  - description: Home oxygen equipment
    codes: [E0424, E0431]
    covered: covered            # covered, not-covered, conditional
    pa: auth-needed             # no-auth, auth-needed, satisfied, performpa, conditional
    documentation: [clinical]
    questionnaire: https://www.springfield-health-plan.example/fhir/Questionnaire/home-oxygen

Każde zamówienie otrzymuje aktualizację systemActions z rozszerzeniem coverage-information CRD - które EHR przechowuje w zamówieniu i później wysyła z upoważnieniem wcześniej - oraz kartę, którą czyta klinicysta. Zamówienie, którego kod nie ma reguły, jest odpowiedzią conditional, nigdy nie zakłada się, że jest objęte; wniosek bez ubezpieczenia w ogóle otrzymuje kartę, mówiącą o tym. examples/crd/ ma plik reguł i pasujący do niego kwestionariusz.

Reguła może również zawierać resztę informacji, które CRD pozwala płatnikowi podać:

• billing_codes: kody do rozliczania.
• details: limity i koszty, takie jak allowed-period lub in-network-copay.
• contact: kto powinien być kontaktowany.
• expiry_days: jak długo odpowiedź jest ważna.
• depends_on: kody innych zamówień, od których zależy odpowiedź, więc EHR pyta ponownie, jeśli się zmienią.
• doc_purpose: do czego służy dokumentacja (withclaim, withorder, retain-doc). withpa jest odrzucany, ponieważ własne ograniczenie CRD 2.2.1 crd-ci-q4 je odrzuca.

Co EHR nie pobiera wcześniej, Perfuse odczytuje z serwera EHR fhirServer za pomocą tokenu, który wysłał. Jeśli to nie powiedzie się, odpowiedź jest indeterminate z powodem technical CRD, nigdy nie jest zgadywana. Pokrycie, które wygasło lub nie jest aktywne, jest odpowiedzią not-covered, no-active-coverage.

members: fhir w pliku reguł rozwiązuje ubezpieczenie przeciwko własnym rekordom płatnika w magazynie FHIR tego serwera (uruchom go z -fhir), te same rekordy, które $member-match czyta:

• pacjent, który nie jest członkiem, jest odpowiedzią no-member-found;
• członek, którego ubezpieczenie nie pasuje, jest odpowiedzią coverage-not-found;
• uprzednia autoryzacja już zatwierdzona tam dla usługi (ClaimResponse z preAuthRef) powoduje odpowiedź satisfied,

z tym numerem.

Odkrywanie deklaruje davinci-crd.version i opcję konfiguracyjną coverage-info. Gdy klient wyłącza tę opcję, odpowiedź jest pusta. Tokeny JWT EHR są sprawdzane zgodnie z definicją CDS Hooks, z iss, aud, exp, iat i jti i bez sub, a powtarzający się jti jest odrzucany.

Połączenia uwierzytelniają się za pomocą tokenu JWT, który EHR podpisał dla każdego połączenia, od wydawcy wymienionego w -cds-clients z jego adresem URL JWKS - który jest tym, jak CDS Hooks je opisuje - lub za pomocą tokenu API Perfuse. Odkrywanie jest otwarte, jak wymaga tego CDS Hooks.

DTR: załaduj kwestionariusze do punktu końcowego FHIR, a POST /fhir/Questionnaire/$questionnaire-package zwróci je jako pakiety DTR, z bibliotekami CQL, które wymieniają. Żądanie może nazwać kwestionariusz lub wysłać zamówienie i pozwolić jego coverage-information określić, który.

Próba: Płatnicy → Roszczenia i autoryzacja → Wymagania dotyczące ubezpieczenia (CRD) wysyła zamówienie do reguł tego serwera lub do adresu URL usługi CDS płatnika i wyświetla karty i informacje o ubezpieczeniu.

16.3 Roszczenia jako CARIN Blue Button

perfuse cms0057 carinbb łączy każde roszczenie w 837 z jego płatnością w 835, według numeru konta pacjenta, który 835 jest wymagany do powtórzenia, i zapisuje transakcję FHIR dla każdego: ExplanationOfBenefit z pacjentem, ubezpieczeniem, organizacjami i praktykami, na które powołuje się.

perfuse cms0057 carinbb -system https://fhir.your-plan.org/identifier -network innetwork \
    claims.837 remittance.835

Profil postępuje zgodnie z roszczeniem: profesjonalne roszczenia (837P) stają się C4BB-ExplanationOfBenefit-Professional-NonClinician, a instytucjonalne (837I) stają się wewnętrzne lub zewnętrzne, w zależności od typu rachunku. Każdy wpis jest PUT z identyfikatorem pobranym z identyfikatorów źródłowych, tak aby załadowanie tego samego roszczenia dwukrotnie zaktualizowało je, zamiast utworzyć drugą kopię.

Trzy rzeczy nie są zawarte w żadnym pliku X12, a każda z nich jest obsługiwana przez wskazanie, że ich nie ma, zamiast zgadywać:

• System identyfikatora. CARIN wymaga, aby identyfikator członka nazwał przestrzeń nazw płatnika. -system jest wymagany; nie ma domyślnego, ponieważ domyślny dałby każdemu płatnikowi używającemu Perfuse tę samą przestrzeń nazw.
• Status sieci. Żadna z transakcji nie mówi, czy dostawca rozliczający jest w sieci, i to decyduje, co członek płaci. Bez -network status płatności korzyści jest other i konwersja zauważa, dlaczego.
• Roszczenie, o którym 835 nie wspomina. Roszczenie CARIN ExplanationOfBenefit jest roszczeniem rozliczonym. Bez 835 nie ma numeru roszczenia płatnika, nie ma płatności i nie ma odpowiedzialności członka, więc roszczenie jest zgłaszane jako pominięte i nieprzekonwertowane.

Diagnozy są zapisywane z kropką dziesiętną (J02.9, a nie J029), ponieważ tak opublikowano system kodowania i serwer terminologiczny zapytany o inne pisownię mówi, że nie istnieje. Identyfikator członka zależnego jest identyfikatorem subskrybenta, który jest tym, co 837 zawiera, i notatki mówią o tym. NPI z niepoprawnym cyfrą kontrolną jest zgłaszany przed odrzuceniem przez US Core.

16.4 Uprzednie autoryzacje jako PDex

perfuse cms0057 priorauth konwertuje odpowiedź Da Vinci PAS ClaimResponse — lub pakiet odpowiedzi PAS, który ją zawiera — na PDex ExplanationOfBenefit dotyczący uprzedniej autoryzacji, który jest obsługiwany przez wszystkie trzy API danych.

perfuse cms0057 priorauth pas-response.json pas-claim.json

PAS Claim jest opcjonalny i prawie zawsze jest potrzebny. ExplanationOfBenefit musi określić, pod jakim ubezpieczeniem została podjęta decyzja, a tylko wniosek zawiera tę informację; bez niej konwersja zostaje zatrzymana i o tym informuje. Czynność przeglądu — zatwierdzenie, odrzucenie, zawieszenie, wraz z numerem autoryzacji i powodem — przechodzi z rozszerzenia PAS do PDex, a kod usługi X12 pozostaje pod adresem URI, do którego jest powiązany przez PDex.

16.5 API dostępu do danych dostawców i API pomiędzy płatnikami

Z -fhir-payer-apis punkt końcowy FHIR obsługuje trzy dodatkowe operacje:

• POST /fhir/Patient/$member-match — dopasowanie członków HRex. Identifikatory ubezpieczenia są ograniczane do kilku kandydatów, a nazwisko i data urodzenia muszą się zgadzać; imię jest porównywane według inicjału, a płeć tylko wtedy, gdy obie strony ją określają. Więcej niż jeden kandydat nie jest dopasowany, a odpowiedź to 422 zamiast zgadywania, ponieważ zgadywanie ujawnia dane osobowe obcych osób. Wymagana jest aktywna zgoda na ujawnienie, ponieważ API pomiędzy płatnikami jest opcjonalne dla członków; -fhir-member-match-without-consent wyłącza to ustawienie dla testów.
• GET lub POST /fhir/Group/{id}/$davinci-data-export — eksport zbiorczy bieżących członków grupy Da Vinci. exportType wybiera odbiorcę: hl7.fhir.us.davinci-pdex#provider-download lub #provider-delta dla dostępu do danych dostawców, #payertopayer dla API pomiędzy płatnikami.
• GET /fhir/Group/{id}/$export — standardowy eksport zbiorczy grupy, traktowany jako dostęp do danych dostawców.

Eksporty stosują reguły wykluczeń podczas eksportowania. Roszczenia tracą informacje o płatnościach i kwotach kosztów, oraz zachowują usługi, kody, daty i dostawców; profil CARIN jest usuwany z meta.profile, ponieważ zasób nie spełnia już jego wymagań. API pomiędzy płatnikami również pomija odrzucone uprzednie autoryzacje. Członkowie posiadający aktywną zgodę na opt-out dostępu do danych dostawców PDex są pomijani w eksportach dostawców, a log rejestruje liczbę takich członków. Parametr patient może być ograniczony tylko do członków grupy; podanie innej osoby jest odrzucane.

Dostęp do eksportu grupy jest decydowany przez uwierzytelnianie punktu końcowego. Zakresy SMART określają, jakie rodzaje zasobów może odczytać token, a nie, do której grupy, więc każdy dostawca potrzebuje tokenu, który może dotrzeć tylko do swojej własnej listy atrybucji. Token API może być ograniczony do grup podczas tworzenia — perfuse token create -label riverside-provider-access -fhir-groups riverside-attributed, lub pole Ogranicz do grup FHIR w sekcji Użytkownicy → Poświadczenia maszynowe — i na punkcie końcowym FHIR może odczytać te grupy, uruchomić $davinci-data-export lub $export na nich i pobrać to, co wyeksportowano, i nic więcej. Inna grupa dostawcy zwraca odpowiedź „nie znaleziono” zamiast „zabroniono”, więc token nie dowiaduje się, jakie inne listy atrybucji istnieją; każde inne żądanie, w tym dopasowanie członków i zwykłe wyszukiwanie, jest odrzucane. Ograniczenie dotyczy tokenów API; token z wydawcy SMART nie ma ograniczenia grupy. Gdy SMART jest również skonfigurowany, tokeny API są odrzucane, chyba że Ustawienia → FHIR → Akceptuj tokeny API Perfuse obok tokenów SMART są włączone (patrz: Bezpieczeństwo, *Kto może wywołać punkt końcowy FHIR*); token dostawcy z ograniczeniem grupy wymaga tego.

16.6 Katalog dostawców: Plan-Net

CMS-0057 również prosi płatników o katalog dostawców, a punkt końcowy FHIR obsługuje go dla Da Vinci Plan-Net 1.1.0 bez możliwości wyłączenia: ładuje Praktyków, Role Praktyków, Organizacje, Powiązania Organizacji, Lokalizacje, Usługi Opieki Zdrowotnej, Planów Ubezpieczenia i Punkty Końcowe, a aplikacje członków mogą wyszukiwać je. Każdy parametr wyszukiwania Plan-Net jest indeksowany - rola sieci i usługi, obszar pokrycia planu, organizacja uczestnicząca w powiązaniu, organizacja partof - wraz z include i łańcuchami odwrotnymi (_has), których używają zapytania przewodnika, a oświadczenie o możliwościach wymienia profile Plan-Net.

Pakiet testowy Plan-Net Inferno przechodzi 199 testów. 10 testów, które nie powiodły się, to łańcuchy do przodu, w których zestaw pobiera wartość wyszukiwania z pierwszej organizacji, którą widział, zamiast tej, na którą odnoszą się wyszukiwane zasoby; jest to zgłaszane do zestawu (jego problem 34), a serwer odpowiada poprawnie na te zapytania, gdy podano wartość, którą przechowuje dane.

16.7 Metriki uprzedniej autoryzacji

perfuse cms0057 metrics odczytuje plik CSV z decyzjami wyeksportowanymi z systemu zarządzania wykorzystaniem i tworzy stronę publiczną, którą wymaga CMS, w układzie *Raportowanie metryk uprzedniej autoryzacji — Przegląd i szablon*.

perfuse cms0057 metrics -year 2025 -org "Springfield Health Plan" -services services.csv \
    decisions.csv > prior-authorization-metrics-2025.html

Kolumny są znalezione według nagłówka: priority, received, decided i decision są wymagane, a request_id, line_of_business, extended, appealed, appeal_decision, service_code i service_description są odczytywane, gdy są obecne. Żądanie należy do roku, w którym zostało podjęte; żądanie, które nadal czeka, jest wyświetlane jako wykluczone, nigdy nie jest liczone. Każdy wiersz, który nie może być odczytany, jest zgłaszany wraz z numerem wiersza.

Arytmetyka postępuje zgodnie ze szablonem: dla standardowych i przyspieszonych żądań oddzielnie, udział zatwierdzony i odrzucony, zatwierdzony i odrzucony w ramach terminu decyzji, zatwierdzony po przedłużeniu czasu przeglądu, oraz zatwierdzony po odwołaniu — spośród odwołań, a nie spośród żądań — wraz z średnim i medianowym czasem od otrzymania do decyzji. Mediana poniżej dnia jest zapisywana w godzinach, a nie zaokrąglana do „0 dni”, co jest wyraźnie wymagane przez szablon. Częściowo zatwierdzone żądania są liczone jako zatwierdzone, ponieważ szablon nie ma kategorii dla nich, a strona podaje, ile ich było. Metryki są raportowane na poziomie linii biznesowej, który jest poziomem wymaganym przez CMS.

Strona jest samodzielna — nie zawiera skryptu, zewnętrznego arkusza stylów ani czcionki — ponieważ jest publikowana na publicznej stronie internetowej przez osobę, która ją utrzymuje, a wszystko, co ładuje z innego miejsca, jest czymś, co może ulec awarii lub śledzić odwiedzającego. -format csv i -format json dają te same numery dla innych zastosowań. Bez -services strona zawiera powiadomienie, że lista elementów i usług wymagających uprzedniej autoryzacji jest niekompletna, ponieważ CMS wymaga tego na tej samej stronie.

16.8 Leki: formularz, Real-Time Prescription Benefit i elektroniczna uprzednia autoryzacja

CMS-0062-P (zaproponowany 14 kwietnia 2026 r.) wprowadziłby leki do uprzedniej autoryzacji: dotknięci płatnicy wspieraliby elektroniczną uprzednią autoryzację NCPDP SCRIPT, standard NCPDP Formulary & Benefit i NCPDP Real-Time Prescription Benefit od 1 października 2027 r., decydowaliby o wnioskach o leki w ciągu 24 godzin (przyspieszone) i 72 godzin (standardowe), podawaliby konkretny powód każdej odmowy i raportowaliby metryki leków od 2028 r. Medicare Part D już wymaga elektronicznej uprzedniej autoryzacji SCRIPT. Jeden plik, formularz, odpowiada na to wszystko:

perfuse serve -fhir -pas -crd-rules payer-rules.yaml -formulary formulary.yaml

examples/formulary/formulary.yaml to przykład, w którym leki są rzeczywistymi pojęciami RxNorm z NDC, których lista jest sprawdzana przeciwko RxNav. Plik nazywa płatnika, jego plany (każdy z formularzem, który używa, jego identyfikatorami grupy i udziałami w kosztach według korzyści aptecznych i poziomu) i jego formularze. Każdy lek jest pojęciem RxNorm SCD lub SBD z jego grupą RxNorm (SCDG lub SBDG, które wymaga interfejs API Formulary), jego NDC, poziomem i limitami: prior_authorization, step_therapy, quantity_limit (ilość w określonej liczbie dni, oraz maksymalna dzienna), not_covered, alternatives (kody RxNorm, najbardziej preferowane jako pierwsze), notes i questionnaire, kanoniczny URL kwestionariusza FHIR, o który prosi uprzednia autoryzacja. cost_30_day to koszt planu 30-dniowego zaopatrzenia, którego współubezpieczenie jest procentem; bez niego współubezpieczenie jest cytowane jako procent, nigdy jako wymyślona kwota. Cały plik jest sprawdzany podczas ładowania, każdy problem jest wyświetlany na raz. Członek jest znaleziony przez listę members pliku, przez grupę lub za pośrednictwem sklepu FHIR: Coverage, którego subscriberId jest identyfikatorem członka, a którego class typu plan jest identyfikatorem planu. Płatnicy › Leki wyświetla formularz, wycenia lek i uruchamia uprzednią autoryzację od końca do końca.

16.8.1 API formularza leków Da Vinci US

Opublikowany w /formulary/fhir jako Da Vinci US Drug Formulary 2.1.0: każdy plan to PayerInsurancePlan, każdy formularz to Formulary (oba InsurancePlan), każdy lek to FormularyDrug (MedicationKnowledge), a każda pozycja to FormularyItem (Basic). Wyszukiwania przewodnika są obsługiwane (Basic?code=formulary-item&formulary=...&drug-tier=...&pharmacy-benefit-type=...&period=..., subject:MedicationKnowledge.code, InsurancePlan?formulary-coverage=..., coverage-type, MedicationKnowledge?code=...&doseform=...) z _include=Basic:subject, Basic:formulary i InsurancePlan:formulary-coverage. Jest to publiczne, bez poświadczeń, tak jak wymaga tego CMS od formularza płatnika: jest on obsługiwany ze sklepu własnego, w pamięci, który zawiera tylko formularz, więc nie może dotrzeć do rekordu pacjenta. Jest tylko do odczytu. Wykluczony lek nie jest publikowany, ponieważ interfejs API wyświetla, co formularz obejmuje; RTPB i ePA nadal odpowiadają na niego jako nieobjęte. Weryfikowany za pomocą walidatora HL7 FHIR wobec pakietu przewodnika 2.1.0 z sprawdzoną terminologią: każdy zasób wygenerowany z przykładu nie ma błędów.

16.8.2 Real-Time Prescription Benefit

POST /ncpdp/rtpb przyjmuje RTPBRequest (NCPDP RTPB v13) z tokenem API roli operatora i odpowiada RTPBResponse z formularza: statusu objęcia ubezpieczeniem, statusu formularza, szacowanego udziału członka i planu oraz ograniczeń objęcia ubezpieczeniem, z maksymalnie pięcioma objętymi alternatywami wycenianymi w ten sam sposób. Kody ograniczeń i status, do którego każdy z nich się odnosi, są zgodne z publicznymi zaleceniami wdrożeniowymi NCPDP dla RTPB: 75 wymagana autoryzacja, 608 terapia stopniowa, 76 przekroczone limity planu, 7X dni dostawy przekraczającej limit planu (np. lek nie dostępny pocztą), 70 nie objęty, wszystkie *z objęciem i ograniczeniami* (CR) z wyjątkiem 70 (NC). Członek z zatwierdzoną autoryzacją w pliku otrzymuje CC i AB8, zgodnie z wytycznymi Surescripts, aby uniknąć ponownego pytania lekarza. Żądanie, które nie może być wycenione, jest oznaczone jako NotProcessed z kodem odrzucenia NCPDP: 52 dla członka nie znalezionego, E7 i 19 dla brakującej ilości lub dni dostawy. Korzyść apteczna jest odczytywana z żądania: wypełnienie powyżej 34 dni jest uważane za trzymiesięczną dostawę, a typ apteki M jest uważany za zamówienie pocztowe.

16.8.3 Elektroniczna uprzednia autoryzacja (NCPDP SCRIPT)

POST /ncpdp/script przyjmuje PAInitiationRequest, PARequest, PAAppealRequest i PACancelRequest z tokenem API roli operatora i odpowiada na każde z nich odpowiedzią:

Zestaw pytań jest kwestionariuszem FHIR leku z magazynu FHIR, tym samym, który wypełnia DTR: wartość logiczna staje się wyborem tak/nie, wybór staje się wyborem, liczba staje się liczbą, data staje się datą, a wszystko inne staje się tekstem dowolnym; grupy są spłaszczane w kolejności, a enableWhen nie jest przenoszony, ponieważ SCRIPT gałęzi się według wyboru, a nie według warunku. Lek bez kwestionariusza jest pytany o trzy pytania tekstowe: rozpoznanie, co było próbowane i dlaczego ten lek. PARequest staje się żądaniem Da Vinci PAS: Claim dla leku (RxNorm i NDC), MedicationRequest, o który się prosi, pacjent, lekarz, płatnik i ubezpieczenie, oraz odpowiedzi jako QuestionnaireResponse, z załącznikami jako DocumentReference. Następnie jest podejmowana decyzja, tak jak w przypadku każdej autoryzacji wstępnej na tym serwerze: plik reguł, usługa decyzyjna (-pas-decider-url), lub kolejka recenzentów, gdzie jest oznaczony jako Lek i zatrzymany do ram czasowych leku. Usługa decyzyjna widzi żądanie leku dokładnie tak, jak widzi je klient PAS z systemu EHR. Zalecamy Vaglio, silnik decyzyjny BioDream (PolyForm Shield), który ma polityki lekowe ze stopniową terapią; silnik własny płatnika jest podłączany przez tę samą -pas-decider-url, a nie jest potrzebny dla pliku reguł i recenzentów do podjęcia decyzji.

Decyzja podjęta po odpowiedzi na żądanie (recenzenta, apelacji) jest wysyłana do lekarza jako niespodziewana PAResponse lub PAAppealResponse, przekierowana do kanału o nazwie -epa-reply-channel, który dostarcza ją do sieci. Bez niego lub gdy dostarczenie nie powiedzie się, przypadek stwierdza, że lekarz nie został poinformowany, a ekran wysyła ją ponownie.

Płatnicy › Leki › Autoryzacja wstępna wysyła wiadomości, które system lekarza wysyła do własnego punktu końcowego serwera (rozpoczęcie, odpowiedź na pytania, wyświetlenie decyzji), wyświetla każdy przypadek z tym, co lekarz został poinformowany, oraz wyświetla dane lekowe, które proponuje CMS-0062-P: zatwierdzone, odrzucone i oczekujące, odwołane i zatwierdzone lub odrzucone w odwołaniu, średni i medianowy czas w godzinach od żądania do decyzji oraz ile z nich zostało podjętych z opóźnieniem. Leki refundowane z korzyści medycznej za pomocą PAS (kod HCPCS J z MedicationRequest lub przedmiot zakodowany w RxNorm lub NDC) są również liczone jako leki w danych PAS.

To, na czym polega, wyrażone w prosty sposób. Schematy i przewodniki wdrożeniowe NCPDP są objęte licencją. Nazwy elementów i ich kolejność są zgodne z publicznymi przewodnikami towarzyszącymi Surescripts ePA i RTPB oraz ich przykładami, a także z publicznymi zaleceniami wdrożeniowymi NCPDP dla RTPB. Dwa elementy, których publiczne materiały nigdy nie pokazują, są zapisywane w wzorcu SCRIPT stosowanym gdzie indziej i powinny być sprawdzone przeciwko objętej licencją kopii przed certyfikacją: Closed/ReasonCode i Denied/DenialReason. Żadna wiadomość nie została sprawdzona przeciwko XSD NCPDP lub certyfikacji sieci. Plik Formularza i Korzyści NCPDP nie jest produkowany: jego pełny układ jest w objętej licencją przewodniku NCPDP, a częściowy plik zostanie odrzucony przez sieć, która go ładuje.

16.9 Co zostało sprawdzone i przeciwko czemu

Wyniki CARIN i PDex zostały zwalidowane z oficjalnym walidatorem FHIR, załadowanym z opublikowanymi pakietami (hl7.fhir.us.carin-bb#2.2.0, hl7.fhir.us.davinci-pdex#2.2.0): profesjonalne, szpitalne i ambulatoryjne roszczenia oraz dwie decyzje PAS, bez błędów. Wejścia PDex były własnymi przykładami przewodnika PAS, a nie kształtami napisanymi tutaj, aby zgadzały się z konwerterem. Walidator znalazł pięć wad w pierwszym przebiegu — wśród nich, że CARIN wymaga wersji profilu w meta.profile i wersji systemu kodowania typu roszczenia na instytucjonalnych roszczeniach — i każda z nich jest naprawiona i objęta testem.

Budowanie tego ujawniło wadę starszą niż ono: magazyn FHIR upuszczał każdy element, którego jego wewnętrzny model nie deklarował, więc ExplanationOfBenefit tracił swoje elementy, diagnozy, rozstrzygnięcia i płatności po drodze. Magazyn teraz zachowuje wszystko, co niesie zasób, a test ładuje roszczenie CARIN przez serwer i odczytuje je z powrotem w całości.

Wyjście CRD - zaktualizowane zamówienie oraz odpowiedź CDS Hooks przeciwko własnemu modelowi logicznemu CRD - oraz wyjście pakietu DTR są walidowane w oficjalnym walidatorze HL7 przeciwko CRD 2.2.1 i DTR 2.2.0 bez błędów.

DTR tutaj jest stroną płatnika w wersji 2.2.0. $questionnaire-package pobiera kwestionariusze o podanych nazwach, te nazwane CRD na zamówieniu lub identyfikatorze asercji CRD zwróconym (context, podczas gdy ten sam proces obsługuje CRD), i zwraca każdy z nich jako pakiet z kwestionariuszem do wypełnienia, bibliotekami CQL i ich zależnościami. Zestawy wartości, których odpowiedzi używają, podróżują w pakiecie, gdy są ładowane (PUT /fhir/ValueSet/{id}), a $expand wyświetla ich kody. $log-questionnaire-errors zapisuje, co aplikacja DTR zgłasza do rejestru serwera.

Adaptacyjne kwestionariusze: napisz cały kwestionariusz raz, z rozszerzeniem SDC questionnaireAdaptive i enableWhen na pytaniach, które mają zastosowanie tylko czasem. Pakiet przekazuje aplikacji pusty szkielet, a każde wywołanie $next-question dodaje następne pytanie, które ma zastosowanie do odpowiedzi dotychczasowych, aż do momentu, gdy nie ma już nic do zapytania i odpowiedź jest oznaczona jako ukończona. Kolejność i gałęzie są własnymi regułami płatnika; pytania, które nie mają zastosowania, nigdy nie są wyświetlane.

Logowanie się jako klient: klienci DTR i PAS docierają do płatnika za pomocą usług Backend SMART - podpisanego JWT wymienionego na token w serwerze autoryzacji płatnika. Wskaż Perfuse na ten serwer za pomocą -smart-issuer (i -smart-jwks, jeśli jego adres nie rozwiązuje się z Perfuse), i przekaż -smart-backend-services, aby dokument odkrycia powiedział o tym. Suite DTR Inferno przechodzi tę drogą z Keycloak jako serwerem autoryzacji.

Perfuse może być również serwerem autoryzacji: serve -fhir -smart-clients clients.yaml wydaje tokeny Backend Services w /auth/token dla klientów wymienionych w pliku, każdy z kluczami publicznymi, których używa do podpisywania swoich oświadczeń, oraz zakresami systemu, które mogą być im przyznane, a punkt końcowy FHIR akceptuje je. Nie jest wymagany oddzielny serwer tożsamości dla klientów maszynowych płatnika.

Z -smart-users users.yaml użytkownicy i klinicyści logują się, aby autoryzować aplikacje, co jest wymagane przez Patient Access API: aplikacja wysyła osobę do /auth/authorize, osoba loguje się, klinicysta wybiera pacjenta, a obie strony widzą, o co aplikacja prosi, i mogą odznaczyć dowolne z tych elementów. Członek jest przydzielany tylko do swojej własnej dokumentacji, niezależnie od tego, o co aplikacja prosi. Każda osoba w pliku nazywa zasób FHIR, którym jest, Patient/… lub Practitioner/…, oraz hash hasła z perfuse smart hash; samo hasło nigdy nie jest zapisywane.

Ludzie mogą logować się za pomocą dostawcy tożsamości organizacji: -smart-oidc oidc.yaml określa dostawcę (wydawcę, identyfikator klienta i miejsce, w którym znajduje się sekret), a strona logowania oferuje „Zaloguj się za pomocą” obok hasła. Każda osoba jest połączona z podmiotem dostawcy, oidc_subject w pliku użytkowników, więc plik nadal decyduje, kto może autoryzować aplikacje i jaki zasób FHIR są; konto połączone z nikim jest odrzucane. Kody, tokeny odświeżania i unieważnienia są przechowywane w bazie danych, więc ponowne uruchomienie nie wyloguje nikogo.

Użytkownicy → Aplikacje SMART w konsoli wyświetla listę zarejestrowanych aplikacji i osób, oraz dodaje, edytuje i usuwa je. Każde zapisywanie jest sprawdzane tak, jak pliki są na starcie, zapisywane do nich i używane od razu. Aplikacja poufna zapisana bez sekretu otrzymuje jeden, wyświetlany raz; hasło jest ustawiane tam i nigdy nie jest ponownie wyświetlane. Usunięcie aplikacji lub osoby natychmiast zatrzymuje tokeny dostępu już wydane dla niej lub przyznane przez nich, a nie po ich wygaśnięciu, oraz tokeny odświeżania z nimi.

Zakresy mogą być drobnoziarniste, tak jak definiują je SMART App Launch 2 i US Core: patient/Observation.rs?category=laboratory odczytuje tylko te Obserwacje, które znalazłaby wyszukiwarka. Zatwierdzenie, które jest filtrowane dla typu, stosuje swój filtr do każdego wyszukiwania i każdego odczytu tego typu; niezatwierdzone dla typu lub dla * podnosi go. Filtrowanie, które nie może być odczytane, niczego nie przyznaje, zamiast wszystkiego.

16.10 Decyzje dotyczące wcześniejszych wniosków o autoryzację: PAS

serve -fhir -pas -crd-rules rules.yaml odpowiada na Da Vinci PAS 2.2.1 w POST /fhir/Claim/$submit i POST /fhir/Claim/$inquire. Decyzje pochodzą z tego samego pliku reguł, co odpowiedzi CRD, więc kolejność, w której klinicysta jest informowany o potrzebie autoryzacji, jest decydowana przez regułę, która tak powiedziała:

  - description: Physical therapy
    codes: ["PT"]                       # matched on the item's productOrService, then the code of the order it requests
    system: https://codesystem.x12.org/005010/1365
    covered: covered
    pa: auth-needed
    pa_decision: approve                # approve, deny or pend; empty: not-covered is denied, no-auth approved, the rest pended
    details:
      - {code: allowed-quantity, value: "6"}   # asked for more, it is certified for six (A6, with the authorised detail)
  - description: MRI
    codes: ["62"]
    pa_decision: approve
    pa_alternative: {system: "https://codesystem.x12.org/005010/1365", code: "4"}  # approved as an X-ray instead (an added item)
  - description: Surgery
    codes: ["2"]
    pa: auth-needed                     # pended for a reviewer, asking for:
    questionnaire: https://payer.example.org/Questionnaire/surgery   # a DTR questionnaire
    pa_attachments: ["18776-5"]         # and documents, by LOINC attachment code

Każdy element otrzymuje akcję przeglądu X12: A1 certyfikowany, A3 niecertyfikowany, A4 wstrzymany, A6 zmodyfikowany, C anulowany (typ certyfikacji 3). Linia, która nie nazwała żadnej usługi, nie jest decydowana, ale odpowiedzią z błędem (X12 901 AG, popraw i ponownie wyślij). Odpowiedź powtarza to, co powtarza odpowiedź 278 — numery śledzenia elementów, daty usług, daty spotkania, identyfikatory transmisji ze zmienionymi nadawcą i odbiorcą — i przyznaje każdej linii własny numer referencyjny administracyjny płatnika. Usługa, której nie nazwała żadna reguła, jest wstrzymana, nigdy nie zatwierdzona: decyzja, której nikt nie zapisał, jest decyzją dla osoby.

Wstrzymane wnioski oczekują na recenzenta, który odpowiada za pomocą POST /fhir/Claim/$decide:

{"resourceType": "Parameters", "parameter": [
  {"name": "claimResponse", "valueString": "<the ClaimResponse id>"},
  {"name": "decision", "valueCode": "approve"},
  {"name": "reason", "valueString": "Reviewed with the plan of care."},
  {"name": "reviewer", "valueString": "<the reviewer's NPI>"}]}

decision może być również modify: certyfikowany, ale nie tak, jak poproszono, z quantity (valueDecimal, jednostki certyfikowane) i/lub alternative (valueCoding, usługa zatwierdzona zamiast). Odpowiedź wtedy mówi A6 Zmodyfikowany, ze szczegółami certyfikacji lub alternatywą jako dodanym elementem, oraz numerem autoryzacji. item (valueInteger, wielokrotny) ogranicza decyzję do niektórych linii. Decyzja staje się nową wersją odpowiedzi, oznaczoną jako przeglądana przez osobę, oraz z -fhir-subscriptions jest dostarczana w temacie PAS (PASSubscriptionTopic, filtrowanym przez org-identifier, identyfikator organizacji wnioskującej) jako pełne wiązanie odpowiedzi PAS, w tej samej transakcji, która ją rejestruje. $inquire zwraca bieżącą odpowiedź na każdy wniosek, jaki dostawca złożył w sprawie tego członka; zapytanie innego dostawcy nie znajduje niczego. $decide wymaga zakresu zapisu; $inquire jest odczytem.

Wnioski i każda wersja ich odpowiedzi są przechowywane w pas_requests i pas_responses w bazie danych serwera.

16.10.1 Kolejka recenzenta

W konsoli internetowej Płatnicy → CMS-0057 → Kolejka recenzenta wyświetla listę wstrzymanych wniosków, które najwcześniej powinny być rozpatrzone: wniosek przyspieszony (Claim.priority stat) jest rozpatrywany w ciągu 72 godzin od jego przybycia, standardowy w ciągu 7 dni. Wybranie jednego z nich wyświetla członka, dostawcę, każdą usługę z jednostkami, o które poproszono, i stanem, o co odpowiedź poprosiła, oraz każdy dokument otrzymany dla niego, z dokumentami w postaci zwykłego tekstu wyświetlanymi w linii. Edytor rejestruje decyzję tam: zatwierdzenie, odrzucenie lub modyfikację (jednostki certyfikowane lub inna usługa zatwierdzona zamiast), z powodem i numerem NPI recenzenta. Modyfikacja musi certyfikować mniej jednostek, niż poproszono; tyle samo lub więcej jest zatwierdzeniem i jest odrzucane jako modyfikacja. Usługa zatwierdzona zamiast rozpoczyna się w systemie kodowania tej, o którą poproszono. Jest to ta sama decyzja, którą podejmuje $decide, więc subskrypcja dostawcy dostarcza ją. Odczyt wniosku i podjęcie decyzji są oba zapisywane w rejestrze audytu.

Monitor → Pulpity zespołowe → Autoryzacja wcześniej wyświetla, za ostatnie 30 dni, ile standardowych i przyspieszonych wniosków zostało rozpatrzonych w ramach czasowych CMS-0057, rozpatrzonych z opóźnieniem, wciąż oczekujących w czasie i spóźnionych teraz, z medianą czasu rozpatrywania, oraz jak usługi, o które poproszono, zostały odpowiedzi: zatwierdzone, zmodyfikowane, odrzucone lub wciąż wstrzymane. Te dwie kafelki są odczytywane z samych wniosków, więc nie są w eksporcie pulpitu Grafana, który mówi o tym w swoim opisie.

16.10.2 Otrzymywanie dokumentów, o które wnioskuje wniosek oczekujący

Odpowiedź wstrzymana prosi o dokumenty z zadaniem i jednym CommunicationRequest na dokument. Kwestionariusz jest wymagany zgodnie z opisem PAS: CommunicationRequest z jednym kodem LOINC 102089-0, pod numerem śledzenia linii, dla której jest (itemTraceNumber, który ClaimResponse powtarza; linia wysłana bez niego otrzymuje jeden). Ten numer śledzenia to kontekst DTR: $questionnaire-package z ustawionym tylko context zwraca kwestionariusz. Dostawca wysyła to, co zostało poproszone, z Da Vinci CDex $submit-attachment (POST /fhir/$submit-attachment): TrackingId jest własnym numerem śledzenia wniosku (pierwszym identyfikatorem ClaimResponse, który jest również identyfikatorem zadania), lub identyfikatorem CommunicationRequest, AttachTo jest preauthorization, a MemberId musi być członkiem wniosku. Każde załączniki DocumentReference lub QuestionnaireResponse są przechowywane z wnioskiem i wyświetlane jego recenzentowi; przychodzący dokument niczego nie decyduje.

16.10.3 Decyzja w systemie zarządzania wykorzystaniem X12

Większość płatników decyduje o uprzednich autoryzacjach w systemie UM, który mówi X12 278. Z -pas-278-url, Perfuse jest frontem FHIR tego systemu: każde $submit jest wysyłane jako jeden wniosek 278 (005010X217), każdy element jest zdarzeniem pacjenta. Każdy z nich zawiera to, co PAS nazywa dla niego: typ przeglądu (extension-serviceItemRequestType, UM01: usługi zdrowia, przyjęcia lub opieki specjalistycznej), typ certyfikacji (extension-certificationType, UM02), typ usługi, miejsce świadczenia usług (UM04), poziom usług (extension-levelOfServiceCode, UM06: wybór, pilny lub nagły; priorytet stat zastępuje pilny), data, daty przyjęcia i wypisu w przypadku przeglądu przyjęcia, diagnozy, świadczeniodawca, który wykona usługę, oraz procedura i ilość, jako usługa profesjonalna (SV1) lub, na roszczeniu instytucjonalnym, usługa szpitala (SV2). Kod akcji i numer autoryzacji odpowiedzi 278 stają się działaniem przeglądu elementu: zatwierdzone, w części lub zmodyfikowane, odrzucone, anulowane lub nierozpatrzone (wstrzymane do przeglądu, z powodami odrzucenia). Nie konsultuje się lokalnych zasad.

perfuse serve -fhir -pas -pas-278-url https://um.example/x12/278 -pas-278-receiver ACMEUM \
  -pas-278-token-env UM_TOKEN

System UM, który najpierw wstrzymuje, a potem decyduje, wysyła swoją późniejszą odpowiedź 278 do POST /fhir/Claim/$decide-278; każde zdarzenie jest dopasowane do swojego żądania przez numer śledzenia, który Perfuse wysłał, i jest decydowane tak, jakby $decide je decydował. Jeśli system UM nie może być dotknięty lub odpowiada czymś, co nie jest odpowiedzią 278, każdy element jest wstrzymany do recenzenta, a dostawca jest informowany tylko o tym; powód jest w logu serwera.

Zapytania, na które system UM odpowiada

Zapytanie $inquire dostawcy musi znaleźć autoryzację, niezależnie od tego, w jaki sposób została ona zażądana: faksem, przez portal płatnika, telefonicznie lub w 278 innym podmiocie, który ją wysłał. Perfuse przechowuje tylko te zapytania, które przyszły przez niego; system UM przechowuje je wszystkie. Dlatego też w przypadku systemu UM, który odpowiada w czasie rzeczywistym (każdy transport z wyjątkiem sftp), każde $inquire jest również wysyłane tam jako zapytanie 278 (005010X215: BHT02 28, członek, dostawca, numer autoryzacji z insurance.preAuthRef Claim, gdy jest dostępny, oraz daty zdarzeń z billablePeriod lub daty usług z pozycji, w przeciwnym razie rok po obu stronach od dziś). Każda autoryzacja, której odpowiedź nie zawiera Perfuse (dopasowana przez numery śledzenia, które wysłał i numery autoryzacji, które już podał), jest zwracana jako kolejny pakiet odpowiedzi na zapytanie o roszczenie: decyzja systemu UM dla każdej pozycji usługi, numer autoryzacji i okres, oraz uwaga, w której miejscu została znaleziona. Żadne roszczenie nie jest tworzone dla autoryzacji, której nikt nie złożył w FHIR: jego ClaimResponse.request zawiera powód braku danych, zgodnie z profilem PAS. Zapytanie odczytuje tylko; nic w rekordach Perfuse nie ulega zmianie. Jeśli system UM jest niedostępny lub odpowiada z TA1 lub 999, dostawca otrzymuje to, co Perfuse posiada, a stan łącza wskazuje, dlaczego.

Jak 278s docierają do systemu UM

Przewodnik połączeń systemu UM mówi, jak akceptuje 278s, a -pas-278-transport (Ustawienia, Płatnicy, Link zarządzania wykorzystaniem) postępuje zgodnie z tym:

Certyfikat klienta to -pas-278-cert i -pas-278-key; -pas-278-ca ufa własnej władzy certyfikacji płatnika. OAuth to -pas-278-oauth-token-url, -pas-278-oauth-client-id i sekret, pobrany za pomocą grantu client-credentials i przechowywany do minute przed wygaśnięciem. Hasła, tokeny i sekrety są zawsze nazwane przez zmienną środowiskową (-pas-278-password-env, -pas-278-token-env, -pas-278-oauth-secret-env, -pas-278-sftp-password-env), lub wpisane w ekranie ustawień, gdzie są przechowywane w pliku ustawień (dostępnym tylko dla konta serwera) i nigdy nie są ponownie wyświetlane.

UM_PASSWORD=... perfuse serve -fhir -pas -pas-278-transport core-soap \
  -pas-278-url https://um.example/CORE/RealTime -pas-278-receiver ACMEUM \
  -pas-278-user perfuse -pas-278-password-env UM_PASSWORD

Przez SFTP każde żądanie jest wstrzymane, aż do czasu otrzymania odpowiedzi: odpowiedź 278 decyduje o elementach, a Perfuse umieszcza 999 akceptujące w folderze nadawanym. Plik, którego nie można odczytać, pozostaje w folderze wejściowym dla osoby i jest ponownie oferowany podczas następnego odczytu.

Kiedy system UM nie może odczytać żądania

System UM, który nie może odczytać 278, odpowiada TA1 (kopertą) lub 999 (transakcją) zamiast decyzją. Perfuse odczytuje, co i jak się nazywa, odkłada każdy element („zarządzanie wykorzystaniem nie mogło odczytać wniosku”) i rejestruje to. Payer, CMS-0057, Kolejka recenzenta wyświetla link: co zostało wysłane w ciągu ostatnich siedmiu dni, każda wymiana według numeru kontrolnego, i co się z nią stało (odpowiedź; potwierdzenie, odpowiedź do przyjścia; odrzucona, z segmentem, elementem i kodem 999; nieosiągnięta). Każda wymiana ma swój własny numer kontrolny, jeden więcej niż poprzedni, który jest tym, co TA1 lub 999 nazywa, gdy odpowiada.

16.10.4 Decyzja na podstawie dowodów klinicznych, z usługą decyzyjną

Plik reguł decyduje o kodzie usługi: kod nie potrzebuje autoryzacji, nie jest objęty, lub jest przekazywany do recenzenta. Czy ten pacjent spełnia kryteria dla niego, jest to inne pytanie, na które odpowiedź jest udzielana na podstawie warunków, odpowiedzi kwestionariusza i dokumentów, które dostawca wysłał wraz z żądaniem. Z -pas-decider-url, każdy element, który reguły pozostawiają do recenzenta, jest najpierw przekazywany do usługi decyzyjnej, takiej jak Vaglio, która odczytuje ten sam pakiet żądania PAS za pośrednictwem opublikowanego pakietu pas Perfuse. Publiczny Vaglio, na wymyślonych żądaniach, działa obok instancji testowej Perfuse pod adresem https://vaglio.perfuse.health:8443 (zaloguj się jako demo, hasło try-vaglio-demo; może on spojrzeć na wszystko i niczego nie zmienić): każda decyzja tam ma swoje uzasadnienie, list w języku zwykłym i potwierdzenie, które każdy może sprawdzić.

perfuse serve -fhir -pas -crd-rules payer-rules.yaml -pas-decider-url https://vaglio.example/api/pas/decide \
  -pas-decider-token-env VAGLIO_TOKEN

Adres URL musi być https lub zwykłym http do tej maszyny (localhost, 127.0.0.1), ponieważ przenosi rekord pacjenta i token. Vaglio sam odpowiada tylko na https; gdy używa certyfikatu z własnej władzy, przekaż tę władzę za pomocą -pas-decider-ca DATA/tls/ca.crt (lub jakąkolwiek wewnętrzną władzę płatnika, z której pochodzi certyfikat usługi). Usługa otrzymuje pakiet żądania jako dostawca go wysłał, POST <url>?item=<sequence> (application/fhir+json), i odpowiada {"decision": "approve" | "deny" | "pend", "why": "...", "requested": ["..."]}, lub 404 gdy decyduje niczego dla tego elementu, co pozostawia odpowiedź reguł. why jest notatką procesu odpowiedzi i jest wymagana dla odmowy, która w przeciwnym razie jest wstrzymana; requested jest powiedziane dostawcy jako informacja, której potrzebuje wstrzymany wniosek. Wstrzymanie może również zawierać "questionnaire": "<canonical>" i "attachments": ["<LOINC>", ...], które są pytane w odpowiedzi CDex Task i CommunicationRequests obok dowolnego kwestionariusza DTR lub załączników, o które prosi reguła (kwestionariusz reguły wygrywa, ponieważ zadanie prosi o jeden; kod, który nie jest kształtem LOINC, jest odrzucany i zalogowany). Reguła, która zatwierdza lub odrzuca, jest polityką ubezpieczeniową płatnika i nie jest wysyłana do usługi. Awaria, limit czasu lub odpowiedź, która nie jest jedną z trzech decyzji, wstrzymuje element do recenzenta, z powodem w logu serwera: nic tutaj nie zmienia awarii w zatwierdzenie. Nie można go łączyć z -pas-278-url, gdzie system UM odpowiada na każdy element.

Porada przed wysłaniem. Z -crd-advisor-url obok -crd-rules, CRD również prosi usługę decyzyjną, co poprzednia autoryzacja wniosku dla każdego zamówienia, które jej potrzebuje, byłaby powiedziana, gdy rekord stoi, i pokazuje odpowiedź jako jedną więcej kartę: "Przed wysłaniem: wniosek o to wymaga: ...", lub "zostałby zatwierdzony", z tym, co jest jeszcze potrzebne, kwestionariuszem, który o to pyta, i tym, co by go zatwierdziło. Vaglio odpowiada na /api/pas/advise, z tym samym tokenem i władzą, co powyżej:

perfuse serve -fhir -pas -crd-rules payer-rules.yaml \
  -crd-advisor-url https://vaglio.example/api/pas/advise -crd-advisor-token-env VAGLIO_TOKEN

CRD wysyła POST <url> z {"service": {"system": "...", "code": "..."}, "resources": [ ... ]}, zasoby są przed-wyborem (pacjent jako pierwszy, pokrycie wykluczone), i czyta {"decides": true, "answer": "approve" | "pend" | "deny", "summary": "...", "missing": [...], "questionnaire": "...", "toApprove": [[...]], "policyTitle": "..."}. Jest to porada i nic nie zmienia: informacje o pokryciu, inne karty i decyzja PAS są tym, co mówią reguły. Czekaj najwyżej trzy sekundy, a brak odpowiedzi, awaria lub "decides": false pozostawia odpowiedź dokładnie taką, jaką jest bez niej. Perfuse nigdy nie potrzebuje usługi decyzyjnej.

Żądanie przenosi X-PAS-Request-Id, identyfikator, przez który odpowiedź jest znana. Usługa z własnymi recenzentami, która wstrzymuje element, może wysłać swoją decyzję później jako każdy recenzent: Claim/$decide z tym identyfikatorem jako claimResponse, sekwencją elementu i decyzją oraz powodem. Subskrypcja dostawcy dostarcza ją tak, jakby została zrobiona w kolejce recenzenta.

Subskrypcja z zawartością id-only mówi dostawcy, jaka odpowiedź się zmieniła, nie mówiąc, co to jest: focus powiadomienia jest Bundle/<id>. GET /fhir/Bundle/<id> zwraca najnowszy pakiet odpowiedzi PAS, GET /fhir/Bundle/<id>/_history/<n> wersję, którą powiadomienie wysłało, a GET /fhir/ClaimResponse/<id> samą ClaimResponse. Token związany z jednym pacjentem jest powiedziany, że nie istnieje, jak w przypadku każdego rekordu poza jego pacjentem.

ZWERYFIKOWANO z oficjalnym pakietem testowym Inferno PAS Server v2.2.1 (patrz weryfikacja). Nie wysłano, chociaż PAS oznacza je jako wymagane: ClaimResponse.adjudication z akcją przeglądu, ClaimResponse.extension:authorizedProvider oraz ClaimResponse.item.extension:communicatedDiagnosis, ponieważ rozszerzenia, których potrzebują, nie są dozwolone w tym miejscu przez ich własny kontekst w PAS 2.2.1, a walidator odrzuca odpowiedź zawierającą je; oraz request.extension:DataAbsentReason, ponieważ Perfuse zawsze wie o wniosku. 278s wysłane do systemu zarządzania wykorzystaniem (powyżej) są sprawdzane przeciwko własnym przykładom wniosków PAS 2.2.1, opublikowanym przykładom esMD 278 CMS i sprawdzarce 278 napisanej z publicznych przewodników towarzyszących, a każdy transport jest sprawdzany przeciwko systemowi zastępczemu UM napisanemu z zasad łączności CAQH (patrz weryfikacja); jeszcze nie przeciwko prawdziwemu systemowi UM lub domu clearingowego, i nie certyfikowany CORE. Niezaimplementowane: załączniki wysyłane z powrotem z CDex.

Plik reguł jest sprawdzany pod kątem własnych niezmienników CRD podczas ładowania: kwestionariusz wymaga dokumentacji, usługa, która nie jest objęta ubezpieczeniem, nie może wymagać autoryzacji, satisfied należy do jednego przypadku, a nie reguły, oraz wszystko, co warunkowe, musi podać powód.

Niezweryfikowane: eksporty i dopasowanie członków do implementacji innego płatnika, metryki w stosunku do opublikowanych danych płatnika oraz CRD w stosunku do klienta CDS Hooks rzeczywistego EHR.

16.11 Wysyłanie wniosków o uprzednią autoryzację do płatnika (dla dostawców)

Wszystko powyżej odpowiada na wnioski, jako płatnik. Strona dostawcy jest odwrotna: system EHR lub aplikacja DTR tworzy paczkę wniosku Da Vinci PAS, a coś musi ją wysłać do płatnika, zachować odpowiedź i ją przekazać. Miejsce docelowe pas robi to.

name: prior-auth-out
dataType: raw
source:
  type: http
  http:
    listen: 127.0.0.1:8095
    path: /pas
destinations:
  - name: acme-health
    type: pas
    pas:
      payer: https://pas.acme-health.example/fhir
      bearer_token: ${ACME_PAS_TOKEN}     # or auth: { type: client_credentials, token_url, client_id, client_secret }
      results_to: pas-answers             # optional: a channel that takes each answer back to the EHR

Każda wiadomość musi być pełną paczką wniosku PAS na kanale surowym. Perfuse publikuje ją bez zmian w {payer}/Claim/$submit: płatnik decyduje o wniosku wraz z pacjentem, ubezpieczeniem i wspierającymi zasobami w paczce, a wniosek odbudowany z podsumowania straciłby je. Poza tą maszyną adres płatnika musi być https.

Decyzja jest dostarczonym żądaniem, niezależnie od tego, co mówi. Akceptacja, odrzucenie i oczekiwanie są wszystkie rejestrowane i żadna z nich nie jest powtarzana, ponieważ powtarzanie odrzucenia skutkuje ponownym wysłaniem tego samego żądania. To, co powoduje niepowodzenie dostarczenia i jest powtarzane, jest płatnikiem, który nie podjął decyzji: status błędu, OperationOutcome (jego tekst jest błędem) lub ClaimResponse, którego wynik jest error. Decyzja jest odczytywana punkt po punkcie z kodów akcji przeglądu PAS (X12 306: A1 zatwierdzony, A2 częściowo, A3 odrzucony, A4 wstrzymany, A6 zmodyfikowany); odpowiedź bez kodu jest wyświetlana jako "brak kodu decyzji" zamiast być traktowana jako akceptacja. Odrzucenie bez powodu w żadnym miejscu jest odrzucane jako nie spełniające wymogów CMS-0057.

Odpowiedź płatnika jest odpowiedzią miejsca docelowego, więc Zbadaj odpowiedź może ją ocenić, a results_to przekazuje ją do innego kanału. Każdy wniosek jest wymieniony na CMS-0057, Wnioski wysłane do płatników: kiedy został wysłany, pacjent, usługa, decyzja i odniesienie płatnika (preAuthRef), które późniejsze zapytanie nazywa. Lista jest przechowywana w prior-auth.json obok bazy danych (maksymalnie 10 000 wniosków; najstarsze zdecydowane idą pierwsze, wniosek w zawieszeniu nigdy nie idzie), a każdy najemca widzi tylko swoje.

Weryfikowany względem implementacji referencyjnej płatnika HL7 Da Vinci PAS (obraz docker hlseven/davinci-prior-auth): wniosek wysłany przez uruchomiony kanał jest zawieszony przez niego z jego odniesieniem, a odpowiedź pojawia się na ekranie (zobacz weryfikację). Jeszcze nie wypróbowany względem płatnika produkcyjnego. Nie zbudowany: kontynuowanie wniosku w zawieszeniu za pomocą $inquire lub otrzymanie późniejszej odpowiedzi płatnika przez subskrypcję; kanał może to robić dzisiaj z miejscem docelowym http lub fhir.

16.12 Sieci wyrównane z CMS

Ramowy program interoperacyjności CMS (Ekosystem technologii zdrowia CMS) prosi sieci danych zdrowotnych o samo-potwierdzenie 26 kryteriów i umieszczenie na liście jako Sieci zgodne z CMS; EHR, dostawcy, płatnicy i aplikacje łączą się z nimi. Kryteria 13 do 16 obowiązują od 4 lipca 2026 r.: interfejsy API FHIR na US Core z pełnym CapabilityStatement i Bulk Data, dokumenty jako załączniki FHIR do czytania przez ludzi, powiadomienia o spotkaniach i wizytach za pomocą subskrypcji FHIR oraz lokalizator rekordu.

Administruj › Sieć zgodna z CMS wyświetla każde kryterium z tym, co Perfuse zapewnia dla niego, oraz stan tego serwera, odczytany z tego, co jest włączone tutaj:

Czworo, które obowiązują od tego serwera:

Ekran jest arkuszem do potwierdzenia, a nie certyfikatem: CMS przegląda sieci, które podejrzewa o nie spełnianie kryteriów, a własny tekst ramowego programu jest autorytatywny. Nie zbudowane dzisiaj: otwarte zapytania o lukę w jakości (kryterium 8), zapytanie płatnika o dane spotkania roszczenia (9), raportowanie metryk zapytań do katalogu dostawców krajowych (19), sprawdzanie dostawców w tym katalogu (6), odczytywanie praw kierowcy lub cyfrowych kart ubezpieczeniowych (3, 23) oraz egzekwowanie ogólnej polityki zgody na każde odczytanie (5). IAL2 identyfikacja tożsamości jest usługą tożsamości; Perfuse akceptuje tokeny wybranej przez Ciebie usługi.

17 Bezpieczeństwo

Perfuse obsługuje dane kliniczne. Ten rozdział opisuje, co robi w tym zakresie i co pozostawia Tobie.

17.1 Bezpieczeństwo transportu

TLS w interfejsie sieciowym jest konfigurowany z -tls-cert i -tls-key. Bez nich interfejs jest zwykłym HTTP, co jest akceptowalne na adresie pętli zwrotnej dla pierwszego spojrzenia i nigdzie indziej — przenosi poświadczenia i zawartość wiadomości, obie czytelne w sieci.

TLS w transporcie kanałów jest na poziomie źródła i miejsca docelowego, pod blokiem tls. Dostępne ustawienia są w odniesieniu do źródła i odniesieniu do miejsca docelowego.

insecure_skip_verify akceptuje każdy certyfikat. Istnieje, ponieważ systemy szpitalne rutynowo przedstawiają certyfikaty, które nie będą weryfikowane, a odmowa połączenia oznaczałaby odmowę integracji. Jest nazwany, aby być wyraźnym, a używanie go oznacza, że połączenie jest szyfrowane, ale nie uwierzytelnione — masz ochronę przed biernym przechwytywaniem i żadną przed serwerem pośrednim.

17.2 Uwierzytelnianie i role

Użytkownicy są przechowywani w bazie danych. Każdy z nich ma jedną z pięciu ról, a każda rola obejmuje wszystko, co zawarte w rolach powyżej niej:

Szósta rola, Platforma, należy do osoby, która zarządza współdzielonym serwerem: tworzy najemców i ustawia ich limity, oraz nie posiada kanałów własnych.

Monitor jest dla biura pomocy technicznej lub dla ekranu operacyjnego na ścianie: wszystko, co jest potrzebne do zobaczenia, że kanał przestał działać, oraz nic, co nie nazywa pacjenta. Widz może odczytywać zawartość wiadomości, co jest danymi klinicznymi; jest to rola o niskich uprawnieniach do *konfiguracji*, a nie do prywatności. Operator oddziela naprawę nieudanej dostawy w nocy od zmiany tego, co robi kanał: osoba, która ponownie wysyła, nie musi mieć możliwości przepisywania kanału.

17.2.1 Powtarzające się błędne hasła

Błędne hasła i nieudane logowania z użyciem klucza są liczone według adresu, z którego pochodzi połączenie, a po kilku w rzeczy ciągu ten adres musi czekać, zanim będzie mógł spróbować ponownie (odpowiedź to 429, z Retry-After). Konta nie są zamykane według nazwy, ponieważ pozwoliłoby to komukolwiek zablokować administratora celowo.

Adres jest własnym adresem połączenia, nigdy tym, który żądanie podaje w X-Forwarded-For, który nadawca pisze. Za reverse proxy na tej samej maszynie Perfuse używa ostatniej wpisu X-Forwarded-For zamiast, tego, który proxy dodał, aby każdy klient był nadal liczbą oddzielną. Proxy na innej maszynie dociera do Perfuse z jednego adresu, i wszyscy jego klienci dzielą jeden licznik: ograniczaj logowania w tym proxy.

17.2.2 Grupy kanałów

Osoba (lub token API) może być ograniczona do niektórych grup kanałów: wtedy widzi i wykonuje działania tylko na kanałach, których group jest jednym z ich własnych. Jest to rozwiązanie grupy szpitali na jednym serwerze, gdzie analitycy każdego obiektu opiekują się własnymi kanałami, a centralny zespół, bez ograniczeń, opiekuje się wszystkimi. Rhapsody nazywa to szafą.

Limit dotyczy wszędzie jednocześnie, ponieważ jest stosowany do żądania, a nie zapamiętany przez każdy ekran: lista kanałów, pulpit nawigacyjny i mapa przepływu, wiadomości i ich wyszukiwanie, liczby i wykresy, kolejka, alerty, metryki, certyfikaty, umowy i użycie zestawu kodów. Kanał spoza grupy osoby nie istnieje dla nich; pytanie o niego pod nazwą odpowiada *nie znaleziono*, więc jego nazwa nie jest potwierdzona. Kanał bez grupy jest widoczny tylko dla osób bez limitu.

Zapisywanie kanału zachowuje go wewnątrz grupy osoby: nie mogą utworzyć kanału w innej grupie ani przenieść go poza swoją własną. To, co każda placówka udostępnia - tabele kodów, biblioteki skryptów, decyzje o uprzedniej autoryzacji - mogą odczytywać, ale nie zmieniać. Dane serwerowe (uprzednia autoryzacja, użycie tokenów, tunele) są wyświetlane tylko osobom bez limitu, oraz metryki i alerty dotyczące całego serwera, a nie kanału.

Administrator ograniczony do grup jest własnym administratorem placówki. Zarządza ludźmi i tokenami swoich grup, uruchamia i zatrzymuje ich kanały oraz czyści ich kolejki. Koledze, którego dodaje, przydziela grupy, chyba że nazwie niektóre z nich, nie może dać grupy, której nie posiada, oraz nigdy nie widzi ani nie zmienia nikogo bez limitu. Wszystko inne, co może zrobić administrator, zmienia cały serwer - ustawienia, logowanie, ponowne uruchomienie, reguły alertów, marka, flota, serwer SMART - i jest mu odmówione.

Grupy są ustawiane w Użytkownicy (i dla tokenów w Tokeny), jako lista rozdzielona przecinkami. Każda zmiana jest rejestrowana w dzienniku aktywności i obowiązuje od następnego żądania osoby.

Inna rola w każdej grupie

Osoba może posiadać różne role w każdej ze swoich grup: lab=editor, adt w Użytkownicy edytuje kanały laboratorium i ma wybraną rolę obok niego - powiedzmy widza - w kanałach przyjęć. Widzi kanały obu grup na każdym ekranie. Zapisywanie, uruchamianie lub ponowne wysyłanie kanału w grupie, w której jego rola jest zbyt niska, jest odrzucane z rolą, którą posiada tam; nie udaje, że kanał jest nieobecny, ponieważ może go zobaczyć. Jego rola u góry ekranu jest najwyższą, którą posiada, co otwiera ekrany, które ta rola używa, oraz każda akcja na tych ekranach jest nadal zawężona do grup, w których ją posiada.

Tylko osoby ograniczone do grup kanałów mogą mieć jedną. Ktoś, kto widzi każdy kanał, ma jedną rolę, ponieważ "edytor kanałów laboratorium" dla osoby bez limitu byłby edytorem wszystkiego, co należy do żadnej grupy, oraz stron serwerowych. Administrator placówki może przydzielić rolę na grupę tylko w grupach, które administruje, oraz nigdy powyżej swojej własnej roli tam.

17.3 Kto może wywołać punkt końcowy FHIR

Punkt końcowy FHIR (serve -fhir) sprawdza jeden z dwóch rodzajów tokenów:

• Tokeny interfejsu API Perfuse, utworzone w Użytkownicy → Poświadczenia maszynowe lub za pomocą perfuse token create. Każdy z nich posiada rolę i może być ograniczony do grup FHIR. Jest to ustawienie domyślne, gdy nie skonfigurowano serwera autoryzacji SMART.
• Tokeny dostępu SMART, z własnego serwera autoryzacji Perfuse (-smart-clients) lub zewnętrznego (-smart-issuer). Każdy z nich posiada zakresy i punkt końcowy przechowuje każde żądanie do nich.

Po skonfigurowaniu SMART, akceptowane są tylko tokeny SMART, więc każdy wywołujący jest ograniczony do swoich zakresów. Token API ma rolę i nie ma zakresów: token widza może odczytać każdy rekord pacjenta. Płatnik, który włączył SMART, aby ograniczyć każdą aplikację do tego, co zostało jej przyznane, nie powinien mieć sposobu na dostęp, który nie jest ograniczony.

Niektóre strony wymagają obu - wewnętrznego kanału roszczeń, który posiada token API i nie ma klienta SMART, obok aplikacji członkowskich, które logują się za pomocą SMART. Dla nich Ustawienia → FHIR → Akceptuj tokeny interfejsu API Perfuse obok tokenów SMART (-fhir-api-tokens podczas uruchamiania) pozwala na tokeny API. Jest wyłączone domyślnie, obowiązuje od następnego żądania w obie strony i zmiana jest zapisywana w rejestrze audytowym. Token jest rozróżniany przez jego kształt: token SMART jest podpisanym JWT, a token API nigdy nie jest, więc jeden jest nigdy nie sprawdzany jako inny. Gdzie możesz, nadaj takiemu systemowi klienta usług backend SMART z tylko tymi zakresami systemu, których potrzebuje.

17.3.1 Punkt końcowy FHIR otwarty dla obcych

Publiczny serwer testowy wydaje poświadczenia, które mogą zapisywać, ponieważ testowanie upoważnienia wcześniej lub subskrypcji wymaga zapisów. Dwa limity uniemożliwiają jednej aplikacji psucie wszystkiego, oba dostępne pod Ustawienia → FHIR i oba wyłączone domyślnie:

• Zapisy na minutę z jednego klienta (-fhir-writes-per-minute): tworzenie, aktualizacja i usuwanie z jednego adresu klienta. Przekroczenie limitu powoduje odpowiedź 429 z Retry-After: 60. Odczyty i wyszukiwania, w tym wyszukiwania za pomocą POST, nigdy nie są liczone.
• Najwięcej przechowywanych zasobów (-fhir-max-resources): po przekroczeniu limitu nowe zasoby są odrzucane z kodem 507, podczas gdy aktualizacje i usuwania nadal działają.

Własny punkt końcowy szpitala nie potrzebuje żadnego z nich.

17.4 Agenci AI: serwer MCP

Z Ustawienia › Bezpieczeństwo › Agenci AI (MCP) włączone (lub serve -mcp), Perfuse obsługuje Model Context Protocol pod adresem /mcp, aby agenci AI, tacy jak Claude, ChatGPT lub asystenci IDE, mogli pytać o to, co się dzieje. Jest wyłączone domyślnie, a wyłączenie powoduje zatrzymanie każdego agenta podczas następnego połączenia.

Agent łączy się z tokenem interfejsu API z Administruj › Użytkownicy › Poświadczenia maszynowe jako token nośnik, nigdy z sesją przeglądarki osoby (co jest odrzucane, więc agent nigdy nie działa z pełnym dostępem osoby). Konfiguracja klienta wygląda następująco:

{ "mcpServers": { "perfuse": { "type": "http", "url": "https://perfuse.example/mcp",
    "headers": { "Authorization": "Bearer <token>" } } } }

Każdy narzędzie jest obsługiwane przez tę samą trasę lub wyszukiwanie FHIR, które wykorzystuje ekran osoby, wywoływane za pomocą tokenu agenta, więc rola tokenu, grupy kanałów i najemca decydują o tym, co widzi, dokładnie tak jak w konsoli; a fhir_search otrzymuje dostęp tokenu do punktu końcowego FHIR (który może odmówić tokenom API; patrz sekcja FHIR powyżej). Agentowi oferowane są tylko narzędzia, których może używać. Domyślnie jest to odczyt: narzędzie, które zmienia coś, wymaga również zakresu mcp:write tokenu („Pozwól agentowi AI działać z nim” podczas wydawania tokenu), więc token wydany dla agenta raportującego nie może być nakłoniony do działania przez podpowiedź. Odpowiedzi tokenu monitorującego mają usunięte treści wiadomości, niezależnie od tego, co zwraca trasa.

Każde połączenie jest w Activity jako mcp.tool z nazwą tokenu, narzędziem, jego argumentami i wynikiem (ok, refused, invalid, rate-limited lub status HTTP); mcp.connect rejestruje, który klient się połączył. Każdy token może wykonać 60 połączeń narzędzi na minutę (Połączenia narzędzi na minutę z jednego tokenu); powyżej tego limitu połączenie jest odpowiedzią z błędem, który agent może przeczytać, i nic nie jest robione. Żądanie ze strony przeglądarki na innym pochodzeniu jest odrzucane, co MCP prosi serwera, aby zatrzymać ponowne wiązanie DNS. Transport to Streamable HTTP MCP, odpowiedzi jako JSON bez strumienia zdarzeń; akceptowane są wersje protokołu 2025-06-18, 2025-03-26 i 2024-11-05. Wiadomości i zasoby FHIR zawierają dane pacjenta: odpowiedzi agenta idą do modelu, na którym działa, więc podaj token agentowi tylko wtedy, gdy ten model jest dozwolony do ich zobaczenia, i podaj mu najniższą rolę, która robi to.

17.5 Konto demonstracyjne

serve -demo-account demo:PASSWORD tworzy wspólnego użytkownika dla publicznego serwera demonstracyjnego, a strona logowania wyświetla nazwę użytkownika i hasło z przyciskiem, który loguje się przy ich użyciu. Konto jest przeglądającym, więc może przeglądać wszystko i niczego nie zmieniać. W przeciwieństwie do innego przeglądającego, może również otwierać ekrany administratorów (użytkownicy, tokeny maszyn, ustawienia, ochrona danych, równorzędni floty), tylko do odczytu: demonstracja jest oceniana przez swoje ekrany. Odczytuje je jak przeglądający kanały, z każdymi poświadczeniami wyświetlanymi jako ustawionymi lub nie, nigdy bez ich wartości, a każda zmiana jest odrzucana. Może również naciskać przyciski sprawdzające, które nie zmieniają niczego i nie docierają poza serwer: sprawdzanie skryptu i walidacja oraz parsowanie edytora kanału. Nie może zmieniać hasła ani dodawać passkey, ponieważ pierwszy odwiedzający, który to zrobi, zablokuje wszystkich po nich. Każdy start przywraca je jako przeglądającego z opublikowanym hasłem. Hasło musi mieć co najmniej 12 znaków, jak każde inne. Używaj go tylko na serwerze zawierającym dane testowe: każdy, kto czyta stronę logowania, może przeczytać każdą wiadomość na serwerze.

17.6 Audyt

Zmiany konfiguracji, logowania i dostępu do zawartości wiadomości są rejestrowane z informacjami o kim, czym i kiedy.

Rejestr audytu jest w tej samej bazie danych co wiadomości. Jest to wygodne i jest to ograniczenie: ktoś, kto może modyfikować bazę danych, może modyfikować rejestr audytu. Jeśli Twoje wymagania obejmują audyt niezmienny, rejestr musi być wysłany w miejscu tylko do dodawania, a własny wyjście rejestru Perfuse jest sposobem na to.

17.7 Tajemnice w konfiguracji

Hasła, kody i klucze pojawiają się w konfiguracji kanału, co oznacza, że są one w plikach YAML.

Dwie konsekwencje. Pliki wymagają uprawnień systemu plików, które odzwierciedlają ich zawartość, a jeśli są w kontroli wersji — co jest zalecane — repozytorium zawiera poświadczenia i musi być traktowane odpowiednio.

Gdzie wartość jest tajemnicą, interfejs wyświetla ją jako tajemnicę, a API nie zwraca jej po zapisaniu. To chroni ją przed odczytaniem przez kogoś lub przedostaniem się do zrzutu ekranu. Nie chroni jednak pliku.

17.8 Co jest w bazie danych

Sklep wiadomości przechowuje wiadomości w postaci otrzymanej, co w przypadku klinicznego kanału informacyjnego oznacza dane identyfikujące pacjenta. Powinien być on umieszczony na zaszyfrowanym nośniku, zabezpieczonym jako dane kliniczne z odpowiednim okresem przechowywania i kontrolą dostępu na poziomie systemu plików, a także za pośrednictwem ról Perfuse.

cleanup.periodDays ogranicza czas, przez jaki jest przechowywany. Zobacz sklep wiadomości w celu zrozumienia napięcia między tym a posiadaniem wystarczającej historii do rytmicznej alarmowania.

17.9 Ochrona danych (RODO i brytyjskie RODO)

Ekran Ochrona danych (Administruj, tylko administratorzy) odpowiada na żądania osoby zgodnie z RODO i brytyjskim RODO. Nie podejmuje żadnych decyzji w imieniu kontrolera: czy żądanie musi być spełnione, a czy ma zastosowanie wyjątek, jest decyzją kontrolera, zarejestrowaną wraz z żądaniem.

Znalezienie przechowywanych informacji. Osoba jest identyfikowana przez identyfikatory: system|value (numer NHS, numer MRN z jego władzą przydzielającą) lub sam numer. Z indeksem pacjenta te identyfikatory rozszerzają się na każdy numer każdego rekordu powiązanego z tą samą osobą, więc żądanie cytujące jeden numer szpitala znajduje rekordy zapisane pod innymi numerami. Zobacz, co jest przechowywane, a następnie wyszukuje każde miejsce przechowywania danych pacjentów:

Jeśli coś nie jest dostępne, podaje informację: ślady wysłane do kolektora (-trace-endpoint), log audytowy (zapisany: jest to zapis tego, kto co zrobił, w tym to żądanie), oraz kopie zapasowe.

Żądania. Żądanie jest rejestrowane z jego rodzajem (dostęp, Artykuł 15; przenośność, Artykuł 20; usunięcie, Artykuł 17; ograniczenie, Artykuł 18), kim jest osoba, której dotyczy, zgodnie z zapisami kontrolera, identyfikatorami oraz notatką (w jaki sposób potwierdzono tożsamość, rozszerzenie i jego powód). Jest ono wymagane w ciągu jednego miesiąca od otrzymania (Artykuł 12(3)); opóźnione żądanie jest wyświetlane na czerwono.

• Dostęp i przenośność: Pobierz kopię daje plik zip: każdą wiadomość, jak została odebrana, wraz z jej rekordem, każdy zasób FHIR z każdą zapisaną wersją, poprzednie żądania autoryzacji oraz ich odpowiedzi, oraz rekordy indeksu pacjenta, w formacie JSON na całej długości, z plikiem README, który wyjaśnia, co jest w każdej części. Oznacz jako odpowiedź zamyka ją.
• Usunięcie: drugi administrator zatwierdza je (osoba, która je zarejestrowała, nie może). Usuń teraz kasuje wszystko, co znaleziono: wiadomości w całości (rekord, treść, dostawy, identyfikatory, załączniki, których nie używa żadna inna wiadomość), dostawy w kolejce (nie są wysyłane), zasoby FHIR wraz z ich historią, poprzednie żądania autoryzacji wraz z odpowiedziami, załączniki oraz numery śledzenia, oraz osobę w indeksie pacjenta wraz z każdym powiązanym rekordem oraz jego historią (jedno zdarzenie rejestruje, że usunięcie miało miejsce i kto je wykonał).
• Ograniczenie: jest rejestrowane jako prawny zakaz, więc nic nie jest kasowane ani wygasa, dopóki trwa.
• Odmów zamyka żądanie z powodem, który musi być podany osobie.

Zamknięte żądanie zachowuje tylko ostatnie znaki numeru osoby: pozostaje jako zapis odpowiedzi bez powielania kopii. Każdy krok jest w logu audytowym z zamaskowanymi numerami.

Prawne zabezpieczenia. Zabezpieczenie określa osobę przez identyfikatory, z powodem oraz opcjonalną datą zakończenia. Dopóki jest w mocy, usunięcie jest odrzucane, a okno przechowywania sklepu wiadomości oszczędza wiadomości osoby (rekordy i treści) do momentu, gdy zabezpieczenie zostanie zniesione.

Kopie zapasowe i rejestr usunięć. Wykonana kopia zapasowa przed usunięciem nadal zawiera usunięte dane, aż do ich wygaśnięcia. Każde usunięcie jest zapisywane w rejestrze: kiedy, przez kogo, zatwierdzone przez kogo, ile danych zostało usuniętych z każdego sklepu oraz identyfikatory osoby jako hashowane SHA-256 z solą zamiast w postaci jawnej. Po przywróceniu kopii zapasowej Ponownie zastosuj usunięcia haszuje identyfikatory przechowywane w przywróconych sklepach z każdą pozycją rejestru oraz kasuje każdą osobę wymienioną w rejestrze. Krótkie numery mogą być odnalezione z ich hashów, próbując każdej wartości, więc rejestr jest sam w sobie danymi osobowymi i jest przechowywany z ochroną bazy danych.

Przechowywanie. Ekran wyświetla, jak długo każdy rodzaj rekordu jest przechowywany i co go zmienia: rekordy wiadomości i ich treści według okien przechowywania, kolejka do momentu dostarczenia lub usunięcia, sklep FHIR, poprzednie żądania autoryzacji oraz indeks pacjenta do momentu usunięcia (rekordy kliniczne nie są kasowane według harmonogramu), log audytowy jest przechowywany.

Rejestr przetwarzania (Artykuł 30). Rejestr przetwarzania pobiera, jako Markdown lub CSV, to, co serwer wie o przetwarzaniu: kontroler, oficer ochrony danych oraz gdzie dane są przechowywane (Ustawienia → Dane → Ochrona danych), przechowywanie każdego rodzaju rekordu oraz jedna aktywność przetwarzania na kanał z tym, co jest otrzymywane, skąd, do jakich miejsc przeznaczenia oraz hostów, do których są wysyłane. Cele, podstawy prawne oraz kategorie podmiotu danych są pozostawione do wypełnienia przez kontrolera i tak wskazują. Komórka CSV zaczynająca się od =, +, - lub @ jest zapisywana z poprzedzającym apostrofem, aby arkusz kalkulacyjny nie wykonywał jej.

Gdzie dane są przechowywane. Gdzie dane są przechowywane (Ustawienia → Dane → Ochrona danych) stwierdza, w słowach, które regulator może sprawdzić, gdzie serwer, jego baza danych oraz kopie zapasowe są uruchomione; ekran Ochrony danych oraz rekord pokazują to. Wersja robocza umowy o przetwarzaniu danych dla organizacji BioDream jest w docs/legal/dpa-template.md; jest to wersja robocza dla prawnika, a nie porada prawna.

Interfejs API to /api/privacy (podsumowanie), /api/privacy/find, /api/privacy/requests (i /{id}/approve, /{id}/export, /{id}/erase, /{id}/close), /api/privacy/holds, /api/privacy/reapply oraz /api/privacy/register.

17.10 Najemcy

Najemca jest granicą izolacji: kanały, wiadomości, użytkownicy i ustawienia należą do jednego, a nic nie przekracza.

Istnieje to dla dostawcy usług, który uruchamia kanały dla kilku praktyk. Nie używaj go do oddzielenia departamentów w ramach jednej organizacji, które muszą widzieć nawzajem swoje dane: izolacja jest realna i nie ma widoku między najemcami. Do tego celu użyj grup kanałów (powyżej), które dzielą ludzi jednej organizacji, pozwalając centralnej grupie zobaczyć wszystko.

17.10.1 Ograniczenia

Operator platformy ustawia limity dla każdego najemcy w Tenants, aby jeden klient nie mógł zagłuszyć resztę współdzielonego serwera. Pozostaw limit pusty, jeśli nie jest wymagany.

• Kanały: ile kanałów najemca może mieć. Tworzenie jednego więcej jest odrzucane, z liczbą i limitem.
• Wiadomości na minutę: ile wiadomości jego kanały razem mogą otrzymać w minutę.
• Przechowywanie: ile przechowywanej zawartości wiadomości może on przechowywać, w megabajtach.

Żaden z nich nie traci wiadomości. Przy przekroczeniu limitu lub limitu przechowywania otrzymana wiadomość jest odmawiana w taki sam sposób, jak zajęty odbiorca odmawia wiadomości, zanim cokolwiek zostanie zapisane lub dostarczone: MLLP nie otrzymuje potwierdzenia (nie jest to odrzucenie, które niektórzy nadawcy traktują jako "nie wysyłaj ponownie"), HTTP otrzymuje 429 z Retry-After, SOAP otrzymuje 503, DICOM otrzymuje status, który można ponowić, a kolejka, wiadro lub plik pozostają tam, gdzie były. Nadawca wysyła ponownie, jak każdy silnik integracji i EHR. Nic, co już jest zapisane, nie jest kasowane, aby zrobić miejsce. Zwiększony limit obowiązuje w ciągu minuty, a każda zmiana limitów jest rejestrowana w logu aktywności.

17.11 Dane testowe

Wygenerowane wiadomości opisane w testing istnieją częściowo jako kontrola prywatności. Odtwarzanie problemu w innym miejscu, wysłanie przykładu do dostawcy lub zaludnienie środowiska testowego to wszystko rzeczy, które w przeciwnym razie są wykonywane z użyciem rzeczywistych wiadomości.

Wynik generatora nie zawiera danych pacjentów dzięki konstrukcji, a nie dzięki redagowaniu. Preferuj go zamiast ręcznie wyłuskanych prawdziwych wiadomości, co jest procesem, który można wykonać niekompletnie i zwykle jest.

17.12 Logowanie jednokrotne

Trzy mechanizmy i konta lokalne obok wszystkich z nich.

OpenID Connect (-oidc), katalog przez LDAP (-ldap) i SAML 2.0 (-saml). Każdy z nich jest konfigurowany z Administruj → Logowanie i zapisywany do pliku, którego nazwę określa flaga, więc ekran i plik są dwoma widokami jednej rzeczy, a nie dwoma miejscami, które trzeba utrzymywać w zgodzie.

Konta lokalne są zawsze dostępne i nie mogą być wyłączone. To jest celowe: silnik integracji na miejscu, którego jedynym sposobem wejścia jest dostawca tożsamości, staje się niedostępny dokładnie wtedy, gdy dostawca tożsamości jest niedostępny, a interfejs kliniczny nie jest dobrym miejscem, aby się o tym dowiedzieć. Ekran logowania informuje, ile istnieje lokalnych administratorów, zanim zachęci do polegania na czymś innym.

17.12.1 Co decyduje o mapowaniu grupy

Wszystkie trzy mapują grupy z katalogu na role Perfuse, a ktoś w grupach pasujących do więcej niż jednej otrzymuje najbardziej uprzywilejowaną. To jest jedyna bezpieczna strona do rozwiązania — alternatywa to osoba tracąca dostęp, do którego ma prawo, ponieważ jest również w mniejszej grupie.

Można udzielić którejkolwiek z sześciu ról: monitor, widz, operator, edytor, administrator i platforma.

Grupa może być również ograniczona do niektórych grup kanałów, w drugim polu wiersza (channel_groups w pliku). Gdy jakakolwiek grupa nazwie jedną, każde logowanie ustawia kanały grupy osoby z grup, które przyznały jej rolę: osoba w grupie, która edytuje kanały laboratorium i w innej, która wyświetla każdy kanał, jest edytorem kanałów laboratorium i niczym więcej. Najwyższa rola nigdy nie jest łączona z najszerszym zasięgiem, ponieważ żadna grupa nie przyznaje tego. Grupa z pustym polem daje każdy kanał. Dopóki żadna grupa nie nazwie żadnego, logowanie pozostawia kanały grupy tak, jak je ustawił administrator w Użytkownicy.

Gdy każda grupa, której osoba odpowiada, nazwie kanały grupy, każda grupa kanałów otrzymuje najwyższą rolę wśród grup, które ją nazwały: z Lab-Interfaces (edytor, laboratorium) i Clinical-IT (widz, laboratorium i adt), osoba edytuje kanały laboratorium i wyświetla kanały przyjęć, jakby były ustawione ręcznie. Gdy jedna z grup daje każdy kanał, nie ma listy, która mogłaby przechowywać rolę na grupę, i stosuje się powyższa reguła.

roles:
  editor: [Lab-Interfaces]
  operator: [Night-Desk]
  viewer: [Clinical-IT]
  channel_groups:
    Lab-Interfaces: [lab, pathology]
    Night-Desk: [adt]

To jest plik OpenID Connect i SAML. Plik katalogu mapuje każdą grupę na jedną rolę (roles: {Lab-Interfaces: editor}), a channel_groups znajduje się obok roles.

Mapowanie, które nie przyznaje nic nikomu, jest odrzucane, a nie zapisywane. Konfiguracja, która uwierzytelnia ludzi i odsyła ich wszystkich, wygląda tak samo jak uszkodzony produkt z zewnątrz: pełna podróż zostaje ukończona, a wszyscy są odrzuceni bez wyjaśnienia, dlaczego.

Tworzenie konta podczas pierwszego logowania jest wyłączone domyślnie. Z wyłączoną opcją, ktoś musi istnieć w Perfuse, zanim będzie mógł się zalogować, więc katalog decyduje, kim są, a Perfuse decyduje, kto ma dostęp.

17.12.2 SAML, konkretnie

Części, które warto wiedzieć przed skonfigurowaniem:

• Tylko certyfikat, który skonfigurujesz, jest zaufany. Certyfikat przenoszony wewnątrz odpowiedzi nigdy nie jest używany. Atakujący, który może wysłać dokument, może również umieścić swój własny certyfikat w nim, a weryfikator, który go odczytuje, jest kimś, do kogo każdy może się uwierzytelnić jako ktokolwiek.
• Odpowiedź musi odpowiedzieć na logowanie, które rozpoczęło się na tym serwerze. Perfuse pamięta żądanie, które wysłał, i odrzuca odpowiedź, która nazywa coś innego lub nazywa żądanie, które już zostało odpowiedziane. Bez tego sprawdzenia ważna odpowiedź jest tokenem nośnym dla osoby, która ją posiada: ktoś loguje się jako on sam, zachowuje odpowiedź i umieszcza ją w Twojej przeglądarce, i wtedy jesteś wewnątrz jego konta z rejestrem inspekcji, który rejestruje jego imię.
• Logowania rozpoczęte u dostawcy tożsamości są więc wyłączone domyślnie. Włącz *Akceptuj logowania rozpoczęte u dostawcy tożsamości* tylko wtedy, gdy potrzebujesz kafelka portalu, i wiedząc, że to jest to, co umożliwia powyższe.
• Atrybut grupy nie ma domyślnej wartości i jest wymagany. Entra wysyła groups, Okta wysyła to, co zostało skonfigurowane dla aplikacji, ADFS wysyła adres URI roszczenia. Przypuszczenie mogłoby spowodować logowanie, które działa i nie przyznaje nic nikomu. Jeśli logowanie zostanie odrzucone z powodu braku roli, log serwera nazywa atrybuty, które dotarły — co zwykle jest całą odpowiedzią.
• Adres URL odpowiedzi musi dokładnie odpowiadać temu, który jest zarejestrowany u dostawcy. Odpowiedź mówi, gdzie została przeznaczona, a odpowiedź skierowana w inne miejsce jest odrzucana, ponieważ zaakceptowanie jej oznaczałoby zaakceptowanie odpowiedzi przeznaczonej dla innego serwisu.

17.12.3 Co każdy dostawca wysyła

Atrybut grupy jest miejscem, w którym logowania idą nie tak, a trzej najczęscy dostawcy każdy nazywają go inaczej.

Adres URI roszczenia może być wprowadzony przez jego ostatni segment: wpisanie groups znajduje http://schemas.microsoft.com/ws/2008/06/identity/claims/groups. Nazwa, która kończy się tylko słowem, nie pasuje — excluded_groups nie jest groups.

Członkostwo w grupie, które przychodzi jako jedna wartość oddzielona przecinkami, jest traktowane jako pojedyncza nazwa grupy i nie pasuje do niczego. To jest poprawna interpretacja standardu, a dzielenie na przecinki oznaczałoby, że grupa, która słusznie zawiera jedną, staje się cichaczem dwiema. Jeśli Twój dostawca wysyła to, zmień to tam.

Test na ekranie logowania sprawdza wszystko, co można sprawdzić bez osoby: ustawienia, certyfikat i czy można zbudować żądanie logowania. Mówi wyraźnie, że nie może udowodnić, że ktoś może się zalogować, ponieważ wymaga to prawdziwego twierdzenia o prawdziwej osobie, a jedynym sposobem, aby to uzyskać, jest to, aby próbowali.

17.13 Konta udostępnione przez dostawcę tożsamości: SCIM

Z -scim (Ustawienia → Logowanie → Konta automatyczne), dostawca tożsamości, taki jak Okta, Microsoft Entra ID lub Google Workspace, tworzy, aktualizuje i usuwa konta Perfuse samodzielnie pod adresem /scim/v2/Users, dzięki czemu osoba, która opuszcza organizację, traci dostęp, gdy konto katalogowe jest wyłączone, a nie gdy ktoś sobie o tym przypomni. Dostawca uwierzytelnia się za pomocą tokenu API z rolą administratora, utworzonego w Użytkownicy → Poświadczenia maszynowe, wysyłanego jako token nośnikowy.

• Wyłączenie konta kończy jego sesje natychmiast, a serwer sprawdza, czy nie przetrwała żadna przed odpowiedzią. Dostawca nigdy nie jest informowany, że konto zostało wyłączone, gdy tak nie było, ponieważ dostawca nie powtarza tego, co zostało pomyślnie wykonane.
• Usuwanie wyłącza najpierw, a potem kasuje, więc awaria w połowie pozostawia konto, na które nikt nie może się zalogować. Zachowuje się historię audytu usuniętego konta.
• Rola pochodzi z grup lub ról osoby, dopasowanych według nazwy: grupa, której nazwa zawiera *admin*, *editor*, *operator*, *widz* (lub *read-only*) lub *monitor*, przyznaje tę rolę, więc APP-Perfuse-Editor i Perfuse Operators działają tak, jak są nazwane. Wszystko inne otrzymuje -scim-default-role, widz, chyba że ustawiono inaczej. Platforma nigdy nie może być przyznana w ten sposób.
• Brak haseł. Konto utworzone przez SCIM loguje się za pośrednictwem dostawcy tożsamości; drugie hasło, o którym nikt w górę nie wie, przetrwałoby wyłączenie tam.
• /scim/v2/ServiceProviderConfig mówi, co jest obsługiwane: tworzenie, odczyt, zastępowanie, łatanie i kasowanie Użytkowników oraz filtry do 200 wyników. Operacje wsadowe, sortowanie i ETagi nie są obsługiwane.

17.14 Co Perfuse nie robi

Nie szyfruje bazy danych w stanie spoczynku. Użyj szyfrowania systemu plików lub woluminu.

Nie zarządza własnymi certyfikatami ani ich odnawianiem. Wskaż pliki i zarządzaj nimi za pomocą tego, co już używasz.

SAML został zweryfikowany z dwoma niezależnymi dostawcami, każdym z prawdziwym logowaniem przeglądarki, prawdziwym potwierdzeniem i prawdziwą sesją: Keycloak 26 i Microsoft Entra. Dwa sprawy są ważniejsze niż dwa razy tyle, co jedna, ponieważ te dwie nie zgadzają się w sposób, który okazał się istotny — Keycloak zapisuje swoje potwierdzenie z prefiksami przestrzeni nazw, a Entra zapisuje te same elementy bez nich, a jednym defektem w tej dziedzinie było obsługiwanie prefiksów.

Zacznij od odczytania metadanych dostawcy. Ustawienia, a następnie Logowanie, a następnie karta SAML: podaj adres URL metadanych lub wklej dokument, a adres logowania i certyfikat podpisywania zostaną wypełnione automatycznie. Każdy dostawca SAML publikuje jeden z nich — Okta, Entra, AWS IAM Identity Center, Keycloak, ADFS — i jest to różnica między konfigurowaniem dostawcy a przepisywaniem go. Robienie tego ręcznie oznacza znalezienie certyfikatu wewnątrz XML, usunięcie znaków nowej linii z base64 i otoczenie go nagłówkami PEM, gdzie jeden zbędny znak spacji powoduje błąd podpisu, który nie mówi nic o formacie.

To, co wraca, jest opisane, a nie zrzucane: podmiot każdego certyfikatu, wygaśnięcie i odcisk palca SHA-256, aby można było sprawdzić go w porównaniu z tym, co pokazuje konsola samego dostawcy. Wygasły certyfikat jest nazwany wygasłym, a nie pozostawiony jako data do porównania oczami. Nic nie jest zapisywane przez odczyt — zastosowanie go do formularza jest oddzielnym kliknięciem, ponieważ dokument, który ktoś wkleił, nie jest jeszcze decyzją o tym, co zaufać.

Adres URL metadanych jest pobierany tylko przez https, a adres jest sprawdzany w stosunku do tej samej polityki, która zarządza miejscami przeznaczenia kanału, więc nie można go użyć do odczytania poświadczeń instancji chmury przez serwer. Przekierowania nie są śledzone, ponieważ dozwolony adres przekierowujący do zablokowanego przejdzie prosto obok tego sprawdzenia.

Jeśli konfigurujesz Entra, pięć rzeczy nie będzie odpowiadać temu, co pokazują przykłady. Nie wysyła żadnego roszczenia e-mail. Jego NameID jest nieprzezroczystym identyfikatorem, a nie adresem. Nie wysyła żadnego roszczenia grupy, chyba że aplikacja jest jawnie skonfigurowana do emitowania jednego, więc mapowanie roli napisane przeciwko grupom odmawia każdego logowania. Gdy grupy są emitowane, są one identyfikatorami GUID obiektów, a nie nazwami, chyba że twoja dzierżawa synchronizuje z lokalnym Active Directory. A nazwy jego roszczeń mieszczą się pod schemas.microsoft.com/identity, gdzie większość dokumentacji pokazuje schemas.xmlsoap.org. Perfuse obsługuje wszystkie pięć; są wymienione, ponieważ pierwsze cztery wyglądałyby inaczej na błędy w Perfuse, gdy są Entra.

Ta różnica nie jest teoretyczna tutaj. Pierwsze prawdziwe potwierdzenie Keycloak nie powiodło się, ponieważ kanoniczna forma, którą obejmuje podpis, była obliczana z pominięciem prefiksów przestrzeni nazw. Żadny prawdziwy dostawca tożsamości nie mógłby podpisać nikogo, a pięć testów kanoniczacji pakietu przeszło przez cały czas — każdy z nich został podpisany i zweryfikowany za pomocą tego samego kodu, więc udowodniły tylko, że zgadza się ze sobą. Jeśli jesteś pierwszym, który wskazuje innego dostawcę na to, spodziewaj się znaleźć coś, a log serwera nazwie etap, który nie powiódł się.

18 Operacje

18.1 Wdrożenie

Jeden plik wykonywalny i dwie ścieżki: katalog plików kanału i plik bazy danych. Nie ma wymaganego serwera aplikacji, oddzielnego warstwy sieci web i brokera wiadomości.

perfuse serve -channels ./channels -db ./perfuse.db -addr 0.0.0.0:8443 \
  -tls-cert ./cert.pem -tls-key ./key.pem

Uruchom go pod nadzorem usług hosta — systemd, launchd, środowisko uruchomieniowe kontenera. Oczekuje, że zostanie ponownie uruchomiony, jeśli wyjdzie.

18.2 Gdzie mogą iść dane (rezydencja danych)

serve -residency (Ustawienia → Dane → Gdzie mogą być wysyłane dane) nazwa chmur, do których serwer może wysyłać lub odczytywać dane: obszary (eea, uk, ch) i kodów regionów (eu-central-1, uksouth, europe-west2), oddzielone przecinkami. eea to regiony AWS, Azure i Google Cloud w Europejskim Obszarze Gospodarczym (Frankfurt, Irlandia, Paryż, Sztokholm, Mediolan, Hiszpania; Holandia, Niemcy, Francja, Szwecja, Norwegia, Włochy, Hiszpania; Belgia, Holandia, Niemcy, Włochy, Francja, Finlandia, Hiszpania, Polska), uk to regiony w Wielkiej Brytanii, ch to regiony w Szwajcarii.

Po ustawieniu kanał jest odrzucany, gdy jest zapisywany i gdy jest ładowany, jeśli łącznik nazwie region spoza listy: źródło lub miejsce docelowe S3, SQS lub SNS region (lub jego endpoint, gdy jest to nazwa hosta AWS), lub każde miejsce docelowe, którego adres jest nazwą hosta AWS zawierającą region (sqs.us-east-1.amazonaws.com, adres URL API Gateway). Serwer odmawia uruchomienia z kolektorem śladów lub webhookiem alertu w innym regionie. Łącznik wskazujący na host, który nie nazwał regionu (własny system szpitala, MinIO w sieci szpitala), nie jest oceniany: rekord przetwarzania na ekranie Ochrona danych wyświetla każdy host, do którego każdy kanał wysyła dane, do sprawdzenia przez kontrolera. Pulpit i ekran Ochrona danych mówią, gdzie mogą być wysyłane dane.

Hostowanie w UE i Wielkiej Brytanii. deploy/hosted zawiera OpenTofu (lub Terraform) dla jednego serwera hostowanego na organizację we Frankfurcie, Irlandii lub Londynie: serwer, jego bazę danych PostgreSQL i kopie zapasowe, bucket kopii zapasowych, logi i rekordy sesji wsparcia, wszystko zaszyfrowane kluczem w Regionie, nic nie jest replikowane do innego Regionu, wsparcie tylko za pośrednictwem Menedżera sesji i Perfuse uruchomiony z -residency. Jego README mówi, co buduje, co nie jest objęte, co zostało zweryfikowane (zweryfikowane i zaplanowane przeciwko prawdziwemu koncie; jeszcze nie zastosowane) i jakie są koszty według ceny katalogowej w każdym Regionie.

18.3 Konfiguracja jako pliki

Kanały są plikami, co oznacza, że mogą być w kontroli wersji, przeglądane przed wdrożeniem i porównywane po incydencie.

Pliki są odczytywane ponownie bez restartu. Plik, który nie jest w stanie sparsować, jest zgłaszany, a poprzednio załadowana wersja nadal działa, więc błąd składniowy nie może wyłączyć działającego kanału.

18.4 Kopia zapasowa

Dwie rzeczy do zabezpieczenia, a one mają różne właściwości.

Katalog kanału jest mały, rzadko się zmienia i jest tym, czego potrzebujesz, aby odbudować usługę. Zabezpiecz go jako konfigurację; kontrola wersji jest zwykle wystarczająca.

Baza danych zawiera wiadomości, użytkowników i historię inspekcji. Jest duża, ciągle się zmienia i zawiera dane kliniczne — więc potrzebuje zabezpieczenia jako dane kliniczne, z retencją i szyfrowaniem, które to implikuje. Utrata jej nie zatrzymuje usługi, ale traci możliwość zbadania wszystkiego, co już się wydarzyło, i historii, na której polega uczący się rytm.

18.5 Zachowanie po ponownym uruchomieniu

Po ponownym uruchomieniu kanały są ładowane, a źródła zaczynają nasłuchiwać. Wstrzymane dostawy są wznowione.

Rzecz, którą trzeba zrozumieć, to to, co się dzieje z pracą w locie. Pod domyślnym potwierdzeniem on_delivery, wiadomość, która nie została jeszcze potwierdzona, nie jest potwierdzona, więc nadawca ją ponownie wyśle — co jest prawidłowym wynikiem. Pod on_receipt, wiadomość, która została potwierdzona, ale nie została jeszcze dostarczona, jest w kolejce i wznowiona; jeśli kolejka jest wyłączona, jest tracona. Zobacz przepływ wiadomości.

18.6 Uaktualnianie

Zamień binarny plik i zrestartuj. Schemat bazy danych jest migrowany do przodu automatycznie podczas startu.

Migracje są tylko do przodu. Nie ma cofnięcia, więc wycofanie się do poprzedniego binarnego pliku po tym, jak schemat został przeniesiony, wymaga poprzedniej bazy danych. Zrób kopię przed uaktualnieniem — to jest jeden operacyjny środek ostrożności, o który warto być dyscyplinowanym.

18.7 Monitorowanie

Alarmowanie z Perfuse jest objęte w alarmowaniu i to powie ci, że kanał przestał działać.

Z zewnątrz monitoruj proces, dysk, na którym znajduje się baza danych, i czy interfejs sieciowy odpowiada. Baza danych rośnie, a pełny dysk zatrzymuje nagrywanie wiadomości, co jest trybem awaryjnym bez innego ostrzeżenia.

18.7.1 SNMP

Dla narzędzi monitorowania, które mówią SNMP (Nagios, Zabbix, PRTG, SolarWinds, LibreNMS), Perfuse uruchamia agenta SNMPv2c tylko do odczytu i wysyła pułapkę, gdy alert zostanie wyzwolony lub rozwiązany. Ustaw to pod Ustawienia → Monitorowanie → SNMP, lub za pomocą flag:

perfuse serve -snmp-listen :161 -snmp-community 'long-random-community' -snmp-allow 10.0.5.0/24 \
  -snmp-traps nms.example.org,10.0.5.9:1162

• Agent odpowiada na GET, GETNEXT i GETBULK, ale tylko z sieci określonych w -snmp-allow: społeczność v2c to hasło wysłane w postaci jawnej, więc nigdy nie jest otwarta dla wszystkich. Społeczność o długości mniejszej niż 6 znaków lub public/private powoduje zatrzymanie serwera podczas uruchamiania.
• Obsługuje grupę systemu (sysDescr, sysUpTime, sysName z etykiety floty, sysContact, sysLocation), sumy pod BASE.1 (kanały, uruchomione, uszkodzone, otrzymane, dostarczone, nieudane, w kolejce) i tabelę kanałów pod BASE.2.1 (nazwa, uruchomiony lub zatrzymany, otrzymane, dostarczone, nieudane, w kolejce, wiek najstarszego komunikatu w kolejce). Liczby są tymi, które wyświetla pulpit nawigacyjny i /metrics.
• Pułapki są wysyłane do każdego menedżera w -snmp-traps: BASE.0.1 alert został wyzwolony, BASE.0.2 został rozwiązany, zawierający rodzaj alertu, poziom ważności, kanał, miejsce przeznaczenia i podsumowanie. Nigdy zawartość komunikatu. Potwierdzony alert nie wysyła pułapki.
• BASE to 1.3.6.1.4.1.8072.9999.9999.16 (przestrzeń eksperymentalna Net-SNMP) chyba że -snmp-base-oid umieszcza go pod własnym numerem przedsiębiorstwa. Pobierz MIB na stronie Ustawienia (lub GET /api/snmp/mib) daje MIB dla bazy w użyciu; ten sam panel mówi, czy agent odpowiada i ile pułapek wysłano.

18.7.2 Inwentaryzacja każdego interfejsu

-inventory interfaces.md (Ustawienia → Monitorowanie → Inwentaryzacja) zapisuje dokument Markdown, który wylistuje każdy kanał - jego format, czy jest uruchomiony, co otrzymuje i co wysyła - a następnie opisuje każdy kanał, i przepisuje go co -inventory-every (dzień domyślnie). Ma być zatwierdzony obok plików kanałów lub przekazany audytorowi i przeczytany bez uruchomienia aplikacji.

18.8 Pojemność

Górna granica przepustowości Perfuse nie została zmierzona na prawdziwym sprzęcie pod prawdziwym ruchem, i ten podręcznik nie wydrukuje liczby, której nie może poprzeć.

Co można powiedzieć: architektura jest jednym gorutynem na połączenie z kolejkami per-destination, więc przepustowość rośnie wraz z miejscami przeznaczenia, a nie jest serializowana przez jednego pracownika; nagrywanie wiadomości jest zapisem SQLite na wiadomość, co sprawia, że dysk jest najbardziej prawdopodobną pierwszą ograniczeniem; a sklep z wiadomościami rośnie liniowo z ruchem, więc retencja jest ustawieniem, które rządzi długoterminowym użyciem dysku.

Jeśli rozmiar jest dostosowywany do dużego źródła danych, należy zmierzyć go przy użyciu własnego ruchu za pomocą wygenerowanego korpusu testowego opisanego w testing. To jest uczciwa odpowiedź, a także lepsza niż liczba z czyjegoś innego sprzętu.

18.9 Miejsce, w którym instalacja uległa awarii

Aktywność wyświetla panel widoczny dla administratorów, pokazujący, co Perfuse odmówił zrobić — pogrupowane według wiadomości, najczęstsze jako pierwsze — i jak daleko instalacja posunęła się w kierunku działającego kanału.

Istnieje, ponieważ każde inne twierdzenie dotyczące łatwości użycia tego oprogramowania pochodzi od osób, które je napisały. Odmowa nie: ktoś chciał czegoś, serwer powiedział nie, i żadna ze stron nie zgadywała. Jest to jedyny dowód w produkcie, który nie pochodzi od BioDream LLC.

Lejek nazywa krok, który jeszcze nie nastąpił, zamiast pozostawiać znaczniki czasu do porównania. Stan wart obserwacji to wiadomości przychodzą, ale żadna nie została dostarczona do miejsca przeznaczenia — kanał może przyjmować ruch przez tygodnie i nie dostarczyć go, i z każdego innego ekranu wygląda to tak, jakby działał.

Nic, co ktoś wpisał, nie jest rejestrowane. Tabela zawiera trasę żądania z identyfikatorami zastąpionymi przez {id}, stan i zdanie serwera. Wiadomość walidacyjna nazywa pole i regułę, co jest użyteczną częścią; wartość, która złamała regułę, jest bardzo często danymi pacjenta, a tabela tych danych byłaby gorszym obciążeniem niż tarcie, które mierzy.

Dwa celowe wykluczenia. 5xx to błąd w tym oprogramowaniu i jest już zalogowany jako taki — łączenie ich obu zakopie przypadki, w których ktoś nie mógł zrozumieć, co wpisać, pod przypadkami, w których nic, co wpisano, nie pomogłoby. A wygasły sesja produkuje serię 401, które nie mówią nic o używalności i utopią każde znalezienie, które tak.

Czytanie raportu również obcina tabelę do pięciu tysięcy ostatnich wierszy. Odmowy są odpowiedziami 4xx, więc rośnie powoli, a odczyt jest naturalnym momentem, aby uporządkować: nie ma timera i nic, co działa, gdy nikt nie patrzy.

GET /api/friction zwraca tę samą rzecz dla każdego, kto woli ją czytać jako JSON.

18.10 Dzienniki

Perfuse zapisuje dane do standardowego wyjścia, gdzie zostaną zebrane przez nadzorcę lub środowisko uruchomieniowe kontenera.

Szczegóły na poziomie wiadomości trafiają do sklepu wiadomości zamiast do dziennika, celowo. Wiersz dziennika na wiadomość w zajętym źródle danych to szum, który ukrywa wiersze, które mają znaczenie, a sklep jest wyszukiwalny w sposób, w jaki plik dziennika nie jest.

Dziennik zawiera to, czego sklep nie może: uruchomienie i zatrzymanie, wyniki ładowania konfiguracji, zmiany stanu kanału i błędy, które nie są przypisane do określonej wiadomości.

18.11 Uruchamianie dwóch wystąpień

Dwa lub więcej serwerów mogą działać jako jeden klaster: gdy serwer, który uruchamia kanał, zatrzymuje się, inny serwer przejmuje go w ciągu kilku sekund, a następna próba nadawcy dociera do niego. Używają one wspólnej bazy danych PostgreSQL zamiast każdego z nich przechowywać plik SQLite, i uzgadniają między sobą, za pomocą niej, który z nich uruchamia co.

perfuse serve -db 'postgres://perfuse:SECRET@db.hospital.internal/perfuse?sslmode=verify-full' \
  -cluster active-passive -node-name perfuse-01 -node-address https://perfuse-01.hospital.internal:8443 \
  -data /var/lib/perfuse

Uruchom każdy serwer w ten sam sposób z własną nazwą i adresem. Konto bazy danych musi utworzyć tabele i, raz, rozszerzenie citext (lub administrator uruchamia CREATE EXTENSION citext wcześniej). Każdy serwer przechowuje własne pliki w -data: swój dziennik, swój identyfikator węzła i swoje kopie konfiguracji.

Dwa sposoby udostępniania pracy.

• active-passive: lider uruchamia każdy kanał i każde zadanie, które musi być uruchomione raz (powiadomienia o subskrypcji FHIR). Pozostali czekają. Najłatwiejszy do zrozumienia i to, czego chce strona z jednym zajętym serwerem i serwerem rezerwowym.
• active-active: kanały są rozłożone na żywe serwery, mniej więcej równomiernie. Serwer, który zatrzymuje się, przekazuje swoje kanały reszcie; serwer, który dołącza, bierze swoją część, gdy kanały są dostępne, jeden po drugim. Kanały, które są trasowane do siebie nawzajem (miejsce przeznaczenia kanału), działają na jednym serwerze i poruszają się razem, ponieważ trasowanie występuje wewnątrz serwera. Administrator może przenieść kanał ręcznie z Monitor → Flota; pozostaje tam, gdzie został umieszczony, dopóki serwer żyje.

Kto uruchamia co, i nigdy nie ma dwóch w tym samym momencie. Każda część pracy to dzierżawa w bazie danych, odnawiana co piątą część -cluster-lease (15 s domyślnie). Serwer, który nie może odnowić jej (uległ awarii, jego sieć uległa awarii, baza danych jest niedostępna), zatrzymuje tę pracę samodzielnie, gdy jego własny zegar mówi, że dzierżawa jest prawie skończona, z trzecią częścią dzierżawy do dyspozycji. Inny serwer bierze dzierżawę tylko po tym, jak jego własny zegar obserwował licznik dzierżawy przez całą dzierżawę. Żaden zegar nie jest porównywany z innym, więc zegary serwerów i bazy danych nie muszą się zgadzać; muszą tylko działać w mniej więcej tym samym tempie, co robi każdy zegar. Między starym posiadaczem a nowym jest krótka luka z nikim, kto nie słucha, co nadawca widzi jako odmowę połączenia i ponawia; nigdy nie ma momentu, w którym dwóch słucha na jednym kanale lub dwóch pracowników opróżnia jedną kolejkę.

Serwer zamykany w sposób czysty lub administrator wybierający Oddaj na liderze, przekazuje natychmiast zamiast po dzierżawie.

Co każdy serwer udostępnia. Komunikaty, kolejka dostarczania, konta i sesje, dziennik inspekcji, magazyn FHIR, tabele terminologiczne i indeks pacjentów są w bazie danych, więc niezależnie od tego, który serwer uruchamia kanał, znajduje kolejkę, którą pozostawił poprzedni. Pliki kanałów, plik ustawień, reguły alertów, pliki logowania jednokrotnego, logo, certyfikaty Direct i zapisane widoki są przechowywane w ten sam sposób na każdym serwerze za pomocą bazy danych: każdy z nich trzyma własną kopię na swoim dysku, zmiana na dowolnym serwerze (w konsoli, ręcznie, przez git pull) dociera do innych w ciągu dwóch sekund, a kanał zmieniony na innym serwerze restartuje się z nowym plikiem. Ten sam plik zmieniony na dwóch serwerach jednocześnie zachowuje wersję, która dotarła do bazy danych jako pierwsza, a drugą obok niego jako NAME.conflict-SERVER. Ustawienia, które mają zastosowanie tylko podczas restartu (baza danych komunikatów, porty, na których nasłuchuje konsola), są stosowane przez każdy serwer podczas następnego restartu, a dziennik mówi o tym. To, co nazwuje coś na jednej maszynie, pozostaje na linii poleceń serwera i poza plikiem współdzielonym: certyfikat i klucz (-tls-cert, -tls-key), adres nasłuchiwania SNMP i nazwa serwera w śladach. Ustawienia wyświetla je jako ustawione na każdym serwerze.

Uruchom i zatrzymaj. Uruchomienie lub zatrzymanie kanału na dowolnym serwerze ma zastosowanie do klastra: serwer, który go uruchamia, uruchamia go lub zatrzymuje w ciągu jednej sekundy, a odpowiedź mówi, który serwer to robi.

Wygładzanie obciążenia przednim. Adres kanału musi dotrzeć do serwera, który go uruchamia. Wskaż nadawcę na wirtualny adres (wygładzanie obciążenia, pływający IP, nazwę DNS z krótkim TTL) i pozwól wygładzaniu obciążenia sprawdzić /readyz?channel=NAME, który odpowiada 200 tylko na serwerze uruchamiającym ten kanał, i 503 na innych. Dla konsoli, /readyz jest 200 na każdym żywym serwerze; /readyz?role=leader tylko na liderze.

Na AWS Network Load Balancer, użyj grupy docelowej na kanał z kontrolą zdrowia HTTPS na /readyz?channel=NAME, interwałem 5 sekund i progiem 2, i włącz przełączanie strefy wygładzania obciążenia. Z wyłączonym przełączaniem, węzeł wygładzania obciążenia w strefie, w której nie uruchamia się kanał, widzi tylko niezdrowe cele i wysyła do wszystkich z nich, a nadawca, który rozwiązał ten węzeł, czeka, aż kanał wróci do jego strefy (95 sekund w teście). Ustaw opóźnienie wyrejestrowania na 0, ponieważ serwer, który przestaje uruchamiać kanał, nie ma nic do opróżnienia.

Co zostało przetestowane. Dwa serwery na PostgreSQL 16, nadawca przesyłający 300 wiadomości, ponawiający wysyłanie, aż do odpowiedzi, i serwer uruchamiający kanał zabity sygnałem SIGKILL dwa razy (pierwszy, a następnie drugi po powrocie pierwszego). Każda potwierdzona wiadomość dotarła do odbiorcy, w obu próbowanych kształtach: dostarczona przed potwierdzeniem i zakolejkowana w udostępnionym magazynie, podczas gdy odbiorca odmówił (185 potwierdzonych wiadomości czekało w kolejce przy zabiciu; ocalały serwer dostarczył je wszystkie). Przejęcie awaryjne zajęło 3 do 4 sekund na 3-sekundowym leasingu. Możliwe jest powtórzenie i zostało raz zobaczone w 600: wiadomość, którą umierający serwer dostarczył i nie mógł potwierdzić, którą nadawca ponowił.

To samo zostało zrobione na AWS: dwa serwery Linux (ARM) i jeden Windows Server 2022 w trzech strefach dostępności, Amazon RDS PostgreSQL 16 przez TLS z sprawdzonym certyfikatem (sslmode=verify-full), wewnętrzny Network Load Balancer z przodu i nadawcy ponawiający wysyłanie, aż do odpowiedzi:

Z domyślnym leasingiem 15 sekund, serwer odcięty od bazy danych zatrzymał swój kanał 10 sekund po ostatnim odnowieniu, a następny serwer uruchomił go 6 do 8 sekund później: nigdy nie oba na raz. Zniekształcone zegary nie zmieniły nic, ponieważ nie porównuje się żadnego zegara z innym.

Nie jeszcze. Klaster służy jednej organizacji: -cluster z -multi-tenant jest odrzucany. Słuchacze przechodzą z kanałem, więc wygładzanie obciążenia jest dostarczane przez witrynę.

Serwer samodzielnie nadal działa tak, jak zawsze, na SQLite, bez klastra w ogóle.

18.12 Więcej niż jeden serwer

Witryna z dwoma instancjami ma pytanie, na które nie może odpowiedzieć żadna pojedyncza konsola: czy wszystko działa? Mirth pobiera opłatę za odpowiedź. To jest widok floty.

Jedna instancja jest wyznaczona jako miejsce, w którym szukamy. Zapytuje inne i pokazuje każdy kanał na każdym serwerze w jednej tabeli, z podsumowaniem we wszystkich.

18.12.1 Dodawanie równej instancji

Ustawienia → Flota, lub PUT /api/fleet/peers. Równy potrzebuje nazwy, adresu URL i tokenu wydanego przez samego siebie.

Nazwa jest wymagana i nie jest adresem URL, ponieważ adres URL nie jest czymś, co ktokolwiek rozpoznaje o trzeciej w nocy.

Token musi być utworzony na równym, pod Użytkownicy, i powinien mieć zakres widza. Dodanie równego bez niego jest odrzucane z tymi instrukcjami, zamiast akceptowania i potem niepowodzenia cicho przy każdym zapytaniu. Czytanie stanu zdrowia innej instancji jest najmniejszym przywilejem, jaki istnieje, i jest to jedyny, którego potrzebuje widok floty.

18.12.2 Kontrolowanie równego, który jest wyłączony

allow_control pozwala na uruchamianie i zatrzymywanie kanałów tego równego z tego miejsca. Jest wyłączone domyślnie i każde użycie jest rejestrowane według nazwy.

Dwa przywileje są celowo oddzielne. Czytanie stanu zdrowia innego serwera jest nieistotne; zatrzymywanie jego kanałów podczas transfuzji nie jest, i to drugie nigdy nie powinno przyjść cicho dołączone do pierwszego.

18.12.3 Co mówi raport

Każdy serwer raportuje łączną liczbę kanałów, ile z nich jest uruchomionych, zatrzymanych lub wystąpił błąd, głębokość kolejki oraz wiek najstarszego oczekującego komunikatu, ile alertów jest aktywnych oraz czy jest opróżniany w celu wyłączenia.

Podsumowanie liczy serwery na trzy sposoby: dostępne, niedostępne i nieokreślone. Trzeci obejmuje równych, których stan zdrowia nikt nie zna — jeszcze nie zapytany, odmawiający tokenu lub uruchamiający wersję, którą ten nie może odczytać. Jest on trzymany oddzielnie od niedostępnych, ponieważ „nie wiemy” nie jest „jest w dół”, a łączenie ich razem jest tym, jak strona floty zaczyna kłamać.

Z tego samego powodu podsumowanie zawiera knownFrom: ile instancji faktycznie odczytało cyfry kanału i kolejki. Dwanaście kanałów uruchomionych w całej flocie oznacza coś innego, gdy dwa z pięciu serwerów nie odpowiedziały, a suma sama nie może powiedzieć tak.

Niedostępny równy mówi, dlaczego w terminach, na które operator może działać. Odmowa połączenia jest zgłaszana jako host, który jest w górę, z niczym nie nasłuchującym na tym porcie, co jest innym problemem niż host, który w ogóle nie odpowiada.

18.12.4 Odchył czasu

Podsumowanie raportuje największą różnicę między zegarami serwerów w nim. Warta liczby własnej: korelowanie incydentu w całych dwóch instancjach, których zegary nie zgadzają się przez cztery minuty, produkuje sekwencję zdarzeń, które nie miały miejsca.

18.12.5 Co równe dowiaduje się o tobie

Liczby i stawki. Raport, który jedna instancja daje innej, nie zawiera identyfikatorów wiadomości, szczegółów na poziomie kanału i żadnych danych pacjentów.

To jest to, co powoduje, że widok floty nie jest scentralizowanym zbiorcem danych klinicznych: instancja agregująca dowiaduje się, ile kanałów jest uruchomionych i niczego więcej o tym, co przez nie przepływa. Jeśli chcesz uzyskać wiadomości, otwierasz konsolę samego serwera, gdzie log audytowy rejestruje to, że to zrobiłeś.

18.12.6 Równe wskazujące na siebie

Odmówiono. Instancja sondująca własny adres za pomocą własnego stosu HTTP pojawia się dwa razy w własnym widoku floty i podwaja liczbę każdego kanału, który posiada.

18.12.7 TLS w sieciach wewnętrznych

insecure_skip_verify akceptuje certyfikat peer'a bez jego weryfikacji. Istnieje dlatego, że infrastruktura szpitala działa na prywatnych urzędach certyfikacji, a odmowa pracy w ogóle spowodowałaby, że ludzie przeszliby na zwykły HTTP, co jest gorsze. Nazwano to w ten sposób, aby nie można było go pomylić z dobrym pomysłem.

19 Wiersz poleceń

Wszystko, co Perfuse robi do uruchomionego systemu, jest dostępne z interfejsu webowego, i jest to celowe: funkcja, która potrzebuje terminala, jest traktowana jako wada, a nie wybór projektowy. Polecenia tutaj są dla pracy, która dzieje się *wokół* uruchomionego systemu — przed jego istnieniem, gdy decydujesz, czy mu ufać, i gdy potrzebujesz przekazać coś komuś innemu

Kilka z nich w ogóle nie dotyka serwera. perfuse explain, perfuse profile, perfuse deident i perfuse translate czytają pliki i zapisują pliki, więc są przydatne na laptopie przeciwko majątkowi, który nadal działa całkowicie na czymś innym

Uruchom każde polecenie z -h dla jego flag. Ten rozdział mówi, do czego służy każde z nich

19.1 Uruchamianie kanałów

19.1.1 perfuse serve

Uruchamia interfejs sieciowy i API, a domyślnie również uruchamia kanały. Jest to polecenie używane przez instalację.

Każda opcja, którą akceptuje, jest wymieniona w Opcjach serwera, generowana z programu. Odmawia obsługi zwykłego HTTP dla wszystkiego poza pętlą zwrotną, chyba że zostanie przekazany parametr -insecure. Nie jest to konfigurowalna uprzejmość: ruch kliniczny i ciasteczko sesji po niezaszyfrowanym połączeniu LAN jest zdarzeniem, które należy zgłosić, a flaga istnieje, aby mówienie tak było decyzją, którą ktoś podjął, a nie domyślną, którą odziedziczył. Zobacz bezpieczeństwo.

19.1.2 perfuse run

Uruchamia kanały z plików YAML bez interfejsu sieciowego i bazy danych. Przydatne w kontenerze, który powinien wykonywać tylko jedną rzecz, oraz przydatne, gdy chcesz zobaczyć zachowanie kanału bez uruchamiania niczego innego.

19.1.3 perfuse check

Weryfikuje definicje kanałów i drukuje, co one robią, bez ich uruchamiania. Druga połowa jest punktem: kanał, który się ładuje, nie jest koniecznie tym kanałem, który miałeś na myśli, a czytanie podsumowania w języku angielskim tego, co plik będzie robił, łapie błąd, którego nie może zobaczyć walidacja.

Zakończa się niezerowym kodem w przypadku błędu, więc należy do niego włączyć wszelkie sprawdzenia konfiguracji przed jej dotarciem do serwera. Parametr -quiet nic nie drukuje w przypadku powodzenia, do tego użytku.

-allow-metadata-egress zezwala na miejsca docelowe wskazujące na adresy metadanych instancji chmury. Te adresy zawierają poświadczenia maszyny, więc kanał, który może być nakłoniony do wysłania tam, jest wyciekiem poświadczeń; sprawdzenie odmawia im, chyba że się inaczej postanowi.

19.1.4 perfuse test

Uruchamia testy napisane przeciwko definicjom kanałów. Test wysyła wiadomość przez rzeczywisty filtr kanału, rzeczywiste transformacje i rzeczywiste skrypty, w rzeczywistej kolejności, z zastąpioną tylko siecią — więc to, co tutaj przechodzi, to to, co robi kanał.

Testy znajdują się w plikach *_test.yaml lub *.test.yaml obok kanałów. Zobacz testowanie.

19.2 Migracja z innego silnika

Te trzy są tymi, które należy uruchomić najpierw, zanim się zdecyduje. Zobacz migracja.

19.2.1 perfuse explain

Czyta eksporty Mirth, Open Integration Engine i BridgeLink — kanał, grupę kanałów lub całą kopię zapasową serwera — i opisuje, co robi każdy kanał i co blokuje migrację. Niczego nie zmienia i nie wymaga instalacji Perfuse, co czyni ją najtańszym możliwym pierwszym krokiem: wskazać ją na eksport Twojego majątku i przeczytać, co wraca.

-strict kończy się niezerowym kodem, jeśli cokolwiek jest zablokowane, więc może bramkować potok. -json emituje te same wyniki dla maszyny.

19.2.2 perfuse translate

Konwertuje eksporty Mirth, Open Integration Engine i BridgeLink na pliki kanałów Perfuse: jeden kanał, grupa kanałów, eksport biblioteki szablonów kodu lub cała kopia zapasowa serwera.

perfuse translate -o ./channels server-backup.xml

Biblioteki szablonów kodu są zapisywane w lib/ obok kanałów, a każdy kanał Mirth miał włączoną bibliotekę, która ją zawiera. Zobacz migracja.

Nic nie jest cicho upuszczane. Każda część kanału jest albo tłumaczona, przenoszona jako skrypt, który działa niezmieniony, albo zgłaszana jako wymagająca interwencji człowieka. Trzecia kategoria jest uczciwa — tłumacz, który wyprodukował czysto wyglądający plik dla każdego wejścia, ukrywałby decyzje, które najbardziej potrzebujesz podjąć.

19.2.3 perfuse compare

Uruchamia ten sam ruch przez dwa silniki i zgłasza, gdzie się nie zgadzają, pogrupowane według pola.

To jest polecenie, które odpowiada na pytanie "dlaczego mam ufać temu z danymi pacjentów", i odpowiada na nie za pomocą zebranych dowodów, a nie oświadczeń złożonych tutaj. Jest to zalecany ostatni krok przed przełączeniem i zalecany pierwszy krok w każdej dyskusji na temat tego, czy Perfuse jest gotowy.

19.3 Zrozumienie kanału

19.3.1 perfuse profile

Odczytuje wiadomości i raportuje, co tak naprawdę w nich jest: które pola są zawsze wypełnione, które nigdy nie są, rzeczywiste zestawy wartości pól zakodowanych, liczniki powtórzeń i które segmenty Z pojawiają się.

Wartości są raportowane tylko dla pól, których wartości tworzą mały zestaw kodów, więc profil rzeczywistego ruchu nie staje się plikiem pełnym danych pacjentów.

Zapisywanie profilu i porównywanie go później pozwala dowiedzieć się, że nadawca coś zmienił:

perfuse profile -save last-month.json corpus/ perfuse profile -against last-month.json new/

19.3.2 perfuse contract

Przekształca wynik tego myślenia w coś egzekwowalnego. Umowa określa, jak powinien wyglądać kanał, aby dzień, w którym ulega zmianie, został powiadomiony, zamiast dowiadywać się tygodnie później od odbiorcy, który upadł — wiadomości są nadal ważne HL7, gdy pole znika, więc nic innego nie zauważa.

perfuse contract promote -o adt.contract.yaml corpus/ perfuse contract check adt.contract.yaml today/

promote generuje punkt wyjścia, a nie odpowiedź. Przeczytaj ją i usuń większość z niej: każda linia rejestruje, czy została zmierzona czy podjęta, co mówi ci, które linie należy zachować.

19.4 Wytwarzanie wiadomości

19.4.1 perfuse generate

Wytwarza syntetyczne wiadomości HL7 v2. Wszystko jest wymyślone — oczywiście fikcyjne nazwy, sekwencyjne identyfikatory, wymyślone adresy — więc dane wyjściowe są bezpieczne do zatwierdzenia, wysłania i dołączenia do biletu.

Może wysyłać bezpośrednio do kanału, zamiast zapisywać plik, co jest najszybszym sposobem udowodnienia, że nasłuchuje:

perfuse generate -n 100 -send 127.0.0.1:6661

19.4.2 perfuse deident

Odczytuje rzeczywiste wiadomości i zapisuje korpus, który zachowuje ich strukturę, ich kody i ich interwały, oraz niczego, co identyfikuje pacjenta. To jest różnica między możliwością wysłania komuś powtórzenia a brakiem tej możliwości.

Nie jest to ten sam narzędzie co perfuse generate, a różnica ma znaczenie. Wygenerowane wiadomości są wymyślone i dlatego bezpieczne, ale nierzeczywiste; deidentyfikowany korpus jest *pochodny od rzeczywistego ruchu*, więc odtwarza dziwactwa, które naprawdę łamią interfejsy.

Dwie właściwości warte zrozumienia przed użyciem:

• To samo ziarno zawsze produkuje ten sam korpus, więc współdzielony korpus może być ponownie wygenerowany, zamiast archiwizowany.
• Zachowaj ziarno w tajemnicy. Pseudonimy są pochodne od wartości rzeczywistych, więc każdy, kto posiada ziarno, może potwierdzić przypuszczenie o tym, do kogo odnosi się rekord.

19.5 Przenoszenie wiadomości ręcznie

19.5.1 perfuse listen

Akceptuje HL7 v2 za pośrednictwem MLLP i potwierdza to. Odbiorca, który istnieje tak długo, jak potrzebujesz, aby udowodnić, że nadawca może dotrzeć do tej maszyny w ogóle.

19.5.2 perfuse send

Wysyła wiadomości HL7 v2 za pomocą MLLP z plików.

19.6 FHIR

19.6.1 perfuse fhir

Konwertuje HL7 v2 na FHIR, waliduje FHIR lub udostępnia go, w zależności od podpolecenia.

Polecenie walidujące jest przydatne samo w sobie: poinformuje, czy zasób, który ktoś wysłał, spełnia wymagania US Core, który jest profilem, przeciwko któremu jest napisany amerykański regulamin. Możliwość udzielenia odpowiedzi bez przyjęcia silnika jest celem.

19.6.2 perfuse x12

Konwertuje X12 (lub inne rozdzielone EDI) na XML Mirth Connect i Open Integration Engine, a także odwrotnie: perfuse x12 xml FILE i perfuse x12 from-xml FILE, standardowe wejście, gdy nie podano pliku. Wyjście jest tym, co OIE 4.6 zapisuje, bajt po bajcie, więc można je porównać z tym, co wyprodukował serwer Mirth lub zostało podane do systemu zbudowanego na jego podstawie. Kanał robi to samo z x12.arrives_as: xml i x12_as: xml miejsca docelowego; zobacz X12.

19.6.3 perfuse sof

Uruchamia zapytanie SQL na widoku FHIR ViewDefinition nad plikami FHIR (NDJSON eksportu wsadowego, Bundles lub tablice JSON; - dla stdin) i zapisuje tabelę: -view FILE (wymagany), -format csv|ndjson|json|parquet (domyślnie csv), -header=false, i -o FILE (wymagany dla Parquet). Zobacz Widoki SQL na FHIR.

19.6.4 perfuse measure

Ewaluuje miarę jakości z kryteriami FHIRPath nad plikami FHIR (NDJSON pełnego eksportu, Bundle lub tablice JSON; - dla stdin) i zapisuje MeasureReport. Flagi:

• -measure FILE, or -measure example:ID for a shipped example: required. -examples lists the examples.
• -period-start and -period-end: required.
• -type summary|subject|subject-list.
• -subject Patient/ID.
• -reporter NAME.
• -o FILE.

Zobacz cyfrowe miary jakości.

19.6.5 Flagi FHIR w perfuse serve

Sklep przechowuje dokumenty, a także zasoby: dokument, kolekcja lub wiązka wiadomości przesłana do /fhir/Bundle/{id} jest przechowywana w całości, odczytywana z każdym wpisem w wersji obsługiwanej i znaleziona przez type, identifier, timestamp i composition. Transakcja przesłana tam jest przechowywana jako rekord i nie jest stosowana; POST do /fhir stosuje ją.

Odpowiedzi są w formacie JSON, chyba że klient prosi o XML (Accept: application/fhir+xml lub _format=xml). Perfuse odczytuje tylko JSON: treść wysłana jako XML otrzymuje 415. Dokument Bundle wysłany do /fhir jest przechowywany, gdy serwer ten posiada, według identyfikatora, pacjenta i spotkania, których Kompozycja wymienia, i odrzucany z 422 w przeciwnym razie. Binarny odczyt z Accept ustawiony na jego własny typ zawartości odpowiada samą zawartością.

19.7 Konfigurowanie i obsługa

19.7.1 perfuse init

Tworzy układ katalogów, przykładowy kanał oraz definicję usługi dla systemu operacyjnego, na którym jest uruchomiony. Nic istniejącego nie jest zastępowane, chyba że przekazano -force.

perfuse init -dir /opt/perfuse -service systemd

19.7.2 perfuse service

Rejestruje Perfuse jako usługę systemu Windows, usuwa ją lub raportuje, czy jest zainstalowana i uruchomiona. Tylko w systemie Windows; w systemie Linux odpowiednikiem jest plik jednostki, który perfuse init może napisać. Zobacz operacje.

19.7.3 perfuse token

Wydaje poświadczenia dla maszyn zamiast ludzi. Token nie wygasa i nie jest dotknięty przez nikogo, kto się wylogowuje, co jest potrzebne przez serwer, który sonduje swojego sąsiada, i co jest celowo nie jest sesją przeglądarki.

perfuse token create -db perfuse.db -label fleet-from-site-a -role viewer perfuse token list -db perfuse.db perfuse token revoke -db perfuse.db -label fleet-from-site-a

Tylko skrót jest przechowywany, więc token jest wyświetlany raz, gdy jest tworzony i nie może być później odzyskany. Skradziony zestaw danych nie daje więc żadnego użytecznego tokenu. Nadaj tokenowi najniższą rolę, która wykonuje zadanie: flota potrzebuje viewer, a nic, co tylko czyta, nie powinno posiadać niczego więcej.

-fhir-groups riverside-attributed,riverside-north ogranicza token do tych grup FHIR, dla eksportu dostawcy CMS-0057 Provider Access: na punkcie końcowym FHIR może odczytać te grupy i wyeksportować je, i niczego więcej. Zobacz CMS-0057 dla płatników.

19.7.4 perfuse athena

Drukuje Amazon Athena CREATE EXTERNAL TABLE dla archiwum S3 napisanego z format: ndjson, używając partycji projekcji na części dt=YYYY-MM-DD klucza, więc żaden crawler nie musi działać, gdy dni są dodawane.

perfuse athena -bucket hospital-archive -destination archive

Wydrukowany zamiast uruchomiony, ponieważ tworzenie tabeli wymaga uprawnień do Athena i Glue, których ten program nie powinien posiadać.

19.7.5 perfuse sbom

Wyświetla wszystko, co jest połączone z binarnym plikiem, odczytanym z samej budowy, a nie z go.mod — więc opisuje binarny plik przed tobą, a nie to, o co ktoś kiedyś poprosił.

-json emituje CycloneDX, a -spdx emituje znacznik-wartość SPDX, co jest zwykle tym, o co pyta przegląd zakupów lub bezpieczeństwa. Kod przeglądarki osadzony w binarnym pliku jest włączony, ponieważ recenzent dopasowujący binarny plik do zaleceń musi wiedzieć, że zawiera aplikację React.

19.7.6 perfuse version

Wydrukuje wersję i commit, z którego została zbudowana. Warto dodać do biletu: „obecna” wersja nie jest wersją, a dwie maszyny, które zostały zainstalowane tydzień temu, często nie uruchamiają tego samego budowania.

20 Opcje serwera

Każda opcja, którą perfuse serve akceptuje, wygenerowana z samego programu, więc ta lista nie może nazwać opcji, która nie istnieje, ani pominąć żadnej. Większość z nich jest również ustawieniem w interfejsie sieciowym, nazwanym w ostatniej kolumnie: wartość zapisana tam wygrywa z flagą przy następnym uruchomieniu, a flaga pozostaje sposobem ustawienia jej z definicji usługi. Adres nasłuchiwania, baza danych i katalog kanału pozostają flagami tylko, ponieważ mówią, gdzie serwer znajduje to, co miałby edytować.

Tajemnice nigdy nie są flagami. Opcja, która wymaga hasła lub tokenu, nazywa zmienną środowiskową, która ją zawiera.

20.1 Wszystkie opcje

21 Odwołanie do kanału

Każdy klucz, który może pojawić się na najwyższym poziomie pliku kanału. Są one wyodrębnione z źródła, więc ten rozdział nie może opisać opcji, która nie istnieje, ani pominąć tej, która istnieje.

21.1 Kanał

Kanał to jeden skonfigurowany przepływ wiadomości: miejsce, w którym wiadomości przychodzą, opcjonalny filtr i jedno lub więcej miejsc, do których są wysyłane.

Zdefiniowane jako Channel w internal/config.

21.1.1 nazwa

Nazwa identyfikuje kanał w logach i metrykach.

Wymagana i unikalna.

21.1.2 grupa

Grupa to część, do której należy ten kanał, służy do organizacji listy, która stała się zbyt długa do odczytania.

Kosmetyczna przy pięciu kanałach i strukturalna przy dwustu: kanały witryny dzielą się na systemy, z którymi rozmawiają, lub zespoły, które je posiadają, a płaska lista dwustu nazw jest nieprzydatna, niezależnie od jakości reszty interfejsu.

Zwykły ciąg znaków, a nie obiekt grupy z własnym plikiem, ponieważ grupa nie ma zachowania. W momencie, gdy ma plik, nabywa ustawienia, a ustawienia na grupie oznaczają, że zachowanie kanału zależy od czegoś, co nie jest napisane w kanale - co jest właściwością, która sprawia, że konfiguracja Mirth jest trudna do zrozumienia. Grupy tutaj są tylko etykietą.

21.1.3 załączniki

Załączniki przenoszą duże ładunki poza wiadomość i przywracają je przed dostarczeniem.

Opcja włączona na kanał: karmienie zwykłych wiadomości ADT nie ma nic do wyodrębnienia i nie powinno płacić za maszynę.

21.1.4 delimited

Delimited konfiguruje kanał z ogranicznikami.

Jedynie istotne, gdy typ danych jest ograniczony.

21.1.5 tabel

Tabele nazw plików udostępnionych tabel mapowania, do których odnosi się przekształcenie według nazwy.

Udostępnione, ponieważ podatek domeny jest w dużej mierze ponownym pochodzeniem mapowania, które ktoś już wyprowadził: kody płci i klasy pacjentów w witrynie są tłumaczone identycznie w każdym kanale, który ich dotyka, a tabela w kanale jest tabelą, którą może używać tylko ten kanał.

21.1.6 włączone

Włączone domyślnie.

Wyłączony kanał jest ładowany i walidowany, ale nie uruchamiany, więc plik, który jest tymczasowo wyłączony, jest nadal sprawdzany przez CI.

21.1.7 typ danych

Typ danych to format wiadomości, które ten kanał otrzymuje.

Domyślnie jest to hl7, więc każdy kanał napisany przed jego istnieniem nadal działa.

21.1.8 x12

X12 zawiera ustawienia, które mają znaczenie tylko na kanale X12.

Ustawienie go na jakimkolwiek innym typie jest odrzucane, a nie ignorowane.

21.1.9 skrypt

Skrypt konfiguruje kanał NCPDP SCRIPT.

Jego kroki znajdują się tutaj, a nie w głównych transformacjach, z tego samego powodu, co inne formaty nie-v2: typy kroków różnią się w zależności od formatu, więc jeden klucz mógłby oznaczać różne rzeczy w zależności od typu danych.

21.1.10 dicom

Obrazowanie konfiguruje nazwane kroki transformacji kanału DICOM.

Nazywane Obrazowaniem, a nie DICOM, ponieważ źródło i miejsce przeznaczenia już mają pole DICOM i trzy pola o tej samej nazwie na różnych poziomach to sposób, w jaki ktoś ustawia niepoprawne.

21.1.11 filtr

Filtr to wyrażenie, które musi być spełnione, aby wiadomość mogła być przekazana dalej.

Wiadomość, która nie spełnia warunku, jest nadal potwierdzana: nadawca nie zrobił nic złego, po prostu nie jesteśmy zainteresowani.

21.1.12 transformacje

Transformacje to deklaracyjne zmiany stosowane do zaakceptowanych wiadomości, w kolejności, przed uruchomieniem skryptu.

To jest warstwa przeznaczona do wykonania zwykłej pracy: każdy krok jest walidowany podczas ładowania pliku, pojawia się w diffie i może być przeglądany przez kogoś, kto nie czyta JavaScript.

21.1.13 skrypty

Skrypty zawierają kod JavaScript dla przypadków, które deklaracyjne kroki nie mogą wyrazić, i to jest to, co skrypty kanału Mirth wprowadzają niezmienione.

Kanał ze skryptem jest oznaczony jako taki w interfejsie, ponieważ jego zachowanie nie może być ustalone przez odczytanie konfiguracji.

21.1.14 cieniowanie

Cieniowanie uruchamia kandydującą wersję tego kanału obok niego i raportuje, gdzie się różnią.

Nic, co robi, nie może dotknąć odbiorcy.

22 Odwołanie do źródła

W każdy sposób, w jaki kanał może otrzymywać wiadomości, oraz każdy klucz, który każdy z nich akceptuje. Kanał ma dokładnie jeden źródło.

22.1 Źródło AMQP

Źródło AMQP otrzymuje z kolejki lub subskrypcji.

Wiadomość jest akceptowana tylko po tym, jak kanał ją obsłużył. Ta, której nie można było obsłużyć, jest zwalniana jako nieudana dostawa, więc broker ponownie ją dostarcza i - w przypadku Service Bus, poza maksymalną liczbą dostaw w kolejce - umieszcza ją w martwym liście.

Zdefiniowane jako AMQPSource w internal/config.

22.1.1 prefetch

Prefetch to liczba wiadomości, które broker może wysłać z wyprzedzeniem.

Domyślnie wynosi 10. Nadal są one obsługiwane pojedynczo, w kolejności.

22.1.2 reconnect

Reconnect to czas oczekiwania po utracie połączenia.

Defaults to 5s.

22.2 Źródło AS2

Źródło AS2 otrzymuje AS2 (RFC 4130): EDI wysłane przez HTTP, podpisanego i zaszyfrowanego za pomocą S/MIME, odpowiedzi z potwierdzeniem (MDN) zawierającym skrót tego, co przybyło.

Payload jest tym, co kanał obsługuje; X12 i EDIFACT są zwykle używane.

Zdefiniowane jako AS2Source w internal/config.

22.2.1 path

Ścieżka jest ścieżką URL, do której partnerzy wysyłają.

Default /as2.

22.2.2 tls

TLS obsługuje HTTPS.

Większość partnerów wymaga tego w umowie, oprócz S/MIME.

22.2.3 id

ID to nasz identyfikator AS2, który partnerzy wysyłają w AS2-To.

Wiadomość do dowolnego innego jest odrzucana.

22.2.4 partnerzy

Partnerzy to ci, którzy mogą wysyłać tutaj.

Wiadomość od każdego innego jest odrzucana.

22.2.5 duplicate_window

DuplicateWindow to czas, przez jaki pamiętany jest identyfikator Message-ID partnera, tak aby wiadomość wysłana ponownie (partner nie otrzymał naszego potwierdzenia i ponowił próbę) była odpowiedzią potwierdzeniem i nie była przekazywana dwukrotnie (RFC 4130 sekcja 7.5).

Default 30 days.

22.3 Azure Blob Źródło

AzureBlobSource pobiera obiekty blob z prefiksu kontenera.

Zdefiniowane jako AzureBlobSource w internal/config.

22.3.1 move_to

MoveTo to miejsce, gdzie przenosi się obsłużony obiekt blob.

Domyślnie ustawiony na processed/.

22.3.2 error_prefix

ErrorPrefix to miejsce, gdzie przenosi się obiekt blob, który nie może być obsłużony, aby nie blokował reszty.

Domyślnie ustawiony na error/.

22.3.3 poll_interval

PollInterval między listami.

Defaults to 30s.

22.3.4 max_object_size

MaxObjectSize odmawia przyjęcia większego obiektu blob, który pozostaje tam, gdzie jest.

Domyślnie ustawiony na 16 MiB.

22.4 Broker Źródło

BrokerSource odczytuje wiadomości z brokera wiadomości.

Czytnik JMS Mirth, dostępny przez STOMP, ponieważ JMS jest interfejsem API Javy, a nie protokołem. Zobacz internal/stomp, aby dowiedzieć się, dlaczego STOMP, a nie OpenWire.

Zdefiniowane jako BrokerSource w internal/config.

22.4.1 addr

Adres to host i port brokera.

Wymagane. 61613 to zwykły port STOMP.

22.4.2 destination

Destination to kolejka lub temat, z którego odczytywane są dane.

Required.

Brokerzy zapisują te dane różnie - /queue/name w ActiveMQ, nazwa bez ścieżki w RabbitMQ - więc są one przekazywane bez zmian, zamiast być montowane w tym miejscu. Odgadnięcie oznaczałoby pracę na jednym brokerze i ciche odczytywanie niczego na innym.

22.4.3 login

Login i Passcode uwierzytelniają.

Większość brokerów odmawia połączenia anonimowego.

22.4.4 passcode

Login i Passcode uwierzytelniają.

Większość brokerów odmawia połączenia anonimowego.

22.4.5 host

Host to host wirtualny.

Domyślnie jest to host adresu.

22.4.6 selector

Selector filtruje wiadomości na brokerze.

Selektor JMS, przekazywany bez interpretacji. Filtrowanie na brokerze, a nie w tym miejscu, oznacza, że wiadomości, których ten kanał nie chce, nigdy nie przekraczają sieci - co w przypadku współdzielonej kolejki jest różnicą między odczytaniem stu wiadomości dziennie a stu tysiącami.

22.4.7 subscription_id

SubscriptionID nazwuje subskrypcję.

Domyślnie jest to nazwa kanału.

Nazwana, a nie wygenerowana, ponieważ trwała subskrypcja jest identyfikowana przez nią: wygenerowana subskrypcja tworzyłaby nową subskrypcję przy każdym ponownym uruchomieniu i pozostawiałaby stare subskrypcje, które gromadzą wiadomości, których nikt nie czyta.

22.4.8 heartbeat

Heartbeat utrzymuje połączenie.

Domyślnie jest to trzydzieści sekund.

Włączone domyślnie, w przeciwieństwie do domyślnego ustawienia klienta, ponieważ źródło utrzymuje otwarte połączenie przez tygodnie. Bez sygnałów serca połączenie przez zapory sieciową, której trasa została cicho usunięta, wygląda idealnie zdrowo z tego końca, a wiadomości po prostu przestają przychodzić, bez logowania.

22.4.9 reconnect

Reconnect to czas oczekiwania przed ponownym połączeniem po awarii.

Domyślnie jest to pięć sekund.

22.4.10 limit czasu

Granice limitu czasu podczas łączenia.

Domyślnie jest to trzydzieści sekund.

22.5 Źródło zapytania DICOM

DICOMQuerySource przesłuchuje archiwum za pomocą C-FIND i emituje wiadomość dla każdego nowego badania.

Mirth nie ma równoważnego łącznika. Jego obsługa DICOM jest odbiornikiem i nadawcą - może odbierać obrazy przesłane do niego i przesyłać je dalej, i to wszystko. Zapytanie archiwum o to, co zawiera, było wnioskowane na ich forach od 2015 roku.

To, co sprawia, że jest warte posiadania, nie jest zapytanie, ale automatyzacja: wstępne pobieranie, które działa o trzeciej rano, uzgodnienie, które zauważa, że archiwum nie zawiera badania, które RIS mówi, że istnieje, lista pracy utworzona z tego, co było rzeczywiście zeskanowane, a nie z tego, co zostało zamówione. Są to zadania, które strony wykonują obecnie za pomocą zaplanowanego skryptu poza silnikiem, co oznacza, że są niewidoczne dla niego - brak ponownych prób, brak alertów, brak historii wiadomości.

Zdefiniowane jako DICOMQuerySource w internal/config.

22.5.1 adres

Adres to host i port archiwum.

Required.

Nazwany, aby dopasować do miejsca przeznaczenia DICOM, a nie skrócony. Dwa były "adres" i "addr" przez popołudnie, co jest rodzajem niekonsekwencji, której ktoś piszący ręcznie plik kanału popełnia raz i potem nieufnie podchodzi do całego formatu.

22.5.2 called_ae

CalledAE to tytuł AE archiwum.

Wymagany w praktyce: większość archiwów odmawia skojarzenia skierowanego do czegoś innego, a to odmówienie jest odczytywane jako awaria, a nie jako błąd konfiguracyjny.

22.5.3 calling_ae

CallingAE to tytuł AE przedstawiany przez Perfuse.

Archiwa często go używają do kontroli dostępu.

22.5.4 poziom

Poziom to poziom zapytania: PACJENT, BADANIE, SERIA lub OBRAZ.

Domyślnie jest to BADANIE.

BADANIE jest domyślnym, ponieważ jest to to, czego prawie każde przydatne zapytanie chce, i dlatego, że alternatywy zaskakują ludzi: poziom OBRAZU wobec dużego CT zwraca jeden odpowiedź na plaster, co jest setkami na badanie.

22.5.5 dopasuj

Dopasuj to klucze zapytania.

Wartość filtruje; pusta wartość prosi o zwrócenie pola.

Klucze są nazwane, a nie ponumerowane - "PatientID" zamiast "0010,0020" - ponieważ plik kanału jest czytany przez ludzi, a numer tagu w pliku konfiguracyjnym jest wyszukiwaniem, które każdy czytelnik musi wykonać.

22.5.6 zwróć

Pola Return są polami, które należy zwrócić bez filtrowania ich.

Oddzielone od Match pustą wartością, chociaż są one zakodowane w ten sam sposób, ponieważ intencja jest inna i czytelnik może zobaczyć, które klucze zawężają wyszukiwanie, a które są zbierane.

22.5.7 interwał

Interwał określa, jak często należy przeprowadzać sondowanie.

Required.

22.5.8 okno

Okno określa, jak daleko wstecz każde sondowanie sięga, jako zakres daty badania.

Zero wyłącza całkowicie filtrowanie dat.

Okno jest tym, co utrzymuje to w granicach. Bez niego każde sondowanie prosi archiwum o wszystko, co kiedykolwiek posiadało, a następnie odrzuca to, co widziało wcześniej - co działa w teście archiwum i jest niegrzeczne wobec prawdziwego archiwum zawierającego miliony badań.

22.5.9 nakładanie

Nakładanie ponownie wysyła zapytanie o ten okres, który już został przesondowany.

Domyślnie ustawiony na jedną godzinę.

Konieczne raczej niż ostrożne. Badanie może być zarejestrowane z datą wczorajszą, nasz zegar i zegar archiwum nie muszą się zgadzać, a granica sondowania, która dokładnie pokrywa się z przybyciem, traci je. Nakładanie ponownie wysyła zapytanie, a już widziany sprawdzian zatrzymuje duplikat - więc koszt nakładania jest nieznacznie większym zapytaniem, a koszt braku nakładania jest cicho pominiętym badaniem.

22.5.10 limit

Limit ogranicza liczba dopasowań akceptowanych z jednego sondowania.

Defaults to 500.

Ograniczenie zamiast braku ograniczenia, ponieważ źle wpisany klucz dopasowania zmienia to w "daj mi wszystko", a pierwszym objawem tego wobec prawdziwego archiwum jest pytanie administratora archiwum, kto uderza w nie.

22.5.11 limit czasu

Limit czasu ogranicza jedno sondowanie.

Domyślnie ustawiony na dwie minuty.

22.5.12 emit_on_first_poll

EmitOnFirstPoll wysyła komunikaty dla wszystkiego, co pierwsze sondowanie znajdzie.

Domyślnie ustawiony na false.

False ma znaczenie. Wskazywanie tego na archiwum, które już zawiera milion badań i powodowanie, że wysyła komunikat dla każdego, nie jest przydatnym pierwszym uruchomieniem, i jest to rodzaj błędu, który jest zauważalny w dół strumienia, a nie tutaj. Pierwsze sondowanie rejestruje, co istnieje i nie emituje nic; drugie sondowanie i dalej raportuje, co jest nowe.

22.6 Źródło DICOM

DICOMSource otrzymuje obiekty obrazowania jako dostawca klasy usługi C-STORE.

To, na co szpital wskazuje aparat lub PACS. Mirth nazywa to słuchaczem DICOM i wykonuje tylko C-STORE, więc jest to równość, a nie podzbiór.

Zdefiniowane jako DICOMSource w internal/config.

22.6.1 listen

Listen to jest adresem, na którym ma być obsługiwany.

Wymagany. 104 to zarejestrowany port DICOM; 11112 to powszechny alternatyw, gdy wiązanie portu uprzywilejowanego nie jest możliwe.

22.6.2 ae_title

AETitle to nazwa, którą ten punkt końcowy nazywa siebie.

Zdecydowanie zalecane, a nie wymagane, i ostrzegane, gdy jest nieobecne. Jedynym mechanizmem kontroli dostępu na punkcie końcowym DICOM jest często tytuł AE, więc punkt końcowy, który akceptuje dowolny tytuł, akceptuje wszystko, co może do niego dotrzeć.

22.6.3 allowed_calling_ae

AllowedCallingAE lista tytułów AE dozwolonych do połączenia.

Pusty lista akceptuje dowolnego nadawcę.

To jest mechanizm kontroli dostępu, jaki ma DICOM. PACS jest zwykle konfigurowany do akceptowania jednego nazwanego tytułu wywołującego i odrzucania wszystkiego innego, a ten koniec nie miał równorzędnego: sprawdzany był tytuł wywołany - który jest nazwą, którą nadawca wybiera, więc każdy może go poprawnie wysłać - podczas gdy to, kto wywoływał, było rejestrowane w dzienniku i w przeciwnym razie ignorowane.

Pusty lista nadal akceptuje wszystko, ponieważ urządzenie, którego nikt nie wymienił, jest normalnym stanem pierwszej instalacji, a odmowa domyślnie złamałaby każde wdrożenie w dniu jeden. Zamiast tego ostrzega, a ostrzeżenie wymienia tytuły, które się połączyły, więc ktoś może wypełnić to na podstawie tego, co faktycznie przybyło.

22.6.4 sop_classes

SOPClasses ogranicza rodzaje obiektów do zaakceptowania.

Pusty lista akceptuje dowolny.

Pusty jest rozsądną wartością domyślną w tym miejscu, ponieważ ten silnik przekazuje obiekty, zamiast je interpretować, więc odmowa nieznanego klasy odmówiłaby ważne obrazy bez korzyści.

22.6.5 transfer_syntaxes

TransferSyntaxes ogranicza kodowania do zaakceptowania, w preferowanym porządku.

Pusty lista akceptuje trzy nieściskane.

22.6.6 max_object_bytes

MaxObjectBytes ogranicza jeden otrzymany obiekt.

Zero stosuje wartość domyślną.

22.6.7 idle_timeout

IdleTimeout zamyka stowarzyszenie, które poszło cicho.

Zero oznacza nigdy, co jest zwykle słuszne - modalność utrzymuje powiązanie otwarte między badaniami.

22.6.8 tls

TLS szyfruje połączenia przychodzące i może wymagać certyfikatu klienta.

Warto to powiedzieć wprost: Mirth potrzebuje swojego płatnego rozszerzenia SSL Manager do tego, a fork społeczności nie może go w ogóle dostarczyć. DICOM przenosi nazwy pacjentów w swoich metadanych, więc to jest jedno z miejsc, w którym bycie przepisanym zamiast forkowanym jest prawdziwą zaletą, a nie stylistyczną.

22.7 Źródło Mweb DICO

DICOMwebSource akceptuje żądania STOW-RS.

Zdefiniowane jako DICOMwebSource w internal/config.

22.7.1 listen

Listen to jest adresem, na którym ma być obsługiwany.

Required.

22.7.2 path

Ścieżka to korzeń usługi.

Obiekty są akceptowane w ścieżce/studies i ścieżce/studies/{uid}. Domyślnie jest to /dicom-web, co używają Orthanc i dcm4chee, więc nadawca skonfigurowany dla jednego z nich potrzebuje tylko zmienionego hosta.

22.7.3 token

Token, jeśli jest ustawiony, jest wymagany jako token nośnikowy.

Nazwa użytkownika i hasło wymagają uwierzytelniania HTTP Basic.

22.7.4 nazwa użytkownika

Token, jeśli jest ustawiony, jest wymagany jako token nośnikowy.

Nazwa użytkownika i hasło wymagają uwierzytelniania HTTP Basic.

22.7.5 hasło

Token, jeśli jest ustawiony, jest wymagany jako token nośnikowy.

Nazwa użytkownika i hasło wymagają uwierzytelniania HTTP Basic.

22.8 Źródło bazy danych

DatabaseSource odczytuje wiersze z bazy danych i przekształca każdy z nich w wiadomość.

To jest sposób, w jaki wiele interfejsów szpitalnych faktycznie zaczyna się. System departamentu nie ma możliwości HL7, więc ktoś zapisuje wiersze do tabeli buforowej, a silnik interfejsu sonduje ją. To nie jest glamour, a jest wszędzie.

To jest również najczęstszy sposób, w jaki kanał Mirth zatrzymuje się, a powodem jest zwykle ta sama forma: wiersz, który nie może być przetworzony, jest odczytany, nie powiedzie się i jest odczytany ponownie, na zawsze, ponieważ nic nie oznaczyło go. Kanał wygląda na żywy. Kolejka wygląda na pustą. Nic się nie porusza, a każda wiadomość za złym wierszem czeka na wiersz, który nigdy nie powiedzie się.

Większość projektu tutaj dotyczy tego.

Zdefiniowane jako DatabaseSource w internal/config.

22.8.1 sterownik

Sterownik określa nazwę bazy danych.

See SupportedDrivers.

22.8.2 dsn

DSN to ciąg połączenia.

Wolą jest odniesienie do zmiennej środowiskowej zamiast literalu, ponieważ zwykle zawiera ono hasło, a kanały są przeznaczone do użycia w git.

22.8.3 zapytanie

Zapytanie wybiera wiersze oczekujące na wysłanie.

Required.

Muszą to być wybrane wiersze. Zapytanie, które wykonałoby polecenia zapisu w trybie cichym, uruchamiałoby się według harmonogramu bez rekordu zmian.

22.8.4 po_zapytaniu

AfterQuery oznacza wiersz jako przetworzony i uruchamia się z kluczem wiersza powiązanym z nim.

Strongly recommended.

Bez tego każde zapytanie ponownie odczytuje każdy wiersz, który nadal pasuje do zapytania, więc samo zapytanie musi wykluczyć wiersze przetworzone w inny sposób. Jeśli żadna z nich nie jest prawdziwa, kanał ponownie wysyła te same wiersze na zawsze, co jest burzą duplikatów, a nie zatorami i jest wręcz gorsze.

22.8.5 kolumna_klucza

KeyColumn identyfikuje wiersz dla AfterQuery, kwarantanny i deduplikacji.

Wymagane, gdy AfterQuery jest ustawione.

22.8.6 szablon

Szablon tworzy wiadomość z wiersza.

Wymagane jest albo to, albo kolumna.

Odwołania do kolumn używają ${nazwa_kolumny}. Brakujące kolumny są błędem podczas ładowania, a nie pustym ciągiem w wiadomości klinicznej.

22.8.7 rozmiar_partii

BatchSize ogranicza wiersze pobrane podczas zapytania.

Defaults to 100.

Ograniczone, ponieważ nieograniczone pierwsze zapytanie do tabeli, którą ktoś wypełniał przez rok, odczytałoby całą jej zawartość do pamięci i wysłałoby ją, co powodowałoby, że migracja zalewałaby żywego odbiorcę.

22.8.8 maksymalna_liczba_prób

MaxAttempts określa, ile razy pojedynczy wiersz może nie powieść się, zanim zostanie poddany kwarantannie i zapytanie przejdzie dalej.

Defaults to 3.

To ustawienie zapobiega zatorom. Ponowne próby bez ograniczeń nie są odpornością; jest to jeden zły wiersz, który zatrzymuje karmienie szpitala.

22.8.9 limit_czasu_zapytania