1 Innledning

Perfuse flytter kliniske meldinger mellom systemer som aldri var designet til å snakke med hverandre. Et laboratorium sender resultater i HL7 v2; praksisadministrasjonssystemet forventer dem med forskjellige feltstillinger, en annen pasientidentifikator og en bekreftelse innen fem sekunder. Noe må sitte i midten, og det er en integrasjonsmotor.

Denne manualen beskriver hva Perfuse gjør, hver enkelt valgmulighet den aksepterer, og — der en avgjørelse ikke er åpenbar — hvorfor den fungerer på den måten den gjør.

1.1 Hva Perfuse er for

En enkelt grensesnitt mellom to kliniske systemer er vanligvis priset i titusener av kroner, med femten til tyve prosent av det igjen hvert år i vedlikehold. Mye av denne kosten er ikke arbeidet; det er at arbeidet krever noen som har gjort HL7 før, og de fleste praksiser har ikke ansatt en slik person.

Perfuse er bygget på antagelsen at personen som konfigurerer den har et problem å løse og ingen tidligere HL7-erfaring. Denne antagelsen viser seg i bestemte steder:

• Alt er konfigurerbart fra nettgrensesnittet. En funksjon som bare er tilgjengelig fra en terminal eller en håndredigert fil, behandles som en feil, ikke et designvalg.
• Meldinger kan spores ett transformasjonssteg om gangen, og viser hva hvert steg leste, hva det endret, og hva det hoppet over og hvorfor.
• Testtrafikk kan genereres som matcher formen på en ekte strøm uten å inneholde noen av dens data.
• En kanal kan foreslås fra en enkelt eksemplarmelding, med en eksplisitt uttalelse om hva eksemplet ikke kan fortelle deg.
• Før en eksisterende motor erstattes, kan dens utgang og Perfuses utgang sammenlignes melding for melding, med forskjellene gruppert etter felt.

1.2 Hva som er i det

Alt under er i den ene binærfilen. Hver linje navngir kapittelet som dekker det.

• Formater. HL7 v2, FHIR R4, R4B og R5, DICOM, X12 (837, 835, 270/271, 276/277, 834, 278, 275), C-CDA og CDA, HL7 v3, NCPDP Telekommunikasjon og SCRIPT, SMART Health Links og Cards, avgrenset og rå. Se meldingsformater.
• Koblinger. 28 kilde-typer og 32 destinasjons-typer, blant annet MLLP, filer, SFTP, databaser, DICOM, Kafka, AMQP 1.0, MQTT, IBM MQ og AWS, Azure og Google Cloud-lagring og meldingsutveksling. Se kilde-referansen og destinasjons-referansen.
• Endring av meldinger. Filter, elleve deklarative transformasjonssteg, JavaScript (Mirths dialekt inkludert) og Lua, felles kartleggings-tabeller og kode-sett, og kartleggings-forslag. Se filtrering og transformasjon.
• Levering av dem. En varig, ordnet kø per destinasjon, gjentakelser, døde brev som beholder meldingen, og kvitteringer sendt etter levering. Se levering og kvitteringer.
• Overvåking av kjøringen. Dashboards, team-dashboards, en flyt-kart, elleve typer varsler, målinger, sporing og en meldings-lager som finner en pasients meldinger på tvers av formater. Se varslings-system, meldings-lageret og feilsøking.
• Endring av en live-grensesnitt trygt. Skygge-modus, feed-kontrakter, kanal-tester og motor-sammenligning. Se testing.
• Forlating Mirth. Mirth, Open Integration Engine og BridgeLink-kanaler forklart, oversatt og eksportert tilbake. Se migrering.
• Betalere og offentlig helse. De fire CMS-0057 API-ene, Da Vinci CRD, DTR, PAS, PDex og Plan-Net, CARIN Blue Button, et valgfritt beslutnings-tjeneste, eCR og ELR. Da Vinci CRD, DTR og PAS besvarer både deres 2.2.x og deres 2.1.0-utgaver. Se CMS-0057.
• Hvem som kan gjøre hva. SAML, OpenID Connect, LDAP, passord-nøkler, SCIM, gjensidig TLS, seks roller, kanal-grupper med en rolle i hver, leietakere, en SMART-autorisering-server, TEFCA og UDAP, og en overvåkings-logg. Se sikkerhet.
• Kjøring av det. En statisk binær-fil for Linux, macOS og Windows, som en tjeneste, med en flåte-oversikt over flere servere. Se drift, web-grensesnittet, kommando-linjen og server-valg.

1.3 Standarder og versjoner

Hvilken utgave av hver standard Perfuse implementerer, og hvordan dette ble sjekket. "Sjekket" navngir den eksterne verktøyet eller referansen som dømte resultatet; hvor ingenting utenfor har dømt det, sier det det. Resultatene er fra testdata, ikke fra en produksjonssted.

1.3.1 Meldinger og dokumenter

1.3.2 FHIR-implementeringsveiledninger

1.3.3 Nasjonale og europeiske profiler

Kontrollert ved å konvertere offentliggjorte eller oppfunne HL7 v2-meldinger og validering av hver ressurs; fullstendige resultater og årsaker til hver feil er i repositoriets conformance/national-mappe.

Ingen av dette er en sertifisering. Perfuse har ikke blitt sertifisert av ONC, CMS, gematik, Nictiz, NHS England eller noen andre.

1.4 Hva det erstatter

Perfuse dekker det området som Mirth Connect holder, og kan importere Mirth-kanal-eksport direkte. Kapittelet om migration beskriver hva som oversettes rent, hva som trenger en avgjørelse, og hvordan man kan bevise at resultatet matcher før man bytte ut.

Forskjellene som teller i daglig bruk er feilsøking og stillhet. I Mirth betyr å se hva en transformer gjorde med en melding vanligvis å gjeninnføre kanalen med logging lagt til. I Perfuse kan enhver innspilt melding spilles tilbake gjennom den nåværende konfigurasjonen og inspiseres steg for steg, uten å berøre den kjørende kanalen. Og hvor en Mirth-varsel på "ingen trafikk" er en fast terskel som er nytteløs på noen strøm som er stille om natten, lærer Perfuse hva hver strøms normale uke ser ut og varsler mot det.

1.5 Hvordan å lese denne manualen

De første kapitlene er konseptuelle og er verdt å lese i rekkefølge: kanaler, meldingsstrøm, deretter transformasjon. Alt etter det kan leses etter behov.

Referanskapitlene nær slutten lister opp hver konfigurasjonsnøkkel, dens type, om den er påkrevd og dens standardverdi. Disse kapitlene er generert fra kildekoden, så de kan ikke beskrive en valgmulighet som ikke eksisterer eller utelate en som gjør det. Hvis en nøkkel vises i en konfigurasjonsfil og ikke i indeksen, er det ikke en Perfuse-nøkkel.

1.6 Konvensjoner

Konfigurasjonen er YAML. De fleste nøklene er snake_case på nettet — max_message_size, idle_timeout — og denne håndboken gir alltid nettformen, fordi det er det du skriver. Det er ett gammelt unntak, dataType på en kanal, som er camelCase; det er dokumentert på den måten i kanalreferansen og aksepteres bare i den stavingen.

Feltreferanser i HL7 bruker den vanlige notasjonen: PID-5 er det femte feltet i PID-segmentet, PID-5.1 er dens første komponent, og PID-3(2) er den andre gjentakelsen av det tredje feltet. En sti skrevet uten en gjentakelse addreserer hver gjentakelse (se stier).

Varigheter skrives som et tall og en enhet — 30s, 5m, 2h. Et bart tall er ikke en varighet og vil bli avvist i stedet for å bli gjettet på.

2 Komme i gang

Perfuse er en enkelt binær fil med en innebygd webgrensesnitt. Det er ingen applikasjonsserver å installere, ingen database å etablere og ingen separat administrasjonskonsoll.

2.1 Kjøre den

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

-channels er en mappe med YAML-filer, en per kanal. -db er en SQLite-fil som inneholder innspilte meldinger, brukere og revisjonslogg; den opprettes hvis den ikke eksisterer.

Ved første start uten konfigurerte brukere, opprettes en administrator-konto og dens passord skrives til loggen en gang. Det passordet kan ikke gjenopprettes senere.

2.2 Den første kanalen

En kanal trenger et navn, en kilde og minst en destinasjon. Den minste nyttige kanalen mottar HL7 over MLLP og skriver hver melding til en fil:

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

Lagre det som channels/first-feed.yaml og det blir plukket opp uten omstart.

Tre ting om den filen er verdt å merke seg, fordi de er formen på hver kanal:

• Kildeblokken er flat for MLLP. listen sitter direkte på source, ikke inni en source.mllp-blokk. Transporter som trenger mer enn en adresse — HTTP, SOAP, DICOM — har sin egen underblokk, og disse er listet opp i kildereferansen.
• En fildestinasjon trenger både root og dir. root er grensen som stier blir løst mot og ikke kan slippe ut av; dir er hvor meldinger havner innenfor den.
• Det finnes ingen transformasjon og ingen filter. Begge er valgfrie, og en kanal med hverken bare sender meldinger videre.

2.3 Bygge en kanal fra grensesnittet

Alt ovenfor kan gjøres fra webgrensesnittet i stedet, og for en første kanal er det den bedre ruten fordi skjemaet ikke lar deg produsere en fil som ikke laster.

Byggeren tilbyr tre måter å komme inn:

1. Fra en melding noen sendte deg. Lim inn eksempelet laboratoriet eller leverandøren sendte. Perfuse leser det og foreslår en kanal, sammen med tre separate lister: hva eksempelet viser, hva som er gjettet, og hva ingen eksempel kan fortelle deg. Dette er beskrevet i testing.
2. Fra noe som allerede fungerer. En samling komplette kanaler som bare trenger å fylle inn adresser.
3. Fra ingenting. Et tomt skjema. Tilgjengelig, men det er den sloweste av de tre og den enkleste å få feil.

2.4 Verifisere at det fungerer før du kobler noe

To ting kan gjøres før sendesystemet eksisterer.

Send en melding for hånd fra grensesnittet — meldingsavsenderen aksepterer limt inn tekst og rapporterer hva som skjedde med den, inkludert hvilke destinasjoner aksepterte den og hva hver transformasjon gjorde.

Eller generer testtrafikk. Hvis kanalen har håndtert noen meldinger overhodet, kan Perfuse lære deres form og produsere flere meldinger like dem, i samme proporsjoner, uten noen av det opprinnelige innholdet. Se testing.

2.5 Hva du skal gjøre neste

• Kanaler forklarer hva en kanal er og hvordan dens deler passer sammen.
• Meldingsflyt følger en melding fra ankomst til levering, som er den raskeste måten å forstå hvor du skal plassere en endring.
• Varsling er verdt å sette opp før en feed går live, heller enn etter den første hendelsen.

3 Web-grensesnittet

Perfuse er bygget på antagelsen om at alt kan gjøres fra nettleseren, og en funksjon som bare kan nås ved å redigere en fil, behandles som en feil. Dette kapitlet er en tur gjennom hva som ligger bak hver del av navigasjonen, organisert på samme måte som grensesnittet: etter spørsmålet du stiller.

Baren har Oversikt og Kanaler direkte, fordi de er der de fleste sesjoner starter og slutter. Alt annet er gruppert, og gruppene er navngitt etter spørsmål rather enn etter undersystemer — du går ikke til "revisjonsundersystemet", du går og finner ut hvem endret noe.

3.1 Lesing av toppfeltet

Fem ting i headeren er lett å overse.

Hver visning har en adresse. Adresselinjen følger visningen — #/channels, #/messages, #/settings — så en omlasting returnerer til den, en bookmark åpner den, en lenke sendt til en kollega lander dem på den, og tilbake-knappen flytter mellom visninger heller enn å forlate konsollen. En adresse som navngir en visning over din rolje åpner dashbordet i stedet.

Søk, eller ⌘K. Det søker over kanaler, innstillinger, meldinger og manualen, som betyr at det vanligvis er raskere enn å navigere — spesielt for en innstilling hvis navn du halvt husker.

Tema. Tre av dem: Midnight, Dark og Light. Midnight er nær-svart og er hva en veggbakke i et serverrom vanligvis ønsker; Dark er en mykere nøytral grå; Light er for en bærbar datamaskin ved et vindu. Valget lagres i nettleseren rather enn mot kontoen, fordi et tema er en egenskap ved hvor noen sitter, ikke hvem de er — samme operatør ønsker Midnight på veggen og Light på et tog. En maskins eget valg konsulteres en gang, for å velge en fornuftig standard første gang.

Språk. Konsollen er på engelsk (UK eller US datoorden), tysk, fransk, nederlandsk, spansk, italiensk, portugisisk, polsk, svensk, dansk, norsk eller finsk, med datoer og tall skrevet på måten som denne locale skriver dem. Valget lagres i nettleseren, og nettleserens eget språk brukes til en valg er gjort. Oversettelsene ble gjort av maskin og har ikke blitt gjennomgått av native talere ennå; engelsk er referansen, og velgeren sier det. Kode, meldinger, payload, kanalnavn og alt som tastes inn blir aldri oversatt. Manualen publiseres på samme språk på https://perfuse.health/manual/<language>/ (denne serverens egen Manual er den engelske).

Manual. Dokumentet du leser, betjent av den kjørende serveren. Det er samme filen som binærfilen kan skrive til disk, så det beskriver alltid versjonen foran deg rather enn den siste utgivelsen.

3.2 Overvåk — om det fungerer, og hva skjedde

3.2.1 Oversikt

Tilstanden til hver kanal, gjennomstrømming og hva som er galt for øyeblikket. Dette er skjermen som skal være åpen.

3.2.2 Meldinger

Hver melding som ankom, hva den ble transformert til, per destinasjon, og hva som skjedde med den. Søkbar, inkludert etter et filteruttrykk, så "vis meg de fra denne avsenderen som ble avvist" er et spørring rather enn en ettermiddag.

Et melding kan spilles av igjen her, og bearbeides på nytt gjennom den *nåværende* konfigurasjonen, i stedet for den som var aktiv på det tidspunktet — som er hvordan du bekrefter at en fiksering fungerer mot trafikken som førte til feilen. Se meldingslagret for hva som lagres og for hvor lenge.

3.2.3 Kø

Hva som venter på å bli levert, og hvorfor. En kø som ikke tømmes er den mest nyttige tidlige advarsel en integrasjonsmotor produserer, og det er verdt å kombinere med en varslingsregel så ingen behøver å overvåke. Se levering.

3.2.4 Varslinger

Hva som har utløst og hva reglene er. Regler redigeres her i stedet for i en fil. Se alerting.

3.2.5 Målinger

Gjennomstrømming, forsinkelse og feilrater over tid. Nyttig for kapasitets-spørsmål og, oftere, for styre-pakker — som er hvorfor nettstedets eget logo vises på det hvis en har blitt lastet opp.

3.2.6 SQL på FHIR

SQL på FHIR-visninger: velg et eksempel eller en lagret visning, eller skriv en, kjør den over denne serverens FHIR-lagring (alle pasienter eller en) eller over ressurser limt inn, se radene med deres typer, og last ned CSV, NDJSON eller Parquet. Lagre beholder den for FHIR-endepunktets $sql-run. Se meldingsformater.

3.2.7 Kvalitetsmål

Digitale kvalitetsmål: velg et eksempel eller et mål i FHIR-butikken, eller skriv ett med FHIRPath-kriterier. Velg et målingsperiode og en rapport (sammendrag, sammendrag med pasientlister eller en pasient) og evaluér det over FHIR-butikken eller limt ressurser. Skjermen viser hver populasjons teller og pasienter, scoren og strata. Last ned Målerapport lagrer FHIR-resultatet, og Lagre til FHIR-butikken beholder målet for Measure/$evaluate-measure. Mål i CQL avvises: Perfuse har ingen CQL-motor. Se digitale kvalitetsmål.

3.2.8 Flytkart

Et bilde av hvordan meldinger faktisk flyter: hvilke kilder mater hvilke kanaler, og hvilke destinasjoner de når.

Verdien er ikke dekorasjon. Hver eiendom akkumulerer en kanal som ingen husker å ha bestilt og en destinasjon som ingen innser fortsatt mottar, og begge er synlige her på en måte de ikke er i en liste over kanalfiler.

3.2.9 Teamdashbord

En dashboard for hver type person som overvåker grensesnittene: Drift, Tilkoblinger, Grensesnittsanalyse, Forhåndsgodkjenning, Bilde, Inntekts_syklus, Laboratorium, Personvern og sikkerhet, og en enkel ord-avdelingssammendrag. Fliser viser tellere, stater og tider, aldri en melding eller en pasient, så en dashboard kan gå til en leder eller en veggskjerm uten å utvide hvem som ser pasientdata.

Hver person åpner dashbordet sitt fra kataloggruppen eller rollen som er gitt. -dashboards dashboards.yaml kartlegger dem:

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

En gruppe seirer over en rolle, og enhver som ikke er koblet åpner på Drift. Arranger fliser skjuler og omprioriterer fliser, kanalvelgeren filterer dem, og Lagre som min utsikt holder det som din egen dashboard til Tilbakestill.

Eksporter til Grafana laster ned dashboardet som Grafana JSON over /metrics, med en datakildevariabel og en kanalfilter, for alle som trenger mer enn lett konfigurasjon. Fliser uten en metrikkbak dem utelates, og eksportbeskrivelsen navngir dem.

Den Tilkoblinger-flisen sjekker hver nettverksdestinasjon i lag. Den ser opp navnet, åpner en TCP-tilkobling, fullfører TLS der det brukes, og leser destinasjonens siste levering og feil fra ekte trafikk. Hver feil sier hva det betyr, for eksempel «avvist: partnerens motor er sannsynligvis stoppet», «tidsavbrudd: en brannmur eller en VPN-tunnel som er nede», eller «et sertifikat fra en myndighet denne serveren ikke stoler på». Ingen blir sendt til partneren, med ett unntak: en vaksinasjonsregister som har hatt ingen trafikk på syv dager blir bedt om sin CDC connectivityTest, som sender ingenting. Med -vpn tunnels.yaml VPN-tunneler-flisen ved siden av den leser hver partner-tunnels tilstand fra AWS Site-to-Site VPN, en Azure VPN Gateway-tilkobling eller strongSwan på denne verten, så et tidsavbrudd kan skilles fra en tunnel som er nede. Den sammenligner også begge sidene sine IKE- og IPsec-innstillinger, da skyen rapporterer våre og filen lister deres, og sier hvor de ikke kan enes. Tilkoblingsskjema laster ned en partners innstillinger side om side som Markdown for å sende dem; den holder aldri en forhåndsdelte nøkkel. Figurer en dashboard trenger som ikke er registrert ennå, listes under Ikke målt ennå i stedet for å tegnes som tomme fliser.

Departementdashbordene beregner sine egne tall på serveren, og hver enkelt sier hva vinduet og kilden dekker:

• Forhåndsgodkjenning: PAS-forespørsler avgjort innen CMS-0057's 72 timer (hastet) eller 7 dager (standard), avgjort for sent, ventende og forsinket nå, samt median tid til avgjørelse. Også hvordan tjenestene som ble bedt om ble besvart (godkjent, modifisert, avvist, utsatt), som hver står nå, over 30 dager.
• Bildebehandling: objekter mottatt av C-STORE per modalitet, og de som ikke ble levert. Også routingsforsinkelsen per kanal (median og 95. percentil), C-FIND-spørringer og feil per spørrekanal, og bilde-rapporter (en ORU hvis OBR-24 er en bilde-seksjon, eller en MDM) som ikke nådde hver destinasjon.
• Inntekts-syklus: 999 transaksjonssett akseptert, akseptert med feil og avvist, og 277CA-krav akseptert og avvist (A3, A4, A6, A7, A8). Også 835-krav som ble matchet med pasientkonto-nummer til 837-er sendt gjennom denne serveren, og de vanligste avvisningsårsakene.
• Laboratorium: resultattid, fra mottak til den siste destinasjonens bekreftelse, og kritiske resultater (OBX-8 HH, LL, AA, > eller <) som ikke nådde hver destinasjon.
• Personverns- og sikkerhet: hvem åpnet meldinger, søkte etter pasienter eller leste forhåndsgodkjenninger i konsollen over 7 dager, fra revisjonsloggen (å åpne en melding blir loggført som message.read). Også hver aktiv API-nøkkel og når den ble sist brukt; en nøkkel som ikke har blitt brukt på 90 dager blir markert.

3.2.10 Deling av hva en feed faktisk inneholder

Profil denne feeden rapporterer hva som faktisk ankommer: hvilke utløsende hendelser, hvilke felt er fylt ut og hvor ofte, hva formen på verdiene tar, og hvilke koder en avsender faktisk bruker. Den siste er vanligvis den mest nyttige enkeltfakta i den.

En profil kan lastes ned og sendes til noen andre. Den trenger et navn og — påkrevd — hvilket system som produserte feeden, fordi spørsmålet en fremmed stiller til en delt profil er om den beskriver deres system, og et valgfritt felt ville gjøre "Ukjent" til det vanligste svaret i noen delt samling.

Den inneholder ingen pasientdata, og det blir sjekket heller enn antatt. En profil er statistisk: tellere, rater, lengder, former. Verdier beholdes bare for felt som standarden definerer som kode-tabeller, fordi en kode-tabellverdi ikke er identifiserende. Identifikatorverdier blir aldri listet.

To følgende punkter kommer fra at dette er et løfte snarere enn et håp. Serveren bygger profilen på nytt fra lagrede meldinger når du eksporterer den, i stedet for å sende den som vises på skjermen — så det som forlater bygningen, ble sammensatt av profileren, som har en test som beviser denne egenskapen, og ikke av en nettleser. Og eksporten avviser helt åpenbart hvis en profil noen gang lister verdier for et felt som ikke er en kode-tabell, og navngir feltet, men ikke verdiene.

En profil som ankommer fra et annet sted, blir sjekket på samme måte på vei inn, av en annen grunn: den ble produsert av noen hvis omsorg er ukjent, og å vise pasientens identifikatorer ville være en avsløring fra denne serveren. Å importere en endrer ingenting — en profil beskriver en feed, og hva som skal gjøres med den, er en separat beslutning.

3.3 Bygg — endre hva en kanal gjør, og prøv det før det er live

3.3.1 Kanaler

Kanalbyggeren. Kilder, mål, filtre, transformasjoner, skript og tester, med den genererte YAML-filen vist ved siden av skjemaet mens du arbeider — så filen er aldri en mysterium, og alle som foretrekker filen, kan følge med.

Se kanaler for hva delene er, og transformasjon for hva stegene gjør.

3.3.2 Skript

En arbeidsplass for skript, adskilt fra byggeren fordi å skrive et skript og å koble et skript er forskjellige aktiviteter.

Alle syv plasser blir tilbudt — filter, transformer, preprosessor, postprosessor, skriver, livssyklus og leser — og å velge riktig plass, er viktig, fordi plassen bestemmer hva skriptet mottar og hva det forventes å returnere. Å sjekke et skript som feil type, er ikke en midlertidig løsning; det kompilerer en annen ting.

JavaScript, Lua og WebAssembly er alle tilgjengelige. Se transformasjon.

3.3.3 Kontrakter

Forventninger om hvordan en feed må se ut, opprettet og sjekket her samt fra perfuse contract. Se kommandolinjen.

3.3.4 Tabeller

Oppslagstabeller og kode-sett: mappingene som omdanner en systems kode til en annens. Redigerbart her så å legge til en kode ikke er en distribusjon.

3.3.5 AI Mapper

Forslag om felttilordninger med en konfidensscore for hver, og avstår heller enn å gjette. Til tross for navnet bruker den ingen språkmodell og gjør ingen nettverksanrop: forslagene kommer fra regler, feltnavn og eksemplets innhold, på denne serveren. Den foreslår også en kanal fra en enkelt eksempelmelding, og uttaler eksplisitt hva eksemplet ikke kan fortelle den. Den andre halvdelen er den delen som gjør den pålitelig — et forslag som så ut til å være fullstendig ville invitere deg til å tro ting meldingen aldri sa.

3.3.6 Lekeplass

En skissebok for meldinger og transformasjoner. Lim inn en melding, aplikér steg, se resultatet.

Ingenting blir sendt noen sted en gang siden siden har lastet, som er grunnen til at den eksisterer i denne formen: det er trygt å lime inn noe reelt inn i, med forståelse av at det blir i nettleseren.

3.3.7 Skygge

Kjører trafikk gjennom en kandidatkonfigurasjon sammen med den live konfigurasjonen og rapporterer forskjellene, så en endring kan dokumenteres før den godkjennes. Samme idé som perfuse compare, men anvendt på en endring i stedet for en migrering. Se testing.

3.4 Utveksling — standardene denne serveren snakker til andre organisasjoner

3.4.1 FHIR lab

Konverter HL7 v2 til FHIR, valider en ressurs, og inspisere resultatet. Eksemplene dekker innleggelse, laboratorie-resultater, avtaler, kliniske notater, vaksinasjoner og en rapporterbar besøk. Valideringen inkluderer US Core, som er profilen amerikansk regulering er skrevet mot, så dette svarer på "er det de sendte oss faktisk konformt" uten å adoptere noe.

Offentlig helse-sak-rapport bygger eCR eICR en sak-rapport-destinasjon ville sende for meldingen. Den viser hvilken utløser-kode gjorde besøket rapporterbar, hva rapporten måtte markere som manglende, og dokumentet selv. En melding med ingenting rapporterbar, får grunnen i stedet. Ingenting blir sendt fra her.

3.4.2 Abonnementer

FHIR-abonnementer og om deres varslinger ankommer: hendelser, aksepterte, ventende og siste grunn til at en ble avvist. Abonnementer opprettes av FHIR-klienter gjennom FHIR-APIen, ikke fra denne siden, og legitimasjonen de ga serveren vises aldri. Se meldingsformater.

3.4.3 Dokumenter

Kliniske dokumenter — CDA og den trykkbare formen av et dokument. Nyttig når det som utveksles er en utskrivelsesoppsummering i stedet for en melding.

3.4.4 Dokumentdeling

IHE XDS.b-registret og -lageret som startet med -xds: hvor mange dokumenter, pasienter og innsendelsessett det inneholder og hvor mange som ble erstattet; adressene til lageret, registret, XCA-gatewayen og MHD; en søk etter en pasients dokumenter i dette registret eller et annet samfunns (et ITI-18-registrer eller en ITI-38-gateway, med en token for det); og publisering av et CDA-dokument manuelt, med fasilitets typen og praksisinnstillingen et dokument ikke sier. Se meldingsformater.

3.4.5 Direkte

Direkte sikker meldingsutveksling. Denne serverens Direct-adresser listar hver adresse en kanal sender eller mottar som, med dens sertifikat, når det utløper, de ankrene det stoler på, og hva som er galt (en manglende fil, et utløpt sertifikat). Adressboken holder korrespondenter og sertifikatene deres e-post er kryptert til: lim inn ett fra deres HISP, eller Lagre med sertifikatet fra DNS; et sertifikat som ikke er for adressen eller dets domene blir avvist. Finn et sertifikat i DNS spør uten å lagre. Se meldingsformater.

3.4.6 Helselenker

SMART Health Links og Cards, for CMS's *Kill the Clipboard*. Motta en SMART Health Link leser lenken eller QR-koden en pasient viser ved innmelding, verifiserer de helsekortene inne og sender den videre til en kanal. Del en besøksrekord lager en lenke denne serveren hoster, eventuelt med en passkode, og en QR-kode for pasienten; Bruk deres pasientoppsummering fyller den med pasientens Internasjonal Pasientoppsummering fra denne serverens FHIR-lager. Lenker denne serveren hoster listar dem med hvor ofte hver ble hentet, når den utløper og hvor mange passkodforsøk er igjen, og trekker tilbake en. Verifiser en SMART Health Card sjekker et kortsignatur og utsteder på egen hånd. Se CMS-0057 for serverinnstillingene det trenger.

3.4.7 Bilde

Arkivet denne serveren beholder når den kjører med -dicomweb-archive: tellinger av studier, serier, eksemplarer og plassbruk, DICOMweb-adressen og datakildeblokken for en OHIF-leser, og en studiesøk etter pasientnavn, ID, aksessjon og dato gjort med samme QIDO-RS-forespørsel en lesere gjør. En studie åpner til sine serier og eksemplarer, og et eksemplar lastes ned som en DICOM-fil. Ingen rendering skjer: Perfuse flytter bilder og en lesere viser dem. Uten et arkiv sier skjermen hvordan du aktiverer det. Se DICOMweb.

3.4.8 TEFCA

Revisjonsspor for utveksling gjennom et Kvalifisert helseinformasjonsnettverk, og formålet med bruken som styrer det.

To transport, på virkelig forskjellige stadier, og skjermen sier hvilken som er hvilken. Én flagg som dekker begge ville være feil i hvilken som helst retning den var avrundet.

Fasilitert FHIR er implementert, og har aldri snakket med et virkelig QHIN. Den følger Sequoia Project Standard Operating Procedure effektiv 8. mars 2026: oppdag partnerens UDAP-metadata, verifiser det, registrer dynamisk, få en tilgangstoken som bærer formålet med bruken, og spør. UDAP er en offentlig nøkkelinfrastruktur over OAuth 2.0 — et tillitsfellesskap utsteder X.509-sertifikater til medlemmene, og en medlem autentiserer ved å signere JWT-er med den private nøkkelen og vedlegge sertifikatkjeden.

Sikkerhetslaget er verifisert mot noen andres implementering, som er den eneste verifiseringen som er noe verd her. En registrering signert av denne byggingen ble sendt til en live tredjeparts-referanseserver og avvist med unapproved_software_statement — Untrusted: Certificate is not a member of community. For å produsere dette svaret dekodet serveren forespørselen, parserte programuttalelsen som en JWT, sjekket signatur, gikk gjennom sertifikatkjeden og tok en beslutning om medlemskap. Det er forskjellen på å bli avvist ved døren og å få tilbake et uleselig brev.

Hva som gjenstår kan ikke gjøres fra her. Sertifikatet som beviser fellesskapsmedlemskap kommer ut av QHIN-opptak og er ikke noe programvare produserer. Før ett eksisterer, fullfører ingen utveksling med en virkelig partner.

Hvordan en kanal ber. En destinasjon av type tefca ber den facilitatede FHIR-partneren i Innstillinger, TEFCA (tefca.partnerFHIRBase) om hver meldings pasient: ved identifikator når meldingen har en (PID-3, eller en FHIR-pasients identifikator), ellers ved etternavn med fødselsdato, og aldri bare ved navn, fordi en feilaktig sammenligning av navn returnerer en annen persons rekord uten feil. Destinasjonen setter formålet med bruk (behandling, betaling, operasjoner, folkehelser, individuell tilgang); et formål som deltakeren ikke erklærer, avvises før noe sendes. Formål går som TEFCA-utvekslingsformål-koder (T-TRTMNT, T-PYMNT, T-HCO, T-PH, T-IAS, system urn:oid:2.16.840.1.113883.3.7204.1.5.2.1), eller med tefca.purposeCodes: hl7 som HL7-formål-med-bruk-koder for samfunn som bruker disse. Bundlet funnet er destinasjonens svar og kan overføres til en annen kanal med results_to. Hver forespørsel, inkludert avviste, er i sporet på denne skjermen, som navngir partneren.

Hele banen, fra oppdagelse til en token som partnerens FHIR-tjener aksepterer, testes mot udap-dotnet-referanseserveren (se verifisering).

Den eldre QHIN-til-QHIN-utvekslingen bygget på IHE-profilene er ikke implementert. Et forsøk avvises med en feil som sier det, og avvisningen auditeres som en feil. Det er bevisst i stedet for å vente på en opprydning: en stubbet utveksling som rapporterer suksess ville sett inn poster i revisjonsspor for utvekslinger som aldri skjedde, og et spor som ikke er enig med hva som skjedde er verre enn ingen, fordi sporet er hva som blir trodd.

Gjennom hele, kommer endepunktene brukt for utveksling fra signerte deler av en partners metadata, aldri dokumentkroppen. Å verifisere en signatur og deretter lese endepunktene fra den usignerte kopi ville være en komplisert måte å stole på nettverket: en angriper i stand til å omskrive svaret lar den signerte delen være alene, peker token-endepunktet mot sin egen server og samler inn klient-påstander fra alle som sjekket signatur og deretter ignorerte hva den dekket.

Et tillitsankerbunt er påkrevd og fravær refuseres ved oppstart. Å sjekke en partners signerte metadata mot sertifikatet som ankom inni den, beviser bare at en part lagde begge — en feil denne kodebasen har gjort før, i SAML, hvor verifiseren foretrakk det innebygde sertifikatet og autentiserte en angriper som administrator mens alle tester passerte. Inkluder mellomleddene i bunten: en UDAP-tjener trenger bare å sende sitt bladsertifikat, og den offentlige referanseserveren gjør nettopp det.

3.5 Betaler — krav, forhåndsgodkjenning, legemidler og CMS-betalerregler

3.5.1 Krav og autentisering

Bygg en X12 275-kravvedlegg i 006020-formen CMS-0053-F antar, fra en limt C-CDA eller en lastet opp PDF, TIFF eller JPEG, og se det leses tilbake. Les en 275 og last ned dokumentet inne. Konverter en X12 278-beslutning til en Da Vinci PAS ClaimResponse. Ingen informasjon på denne siden blir lagret eller sendt. Se meldingsformater for hva 275 er bygget fra og hva den ikke gjør.

3.5.2 Legemidler

Legemiddelformulariet lastet med -formulary, og de to NCPDP-standardene besvart fra det. Formulary listar planene og legemidlene med deres nivå og krav, og hvor de offentlige Da Vinci US Drug Formulary API og NCPDP-endepunktene er. Prissjekk (RTPB) priser et legemiddel for en medlem som en reseptors Real-Time Prescription Benefit forespørsel ville: dekningstatus, begrensninger i ord med deres koder, medlemmets andel og planens, og billigere alternativer. Forhåndsgodkjenning (ePA) sender en SCRIPT-initiering til denne serverens eget endepunkt, viser spørsmålssettet som en skjema, sender svarene og viser avgjørelsen; under, hver sak med hvor den står og om reseptoren har blitt informert, sakens svar, en knapp for å sende en usendt avgjørelse igjen, og legemiddelfigurene CMS-0062-P foreslår. Se CMS-0057.

3.5.3 CMS-0057

Betalerens side av CMS Interoperability og Forhåndsgodkjenning-regelen, som fem verktøy:

• De fire API-ene: om Pasienttilgang, Tilbydertilgang, Betaler-til-betaler og Forhåndsgodkjenning er klare på denne instansen,

og hva hver av dem ennå mangler.

• Gjennomgangskø: PAS-forespørsler som venter på en person, med de dokumentene som er sendt for hver, og med mulighet til å godkjenne, avvise eller

godkjenne færre enheter. Se gjennomgangskøen.

• Krav til CARIN BB: en 837 og dens 835 konvertert til CARIN Blue Button-pakker.
• Forhåndsgodkjenning til PDex: en PAS-svar konvertert til en PDex-forhåndsgodkjenning.
• Forhåndsgodkjenning-mål: årlige offentlige forhåndsgodkjenning-mål, forhåndsvisning fra en CSV-fil med beslutninger.

Konverteringene lagrer ingen informasjon og sender ingen informasjon.

3.5.4 CMS-sammenstilling

Klarhet for CMS Interoperability Framework: hver av dets 26 kriterier, gruppert som CMS grupperer dem, med hva Perfuse tilbyr, om det er på her, innstillingen som slår det på, og hva organisasjonen må gjøre. Tellene øverst filterer listen. Se CMS-0057.

3.6 Administrer — hvem som kan gjøre hva, og hvordan denne serveren er konfigurert

3.6.1 Brukere

Kontoer, roller (overvåker, viser, operatør, redaktør, admin) og kanalgrupper. Hver persons kanalgrupper redigeres på plass i listen; tom betyr alle kanaler, og lab=editor, adt gir en annen rolle i en gruppe. En administrator begrenset til noen grupper ser bare personene i disse gruppene. Overskriften viser dine egne grupper ved siden av din rolle når du har noen. Se sikkerhet.

Maskinlegitimasjoner er også her. En token er for en maskin i stedet for en person: den utløper ikke og påvirkes ikke av noen som logger ut, hvilket er hva en server som poller sin nabo trenger. Bare en hash lagres, så en token vises bare en gang når den opprettes og kan ikke gjenopprettes — en stjålet database gir ingen brukbar token. Gi den lavest rolle som gjør jobben.

Med MCP på, viser seksjonen også adressen en AI-agent kobler til, en klientkonfigurasjon til å kopiere og hvert verktøy med rollen det trenger; utstedelse av en token med La en AI-agent handle med den gir den mcp:write-omfang. Se sikkerhet.

3.6.2 Leietakere

På en delt server, plattformoperatørens liste over organisasjoner: hver enkelt organisasjons kanalantall og lagrede størrelse ved siden av dens begrensninger (kanaler, meldinger per minutt, lagring), som settes på plass. Vist bare til plattformrollen. Se sikkerhet for hva hver begrensning gjør.

3.6.3 Sertifikater

De TLS-sertifikatene som er i bruk og når de utløper. Utløpsdatoene er poenget: et sertifikat som utløpte på en søndag er en klasse av nedtid som er fullstendig forebyggelig og rutinemessig ikke forebygges.

3.6.4 Aktivitet

Hvem endret hva, og når. Hver konfigurasjonsendring blir registrert, hvilket er hva gjør "det begynte å feile på tirsdag" besvart.

3.6.5 Dataproteksjon

En persons forespørsler under GDPR og UK GDPR, juridiske hold, slettingslogg, oppbevaring og prosessering av aktivitetsrekorder; bare administratorer. Se datatilsyn.

3.6.6 Flåte

Hvert Perfuse-eksempel på en side.

Mirth selger dette som et separat produkt; her er det en konfigurasjonsfil og en skrivebeskyttet token. Grunnen til at det er verdt å ha er smal og viktig: en død server ser ikke ut som en stille en. En enkelt instans' dashboard kan ikke fortelle deg at en annen nettsted stoppet med å rapportere, og en flåtevisning kan.

3.6.7 Migrer

Slipp inn en Mirth- eller OIE-kanal-eksport og se hvor mange av dine kanaler som ville kjøre her uendret. Samme analyse som perfuse explain og perfuse translate, uten å trenge en terminal. Se migration.

3.6.8 Innstillinger

Hver innstilling serveren har, med en kontroll for hver — inkludert de som tradisjonelt bare ville leve i en fil. Hver sier om den trenger effekt med en gang eller trenger en omstart, og om den er satt eksplisitt eller sitter på sin standardverdi.

Innstillingene dekker hver perfuse serve-valg som slår på en funksjon: FHIR-endepunktet og dets versjon, payer-API-ene, PAS og CRD-reglene, X12 278-broen, eCR, SMART-autoriseringsserveren, TLS og signing, målinger, flåte og VPN. De er gruppert som FHIR, Payers, Folkehelse, SMART, Sikkerhet og så videre. Hver er også vist med flagget det korresponderer til.

Omstart fra konsollen. En innstilling merket *Trenger omstart* blir lagret med en gang, men leses bare når serveren starter. Mens noen venter, viser en banner øverst i Innstillinger dem med en Omstart serveren-knapp (signeringseditoren og innstillingfilene tilbyr samme knapp etter en lagring). Den spør først, fordi hver kanal stopper i noen sekunder: hver fullfører meldingen den håndterer, som den gjør når tjenesten stoppes, og sendere sender på nytt hva som ankommer imens. Konsollen venter deretter på at serveren skal svare igjen og leser innstillingene på nytt. Bare en administrator kan omstarte, og hver omstart blir logget i aktivitetloggen som server.restart.

På Linux og macOS erstatter prosessen seg selv med en fersk kopi av samme program og argumenter, og beholder prosess-ID-en, så systemd, launchd eller en container-runtime ser ingenting skje. På Windows starter serveren på nytt inni samme prosess, som holder en Windows-tjeneste under tjenestehåndtereren. Hvis serveren ikke har svart etter to minutter, sier konsollen det; årsaken finnes i serverens logg.

Flagg og innstillingsfilen. Første gang serveren starter, skrives flaggene den fikk med til innstillingsfilen. Deretter er filen viktigere enn flaggene, så endring av en innstilling gjøres i konsollen (eller filen), ikke ved å redigere servicens kommandolinje. Et flagg filen enda ikke nevner, blir registrert når serveren starter med det. Fjerning av et flagg fra kommandolinjen senere vil ikke deaktivere funksjonen: slå den av i Innstillinger.

SNMP har en panel under innstillingene: om agenten svarer og på hvilken adresse, nettverkene det svarer, hvor mange varslingstrapper ble sendt eller mislyktes, og Last ned MIB for basis-OID i bruk. Verdier blir satt under Overvåking, SNMP.

Branding er her også: et nettsted kan sette produktets navn, en slagord, en aksentfarge og laste opp et logo. Logoen vises deretter i headeren, på innloggingssiden, på dashboarden og på rapporteringsskjermbildene. Hvis ingen lastes opp, settes ingenting i stedet — en ubrandet installasjon forblir ubrandet heller enn å tilegne seg dekorasjon.

3.7 Hva fargene betyr

Fire register, og hver sier noe annet. Forskjellen er verdt å nevne fordi det er forskjellen på en skjerm du kan lese på ett blikk og en der alt konkurranse om oppmerksomheten.

Vanlig tekst er en faktum om hvordan Perfuse fungerer. Størsteparten av grensesnittet. Ingen er farget for å fortelle deg at det er viktig.

Grønn betyr at noe lyktes akkurat nå, fordi du gjorde noe. Den vises etter en handling og forsvinner ikke.

Gul er en advarsel: verdt å vite før du handler, og ikke en feil. En funksjon som ikke er slått på, en innstilling hvis endringer er audited, en konvertering som approksimerer heller enn reproduserer, en transport Perfuse håndterer men ikke kan fullt verifisere. Gul er fargen til "les dette før du fortsetter".

Rød betyr at noe er galt akkurat nå. En verdi som ble avvist, en forespørsel som feilet, et sertifikat som har utløpt, en kritisk varsling som utløses. Ingen andre bruker den.

Den siste regelen er hvorfor en skjerm ikke åpner rød. Rød er den eneste fargen som bærer en instruksjon — stopp, og det kan være noe du gjorde — og en skjerm som bruker den på dekorasjon har ingenting igjen å si når inndata faktisk er feil. Dette var ikke alltid sant: brukerskjermbildet åpnet tidligere med "serveren sendte en respons som ikke kunne leses" på hver installasjon som ikke hadde konfigurert passnøkler, og innstillingskjermbildet markerte auditede verdier med samme farge som en avvist en. En test i web/src/RedMeansWrong.test.ts feiler nå hvis en frase som beskriver noe fraværende eller approksimert får en rød stil.

Inni en kodeboks er vokabularet annerledes. Der bærer rød ingen domme i det hele tatt — en HL7-segmentnavn, en XML-element — og er bare en token-type.

4 Kanaler

En kanal er én strøm av meldinger: et sted de kommer fra, valgfrie endringer og ett eller flere steder de går. Den er konfigurasjonsenheten, overvåkingsenheten og driftsenheten. Alt annet i Perfuse eksisterer for å betjene kanaler.

4.1 Anatomi

En kanalfil har disse delene, i rekkefølgen de virker:

Pluss flere som gjelder for hele kanalen: scripts, shadow, contract, tables, attachments, group og enabled. Hver er i kanalreferansen.

4.2 Én kilde, mange destinasjoner

Denne asymmetrien er bevisst og det er verdt å forstå tidlig, fordi det er den eneste vanligste kilden til forvirring når man kommer fra en annen motor.

En kanal har nøyaktig én kilde. Hvis meldinger ankommer fra to steder, er det to kanaler. Å forsøke å uttrykke det som én kanal produserer en konfigurasjon hvor en feil i noen transport ser lik ut fra utsiden, og hvor de to strømmenes trafikk blandes sammen i statistikken — så et fall i én blir skjult av den andre.

En kanal har et hvilket som helst antall destinasjoner, og de er uavhengige. Én feil stopper ikke de andre, og hver har sin egen kø, sin egen gjentakelsespolitikk og sin egen leveringspost. En melding som nådde tre av fire destinasjoner blir registrert som nettopp det, ikke som en suksess eller en feil.

4.3 Destinasjoner er ikke en kjede

Hver destinasjon mottar meldingen slik den var etter kanalens transformasjoner. En destinasjon mottar ikke utgangen av destinasjonen før den.

Dette er viktig når en destinasjon har sine egne transformasjoner, som den kan. Disse gjelder bare for den destinasjonens kopi. En vanlig feil er å legge en endring på den første destinasjonen og forvente at den andre skal se den.

Hvis du virkelig trenger en kjede — utgangen av én strøm som mates inn i en annen — bruk en kanaldestinasjon, som sender til en annen kanal ved navn. Det er eksplisitt, vises i meldingens historikk som to kanaler, og kan overvåkes som to ting, som en skjult kjede ikke kan.

4.4 Navngiving

Navnet er kanalens identitet overalt: i filen, i meldingslagret, i varslinger, i revisjonsloggen og i URL-en. Å endre det er ikke en omnavngiving; det er en ny kanal, og den gamle kanalens historikk blir under det gamle navnet.

group er separat og eksisterer for å organisere grensesnittet. En gruppe har ingen effekt på atferd, og å gruppere kanaler gjør dem ikke til å dele noe.

4.5 Aktivering og deaktivering

enabled: false stopper en kanal fra å starte uten å slette den. Konfigurasjonen, historikken og statistikken blir.

En deaktivert kanal er ikke en pause. Kilden lytter ikke, så en sender som forsøker å koble til får en avvist tilkobling i stedet for en hengt tilkobling. For MLLP er det riktig atferd — senderen vil køe og gjenta — men det betyr at senderens egen feillogg vil fylles opp, så en deaktivert kanal er ikke en erstatning for å avtale en nedetid med den som sender.

4.6 Hvor kanaler bor

Én YAML-fil per kanal, i katalogen gitt av -channels. Filnavnet er ikke kanalnavnet; name-nøkkelen er. Å holde dem like er sterkt rådet og ingenting tvinger det.

Filer leses på nytt uten omstart. En fil som ikke parseres rapporteres og den tidligere lastede versjonen fortsetter å kjøre, så en syntaksfeil kan ikke ta en fungerende strøm av luften.

4.7 Kryptering av en kanals egen lytter

En kanal som lytter på en port er sin egen server, og dens TLS er separat fra TLS på Perfuses nettgrensesnitt. Å sette den ene betyr ikke at den andre settes. For en HTTP-kilde er innstillingene under TLS og grenser på kilde.

Å slå på TLS ber om et sertifikat og en privat nøkkel. Å kreve en klient-sertifikat gjør det til gjensidig TLS: avsenderen må presentere ett signert av en myndighet du navngir, som er autentisering, så en lytter med det på ikke også trenger en delt token — selv om å ha begge er ikke feil.

Myndigheten spørres bare om en gang en klient-sertifikat kreves, og utelates fra filen til da. En kanal som navngir en myndighet som aldri konsulteres, ser ut som om avsendere verifiseres når de ikke er det.

En MLLP-lytter har samme innstillinger under Krypter denne lytteren, med en forskjell verdt å nevne: på MLLP er et klient-sertifikat den eneste autentiseringen som er tilgjengelig. Det finnes ingen token og ingen header, så en lytter uten ett aksepterer meldinger fra enhver vert som kan nå porten.

To grenser sitter ved siden av det. Gi opp å lese etter en varighet, fordi en avsender som åpner en forbindelse og stopper å skrive ellers holder den åpen. Og største melding akseptert, i bytes, fordi null betyr ingen grense og grensen er da minne — en avsender som poster en gigabyte blir avvist i stedet for å absorbere.

4.8 Validering

En kanal sjekkes når den lastes, og sjekken er nektelser i stedet for advarsler der alternativet ville være en kanal som kjører og gjør feil ting.

Eksempler på ting som blir avvist på en gang: en destinasjon uten type, en transformasjon som addresserer en sti som ikke kan eksistere i den erklærte datatypen, en bekreftelsesmodus som kilde-transporten ikke kan levere, og en Schedule II-resept med refiller.

Forskjellen Perfuse prøver å holde fast ved er at alt som ville produsere et plausibelt feil resultat blir avvist, og alt som bare er uvanlig blir tillatt og rapportert. En kanal som ikke kan være feil er mer verdifull enn en kanal som starter.

5 Meldingsflyt

Dette kapitlet følger en melding fra øyeblikket den ankommer til øyeblikket den leveres eller gir opp på. Å kjenne denne rekkefølgen er den raskeste måten å finne ut hvor en endring hører hjemme, og hvorfor noe ikke skjer.

5.1 Rekkefølgen av hendelser

1. Ankomst. Kilden aksepterer byteene. For en strømmetransport inkluderer dette de-framing — å finne hvor en melding slutter og den neste begynner.
2. Parse. Byteene blir et tre i henhold til kanalens dataType. En melding som ikke kan parses, stopper her og registreres som en parse-feil.
3. Registrer. Meldingen skrives til meldingslagret slik den mottas, før noe modifiserer den. Dette er hva som gjør det mulig å replaye og reprosessere.
4. Filter. Hvis kanalen har en filter, bestemmer den om å akseptere meldingen. En avvist melding registreres som filtrert, som er en normal utfall og ikke en feil.
5. Transform. Kanalens transformations kjøres i rekkefølge, hver mot resultatet av den forrige.
6. Fan out. Hver destinasjon får en kopi av den transformerte meldingen, anvender sine egne transformasjoner hvis den har noen, og leverer.
7. Registrer utfallet. Per destinasjon: levert, køt, feilet eller filtrert.
8. Bekreft. Hvis kilden forventer en bekreftelse, genereres og sendes den. Som standard skjer dette her, etter levering — se nedenfor.

5.2 Når bekreftelsen sendes

Dette er den mest konsekvensfulle innstillingen i en kanal, fordi den bestemmer hva avsenderen blir lovet. Det er ack.when, og det har to verdier.

on_delivery er standard. Bekreftelsen sendes bare etter at hver aktivert destinasjon har akseptert meldingen. En positiv bekreftelse betyr derfor at data faktisk ankom et sted, som er den sterkste påstand en motor i midten kan ærlig gjøre.

on_receipt bekrefter så snart meldingen er parsed og køet, før noen destinasjon har blitt skrevet.

Perfuse standarder til on_delivery fordi å love levering og så miste meldingen er verre enn å være langsom. Under on_receipt, en melding som har blitt bekreftet kan fortsatt bli mistet hvis prosessen dør med arbeid køet — avsenderen tror det er levert, ingenting oppstrøms vil sende det igjen, og den eneste rekorden som det eksisterte er i Perfuses eget lager.

5.3 Når å velge on_receipt

Saken for det er reel, og det er tidsfrister. En MLLP-avsender som ikke får en bekreftelse innen noen sekunder vil vanligvis sende igjen, så en langsom destinasjon under on_delivery produserer duplikater i stedet for forsinkelse. Hvis en destinasjon er en langsom arkiv eller et system som regelmessig er utilgjengelig, on_delivery kobler avsenderens tidsfrist til den destinasjonens verste case.

Handelen er eksplisitt: on_receipt overfører risikoen fra duplikater til tap. Å velge dette betyr å akseptere at en bekreftet melding kan gå tapt i tilfelle av en feil, og det er verd å kombinere med varsel om kødybde slik at en kø som har stoppet å tømme blir merket. Se varsel.

5.4 Hvor meldingen blir registrert

Før filteret, og derfor før noen transformasjon. Tre konsekvenser:

• Et melding som filteret avviste, er fortsatt i lagret. Du kan se hva som ankom og bekrefte at filteret var riktig.
• Replay og gjenprosessering starter alltid fra hva som faktisk ankom, ikke fra en delvis transformert versjon.
• En endring i transformasjonene kan testes mot ekte historisk trafikk, fordi den opprinnelige er fortsatt der. Se testing.

Den transformerte formen blir også registrert, per destinasjon, sammen med utfallet. Så lagret inneholder hva som ankom, hva som ble sendt, og hva som skjedde — som er hva en undersøkelse trenger.

5.5 Feil på hvert steg

Den viktige asymmetrien: en pars-feil er permanent og en leveringsfeil vanligvis ikke er det. Å forsøke å parsere en umulig melding vil aldri hjelpe, så den forsøkes ikke. Å forsøke å nå en utilgjengelig destinasjon vil vanligvis hjelpe, så den forsøkes.

5.6 Rekkefølge

Innen én destinasjon, meldinger leveres i rekkefølgen de ankom, og en melding som feiler og kommer inn i køen holder sin plass — senere meldinger venter bak den i stedet for å gå forbi.

Dette er standardrekkefølgen for kliniske data, hvor en innleggning fulgt av en utskrivning leveres i feil rekkefølge er verre enn at begge er forsinket. Det betyr også at én forgiftet melding kan holde opp en kø, som er hvorfor kø-dybde er verdt å varsle om.

Mellom destinasjoner er det ingen rekkefølgegaranti, fordi de er uavhengige. To destinasjoner vil ikke nødvendigvis motta samme melding på samme tid, og en rask kan være flere meldinger foran en langsom.

5.7 Samtidighet

En kilde kan håndtere flere forbindelser samtidig, begrenset av max_connections. Meldinger fra forskjellige forbindelser prosesseres samtidig.

Dette betyr at ankomstrekkefølgen for to meldinger sendt samtidig ned to forbindelser ikke er definert, og kan ikke være — de ankom faktisk på samme tid. En avsender som trenger rekkefølge må bruke én forbindelse, som er hva de fleste av dem gjør.

6 Transformasjon

Transformasjoner endrer en melding. De er en liste, de kjøres i rekkefølge, og hver enkelt ser resultatet av den foregående.

Perfuses transformasjoner er deklarative: hver enkelt steg navngir en operasjon og feltet det gjelder for. Det finnes ingen skriptspråk i den vanlige banen. Dette er en bevisst begrensning og begrunnelsen er i hvorfor ikke et skript nedenfor.

6.1 Stegene

Hvert steg aksepterer også description, som vises i sporet og i grensesnittet, og when, som gjør stegene betingede.

Et steg skrives som operasjonsnavnet med sin egen blokk:

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 Tøm, fjern og forskjellen

clear lar feltet være til stede og tomt. remove fjerner det helt.

For HL7 er denne forskjellen reell og den når mottakeren. Et tomt felt sier "Jeg har dette feltet og det har ingen verdi". Et fraværende felt sier ingenting i det hele tatt. Noen mottakersystemer behandler den første som en instruksjon om å slette deres lagrede verdi og den andre som en instruksjon om å la den være alene — som er forskjellen mellom å slette en pasients registrerte allergi og ikke å nevne den.

Hvis du ikke vet hvilken mottakeren ønsker, spør. Å gjette har en femti prosent sjanse til å ødelegge data på den andre siden uten å varsle om det.

6.3 Betingelser

when tar en uttrykk og trinnet kjører bare hvis det er sant:

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

Et steg hvis betingelse er falsk, registreres som skipped, og dette rapporteres separat fra et steg som kjørte og ikke endret noe. Denne distinksjonen er poenget med steg-gjennom-debuggeren og det dekker i feilsøking: en falsk betingelse og et fraværende felt ser identiske ut fra utsiden og betyr motsatte ting.

6.4 Stier

En sti adresserer et felt: PID-5 er det femte feltet i PID, PID-5.1 er dens første komponent, PID-3(2) er den andre gjentakelsen av PID-3 og OBX(3)-5 er det femte feltet i det tredje OBX-segmentet.

To beteender verdt å vite:

• set oppretter den adresseerte banen, inkludert mellomliggende struktur. Dette er praktisk, og det betyr at set aldri kan demonstrere at et felt manglet — etter steg er det der. For å teste hva som skjer når et felt mangler, bruk copy fra en bane som ikke er der.
• En bane uten indeks addresserer hver gjentakelse og hver forekomst, slik det gjør i et filter (hvor PID-3.5 == "SS" er sant når noen gjentakelse er). På et melding med fem OBX-segmenter, endrer set på OBX-5 alle fem, og set på PID-3.4 omlabeler hver identifikator i PID-3, inkludert den nasjonale nummeret. For å endre en, gi dens indeks: PID-3(1).4, OBX(2)-5.

6.5 Feil

De fleste trinn har ingenting å feile på. Å sette en verdi, å fjerne et felt eller å kopiere fra en fraværende sti med en standardverdi er alle definert for alle inndata.

date er unntaket, fordi en verdi som ikke er en dato den gjenkjenner, har ingen korrekt konvertering. Den tar on_error:

• fail — standard. Meldingen stopper og blir registrert som en transformasjonsfeil.
• keep — la den opprinnelige verdien være uendret.
• clear — tøm feltet.

Standard er fail fordi en tidsstempel som stille ikke konverterer er verre enn en melding som ikke ankom. En dato i feil format ser likevel ut som en dato, så den passer mottakerens validering og havner i rekorden som feil dag.

keep er legitimt når mottakeren tolererer begge format, og når den brukes, markerer sporet endringen som bevisst, så den ikke leser som et trinn som feilet stille.

6.6 Rekkefølge betyr noe, og sporet viser det

Hvert trinn ser forrige trinns utdata. To konsekvenser som fanger folk:

• En map etter en case ser case-omdannet verdi, så dens tabellnøkler må matche den omformede formen. En tabell med M/F etter en småbokstavs-trinn matcher ingenting, stille, fordi en verdi som ikke er i tabellen blir latt uendret.
• En copy fra et felt som et senere trinn fjerner, fungerer likevel, fordi det kjørte først. Det omvendte gjelder ikke.

Begge er synlige i steg-for-steg-visningen, som viser hele meldingen etter hver enkelt steg i stedet for bare endringen. Se feilsøking.

6.7 Forslag til mapping, og hva å gjøre med et forslag

AI Mapper foreslår mapping mellom en sett av kildefelter og en sett av mål. Dets definierende atferd er at det avstår: under sin konfidensstørrelse avstår det fra å gjette, fordi en selvsikker feil mapping i et klinisk system er verre enn ingen mapping i det hele tatt.

6.7.1 Gi det noe å være trygg på

Et navn på egen hånd er svak bevis, selv når det matcher nøyaktig. PatientMRN mot PatientMRN scorer 68, som avstår ved standardtørskelen på 70.

The engine knows what an HL7 path means — it will tell you PID-7 is Date/Time of Birth and score your field name against that rather than against the string PID-7, which shares no characters with anything. A locally defined Z segment means whatever your site decided, so nothing is claimed about it.

Det får en mapping nesten hele veien. For å fullføre det, lever både halvdelene:

• Eksempelverdier for et kildefelt, etter en likhetstegn: ZPI-1 = MRN00412, MRN00998
• Den type verdi et målfelt holder, på samme måte: PID-3.1 = mrn. Typene er mrn, npi, ssn, phone, date og email.

Med disse, kan motoren se at verdiene er enige med målfeltets type, og et forslag hviler på mer enn et navn.

6.7.2 Godkjenning skjer ett kartlegging til gangen

Hver forslag har sin egen godkjenningsboks. Det finnes ingen «godta alt over 80 %», med vilje: motoren har allerede brukt konfidensen til å bestemme om å tilby kartleggingen, og hva som gjenstår er en vurdering om dette feltet i denne feeden. Et tall er ikke den vurderingen.

En avstemning kan ikke godkjennes i det hele tatt. Den har ingen boks, ikke engang en deaktivert en, og skjermen sier at motoren ikke vet. Hvis du kjenner svaret, kartlegg det manuelt — det er en annen handling enn å gå med på et forslag.

Et forslag under din terskel vises uten en boks også, merket som under den. Verdt å lese — et nærmiss er ofte den kartleggingen du ønsket, og å skjule den ville etterlate deg med å undre deg om motoren vurderte den — men ikke godkjennbar, fordi din terskel er linjen du tegnet.

6.7.3 To ting å gjøre med det du har godkjent

Legg dem til en kanal gjør hver kartlegging til en kopi-trinn. Dette fungerer bare der kilden er en sti i meldingen, slik som ZPI-1, fordi et trinn kopierer fra ett sted i en melding til et annet. Trinnene går inn i kanal-filen og treffer når den neste lastes — ingenting endrer seg i trafikken før da. Hver trinns beskrivelse registrerer konfidensen det ble foreslått med og at en person godkjente det, som er det som gjør det ansvarlig seks måneder senere.

Last ned som en oppskrift er det riktige svaret for den vanligere casen: en kartlegging fra en kolonne-navn, en JSON-nøkkel eller en leverandørs eget felt-navn. Disse er ekte kartlegginger, og en kanal kan ikke lese slike felt direkte, så et trinn kan ikke uttrykke dem. Oppskriften registrerer dem som godkjent og kan deles.

6.8 Hvorfor ikke et skript

Mirth setter en JavaScript-omformer i midten av hver kanal, og det er den mest fleksible designet som er tilgjengelig. Perfuse tilbyr skripting — se scripts-nøkkelen i kanal-referansen — men gjør det ikke til den vanlige stien, av tre grunner som kommer fra hva som går galt i praksis.

Et deklarativt trinn kan inspiceres. Perfuse kan si deg at et trinn leser PID-5 og skriver PID-8, før det kjøres, og kan derfor vise en felt-nivå-sporing, advare om at et trinn adresserer en sti som den erklærte datatypen ikke kan inneholde, og generere en per-trinn-replay. Ingen av dette er mulig for arbitrær kode.

Et deklarativt trinn kan resonereres om av grensesnittet. Byggeren kan tilby feltene som finnes i denne kanalens trafikk, og en endring av et trinn kan sjekkes mot ekte historiske meldinger før det lagres.

Og et deklarativt trinn kan ikke gjøre noe uavhengig av meldingen. Et skript kan ringe ut til nettverket, lese filsystemet eller avhenge av tid på dagen. Når en kanal som fungerte i to år begynner å produsere feil output, er årsaken utenfor meldingen den hardeste casen å diagnostisere, og å fjerne muligheten er verdt mer enn den fleksibiliteten det koster.

Der en ekte transformasjon ikke kan uttrykkes deklarativt, bruk et skript og aksepter at sporingen vil vise det som ett uigjennomsiktig trinn.

6.9 Hva et skript er tillatt å gjøre

Et skript er nektet alt utenfor meldingen med mindre det er gitt, og tillatelsene er på Skript-delen av byggeren. Dette er med vilje ulikt Mirth, som gir hver skript alle — så der, kan en omformer stille lese filsystemet etter en kopi-og-lim-inn.

Det finnes tre.

Les og skriv filer krever at du navngir katalogene det kan bruke, og en kanal som gir fil-tilgang uten dem blir nektet ved lasting. Denne kravet er hele forskjellen mellom fil-tilgang og ubegrenset fil-tilgang: å gi det uten kataloger en gang nådde hele filsystemet, inkludert Perfuses egen database, som holder passord-hashes, LDAP-tjenestekonto-passord og OIDC-klient-hemmelighet. Å opprette en kanal trenger bare redaktør-rolle, så eskaleringen fullførtes øyeblikket en administrator startet kanalen.

Spørr en database bruker koblingene konfigurert på kanalen. Et skript med dette kan lese alt disse legitimasjonene kan.

Rute meldinger til andre kanaler lar et skript sende en melding inn i en annen kanal, som er hvordan en løkke mellom to kanaler blir mulig.

Å gi en evne til en kanal uten skript gjør ingenting, og den genererte filen utelater hele blokkene i det tilfelle.

6.10 Håndtering av en dato som ikke matcher sin format

Et dato-trinn konverterer fra ett format til et annet, og det interessante spørsmålet er hva som skjer når en verdi ikke matcher formatet det hevder.

Standarden er å stopp meldingen, og det er riktig standard: en tidsstempel som stille ikke konverterer er akseptert nedstrøms og deretter misforstått, som er verre enn en melding som feilet høyt og sitter der noen kan se det.

La verdien være som den er passerer den gjennom i sitt opprinnelige format. Nedstrøms ser deretter to formater i ett felt, som er feilen trinnet eksisterte for å forhindre — men det er riktig valg der feltet er valgfritt og en partner sender det inkonsekvent.

Tøm feltet er ærlig og bedre enn et feil format, men en mottaker som krever feltet avviser deretter meldingen i stedet.

6.11 Skriptspråkene

Tre er akseptert, og hvilken en som skal velges avhenger hovedsakelig av om du migrerer. Verdien går i en skripts language-nøkkel:

JavaScript er standard, og et uskrevet skript behandles som JavaScript. Det er her som en kompatibilitetsforpliktelse snarere enn et valg: Mirths skript er JavaScript og en nettsted som flytter over har tusenvis av linjer med det. Dette inkluderer støtte for E4X, en utdødde utvidelse av språket som Mirth-skript bruker for XML og som må oversettes før noe vil parse det.

Lua (lua) er bedre valg for alle som ikke migrerer. En mindre kjøretid, ingen prototype-kjede å misbruke, og heltallsindekserte tabeller som matcher segment- og feltadressering mer naturlig enn JavaScripts gjør. Dets standardbibliotek er små nok til å oppramse, hvilket er hva som gjør sandkassen lettere å være trygg på.

WebAssembly (wasm) er ikke et språk, men et kompilert modul, og feltet ønsker byte av en .wasm-fil i stedet for kilde. Bruk det når transformasjonen allerede eksisterer i et kompilert språk, eller når det er tungt nok til at kjøretidkostnaden teller.

Dets kontrakt er bevisst den enkleste tilgjengelige: et modul leser meldingen på standardinngang og skriver resultatet til standardutgang. Byte inn, byte ut — hvilket er hva hver verktøykjedde allerede gjør, og hva noen som tester et modul på sin egen kommandolinje allerede har. Alternativet var en eksportert funksjon over lineær minne, som er raskere og krever at hver modulforfatter er enig om allokering, strengkoding og hvem frigjør hva; for noe som kjører én gang per melding, er den handelen ikke verdt det.

Alt et modul skriver til standardfeil blir loggliner, så det kan forklare seg selv på samme måte som et skript som kaller logger kan.

6.11.1 Hva utgangen betyr

Reglene er de samme for alle tre språkene i stedet for nye for hver kjøretid, så et skripts observerbare atferd — hva det kan se, hva det kan gjøre, hvor lenge det kan ta, hva et filterutslag betyr — er definert én gang.

For en transformer, forprosessor eller skriver, tom utgang betyr at meldingen er uendret. Å falle av slutten av et skript lar meldingen være alene; å behandle ingen utgang som "meldingen er nå tom" ville kaste trafikk på en teknisitet.

WebAssembly-moduler er kompilert når kanalen lastes, ikke på den første meldingen. Kompilering er ikke gratis — et modul bygget fra et språk som bringer sin egen kjøretid kan ta hundrevis av millisekunder — og å betale det på lasttid betyr at den første meldingen gjennom en kanal ikke er mystisk langsommere enn resten.

6.12 Felles karttabeller

Den andre halvdelen av samme problem: en steds kjønnskoder og pasientklasser oversettes identisk i hver kanal som berører dem, og en tabell inne i en kanal er en tabell bare den kanalen kan bruke.

# 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

Provenansen er poenget. Det meste av hva som gjør et grensesnitt vanskelig å vedlikeholde er at ingen vet *hvorfor* en mapping er slik den er, og personen som visste har forlatt. En mapping med en grunn kan diskuteres; en uten blir noe ingen våger å endre og ingen våger å slette.

Tabeller opprettes og endres på Build → Tabeller samt i filen. Å lagre en aktiv tabel omstarter de kjørende kanalene som laster inn filen, så den neste meldingen bruker den; en utkast omstarter ingenting.

6.12.1 Versjoner og effektive datoer

En tabell kan holde flere utgaver under ett navn, hver med sin egen version. Utgaven en melding bruker, velges når meldingen ankommer: blant de godkjente utgavene hvis datoer dekker denne dagen (UTC), den som startet senest. Så en kodeendring som er enige om for første dagen i neste måned, blir nå innført og overtar på egen hånd.

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 er approved (standard), draft (brukt av ingenting) eller retired (bevart for rekordens skyld, brukt av ingenting).
• To utgaver av ett navn med samme versjon, eller to godkjente utgaver som starter samme dag, blir avvist når filen lastes.
• Lagring av en ny versjon uten startdato mens en annen er godkjent, daterer den fra i dag, så den erstatter den som er i kraft. En som bare startet i dag blir pensjonert, siden to utgaver som starter samme dag ikke lar noen regel.
• En kartstegs egen default og strict brukes når steget setter dem; ellers brukes tabellens.
• På Skjermbildet Viser versjoner lister hver utgave med sin status, hvem som lagret og hvem godkjente den, og Sammenlign med den gjeldende versjonen viser hva en utgave legger til, fjerner og endrer.

6.12.2 Godkjenning

Med Innstillinger → Data → Karttabeller "Endringer i en karttabell trenger en annen persons godkjenning" (data.tableApproval) på, blir hver lagring et utkast, og personen som lagret den, kan ikke godkjenne den: noen andre gjør det, eventuelt med dagen det kommer i kraft. En godkjent utgave kan ikke redigeres på stedet; Ny versjon fra denne kopierer den inn i neste versjon. Godkjenning, pensjonering og sletting av et utkast skrives til revisjonsloggen, og godkjenning starter om de kjørende kanalene som laster filen.

6.12.3 Verdier ingen tabel matcher

Hver verdi en kartsteg så etter og ikke fant, blir telt, per tabell, med kanalene den kom gjennom og når den ble først og sist sett. Skjermbildet Tabeller lister dem, mest frekvent først. Kart den åpner tabellen med den verdien allerede lagt til som en rad; Fjern fjerner den til den blir sett igjen. Verdier lengre enn 64 tegn blir ikke registrert (de er ikke koder), og listen holder hva som ble sett innen meldingsretensjonsperioden. Listen blir holdt i terminology.db ved siden av hoveddatabasen.

6.12.4 Kodesystemer

Publiserte kodesystemer kan importeres fra deres utgivere sine egne filer, under Kodesystemer på Tabelloverlappings-skjermen (admins) eller med POST /api/terminology/import?format=… og filen som innholdet:

Ingen følger med Perfuse: LOINC, SNOMED CT, RxNorm og CPT har hver sine egne lisenser, og skjermen ber importereren bekrefte at organisasjonen har lisensen (registrert med importen). Importerte koder brukes på tre måter:

• en tabel som navngir source_system eller target_system har innleggene kontrollert når

de lagres, og koder som ikke er i systemet listes på utgaven;

• Finn en kode søker etter kode eller ord i navnet;
• FHIR-tjeneren besvarer CodeSystem/$lookup og CodeSystem/$validate-code

for dem (se FHIR-tjenerens alternativer). ICD-10-CM-koder aksepteres med eller uten punktum.

Nasjonale utgaver og klassifiseringer. En SNOMED CT-utgave importeres fra hele RF2-pakken: begreper med deres faktiske status, hver aktiv beskrivelse og språkreferansesettene. Utgaven finnes fra pakken (den nasjonale modulen med flest begreper; edition navngir den i stedet) og blir versjons-URIen. language velger hvem som foretrukket betegnelse er for hvert begrep (sv, da, nl, de, fr, en-GB, en-US ...; engelsk ellers), og hver språks foretrukne betegnelse og fullt spesifisert navn beholdes som betegnelser: $lookup returnerer dem, og dens displayLanguage velger en (de-CH falter tilbake til de). Utgavene Perfuse navngir (Internasjonal, UK, Tyskland, Nederland, Sverige, Danmark, Belgia, Irland, Norge, Sveits, Estland, Spania) er listet av GET /api/terminology/editions, modul-IDene ikke sjekkes mot en publisert kilde merket som slik; noen andre utgave importeres også, navngitt av sin modul.

ClaML-filer leses i UTF-8, ISO-8859-1, ISO-8859-15 eller Windows-1252, som deres XML-erklæring sier. Hver kategoris tittel er dens foretrukne rubrik (innlemmet terminologi inkludert); en modifiserer (en femte karakter for stedet for en fraktur, for eksempel) gjør kodene den legger til, med modifisererens tittel etter kategoritittelen, med mindre kategorien ekskluderer den; blocks=true importerer kapitler og blokker også. ICD-11-tabellens kolonner finnes ved navn, siden deres rekkefølge har endret seg mellom utgaver, og bindestrekene som viser dybde fjernes fra titler. En avgrenset fil tar delimiter (, ; | eller tab), encoding (utf-8, iso-8859-1, iso-8859-15, windows-1252) og noHeader=true`, med kolonner nummerert fra 1 deretter. Konsollen tilbyr innstillinger for UK ICD-10 5. utgave og OPCS-4-filer (TRUD), Frankrikes CIM-10 FR-tabel over etiketter (ATIH) og en ICD-10-BE-eksport; deres forlag dokumenterer ikke alle kolonnene, så sjekk dem mot filens header.

Virkningsdatoer. effective=YYYY-MM-DD importerer en versjon nå og bruker den fra den dagen (ICD-10-GM, for eksempel, hver 1. januar): inntil da svarer en oppslag som ikke navngir noen versjon med versjonen som allerede er i kraft, og skjermen viser datoen.

ICD-11 fra WHO. Med en klient registrert på icd.who.int (Innstillinger → Data → Kodesystem, serve -icd11-client-id og -icd11-client-secret; -icd11-release, 2025-01 som standard), ICD-11-koder som ikke er importert søkes i WHO ICD API (codeinfo, deretter enhetens tittel) og beholdes i en dag. En postkoordinert kode (NC72.2&XK9K) sjekkes hel, så en kombinasjon ICD-11 ikke tillater, avvises, og dens visningsnavn hver del ("Brudd i halsen på femur (Høyre)").

ICD-11 uten å sende koder ut. WHO publiserer samme API som en container (whoicd/icd-api, gratis, Intel og Arm). Kjør den på ditt eget nettverk og gi dens adresse (serve -icd11-url http://icd-api.local, eller ICD API-adresse i samme innstillinger); ingen klient er nødvendig og ingen kode forlater ditt nettverk. Testet mot denne containeren (versjon 2.6.0, utgivelse 2025-01 på engelsk og fransk).

7 Filtrering

Et filter bestemmer hvilke meldinger en kanal aksepterer. Det er ett uttrykk på kanalen, evaluert etter at meldingen har blitt parsert og registrert, før noen transformasjon.

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

Et melding som filteret avviser, blir registrert med resultatet filtered. Dette er et normalt resultat, ikke en feil, og det utløser ikke en advarsel eller produserer en negativ bekreftelse.

7.1 Filtrert er ikke feilet

Denne distinksjonen er verdt å være fast på fordi å blande dem sammen er hvordan et reelt problem blir skjult.

En filtrert melding ble riktig avvist: den var ikke for denne kanalen. En feilet melding var en som denne kanalen skulle ha håndtert og ikke kunne. Hvis begge ble registrert på samme måte, ville en kanal som starter med å feile hver melding se ut akkurat som en kanal som filtrerer mesteparten av trafikken, som er den normale tilstanden for mange kanaler.

Så statistikken teller dem separat, advarselreglene behandler dem forskjellig, og grensesnittet viser dem i forskjellige farger. En økning i filtrerte meldinger kan bety at avsenderen har startet å sende noe nytt; en økning i feil betyr at noe er feil.

7.2 Hva et filter kan lese

Ethvert felt i den parsede meldingen, ved samme stier som transformasjoner bruker. Filteret kjører før transformasjoner, så det ser meldingen slik den ankom — ikke slik den vil bli sendt.

Denne rekkefølgen er bevisst. Et filter som leser post-transformasjonsverdier ville være å bestemme om å akseptere en melding basert på endringer gjort under antagelse av at den var akseptert, som er sirkulær og produserer kanaler hvis oppførsel avhenger av rekkefølgen på to ting som ser uavhengige ut.

7.3 Uttrykk

Sammenligninger: ==, !=, og for tall <, <=, >, >=.

Medlemskap: in ("A01", "A03"), som er klarere enn en kjede av || og er formen byggeren produserer.

Kombinasjon: &&, ||, og parenteser. Negasjon med !.

Fravær: en sti som ikke er til stede sammenlignes ulikt med noen verdi, inkludert den tomme strengen. For å teste for fravær eksplisitt, sammenlign mot absent. Dette er viktig fordi et fraværende felt og et tomt felt er forskjellige, som beskrevet i transformasjon, og et filter som behandler dem likt vil akseptere meldinger det var skrevet for å ekskludere.

7.4 En feil i filteret er en nektelse

Hvis filteret selv feiler å evaluere — et ugyldig uttrykk som kom forbi validering, eller en sammenligning som ikke kan gjøres — blir meldingen nektet og feilen blir registrert mot den.

Nektelse i stedet for aksept er det tryggere av de to, men ingen av dem er god, og resultatet blir registrert forskjellig fra et vanlig filternektelse så det kan varsles på. Et filter som feiler på hver melding er stille og slipper hele strømmen, og det må ikke se ut som et filter som fungerer.

7.5 Filtrer ved kilde hvor du kan

Et filter kjører etter at meldingen har krysset nettverket og blitt parsed. Noen kilder kan filtrere tidligere og billigere:

• En broker-kilde tar en selector, som filtrerer ved brokeren. Meldinger denne kanalen ikke ønsker å krysse nettverket i det hele tatt. På en delt kø er det forskjellen på å lese hundre meldinger om dagen og hundre tusen.
• En databasekilde sin spørring bestemmer hva den returnerer.
• En filkilde sin mønster bestemmer hvilke filer den plukker opp.

Filtrering ved kilde er en ytelsesbeslutning, ikke en korrekthetsbeslutning, og det har en kostnad: en melding som filtreres ved brokeren blir aldri registrert av Perfuse, så den vises ikke i meldingslagret og kan ikke inspiceres senere. Hvis du trenger å kunne bevise hva avsenderen sendte, filtrer her i stedet for der.

7.6 Testing av et filter

Et filter kan sjekkes mot virkelig historisk trafikk før det blir lagret. Grensesnittet rapporterer hvor mange av de siste N registrerte meldinger filteret ville akseptere, avvise og feile på — som er den raskeste måten å finne ut at et uttrykk som ser riktig ut aksepterer ingenting.

Sporet viser også, per melding, hvilke felt filteret leste og hva verdier den fant. Et filter som uventet avviser alt er vanligvis å lese en sti som ikke eksisterer i denne strømmen, og sporet navngir den.

8 Meldingsformater

En kanals dataType bestemmer hvordan bytes blir en melding. Det påvirker parsing, hva stier betyr, hvordan meldingen skrives tilbake ut, og hvilke transformasjoner som er gyldige.

8.1 HL7 v2

Standardverdien, og det som de fleste eksemplene i denne håndboken bruker. Segmenter avsluttes med linjeskift, felt med |, komponenter med ^, gjentakelser med ~.

To ting om kodingen er verdt å vite fordi de kan forårsake stille feil.

Skilletegnene er ikke faste. De er erklært i MSH-1 og MSH-2 i hver melding, og Perfuse leser dem fra der i stedet for å anta pipes. En avsender som bruker en annen feltseparator parser korrekt.

Konsekvensen er at en melding hvis separatorer har blitt erstattet — oftest av en tekstbehandler eller e-postklient som erstatter typografiske likhetstegn — parser perfekt inn i felt som alle er feil. Ingen feil oppstår. Dette er hvorfor eksempel-leseren beskrevet i testing rapporterer hvilket separator-tegn den fant, og nekter å uttrykke tillit når det er uvanlig.

8.2 HL7 v3 og CDA

XML i stedet for skilte. Stier er element- og attributtpunkter i stedet for feltstillinger.

I v3 er en verdi nesten alltid et attributt i stedet for elementtekst. En sammenligning som bare leser elementtekst vil rapportere to dokumenter som identiske når fødselsdatoen, kjønnet og hver identifikator skilles. Perfuses sammenligning leser både, og dette er hvorfor: alternativet lykkes stille.

hl7v3-valg er i format-referansen.

8.3 X12

Segmenter avsluttes med ~ konvensjonelt, med skilletegn erklært i ISA-segmentet. Liksom HL7, leses de fra meldingen i stedet for å antas.

X12s struktur er konvolutter innen konvolutter — utveksling, funksjonell gruppe, transaksjonssett — og en enkelt utveksling kan holde mange transaksjoner.

Som standard er en utveksling en melding. Hele filen får en post, ett resultat og en rad i grensesnittet, uansett hvor mange transaksjoner den inneholder.

8.3.1 Mirths X12-XML

Mirth Connect og Open Integration Engine viser X12 som XML: en rot X12Transaction (eller EDIMessage når innputt ikke starter med ISA) som bærer grenseverdier som attributter, og ett element per segment og element navngitt ISA.01, NM1.03.1 osv. Kanaler og mottakere bygget for Mirth leser og skriver denne formen. Perfuse leser og skriver samme form:

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

Formatet ble skrevet fra Open Integration Engine 4.6s observerte utdata og publisert format, og sjekkes mot det: 25 genererte interchanges og 4 beholdte eksempler kommer ut byte for byte som OIE skriver dem, og tilbake (se verifisering). En DOCTYPE avvises, som i hver XML Perfuse leser.

8.3.2 Deling av en utveksling

Innstilling av split gjør hver transaksjonssett til en melding i eget rett, med sin egen post, sine egne målinger og sin egen rad. En operatør som søker etter ett krav finner da ett krav i stedet for en fil med fire hundre.

Det er av som standard fordi å slå det på multipliserer alt nedstrøms — meldings teller, rader, varslingstrøskler — og en terskel innstilt for filer som plutselig teller krav, vil ikke bety det samme som tidligere. Det bør være en beslutning noen tok, i stedet for en standard de arvet.

8.3.3 Når tellingene ikke stemmer overens

X12 erklærer sine egne tellinger — hvor mange segmenter, hvor mange transaksjoner — og envelope-nøkkelen sier hva som skal gjøres når de ikke stemmer overens med hva som faktisk er til stede. Disse tellingene er den eneste mekanismen X12 har for å oppdage at halve kravfilen ankom.

warn eksisterer for en reell situasjon: noen partnere sin programvare har generert feil tellinger i år i ellers fullstendige filer, og en nettsted som må behandle dem, trenger en måte å si det høyt i konfigurasjonen i stedet for å slå av validering helhetlig.

8.3.4 Transaksjoner Perfuse leser som strukturert data

Enhver X12-utveksling kan rutes, filtreres og adresseres etter sti. Disse transaksjonene parses også til navngitte felt, så en kanal kan spørre hva en betaler bestemte, i stedet for hvilket element sitter på posisjon fire.

Perfuse bygger også 270-rettighetssøknaden og 276-kravstatusforespørselen, under Betaler → Krav & godkjenning eller gjennom POST /api/x12/eligibility/build og /api/x12/claimstatus/build. Begge er HIPAA 5010-versjonene (005010X279A1, 005010X212), lest tilbake og konvolutfunksjonskontrollert før de vises, og ingen av dem sendes fra denne siden: å levere en er en kanals jobb, der handelspartnern og dens legitimasjon er.

8.3.5 Kvalifisering og CAQH CORE datainnholdregel

En 271 er en liste over EB-segmenter, hver enkelt faktum: aktiv dekning, eller en $25-kontantbetaling for tjenestetype 30 i nettverk, eller $800 av den enkeltes fradragsbeløp igjen. Leseren setter dem sammen til svaret en resepsjon ønsker - "dekning aktiv under Gold PPO 2000; kontantbetaling i nettverk $25; enkeltfradragsbeløp igjen i nettverk $800" - og navngir en avvisning (et AAA-segment) i ord, med hva betaleren sier å gjøre neste.

Den sjekker også svaret mot CAQH CORE Eligibility & Benefits datainnholdregelen: for en søknad om helseforsikringsdekning (tjenestetype 30), skal en aktiv respons medføre plan datoer, plan navn, kontantbetaling, selvbetaling, fradragsbeløp og igjen fradragsbeløp både i og utenfor nettverk, og basis tjenestetyper (1, 33, 35, 47, 48, 50, 86, 88, 98, AL, MH, UC). Hver er listet som møtt eller mangler. Dette er Perfuses lesning av regelen, nyttig for "hvorfor forteller denne betaleren oss aldri fradragsbeløpet?" - det er ikke CORE-godkjenning, som CAQHs autoriserte testleverandører utfører.

8.3.6 Forhåndsgodkjenning

Perfuse implementerer forhåndsgodkjenning to ganger, med vilje.

Den FHIR-siden er hva CMS-0057-F krever at betalere eksponerer fra 1. januar 2027. Den 278 er hva betalere aksepterer i dag, og regelen erstatter den ikke — Da Vinci PAS er i praksis en mapping til denne transaksjonen, fordi en 278 er hva en utnyttelsesstyringssystem snakker. En motor som bare leser den FHIR-halvdelen kan snakke med systemene som vil eksistere og ikke med de som gjør.

En 278-respons inneholder godkjenningnummer, og det er feltet hele transaksjonen eksisterer for å levere. Uten det er en sertifisert tjeneste ikke fakturerbar: kravet går inn uten godkjenningnummer og avvises for mangelen på ett, som les nedover som en klinisk avvisning.

En avvisning og en nektelse til å vurdere er ikke det samme

Dette er den dyreste forvirringen i transaksjonen, og Perfuse rapporterer de to separat.

Begge leses som "ikke godkjent" for enhver som scannrer, og de riktige handlingene er motsatte. Å anke noe som ingen har avgjort, fører ikke til noe; å sende inn en avslag på nytt, resulterer i samme avslag. De parsede resultatnavnene som skjedde — denied mot not-considered — og AAA04 inneholder forsikrers egen råd om hvorvidt forespørselen er tilbakekrevbar overhodet.

Delvis sertifisering rapporteres som partially-certified i stedet for å bli innlemmet i godkjenning. Det finnes en autorisasjonsnummer å fakturere mot, så det teller som godkjent, men mengden sertifisert er ikke mengden som ble forespurt — og en praksis som booker seks sesjoner mot tre godkjente oppdager det ved den fjerde kravet.

En handlingkode Perfuse ikke gjenkjenner, rapporteres som unknown, ikke som pending. Pending leses som "vent", og venting er feil handling for det meste av hva en ikke-gjenkjent kode kunne være.

En kanal kan rute på avgjørelsen direkte:

filter: HCR-1 == "A3"

Omforming mellom de to

Perfuse omformer en parsed 278 til en Da Vinci PAS ClaimResponse, og rapporterer hver enkelt vurdering omformingen trengte i stedet for bare resultatet. Omformingen følger tre regler:

• Ingen beslut oppgraderes. Delvis sertifisering forblir delvis, og en forespørsel som betaleren nektet å vurdere, blir ikke til et avslag. Begge sammenbrudd er tilgjengelige i den åpenbare mappingen og begge er feil i den dyre retningen.
• Ingenting er oppfunnet for å fylle et påkrevd felt. En sertifisert hendelse uten autorisasjonsnummer rapporteres som sådan, ikke gitt et plausibelt ett — et fabrikkert nummer produserer en krav som senere avvistes av en grunn ingen kan spore.
• Et beslutning som bare er båret på linjenivå, brukes. En betaler som svarer per tjeneste, kan la hendelsen uten et beslutning av sin egen; å lese bare på hendelsesnivå ville rapportere det som ventende, og en praksis venter på et svar det allerede har, mens godkjenningen utløper. Hvor linjene er uenige, vinner den minst gunstige, fordi en hendelse med en avvist linje ikke er en godkjenning.

Innsnevring til en tre-tilstands-vokabular — godkjent, avvist, ventende — er tilgjengelig og eksplisitt om hva den kasserer. Innsnevring av et avslag på å vurdere, gir "avvist" og sier i ord at den riktige handlingen er en korrigert gjeninnsending i stedet for en anke.

Kontrollert mot PAS 2.2.1, ikke bare mot seg selv

ClaimResponse er formet til Da Vinci PAS 2.2.1-profilen og ble kontrollert med den offisielle HL7-validereren lastet med den publiserte PAS-pakken. Den første versjonen hadde bare blitt kontrollert av Perfuses egne tester, og validereren avviste den med seks til åtte feil per ressurs. Hver enkelt av dem er noe en betalers PAS-endepunkt også ville ha avvist:

Den korrigerte utdataen validerer uten feil for en sertifisering, et avslag og en ventende. Advarselen som gjenstår er validereren som sier at den ikke kan laste X12s kode-systemer, som X12 lisenser. Autorisasjonsnummeret er båret i reviewAction.number, hvor guidens eget eksempel plasserer det, og i preAuthRef når svaret bare har ett.

Validereren er ikke en del av make check, fordi den trenger Java og en nedlasting av guiden og dens avhengigheter. Hva den fant, holdes av en test i stedet: hver regel den tvang frem, hevdes, så en endring som gjeninnfører en av disse feilene, feiler.

Krav & auth-visningen konverterer en limt 278 og viser beslutningene, notatene og ressursen.

8.3.7 Vedlegg og hvorfor de trenger spesiell håndtering

CMS-0053-F gjør 275 til en HIPAA-standard for krav-vedlegg, med overholdelse påkrevd fra 26. mai 2028. Den bærer et dokument — en operativ notat, en bilde-rapport, en skannet skjema — knyttet til kravet det støtter.

277 er den andre halvdelen av samme samtalen. En betaler mottar et krav, bestemmer at det trenger dokumentasjon, og sender en 277 som ber om det; leverandøren svarer med en 275.

En kanal kan rute på status-koden direkte, fordi STC01 er en sammensatt og dens andre komponent er status. Skrevet i kanonisk form, fordi en komponent er adressert med en punktum og de to notasjonene ikke kan blandes — STC-1.2 er element 1, komponent 2:

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

Disse er kodene som uansett betyr at et dokument er ønsket. Status kategori i STC-1.1 er med vilje ikke brukt på egen hånd: R4 betyr en dokument-anmodning i noen implementeringsguider og "videreformidlet andre steder" i andre, så en filter på kategorien alene ville plassere ferdigstilte krav i køen for noen å jakte.

To identifikatorer bestemmer om et vedlegg noen gang assosieres med sitt krav, og begge rapporteres: vedlegg-kontrollnummeret, som leverandøren plasserte på det opprinnelige kravet for å si at dokumentasjon ville følge, og sporing-nummeret, som matcher betalers anmodning. Et vedlegg som ankommer med ingen av dem, blir arkivert og aldri koblet til noe, mens kravet eldes.

006020-skjemaet, som er det regelen antar

CMS-0053-F antar versjon 006020, og dens 275 skiller seg fra 005010-skjemaet på to måter som betyr noe.

• Payloaden er i BDS, ikke BIN. BDS01 navngir en filter, ASC eller B64. BDS02 er lengden og BDS03 dataene.
• Payloaden er en MIME-entitet, med header som sier hva dokumentet er og en base64-kropp. Med B64 er entiteten selv base64 også.

Perfuse pakker ut enheten og rapporterer dokumentet inne i den, med innholdstypen og filnavnet. Bytesene den rapporterer er nøyaktig de samme som avsenderen pakket inn. En enhet som ikke kan pakkes ut lar den rå payloaden være på plass, med en notis som sier hvorfor.

Bygging av en 275. Perfuse bygger også 006020X314-vedlegg: et uoppfordret vedlegg som følger en krav, eller et svar på en betalers 277-forespørsel. Forskjellen er BGN01 02 mot 11, og om TRN02 bærer kravets PWK06 eller 277-forespørselens TRN02. Hvert bygget utveksling parses tilbake før det returneres, og svaret sier om dokumentet inne er det samme som gikk inn.

Strukturen kommer fra de to publiserte companion-guidene for 006020X314: CMS esMD-guiden og UnitedHealthcares. Den kommer ikke fra X12-teknisk rapport, som X12 lisenser og som dette prosjektet ikke har.

• Hvor de to guidene er enige, følger Perfuse dem.
• Hvor de forskjeller, tilfredsstiller den begge hvis det er mulig. CAT02 er HL for et HL7-dokument, som esMD bruker, og IA for et bilde, som UnitedHealthcare bruker.
• Ellers sender den bare det valgfrie segmentet når den får verdien: esMDs REF*X1 krav-identifikator og UnitedHealthcares DTP*472-servicedato.

Det er ingen validering mot den tekniske rapporten. Partnerens companion-guide styrer.

8.3.8 Elektroniske signaturer på vedlegg

CMS-0053-F tar også i bruk en signaturstandard, på 45 CFR 162.2002(e): HL7 Implementation Guide for CDA Release 2, Digital Signatures and Delegation of Rights, Release 1. Den gjelder for signaturer som legges på vedleggsinformasjon når den sendes i en HIPAA-vedleggs-transaksjon, fra 26. mai 2028. En betaler kan ikke be om mer enn guiden gjør.

Perfuse signerer en C-CDA på den måten på vei inn i en 275, og sjekker signaturer på hver C-CDA i en 275 den leser.

• Hva som signeres. Hele dokumentet unntatt legalAuthenticator og authenticator-deltakere, så hver senere signer lar tidligere signaturer være intakte. Signaturer sier det med en XPath Filter 2.0-transform som ethvert XML-signaturbibliotek kan evaluere.
• Hvor den går. Base64 i sdtc:signatureText på signaturdeltakeren, med en enkelt linje plain-text-beskrivelse. Signeren er dokumentets juridiske autentifikator hvis det har en usignert en, ellers en ny authenticator.
• Hva den sier. Signerens sertifikat, tiden i UTC, en rolle fra NUCC-leverandørstaksonomi og en formål fra ASTM E1762. Formålet standardiseres til *Forfatterens signatur* for en juridisk autentifikator og *Medforfatterens signatur* ellers, som i guidens eget eksempel.
• Hvor lenge den varer. Guiden ber om XAdES-X-L, som bærer alt en betaler trenger for å verifisere signatur årene senere uten å nå nettverket. Det er sertifikatstiden, en OCSP-respons eller CRL fra CA-en, og to tidsstempel fra en tidsstempelmyndighet. Perfuse henter revokasjonsdata fra adressene i sertifikatet og tidsstemple fra -tsa-url.

Hvis noen av dette er utilgjengelig, blir signaturen likevel laget og holder. Resultatet navngir XAdES-formen den nådde, og sier hva som stoppet den kortere enn X-L: for eksempel et selvsignert sertifikat (ingen CA å spørre) eller ingen tidsstempelmyndighet.

Nøkkelen er -signing-cert og -signing-key. Plasser CA-sertifikatene etter signatursertifikatet i samme fil så stien reiser med signatur. For en signatur som betyr hva DSDR betyr, bør sertifikatet navngi kliniker, med deres NPI, i stedet for serveren. Signering er en admin-handling, som signering av ethvert dokument er.

Guiden navngir ikke et navnerom for sine egne elementer. Perfuse plasserer digitalSignature, authorizedSigner og SignaturePurpose i urn:hl7-org:sdtc. Den uttaler også formålet som en XAdES-forpliktelsestype med ASTM-OID, som XAdES-verktøy forstår. Delegering av rettigheter, hvor en delegat signerer med en SAML-påstand fra den autoriserte signer, produseres ikke, og en mottatt en rapporteres som ikke verifisert.

Lege-NPI sjekkes mot kontrollsifferet. En betaler matcher et vedlegg til kravet delvis på dette nummeret, og et feilskrevet nummer lar vedlegget være umatchet mens kravet avvises for manglende dokumentasjon.

Visningen Krav & auth bygger en 275 fra en limt C-CDA eller en lastet opp fil, valgfritt signere C-CDA, og leser en tilbake med hver signaturs funn. Ingen ting på denne siden sender noe: utvekslingen håndteres tilbake til å bli levert gjennom en kanal, som er der partneren, legitimasjonen og audit-spor hører hjemme.

8.3.9 Binarsegmenter

En BIN-segment bærer rå bytes, og rå bytes inneholder avgrensnings tegn. Hvert annet X12-segment slutter ved segment-terminatoren, så en vanlig parser finner segmenter ved å søke etter ett byte; et vedlegg kan ikke finnes på den måten. En PDF som inneholder en ~ ville bli delt i stykker, og hvert stykke er et strukturert gyldig segment — så dokumentet er trunkert, hvert segment etter det er misjustert, og ingenting rapporterer en feil.

Perfuse leser byte-tellingen segmentet erklærer og tar nøyaktig like mange bytes. To konsekvenser verdt å vite:

• En erklært lengde som ikke stemmer overens med dataene, blir avvist, og begge tallene navngis. Det nyttige spørsmålet er om avsenderens telling var feil eller filen ble trunkert under overføringen, og bare de to tallene besvarer det.
• BDS, den binære 006020-segmentet, beholder sin telling i BDS02 og sine data i BDS03. Det ble avvist til det kunne bekreftes fra en offentlig kilde heller enn fra minnet, og to kilder bekrefter nå det: CMS esMD companion guide's BDS-tabell og UnitedHealthcare's guide.

esMD-guidens egen eksempel på utveksling erklærer 16 byte for samme 53-byte payload som tabellen korrekt teller som 53. Perfuse avviser dette eksemplet, som det skal. En test holder både tabellens eksempel og eksemplets skrivefeil, så en endring i noen retning blir merket.

8.4 FHIR

8.4.1 Hva en HL7 v2-melding blir

Meldingstypen bestemmer hva som produseres, og hver konvertering rapporterer dommene den trengte som notater ved siden av pakken.

Alt annet produserer Pasient og en advarsel som navngir typen som ikke ble kartlagt.

Planlegging. En booking, en ombooking, en avbestilling og en ikke-møte alle lander på samme Avtale. dens identitet kommer fra avtalens egne numre i SCH-1 og SCH-2, aldri fra meldingen, så en avbestilling oppdaterer bookingen. Alternativet ville være en annen, avbrutt avtale ved siden av en live en, som viser at pasienten booket inn i en tid som ikke lenger eksisterer.

• Status. Fyllerstatusen i SCH-25 bestemmer det, og triggerhændelsen brukes bare når det er tomt.
• Blokkerte tidsluker. En blokkert tidsluke er ikke en avtale med en pasient, og produserer ingen.
• Starttid. Den leses fra AIS, AIG, AIL eller AIP først, så SCH-11, fordi versjon 2.5 flyttet det og feeds ikke alle fulgte med det.
• Varigheter. En varighet i en enhet Perfuse ikke gjenkjenner, blir utelatt, ikke gjetting.

Dokumenter. Tekstnotater (TX, FT, ST) beholder sine linjeskift, inkludert blanke linjer, fordi en blank gjentakelse i en notat er en avsnittsbrudd.

• Innlemmede dokumenter. Et innlemmet PDF, TIFF eller JPEG (ED) overføres byte for byte. Base64 som ikke er gyldig base64 avvises i stedet for å videreformidles.
• Typer. Dokumenttypen i TXA-2 beholdes som den ble sendt, og hvor det finnes en klar ekvivalent, gis LOINC-koden US Core bruker.
• Signering. En note som ingen har signert, er preliminary, og T11 gjør dokumentet entered-in-error.
• Ingen innhold. En notifikasjon uten innhold (T01, T03 og andre oddetallshendelser) produserer ingen DocumentReference. FHIR krever innhold, og en tom vedlegg vil se ut som notatet mens det sier ingenting.

Dette er hva CMS Interoperability Framework-kriterium 14 ber om: kartnotater og kliniske dokumenter returnert som FHIR-vedlegg.

Vaksinasjoner. En dose blir aldri rapportert som gitt når meldingen sier noe annet.

• Avviste doser. En avvist eller ikke-administrert dose (RXA-20 RE eller NA) er not-done, med årsak fra RXA-18.
• Slettinger. En slettet dose (RXA-21 D) er entered-in-error.
• Historiske poster. En post som er transkribert fra et annet sted (RXA-9 annet enn 00) er ikke en primær kilde.
• Ukjente mengder. En mengde på 999 betyr ukjent, ikke 999.
• Ruter og steder. Hver dose tar rute og sted fra RXR etter den, så en melding med to doser ikke gir den andre dosens rute.

Ubehagelig innputt. Hver av disse rapporteres i notatene heller enn avgjort stille:

• Identifikatorer. PID-2 og PID-4, trukket tilbake etter v2.7, men fortsatt sendt, behandles som PID-3. CX.7 og CX.8 blir

Identifier.period. En tildelt myndighet som bærer en ISO OID (AUSHIC&2.16.840.1.113883.3.879&ISO) blir urn:oid:. En typekode utenfor HL7-tabell 0203 beholdes som tekst, ikke merket som en.

• Sammenslåinger. MRG på en sammenslåingshendelse (A40 og dens slektninger) sender den pensjonerte posten også, inaktiv, med Patient.link begge veier. På enhver

annen hendelse, som en A08, slås ingenting sammen og en advarsel sier at den forrige identifikatoren fortsatt er aktiv.

• Tider. En fødselsdato i PID-7 går til patient-birthTime-utvidelsen. Et tidsstempel uten offset tar den konfigurerte

tidssonen, ellers offsettet på MSH-7 (v2 antar avsenderens lokale tid), ellers UTC. En fødselsdato er unntaket: uten offset fra noen av de tre blir den utelatt i stedet for å bli merket som UTC, fordi en feil offset kan flytte en fødsel til en annen dag. birthDate beholdes, og en advarsel sier at tiden ble droppet og at å sette en tidssone for datastrømmen beholdes.

• Resultater. Gjentakelser av et tekstresultat slås sammen med linjeskift. Et ED-resultat eller et kodet resultat hvis verdi er åpenbart Base64, blir et

DocumentReference som Observation peker på i derivedFrom, ettersom en R4 Observation ikke har en vedleggverdi. En SN komparator på = droppes som overflødig; <> beholdes teksten, fordi ingen mengde kan si "ikke lik".

• Besøk. En A08 med en utskrivningsdato (PV1-45) er et fullført møte. En manglende eller ukjent pasientklasse er den null

smaken UNK, fordi R4 krever en klasse.

• Z-segmenter navngis i en advarsel, ettersom det ikke finnes en standard kartlegging for dem.

• Names. When the sender splits a family name (XPN.1, XCN.2) into its parts - a surname prefix and a surname, the person's

own and a partner's, as Dutch and Flemish names are sent - family is the whole name and the parts go in HL7's family-name extensions (humanname-own-prefix, -own-name, -partner-prefix, -partner-name).

• Procedures. PR1 becomes a Procedure with status unknown, since an ADT does not say whether it was done or planned; the

anaesthetist (PR1-8) and surgeon (PR1-11) are performers with SNOMED CT roles. An OPS code also gets its SNOMED CT category from its chapter, by HL7 Deutschland's OPS-SNOMED-Category map, which ISiK requires.

8.4.2 Hva et nettsted legger til: bunke-skriptet

Et nasjonalt profil ønsker ofte hva en HL7 v2-melding ikke bærer: et sykehusets IK-nummer eller ODS-kode, hvilket kontakt nivå et besøk er (ISiK), om et gitt navn er et fornavn eller en initial (den nederlandske nl-core). Perfuse gjetter ikke disse. En fhir-destinasjons bundle_script er der et nettsted skriver dem: JavaScript kjørt på hver konvertert Bundle, som bundle, før det valideres og sendes. Hva skriptet lar være er hva som går ut, sjekket som noen konvertering, og et skript som kaster feiler meldingen som noen transformer gjør. Konsollen har det under destinasjonens *Legg til hva dine systemer vet*.

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.

Bunken går gjennom Perfuses modell på vei tilbake, så et skripts endringer sjekkes og skrives i målets FHIR-versjon. Medlemmer modellen ikke har noen felt for, beholdes som skriptet skrev dem, inne i datatyper også.

8.4.3 US Core 9.0.0 og USCDI v6

-us-core (og claim_us_core på en fhir-destinasjon) setter et US Core-profil i meta.profile, men bare på en ressurs som har blitt sjekket mot dette profilen og funnet å være i samsvar. En som ikke møter kravene, blir likevel konvertert og sendt uten kravet, og en notis gir grunnen, som for eksempel "US Core krever en møte-type, og denne Encounter mangler". Sjekkingene er transkribert fra US Core 9.0.0, den versjonen ONC's 2026 Standards Version Advancement Process godkjenner for USCDI v6. De dekker Patient, Encounter, laboratorie-Observation og DiagnosticReport, Prøve, Praktiker, Organisasjon, Sted, Vaksinasjon, DocumentReference, møte-diagnose Condition og AllergyIntolerance.

Hva konverteren bærer, etter USCDI v6 dataklasse:

Ikke medtatt, fordi v2-meldinger av disse typene ikke inneholder dem eller Perfuse ikke kartlegger dem: Medisiner, Prosedyrer, Mål og preferanser, Helsestatusvurderinger, Omsorgsplan, Familiens helsehistorie, Medisinske enheter (UDI), Helseforsikringsinformasjon, Vitaltegn som en distinkt profil og Proveniens.

8.4.4 R4 i begge retninger

En FHIR-tjener som erklærer R4 aksepterer R4. Det var ikke sant for Møter før denne utgaven. Tjeneren konverterte hva den betjente til R4, men leste hva den mottok som om det allerede var i sin interne form, så en R4 Møte ble avvist med en 400. Det samme var hver bundle Perfuse egen ADT-konvertering produserte, fordi hver bærer Encounter.class, som R4 skriver som en enkelt kode.

Det ble funnet første gang noe postet en konvertert ADT til Perfuse egen R4-tjener. En test gjør nå det for hver kartlagt meldingstype, og en annen sjekker at alt som skrives som R4 leses tilbake uendret.

8.4.5 Internasjonal Pasientoppsum

GET /fhir/Patient/{id}/$summary, eller GET /fhir/Patient/$summary?identifier=system|value, returnerer en internasjonal pasientoppsummering (HL7 IPS 2.0.0): en FHIR document-samling som lister pasientens aktive problemer, allergier, medisiner, vaksinasjoner, resultater, vitaltegn, prosedyrer, enheter, tidligere sykdommer og omsorgsplaner, hver med en lesbar narrativ. Det er den korte rekorden en kliniker som aldri har møtt pasienten leser først, og oppsummeringen det europeiske helsedataspace bytter mellom land fra 2029.

Det bygges fra hva FHIR-butikken inneholder, og ingenting oppfinnes:

• Poster merket entered-in-error utelates.
• En løst betingelse havner under tidligere sykdom, ikke problemer.
• En medisinordre som ble stoppet eller fullført er historie, ikke en nåværende medisin.
• De tre seksjonene IPS krever (problemer, allergier, medisiner) er alltid til stede. Når en av dem ikke har noe i seg, bærer seksjonen den kodete tomme grunn unavailable og sier at serveren ikke har noen informasjon, "hvilket ikke betyr at det ikke finnes noen". En tom allergiliste må aldri lese som "ingen kjente allergier".
• Praktikerne, organisasjonene, medisinene og stedene postene peker på, er inkludert, så dokumentet kan leses på egen hånd.

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.

Utveksling → Helse-lenker → Del fyller innholdet med en pasients oppsummering: skriv inn pasientens FHIR-id og velg Bruk deres pasientoppsummering, deretter les den og opprett lenken. Byggingen blir auditeret som fhir.summary.

8.4.6 Overføringsoppsummeringer for post-akutte omsorg (PACIO)

Når en pasient forlater sykehuset for et sykehjem, et rehabiliteringsenhet eller hjemme helse, sender sykehusets EHR en C-CDA: en overføringsoppsummering, en utskrivningsoppsummering eller en CCD. Perfuse omgjør dette dokumentet til overføringsoppsummeringen som PACIOs Transitions of Care-veileder beskriver (hl7.fhir.us.pacio-toc 1.0.0): en FHIR R4 document-samling, US Core 8.0.1 inne, som mottakende fasilitets system kan arkivere uten at noen må lese XML.

• Hver enkelt av guideens femten seksjoner er til stede, hver med sin egen tekst, i guideens rekkefølge: forhåndsgodkjenninger, allergier, atferdshelse, funksjonell status, vaksinasjoner, utskrivningsinstruksjoner, medisinske enheter, medisiner, behandlingsplan, problemer, prosedyrer, grunn for henvisning, resultater, sosial historie og vitale tegn.
• En seksjon som dokumentet ikke har, sies å være manglende, aldri fylt inn. Den sendes ut tom, med den kodete grunnen unavailable og setningen "Det sendende dokumentet hadde ingen ... seksjon". En tom allergiseksjon må ikke leses som "ingen kjente allergier".
• En seksjon som bæres som ren tekst beholder sin tekst og får ingen poster. Prosa blir ikke omgjort til kodet data. Funksjonell status, atferdshelse (C-CDAs mentale statusseksjon), forhåndsgodkjenninger, medisinske enheter, behandlingsplan, utskrivningsinstruksjoner, grunn for henvisning og sosial historie sendes på denne måten i dag; notatene sier det for hver.
• Kodete poster blir ressurser etter samme regler som den vanlige konverteringen: allergier (US Core AllergyIntolerance), problemer og utskrivningsdiagnoser (US Core Condition, problem liste eller møtediagnose), prosedyrer, vaksinasjoner, resultater, vitale tegn og medisiner som en PACIO-medisinliste av MedicationStatements (104204-3, utskrevet medisinsliste, fra en utskrevne medisiner-seksjon; 104202-7, aktiv medisinsliste, ellers).
• Vitale tegn i FHIRs form. En systolisk og en diastolisk trykk målt sammen blir ett blodtrykkspanel (85354-9) med to komponenter, og en mer spesifikk kode (kroppsvekt målt, 3141-9) bærer også koden FHIRs vital-signs-profiler fikserer (29463-7), ved siden av den opprinnelige.
• Hvem og fra hvor. Dokumentets forfatter blir Compositions forfatter (en Practitioner, med NPI når kontrollsifferet er gyldig), dens forvalter blir forvalterorganisasjonen, dens omfattende møte blir oppholdet som sammenfattningen lukker. Et dokument uten person som forfatter, eller uten forvalter, avvises: guiden krever begge, og Perfuse vil ikke sette et navn på en klinisk rekord som ingen ga.
• Negasjon beholder sin betydning. "Ingen kjente allergier" (en negert allergi mot noen substans) sendes som SNOMED CT 716186003; en negert allergi mot ett legemiddel avvises, fordi FHIR ikke kan si det og ressursen ville si det motsatte; en negert problem er refuted.

Tre måter å lage en:

• A channel: a cda destination with write: transfer posts each document's transfer summary to the FHIR server's

Bundle endpoint (url), or writes <document>.transfer.json to dir. In the channel builder: Emit › A PACIO transfer summary.

• The command line: perfuse fhir transfer [-authority OID=URI] [-out dir] <document.xml>....
• The console: Documents, turn on Also make a PACIO transfer summary, and read the document.

Kontrollert med den offisielle FHIR-valideringen mot TOC 1.0.0 Bundle-profilen, mot HL7 sine egne C-CDA-eksempler (en overføringsoppsummering, en utskrivelsesoppsummering og en CCD). Den ene feilen den rapporterer, er i guiden: hver vitalt tegn matcher både sin simple-observation og sin vital-signs Bundle-inndelingspunkt, så det kan ikke unngås av noen avsender. Ikke gjort enda: å omdanne tekstbare seksjoners poster (funksjonell status, mental status, omsorgsplan, enheter) til kodete ressurser, og guidens TOC DocumentReference som indekserer en lagret overføringsoppsummering.

8.4.7 Abonnementer

Med -fhir-subscriptions sender FHIR-endepunktet varslinger når en Encounter eller en Appointment opprettes eller endres. Den følger FHIR Subscriptions R5 Backport IG for R4, som er hva CMS Interoperability Framework-kriterium 15 og TEFCA's FHIR-veikart bruker for appointment- og encounter-varslinger.

En klient oppretter en Subscription som navngir et emne, og valgfritt en filter som Encounter?patient=Patient/123. Emnene er listet i kapasitetsutviklingen:

En filter som navngir noe annet avvises, ikke ignoreres. En ignorert filter er et abonnement som varsler om hver pasient når klienten spurte om en.

Egenskapene implementeringen er bygget rundt:

• En bekreftet endring er aldri en tapt notifikasjon. Notifikasjonen blir registrert i samme database-transaksjon som endringen den beskriver, og leveres derfra, så den overlever en omstart. En test skriver en Encounter, starter en ny server på samme database, og sjekker at notifikasjonen ankommer.
• Notifikasjoner ankommer i rekkefølge, og hull er synlige. Hendelse 2 blir ikke sendt før hendelse 1 er akseptert, og hver notifikasjon bærer den løpende tellingen, så en mottaker kan se når den har mistet en.
• Serveren bestemmer når en abonnement er aktiv. Et nytt abonnement er requested, og blir active bare når endepunktet aksepterer en håndtrykk. En klient som ber om active får requested. Et avvist håndtrykk prøves igjen fire ganger over omtrent femten sekunder før abonnementet blir en error: det går ut øyeblikket abonnementet lagres, ofte før klienten som opprettet det lytter.
• En full-resurs-notifikasjon bærer den versjonen som ble endret. En utskrivningsnotifikasjon bærer utskrivningen, ikke hva Encounter hadde blitt ved leveringstidspunktet.
• Feil er begrenset. En avvist levering blir prøvd igjen med en økende forsinkelse. Etter ti påfølgende feil går abonnementet til error: senere endringer blir talt, men ikke køet, og oppdatering av abonnementet gjenopptar leveringen fra den eldste holdte notifikasjonen. Tellingen viser da hvor mange ble mistet.

Hva en klient kan få serveren til å gjøre, er begrenset med vilje:

• Endepunkter må være https med mindre operatøren passerer -fhir-subscriptions-allow-http, som er for en testmottaker.
• Egress-politikken gjelder når et abonnement opprettes, igjen ved hver levering, og på den adresse hver forbindelse faktisk når (så et navn som endrer hva det løser til mellom sjekken og forbindelsen, er likevel avvist); omdirigeringer følges ikke.
• Nyttelasten standarder til id-only, som sier hva som endret og lar mottakeren hente det med sine egne legitimasjoner.
• Ingen melding mottakeren sender tilbake, vises til noen, bare statuskoden.

Det er av med mindre det ber om, fordi en gang det er på, kan en FHIR-klient få denne serveren til å sende pasientdata til en URL som klienten velger. Den trenger en R4-endepunkt som aksepterer skriving, og avviser å starte ellers.

Ikke implementert, så ingen trenger å finne ut ved å prøve:

• kanaler andre enn rest-hook
• hjerteslag
• varslinger ved sletting
• $status- og $events-operasjonene

Visningen Abonnementer viser hvert abonnements emne, filter og endepunkt, hvor mange hendelser det har hatt, hvor mange som er akseptert og hvor mange som venter, og siste grunn til at en ble avvist. Header-verdier og endepunktets spørringsstreng holdes tilbake, fordi det er der en abonnents legitimasjoner bor.

8.5 NCPDP Telekommunikasjonsstandard

Apotek-krav. Fast bredde-header fulgt av variable segmenter.

To detaljer som teller, begge av dem er lette å få galt og produsere plausibele resultater:

Headeren er nøyaktig 56 bytes og fast bredde. En kort header kan ikke detekteres bare ved lengde, fordi en avkortet header pluss følgende segmenter fortsatt overstiger 56 bytes. Detektering skjer ved at en korrekt header aldri inneholder en separatorbyte, så headeren skannes for en og en melding som har en blir avvist med antall bytes den mangler.

0x1E og 0x1C er gruppe- og felt start-markører, ikke separatorene. Å behandle dem som separatorene flytter hver felt en plass til venstre, og de fleste av de resulterende verdiene forblir plausibele — en mengde havner der en dags forsyning var forventet og begge er tall.

8.6 NCPDP SCRIPT

Elektroniske resepter, i XML. Den interne pakken kalles eprescribe fordi script var tatt av JavaScript-motoren.

Den sentrale sikkerhetsbekymringen er erstatningsflagget, og det leser motsatt av intuisjonen: på ledningen, betyr 0 at erstatning er tillatt og 1 betyr utlever som skrevet.

Et fraværende erstatningsflag avvises i stedet for å være standard. Begge mulige standarder når pasienten — en kan utlevere en generisk der legen krevde merkevaren, den andre forhindrer en erstatning som legen tillot — så det finnes ingen trygg antagelse og meldingen stopper.

En Schedule II-resept med refiller avvises, og byggeren vil ikke produsere en.

Avvisninger og advarsler holdes som separate lister i stedet for en liste med alvorlighetsmerking, fordi en leser som må sjekke en alvorlighetsfelt for å vite om meldingen ble sendt, vil til slutt ikke sjekke det.

Elektronisk forhåndsgodkjenning (PAInitiationRequest, PARequest, PAAppealRequest, PACancelRequest) og Real-Time prescriptionsfordel er besvart av betaleren på /ncpdp/script og /ncpdp/rtpb, fra legemiddelformular; se CMS-0057.

8.7 DICOM

Bildebehandling. Perfuse kan motta DICOM-objekter, spørre en fjernarkiv og lagre til en, over de klassiske DICOM-nettverkstjenestene eller over DICOMweb, og den kan holde et arkiv av sin egen for visere.

DICOM er ikke en meldingsformat på samme måte som de andre — objekter er store, og assosieringshåndtrykkingen betyr mer enn payload-parsing. De called_ae og calling_ae-tittelene er den vanligste årsaken til at en første forbindelse feiler, og feilen ser ut som et nettverksproblem i stedet for et konfigurasjonsproblem.

8.7.1 Hva en C-STORE-lytter aksepterer

Latt åpne, aksepterer en DICOM-lytter alt fra noen som kan nå porten. Fire innstillinger under Hva denne lytteren aksepterer snevrer dette inn, og den første er den som er verdt å forstå.

Kun aksepter disse kalende AE-titler er begrensningen. Den *kalte* AE-tittel — den som ligger ved siden av adressen — er navnet en avsender ringer, så den identifiserer denne lytteren i stedet for avsenderen, og den er ikke en begrensning. Enhver som kan nå porten kan bruke den korrekte kalte AE-tittel, fordi den er publisert til dem. Uten en liste over tillatte kallere, kan enhver vert på nettverket trykke bilder inn i en klinisk kanal.

Kun aksepter disse SOP-klassene og kun aksepter disse overførings-syntaksene tar komma-separerte UIDs. Tom aksepterer hver type objekt og forhandler hva som helst kompresjon avsenderen tilbyr, som inkluderer typer denne kanalens destinasjoner ikke kan håndtere. Avvisning ved assosiering er klarere for avsenderen enn å akseptere objektet og feile etterpå.

Største objekt akseptert er i bytes, og null betyr ingen begrensning. Hel-side-bilder og lange serier kan nå gigabytes, så begrensningen er ellers minne.

8.7.2 DICOMweb

DICOMweb er DICOM over HTTP: QIDO-RS-søk, WADO-RS og WADO-URI henter, STOW-RS lagrer. Nettlesere som OHIF snakker bare DICOMweb, og det gjør også skytjenestene for bildebehandling (Google Cloud Healthcare, Azure Health Data Services, AWS HealthImaging). Perfuse bruker det på tre steder.

Bildearkivet. Start serveren med -dicomweb-archive DIR (Innstillinger › Data › Bildearkiv) og den lagrer objekter i den mappen, indekserer dem i SQLite og tilbyr dem på /dicomweb på konsollens egen adresse: QIDO-RS på studie-, serie- og instansnivå, WADO-RS for objekter, metadata, ramer og bulkdata, WADO-URI på /dicomweb/wado og STOW-RS. Leseoperasjoner krever seerrollen og lagring operatørrollen, med en sesjon eller en API-nøkkel; hver lese- og lagringsoperasjon er loggført i Aktivitet som dicomweb.read eller dicomweb.store. En konto begrenset til en leier eller til kanalgrupper avvises, fordi arkivet tilhører hele serveren. Objekter lagres nøyaktig som de mottas, så hva en seer henter er bokstavelig talt det samme som ble lagret. Ramer returneres i overføringssyntaxen de ble lagret i; en forespørsel som ville kreve omkoding svarer 406 i stedet for et konvertert bilde.

En søk på en attributt arkivet ikke indekserer svarer 400 i stedet for å ignorere betingelsen og returnere flere studier enn det som ble bedt om. Indekserer: pasientnavn (jokertegn og fuzzy-matching med fuzzymatching=true), pasient-ID, fødselsdato, kjønn, studie-dato og -tid (intervaller), inntaksnummer, studie-ID, beskrivelse, henvisende lege, studie-, serie- og SOP-eksemplar-UID (lister), modalitet, kroppsdel, serienummer og -beskrivelse, SOP-klasse, eksemplar-nummer, rader, kolonner og antall rammeverk.

Kilden. type: dicomweb lytter etter STOW-RS, på /dicom-web/studies som standard (sammen med Orthanc og dcm4chee bruker), og sender hver objekt gjennom kanalen som en DICOM-melding. Kanalen trenger dataType: dicom. Sett en bearer- token eller et brukernavn og passord: uten en, kan hvem som helst som kan nå porten sende bilder inn i kanalen. Svaret lister hver objekt som lagret eller feilet, med DICOM-feilårsak, så en avsender vet hvilke som skal sendes på nytt.

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}

Destinasjonen er i levering, under DICOMweb-arkiv.

Peke OHIF mot arkivet

Bruk en DICOMweb-datakilde med qidoRoot og wadoRoot satt til arkivets adresse (skjermen Bilde viser den, med hele datakilde-blokken til å kopiere), wadoUriRoot til den adressen etterfulgt av /wado, imageRendering og thumbnailRendering til wadors, og supportsFuzzyMatching true. En visningsprogram på en annen opphav trenger den opphav i -dicomweb-cors (Tillatte nettleser-opphav som kan ringe det), og dens forespørsler trenger en API-nøkkel i Authorization-headeren, fordi en nettleser på en annen opphav ikke sender konsollens sesjonskoke. Å tilby OHIF fra samme opphav gjennom en omvendt proxy unngår begge.

Testet mot Orthanc med DICOMweb-utvidelsen, i begge retninger: destinasjonen lagrer i Orthanc, og Orthancs DICOMweb-klient søker i Perfuses arkiv og henter en studie som er byte-identisk med den lagrede. OHIF 3 lister arkivets studier og viser deres rammeverk med innstillingene ovenfor. OHIF og flere andre klienter sender type= uquotet i Accept- og Content-Type-hodene, som RFC 2045 ikke tillater; Perfuse aksepterer det.

8.8 IHE-dokumentdeling: XDS.b, XCA, XDR, MHD, PIXm og PDQm

Kliniske dokumenter delt mellom organisasjoner på samme måte som helseinformasjonsutvekslinger, Carequality og eHealth Exchange gjør: et repository holder dem, et register indekserer deres metadata, og en samfunn svarer andre samfunns spørringer gjennom en portal. Start serveren med -xds REPOSITORY-OID (Innstillinger › Data › Dokumentdeling) og den er alle tre, i denne serverens database, på disse adressene, hver som tar en API-nøkkel som en bærertoken (visningsrollen for å spørre og hente, operatørrollen for å sende inn; de fleste affinitetsdomener legger til gjensidig TLS foran):

SOAP-transaksjonene er SOAP 1.2 med WS-Addressing, og MTOM/XOP der dokumenter reiser (et dokument inline som base64 blir også akseptert). En feilet transaksjon blir svart med en RegistryResponse som bærer IHEs feilkoder, ikke en SOAP-feil: XDSDuplicateUniqueIdInRegistry, XDSNonIdenticalHash, XDSPatientIdDoesNotMatch, XDSMissingDocument, XDSRegistryMetadataError (med feltet som mangler), XDSStoredQueryMissingParam, XDSUnknownStoredQuery, XDSUnknownRepositoryId, XDSUnknownCommunity, og UnresolvedReferenceException. En erstatning (RPLC, XFRM_RPLC) gjør det dokumentet den erstatter, uaktuell, som deretter bare svarer på spørringer som ber om uaktuelle dokumenter; APND, XFRM og signs blir holdt som assosiasjoner. Hash og størrelse blir beregnet av repository og sjekket mot hva innleveringen sier. Dokumenter og metadata oppdatering (ITI-57) blir ikke støttet, og en innlevering som ber om det blir avvist med grunn.

MHD er samme register i FHIR: et dokument levert over MHD finnes ved ITI-18 og over XCA, og ett levert over XDS.b finnes ved ITI-67. En DocumentReferences id er postens UUID, masterIdentifier den unike id, og vedleggets url er ITI-68-adressen til dokumentet. Pasienter løses til affinitetsdomenets identifikator fra FHIR-butikken: den første identifikatoren hvis system er urn:oid:, eller Pasienten som følger med i Bundle. PIXm svarer på hver annen identifikator til Pasienten med den gitt (sourceIdentifier=system|value, innsmalere av targetSystem), og 404 for en den ikke kjenner; PDQm søker etter identifikator, navn, fødselsdato, kjønn, adresse og telecom.

Publisering. En kanals xds-destinasjon publiserer hver klinisk dokument den mottar, et CDA-dokument eller et som er med i en HL7 v2-melding, til ethvert XDS.b-repository med ITI-41. Metadaten leses fra dokumentet: pasienten (identifikatoren i patient_domain, affinitetsdomenets tildelingsmyndighet), tittel, type (som typeCode og, med mindre den er satt, classCode), opprettelse og tjenestetid, forfatter, konfidensialitet, språk og format (C-CDA 2.1 eller 1.1 strukturert innhold, XDS-SD eller mimeTypeSufficient, fra dens maler); og fullføres fra hva et dokument ikke sier: senders source_id, facility_type og practice_setting hver registry krever. Repositorys RegistryResponse bestemmer leveringen: en feil eller en feil i en PartialSuccess er en feilaktig levering med registrys feilkoder.

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. Legg til direct_from (din Direct-adresse) og direct_to (mottakerens) og samme destinasjon sender XDR som Directs transport, som Direct-prosjektets *XDR og XDM for Direct Messaging* beskriver det: en Direct-adresseblokk (urn:direct:addressing) i SOAP-hodet navngir avsender og mottakere, og innsendingens intendedRecipient navngir hver mottaker (||^^Internet^address). Peke url mot mottakerens XDR-endepunkt eller en HISP som tar XDR. XDR reiser over TLS, vanligvis med en klient-sertifikat (tls), og er ikke S/MIME. En direct kilde tar XDR også (se Direct nedenfor).

    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 og PDQ i HL7-versjon 3. Med pasientindekset på (-mpi), er /pixv3 en PIX Manager og /pdqv3 en PDQ Leverandør over SOAP 1.2, for sykehus og bytte som fortsatt snakker IHEs v3-profiler. En kilde mater pasienter med ITI-44 (rekord lagt til PRPA_IN201301UV02, revidert PRPA_IN201302UV02, duplikater løst PRPA_IN201304UV02): pasientens første identifikator er dens rekord, de andre og de i asOtherIDs er identifikatorer den bærer, og en sammenslåing folder den forrige rekordens identifikator inn i den overlevende, som en HL7 v2 A40 gjør. ITI-45 (PRPA_IN201309UV02) svarer på de andre identifikatorene til personen som holder en, innsmurret av dataSource, i Patient.id; den spørte identifikatoren kommer bare tilbake i den gjentatte spørringen. ITI-47 (PRPA_IN201305UV02) matcher demografi (navn, kjønn, fødselsdato, identifikator, adresse, telecom) med indeksets egen matcher, minimumDegreeMatch som en score på 100, otherIDsScopingOrganization begrensning av domener, og initialQuantity sidning av svaret: resten kommer med QUQI_IN000003UV01 for ti minutter, eller blir droppet av dens avbryt. Svarene følger transaksjonenes caser: en ukjent pasient eller domene er AE med feil 204 og plasseringen av parameteren, en kjent pasient med ingenting i domenene som spørres, er NF. v3 navngir en myndighet bare med OID, så en identifikator hvis system er en URL uten OID bak (noen nasjonale numre) blir utelatt fra v3-svar og gitt over FHIR; sett enterprise-identifikatorens system til en OID (urn:oid:..., i indeksinnstillingene) for EUID og custodian å dukke opp. Viserrollen spør og operatørrollen mater; hver transaksjon blir audited med en identifikator, aldri et navn. En bare v3-melding postet som application/xml blir svart i samme, som er håndig for testing ved hånden.

Utveksling › Dokumentdeling viser hva registry inneholder og hvor den nås, finner en pasients dokumenter i denne registry eller en annen (en registrys ITI-18 eller en gateways ITI-38), laster ned en og publiserer et CDA-dokument manuelt med metadaten en destinasjon ville gi den.

Verifisert mot NIST XDS Toolkit 7.13.0, IHE-referanseimplementeringen: Perfuses ITI-41, ITI-18 og ITI-43 mot dens Registry/Repository-simulator (akseptert med ingen valideringsfeil, dokumentet hentet byte-identisk), og dens Initiating Gateway-simulator som spør og henter fra Perfuses Responding Gateway over XCA, med ingen feil i loggen. Hvert SOAP-melding Perfuse skriver validerer mot ebXML Registry 3.0 og XDS.b-skjema, og MHD DocumentReference og SubmissionSet mot IHE MHD 4.2.2 med HL7 FHIR-validereren. XDR fra en xds-destinasjon med en Direct-adresseblokk ble akseptert av verktyets Document Recipient-simulator, hvis metadata-validering fant den ene feilen beskrevet i docs/verification.md, og av ONC SITES XDR-validerer, Direct XDR-sjekklister (h)(2)-sertifiseringstesten anvender. PIX og PDQ v3-svarene validerer mot IHEs HL7 V3-skjema (NE2008 multicacheschemas), og IHEs egne eksempel-meldinger (ITI-44-feed, slå sammen, ITI-45-spør, ITI-47-spør, fortsettelse og avbryt) besvares som deres publiserte svar viser. Ikke sjekket mot en uavhengig PIX eller PDQ v3-implementering, Gazelle eller en Connectathon.

8.9 Direkte sikker meldingsutveksling

Direct er hvordan US-leger sender hverandre henvisninger, sammenfatninger og resultater via sikker e-post: hver melding er signert med avsenders sertifikat og kryptert til mottakers (S/MIME), og reiser mellom HISPer (Health Information Service Providers) som utsteder adresser og garanterer for dem. Perfuse er kantsystemet ved siden av din HISP, ikke en HISP: HISP utsteder din adresse, dens sertifikat og dens nøkkel, og du beholder dens tillitsbunt (slik som DirectTrusts). Det følger Direct Applicability Statement for Secure Health Transport 1.2, Implementation Guide for Delivery Notification, IHE XDM (ITI TF-1 Annex 15) for dokumenter med metadata, Certificate Discovery for Direct Project Implementation Guide (DNS og LDAP), og XDR og XDM for 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

Mottak. En direct-kilde er SMTP-serveren HISP leverer din adressens e-post til. Den tar imot e-post bare for den adressen (alt annet avvises ved RCPT), krever STARTTLS når det er gitt et sertifikat, og åpner hver melding før noe leser den: dekrypterer den med din nøkkel, verifiserer signatur mot dine ankere og sjekker at signatur-sertifikatet er for Fra-adressen eller dens domene. En melding som ikke er kryptert S/MIME, er signert av en sender du ikke stoler på, eller er signert av et sertifikat for noen andre, avvises ved DATA med årsaken, så HISP beholder den og rapporterer den til senderen; Perfuse aksepterer aldri hva den deretter dropper. Et XDM-pakkes dokumenter blir hver en melding (sjekket mot hasene i dens metadata); ellers hver vedlegg blir en melding, eller teksten når det ikke er noen. Med smtp_host satt, hver melding tatt imot besvares med en signert, kryptert "prosessed"-bekreftelse (MDN), og bekreftelser som ankommer for hva du sendte, logges.

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

Fra HISPs postkasse. En HISP som beholder e-post i stedet for å levere den gir adressen en IMAP-postkasse: imap leser den (TLS eller STARTTLS, hver avstemming en ny sesjon), åpner hver melding som ovenfor, flytter hva som ble tatt til move_to (eller sletter det) og hva som ikke kunne åpnes til error_folder, så ingenting leses to ganger. listen kan da bli utelatt. En HISP hvis e-postserver har et privat sertifikat tillits med tls.ca_file (dets sertifikat, eller dets myndighets) og tls.server_name; verifisering kan ikke slås av.

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

XDR. xdr tar imot XDR på /xdr på sin egen HTTPS-adresse, som en HISP sender Direct som er konvertert til SOAP eller en partner sender punkt-til-punkt: en ITI-41 Provide and Register-forespørsel hvis dokumenter hver blir en melding. En innsending hvis Direct-adresseblokk navngir en annen adresse, blir avvist, og en som kanalen ikke tar imot, blir besvart med en RegistryResponse-feil som sier hvorfor. client_ca_file krever en klient-sertifikat fra disse myndighetene. XDR er beskyttet av TLS, ikke S/MIME, så en kilde som bare tar imot XDR, trenger adressen, men ikke sertifikatet, nøkkelen eller ankrene. Hvert dokument blir en melding av kanalens dataType: CDA-dokumenter trenger raw (videreformidlet som de er) eller hl7v3, siden standarden, hl7, forventer HL7 v2 og avviser dem.

    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

Utveksling › Direct listar Direct-adressene dine kanaler sender og mottar som, med deres sertifikater, utløp og ankere; beholder adresseboken over korrespondenter (navn, organisasjon, notater og sertifikat, limt fra deres HISP eller funnet i DNS eller LDAP, og avvist når det ikke er for den adressen eller domenet); og søker opp en adressens sertifikater i DNS eller LDAP uten å lagre dem. Boken er katalogen direct-certs ved siden av databasen, en PEM-fil per adresse eller domene, som en destinasjon leser med mindre den navngir sin egen recipient_certs_dir.

Verifisert mot OpenSSL 4.0s cms og smime i begge retninger: hva Perfuse signerer og krypterer OpenSSL verifiserer og dekrypterer (PKCS#1 v1.5 og OAEP-nøkkeltransport), og Perfuse åpner hva OpenSSL signerer og krypterer (AES-128 og AES-256). En melding laget med openssl smime og levert over SMTP mottas, åpnes og lagres av en kanal, og en som Perfuse sender en melding til en annen gjennom en HISP-stedfortreder, som svarer med en MDN avsender åpner. Sertifikater finnes i OpenLDAP 2.4 (adresse-bundet og domene-bundet, skrevet av OpenLDAPs egen ldapadd); en Direct-melding leses fra en GreenMail IMAP-postboks og åpnes, og en som ikke er Direct flyttes til feil-mappen; XDR fra en xds-destinasjon tas av en direct-kilde og avvises når den er adressert til noen andre, og aksepteres av NIST XDS Toolkit's Document Recipient og ONC SITES XDR-verifisering; SITES Direct XDR Edge Test Tool sendte både minimal og full metadata-meldinger til en direct-kilde, som tok dem. Mot ONCs Direct-sertifikat-verifisering verktøy, en Direct-destinasjon velger riktig sertifikat, eller ingen, i alle 18 av dens oppdagelses-tilfeller (D1 til D18: utløpte, revokerte og AIA-utstedte sertifikater, SRV-prioritet og vekt, en utilgjengelig katalog). En Direct-kilde leser en melding fra SITES egen HISP (Apache James) over IMAP med STARTTLS. Ikke testet ennå: SMTP-utveksling med SITES HISP (AWS holder utebunden post på port 25 for nye kontoer) eller med en akkreditert HISP.

8.10 SQL på FHIR-utsikt

En ViewDefinition (HL7 SQL på FHIR v2) gjør hver FHIR-ressurs av en type om til rader med navngitte kolonner, hver kolonne en FHIRPath-uttrykk, så FHIR-data kan leses som tabeller av DuckDB, Athena, Spark, et datawarehouse eller et regneark. Perfuse kjører dem med sin egen FHIRPath-motor: column, nestede select, forEach, forEachOrNull, repeat og unionAll, where, constant (hver value[x]-type), collection-kolonner, %rowIndex og getResourceKey() og getReferenceKey(type)-join-nøkler.

{
  "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" }
  ]}]
}

Overvåkning › SQL på FHIR kjører en visning over denne serverens FHIR-lagring (en pasient eller alle) eller over ressurser limt inn (NDJSON fra en bulk-eksport, en Bundle, en JSON-array), viser radene og laster dem ned som CSV, NDJSON eller Parquet. Den starter fra fem eksempelvisninger (pasientdemografi, observasjoner med en verdi, blodtrykk, tilstander, møter) og lagrer visninger i views-katalogen ved siden av databasen, en JSON-fil hver.

FHIR-endepunktet svarer på spesifikasjonens $sql-run på systemnivå, ved hjelp av GET eller POST, for en ViewDefinition-objekt gitt inline (subjectResource), ved subjectReference (ViewDefinition/<name>, en lagret visning) eller ved subjectCanonical (en lagret visnings url), med _format (csv, ndjson (standard), json eller parquet), header, patient, _since, _limit og resource for å kjøre over ressurser sendt med forespørselen i stedet for lagret. Dette er en leseoperasjon: en SMART-token trenger leseomfang for visningsressursens type, en token bundet til en pasient får bare den pasientens rader, og granulære omfang begrenser ressursene som leses, slik de gjør under en søk. Mer enn en million rader krever _limit, patient eller _since.

perfuse sof -view v.json [-format csv|ndjson|json|parquet] [-o out] files... kjører en visning over FHIR-filer uten en server: NDJSON-filene fra en bulk-eksport, Bundles eller arrayer.

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"

Parquet-filer har en radgruppe og upakkede PLAIN-sider; booleans er BOOLEAN, heltallstyper INT64, desimaler DOUBLE og alt annet UTF-8-strenger (en samlingkolonne som dens JSON).

Verifisert med den offisielle SQL på FHIR-testsuite (de 144 testene i sql-on-fhir.js-repositoriets tests/, kjørt på hver bygging: alle passerer), og Parquet-utdata leses tilbake av DuckDB 1.5.6 med riktige typer og verdier. Ikke støttet: SQLQuery og SQLView-biblioteker (SQL over visningstabellene), $sql-export, _format=fhir og source- og group-parametere; hver av dem avvistes med begrunnelse.

8.11 Digitale kvalitetsmål

En digital kvalitetsmåling teller pasientene i hver befolkning av en FHIR Measure over en målingsperiode (initial befolkning, teller, tellelle eksklusjoner og unntak, teller, teller eksklusjoner) og scorer resultatet. Svaret er en FHIR MeasureReport, formet som Da Vinci Data Exchange for Quality Measures (DEQM)-veilederen ber om. Dette er der CMS's eCQM-programmer og NCQA's digitale HEDIS er på vei.

I Perfuse er befolkningskriteriene FHIRPath ("language": "text/fhirpath"), kjørt av samme motor som SQL på FHIR. Hvert kriterium evalueres én gang per pasient. Fokus er en Bundle av pasientens journal (Patient-kompartimentet), og det har disse variablene: %subject (pasienten), %periodStart og %periodEnd (perioden, som dateTimes) og %"Measurement Period". Et kriterium gir true eller false; en enkelt verdi som eksisterer, teller som 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()"
  }
}

Befolkningene nestes som Målingsspesifikasjonen sier. En pasient er i tellen bare hvis den er i den innledende befolkningen. Et telleunntak fjerner pasienten før telleren vurderes. Et unntak teller bare for en pasient som ikke er i telleren. En proporsjons score er (teller − tellerunntak) / (telle − unntak − unntak); en ratios score er teller / telle; en kohort har tellinger og ingen score. Enkeltkriteriums-stratifikatorer deler hver befolkning etter deres verdi (kjønn, for eksempel).

Perfuse har ingen CQL-motor. De publiserte CMS eCQM-ene og HEDIS-digitalmålingene er skrevet i CQL, så de kan ikke kjøres som de er. En Måling hvis kriterier er CQL avvies med denne årsaken. Skriv logikken som FHIRPath i stedet. Kontinuerlig-variabel scoring, flerkomponent-stratifikatorer og Gruppe eller Praktiker-emner avvies på samme måte.

Overvåkning › Kvalitetsmål vurderer et mål over denne serverens FHIR-lager eller over limte ressurser, for en periode. Den tilbyr tre rapporter: en sammenfatting, en sammenfatting med pasienter i hver befolkning, eller en pasient. Skjermen viser befolkningene, poengsummen og stratene, og laster ned MeasureReport. Den starter fra tre eksempler: blodtrykk under kontroll, diabetes med et HbA1c-test, og pasienter sett i perioden. De er illustrative, skrevet for denne håndboken, og er ikke CMS eCQMs eller HEDIS-mål. Lagre til FHIR-lager sjekker målet og lagrer det som en Measure-ressurs.

FHIR-endepunktet svarer Measure/[id]/$evaluate-measure og Measure/$evaluate-measure?measure=<url>, ved GET eller POST av en Parameters-ressurs. Parametere:

• periodStart og periodEnd: påkrevd. En dato betyr hele dagen.
• reportType: summary, subject eller subject-list.
• subject: Patient/<id>.
• reporter: Organization/<id>. Når denne er fraværende, inneholder rapporten en organisasjon navngitt av serve -measure-reporter.
• measure: et mål sendt inline, som en POST-parameter.

Rapporten returneres, ikke lagret. Operasjonen er en leseoperasjon, så en SMART-token trenger leseadgang til Måling og Pasient. En token bundet til en pasient får en individuell rapport om den pasienten og ingen andre.

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... evaluerer en måling over FHIR-filer (en bulk-eksports NDJSON, Bundles, arrayer) uten en server. -measure example:example-bp-control kjører en eksempel som er levert, og -examples lister dem.

Verifisert. HL7 FHIR-validereren sjekker de medfølgende Målinger mot FHIR R4, uten feil. Den sjekker en sammenfatting, en individuell og en emne-liste Målingsrapport mot DEQM 5.0.0-sammenfattnings-, individuelle og emne-liste-profiler, også uten feil. Ikke verifisert: ekvivalens med noen publisert eCQM, siden ingen kan kjøres her uten CQL.

8.12 Pasientindekset (MPI)

En masterpasientindeks kobler sammen alle systemers journaler for en person (sykehusets MRN, klinikken, laboratoriet) til én bedriftsidentifikator, EUID. Den er av til noen bestemmer seg for å holde en, fordi den er en tabell over pasienters navn, fødselsdato og identifikatorer: slå på Innstillinger → Data → Pasientindeks (eller serve -mpi) og restart. Den bor i mpi.db ved siden av hoveddatabasen.

Mating det. Legg til en destinasjon av type mpi (Pasientregisteret i byggeren) til kanalene som bærer registreringer. Den leser PID fra hver HL7 v2-melding eller en FHIR-pasient på en rå kanal. Postens eget identifikator er PID-3-gjentakelse av type MR (id_type endrer det); de andre, og PID-19, blir dens andre identifikatorer. En tildelingsmyndighet med et universelt identifikator (PID-3.4.2 med type ISO) blir urn:oid:...; en med bare et navnerom kartlegges av authorities, eller blir urn:perfuse:aa:<namespace>. En A40, A34, A18 eller A39 slår sammen personen som har MRG-1s identifikator med personen som har PID-3s (no_merge ignorerer dem).

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

Sammenligning. En ny post blir koblet i denne rekkefølgen:

1. Pålitelige identifikatorer. En post som deler en identifikator fra et system som er listet som pålitelig (en nasjonal identifikator, et bedriftsnummer) er samme person, uten scoring. List aldri et system som en familie deler, som for eksempel en forsikringsabonnents abonnentnummer.
2. Score. Ellers finnes personene hvis poster som kan matche ved blokkering (samme lydende etternavn og fødselsår, samme fødselsdato eller samme telefonnummer) og scores med Fellegi-Sunter-vekt over etternavn og fornavn (Jaro-Winkler og Soundex, aksenter og punktering ignorert, byttede navn merket), fødselsdato (en dag og måned byttet er delvis enighet), kjønn, postnummer, telefon og adresse. Bare felt som begge postene har, teller. Scoringen er bevis funnet som en andel av mulig bevis. Blokkering bruker fem nøkler, så ett feil ikke skjuler en person: etternavnslyd og fødselsår, fødselsdato, telefon, begge navnenes lyd (i hvilken som helst rekkefølge) og postnummer med fornavnets lyd.
3. Avgjørelse. Som standard kobles ingenting på scoring alene. En post som scorer på eller over gjennomgangsgransen (60%) blir en ny person og mulig match venter på gjennomgangskøen; de som er på eller over automatisk terskel (90%) med etternavn og fødselsdato som begge er enige, merkes *sikkert*. Å koble to personer sammen til en (en overlagring) plasserer en pasients resultater i en annen pasients diagram, så automatisk kobling er en bryter en administrator slår på (Koble sikkert sammen uten å spørre noen) en gang køen har vist at de sikkert er riktige. Med den på, kobles en sikkert match når ingen andre personer scorer like høyt. Under gjennomgangsgransen er posten en ny person.

Nasjonale numre. NHS-nummeret (og Skottlands CHI og Nord-Irlands helse- og omsorgsnummer), Irlands PPSN og IHI, Tysklands KVNR, Østerrikes SVNR, Sveits' AHV-nummer, Nederlands BSN, Belgias nasjonale registernummer, Luxembourgs matricule, Frankrikes INS (NIR og NIA), Italias codice fiscale, Spanias DNI/NIE og CIP-SNS, Portugals SNS-nummer, de nordiske personnumrene (Sverige, Danmark, Norge med d-nummer, Finland, Island), de baltiske kodene, Polens PESEL, Tsjekkias og Slovakias fødselsnummer og de ungarske, rumenske, bulgarske, kroatiske, slovenske og greske numrene er kjent for registeret. Hver er lagret på én måte: under dens systemsystem, mellomrom og punktum fjernet, så NHS-nummeret sendt som urn:oid:2.16.840.1.113883.2.1.4.1|999 000 0018 av ett system og som https://fhir.nhs.uk/Id/nhs-number|9990000018 av et annet er ett identifikator. En HL7 v2 PID-3-gjentakelse hvis identifikatortype er NN og et lands trebokstavers kode (NNDEU, NNNLD) leses som landets hovednummer, og type NH fra NHS-myndigheten som NHS-nummeret. Hvert nummers kontrollsiffer testes: ett som feiler, beholdes på dens post, rapporteres (maskert) i svaret og brukes aldri til å koble eller å finne noen, siden et feilskrevet siffer vanligvis gjør en annen persons nummer. Danmarks CPR sjekkes bare for dato, fordi numre utstedt siden 2007 ikke trenger å gå gjennom den gamle modulus 11.

Innstillingene lister opp hver ordning med dens format, dens kontroll og systemet det lagres under. Systemer tatt fra landets egen FHIR-veileder (UK Core, fhir.de, Nictiz, CH Core, ANS, HL7 Italia, MedCom, de svenske, norske og finske OID-registrene) er merket som slike; de andre er standarder som kan endres til nasjonal verdi, som en nettsted kan gjøre per ordning (den gamle er fortsatt gjenkjent). Å stole på en ordning er ett hakk. Nasjonale numre vises i fullt til redaktører og over som standard og maskert (de siste tegnene) til alle andre; Hvem ser numre i fullt endrer det, ned til visere eller opp til administratorer bare. Der et lands lovgivning begrenser en nummers bruk (Frankrikes Référentiel INS, Irlands PPSN, Belgias nasjonale registernummer, Tysklands §290 SGB V), sier innstillingene det. GET /api/mpi/schemes lister opp ordningene og POST /api/mpi/check sjekker ett nummer uten å lagre det. FHIR $match og PIXm svarer autoriserte klienter med numre i fullt.

En dato skrevet dag- eller månedsførst (08/15/1972) beholdes som skrevet og matcher ikke en år-først en: USAs og Europas rekkefølger er uenige, og å gjette ville koble feil personer.

Pasientregisterets skjerm (Bygg) viser tellinger, finner personer etter navn, nummer, EUID eller fødselsdato og åpner hver person: deres poster, hver identifikator og hva som har skjedd med dem og hvem som har gjort det. Redaktører avgjør gjennomgang (Samme person kobler dem; Forskjellige personer holder dem adskilt for alltid), flytter en post til en annen person, tar en post ut (Ikke denne personen) og slår sammen to personer. Administratorer setter terskler, pålitelige identifikatorsystemer, nasjonale numre og EUIDs system. Hver søkning og hver person lest skrives til revisjonsloggen.

Svarer på andre. POST /fhir/Patient/$match (FHIR-operasjon, som IHE PDQm ITI-119 bruker) tar en pasient og returnerer personene som kunne være det, best først, hver en pasient hvis id er EUID, med hver identifikator, search.score og match-grade-utvidelsen (certain, probable, possible); onlyCertainMatches og count blir respektert. PIXm (/mhd/Patient/$ihe-pix, ITI-83) svarer fra indeksen: hver identifikator av hver journal som er koblet til personen, og EUID. Dette gjør også PIX og PDQ i HL7 v3 (/pixv3, /pdqv3; se IHE-dokumentdeling), som også forsyner det.

API-en er /api/mpi (oppsummering og søk), /api/mpi/persons/{euid}, /api/mpi/find, /api/mpi/reviews, /api/mpi/records (register, kobling, frakobling), /api/mpi/merge og /api/mpi/settings.

Vekter. Standard Fellegi-Sunter-vekter kommer fra litteraturen om record-linkage for sykehusregistreringsdata. Estimér fra våre poster (i innstillingene, administratorer; POST /api/mpi/estimate) passer dem til stedets egen indeks med forventning-maksimering, ingen gjennomgåtte par nødvendig: m (enighet blant sanntidige treff) fra parene som blokkering bringer sammen, u (enighet ved tilfeldighet) fra 20 000 par trukket tilfeldig, siden blokkerte par er enige om navn og datoer ved konstruksjon. Estimatet vises ved siden av vektene i bruk og endrer ingenting før det brukes og lagres. Et felt sammenlignet på for få par beholder sin standardverdi. Tilpasningen antar at feltene er uavhengige gitt klassen, som de ikke helt er, så behandle en stor endring med mistanke.

Målt. På FEBRL-datasett 3 (5 000 syntetiske poster av 2 000 personer, duplikatene med skrivefeil, byttede felt, manglende verdier og kallenavn; PERFUSE_TEST_FEBRL), registrert i filrekkefølge med en gjennomgående som svarer på hvert køtt par:

Ingen journal ble noen gang koblet til feil person, og ingen av de 2 000 nye personene ble køet unødvendig. De manglende forskjellene på nesten hvert felt (en fødselsdato og en adresse begge skrivefeil, for eksempel) og score under gjennomgangsterskelen. FEBRL er syntetisk og har få navnelikheter; en virkelig indeks har flere, så dens gjennomgangskø vil være lenger, og disse tallene er en gulv på omsorg, ikke et løfte.

8.13 Avgrenset

CSV og dens slektninger. Valgene er på kilde i byggeren, og format-referansen lister filnøklene.

Stier adresserer kolonner. En navngitt kolonne er tilgjengelig når en header-rad er erklært eller navnene er gitt; ellers er kolonnene posisjonelle.

8.13.1 Navngi kolonnene

Det er to måter, og de er eksklusive. Enten navner den første raden i filen dem — den første raden navner kolonnene — eller du lister dem selv, i rekkefølge. Å erklære en header betyr at raden ikke behandles som data.

Hvis ingen er satt, kan kolonnene bare adresseres ved posisjon, så et filter skrevet mot et navn har ingenting å sammenligne med. Å slå på headeren fjerner listen over navn i stedet for å beholde begge: med en header kommer navnene fra filen, så en liste som er igjen vil bli ignorert, og en kanal som leser som om den valgte navnene når filen valgte dem er vanskeligere å feilsøke enn en som nekter.

8.13.2 Hva et filter eller et skript ser

En avgrenset dokument blir mange meldinger, så dette må stå før du skriver noen.

Med splitting på, kjører alt per rad. Declarative trinn, filteret og transformer-skriptet ser alle en rad, og en sti betyr *denne* radens kolonne. Et filter som avviser en rad avviser bare den raden og ingen andre, og mottatt teller er rader i stedet for dokumenter.

Med splitting av, er meldingen hele dokumentet og en skrivning som krysser rader nektes i stedet for å bli brukt på den første. Denne nektelsen er bevisst: stille skrivning til rad én er det atferd som produserer en fil som ser omformet ut og ikke er.

8.13.3 De tre som endrer hva som teller som en feil

Aksepter rader med feil antall kolonner er av som standard. En rad med for mange eller for få kolonner er da en feil, som er hva som fanger en fil hvis form endret uten varsel. Å slå på aksepterer raden og lar manglende kolonner være tomme.

Klipperom mellomrom rundt hver verdi fikser det vanlige tilfelle av en verdi som er padet til en kolonnebredde. La det være av hvor trailing-rom er viktige, som de av og til er i en identifikator.

Behold blanke linjer som rader er av som standard og bør vanligvis være det. På, blir en blank linje en rad med tomme kolonner, som bare betyr noe når en teller må være lik filen nøyaktig.

8.14 Rå

Ingen parsing i det hele tatt. Meldingen er bytes.

Bruk dette når innholdet ikke er noe Perfuse forstår og ikke trenger å: en PDF som flyttes mellom systemer, et proprietært format, et allerede dannet dokument som videreformidles uendret.

Kosten er at ingenting som avhenger av struktur fungerer — ingen felt-nivå-transformasjon, ingen filter på et felt, ingen felt-nivå-sammenligning i paritetssjekkeren. En rå kanal er en pipe, og den er ærlig om å være en.

8.15 Velg

Hvis meldingen er HL7 v2, bruk hl7, selv om du bare har tenkt å videreformidle den uendret. Parsing gir deg sporet, felt-nivå-statistikk, mulighet til å filtrere senere og mulighet til å sammenligne. raw på parsbar innhold kjøper ingenting og mister alt dette.

Bruk raw når parsing ville feile eller ville være en løgn om innholdet.

8.16 SMART Helse-lenker og -kort

CMS's *Kill the Clipboard* ber leverandører om å akseptere en pasients poster fra en QR-kode ved innmelding, og å levere besøksposten tilbake på samme måte. QR-koden inneholder en SMART Health Link (shlink:/...): en adresse, en 256-bits nøkkel og, valgfritt, en etikett, en utløpsdato og en passkodflagg. Utveksling → Helse-lenker leser en.

Mottak. Lim inn lenken, eller skann den med kameraet der nettleseren kan (Chrome og Edge). Perfuse henter manifestet, dekrypterer hver fil med nøkkelen fra lenken, summerer hver FHIR-pakke - hvem pasienten er, hvor mange av hver ressurs - og sjekker hver SMART Health Card inne mot utgiverens publiserte nøkkel. *Levér til kanalen* overfører FHIR-innholdet til en kanal som en melding, som er hvordan det når EHR. Henting holdes til egress-politikken ved tilkoblingstid, plain HTTP avvisses, og svaret fra en server som ikke er en manifest-server vises aldri, fordi adressen kom fra en ukjent QR-kode.

Deling. *Del* krypterer en FHIR-pakke, hoster den og viser lenken og dens QR-kode en gang. Serveren beholder chifferteksten og ikke nøkkelen - den kan ikke åpne hva den hoster, og kan ikke vise lenken igjen. En passkod hasheres; ti feil passkoder deaktiverer lenken. Lenker utløper etter 30 dager som standard, kan tilbakekalles og lister hvor ofte og av hvem de ble hentet. Start serveren med -public-url satt til https-adressen pasientenes telefoner når; manifest-URL-en den bygger må være innenfor spesifikasjonens 128 tegn.

Verifisere et kort. *Verifisere et kort* tar en numerisk shc:/ QR (en blokk eller flere), en .smart-health-card-fil eller en JWS, og sier om signaturen matcher utgiverens nøkkel.

8.17 UN/EDIFACT

dataType: edifact leser UN/EDIFACT-utvekslinger (ISO 9735): ORDERS, INVOIC, DESADV, IFTSTA og resten, inkludert den europeiske helsekrav- og laboratoriemeldingen. Tjenestestreng-råd (UNA) respekteres, med frigjørings tegn og, for syntaksversjon 4, gjentakelsesseparator; funksjonelle grupper (UNG/UNE) er valgfrie. Utvekslingen leveres nøyaktig som avsender skrev den.

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"'

Konvolutten. UNTs segmenttelling og referanse, UNEs meldingsantall og referanse, og UNZs telling og referanse sammenlignes med hva utvekslingen inneholder. Med require, standard, avviser en mismatch utvekslingen (det er hvordan en overføring som ble avbrutt vises); warn aksepterer den og logger en advarsel; ignore sjekker ikke.

Stier, for kanal- og destinasjonsfilter, teller elementer og komponenter fra 1 i rekkefølgen segmentet skrives, som implementeringsveiledninger nummerer dem: BGM-2 (dokumentnummer), BGM-1.1, NAD(2)-2.1 (den andre NAD-part), LIN-3(2).1 (en repetisjon), UNB-2.1 (avsender), UNH-2.1 (meldingstype). En sti uten en forekomst addreser hver enkelt.

Splitt leverer en utveksling per melding, hver med den opprinnelige UNB (og gruppeheader) og trailere som teller en, så en bestilling kan filtreres, søkes og prøves på egen hånd. Destinasjonsfiltre ser hver del. En fildestinasjon navngir filer etter meldingstype (ORDERS_INVOIC-20261017.edi), og ${control_id} er utvekslingsreferansen.

CONTRL. Med acknowledge: contrl, en avsender som poster over HTTP besvares med en CONTRL-syntaks og tjenesterapport: UCI-handling 7 når utvekslingen ble lest og levert, 4 når den ble avvist eller ikke kunne leveres (HTTP 400 eller 502 så). Den kan ikke kombineres med split, siden en CONTRL besvarer en hel utveksling. Over AS2 er partnerens kvittering bekreftelsen.

Ikke tilbudt: meldingskataloger (som segmenter ORDERS D.96A tillater), så strukturen sjekkes, ikke innholdet; transformasjoner, som ville omskrive en partners dokument; og filter- eller transformasjonsskript (en preprosessor kjører, før parsing). Sjekket mot pydifact 0.1.8, en uavhengig parser, i begge retninger.

9 Bekreftelser

En bekreftelse forteller avsender hva som skjedde. For HL7 v2 over MLLP er det en ACK-melding; avsender vil ikke sende neste melding før den ankommer, og vil vanligvis sende på nytt hvis den ikke gjør det.

Å få bekreftelser feil er den vanligste måten en integrasjon tyst taper data, fordi en avsender som bekreftes har ingen grunn til å klage.

9.1 Tid

Dekket i meldingsflyt, og sammenfatningen er: ack.when er on_delivery som standard, hvilket betyr at bekreftelsen sendes bare etter at hver aktivert destinasjon har akseptert meldingen. on_receipt sender den så snart meldingen er parsert og køet.

9.2 Hva Perfuse sender

En AA når meldingen ble akseptert, en AE når den ble avvist på grunn av en årsak avsender kunne handle på, og en AR når den ble avvist på grunn av en årsak avsender ikke kunne.

Forskjellen mellom AE og AR er hvem som må gjøre noe. AE betyr at meldingen hadde et problem — et felt som ikke kunne tolkes som en dato, et påkrevd segment manglet — og avsenderen kan korrigere det og sende det på nytt. AR betyr at Perfuse ikke kunne akseptere det uavhengig av innhold, noe som vanligvis betyr et konfigurasjons- eller tilgjengelighetsproblem i denne enden. En avsender som sender på nytt etter en AR vil få samme svar.

9.3 Identifisere denne motoren

ack.application og ack.facility fyller MSH-3 og MSH-4 i bekreftelsen.

Når begge er tomme, speiler bekreftelsen den opprinnelige mottakeren — den bruker hva den innkommende meldingen hadde i MSH-5 og MSH-6. Dette er hva de fleste sendere forventer, og det er standard på grunn av det.

Sett dem eksplisitt når senderen validerer dem, eller når flere Perfuse-eksemplarer behandler samme feed og du trenger å vite hvilken som svarte.

9.4 Utløsende hendelse

ack.include_trigger_event sender ACK^A01 i stedet for bare ACK.

Noen mottakere krever det, og andre avviser det, som er grunnene til at det er en eksplisitt valg uten noen smart standard. Hvis en sender avviser dine bekreftelser og innholdet ser riktig ut, er dette det første du bør prøve.

9.5 Negative bekreftelser er ikke feil som skal skjules

En NACK behandlet som en suksess er en av de mest skadelige miskonfigurasjonene som er mulig, og det er vanlig nok til å være verdt å navngi. Det skjer når en destinasjon sender tilbake en negativ bekreftelse og sendersiden registrerer *overføringen* som suksessfull fordi byteene gikk ut og noe kom tilbake.

Perfuse leser bekreftelsen den mottar fra en MLLP-destinasjon og registrerer resultatet i henhold til det. En AE eller AR fra et nedstrømsystem er en leveringsfeil, og det prøves på nytt i henhold til destinasjonens retningslinjer, og teller mot feilraten som utløser varslinger.

9.6 Tidsavbrudd

Å vente på en bekreftelse er begrenset. Når den ikke ankommer i tide, er leveringen en feil og køes for nytt forsøk.

Et tidsavbrudd er ikke det samme som en avvisning og registreres forskjellig. En avvisning betyr at den andre siden vurderte meldingen og avviste den; et tidsavbrudd betyr at du ikke vet om den ble prosessert. Den forskjellen bestemmer om et nytt forsøk er trygt: å prøve på nytt etter en avvisning er meningsløst, og å prøve på nytt etter et tidsavbrudd risikerer en duplikat. Perfuse prøver på nytt etter et tidsavbrudd, fordi en manglende klinisk melding vanligvis er verre enn en duplikat, og mottakersystemet vanligvis er i stand til å oppdage en gjentakelse av meldingskontroll-ID.

Om den handelen er riktig for en gitt feed, er en vurdering, og det er verdt å gjøre bevisst for alt der en duplikat har en klinisk konsekvens — en ordre, en medikamentadministrasjon — i stedet for å akseptere standardvalget stille.

9.7 Kilder som ikke bekrefter

Ikke alle transportmidler har begrepet. En filkilde har ingen sted å sende en bekreftelse; en brokerkilde bekrefter til brokeren i stedet for til den opprinnelige senderen; en HTTP-kilde svarer med en statuskode.

Hvor kilden ikke kan levere bekreftelsesmodusen en kanal ber om, avvises kanalen ved lasting i stedet for å starte og stille bekrefte. En kanal som tror den bekrefter og ikke gjør det, er verre enn en som ikke starter.

9.8 X12-bekreftelser

Alt ovenfor handler om HL7 v2. X12 har sine egne bekreftelser, og i motsetning til v2 er de av på standard: en tom innstilling betyr ingen.

Den standarden er den tryggeste, fordi en handelspartner som ikke forventer en bekreftelse og mottar en, kan behandle den som en uønsket interchange. acknowledge-nøkkelen på en X12-kanal tar en av fire verdier:

Hva som skal sendes, er en egenskap ved handelspartnerforholdet i stedet for meldingen, som er grunnene til at det må konfigureres og ikke kan sluttes. En 999 erstatter en 997 for HIPAA-transaksjoner, men mange partnere — eldre betalingsforbindelser spesielt — er satt opp for å forvente en 997 og vil behandle en 999 som en ukjent fil.

9.9 HL7 v3-bekreftelser

En HL7 v3-kanal sender en bekreftelse på standard, som er motsatt av X12 og verdt å vite.

Årsaken er transporten snarere enn standarden: en v3-interaksjon ankommer vanligvis over en synkron tilkobling hvor senderapplikasjonen venter på en svar, og en sender som ikke mottar noe vil vanligvis prøve igjen. Det er hvordan en pasient blir registrert tre ganger.

Å slå det av er mulig og må gjøres eksplisitt — "ikke satt" og "satt til false" er med vilje forskjellige, så standarden står med til noen sier noe annet.

10 Levering, køing og nytt forsøk

En destinasjon som ikke kan nås er det normale tilfelle, ikke unntaket. Systemer starter om på nytt, nettverk slutter å fungere, og et sykehus grensesnittsmotor er utilgjengelig under eget vedlikeholds vindu. Levering er bygget rundt dette.

10.1 Kø per destinasjon

Hver destinasjon har sin egen kø. En destinasjon som feiler, påvirker ikke de andre, og hver har sin egen dybde, alder og nyttforsøksstatus.

Køing er per destinasjon snarere enn per kanal fordi feilen er per destinasjon. En kanalvid kø ville forsinke levering til tre fungerende systemer fordi et fjerde er nede, og de to situasjonene — en destinasjon utilgjengelig, alle fire utilgjengelige — ville se lik ut i statistikken.

10.2 Køinnstillinger

queue on a destination:

De to siste manglet fra denne tabellen og fra byggeren, og de er paret som stopper en disk fra å fylle seg. En kø uten noen av dem vokser til filsystemet er fullt, og denne feilen kommer som noe ubeslektet som bryter — en skrivefeil et helt annet sted — snarere enn som et køproblem.

Backoff øker mellom forsøk opp til max_backoff. Økende snarere enn fast, fordi en destinasjon som er nede vanligvis er nede i minutter snarere enn sekunder, og å prøve igjen hver sekund i ti minutter produserer flere hundre logginnførsler som begraver den som betyr noe.

10.3 Rekkefølge bevares

Innenfor en destinasjon, leveres meldinger i ankomstrekkefølge, og en melding som feiler holder sin plass. Senere meldinger venter bak den snarere enn å overtake.

Dette er riktig standard for klinisk data — en innleggelse og en utskrivning som gjøres i feil rekkefølge er verre enn begge som er forsinket — og det har en konsekvens verdt å forstå: en melding som alltid feiler, holder opp alt bak den.

Dette er grunnen til at kølengde og køalder er separate varslingsbetingelser. En dyp kø som tømmes, er et beskjeftiget system. En kø der den eldste meldingen bare blir eldre og eldre, er fastlåst, og varslingstypene queue-depth, queue-age og queue-stuck skiller mellom dem.

10.4 Når køing er deaktivert

Med queue.enabled false, er en feilet levering en feilet levering. Den blir registrert og ikke prøvd igjen.

Det er riktig valg når forsinket data er verre enn ingen data — en sanntidsvisning, en pagingsystem, noe hvor en melding levert førti minutter etter hendelsen ville være misvisende snarere enn bare forsinket.

Det er feil valg for noe som går inn i en rekord, hvor meldingen er like gyldig en time senere.

10.5 Nytt forsøk versus kø

Det finnes to mekanismer og de opererer på forskjellige nivåer.

retry på en destinasjon styrer umiddelbare forsøk innen én levering — en tilkobling som feiler, prøves igjen etter en kort pause, uten å forlate leveringsveien. Dette håndterer midlertidige feil: en droppet tilkobling, et øyeblikks nei.

queue styrer hva som skjer når disse umiddelbare forsøkene er uttømt. Meldingen forlater leveringsveien og prøves igjen senere på en lengre plan.

Begge eksisterer fordi de to feilene er forskjellige. En tilkoblingsnullstilling på første forsøk er vanligvis borte ved andre forsøk, og å gå gjennom køen for det ville legge til minutter med latency til en feil som varte millisekunder. En destinasjon som er skrudd av for vedlikehold, kommer ikke tilbake innen tre umiddelbare forsøk, og å hamre på den er meningsløst.

10.6 Hva en HTTP-endepunkt regner som levert

En HTTP-destinasjon har tre innstillinger som bestemmer om en melding behandles som sendt, og alle tre er på destinasjonen i byggeren.

Statuskoder som betyr levert. Tom betyr noen 2xx. Noen endepunkter svarer 202 Accepted for noe de ikke har prosessert ennå, og noen svarer 200 med en feil i kroppen — det siste er hva *Behandle som feil hvis svaret inneholder* er for. Å sette en eksplisitt liste er verdt å gjøre når en partner har fortalt deg hvilken kode betyr hva, fordi alternativet er å oppdage forskjellen fra en melding som aldri ble levert og aldri køet.

Følg omdirigeringer. Av ved default, og med overlappende formål. En omdirigering kan peke på en annen vert, så å følge en sender meldingen til et sted ingen har konfigurert og rapporterer suksess.

Bearer-token. Sendes som en Authorization-header. Den lagres med kanalen og vises aldri igjen, så å la boksen være tom når du redigerer en eksisterende kanal beholder tokenet som allerede er lagret, i stedet for å fjerne det.

10.7 Navngi og beskjær et arkivmappe

En fildestinasjon legger til en fil per dag og meldingstype som standard (20261012-ADT_A01.hl7), MLLP-rammet så filen kan spilles av med perfuse send. Fire innstillinger på destinasjonen endrer dette.

Filnavn (file_name) gjør en fil per melding i stedet, navngitt fra ${date}, ${timestamp}, ${control_id}, ${message_type} og ${destination}. Et navn som allerede er tatt (samme kontroll-ID to ganger) får et unikt suffiks i stedet for å overskrive meldingen der.

Legg til (append: true) skriver hver melding til filen Filnavn navner, så ${date}.hl7 er en fil per dag for hver type.

Suffix under skriving (temp_suffix, en fil per melding bare) standard er .part og fjernes ved omnavning når filen er fullstendig. Den som samler inn disse filene bør ikke plukke opp en halvskrevet, og en omnavning innen en mappe er atomisk. Endre det bare hvis samleren filtrerer på en annen utvidelse.

Slett etter (retain_hours) rydder filer i mappen eldre enn det gitt antall timer, sjekket på maks hver tiende minutt mens meldinger ankommer. Bare vanlige filer direkte i mappen slettes, aldri en undermappe. Tom eller null beholder dem for alltid, som er standard og er et valg i stedet for en oversikt — men et arkiv ingen rydder fyller disken, og en full disk stopper kanalen i stedet for arkiveringen.

10.8 Sending til en FHIR-tjener

Tre innstillinger bestemmer hvor mye som sjekkes før en pakke forlater.

Hevde US Core-overensstemmelse legger profilen til hver ressurs. Hevde det bare når ressursen bærer hva profilen krever, fordi en mottaker kan validere mot hevdningen og avvise en pakke som ellers ville blitt akseptert.

Valider før sending sjekker hver ressurs her i stedet for å lære fra mottakeren. Et avslag i den fjerne enden forteller deg mindre, senere, og ofte bare i en logg du ikke kan lese.

Behandle advarsler som avslag har bare en effekt når validering er på, og kontrollen er utilgjengelig til den er. Den er streng nok til å stoppe en pakke en mottaker ville akseptere, så den hører hjemme på en feed som tas i bruk i stedet for en i tjeneste.

10.8.1 Vertede FHIR-tjenester

En fhir-destinasjons auth-blokk logger inn på de vertede tjenestene, hvor et limt bearer-token slutter å fungere innen time:

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 signerer hver forespørsel til AWS HealthLake med Signature Version 4, med regionen lest fra URLen. azure får en Microsoft Entra-ID-token for Azure Health Data Services fra tenant_id, client_id og client_secret - en app-registrering som innehar FHIR Data Contributor-rolle - med FHIR-tjenestens URL som målgruppe. client_credentials gjør det samme mot en hvilken som helst OAuth 2.0 token_url. Tokenene gjenbrukes til en minutt før de utløper. De samme valgene finnes under Hosted service sign-in i kanalbyggeren.

10.8.2 Offentlig helse-rapportering av tilfeller

Velg Rapporter rapporterbar tilstand til offentlig helse på en FHIR-destinasjon, og den sender saksrapporter i stedet for samlinger. Hver melding sjekkes for en rapporterbar-tilstand-utløserkode: en diagnose, en laboratorietest eller en kodet resultat. Hvis den har en, blir meldingen en HL7 eCR 2.1.2 eICR, innkapslet i en eCR-melding og postet til URLens $process-message. Hvis den ikke har noen, sendes ingenting og ingenting feiler; destinasjonen teller den som ikke-rapporterbar.

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 er Reportable Conditions Trigger Codes, som en FHIR ValueSet eller eRSD Bundle. Den trenger en UMLS-lisens, så den er ikke inkludert; uten den brukes en kort innbygd eksempel til testing kun. source er hvor byrået sender sin Reportability-svar. Enhet er påkrevd fordi eCR ber om telefon og adresse, og en v2-melding har ingen av delene.

En rapport sier hva meldingen manglet i stedet for å oppfinne det, og hver gap blir logget. Prøv en melding i FHIR-laboratoriets Offentlig helse saksrapport-panel før du peker en live-strøm mot et byrå.

10.8.3 Laboratorieresultater til offentlig helse: ELR

perfuse elr -config elr.yaml results.hl7 konverterer et laboratoriums resultater til HL7 2.5.1 ELR-meldinger som helsemyndighetene mottar, én for hver melding med en rapporterbar resultat, og bare de bestillingene som inneholder en: en fullstendig blodprøve ved siden av en positiv SARS-CoV-2 test er ikke offentlig helsevern. Utløserkodene er de samme som for casereportering, RCTC du laster eller den innebygde eksempelet.

ELR navner alle ved OID eller CLIA-nummer, som ingen laboratoriefeed inneholder for avsender og mottaker, så disse kommer fra filen:

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}

Bestillingsfasiliteten, utførende laboratorium og tildelingsmyndighetene brukes bare der laboratoriets melding utelater dem, og hver bruk er en notat. Det som bare laboratoriet vet, fylles aldri inn: en resultat uten prøve-type går med SPM-4 tom og en notat som sier så, fordsom en gjettet prøve i en rapport til offentlig helse er verre enn et hull staten kan spørre om. Start med processing: T så lenge statens onboarding-team tester feeden.

Hva laboratoriet gjorde riktig, beholdes som det ble sendt. En underordnet bestilling (en susseptibilitetspanel eller en refleks-test hvis OBR-29 navngir forelderen och som ikke har noen ORC på egen hånd) går som mottatt, uten noen ORC eller prøve oppfunnet for den, og en underordnet uten noen rapporterbar resultat på egen hånd går med foreldrens, ettersom en susseptibilitet ikke betyr noe uten kulturen det tilhører. En notat etter PID blir hos pasienten, og ORC-14, tilbakekall-telefonnummer, kopieres fra OBR-17 når laboratoriet bare plasserte det der. Alle 28 eksempel- meldinger ONC publiserer for sin ELR-sertifiseringstool kommer ut gyldige uten feil.

MSH-2 skrives som ^~\&#, de fem tegnene ELR Release 1's errata krever og ONC's sertifiseringstool sjekker. Hvis din stats guide viser de eldre fire, legg til encoding_characters: "^~\\&" til filen.

For å sende dem fra en kanal i stedet for fra kommandolinjen, gi destinasjonen som nårer staten en elr-blokk som navngir samme fil. Hver laboratorie-resultat omformes på vei ut, og en med ingen rapporterbar er ikke sendt i det hele tatt, hvilket teller som levert, ikke feilet: staten ba om rapporterbare resultater bare.

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

Blokkene gjelder på en HL7 v2-kanal, til destinasjoner som leverer meldingen selv (mllp, http, tcp, fil, sftp, ftp, S3, Azure Blob, soap, meldingsformidlerne eller en annen kanal); kanalen nekter å laste ellers, og når filen mangler eller lacker sendingfasilitet, mottakende applikasjon eller mottakende fasilitet. Notatene skrives til loggen med meldingens kontroll-ID.

ELR-filen er kanalen companion, ikke en kanal: perfuse check og Kanaler-skjermen hopper over den heller enn å rapportere en kanal som ikke laster. I kanalen-byggeren er de samme to innstillingene under destinasjonen, i Lab-rapportering (ELR 2.5.1); utløserkodene-feltet åpner en gang en ELR-fil er navngitt, og lagring avviser en fil som ikke er ved siden av kanalen.

10.8.4 DICOMweb-arkiv

type: dicomweb lagrer hver objekt med STOW-RS: Orthanc, dcm4chee, skytjenester for bilde, eller en Perfuse-servers egen arkiv. Gi tjenestens rot (https://pacs.example/dicom-web); /studies legges til, og en URL som allerede slutter med /studies avvises heller enn å poste til /studies/studies. Autentiser med token (en bearer-token) eller username og password; headers legger til andre, som en skytjenestes prosjektnøkkel. Kanalen trenger dataType: dicom.

Serverens svar bestemmer resultatet, ikke bare statuskoden alene. En objekt som svaret lister som feilet er en feilaktig levering med DICOM-feilårsak, og det samme er en 202 som ikke lister noe som lagret: serveren tok forespørselen og beholdt ingen av den. Tidsavbrudd har en standardverdi på to minutter, fordi en stor serie er langsom.

10.8.5 Dokument-repositorier (IHE XDS.b)

type: xds publiserer hver klinisk dokument til en XDS.b-arkiv med ITI-41 Provide and Register: en CDA-dokument, eller en en HL7 v2-melding (MDM, ORU) bærer. Metadaten kommer fra dokumentet og destinasjonens innstillinger (source_id, patient_domain, facility_type, practice_setting), og arkivets RegistryResponse avgjør leveringen. Se IHE-dokumentdeling.

10.8.6 Vaksinasjons-registre

Hver US-stat immunisering-registrer (IIS) tar HL7 2.5.1-meldinger på samme SOAP-grensesnitt, det som CDC publiserte i 2011 (navnerom urn:cdc:iisb:2011). Det har to operasjoner: connectivityTest, som beviser endepunktet, og submitSingleMessage, som bærer meldingen. En VXU^V04 rapporterer en vaksine og kommer tilbake som en ACK; en QBP^Q11 spør om en pasients historie og prognose og kommer tilbake som en RSP^K11.

Velg Vaksinasjonsregister (CDC IIS web-tjeneste) som tjenesten til en SOAP-destinasjon, eller skriv 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 bygger omslaget, så det er ingen kropp å skrive. Brukernavnet og passordet går inn i forespørselen, der CDC WSDL plasserer dem, ikke i HTTP-autentisering. Versjonen er SOAP 1.2, WSDLs binding, med mindre du setter version: "1.1" for en registreringsveileder som ber om det. Hvor en registrering krever en klient-sertifikat, sett destinasjonens tls som for en hvilken som helst HTTPS-oppkall.

Registreringsbekreftelsen bestemmer om meldingen ble levert, ikke HTTP-status. En registrering svarer en avvist vaksine med HTTP 200 og en AR inni, så en destinasjon som stole på status ville rapportere en tapt vaksinering som levert.

warnings_are_errors: true (Behandle advarsler som feil) gjør at hver AE venter på en person. Svaret, som respons-skriptene og en HTTP-kaller som venter på kanalen leser, er registrets HL7-melding: ACK eller RSP med historikk og prognose. examples/iis inneholder tre kanaler å starte fra: VXU fra et EHR over MLLP, QBP-spørringer over HTTP og en lokal erstatter for et register.

The Connections-dashbord spør et register om dets connectivityTest når ingenting har blitt sendt i syv dager. Denne operasjonen finnes for dette formålet og sender ingenting, så det er den eneste applikasjonsnivåkontrollen Perfuse gjør. Den beviser adressen, TLS og SOAP-bindingen, ikke brukernavn og passord; bare en ekte sending tester disse.

En SOAP-kilde kan svare på samme måte: Svar som en vaksinasjonsregister, eller profile: cdc-iis på kilde. Den gjentar connectivityTest, tar meldingen fra submitSingleMessage, returnerer kanalens bekreftelse i return, og betjener CDC WSDL på ?wsdl. Et brukernavn og passord, når de er satt, blir sjekket mot de som er i forespørselen, og et feil par får WSDLs SecurityFault. En melding som kanalen avviser, blir returnert som en NAK, aldri som en feil, slik CDC-veilederen sier. Bruk den som en test-dobbeltgjenger, eller for å motta innsendinger på samme måte som en register gjør.

Ikke dekket: de statsspesifikke delene av påmelding. Hver registrering har sin egen endpoint, konto-prosess og lokal profil av 2.5.1-veilederen (påkrevde RXA- og OBX-felt, VFC-berettigelse, nekt-koder). Disse er meldingens innhold, som kanalens transformasjoner former; ingen stats endpoint er bygget inn. Perfuse er testet mot seg selv og mot innspilte registrerings-svar, ikke mot en live statsregistrering.

10.9 Når transporten sier ja og meldingen ikke ankom

"Ankom denne" er ofte ikke et spørsmål transporten kan svare på. En MLLP-mottaker returnerer en applikasjonsbekreftelse hvis mening er i dens tekst. En HTTP-mottaker returnerer 200 med en feildokument. I begge tilfeller lyktes transporten og meldingen ankom ikke.

Inspecter svaret på en destinasjon tar et skript gitt mottakerens respons. Returner false, eller kast, og leveringen blir merket feilet — hvilket betyr at den prøver igjen, køer og vises i feil-tellingen i stedet for å bli stille regnet som levert.

Den tilbys bare på destinasjoner som mottar et svar. På en som ikke kan, blir den avvist ved lasting i stedet for å bli liggende uten å kjøre.

10.10 Hva en leveringsresultat betyr

Disse blir registrert per destinasjon per melding, så en melding som nådde tre av fire destinasjoner blir registrert som nettopp det. Det finnes ingen kanal-nivå "suksess", fordi det ikke ville bety noe.

10.11 Langsom levering

En destinasjon som aksepterer meldinger, men tar lang tid om det, er et eget problem fra en som feiler, og det er lett å overse fordi hver resultat er en suksess.

Den slow-delivery-varslingsarten finnes for dette. Den er verdt å sette på alt hvor senders bekreftelse venter på levering, fordi en destinasjon hvis responstid har stille doblet, vil til slutt krysse senderens tidsavbrudd og begynne å produsere resendinger — og på det tidspunktet vises symptomet oppstrøms, i et system du kanskje ikke administrerer.

10.12 Skriving til en database

type: database kjører en uttalelse per melding med verdier bundet fra meldingen.

Placeholdere er driverens egne — $1 for postgres, ? for mysql og sqlite, @p1 for sqlserver — og Perfuse omskriver dem ikke. Dette er bevisst: en oversettelseslag som fikk en placeholder feil, ville binde en pasients navn til feil kolonne, og resultatet ville se ut som gyldig data i stedet for en feil.

En uttalelse skrevet i feil dialekt blir avvist når den blir lagret, og navnet på stilen driveren ønsker. Før denne kontrollen eksisterte, dukket feilen opp som syntax error at or near "," fra serveren når en melding ankom, som navnet en uttalelse du skrev, og sender deg til å se etter en skrivefeil i stedet for på dialekten.

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

En sitert parameter er en konstant i stedet for en sti, som er hvordan en kanal skriver sin egen navn eller en kilde-systemkode inn i en rad ved siden av meldingsdataene.

Verdier er alltid bundet som parametre. En ${...}-referanse inne i uttalelsen blir avvist: et navn som inneholder en apostrof ville bryte uttalelsen, og en fiendtlig verdi ville omskrive den.

10.13 Sending til en rå socket

type: tcp skriver til en socket med ramming du velger, som er hva en enhet eller et laboratorieinstrument vanligvis ønsker. MLLP er en ramming blant flere; denne destinasjonen tilbyr de andre.

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

Ramming har ingen standardverdi, med vilje. Skriving med feil ramming feiler ikke. Den fjerne enden leser meldinger delt på feil steder, eller venter på en avslutter som aldri kommer, og symptomet vises i mottakssystemet heller enn her.

Kun innstillingene den valgte rammingen bruker, er akseptert. En postlengde på en avgrenset strøm avvises heller enn ignoreres, fordi en innstilling som stille ignoreres er en noen tror er i virksomhet.

expect_reply endrer hva levering betyr. Uten det, betyr suksess at byte nådde operativsystemets sendebuffert — som en peer som krasjet et øyeblikk senere aldri leste.

10.14 Amazon S3, SQS og SNS

En kanal kan lese fra en SQS-kø eller en S3-bucket-prefiks, og levere til SQS, SNS eller S3. Alle fem er signert HTTP med ingen AWS SDK i binærfilen, og alle fem tar samme tilgangsinnstillinger: region, access_key_id, secret_access_key (skriv ${AWS_SECRET_ACCESS_KEY} for å lese miljøvariabelen), et valgfritt session_token og endpoint for LocalStack, MinIO eller en VPC-endpoint. Under Kanaler → Ny kanal, velg *Vi leser fra en Amazon SQS-kø*, *Vi samler objekter fra en Amazon S3-bucket* eller SQS-, SNS- og S3-destinasjonstypene.

Ingenting blir bekreftet til AWS før kanalen har håndtert det. En SQS-melding slettes etterpå og kommer ellers tilbake når synlighets-tidsavbruddet slutter, så en køs redrive-politikk er det som flytter en som fortsatt feiler til en død-brev-kø. En S3-objekt flyttes til processed/ etterpå, eller til error/ hvis den ikke kunne håndteres, så en dårlig fil ikke stopper resten.

På en FIFO-kø eller -emne, blir meldinger gruppert etter pasient som standard - SQS beholder rekkefølge innen en gruppe og ingen andre steder - og deduplisert etter innhold, så en gjentakelse ikke blir levert to ganger.

En S3-arkiv kan skrives direkte til Glacier med storage_class, og som JSON-linjer for Amazon Athena med format: ndjson; perfuse athena skriver ut tabellen. Referansen har alle innstillingene.

10.15 AMQP 1.0 og Azure

AMQP 1.0 er hva Azure Service Bus og Event Hubs kommuniserer med, og RabbitMQ 4, ActiveMQ og Artemis i tillegg til deres andre protokoller. En amqp-kilde mottar fra en kø eller en abonnement og aksepterer hver melding bare én gang kanalen har behandlet den; en som ikke kunne behandles, frigjøres som en feilaktig levering, så megleren leverer den på nytt og, forbi køens grense, markerer den som avdød. En amqp -destinasjon rapporterer bare suksess når megleren aksepterer meldingen. For Service Bus: addr er <namespace>.servicebus.windows.net:5671 med tls, username er navnet på den delt tilgangspolitikken, password er dens nøkkel, og address er navnet på køen, eller <topic>/subscriptions/<name> for å motta.

Azure Blob Storage: en azure_blob-destinasjon skriver en blob per melding i valgt tilgangsnivå - Hot, Cool, Cold eller Arkiv - og en azure_blob-kilde plukker opp blobs fra en prefiks, flyttende dem til processed/ eller error/ som S3-kilden gjør. Foretræk en SAS-token begrenset til containeren over konto-nøkkelen.

10.16 MQTT

En mqtt kilde abonnerer på et emnefilter (+ matcher ett nivå, # hver nivå under) på en hvilken som helst MQTT 3.1.1-broker: Mosquitto, EMQX, HiveMQ, AWS IoT Core, Azure Event Grid. Ved QoS 1, standardverdien, blir hver melding bare bekreftet én gang kanalen har håndtert den. MQTT har ingen måte å avvise en enkelt melding på, så en som ikke kunne håndteres blir latt ubekreftet og forbindelsen gjøres på nytt; brokkeren beholder sesjonen under klient-id (perfuse-<channel> med mindre client_id sier noe annet) og sender den på nytt, først i kø. QoS 0 er maks én gang: alt som sendes mens Perfuse er nede, går tapt. En mqtt destinasjon publiserer og, ved QoS 1, rapporterer suksess når brokkeren har mottatt meldingen.

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 ønsker en klient-sertifikat: gi tls.cert_file og tls.key_file.

10.17 IBM MQ

ibm_mq leser og skriver IBM MQ-køer gjennom kømanagerens meldings-REST-API (mqweb), som IBM MQ 9.1.5 og senere leverer på hver plattform, inkludert z/OS, så ingen MQ-klient er installert ved siden av Perfuse. Brukeren trenger MQWebUser-rollen og put, get og browse-myndighet på køen. En kilde blar gjennom den første meldingen, overfører den til kanalen og fjerner den ved meldings-id bare én gang den ble håndtert; en melding som feiler, blir først i køen. Kjør en lesere per kø. En destinasjon legger til vedvarende meldinger (med mindre non_persistent), med HL7-kontroll-id som korrelasjons-id.

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 er v3 for MQ 9.3 og senere (standard), v2 for 9.1.5 til 9.2. En kømanager med en AMQP-kanal kan også nås med amqp-koblingen.

10.18 Google Cloud Pub/Sub og Cloud Storage

En pubsub-kilde trekker fra en abonnement og bekrefter hver melding når den er håndtert; en som feiler blir levert tilbake med en gang (ved å sette dens bekreftelsesfrist til null), sammen med resten av batchen, så Pub/Sub leverer den på nytt og, etter abonnementets dead-letter-policy, sender den til dead-letter. En pubsub-destinasjon publiserer med HL7-meldingstype og kontroll-ID som attributter; order_by: patient setter sorteringsnøkkel fra PID-3.1, så et abonnement med meldingsrekkefølge holder hver pasients meldinger i rekkefølge.

En gcs-destinasjon skriver et objekt per melding, navngitt som en S3-nøkkel, i lagringsklassen valgt (STANDARD, NEARLINE, COLDLINE, ARCHIVE). En gcs-kilde plukker opp objekter fra et prefiks og flytter dem til processed/ eller error/ som S3-kilden gjør.

Begge logger inn som en tjenekonto: credentials_file er dens JSON-nøkkel. La den være tom på Google Cloud (en VM, GKE eller Cloud Run) for å bruke tjenekontoen som er koblet der. endpoint navngir en emulator (Pub/Sub-emulator, fake-gcs-server), som ikke tar noen legitimasjon.

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

10.19 Lese en postkasse (IMAP og POP3)

En email-kilde leser en postkasse og omdanner hva den finner til meldinger: hver vedlegg (take: attachments, standard, innsmurret av attachment_names-mønster), e-postens tekst (take: body), eller hele e-posten (take: raw) for et skript å ta fra hverandre. Laboratorier, bildebehandlingscentre og små praksiser sender fremdeles resultater på denne måten.

Hver kontroll logger inn, leser den ubleste e-posten fra eldst til nyest, og logger ut. Over IMAP hentes en e-post uten å bli merket som lest, levert til kanalen, og bare én gang alle meldinger fra den er akseptert, flyttes den til move_to (Behandlet), merkes som lest (after_read: flag) eller slettes. E-post som feiler, eller som ikke blir tatt (en avsender utenfor allowed_senders, ingen vedlegg som matcher attachment_names, større enn max_message_size), flyttes til error_folder (Feil) med årsaken i loggen. Begge mappene opprettes når de mangler. POP3 har ingen mapper eller flagg, så det sletter: slettinger blir bekreftet ved QUIT-en ved slutten av kontrollen, så en sesjon som avbrytes sletter ingenting og en håndtert e-post kan leses igjen (aldri tapt). POP3-e-post som ier tatt, blir værende på serveren og rapporteres én gang.

Innlogging er et passord (${MAIL_PASSWORD}; et app-passord for Gmail) eller OAuth 2.0 over SASL XOAUTH2, som Microsoft 365 krever (det har slått av passord-innlogging) og Gmail foretrekker:

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]

Med client_secret og ingen refresh_token, brukes Microsoft 365 app-bare tilgang (client-credentials-godkjenning, omfang https://outlook.office365.com/.default): en administrator registrerer appen, gir den IMAP.AccessAsApp og begrenser den til den ene postkassen med en Exchange-tjenesteeier. Med en refresh_token (en persons samtykke), brukes det delegerte omfanget IMAP.AccessAsUser.All eller POP.AccessAsUser.All, og en rotert refresh-token blir lagret for prosessens levetid. Gmail trenger en refresh_token: Google tilbyr ingen app-bare tilgang til en postkasse.

allowed_senders tar adresser og domener. Fra-linjen i en e-post kan forfalskes, så den holder ute uhell og villfarne e-post, ikke en angriper; en feed som må være tillitsfull, hører hjemme på Direct (S/MIME-signert), SFTP eller en VPN. security er tls (993 eller 995, standard), starttls (143 eller 110) eller none, som bare er tillatt til localhost. Kontroller er minst 10 sekunder fra hverandre (60 som standard), fordi e-post-tjenester begrenser kontoer som kontrollerer oftere.

Testet mot GreenMail 2.1.3 (IMAPS, IMAP, POP3S og POP3: innlogging nektet med feil passord, henting uten å markere som lest, FLYTT, flagg, slett, en for stor e-post nektet før den leses) og mot Gmails IMAP med et app-passord (opprett en mappe, legg til, hent, FLYTT, slett). OAuth ble testet mot en stand-in token-sluttpunkt bare: ikke mot Microsoft eller Google.

10.20 AS2

AS2 (RFC 4130) er hvordan mange betalere, klareringshus og leverandører utveksler EDI: en HTTP-POST hvor body er signert med avsendersertifikatet og kryptert til mottakers, besvart med en kvittering (en MDN) som navngir en digest av hva som ankom. S/MIME er samme kode som Direct-meldinger bruker. Begge ender er på kanalbyggeren: Handelspartnere sender oss EDI over AS2 som kilde, En handelspartner over AS2 som destinasjon.

# 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"

Mottak. En melding til en annen AS2-To, eller fra en avsender som ikke er i partners, blir nektet med 403 og ingen kvittering. En partners melding må være signert og kryptert med mindre dens post setter allow_unsigned eller allow_unencrypted. Payloaden dekrypteres, signatur kontrolleres mot partnersertifikatet (partnere bytter vanligvis selvsignerte sertifikater, som er greit: sertifikatet er tillit), og overføres til kanalen som dens meldingsformat sier. Partneren får kvitteringen den ba om: i svaret, eller postet til dens Receipt-Delivery-Option-URL; signert når den ba om en signert en. En melding som feiler, får en kvittering som navngir hvorfor (decryption-failed, authentication-failed, insufficient-message-security, unexpected-processing-error).

Sending. Hver melding signeres (SHA-256) og krypteres (AES-256-CBC). Med receipt: sync, som er standard, regnes det som levert først når kvitteringen verifiseres mot partner_cert_file, sier processed, og har samme digest (MIC) som what ble sendt; noe annet er en feilende levering og prøves på nytt. receipt: async ber om kvittering på receipt_url, som må være en AS2-kilde på denne serveren som listar partnern: meldingen regnes som levert så snart partnern aksepterer forespørselen, og en kvittering som senere ikke er enig logges som en feil. receipt: none ber om ingenting. unsigned, unencrypted og unsigned_receipt avslapper hver del for en avtale som sier det; username og password legger til HTTP-basisk autentisering for gateways som krever det. Innholdstypen følger kanalens format (application/edi-x12 for X12) med mindre content_type setter en.

Triple DES, AES-128 og AES-192 leses like godt som AES-256, siden partnere fortsatt sender dem, og likeledes er det streaming BER (uendelige lengder) som Java-gateways skriver.

Komprimering (RFC 5402). En komprimert melding leses uansett hvordan den ble bygget: komprimert før signering eller kryptering, eller en signert melding komprimert hel. Kvitteringens MIC følger RFC-en: over hva som ble signert når det er signert, over ukomprimert innhold når det ikke er. En melding som ville utvide seg forbi ti ganger kildens max_message_size, blir nektet med decompression-failed, så noen få kilobyte ikke kan kreve gigabyte med minne. En destinasjon komprimerer med compress: true, før signering og kryptering, som de fleste gateways gjør; spør partneren først.

En melding sendt to ganger. En partner som aldri fikk vår kvittering sender meldingen igjen med samme Message-ID (RFC 4130 seksjon 7.5). Kilden husker hver partners Message-IDs for duplicate_window (standard 720h, 30 dager; minst en time) og svarer på en ny sending med en processed kvittering uten å sende den videre igjen. Oppføringen lagres i databasen, så en omstart glemmer den ikke. En melding hvis behandling feilet, huskes ikke, så partnerens nytt forsøk går igjennom. Kopier som ankommer samtidig venter på hverandre, og bare den første sendes videre. Hvis oppføringen ikke kan leses, avvises meldingen med unexpected-processing-error og partneren prøver igjen senere, i stedet for å risikere en andre kopi. En melding uten Message-ID kan ikke gjenkjennes og logges som slik.

Samhandling testes mot pyas2lib 1.4.3 i begge retninger, med Triple DES og AES-256, komprimert og ikke, signerte synkroniseringskvitteringer inkludert.

10.21 OpenPGP

Betalere, clearinghus og statlige etater tar ofte og sender filer bare under OpenPGP. En pgp-blokk på en kilde åpner hva som ankommer; en på en destinasjon beskytter hva som forlater. Begge er på kanalbyggeren: Åpne PGP-krypterte meldinger under kilden, Krypter med OpenPGP på hver destinasjon.

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}

Nøkkel-filer leses relativt til kanal-filen, og leses og låses åpne når kanalen lastes: en manglende nøkkel eller feil passord stopper kanalen der, ikke på den første filen.

• På en kilde, åpnes hele filen, objektet, e-postvedlegget eller forespørselskroppen først og deretter deles den inn i meldinger, så en batch kryptert som en fil fungerer. En som ikke åpnes, avvises: en filkilde flytter den til feilmappe, en HTTP-avsender besvarer 400 med årsaken. require_signature avviser en melding som ikke er signert av en av verify_with; allow_unencrypted aksepterer en som bare er signert; pass_plain lar en melding som ikke er PGP i det hele tatt gå ubendret, for en mappe som mottar begge.
• På en destinasjon, krypteres det som ville blitt levert (til en av encrypt_to) og signeres (med sign_with), etter hver enkelt steg. En fil-, SFTP-, FTP-, S3-, Azure Blob- eller GCS-destinasjon navngir fortsatt filen fra den upaktede meldingen, så ${control_id} fungerer, og eventuell rammeverk er inni krypteringen. armor: true skriver .asc-tekst i stedet for binær; no_compress slår av komprimering; file_name er navnet som bæres inni meldingen.

Meldinger skrives med AES-256 i RFC 4880-formatet eldre mottakere leser, og nyere RFC 9580-formatet leses også. Kryptografien er ProtonMail/go-crypto; Perfuse implementerer ingen primitiv. Samarbeidstesting er testet mot GnuPG i begge retninger: gpg dekrypterer og verifiserer hva Perfuse skriver, og Perfuse åpner og verifiserer hva gpg skriver.

10.22 Levering til en annen kanal

En kanal-destinasjon overleverer meldingen til en annen kanal ved navn. Mottaker-kanalen behandler den som en vanlig ankomst: den registrerer den, filtrerer den, transformerer den og sender den videre.

Dette er den støttede måten å bygge en kjede. Den er bevisst synlig — to kanaler, to sett med statistikk, to oppføringer i meldingshistorikken — fordi en kjede skjult inni en kanal er en kjede ingen kan overvåke.

Meldingen overleveres i minne i stedet for over et nettverk, så det er ingen ramming, ingen bekreftelse og ingen tidsavbrudd mellom de to.

10.23 Hva skjer når prosessen avsluttes

Spørsmålet enhver som har kjørt en grensesnittsmotor spør først, og det som sjelden besvares, fordi det ærlige svaret vanligvis er pinlig.

Det ble svart ved å drepe prosessen med SIGKILL delvis gjennom en batch — som er hva en strømfeil, en minne-ut-mot-kill og en hypervisor-tilbakestilling alle ligner på fra innen — og telle hva som overlevde mot hva som var lovet.

Egenskapen som testes, er ikke "ingen blir tapt". Det er ikke oppnåelig og å hevde det ville være en løgn. Det er det smalere løftet en avsender faktisk pålitrer: en melding som ble positivt bekreftet, er en melding som ankom.

Med ack.when: on_delivery, som er standard, skrives hver destinasjon før bekreftelsen sendes ut, så en AA er en uttalelse om destinasjonen heller enn om en kø. En melding som ble drept før bekreftelsen, kan godt bli tapt, og det er correct: avsenderen ble aldri lovet noe og vil sende den igjen.

10.23.1 Bekreftelse ved levering

Fem kjøringer, drept etter 5, 25, 40, 75 og 110 meldinger av 120.

Løftet som ble holdt på hver avbrytning, og ingenting ble duplisert. En duplikat ville ha vært akseptabelt og en tap ville ikke: en sendt A08 er en plage mottakere absorberer, og et laboratorie-resultat som stille og rolig aldri ankom er en pasientsikkerhetshendelse.

10.23.2 Bekreftelse ved mottak

on_receipt svarer så snart meldingen er køet, før noen destinasjon har blitt skrevet. Dette kapitlet har alltid sagt en bekreftet melding kan fortsatt bli tapt på denne måten. Her er størrelsen på det.

Essensielt alt i flyt. Innstillingen er ikke en defekt og det finnes fôringer hvor det er riktig valg, men det bør velges med kunnskap om at en krasj diskarderer hva som har blitt bekreftet og ikke skrevet ennå, og at dette er nesten alt av en burst.

Ingenting gjenopprettet ved omstart, fordi perfuse run har ingen varig lagring. En destinasjon som ikke må tape meldinger under en nedtid, trenger queue.enabled, som trenger databasen som perfuse serve tilbyr — og perfuse run nekter nå slike kanaler heller enn å starte dem uten køen.

10.23.3 En avsender som dør halvveis gjennom en melding

Den farligste av disse feilene, fordi en trunkert HL7-melding vanligvis fortsatt parser. Segmentene før kuttingen er komplette og velformede, så en mottaker har ingen måte å vite at PID og PV1 ankom og OBX-segmentene som bærer resultater ikke gjorde.

En ramme ble åpnet, seks tiendedeler av en melding sendt, og tilkoblingen nullstilt i stedet for lukket. Den delvise meldingen ble ikke levert, lytteren overlevde, og en velformet melding sendt umiddelbart etterpå ble akseptert normalt, så fragmentet ble ikke båret inn i den neste meldingen heller.

Tilkoblingsloggen rapporterer nå hvor mange bytes av en ufullstendig ramme som ble forkastet, for hver feilmodus heller enn bare en ren lukking. Tidligere logget en krasjet avsender, en drept prosess og en trukket kabel alle messages=0 og ingenting annet, som ikke kan skille en tom helsekontroll fra et laboratorieresultat kastet bort ni tiendedeler av veien.

10.23.4 En full disk

Utmatings-utmattelse blir nå detektert og logget i stedet for svelget. To ting om det er verdt å vite.

Avsenderen får ikke en umiddelbar avvisning. Leveringen gjentas på den vanlige skjemaet — en sekund, to, fire, åtte — og den negative bekreftelsen ankommer omtrent femten sekunder senere. En avsender hvis egen tidsavbrudd er kortere enn det ser en stanset tilkobling i stedet for en AE, og vil konkludere at nettverket er feil i stedet for disken.

Og en volum som rapporterer null byte ledig kan fortsatt akseptere små vedlegg en stund, fordi tilføyelse av noen hundre byte til en fil hvis siste blokk har plass trenger ingen ny allokering. Den første skrivefeil skjer senere enn øyeblikket disken ble full.

10.23.5 Hva som ikke ble testet

En destinasjonsmappe som mister skrivetilgang. Den kunne ikke injiseres med chmod: motoren holder skrivefilen åpen, og å endre en filsmode påvirker ikke en beskriver allerede åpnet mot den. Å teste det ordentlig krever at volumet monteres som skrivebeskyttet eller fjernes under prosessen, noe som ikke er gjort. Den er nevnt her i stedet for å utelates, fordi et gap ingen nevner, leser som et gap ingen har søkt etter.

11 Varsling

Ingenting utenfor Perfuse vil fortelle deg at en fôring har stoppet. Avsenderen blir bekreftet og er tilfreds; mottakeren har ingen måte å vite at en melding ble sendt. Varsling er det eneste som står mellom en ødelagt grensesnitt og noen som legger merke til det uker senere.

11.1 Varslingstypene

De fire siste overvåker tilgang til pasientdata og beskrives nedenfor.

11.2 Stille er det hardeste å oppdage

En kanal som har stoppet å motta data produserer ingen feil. Det er ingenting å telle. Dette er hvorfor no-traffic eksisterer, og hvorfor det ikke er nok på egen hånd.

no-traffic er en fast terskel: varsle hvis ingenting har ankommet i, for eksempel, to timer. På en feed som aldri går stille, fungerer det. På en klinikkens laboratoriefeed er det nytteløst — feeden er stille hver natt og hele helgen, så en to-timers terskel varsler noen klokken 01.00 hver natt, og en terskel lang nok til å overleve helgen vil ikke merke en utsikt på en tirsdag morgen før på tirsdag ettermiddag.

Det finnes ingen enkelt tall som er begge deler. Dette er ikke et justeringsproblem; det er at spørsmålet "har denne feeden stoppet" ikke kan besvares av en konstant når feedens normale varierer med en faktor på hundre over uken.

11.3 Rytmebevisst deteksjon

below-rhythm sammenligner nåværende trafikk mot hva denne kanalen normalt gjør i denne timen på denne dagen i uken.

Perfuse lærer hver kanals uke fra sin egen innspilte historie: 168 timebøtter, mandag først så en arbeidsuke er sammenhengende. For hver bøtte holder den en median, en lav og en høy, en gulv, og hvor mange observasjoner den er basert på.

Grensen er en andel av normalt, som standard er 0.8 (80 prosent i konsollen) — varsle når trafikken faller under fire femdeler av hva som er normalt for denne timen.

11.3.1 Median, ikke gjennomsnitt

En enkelt backlogg-utløsning av førti tusen meldinger mot en normal på tre hundre flytter et gjennomsnitt langt nok til at feeden kan gå helt stille etterpå uten å noen gang falle under det. Medianen er uendret av en ekstraordinær time, som er nettopp den egenskapen som trengs.

11.3.2 Gulvet er en percentil, ikke minimum

Om en kanals rytme er pålitelig nok til å varsle på, bestemmes av dens laveste punkt, ikke dens høyeste punkt. En varsling for underskudd utløses når trafikken er *lav*, så bare laveste punkt kan fortelle om det vil produsere falske positiver. En tidlig versjon av dette sammenlignet høyde mot median og fikk det feil i begge retninger på samme tid: den diskvalifiserte en fullstendig jevn feed i en måned etter en backlogg, og den godkjente en genuint ustabil feed som svingte mellom to og ni hundre meldinger i samme time fordi dens høyde bare var tre ganger dens median.

Gulvet er den tyvende percentilen i stedet for minimum, fordi minimum trekkes til null av en enkelt bankferie. Og percentilen er ikke interpolert — hvert tall i en varsling klokken to om morgenen bør være et tell som feeden faktisk produserte, ikke en gjennomsnitt av to tell som den ikke gjorde.

11.3.3 Den vil si når den ikke kan si

En kanal med ingen historie overhodet utelates fullstendig i stedet for å behandles som en som har stoppet. En ny kanal må ikke se ut som en ødelagt en.

Hvor historien er for tynn eller for ustabil til å støtte en dom, avviser regelen å utløse i stedet for å gjette. "Jeg kan ikke ærlig si" er et førsteklasses svar her, og det er foretrukket fremfor en varsling som er riktig litt oftere enn tilfeldighet.

11.4 Konfigurere varslinger

Fra grensesnittet, underVarsler, per kanal eller på tvers av alle. Hver regel har en type, en terskel og hvor å sende varselet. Reglene lagres til alerts.yaml ved siden av databasen (eller filen -alerts navn) og treffer umiddelbart; inntil den første lagringen gjelder de innebygde reglene. Filen kan også redigeres manuelt: endringen blir plukket opp innen tretti sekunder, og en fil som ikke lenger lastes, rapporteres i loggen og reglene i kraft beholdes.

Verdt å gjøre før en feed går live i stedet for etter den første hendelsen. Den spesifikke samlingen verdt å ha på noen kliniske feed:

1. below-rhythm — feeden har gått stille når den ikke bør være stille.
2. error-rate — meldinger ankommer og feiler.
3. queue-age — noe er fast og ikke bare opptatt.
4. channel-down — kanalen kjører ikke i det hele tatt.

Den første er den som fanger feilen ingen andre vil rapportere.

11.5 Overvåking av tilgang til pasientdata

En bruddannonsere seg sjelden. Det ligner en kanal som bærer mer enn vanlig, trafikk klokken tre om natten på en kanal som bare arbeider på kontortid, en destinasjon ingen har satt opp, eller en person åpner pasient etter pasient. Perfuse overvåker disse fire, på som standard (serve -watch-access=false slår det av), og rapporterer hva den ser gjennom advarselsreglene ovenfor, så det er konfigurert, bekreftet og levert som enhver annen advarsel.

• Eksplosjoner (phi-volume). Hver kanals rate sammenlignes med sin egen historikk på samme klokkeslett, så en travel morgen er ikke nyheter. Terskelen er en multiplum av den vanlige raten, tre som standard. En eksplosjon er vanligvis en opphopning som slipper ut etter en nedtid, og det er også hva poster som hentes ut gjennom en kanal ser ut som.
• Natttrafikk på en dagkanal (phi-after-hours). En kanal regnes som dag-kanal når under 2 prosent av hva den har transportert, falt utenfor 07:00 til 19:00, i serverens tidssone.
• En ny destinasjon (phi-new-destination). Addressen er hva destinasjonsnavnene: en vert og en port, en URL, en mappe. Omnavngivning av en destinasjon er ikke nyheter; peking en på en ny vert er det. Addressene hver kanal har sendt til, lagres i access-watch.json ved siden av databasen, så en destinasjon endret mens serveren var ned, rapporteres likevel.
• Bulklesninger (phi-bulk-reads). Telt fra revisjonssporingen: meldinger åpnet, pasienter søkt etter eller sett på (PDQm, PIXm, identitetssøk), dokumenter og bilder lest (XDS, MHD, DICOMweb), tidligere autorisasjoner lest, sammenfatninger og visninger kjørt. Lesning av samme post igjen teller ikke dobbelt. Terskelen er hvor mange forskjellige poster i en minutt, ti som standard, av en konto fra en adresse.

Ingenting vurderes for en kanal før den har sendt 200 meldinger, fordi "uvanlig" ikke betyr noe uten en mønster. Mønsteret lærer fra de siste to ukene av meldingslagret når serveren starter, så en omstart gjør ikke hver kanal ny igjen. Alt som sees, holdes i femten minutter, så varslingen fjerner seg selv.

Den ser bare på og rapporterer. Den holder aldri opp en melding eller nektar en lesing: disse er heuristiske, og en strøm som stopper fordi en gjetning var feil, er et klinisk problem. Hver varsling sier hva som ble sett og hva det kunne uskyldig være, fordi de fleste av dem vil være uskyldige.

Administratorene ser hva overvåkningen har lært på Varslingsskjermbildet, under Overvåking av tilgang til pasientdata: hver kanals mønster (fortsatt lærer, bare på dagtid eller dag og natt), hvor mange destinasjoner den kjenner, og alt som er sett i de siste femten minuttene, inkludert hva som er under en regels terskel.

11.6 Hvor varslinger går

Varsler kan sendes som JSON til en webhook (-alert-webhook: Slack, Teams, Mattermost, PagerDuty, Alertmanager eller noe som aksepterer en POST), sendes som SNMPv2-feller til SNMP-managere (-snmp-traps, se SNMP), eller skrives til loggen for en samler å plukke opp. Det finnes ingen e-postlevering på egen hånd: peke webhooken mot en relé hvis varsler må ankomme som e-post.

En varsling som bare skrives til en logg ingen leser er ikke en varsling. Hvis Perfuse er det eneste som vil merke en stoppet feed, må varslingen nå en person.

12 Meldingslagringen

Hver melding Perfuse mottar blir registrert, slik den ble mottatt, før noe modifiserer den. Det samme gjelder for hva som ble sendt til hver destinasjon og hva som skjedde med den. Lagringen er en SQLite-fil gitt av -db.

12.1 Hva som lagres

Per melding: de rå byte som ankom, når de ankom, hvilken kanal, den parsede meldingstypen og triggerhændelsen, og filterresultatet.

Per destinasjon per melding: byte som ble sendt, resultatet, tiden det tok, og eventuelle feil eller negative bekreftelser som ble mottatt.

Dette er formen en undersøkelse trenger. "Hva sendte de oss", "hva sendte vi dem" og "hva sa de om det" er tre forskjellige spørsmål og hver av dem blir stilt.

12.2 Søking

Etter kanal, tidsspann, resultat, meldingstype og triggerhændelse, og etter feltverdi.

Feltsøk fungerer på den parsede meldingen, så søking etter en journalnummer finner det uansett hvor i meldingen feltet bor, i stedet for å matche sifrene hvor som helst i teksten. En tekstsøk etter 12345 i en melding som inneholder en mengde på 12345 finner en melding som ikke har noe å gjøre med pasienten du søker etter.

12.3 Gjenavspilling og gjenprosessering

Fordi originalen lagres, kan en melding kjøres gjennom den nåværende konfigurasjonen igjen.

Sporing tar en innspilt melding og viser hva kanalen ville gjøre med den nå, uten å sende noe. Dekket i feilsøking.

Gjenprosessering kjører den faktisk igjen, inkludert levering. Dette er hva fikser en batch med meldinger som feilet fordi en destinasjon var feilkonfigurert: korrigér konfigurasjonen, velg de berørte meldingene, gjenprosesser.

12.4 Uaktualitet

En sporingslogg av en gammel melding mot den nåværende konfigurasjonen svarer på en hypotetisk: hva *ville* skje nå. Det er vanligvis hva du vil, men ikke alltid — hvis du undersøker hva gikk galt forrige tirsdag, kan kanalen ha endret seg siden.

Perfuse detekterer dette og sier det. En sporingslogg av en melding som ankom før kanalen ble redigert sist, blir merket som sådan, så svaret ikke blir forvekslet med en rekonstruksjon av hva som faktisk skjedde.

12.5 Oppbevaring

Lagringen vokser. cleanup.periodDays kontrollerer hvor lenge meldinger lagres.

To ting å veie. Kliniske meldinger kan falle under oppbevaringskrav som er lengre enn noe du ville velge av operative årsaker, og lagringen er ikke systemet for registrering — mottakssystemet er. Perfuses kopi eksisterer for å diagnostisere og gjenprosessere, og begge disse behovene avtar skarpt etter noen uker.

Retensjon bestemmer også hvor mye historikk rytme-læren har å jobbe med. Se alerting: et retensjonsvindu kortere enn noen uker gjør det umulig å skille mellom en stille søndag og en stoppet strøm.

12.6 Lagringen inneholder kliniske data

Dette er den delen av Perfuse som inneholder pasientinformasjon, og den bør behandles som sådan: på kryptert lagring, sikkerhetskopiert som klinisk data og tilgangskontrollert. Se sikkerhet.

De genererte testmeldingene beskrevet i testing eksisterer delvis så denne dataene ikke trenger å forlate miljøet for å reprodusere et problem andre steder.

13 Feilsøking

Spørsmålet er nesten alltid det samme: denne meldingen kom inn, noe gikk galt ut, hvor ble det endret? Perfuse besvarer det ved å spille av en innspilt melding gjennom den nåværende konfigurasjonen og vise hver enkelt steg.

Ingenting sendes mens det spores. Kanalen fortsetter å kjøre urørt, og ingen ny distribusjon er nødvendig.

13.1 Sporing av en melding

Velg en hvilken som helst innspilt melding og spor den. Resultatet vises, i rekkefølge:

• Hva filteret leste. Hvilke felt det så på og hva verdier det fant. Et filter som avviser alt, er vanligvis å lese en sti som ikke eksisterer i denne strømmen, og dette navngir den.
• Hver transformasjon. Hva det endret, fra hva til hva.
• Hva hver destinasjon bestemte. Om den ville akseptere meldingen, og hvorfor ikke hvis den ikke ville.
• Utdata. Meldingen slik hver destinasjon ville sende den.

13.2 Steg for steg

Gjennomgangsvisningen kjører hver transformasjon for seg og tar et øyeblikksbilde av hele meldingen etterpå. En nummerert liste over steg, fargelagt etter hva som skjedde, og meldingen slik den var på hvert punkt.

Hele meldingen heller enn bare endringen, fordi problemet ofte ikke er der endringen er — et steg som korrekt modifiserte feltet det var rettet mot, på en melding hvor et tidligere steg allerede hadde plassert feil ting der, ser perfekt korrekt ut i isolasjon.

13.3 Fire resultater, og forskjellen som teller

no-effect og skipped rapporteres separat, og dette er poenget med hele funksjonen.

Utenfor er de identiske: meldingen er den samme etterpå uansett. De betyr motsatte ting. skipped betyr at betingelsen fungerte som skrevet og denne meldingen var ikke en den gjaldt for — vanligvis korrekt. no-effect betyr at steget kjørte og fant ingenting å gjøre, som vanligvis betyr at det er rettet mot et felt som ikke er der.

En motor som rapporterer begge som "ingenting skjedde" lar deg ikke kunne skille mellom en fungerende betingelse og en feil sti, og det er den vanligste transformasjonsfeilen der er.

13.4 Testing av en endring før den lagres

Byggeren kan kjøre en kandidatkonfigurasjon mot innspilt trafikk og rapportere hva som vil være forskjellig. Dette er den tryggeste måten å endre en live-kanal: gjør redigeringen, se hva den gjør med de siste få hundre ekte meldingene, og lagre deretter.

Det er også hvordan du finner ut at en endring som ser åpenbart korrekt påvirker meldinger du ikke hadde tenkt på — et steg betinget av en utløsende hendelse, på en strøm som viser seg å bære fire.

13.5 Hva sporingsfunksjonen ikke kan fortelle deg

Den kjører den nåværende konfigurasjonen. Hvis kanalen er redigert siden meldingen ankom, er sporingen en hypotetisk heller enn en rekonstruksjon, og Perfuse markerer den som sådan heller enn å la forskjellen passere stille.

Den øver ikke transporten heller. En sporingsfunksjon viser hva som ville bli sendt, ikke om destinasjonen ville akseptere det — en melding som er korrekt og en destinasjon som nektar forbindelser, produserer en ren sporingsfunksjon og en feilende levering. Disse er synlige i leveringsrekorden i stedet.

13.6 Skript

Et skript er ett uigjennomsiktig steg i sporingen. Perfuse kan vise hva som gikk inn og hva som kom ut, og kan ikke vise hva som skjedde imellom eller hvilke felt som ble lest.

Dette er den konkrete kostnaden ved å bruke et skript i stedet for deklarative steg, og det er verdt å vurdere når du velger. Se transformation.

14 Testing

Standard råd for testing av et grensesnitt er å bygge eksempelmeldinger som reflekterer din egen miljø — laboratoriets koder, case-mix, senders vaner — og å fjerne pasientdataene for hånd. Det er tregt, og å gjøre det ufullstendig er det normale resultatet.

Perfuse tilbyr tre ting i stedet: generert trafikk som matcher en strøms form uten innhold, en kanal foreslått fra en eksempel noen sendte deg, og en sammenligning mot motoren du erstatter.

14.1 Generert testtrafikk

Hvis en kanal har håndtert meldinger, kan Perfuse produsere flere meldinger som ligner dem.

Hva som er troverdig:

• Utløser hendelser i de proporsjoner som faktisk er observert, med minst en av hver slik at en sjelden hendelse fremdeles vises.
• Felt som er fylt ut med de riktige ratene — slik at tilfelle hvor et felt er *fraværende* blir testet, som er tilfelle som bryter ting.
• Repetisjoner hvor repetisjoner forekommer, sammensatt struktur hvor det forekommer.
• Koder tegnet fra kode-tabellene som faktisk er sett.

Hva som ikke er troverdig, og dette er uttalt heller enn antydet: klinisk konsistens. En generert pasient har et urelatert journalnummer, en navn-lignende streng og en diagnose uten noen relasjon til observasjonen. Disse meldingene øver en grensesnitt. De er ikke en klinisk testsett og kan ikke brukes til å validere klinisk logikk.

14.1.1 Hvorfor den ikke inneholder noen ekte data

Argumentet er strukturelt heller enn et krav om innsats. Generatorens eneste innputt er kanalens trafikk profil, og en profil holder fyllingsrater, former, lengder, repetisjons tellere og segmentfrekvenser. Den holder ingen verdier.

Den eneste unntakningen er kode-tabellfelt, og en kode identifiserer ingen.

Dette er en sterkere garanti enn å fjerne identifiserende opplysninger fra ekte meldinger, som er en prosess som kan gjøres ufullstendig og vanligvis er det. Her er det ingen vei hvor et navn kunne nå utdata, fordi navnet aldri var i innputt.

Hver generert melding blir parsert før den returneres — en uparsbar korpus ville sende noen på jakt etter en feil i deres grensesnitt som faktisk er en feil i generator — og hver enkelt er merket T i MSH-11, med en bevisst syntetisk senderapplikasjon og fasilitet.

14.2 Bygging av en kanal fra et eksempel

Lim inn meldingen en laboratorium, sykehus eller leverandør e-postet deg og Perfuse foreslår en kanal for den. Ingen trenger å kjøre først.

Den håndterer hva folk faktisk limmer inn: flere meldinger i en blokk, noen som helst linjeavslutning, MLLP-ramming som overlevde kopieringen, og dekknoten over meldingen. Å nekte et eksempel fordi det ankom med Windows-linjeavslutninger ville være et hinder heller enn en kontroll.

14.2.1 Tre lister

Forslaget kommer med hva eksemplet viser, hva som har blitt gjettet, og hva eksemplet ikke kan fortelle deg — tre separate lister, vektet like mye i grensesnittet.

De er separate fordi en leser som ikke kan se hvilken som er hvilken må verifisere alt eller stole på alt, og begge er verre enn å vite hvor å se.

Fra en enkelt melding er grensene navngitt spesifikt heller enn generelt: hvilke felt er valgfrie, hvilke segmenter gjentas, hvilke koder finnes utover de som er her, om senderen noen gang sender en annen utløserhendelse. En generell advarsel er en advarsel folk skumler.

Tillit er et ord — lav, moderat, rimelig — aldri en prosent. En prosent antyder en beregning, og dette er en vurdering av hvor mange eksempler det er.

Z-segmenter kalles ved navn, fordi et lokalt segment er det ingen spesifikasjon nevner og den vanligste årsaken til at en kanal bygget fra en standardmal ikke fungerer.

14.2.2 Advarsel om separator

Hvis eksemplets feltseparator ikke er den vanlige |, vises det først, og tillit senkes til lav.

Årsaken er en ekte stille feil. HL7 tar sin feltseparator fra meldingen selv, så et eksempel hvor pipene er erstattet med typografiske likheter — som er hva en tekstbehandler gjør — parser perfekt inn i felt som alle er feil. Ingen feil noen steder.

Å nekte et slikt eksempel ville være feil, fordi en sender kan legitimt bruke en annen separator. Så det merkes, og tegnet navngis, og det foreslås å be om en vanlig tekstvedlegg.

14.3 Sammenligning mot den gamle motoren

Før du flytter en live-strøm, er spørsmålet om Perfuse produserer samme utdata som det som har vært i drift i årevis. Ingen mengde designkvalitet kan besvare det. Se migration.

14.4 Verifisering mot den virkelige ting, i containere

Tre sjekker kjøres mot virkelige implementasjoner i stedet for mot Perfuse's egen ide om et protokoll. De lever utenfor make check fordi de trenger en container-kjøretid og en sjekk som trenger Docker er en sjekk folk stopper å kjøre.

scripts/interop-up.sh starter alle og skriver ut hva hver enkelt låser opp.

Hver enkelt hopper over i stedet for å feile når dens container er fraværende, så make check passerer på en maskin med ingen Docker.

Hvorfor dette er separat fra resten av suiten. Hver andre test av disse funksjonene hadde begge halvdelene skrevet her: et dokument denne kodebasen signerte, lest tilbake av koden som signerte det. Det er enighet med seg selv, og det er verdt mindre enn det ser ut til.

SAML-kanonisereren er caset som beviser poenget. Den bar tusen linjer med tester, fem av dem spesifikt om kanonisering, og alle passerte mens ingen virkelig identitetsleverandør noen gang kunne ha signert noen inn — den kanoniske formen som en signatur dekker ble beregnet med namespace-prefikser droppet, og den eneste måten å finne det ut var å håndtere et dokument Perfuse ikke hadde skrevet.

To av de åtte sjekkene fant feil rett og slett, og en tredje utløste en virkelig forbedring. Tre fant ingen feil. Denne forholdet er argumentet for å holde alle: en sjekk som passerer har fortalt deg noe du ikke kunne ha visst på forhånd, og det var ingen måte å vite på forhånd hvilke de ville være.

En mønster verdt å navngi, fordi den dukket opp i begge feil: aksept er ikke verifisering. HAPI aksepterte det feilaktige identifikasjonssystemet og lagret det; feilen dukket bare opp da ressursen ble lest tilbake. En mottaker som tolererer noe er ikke bevis for at det er riktig, bare at denne mottakeren var mild.

To fanget påstander er commitet, på internal/saml/testdata/keycloak-assertion.xml og entra-response.xml, med tester over begge — så den spesielle regressionen fanges uten en container.

Begge er nødvendige i stedet for at en er reserve. Keycloak prefikserer sin påstand og signatur, Entra gjør ikke, og disse er de to motsatte casene i kanonisering — som er nettopp der feilen var. En test påstår hver enkelt dokument fortsatt dekker sin egen casus, fordi en erstatning som skjedde å prefiksere ville stille halvparten av dekningen uten å feile noe. Den generelle læren generaliserer ikke så billig: for alt annet, er containeren sjekken.

14.5 Diagnose av en test som feiler en gang og aldri igjen

En test som feiler i en fullstendig kjøring og passerer alene seksten ganger er ikke en flakende test. Det er en test som deler noe med kjøringen, og måten å finne ut hva er å måle det delte på i stedet for testen.

To instrumenter eksisterer for dette, og begge er ment å kjøres sammen med en fullstendig suite:

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

Hver oppdager kjøringens porter fra setupets egen tilstandsfil og sampler hver 500 millisekund inntil serveren eksiterer. De logger hver enkelt sample i stedet for bare feilene, som er det som gjør dem nyttige: en blip viser opp i en kjøring hvor ingenting feiler, så en feil som viser seg en gang i tre kjøringer blir målbar på hver enkelt.

Sett PERFUSE_E2E_KEEP=1 for å beholde den midlertidige katalogen, som inneholder databasen slik den ble latt og serverloggen for hele kjøringen. Serverloggen er vanligvis svaret. I ett undersøkt tilfelle ble det registrert en kanal som stoppet og dens lytter ble koblet på nytt 421 millisekunder senere, og sonens ene avviste forbindelse falt innenfor dette vinduet.

Les sporet i stedet for error-context.md, som har vært tom på mer enn ett tilfelle hvor sporet inneholdt den virkelige meldingen.

Kopier artefaktene ut før du kjører noe på nytt. En vellykket kjøring sletter test-results, så sporet av feilen du undersøker forsvinner i samme øyeblikk du prøver å gjenskape den. Når den er borte, kan spørsmålet det ville ha svart på ikke lenger besvares.

Stans interop-beholderne først. Stans dem før en fullstendig nettleserkjøring, og start dem med ./scripts/interop-up.sh etterpå hvis du fortsatt trenger dem.

Åtte containere holder rundt 9,8 GB med minne, og på en maskin uten mye mer enn det er det for lite igjen til Chromes prosesser, node og Go-verktøykjedet sammen. Det det produserer er ikke en out-of-memory-feil, men en renderer som slutter å bli planlagt: ett registrert spor viser et 60,2 sekunders gap med ingen ramer i det hele tatt, under hvilket Playwright ventet på at en knapp skulle bli "synlig, aktivert og stabil" og ikke kunne få to påfølgende animasjonsrammer til sammenligning. Serveren var frisk gjennom hele kjøringen, den sloweste forespørselen i hele kjøringen var 154 millisekunder.

Den feilen ser ut som en defekt i hvilket som helst test som skjedde å kjøre. Det er verdt å vite formen på den: hver forespørsel rask, siden visuelt frosset, gjentakelsesløkken nådde aldri en andre iterasjon, og hele ting passerer i isolasjon.

Kun én kjøring om gangen. Suiten deler en server, en pålogget økt i web/e2e/.auth/admin.json, og en tilstandsfil som navngir serverprosessen. Ingen av dette er per-kjøring, så en andre kjøring som starter mens den første pågår overskriver tilstandsfilen, og hvilken som helst avslutning som fullføres først dreper den andre kjøringens server og sletter dens økt.

What that looks like is nothing like the cause. It produced a run of 279 failures whose first message was ENOENT: no such file or directory, open './e2e/.auth/admin.json', a run that stopped early reporting 217 passed, and two tests failing with bind: address already in use — none of which suggest two runs fighting. The suite now takes a lock and refuses to start, naming the process that holds it. A lock left by an interrupted run is taken over rather than blocking for ever, because a safety measure that wedges the suite is one somebody deletes along with the safety.

En relatert felle, nå fikset: to spesifikasjoner navnga deres lytterporter åpenbart, så en server som ble igjen etter en avbrutt kjøring gjorde dem feile på noe de ikke hadde noe å gjøre med. Portene spørres nå om av operativsystemet.

Svare ikke på noen av dette med gjentakelser. En test som passerer på andre forsøk fant en virkelig kappløp og skjulte det, og playwright.config.ts setter retries: 0 av denne grunn.

En advarsel: å prøve hver 100 millisekunder spawnet tyve prosesser per sekund, strakk en kjøring med en halv gang, og feilet to tester på tidsavbrudd som ikke hadde noe galt med dem. Et instrument som endrer hva det måler produserer funn om seg selv.

14.6 Hva som fortsatt trenger ekte infrastruktur

Flere deler av Perfuse er implementert og har aldri blitt testet mot den ekte varen. De er listet her i stedet for å bli oppdaget:

• SMB mot en ekte Windows-deling — protokollkoden er fullstendig og testet for stisikkerhet og argumentbehandling, men ingen test åpner en socket til en domene-tilkoblet server.
• En ekte serieport.
• Mirth-importøren mot XML fra en ekte Mirth-produsent. Testet mot Mirth 4.5.2 i en container, og funn var om dette repository: den eneste migreringsfikseringen her ble skrevet for hånd og Mirth vil ikke laste den — den lagrer kanalen som ugyldig og kasserer hver connector. Hva som ble avgjort, er at version-attributtene en ekte Mirth skriver på hvert element parser til samme kanal, så de er ikke en fare; hva som ikke er avgjort, er alt annet en ekte eksport inneholder.
• SAML mot en vert kommersiell identitetsleverandør. Keycloak er verifisert; en leverandør beviser at en implementering matcher en leverandør.
• En NCPDP-krav via en ekte apotekswitch.
• En SCRIPT-melding via Surescripts, der sertifisering er en kommersiell prosess snarere enn en teknisk.

Funksjonene i dette kapitlet og det neste eksisterer så du kan samle dine egne bevis i stedet for å ta noen andres ord.

14.7 Målt mot offentlige konformitetskorpus

En test-suite hvis fikseringer ble skrevet her, beviser enighet med seg selv. Dette er andre menneskers data.

14.7.1 FHIR R4, spesifikasjonens egne eksempler

Alle 2 912 eksempelfiler som er publisert med FHIR R4-spesifikasjonen — hver enkelt eksempel som standardforfatterne skrev.

Ingen enkelt ressurs ble valideret feil. Hver feil er en eksplisitt nektelse som navngir typen den ikke kan lese — 672 ValueSet, 80 ConceptMap og en Parameters. En validerer som stille passerer hva den ikke forstår er verre enn en som sier det.

Korpuset fant en defekt, som er grunnen til å kjøre det. Validering av en samling skrev ut "Validering av samling fra en fil støttes ikke ennå" og fortsatte. Det var feil i begge retninger: samlinger hvis oppføringer skjedde å være typer parseren kunne holde, ble allerede valideret, og en samling som var genuint ugyldig produserte samme linje, teller ingenting, og avsluttet null — inkludert under -strict, som eksisterer så dette kan porte en bygging. Førtito av spesifikasjonens egne samlinger ble hoppet over.

Samlinger valideres nå inngang for inngang, med tre resultater holdt adskilt: en inngang som er feil feiler og navngir feltet, en inngang av en type som denne bygningen ikke kan lese, teller som hoppet over og rapporteres, og en samling som bærer ingen ressurskropper er ingen. Samme korpus gikk fra 2 100 ressurser sjekket til 13 723.

14.7.2 HL7 v2, HAPI-testkorpuset

Meldingsfikser fra HAPI, den referanse Java HL7 v2-implementeringen — bevisst vanskelig materiale inkludert uuencoded payloader, escaped delimitere og gjentakende grupper.

59 meldinger, 59 parsede, ingenting avvist. Syv meldingstyper i et korpus som enhver enkelt system ville beskrive som en ting, som er poenget perfuse profile eksisterer for å gjøre.

14.7.3 Hva som ikke er kjørt

DICOM mot en offentlig konformitetssamling, og X12 mot en publisert korpus. Ingen av dem er gjort, og ingen av dem bør antydes fra de to ovenfor.

15 Migrering fra Mirth

To ting er nødvendige for å erstatte en arbeidende motor: kanalene må komme over, og noen må kunne vise at erstatningen produserer samme utgang. Perfuse gjør det første ved å importere Mirths egne eksporteringer, og det andre ved å sammenligne de to motorer på eget trafikk.

Alt i dette kapitlet gjelder like mye for Open Integration Engine og BridgeLink. Mirth Connect sluttet å være åpen kildekode ved 4.6 i mars 2025; OIE (vært av Eclipse Foundation) og BridgeLink (Innovar Healthcare) er forkene som fortsetter åpen kildekode-linjen, og begge skriver samme eksportformater. Importøren er testet mot alle tre nedenfor.

15.1 Importering av kanaler

Perfuse leser hver eksport disse motorer skriver:

Pek perfuse translate på noen av dem, eller slipp en på Administer → Migrer:

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

En kodemalbibliotek blir lib/<library>.js ved siden av kanalene, og hver kanal Mirth hadde biblioteket aktivert for, får scripts.include: [lib/<library>.js] — så en transformer som kalder en stedfunksjon som formatMRN() fortsatt finner den. En kanal biblioteket ikke var aktivert for, inkluderer det ikke, fordi skriptene ikke kunne se det i Mirth heller. Drag-and-drop-utklipp utelates: Mirth limte dem bare inn i et steg manuelt, så de er ikke kode som kjører på egen hånd. I nettleseren lagrer import av en kanal bibliotekene den inkluderer først.

En Kanal-forfatter navngir kanalen den leverer til, ved id. I en gruppe eller en reserve er målet i samme dokument, så det blir en channel-destinasjon som navngir den kanalen; fra en enkelt-kanal-eksport rapporteres det for å fylle inn. Server-wide globale skript har ingen Perfuse-ekvivalent og rapporteres i stedet for å droppes.

Rapporten sier, per kanal, om den ble oversatt ren, oversatt med advarsler eller ikke kunne leses.

Overskriften er en brøk med teller — "37 av 40 klare" — fordi "37 klare" forteller deg ingenting om hva du fortsatt må gjøre.

En kanal som ikke kunne leses er et annet problem enn en som ikke kunne oversettes. Førstnevnte betyr at XML selv ikke parserte og er vanligvis en trunkert eller delvis eksport; sistnevnte betyr at kanalens innhold har noe uten en Perfuse-ekvivalent. Importen skiller dem.

15.2 Hva som oversettes og hva som trenger en avgjørelse

Kilder, destinasjoner, filtre og vanlige transformer-steg oversettes direkte. Konnektorene som oversettes: TCP/MLLP (og rå TCP med ramming), HTTP, Fil, Database, JavaScript, DICOM, Web Service (SOAP), SMTP og Kanal Leser/Skriver. JMS og Dokument Skriver oversettes ikke, og rapporteres som blokkeringer.

En Mapper-steg som setter en variabel legger den i kartet med navnet på området sitt — channelMap som standard — nøyaktig som Mirth gjør, så senere steg som leser den med $('name') finner den.

JavaScript-transformatorer gjør det vanligvis ikke. Mirth-kanaler inneholder ofte betydelig kode i en transformer, og det er ingen automatisk konvertering fra vilkårlig JavaScript til deklarative steg. Importøren rapporterer disse heller enn å forsøke en oversettelse som kan være subtilt feil: en mistranslatert transformer er verre enn en som er flagget for en menneskelig, fordi den vil kjøre.

Hvor et skript virkelig må forbli et skript, kan Perfuse kjøre det – se scripts-nøkkelen i kanalreferansen – til en kostnad av stegnivåsporingen beskrevet i feilsøking.

15.3 Hva importøren er testet mot

Fem motorer, hver som skriver sine egne dokumenter: Mirth 4.5.2, OIE 4.5.2, 4.6.0 og 4.7.0, og BridgeLink 26.9.0. scripts/mirth-engine-corpus.sh kompilerer et lite program mot hver motors egne jar-filer og har sin egen serialisator skrive tre vanlige kanaler — en MLLP-matning med en mapper, et skript som kaller en kode-malbibliotek og en filter; en HTTP-matning inn i en database; en fil-polling ut over MLLP — pluss biblioteket og en kanalgruppe. Det laster dem inn i den kjørende motoren og laster ned motorens egen server-bakoppslag. Resultatene er commitet under internal/mirth/testdata/engines/, og test-suitten holder importøren til hver av dem på hver bygging: hver bakoppslag leses, oversettes, lastes, og ADT-kanalen kjøres med to meldinger for å sjekke at biblioteket fyller rekordnummeret og filteret dropper resultatet.

Perfuses egne eksport går den andre veien — Perfuse-kanaler importert inn i hver kjørende motor og sjekket at motoren ikke lagrer dem som ugyldige. Alle fem aksepterer hver transport Perfuse eksporterer. Open Integration Engine 4.7.0 la til to HTTP-innstillinger uten noen ekvivalent her: en HTTP-avsender bundet til en valgt lokal adresse rapporteres som en advarsel, og en HTTP-lytter forespørsels-hodegrense bare når den er over 1 MB som Perfuse aksepterer.

Den første kjøringen mot denne korpusen fant fire feil, alle fikset: oversetteren nektet HTTP- og filkilder som «bare MLLP er støttet» lenge etter at Perfuse hadde både; den leste en HTTP-avsenders adresse fra et felt ingen av motorene skrev; den oversatte Mirths sokkelbuffertstørrelse som en 64 KB-meldingsbegrensning; og en Mappers variabel ble en JavaScript-global som $('mrn') aldri så, så biblioteket fylte en tom streng.

Den enkelt-kanal-fikset som startet dette, ble også eksportert av Mirth 4.5.2, skrevet av Mirth selv, i stedet for å være skrevet her. Denne distinksjonen tjente sin plass: den eneste fikset i dette repositoryt, ble brukt til å være håndskrevet, og en ekte Mirth vil ikke laste det — API-et aksepterer POST-en og lagrer så kanalen som This channel is invalid. Verify all required extensions are loaded correctly, med hver destinasjons-connector diskardert.

Håndskrivning var aldri gått å fungere, og grunnen er verdt å vite hvis du produserer eksporter av din egen. Mirths serialiser ignorerer elementer den ikke kjenner, så et feil elementnavn produserer ingen feil i det hele tatt — connector-en er bare ikke der etterpå. Det er ingenting å lese og ingenting å korrigere mot.

scripts/mirth-author-channel.sh bygger en ved hjelp av Mirths egne modell-klasser og sin egen serialiser, så poster den til en kjørende server og feiler hvis serveren avviser den. Perfuses importør les resultatet: navn, kilde-transport og destinasjoner overlever alle.

15.4 Beviser at det matcher

Dette er den delen som bestemmer om en migrering skjer, og det trenger bevis snarere enn tillit.

Perfuse sammenligner sin egen utdata mot den gamle motorens, melding for melding, på din trafikk. Hva den trenger er par: meldingen som den ankom, og meldingen den gamle motoren produserte fra den. Begge er i Mirths egen meldings-lager og kan eksporteres fra dens meldings-blað.

15.4.1 Fire tall, ikke en bestått rate

De er fire tall fordi de betyr fire forskjellige ting og å kollapse dem skjuler de som trenger en beslutning.

Identisk betyr byte for byte, ikke ekvivalent. En svakere test ville la forskjeller i segment-rekkefølge eller trailing-separatere gjennom, og det er nettopp det en krævende nedstrøms-system avviser.

Kosmetiske forskjeller telles separat snarere enn foldet inn i den gode kolonnen. De bærer virkelig ingen informasjon, så å behandle dem som feil ville begrave ekte funn under tusenvis av ingenting — men de er ikke identiske heller, og en mottaker som gjør sin egen strenge parsing kan være uenig.

«Ville ikke kjøre» er separat fra «forskjell» fordi det vanligvis er et konfigurasjons-gap importøren ikke kunne fylle, ikke en mapping-beslutning. Hvis alt er i den kolonnen, sier dommen det og forteller deg å se på konfigurasjonen før du leser noe annet.

15.4.2 Forskjeller er gruppert etter felt

En kjøring over femti tusen meldinger som rapporterer fire tusen forskjeller har fortalt deg ingenting du kan handle på. Samme kjøring som rapporterer at PID-8 forskjeller i hver melding fordi den gamle motoren skrev Male hvor Perfuse skriver M har fortalt deg nettopp en ting å bestemme.

Så hver funn er et felt, med en telling, og det sier om forskjellen er systematisk — samme verdi-par hver gang — eller om feltets innhold forskjeller.

Den distinksjonen er det mest nyttige i rapporten. Et distinkt verdi-par over fire tusen meldinger er en enkelt mapping-beslutning. Fire tusen distinkte par er innholdet som forskjeller, som er et annet og mye verre problem, og de to må ikke lese likt.

Funnet er ordnet etter hvor mange meldinger de påvirker, så den største enkeltårsaken er først.

15.4.3 Dommen runder ikke

Den gir eksakte tellinger: 49 993 av 50 000, ikke «over 99 %». De syv er hele poenget med å kjøre det.

Det er skrevet for å kunne sitere i en endringsforespørsel, fordi det er der nummeret ender.

15.5 En foreslått sekvens

1. Importer kanaler og løs eventuelle problemer som rapporteres som uleselige.
2. Gjennomgå advarsler for hver kanal. De fleste vil være skript.
3. Eksporter noen tusen meldingspar fra Mirth for den travleste kanalen og kjør sammenligningen.
4. Gjennomgå funnene. Systematiske funn er ett valg hver.
5. Kjør på nytt til de eneste forskjellene er de du har bestemt er korrekte.
6. Kjør Perfuse i skyggen sammen med Mirth på live-trafikk, leverer ingen steder, og sammenlign på nytt over en periode som inkluderer en helg og en månedsslutt.
7. Bytt ut en kanal, ikke alle sammen.

15.6 Hva som bare kjører på en leverandørs programvare

Migrasjons-skjermen besvarer et annet spørsmål, og det er verdt å spørre før du har noen mening om Perfuse: hvor mye av din integrasjonslogikk kan bare kjøre på programvaren du har.

Hver kanal får en Portabilitet-dom, fra samme skanning som produserer migrasjonsnotater. Den kjører mot en kanal-eksport, så den trenger ingen installert og endrer ingenting.

15.6.1 Forskjellen er hele poenget

De fleste Java i Mirth-skript er ikke låst til. SimpleDateFormat, HashMap, Apache Commons — alt sammen arbeider rundt en JavaScript-motor fra 2009, alt sammen vanlig, alt sammen med direkte ekvivalenter. En kanal med tre hundre av disse referansene er fullstendig portabel, og et verktøy som rapporterte "300 Java-referanser, du er fanget" ville lyve for deg.

Låsing er spesifikt kallene som trenger leverandørens egen server: com.mirth.connect.* og leverandør-jar. Fem av disse og du er fanget. Fem hundre av den andre typen og du er fri.

Så dommen starter med det tall som teller og sier i samme setning at det større tallet ikke er det. Der det finnes leverandør-kall, listes de opp ved navn — en telling er en påstand, og en liste er noe din egen ingeniør kan gå og sjekke.

En tredje kategori holdes separat: funksjonalitet som eksisterer, men ikke fra et skript. Å starte en kanal fra JavaScript har ingen ekvivalent her, og det finnes en API-endepunkt som gjør nøyaktig det samme. Å kalle det låsing ville overdrive funnene.

15.6.2 Java-kall som kjører uendret

De vanligste Java-klassene kjører som de er skrevet. Perfuse har ingen Java-kjøretid, så disse er JavaScript-klasser med samme navn og metoder, nok for måten kanalmanuscripter bruker dem; importPackage(java.util) og importClass(...) bringer dem inn i omfang med kort navn, som i Rhino (JavaScripts egen Date, Map, Set, Math, String og Boolean er aldri erstattet: Java-utgavene er fortsatt der med fullt navn). Migreringsrapporten teller hver av disse kallene som allerede støttet.

De oppfører seg som Java der skriptene avhenger av det: Integer.parseInt("x") kaster NumberFormatException, String.replaceAll og split tar regulære uttrykk mens replace er bokstavelig, kartlegger nøkkelstrenger med verdi, TreeMap og TreeSet itererer i rekkefølge, og SimpleDateFormat.parse returnerer en dato getTime() fungerer på. En metode et skript kaller som den tilsvarende mangler feiler på den linjen, og navngir den; enhver annen Java-klasse feiler med navn, som før. BigDecimal er en dobbel her, så den beholder ikke Javas nøyaktige desimalaritmetikk: sjekk skript som bruker den for penger.

15.6.3 Eksterne skript rapporteres som ukjent

Et steg som kjører et eksternt skriptfil refererer til en sti på den gamle serveren, og filen er ikke i eksporten. Ingen kan si noe om hva den inneholder, så den teller som ukjent i stedet for å anta enten vei — i begge retninger.

15.6.4 Perfuses egen låsing, uttalt i samme åndedrag

Dette avsnittet ville være uærlig uten det.

Perfuse er Apache 2.0, som er uopprettelig for kode som allerede er utgitt. Du kan fork det som eksisterer i dag og ingen kan trekke det tilbake. Kanaler er YAML-filer og skriptene er vanlig JavaScript, så det finnes ingen proprietær overflate å ringe — Mirths smak av Java-avhengighet er strukturelt utilgjengelig her, som er det eneste stedet en begrensning virkelig er en funksjon.

Hva det ikke lover: at en fremtidig versjon forblir åpen, at en vertsetjeneste eksisterer til en pris du liker, eller at å migrere vekk fra Perfuse kostar ingenting. Å flytte noen integrasjonslag innebærer å gjennomføre hver kanal på nytt mot ekte trafikk. Det du velger er om artefaktene du bygger er leselige og portable, og om utgangen avhenger av en lisens noen andre kontrollerer.

15.6.5 Konfigurasjon av steg 6

Avsnittet Skygge starter en sammenligning. Velg kanalen som kjører, velg kandidaten til å sammenligne mot fra listen, og start.

Tre ting om det er verdt å vite før du baserer deg på tallene.

Kandidaten velges fra en liste, ikke skrevet. En skyggenavn gir en kanalfil, og et navn som ikke kan løses, gjør den *aktive* kanalen ugyldig — Perfuse avviser en kanal som helhet når noe den refererer til er feil. Så et skrivefeil produserer ikke en advarsel, det gjør den kjørende kanalen forsvinner.

Andelen er et prosent. Reduser det bare på en travel feed, og vite hva det koster: steking reducere arbeid og tillit i samme proporsjon, og meldingen som ville ha vist forskjellen er den uvanlige en.

Felter som skal ignoreres er vanligvis nødvendig. En kanal som stempler en tidsstempel eller en sekvensnummer forskjeller på hver enkelt melding, som rapporterer en forskjellshastighet på 100% og forteller deg ingenting. MSH-7 og MSH-10 er det vanlige paret.

En sammenligning skrives til kanalfilen så snart du starter den, og begynner å observere når kanalen neste laster — skjermen sier det heller enn å hevde at den allerede kjører. Stopp en sammenligning lar kandidatkanalen være på plass, fordi kandidaten er det som er ment å gå live.

Trinn 6 er det som ikke kan forkortes. Forskjellene som betyr noe er vanligvis i trafikk som bare viser seg av og til — en sjelden utløsende hendelse, en månedsslutt part, en avsender som oppfører seg annerledes ved midnatt — og et utvalg tatt over en ettermiddag vil ikke inneholde dem.

15.7 Gå tilbake den andre veien

En kanal kan eksporteres som en Mirth-kanalfil, fra nettleseren: Kanaler, deretter Til Mirth på kanalen du ønsker.

Dette eksisterer fordi innvendingen mot å erstatte en fungerende motor er sjelden om erstatningen er noen god. Det er hva som skjer hvis avgjørelsen viser seg å være feil, og en eksport som går tilbake den samme veien er det billigste svaret på det.

Les hva dialogen forteller deg før du tar filen. Mirths format har ingen sted å plassere en Perfuse-filt, en transformasjonskjede, en kontrakt eller en skyggesammenligning, så en eksportert kanal gjør mindre enn den den kom fra. Transportene og deres adresser konverterer; logikken gjør det ikke. Hver tap liste opp navn før filen tilbys, og samme liste går inn i kanalens beskrivelse så at den som importerer den ser det også.

En kanal Mirth ikke kan uttrykke avvises heller enn approksimert. En S3-destinasjon har ingen Mirth-ekvivalent, og en kanal som importerte renlig mens den leverte et annet sted enn bucket ville være verre enn ingen fil i det hele tatt. Avvisningen navngir destinasjonen som er feil.

Konnektordefinisjonene er ikke skrevet fra en lesing av Mirths format. scripts/mirth-dump-connector-templates.sh har Mirths egen serialisator produsere standarder for hver konnektorklasse, og Perfuse erstatter verdier i disse dokumentene — avviser enhver innstilling som malen ikke allerede inneholder. Dette betyr på grunn av hvordan Mirth svarer på en kanal det ikke kan parsere: det avviser ikke importen. Det lagrer en kanal hvis beskrivelse har blitt erstattet med "Denne kanalen er ugyldig. Verifiser alle nødvendige utvidelser er lastet korrekt" og hvis destinasjoner har blitt stille diskardert. En eksportør som er kontrollert mot sin egen utgang heller enn mot en server passer hver test mens den produserer dokumenter som kastes, som er nettopp hva som skjedde her før eksportene ble prøvd mot en kjørende Mirth.

Hva krysser i dag: MLLP og TCP i begge retninger, HTTP i begge retninger, fillesing og skriving, databaselesing og skriving, DICOM i begge retninger, og SMTP, SOAP og JavaScript-destinasjoner. Hver par er verifisert ved å importere til en ekte Mirth 4.5.2 og sjekke serveren ikke stille erstattet kanalen.

16 CMS-0057 for betalere

CMS Interoperabilitet og Prior Autorisasjon sluttrapport (CMS-0057-F) krever at berørte betalere — Medicare Advantage-organisasjoner, statlige Medicaid og CHIP-programmer og deres managed care-planer, og QHP-utgivere på de føderale børsene — kjører fire FHIR-APIer fra 1. januar 2027, og å publisere prior autorisasjonsmetrikker på deres offentlige nettsted hvert år fra 2026.

Perfuse tilbyr de fire API-ene på sin FHIR-endepunkt og konverteringene som fyller dem: avgjorte krav som CARIN Blue Button, prior autorisasjoner som Da Vinci PDex, og de årlige metrikkene i layoutet til CMS-eget mal. CMS-0057-visningen, under Utveksling, sier hvilke av de fire denne instansen kan svare og hva hver ennå trenger, og gjør alle tre konverteringene i nettleseren.

Legemidler er utenfor omfang hele tiden, slik de er i regelens prior autorisasjonsbestemmelser: ingen apotekkrav, ingen formular, og en metrikkrad som navngir et legemiddel avvises heller enn telle.

16.1 De fire API-ene

Pasienttilgangs-API trenger ingen egen operasjon: det er FHIR-endepunktets vanlige lese- og søkefunksjoner, beskyttet av SMART, med CARIN- og PDex-ressurser i lagret. Søking etter ExplanationOfBenefit støtter parameterne CARIN-navn — patient, identifier, type, service-date, billable-period-start, provider, insurer, coverage — og Coverage støtter subscriber-id, identifier og payor.

16.1.1 To utgaver av guidene: 2.1.0 og 2.2.x

CMS-0057-F anbefaler CRD, DTR og PAS 2.0.1 og 2.1.0. 2.0.1-utgavene hviler på US Core 3.1.1, som utløp 1. januar 2026, så 2.1.0 er utgaven en EHR bygget for regelen sannsynligvis snakker; de nyeste er CRD 2.2.1, DTR 2.2.0 og PAS 2.2.1. Perfuse svarer i begge. Den finner ut hvilken en kaller snakker, mest spesifik først:

1. fra forespørselen: CRDs CDS Hooks-utvidelse davinci-crd.requestedVersion ("2.1"), eller versjonen på en Da Vinci-profil en DTR eller PAS-krav (profile-pas-request-bundle|2.1.0);

2. fra kallerens registrering: davinci_version: "2.1" på en SMART-klient (-smart-clients) eller en CDS-klient (-cds-clients); 3. fra serveren: serve -davinci-version 2.1; standard er 2.2.

clients:
  - issuer: https://ehr.example.org
    jwks_url: https://ehr.example.org/.well-known/jwks.json
    davinci_version: "2.1"

Hver beslutning avgjøres og lagres i 2.2.x-format og omskrives for en 2.1.0-kaller når den sendes, så reglene, gjennomgangskøen, X12 278-lenken og målingene er de samme for begge. Omskrivingen dekker hva utgavene staver forskjellig: CRD 2.1.0 har ingen indeterminate (Perfuse sier betinget, med årsak) og ingen kategori på en dekningsdetalj; DTR 2.1.0 navngir pakken PackageBundle og lar QuestionnaireResponse være til appen; PAS 2.1.0's $inquire svarer med én Bundle, og den mangler reviewer- og overføringsutvidelser. Den fullstendige listen, og sjekken mot hver 2.1.0-veileder sin egen eksempler, er i conformance/davinci21. En PAS-varsling følger -davinci-version, ettersom en abonnement ikke sier hvilken utgave eieren leser.

16.2 Dekningskrav og dokumentasjon: CRD og DTR

Prior Authorization API er i praksis tre Da Vinci-veiledere sammen. CRD forteller klinikerne, mens ordren fortsatt er en utkast, om den er dekket, om den trenger forhåndsgodkjenning og hva dokumentasjon som ønskes. DTR overfører EHR-spørsmålet som samler inn den ønskede dokumentasjonen. PAS sender forespørselen og returnerer avgjørelsen. Perfuse betjener alle tre som betaler.

-crd-rules rules.yaml betjener CRD via CDS Hooks på /cds-services: alle seks av CRD's hooks, order-sign, order-select, order-dispatch, appointment-book, encounter-start og encounter-discharge, hver med en prefetch for pasientens aktive dekning. De to møtehookene henter også møtet og besvarer spørsmål om møtet selv, sammenlignet med dens type og servicetype, slik appointment-book besvarer spørsmål om en avtale. Reglene er forsikrers politikken, lagret i en fil fordi de endres uten programvareutgivelser:

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

Hver ordre får en systemActions-oppdatering som bærer CRD-dekning-informasjonsutvidelsen - som EHR lagrer på ordren og senere sender med forhåndsgodkjenningen - og et kort som klinikerne kan lese. En ordre hvis kode ikke har noen regel, blir besvart conditional, aldri antatt dekket; en forespørsel uten noen dekning overhodet får et kort som sier det. examples/crd/ har en regelfil og et tilhørende spørsmål.

En regel kan også bære resten av hva CRD lar en betaler si:

• billing_codes: kodene som skal faktureres under.
• details: begrensninger og kostnader, som allowed-period eller in-network-copay.
• contact: hvem som skal ringes.
• expiry_days: hvor lenge svaret gjelder.
• depends_on: koder for andre ordrer som svaret avhenger av, så EHR spør igjen hvis de endres.
• doc_purpose: hva dokumentasjonen er for (withclaim, withorder, retain-doc). withpa avvises, fordi CRD 2.2.1s egen invariant crd-ci-q4 avviser det.

Hva EHR ikke forhåndshentet, leser Perfuse fra EHRs fhirServer med tokenet det sendte. Hvis det feiler, er svaret indeterminate med CRD-technical årsak, aldri et gjett. En dekning som har utløpt eller ikke er aktiv, blir besvart not-covered, no-active-coverage.

members: fhir i regelfilen løser dekningen mot betalerens egne poster i denne serverens FHIR-lager (start den med -fhir), samme poster $member-match leser:

• en pasient som ikke er medlem, blir besvart no-member-found;
• et medlem hvis dekning ikke matcher, blir besvart coverage-not-found;
• en forhåndsgodkjenning allerede godkjent der for tjenesten (en ClaimResponse med en preAuthRef) gjør svaret satisfied,

med det nummeret.

Oppdagelse erklærer davinci-crd.version og en coverage-info konfigurasjonsvalg. Når en klient slår av valget, er svaret tomt. EHR JWT-er sjekkes som CDS Hooks definerer dem, med iss, aud, exp, iat og jti og ingen sub, og en gjentakelse jti avvises.

Anrop autentiserer med JWT-en EHR signerer for hver anrop, fra en utgiver navngitt i -cds-clients med sin JWKS-URL - som er hvordan CDS Hooks beskriver det - eller med en Perfuse API-nøkkel. Oppdagelse er åpen, som CDS Hooks krever.

DTR: last inn spørsmålene i FHIR-endepunktet, og POST /fhir/Questionnaire/$questionnaire-package returnerer dem som DTR-pakkebunter, med CQL-bibliotekene de navngir. Forespørselen kan navngi spørsmålet, eller sende ordren og la dekning-informasjonen si hvilket.

Prøving: Payers → Claims & auth → Coverage requirements (CRD) sender en ordre til denne serverens regler, eller til en betalers CDS-tjeneste-URL, og viser kortene og dekning-informasjonen.

16.3 Krav som CARIN Blue Button

perfuse cms0057 carinbb parer hver krav i en 837 med sin betaling i en 835, etter pasientkonto-nummeret 835 er påkrevd å echo tilbake, og skriver en FHIR-transaksjon for hver: ExplanationOfBenefit med pasienten, dekning, organisasjoner og praktikere den refererer til.

perfuse cms0057 carinbb -system https://fhir.your-plan.org/identifier -network innetwork \
    claims.837 remittance.835

Profilen følger kravet: profesjonelle krav (837P) blir C4BB-ExplanationOfBenefit-Professional-NonClinician, og institusjonelle (837I) innlagt eller utlagt etter type av regning. Hver post er en PUT med en ID tatt fra kilde-identifikatorene, så lasting av samme krav to ganger oppdaterer det i stedet for å lage en annen kopi.

Tre ting er ikke i noen av X12-filene, og hver håndteres ved å si det i stedet for å gjetting:

• Identifikasjonssystemet. CARIN krever at medlem-identifikatoren navngir betalernes navnerom. -system er påkrevd; det er ingen standard, fordi en standard ville gi hver betaler som bruker Perfuse samme navnerom.
• Nettverksstatus. Ingen av transaksjonene sier om faktureringsleverandøren er i nettverket, og det bestemmer hva medlemmet betaler. Uten -network er fordelingsbetaling-status other og konverteringen noterer hvorfor.
• En krav som 835 ikke nevner. En CARIN ExplanationOfBenefit er en avgjort krav. Uten 835 er det ingen betaler-krav-nummer, ingen betaling og ingen medlem-ansvar, så kravet rapporteres som hoppet over og ikke konvertert.

Diagnoser skrives med desimalpunkt (J02.9, ikke J029), fordi det er hvordan kode-systemet publiserer dem og en terminologiserver spurt om den andre stavingen sier at den ikke eksisterer. En avhengigs medlem-identifikator er abonnentens, som er hva 837 bærer, og notatene sier det. En NPI hvis kontrollsiffer er feil, rapporteres før US Core avviser det.

16.4 Forhåndsgodkjenninger som PDex

perfuse cms0057 priorauth konverterer en Da Vinci PAS ClaimResponse — eller PAS-svarspakken som inneholder en — til en PDex prior autorisasjons ExplanationOfBenefit, som er det alle tre data-API-ene betjener.

perfuse cms0057 priorauth pas-response.json pas-claim.json

PAS-kravet er valgfritt og nesten alltid nødvendig. En ExplanationOfBenefit må angi hvilket dekning beslutningen ble fattet under, og bare forespørselen inneholder dette; uten det stopper konverteringen og sier det. Gjennomgangshandlingen — godkjent, avvist, utsatt, med autorisasjonsnummer og årsak — flyttes fra PAS-utvidelsen til PDex, og X12-tjenestetype beholdes under URI-en PDex binder den til.

16.5 Tilbyderadgangs- og betaler-til-betaler-API-er

Med -fhir-payer-apis svarer FHIR-endepunktet på tre flere operasjoner:

• POST /fhir/Patient/$member-match — HRex-medlemssammenligning. Dekningsidentifikatorene snevres inn til noen få kandidater, og etternavn og fødselsdato må deretter være enige; et fornavn sammenlignes ved initial, og kjønn bare når begge sider angir det. Mer enn en overlevende kandidat er ikke en sammenligning, og svaret er 422 i stedet for et gjett, fordi et gjett avslører en fremmeds krav. En aktiv samtykke som tillater avsløring er nødvendig, siden betaler-til-betaler-API-en er valgfri for medlemmet; -fhir-member-match-without-consent slår det av for testing.
• GET eller POST /fhir/Group/{id}/$davinci-data-export — Da Vincis bulk-eksport av en gruppes nåværende medlemmer. exportType velger målgruppen: hl7.fhir.us.davinci-pdex#provider-download eller #provider-delta for tilbyderadgang, #payertopayer for betaler-til-betaler.
• GET /fhir/Group/{id}/$export — standard Bulk Data-gruppe-eksport, behandlet som tilbyderadgang.

Eksportene følger regelens eksklusjoner på vei ut. Krav mister betalingen og hver kostnadsdeling og refusjonsbeløp, og beholder tjenestene, kodene, datoene og tilbyderne; CARIN-profilen fjernes fra meta.profile fordi ressursen ikke lenger møter den. Btaler-til-betaler utelater også avviste forhåndsgodkjenninger. Medlemmer som innehar en aktiv PDex-tilbyderadgang-opt-out-samtykke utelates fra en tilbyder-eksport, og loggen registrerer hvor mange. patient-parameteren kan bare snevres inn til medlemmer av gruppen; å navngi noen andre blir avvist.

Tilgang til en gruppes eksport avgjøres av endepunktets autentisering. SMART-omfang sier hva slags ressurs en nøkkel kan lese, ikke hvilken gruppe, så hver leverandør trenger en nøkkel som kan nå bare sin egen tilskrivelsesliste. En API-nøkkel kan begrenses til grupper når den lages — perfuse token create -label riverside-provider-access -fhir-groups riverside-attributed, eller Begrens til FHIR-grupper-feltet under Brukere → Maskinlegitimasjoner — og på FHIR-endepunktet kan den deretter lese disse gruppene, kjøre $davinci-data-export eller $export på dem og hente hva eksporten produserte, og ingenting annet. En annen leverandørs gruppe svarer ikke funnet i stedet for forbudt, så en nøkkel lærer ikke hvilke andre tilskrivelseslister som finnes; hver annen forespørsel, medlemssammenligning og vanlig søk inkludert, avvises. Begrensningen gjelder for API-nøkler; en nøkkel fra en SMART-utgiver bærer ingen gruppebegrensning. Når SMART er konfigurert også, avvises API-nøkler med mindre Innstillinger → FHIR → Aksepter Perfuse API-nøkler ved siden av SMART-nøkler er på (se Sikkerhet, *Hvem kan ringe FHIR-endepunktet*); en leverandørs gruppebegrenset nøkkel trenger det.

16.6 En tilbyderkatalog: Plan-Net

CMS-0057 ber også forsikringsgivere om en leverandørkatalog, og FHIR-endepunktet tilbyr en til Da Vinci Plan-Net 1.1.0 uten mulighet til å slå den av: last inn praktiserende, praktiserende roller, organisasjoner, organisasjonsmedlemskap, steder, helsetjenester, forsikringsplaner og endepunkter, og medlemmers apper kan søke i dem. Hver Plan-Net søkeparameter er indeksert - en rolles nettverk og tjeneste, en plans dekningområde, et medlemskaps deltakende organisasjon, en organisasjons partof - sammen med inkluder og reverskjeder (_has) veiledningens spørringer bruker, og CapabilityStatement listen Plan-Net profiler.

Infernos Plan-Net suite består av 199 tester. De 10 den feiler er fremoverkjeder hvor kit tar sin søkeverdi fra den første organisasjonen den har sett, i stedet for en som de søkte ressursene henviser til; det rapporteres til kit (dets problem 34), og serveren svarer korrekt på disse spørringene når den får en verdi dataene inneholder.

16.7 Forhåndsgodkjenning-mål

perfuse cms0057 metrics leser en CSV med beslutninger eksportert fra utnyttelses­ledelsessystemet og produserer den offentlige siden CMS krever, i layoutet til dets *Forhåndsgodkjenning-mål-rapportering — Oversikt og mal*.

perfuse cms0057 metrics -year 2025 -org "Springfield Health Plan" -services services.csv \
    decisions.csv > prior-authorization-metrics-2025.html

Kolonner finnes ved header: priority, received, decided og decision er påkrevd, og request_id, line_of_business, extended, appealed, appeal_decision, service_code og service_description leses når de er til stede. En forespørsel tilhører året den ble avgjort i; en som fortsatt er pendende listes som ekskludert, aldri tellt. Hver rad som ikke kan leses, rapporteres med sin linje­nummer.

Arithmetikken følger malen: for standard og akselererte forespørsler separat, andelen godkjent og avvist, godkjent og avvist innen beslutningstid, godkjent etter at gjennomgangstiden ble forlenget, og godkjent etter anke — av anker, ikke av forespørsler — med gjennomsnitt og median tid fra mottak til beslutning. En median under en dag skrives i timer i stedet for å avrundes til "0 dager", som malen ber om eksplisitt. Delvis godkjente forespørsler telles som godkjent, siden malen ikke har en kategori for dem, og siden sier hvor mange det var. Mål rapporteres per forretningslinje, som er nivået CMS krever.

Siden er selvinnholdende — ingen skript, ingen ekstern stylesheet eller font — fordi den publiseres på en offentlig nettside av den som vedlikeholder den, og alt den laster fra andre steder er noe annet som kan bryte eller spore en besøkende. -format csv og -format json gir samme tall for andre formål. Uten -services har siden en merknad om at listen over elementer og tjenester som krever forhåndsgodkjenning mangler, fordi CMS krever det på samme side.

16.8 Legemidler: formulariet, Real-Time Prescription Benefit og elektronisk forhåndsgodkjenning

CMS-0062-P (forslag 14. april 2026) vil bringe medisiner inn i forhåndsgodkjenning: berørte forsikringsgivere vil støtte NCPDP SCRIPT elektronisk forhåndsgodkjenning, NCPDP Formulary & Benefit-standarden og NCPDP Real-Time Prescription Benefit fra 1. oktober 2027, avgjøre medisinerforespørsler innen 24 timer (hastet) og 72 timer (standard), gi en spesifikk grunn for hver avvisning, og rapportere medisinermetrikk fra 2028. Medicare Part D krever allerede SCRIPT ePA. En fil, formulariet, besvarer alt dette:

perfuse serve -fhir -pas -crd-rules payer-rules.yaml -formulary formulary.yaml

examples/formulary/formulary.yaml er et eksempel hvis medisiner er virkelige RxNorm-begreper med NDCs RxNorm lister for dem (sjekket mot RxNav). En fil navngir forsikringsgiveren, dens planer (hver med formulariet den bruker, dens gruppe-ID og dens kostnadsdeling etter apotekfordel og nivå) og dens formularier. Hver medisin er en RxNorm SCD eller SBD med sin RxNorm-gruppe (SCDG eller SBDG Drug Formulary API krever), dens NDCs, et nivå og dens begrensninger: prior_authorization, step_therapy, quantity_limit (en mengde i en rullerende antall dager, og en daglig maksimum), not_covered, alternatives (RxNorm-koder, mest foretrukket først), notes, og questionnaire, den kanoniske URL-en til FHIR-spørreskjemaet en forhåndsgodkjenning ber om. cost_30_day er planens kostnad for en 30-dagers forsyning, som en coinsurance er en prosentdel av; uten det er en coinsurance sitert som en prosent, aldri som en oppfunnet mengde. Hele filen sjekkes når den lastes, hver problem liste samtidig. En medlem finnes ved filens members liste, ved gruppe, eller gjennom FHIR-butikken: en Coverage hvis subscriberId er medlem-ID og hvis class av type plan er planens ID. Forsikringsgivere › Medisiner viser formulariet, priser en medisin og kjører en forhåndsgodkjenning fra ende til ende.

16.8.1 Da Vinci US Drug Formulary API

Publisert på /formulary/fhir som Da Vinci US Drug Formulary 2.1.0: hver plan en PayerInsurancePlan, hver formular en Formulary (begge InsurancePlan), hver medisin en FormularyDrug (MedicationKnowledge) og hver post en FormularyItem (Basic). Veiledningens spørringer betjenes (Basic?code=formulary-item&formulary=...&drug-tier=...&pharmacy-benefit-type=...&period=..., subject:MedicationKnowledge.code, InsurancePlan?formulary-coverage=..., coverage-type, MedicationKnowledge?code=...&doseform=...) med _include=Basic:subject, Basic:formulary og InsurancePlan:formulary-coverage. Det er offentlig, uten legitimasjon, som CMS krever av en forsikringsgivers formular: det betjenes fra en butikk på eget initiativ, i minne, som holder formulariet og ingenting annet, så å være åpen kan ikke nå en pasients journal. Det er skrivebeskyttet. En ekskludert medisin publiseres ikke, ettersom API-en lister hva et formular dekker; RTPB og ePA svarer likevel på den som ikke dekket. Verifisert med HL7 FHIR-validerer mot veiledningens 2.1.0-pakke med terminologi sjekket: hver ressurs generert fra eksemplet har ingen feil.

16.8.2 Real-Time Prescription Benefit

POST /ncpdp/rtpb tar en RTPBRequest (NCPDP RTPB v13) med en API-nøkkel for operatørrollen og svarer en RTPBResponse fra formulariet: dekningstatus, formularstatus, medlemmets estimerte andel og planens, og dekningbegrensninger, med opptil fem dekkede alternativer priset på samme måte. Begrensningkoder og statusen hver kartlegger følger NCPDPs offentlige RTPB-Implementeringsanbefalinger: 75 forhåndsgodkjenning påkrevd, 608 stegterapi, 76 planbegrensninger overskredet, 7X dagers forsyning over planbegrensningen (en medisin ikke tilgjengelig via post, for eksempel), 70 ikke dekket, alle *dekket med begrensninger* (CR) unntatt 70 (NC). En medlem med en godkjent forhåndsgodkjenning på fil får CC og AB8, slik Surescripts-veiledningen ber om, så prescriberen ikke sendes for å spørre igjen. En forespørsel som ikke kan prises er NotProcessed med en NCPDP-avvisningskode: 52 for en medlem ikke funnet, E7 og 19 for en manglende mengde eller dagers forsyning. Apotekfordelen leses fra forespørselen: en fylling over 34 dager er en tre-måneders forsyning, og apotektype M er postordre.

16.8.3 Elektronisk forhåndsgodkjenning (NCPDP SCRIPT)

POST /ncpdp/script tar PAInitiationRequest, PARequest, PAAppealRequest og PACancelRequest med en API-nøkkel for operatørrollen, og svarer hver med sin respons:

Spørsmålssettet er legemidlets FHIR-spørreskjema fra FHIR-butikken, det samme som DTR fyller ut: en boolesk blir et ja/nei-valg, et valg et valg, et tall et numerisk felt, en dato et datofelt, og alt annet fritt tekstfelt; grupper er flattet i rekkefølge, og enableWhen blir ikke med, siden SCRIPT grenser etter valg og ikke etter betingelse. Et legemiddel uten spørreskjema blir bedt om å svare på tre fritt-tekst-spørsmål: diagnosen, hva som ble prøvd, og hvorfor dette legemidlet. En PARequest blir en Da Vinci PAS-forespørsel: en Claim for legemidlet (RxNorm og NDC), MedicationRequest det ber om, pasienten, skriver ut og dekning, og svarene som en QuestionnaireResponse, med eventuelle vedlegg som DocumentReference. Det blir deretter avgjort som alle tidligere godkjenninger på denne serveren: regelfilen, et avgjørelsestjeneste (-pas-decider-url), eller reviewer-køen, hvor det merkes som Legemiddel og holdes til legemidletidsrammene. En avgjørelsestjeneste ser en legemiddelforespørsel nøyaktig som den ser en fra en EHRs PAS-klient. Vi anbefaler Vaglio, BioDreams åpne kildekode (PolyForm Shield) avgjørelsemotor, som har legemiddepolitikker med stegterapi; en payers egen motor kobles inn gjennom samme -pas-decider-url, og ingen er nødvendig for regelfilen og reviewerne for å avgjøre.

En avgjørelse som er gjort etter at forespørselen ble besvart (en reviewers, en anke) sendes til skriver ut som en uoppfordret PAResponse eller PAAppealResponse, rute til kanalen navngitt av -epa-reply-channel, som leverer det til nettverket. Uten en, eller når leveringen feiler, sier saken at skriver ut ikke har blitt fortalt og skjermen sender det igjen.

Payers › Legemidler › Godkjenning sender meldingene en skriver ut-system ville til denne serverens egen endpoint (start, besvar spørsmålene, se avgjørelsen), lister hver sak med hva skriver ut ble fortalt, og viser legemiddeltallene CMS-0062-P foreslår: forespørsler godkjent, avvist og ventende, anket og godkjent eller avvist på anke, gjennomsnitt og median timer fra forespørsel til avgjørelse, og hvor mange ble avgjort for sent. Medisinske legemidler som blir forespurt gjennom PAS (en HCPCS J-kode med en MedicationRequest, eller en vare kodet i RxNorm eller NDC) teller som legemidler i PAS-tallene også.

Hva dette hviler på, uttalt på en enkel måte. NCPDPs skjemaer og implementeringsveiledninger er lisensiert. Elementnavnene og rekkefølgen her følger de offentlige Surescripts ePA- og RTPB-veiledninger og deres eksempler, og NCPDPs offentlige RTPB-anbefalinger. To elementer det offentlige materialet aldri viser er skrevet til SCRIPT-mønsteret som brukes andre steder og bør kontrolleres mot en lisensiert kopi før sertifisering: Closed/ReasonCode og Denied/DenialReason. Ingen melding har blitt kontrollert mot NCPDPs XSD eller et nettverks sertifisering. NCPDP Formulary & Benefit-filen blir ikke produsert: dens fullstendige layout er i NCPDPs lisensiert veiledning, og en delvis fil vil bli avvist av nettverket som laster den.

16.9 Hva som ble kontrollert, og mot hva

CARIN- og PDex-utdataene ble valideret med den offisielle HL7 FHIR-validereren, lastet med de publiserte pakkenavnene (hl7.fhir.us.carin-bb#2.2.0, hl7.fhir.us.davinci-pdex#2.2.0): profesjonell, innlegg og utlegg krav og to PAS-beslutninger, uten feil. PDex-inndata var PAS-veiledningens egne eksempler fremfor former skrevet her for å være enig med konverteren. Validereren fant fem feil på første kjøring — blant dem at CARIN krever profilversjonen i meta.profile og krav-type kode-systemversjon på institusjonelle krav — og hver er fikset og dekket av en test.

Bygging av dette fant en feil eldre enn det: FHIR-butikken droppet hver enkelt element dens interne modell ikke erklærte, så en ExplanationOfBenefit mistet sine elementer, diagnoser, avgjørelse og betaling på veien inn. Butikken holder nå hva enn en ressurs bærer, og en test laster en CARIN-krav gjennom serveren og leser det tilbake helt.

CRDs utdata - den oppdaterte ordren, og CDS Hooks-svaret mot CRDs egen logiske modell - og DTRs pakkeutdata validerer i den offisielle HL7-validereren mot CRD 2.2.1 og DTR 2.2.0 uten feil.

DTR her er payers siden av 2.2.0. $questionnaire-package tar spørreskjemaene navngitt, de CRD navngav på en ordre, eller dekningssertifikatets id CRD returnerte (context, mens samme prosess betjener CRD), og returnerer hver som en pakke-bundle med en QuestionnaireResponse å fylle ut, Bibliotekene dens CQL trenger og deres avhengigheter. Verdisettene svarene bruker reiser i pakken når de lastes (PUT /fhir/ValueSet/{id}), og $expand lister deres koder. $log-questionnaire-errors skriver hva en DTR-app rapporterer til serverloggen.

Adaptive spørreskjemaer: skriv hele spørreskjemaet en gang, med SDCs questionnaireAdaptive-utvidelse og enableWhen på spørsmålene som bare gjelder noen ganger. Pakken gir appen en tom skall, og hver $next-question-kall legger til neste spørsmål som gjelder for svarene hittil, til det ikke er noe igjen å spørre om og svaret er merket som fullført. Rekkefølgen og grenseringen er payers egne regler; spørsmål som ikke gjelder vises aldri.

Logge inn som en klient: DTR- og PAS-klienter når payer med SMART Backend Services - en signert JWT byttet mot en token på payers autorisasjonsserver. Peker Perfuse mot den serveren med -smart-issuer (og -smart-jwks hvis dens adresse ikke kan løses fra Perfuse), og passer -smart-backend-services så oppdagelsesdokumentet sier det. Inferno DTR-suiten passerer denne måten med Keycloak som autorisasjonsserver.

Perfuse kan være den autorisasjonsserveren selv: serve -fhir -smart-clients clients.yaml utsteder Backend Services-tokens på /auth/token til klientene listet, hver med de offentlige nøklene den signerer sine påstander med og systemomfangene den kan bli tildelt, og FHIR-endepunktet aksepterer dem. Ingen separat identitetsserver er nødvendig for en payers maskin-til-maskin-klienter.

Med -smart-users users.yaml også, medlemmer og kliniske ansatte logger inn der for å autorisere apper, som Patient Access API trenger: appen sender personen til /auth/authorize, de logger inn, en klinisk ansatt velger pasienten, og begge ser hva appen ber om og kan fjerne noen av det. En medlem blir bare noen gang gitt sin egen post, uansett hva appen ber om. Hver person i filen navngir FHIR-resursen de er, Patient/… eller Practitioner/…, og en passordhash fra perfuse smart hash; passordet selv blir aldri skrevet ned.

Personer kan logge inn hos organisasjonens egen identitetsleverandør i stedet: -smart-oidc oidc.yaml angir navnet (utsteder, klient-ID og hvor hemmeligheten er), og innloggingsiden tilbyr "Logg inn med" den ved siden av passordet. Hver person er koblet til leverandørens emne, oidc_subject i brukerfilen, så filen bestemmer fortsatt hvem som kan godkjenne apper og hvilken FHIR-ressurs de er; en konto koblet til ingen blir avvist. Koder, oppfriskningstoken og tilbaketrekninger lagres i databasen, så en omstart logger ingen ut.

Brukere → SMART-apper i konsollen lister opp registrerte apper og personer, og legger til, redigerer og fjerner dem. Hver lagring kontrolleres som filene er ved oppstart, skrevet til dem og brukt med en gang. En konfidensiell app lagret uten hemmelighet får en, vist en gang; et passord settes der og vises aldri igjen. Fjerning av en app eller en person stopper tilgangstokene som allerede er utstedt til den eller gitt av dem med en gang, ikke når de utløper, og deres oppfriskningstoken med dem.

Omfang kan være detaljert, som SMART App Launch 2 og US Core definerer dem: patient/Observation.rs?category=laboratory leser bare Observasjoner som søket ville finne. En godkjenning som er filtrert for en type anvender filteret til hver søk og hver lesing av den typen; en ufiltret godkjenning for typen, eller for *, løfter det. Et filter som ikke kan leses gir ingen tilgang i stedet for all tilgang.

16.10 Avgjørelse av på forhånd autorisasjonsforespørsler: PAS

serve -fhir -pas -crd-rules rules.yaml svarer Da Vinci PAS 2.2.1 på POST /fhir/Claim/$submit og POST /fhir/Claim/$inquire. Beslutningene kommer fra samme regelfil som CRD's svar, så rekkefølgen en kliniker blir bedt om å godkjenne, avgjøres av regelen som sa det:

  - 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

Hver post får en X12-gjennomgangshandling: A1 sertifisert, A3 ikke sertifisert, A4 utsatt, A6 endret, C avlyst (sertifiseringstype 3). En linje som ikke navngir en tjeneste, blir ikke avgjort, men besvart med en feil (X12 901 AG, korrekt og send igjen). Svaret gjentar hva en 278-svar gjentar — postsporingnummer, ønskede tjenestedatoer, møtedatoer, overføringsidentifikatorer med avsender og mottaker byttet om — og gir hver linje forsikringsgiverens egen administrasjonsreferansenummer. En tjeneste som ingen regel navngir, blir utsatt, aldri godkjent: en avgjørelse som ingen har skrevet ned, er en avgjørelse for en person.

Utsatte forespørsler venter på en gjennomganger, som svarer med 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 kan også være modify: sertifisert, men ikke som bedt om, med quantity (valueDecimal, enhetene sertifisert) og/eller alternative (valueCoding, tjenesten godkjent i stedet). Responsen sier da A6 Modified, med den sertifiserte detaljen eller alternativet som en lagt til post, og en autorisasjonsnummer. item (valueInteger, gjentakelse) begrenser avgjørelsen til noen linjer. Avgjørelsen blir en ny versjon av responsen, merket som gjennomgått av en person, og med -fhir-subscriptions leveres den på PAS-tema (PASSubscriptionTopic, filtrert av org-identifier, organisasjonens identifikator som ba om det) som det fullstendige PAS-svar-bundle, i samme transaksjon som registrerer det. $inquire returnerer den nåværende responsen til hver forespørsel leverandøren gjorde om den medlemmen; en annen leverandørs forespørsel finner ingenting. $decide trenger en skriveområde; $inquire er en leseområde.

Forespørsler og hver versjon av deres svar lagres i pas_requests og pas_responses i serverens database.

16.10.1 Gjennomgangerkøen

I webkonsollen, Forsikringsgivere → CMS-0057 → Gjennomgangskø lister opp utsatte forespørsler som snartest utløper først: en rasjonert forespørsel (Krav.prioritet stat) utløper 72 timer etter ankomst, en standard 7 dager. Valg av en viser medlemmen, leverandøren, hver tjeneste med enhetene som er ønsket og hvor den står, hva svaret ønsket, og hver dokument mottatt for den, med ren tekst-dokumenter vist inline. En redaktør registrerer avgjørelsen der: godkjenne, avvise eller endre (sertifiserte enheter, eller en annen tjeneste godkjent i stedet), med en grunn og redaktørens NPI. En endring må sertifisere færre enheter enn det som ble ønsket; like mange eller flere er en godkjenning, og avvises som en endring. En godkjent tjeneste i stedet starter i kode-systemet til den som ble ønsket. Det er samme avgjørelse som $decide gjør, så leverandørens abonnement leverer den. Lesing av en forespørsel og avgjørelse av den er begge skrevet til revisjonsloggen.

Overvåk → Teamdashbord → Forhåndsgodkjenning viser, for de siste 30 dagene, hvor mange standard- og rasjonerte forespørsler ble avgjort innen CMS-0057s tidsrammer, avgjort for sent, fortsatt venter innen tidsrammene og forsinket nå, med median tid til avgjørelse, og hvordan tjenestene som ble ønsket ble besvart: godkjent, endret, avvist eller fortsatt utsatt. Disse to flisene leses fra forespørslene selv, så de er ikke i dashbordets Grafana-eksport, som sier det i sin beskrivelse.

16.10.2 Motta dokumenter som en pendende forespørsel ber om

En ventende respons ber om dokumenter med en oppgave og en CommunicationRequest per dokument. Et spørreskjema blir bedt om som PAS beskriver det: en CommunicationRequest med den enkelte LOINC-koden 102089-0, under sporingsnummeret for linjen det gjelder for (itemTraceNumber, som ClaimResponse gjentar; en linje sendt uten ett blir tildelt ett). Det sporingsnummeret er DTR-konteksten: $questionnaire-package med bare context satt til det returnerer spørreskjemaet. Leverandøren sender det som ble bedt om med Da Vinci CDex $submit-attachment (POST /fhir/$submit-attachment): TrackingId er forespørselens eget sporingsnummer (ClaimResponses første identifikator, som også er Task-identifikatoren), eller en CommunicationRequests identifikator, AttachTo er preauthorization, og MemberId må være forespørselens medlem. Hver vedleggs DocumentReference eller QuestionnaireResponse beholdes med forespørselen og vises til dens gjennomgående; et dokument som ankommer avgjør ingenting.

16.10.3 Avgjøre i et X12-utnyttelsesstyringssystem

De fleste betalere bestemmer forhåndsautorisasjoner i et UM-system som snakker X12 278. Med -pas-278-url er Perfuse FHIR-fronten av dette systemet: hver $submit sendes som en 278-forespørsel (005010X217), hver enkelt pasienthendelse. Hver bærer hva PAS navngir for det: gjennomgangstypen (extension-serviceItemRequestType, UM01: helse-tjenester, innleggelse eller spesialistbehandling), sertifikat-typen (extension-certificationType, UM02), tjenestetypen, stedet for tjenesten (UM04), tjenestenivået (extension-levelOfServiceCode, UM06: valgfri,急 eller nødvendig; en stat-prioritet står i for urgent), datoen, en innleggelses-gjennomgangs innleggelses- og utskrivningsdatoer, diagnosene, omsorgsteamets leverandør som skal utføre tjenesten, og prosedyren og mengden, som en profesjonell (SV1) eller, på en institusjonell krav, et sykehus (SV2) tjenestelinje. 278-svarets handling-kode og autorisasjonsnummer blir hendelsens gjennomgangshandling: sertifisert, delvis eller endret, avvist, utsatt, avbrutt eller ikke vurdert (utsatt for en gjennomgang, med avvisningsårsaker). Lokale regler konsulteres ikke.

perfuse serve -fhir -pas -pas-278-url https://um.example/x12/278 -pas-278-receiver ACMEUM \
  -pas-278-token-env UM_TOKEN

Et UM-system som først setter på vent og avgjør senere, posterer sin senere 278-svar til POST /fhir/Claim/$decide-278; hvert hendelse er koblet til sin forespørsel ved sporingsnummeret Perfuse sendte, og avgjøres som $decide ville avgjøre det. Hvis UM-systemet ikke kan nås, eller svarer med noe som ikke er et 278-svar, settes hver post på vent for en gjennomganger og leverandøren blir bare informert om det; årsaken er i serverloggen.

Spørsmål UM-systemet svarer på

En lege's $inquire må finne en autorisasjon uansett hvordan den ble bedt om: via faks, gjennom betalerens portal, via telefon, eller i en 278 en annen søker sendte. Perfuse holder bare forespørsler som kom gjennom det; UM-systemet holder dem alle. Så med et UM-system som svarer i sanntid (hver transport bortsett fra sftp), hver $inquire sendes også der som en 278-spørsmål (005010X215: BHT02 28, medlem, lege, autorisasjonsnummer fra Kravets insurance.preAuthRef når det har ett, og hendelsesdatoer fra billablePeriod eller tjenestens datoer, ellers et år på hver side av i dag). Hver autorisasjon svaret holder som Perfuse ikke (matchet av spor-numre det sendte og autorisasjons-numre det allerede ga) kommer tilbake som en mer Krav-spørsmål-pakke: UM-systemets avgjørelse for hver tjenestelinje, autorisasjonsnummer og periode, og en notis som sier hvor det ble funnet. Ingen Krav lages opp for en autorisasjon ingen sendte i FHIR: dens ClaimResponse.request bærer en data-fraværs-årsak, som PAS-profilen tillater. Et spørsmål leser bare; ingenting i Perfuse egne poster endres. Hvis UM-systemet er nede eller svarer med en TA1 eller 999, får lege det Perfuse holder, og lenkens status sier hvorfor. Formen følger 278-spørsmål-veiledningene UnitedHealthcare, Cigna og Blue Cross Blue Shield of Massachusetts publiserer; den har ikke blitt prøvd mot et virkelig UM-system.

Hvordan 278-ene når UM-systemet

UM-systemets tilkoblingsveileder sier hvordan det tar 278-er, og -pas-278-transport (Innstillinger, Payers, Utnyttelsesstyring lenke) følger det:

Et klient-sertifikat er -pas-278-cert og -pas-278-key; -pas-278-ca stoler på en payers egen sertifikat-utsteder. OAuth er -pas-278-oauth-token-url, -pas-278-oauth-client-id og hemmeligheten, hentet med klient-credens-grant og holdt til en minut før den utløper. Passord, token og hemmeligheter er aldri flagg: hver er navngitt av en miljøvariabel (-pas-278-password-env, -pas-278-token-env, -pas-278-oauth-secret-env, -pas-278-sftp-password-env), eller skrevet inn i innstillingsskjermbildet, hvor den holdes i innstillingfilen (lesbar av serverkontoen bare) og aldri vist igjen.

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

Over SFTP ventes hver forespørsel ut til svaret kommer: 278-svaret avgjør elementene, og Perfuse legger en 999 som godtar det i utgående mappe. En fil den ikke kan lese, blir i innkommende mappe for en person og tilbys igjen ved neste lesing.

Når UM-systemet ikke kan lese en forespørsel

Et UM-system som ikke kan lese en 278 svarer med en TA1 (konvolutten) eller en 999 (transaksjonen) i stedet for en avgjørelse. Perfuse leser hva og hva det sier, venteer hver element ("utnyttelsesstyring kunne ikke lese forespørselen"), og registrerer det. Betaler, CMS-0057, Gjennomgående kø viser lenken: hva som ble sendt de siste syv dagene, hver interchange etter sitt kontrollnummer, og hva som skjedde med det (besvart; bekreftet, svar kommer; avvist, med 999-segment, element og kode; ikke nådd). Hver interchange har sitt eget kontrollnummer, ett mer enn det forrige, som er hva en TA1 eller 999 navngir når den svarer.

16.10.4 Avgjøre basert på kliniske bevis, med en avgjørelsetjeneste

En regelfil avgjør etter tjenestekode: en kode trenger ingen autorisasjon, er ikke dekket eller går til en gjennomganger. Om denne pasienten møter kriteriene for det, er et annet spørsmål, besvart fra betingelsene, spørsmålsbesvarelser og dokumenter leverandøren sendte med forespørselen. Med -pas-decider-url, settes hver post reglene lar gå til en gjennomganger, først til en avgjørelsestjeneste, som f.eks. Vaglio, som leser den samme PAS-forespørsel-bunten gjennom Perfuses publiserte pas-pakke. En offentlig Vaglio, på oppfunnete forespørsler bare, kjører ved siden av Perfuses testinstans på https://vaglio.perfuse.health:8443 (logge inn som demo, passord try-vaglio-demo; den kan se på alt og endre ingenting): hver avgjørelse der har sin bevis, et rent språk-brev og en kvittering alle kan sjekke.

perfuse serve -fhir -pas -crd-rules payer-rules.yaml -pas-decider-url https://vaglio.example/api/pas/decide \
  -pas-decider-token-env VAGLIO_TOKEN

The URL must be https, or plain http to this machine (localhost, 127.0.0.1), because it carries a patient's record and the token. Vaglio itself answers on https only; when it uses a certificate from its own authority, pass that authority with -pas-decider-ca DATA/tls/ca.crt (or any payer's internal authority the service's certificate comes from). The service is sent the request Bundle as the provider sent it, POST <url>?item=<sequence> (application/fhir+json), and answers {"decision": "approve" | "deny" | "pend", "why": "...", "requested": ["..."]}, or 404 when it decides nothing for that item, which leaves the rules' answer standing. why is the response's process note and is required for a denial, which is otherwise pended; requested is said to the provider as the information a pended request needs. A pend may also carry "questionnaire": "<canonical>" and "attachments": ["<LOINC>", ...], which are asked for in the response's CDex Task and CommunicationRequests beside whatever DTR questionnaire or attachments the rule asks for (the rule's questionnaire wins, since a Task asks for one; a code that is not LOINC's shape is dropped and logged). A rule that approves or denies is the payer's coverage policy and is not sent to the service. A failure, a timeout or an answer that is not one of the three decisions pends the item for a reviewer, with the reason in the server log: nothing here turns a failure into an approval. It cannot be combined with -pas-278-url, where the UM system answers every item.

Råd før innsending. Med -crd-advisor-url ved siden av -crd-rules, ber også CRD en avgjørelsestjeneste hva en priorisert godkjenningforespørsel for hver ordre som trenger det, ville bli sagt som journalen står, og viser svaret som en ekstra kort: "Før du sender: en forespørsel for dette ville trenge: ...", eller "ville bli godkjent", med hva som fortsatt trengs, spørsmålet som ber om det, og hva som ville godkjenne det. Vaglio svarer på /api/pas/advise, med samme token og myndighet som ovenfor:

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 sends POST <url> with {"service": {"system": "...", "code": "..."}, "resources": [ ... ]}, the resources being the hook's prefetch (the patient first, the coverage left out), and reads {"decides": true, "answer": "approve" | "pend" | "deny", "summary": "...", "missing": [...], "questionnaire": "...", "toApprove": [[...]], "policyTitle": "..."}. It is advice and changes nothing: the coverage-information, the other cards and the PAS decision are what the rules say. It waits at most three seconds, and no answer, a failure, or "decides": false leaves the response exactly as it is without it. Perfuse never needs a decision service.

Forespørselen bærer X-PAS-Request-Id, id-en svaret er kjent med. En tjeneste med sine egne gjennomgåere som setter en post på vent, kan sende sin avgjørelse senere som en hvilken som helst gjennomgåers: Claim/$decide med den id-en som claimResponse, postens sekvens, og avgjørelsen og årsaken. Leverandørens abonnement leverer det som det ville en avgjørelse lagt i gjennomgåer-køen.

En abonnement med id-only-innhold forteller leverandøren hvilket svar som har endret seg uten å si hva det er: fokuset for varselet er Bundle/<id>. GET /fhir/Bundle/<id> returnerer den siste PAS-svaretpakken, GET /fhir/Bundle/<id>/_history/<n> versjonen som varsende varselet, og GET /fhir/ClaimResponse/<id> ClaimResponse alene. En token som er bundet til en pasient tildelt blir informert om at de ikke eksisterer, slik som for noen rekord utenfor dens pasient.

Verifisert med den offisielle Inferno PAS Server v2.2.1-suitten (se verifisering). Ikke sendt, selv om PAS merker dem som må-støtte: ClaimResponse.adjudication med en gjennomgangshandling, ClaimResponse.extension:authorizedProvider og ClaimResponse.item.extension:communicatedDiagnosis, fordi utvidelsene de trenger ikke er tillatt der av deres egen kontekst i PAS 2.2.1 og validereren avviser et svar som bærer dem; og request.extension:DataAbsentReason, fordi Perfuse alltid vet forespørselen. 278-ene som sendes til et utnyttelsesstyringssystem (ovenfor) er sjekket mot PAS 2.2.1-eget forespørsels eksempler, CMS-publikerte esMD 278-eksempler og en 278-sjekker skrevet fra offentlige companion-guider, og hver transport mot en stand-in UM-system skrevet fra CAQHs Connectivity Rules (se verifisering); ikke ennå mot et virkelig UM-system eller clearinghouse, og ikke CORE-sertifisert. Ikke implementert: vedlegg sendt tilbake med CDex.

En regelfil sjekkes mot CRDs egne invarianter når den lastes: et spørsmål trenger dokumentasjon, en tjeneste som ikke er dekket kan ikke trenge autorisasjon, satisfied hører til ett tilfelle og ikke en regel, og alt betinget må gi en årsak.

Ikke verifisert: eksportene og medlemssammenligning mot en annen betalers implementering, målingene mot en betalers publiserte tall, og CRD mot en virkelig EHRs CDS Hooks-klient.

16.11 Sending av forespørsler om forhåndsgodkjenning til en betaler (for leverandører)

Alt ovenfor svarer forespørsler, som en betaler. En leverandørs side er motsatt: en EHR eller en DTR-app bygger en Da Vinci PAS-forespørselbunke, og noe må sende den til betaleren, holde svaret og sende det videre. En pas-destinasjon gjør dette.

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

Hvert melding må være en hel PAS-forespørsel Bundle på en rå kanal. Perfuse posterer den uendret til {payer}/Claim/$submit: betaleren avgjør Claim sammen med pasienten, dekning og støtteressursene i Bundle, og en Claim gjenoppbygget fra en sammenfatting ville tape dem. Av denne maskinen må betalerens adresse være https.

En beslutning er en levert forespørsel, uansett hva den sier. En godkjenning, en avvisning og en pend er alle registrert og ingen blir forsøkt på nytt, fordi å forsøke på nytt en avvisning sender samme forespørsel to ganger. Det som feiler leveringen, og blir forsøkt på nytt, er en betaler som ikke har avgjort: en feilstatus, en OperationOutcome (dens tekst er feilen) eller en ClaimResponse hvis utfall er error. Beslutningen leses punkt for punkt fra PAS-gjennomgangshandlingene (X12 306: A1 godkjent, A2 delvis, A3 avvist, A4 utsatt, A6 modifisert); et svar uten kode blir listet som "ingen beslutningskode" i stedet for å bli tatt som en godkjenning. En avvisning uten noen grunn blir avvist fordi den ikke møter CMS-0057.

Svar fra betaleren er bestemmelsens svar, så Inspect the reply kan vurdere det, og results_to overfører det til en annen kanal. Hver forespørsel er listet på CMS-0057, Forespørsler sendt til betalere: når den ble sendt, pasienten, tjenesten, avgjørelsen og betalerens referanse (preAuthRef), som en senere forespørsel navngir. Listen oppbevares i prior-auth.json ved siden av databasen (høyst 10 000 forespørsler; de eldste avgjorte går først, en ventende går aldri), og hver leier ser bare sin egen.

Verifisert mot HL7 Da Vinci PAS-betalerreferanseimplementeringen (docker-bilde hlseven/davinci-prior-auth): en forespørsel sendt gjennom en kjørende kanal blir utsatt av den med dens referanse, og svaret vises på skjermen (se verifisering). Ikke prøvd mot en produksjonsbetaler ennå. Ikke bygget: oppfølging av en utsatt forespørsel med $inquire, eller mottak av betalerens senere svar via abonnement; en kanal kan gjøre begge deler i dag med en http- eller fhir-bestemmelse.

16.12 CMS-sammenlignede nettverk

CMS Interoperabilitetsrammeverket (CMS Health Technology Ecosystem) ber helse-data-nettverk om å selv-erklære seg til 26 kriterier og bli listet som CMS Aligned Networks; EHRer, leverandører, betalere og apper kobler seg til dem. Kriterium 13 til 16 har vært i kraft siden 4. juli 2026: FHIR-APIer på US Core med en full CapabilityStatement og Bulk Data, dokumenter som menneske-leselige FHIR-vedlegg, avtale- og møtevarslinger via FHIR-abonnement, og en journal-lokator.

Administrer › CMS-sammenlignende nettverk listar hver kriterium med hva Perfuse tilbyr for det og hvor denne serveren står, lest fra hva som er slått på her:

Hva de fire i kraft trenger fra denne serveren:

Skjermen er et arbeidsark for attestering, ikke en sertifisering: CMS gjennomgår nettverk de mistenker ikke møter kriteriene, og ramverkets egen tekst er myndigheten. Ikke bygget i dag: åpne kvalitetsgapforespørsler (kriterium 8), en forsikrers spørring for en kravs møtedata (9), rapportering av spørringsmetrikker til National Provider Directory (19), sjekking av leverandører mot denne katalogen (6), lesing av mobile sjåførerlisenser eller digitale forsikringskort (3, 23), og gjennomføring av en generell samtykkepolitikk på hver lesing (5). IAL2-identitetsverifisering er identitetstjenestens; Perfuse aksepterer tokenene til den du velger.

17 Sikkerhet

Perfuse håndterer klinisk data. Dette kapitlet er hva det gjør med det og hva det lar være til deg.

17.1 Transport-sikkerhet

TLS på web-grensesnittet er konfigurert med -tls-cert og -tls-key. Uten dem er grensesnittet vanlig HTTP, som er akseptabelt på en loopback-adresse for en første titt og ingen andre steder — det inneholder legitimasjon og meldingsinnhold, begge lesbar på ledningen.

TLS på kanal-transporter er per kilde og per mål, under en tls-blokk. Tilgjengelige innstillinger er i kilde og mål referanser.

insecure_skip_verify aksepterer ethvert sertifikat. Den eksisterer fordi hospitalsystemer rutinemessig presenterer sertifikater som ikke vil verifiseres, og å nekte å koble til ville bety å nekte å integrere. Den er navngitt for å være tydelig, og å bruke den betyr at forbindelsen er kryptert, men ikke autentisert — du har beskyttelse mot passiv avlytting og ingen mot en innført server.

17.2 Autentisering og roller

Brukere holdes i databasen. Hver har en av fem roller, og hver rolle inkluderer alt i rollene over den:

En sjette rolle, Plattform, tilhører den som kjører en delt server: den oppretter leietakere og setter deres grenser, og har ingen kanaler av sin egen.

Overvåkning er for en hjelpepult, eller for en operasjonsskjem på en vegg: alt som trengs for å se at en kanal har stoppet, og ingenting som navngir en pasient. Viser kan lese meldingsinnhold, som er klinisk data; det er en lav-privilegeringsrolle for *konfigurasjon*, ikke for personvern. Operatør skiller fiksering av en feilende levering om natten fra å endre hva en kanal gjør: personen som sender på nytt trenger ikke å kunne omskrive kanalen.

17.2.1 Gjentatte feil passord

Feil passord og mislykkede passkort-innlogginger telles etter adresse som tilkoblingen kommer fra, og etter noen på rad må denne adressen vente før den kan prøve igjen (svaret er 429, med Retry-After). Kontoer låses ikke ved navn, fordi det ville tillate noen å låse ut en administrator med vilje.

Adressen er tilkoblingens egen, aldri en adresse som en forespørsel hevder i X-Forwarded-For, som avsenderen skriver. Bak en omvendt proxy på samme maskin bruker Perfuse siste X-Forwarded-For-post, den proxyen la til, så hver klient teller likevel hver for seg. En proxy på en annen maskin når Perfuse fra én adresse, og alle dens klienter deler én telling: ratelimiter innlogginger ved den proxyen også.

17.2.2 Kanalgropper

En person (eller en API-nøkkel) kan begrenses til noen kanalgrupper: de ser da og handler kun på kanaler hvis group er en av deres. Dette er ordningen for en sykehusgruppe på en server, hvor hver enkelt anleggs analytikere tar hånd om sine egne feeds og et sentralt team, uten begrensning, tar hånd om alle. Rhapsody kalder det en låst boks.

Begrensningen gjelder overalt på samme tid, fordi den pålegges forespørselen i stedet for å huskes av hver skjerm: kanalisten, dashbordet og flytskjemaet, meldinger og deres søk, tellinger og diagrammer, køen, varslinger, metrikker, sertifikater, kontrakter og kodebruk. En kanal utenfor personens grupper eksisterer ikke for dem; å spørre etter den ved navn svarer *ikke funnet*, så navnet er heller ikke bekreftet. En kanal uten gruppe sees bare av personer uten begrensning.

Lagring av en kanal holder den inne i personens grupper: de kan ikke opprette en kanal i en annen gruppe, eller flytte en ut av sin egen. Hva hver fasilitet deler - kodetabeller, skriptbiblioteker, forhåndsgodkjenningsbeslutninger - kan de lese, men ikke endre. Serveromfattende tall (forhåndsgodkjenning, tokenbruk, tunneler) vises bare til personer uten begrensning, og det samme gjelder metrikker og varslinger om hele serveren i stedet for en kanal.

En administrator begrenset til grupper er en fasilitets egen administrator. De håndterer personer og nøkler i sine grupper, starter og stopper sine kanaler og rydder sine køer. En kollega de legger til får deres grupper med mindre de navngir noen av dem, de kan ikke gi en gruppe de ikke har, og de ser eller endrer aldri noen uten begrensning. Alt annet en administrator kan gjøre, endrer hele serveren - innstillinger, pålogging, omstart, varslingsregler, merking, flåte, SMART-serveren - og nektes dem.

Grupper settes i Brukere (og for nøkler i Nøkler), som en komma-separert liste. Hver endring registreres i aktivitetlogg og treffer i kraft ved personens neste forespørsel.

En annen rolle i hver gruppe

En person kan ha en annen rolle i hver av sine grupper: lab=editor, adt i Brukere redigerer labens kanaler og har rollen valgt ved siden av den - for eksempel viser - i admissjonens kanaler. De ser begge gruppens kanaler på hver skjerm. Lagring, start eller gjensending av en kanal i en gruppe hvor deres rolle er for lav, blir avvist med rollen de har der; det later ikke som om kanalen mangler, siden de kan se den. Deres rolle øverst på skjermen er den sterkeste de har, som åpner skjermene som rollen bruker, og hver handling på disse skjermene er fortsatt begrenset til gruppene hvor de har den.

Kun personer begrenset til kanalgrupper kan ha en. Noen som ser hver kanal har en rolle, fordi "redaktør av labens kanaler" for en person uten begrensning ville være redaktør av alt som tilhører ingen gruppe, og av serveromfattende sider. En fasilitets administrator kan gi en rolle per gruppe bare i gruppene de administrerer, og aldri over sin egen rolle der.

17.3 Hvem kan ringe FHIR-endepunktet

FHIR-endepunktet (serve -fhir) sjekker en av to typer token:

• Perfuse API-teksttoken, laget under Brukere → Maskinlegitimasjoner eller med perfuse token create. Hver bærer en rolle og kan

begrenses til FHIR-grupper. Dette er standard når ingen SMART-autorisasjonstjeneste er konfigurert.

• SMART-tilgangstoken, fra Perfuses egen autorisasjonstjeneste (-smart-clients) eller en ekstern en (-smart-issuer). Hver

bærer omfang og endpointet holder hver forespørsel til dem.

Med SMART konfigurert, aksepteres bare SMART-nøkler, så hver kaller holdes til sine omfang. En API-nøkkel har en rolle og ingen omfang: en viser-nøkkel kan lese hver pasients journal. En forsikrer som aktiverte SMART for å begrense hver app til hva den var gitt, bør ikke ha en måte inn som ikke er begrenset.

Noen steder trenger både alt det samme - en intern kravstrøm som inneholder en API-nøkkel og ikke har en SMART-klient, i tillegg til medlemsapper som logger inn via SMART. For disse, lar Innstillinger → FHIR → Aksepter Perfuse API-nøkler samt SMART-nøkler (-fhir-api-tokens ved oppstart) API-nøkler inn også. Den er av som standard, den trer i kraft på neste forespørsel i begge retninger, og endring av den skrives til revisjonsloggen. En nøkkel skilles fra hverandre av sin form: en SMART-nøkkel er en signert JWT, og en API-nøkkel er aldri det, så en sjekkes aldri som den andre. Der du kan, gi et slikt system en SMART Backend Services-klient i stedet, med bare de systemomfangene det trenger.

17.3.1 En FHIR-endepunkt åpen for fremmede

En offentlig testserver gir ut legitimasjoner som kan skrive, fordi testing av på forhånd autorisasjon eller abonnementer trenger skriving. To begrensninger forhindrer at en klient ødelegger det for alle, begge under Innstillinger → FHIR og begge av er deaktivert som standard:

• Skriver en per minutt fra en klient (-fhir-writes-per-minute): oppretter, oppdaterer og sletter fra en klientadresse. Over dette, blir en skrive besvart med 429 og Retry-After: 60. Leser og søker, inkludert søk via POST, blir aldri telt.
• Fleste ressurser holdt (-fhir-max-resources): forbi dette, blir nye ressurser avvist med 507, mens oppdateringer og slettinger fortsatt fungerer.

Et sykehus eget endpoint trenger ikke dette.

17.4 Et sykehusets eget endepunkt trenger ingen av delene.

Med Innstillinger › Sikkerhet › AI-agenter (MCP) på (eller serve -mcp), betjener Perfuse Model Context Protocol på /mcp, så en AI-agent som Claude, ChatGPT eller en IDE-assistent kan spørre det hva som skjer. Den er av som standard, og å slå den av stopper hver agent på dens neste anrop.

En agent kobler seg til med en API-nøkkel fra Administrer › Brukere › Maskinlegitimasjoner som en bærertoken, aldri med en persons nettlesersesjon (det blir avvist, så en agent handler aldri med en persons full tilgang). En klientkonfigurasjon ser ut som:

{ "mcpServers": { "perfuse": { "type": "http", "url": "https://perfuse.example/mcp",
    "headers": { "Authorization": "Bearer <token>" } } } }

Hvert verktøy besvares av samme rute eller FHIR-søk en persons skjerm bruker, kalt med agentens egen token, så tokenets rolle, kanalgrupper og leietaker bestemmer hva det ser, nøyaktig som de gjør i konsollen; og fhir_search får tokenets egen tilgang på FHIR-endepunktet (som kan avvise API-nøkler helt; se FHIR-delen ovenfor). En agent tilbys bare verktøyene dens token kan bruke. Lesing er standard: et verktøy som endrer noe, må også ha tokenets mcp:write-omfang ("La en AI-agent handle med det" når token utstedes), så en token utstedt for en rapporteringsagent kan ikke overtale til å handle ved en prompt. En overvåkingsokens svar har meldingsinnhold fjernet, uansett hva en rute returnerer.

Hver enkelt kall er i Activity som mcp.tool med tokenets navn, verktøyet, dets argumenter og resultatet (ok, refused, invalid, rate-limited eller HTTP-status); mcp.connect registrerer hvilken klient som koblet til. Hver token kan gjøre 60 verktøykall per minutt (Verktøykall per minutt fra en token); over dette, besvares et kall med en feil som agenten kan lese, og ingenting gjøres. En forespørsel fra en nettleserside på en annen opprinnelse avvises, som MCP ber en server om å stoppe DNS-omkobling. Transporten er MCPs strømbare HTTP, besvart som JSON uten hendelsesstrøm; protokollversjoner 2025-06-18, 2025-03-26 og 2024-11-05 er akseptert. Meldinger og FHIR-ressurser inneholder pasientdata: et agents svar går til den modellen det kjører på, så gi en token til et agent bare der den modellen er tillatt å se dem, og gi den den laveste rollen som gjør jobben.

17.5 En demonstrasjonskonto

serve -demo-account demo:PASSWORD oppretter en delt konto for en offentlig demonstrasjonsserver, og innloggingsiden viser brukernavnet og passordet med en knapp som logger inn med dem. Kontoen er en viser, så den kan se på alt og endre ingenting. I motsetning til enhver annen viser kan den også åpne administrator-skjermene (brukere, maskintokene, innstillinger, datavern, flåtens likeverdige), skrivebeskyttet: en demonstrasjon vurderes av skjermene. Den leser dem som en viser leser kanaler, med hver legitimasjon vist som satt eller ikke, aldri verdien, og hver endring avvist. Den kan også trykke på kontrollene som ikke endrer noe og når ingenting utenfor serveren: et skripts kontroll, og kanalredigeringsverktoyets valider og pars. Den kan ikke endre passordet eller legge til en passnøkkel, fordi den første besøkeren som gjør noen av delene ville låse ute alle etter dem. Hver start setter den tilbake som viser med det publiserte passordet. Passordet må være minst 12 tegn, som ethvert annet. Bruk det bare på en server som inneholder testdata: enhver som leser innloggingsiden kan lese hver melding på serveren.

17.6 Revisjon

Konfigurasjonsendringer, innlogginger og tilgang til meldingsinnhold registreres med hvem, hva og når.

Revisjonsloggen er i samme database som meldingene. Det er praktisk og det er en begrensning: noen som kan modifisere databasen, kan modifisere revisjonsloggen. Hvis dine krav inkluderer åpenbar revisjon, må loggen sendes til et sted som bare kan legges til, og Perfuses egen loggutgang er måten å gjøre det på.

17.7 Hemmeligheter i konfigurasjon

Passord, passkoder og nøkler vises i kanal-konfigurasjon, som betyr at de er i YAML-filene.

To konsekvenser. Filene må ha filsystemrettigheter som reflekterer hva de inneholder, og hvis de er i versjonskontroll — som ellers anbefales — inneholder laget legitimasjoner og må behandles deretter.

Hvor en verdi er en hemmelighet, viser grensesnittet den som en hemmelighet og API-et returnerer den ikke når den er lagret. Dette beskytter den mot å bli lest over noen sin skulder eller lekket i et skjermbilde. Det beskytter ikke filen.

17.8 Hva som er i databasen

Meldingslagret inneholder meldinger som mottatt, som for en klinisk strøm betyr pasientidentifiserbare data. Det bør være på kryptert lagring, sikkerhetskopiert som kliniske data med den oppbevaringstiden det innebærer, og tilgangskontrollert på filsystemnivå samt gjennom Perfuses egne roller.

cleanup.periodDays begrenser hvor lenge det beholdes. Se meldingsarkivet for spenningen mellom det og å ha nok historikk for rytmebevisst varsling.

17.9 Dataproteksjon (GDPR og UK GDPR)

Skjermen Databeskyttelse (Administrer, bare administratorer) besvarer en persons forespørsler under GDPR og UK GDPR. Den avgjør ingenting på vegne av kontrolleren: om en forespørsel må innvilges, og om en unntak gjelder, er kontrollerens avgjørelse, som blir registrert med forespørselen.

Hva som er lagret. En person identifiseres ved hjelp av identifikatorer: system|value (et NHS-nummer, et MRN med sin utstedende myndighet) eller et nummer på egen hånd. Med en pasientindeks utvides disse til hvert nummer på hver post som er koblet til samme person, så en forespørsel som nevner ett sykehusnummer finner postene som er arkivert under de andre. Se hva som er lagret søker deretter i hver butikk som lagrer pasientdata:

Hva den ikke kan nå, sier den: spor sendt til en samler (-trace-endpoint), revisjonsloggen (den er beholdt: den er rekorden av hvem gjorde hva, denne forespørselen inkludert), og sikkerhetskopier.

Forespørsler. En forespørsel registreres med sin type (tilgang, artikkel 15; overførbarhet, artikkel 20; sletting, artikkel 17; begrensning, artikkel 18), hvem den er fra som kontrollerens poster refererer til dem, identifikatorene og en notat (hvordan identiteten ble bekreftet, en utvidelse og dens grunn). Den er forfalt en måned etter mottak (artikkel 12(3)); en forfalt forespørsel vises i rødt.

• Tilgang og overførbarhet: Last ned kopi gir en zip: hver melding som mottatt med sin post, hver FHIR-ressurs med hver lagret versjon, tidligere autoriseringsforespørsler og deres svar, og pasientindeksens poster, JSON gjennomgående, med en README som sier hva hver del er. Merk besvart lukker den.
• Sletting: en annen administrator godkjenner den (hvem som helst som registrerte den, kan ikke). Slett nå sletter alt funnet: meldinger hele (post, innhold, leveranser, identifikatorer, vedlegg som ingen annen melding bruker), køede leveranser (de blir ikke sendt), FHIR-ressursene med deres historikk, tidligere autoriseringsforespørsler med deres svar, vedlegg og sporingsnumre, og personen i pasientindeksen med hver lenket post og dens historikk (en hendelse registrerer at en sletting skjedde, og av hvem).
• Begrensning: registrert som en rettslig varetekt, så ingenting slettes eller utløper mens den varer.
• Avvis lukker en forespørsel med dens grunn, som personen må bli fortalt.

En lukket forespørsel beholder bare de siste tegnene av personens nummer: den forblir som en rekord av et svar uten å være en kopi av dem. Hvert steg er i revisjonsloggen med numrene maskert.

Rettslige hold. Et hold navngir en person med identifikatorer, med en årsak og et valgfritt sluttdato. Mens det er i kraft, avvises en sletting fullstendig, og meldingslagringsvinduet for personens meldinger (rekorder og tekst) unntas inntil holdet løftes.

Sikkerhetskopier og slettingslogg. En sikkerhetskopi laget før en sletting inneholder fortsatt det som ble slettet inntil den utløper. Hver sletting skrives til en logg: når, av hvem, godkjent av hvem, hvor mye ble fjernet fra hver lagring, og personens identifikatorer som saltede SHA-256-hashes i stedet for i klartekst. Etter å ha gjenopprettet en sikkerhetskopi, hasher Bruk slettinger på nytt identifikatorene lagret i hver post med salt og sletter hver person loggen navngir. Korte numre kan finnes fra deres hasjer ved å prøve hver verdi, så loggen er selv personlige data og lagres med databaseens egen beskyttelse.

Oppbevaring. Skjermen lister hvor lenge hver type rekord oppbevares her og hva som endrer det: meldingsrekorder og tekst etter deres oppbevaringsvinduer, køen inntil den er levert eller fjernet, FHIR-lagringsplassen, tidligere autoriseringsforespørsler og pasientindekset inntil det slettes (kliniske rekorder slettes ikke på en fast plan), revisjonsloggen oppbevares.

Behandlingsrekord (Artikkel 30). Behandlingsrekord laster ned, som Markdown eller CSV, hva denne serveren vet om det: kontrolleren, personvernombudet og hvor dataene lagres (Innstillinger → Data → Personvern), oppbevaringstiden for hver type rekord, og en behandlingsaktivitet per kanal med hva den mottar, fra hvor, til hvilke destinasjoner, og vertene den sender til. Formålene, lovlige grunnlag og kategorier av datasubjekt er igjen for kontrolleren å fylle ut, og si det. En CSV-celle som begynner med =, +, - eller @ skrives med en ledende apostrof, så et regneark ikke kjører det.

Hvor dataene lagres. Hvor dataene lagres (Innstillinger → Data → Personvern) angir, i ord en regulator kan sjekke, hvor serveren, dens database og dens sikkerhetskopier kjører; personvernsskjermen og rekorden viser det. En utkast til personvernavtale for organisasjoner BioDream er vert for, er i docs/legal/dpa-template.md; det er et utkast for en advokat, ikke juridisk råd.

API-et er /api/privacy (oppsummering), /api/privacy/find, /api/privacy/requests (og /{id}/approve, /{id}/export, /{id}/erase, /{id}/close), /api/privacy/holds, /api/privacy/reapply og /api/privacy/register.

17.10 Leietakere

En leier er en isoleringsgrense: kanaler, meldinger, brukere og innstillinger tilhører en, og ingenting krysser.

Dette eksisterer for en tjenesteleverandør som kjører feeds for flere praksiser. Ikke bruk det til å skille avdelinger innen én organisasjon som trenger å se hverandres trafikk: isolasjonen er reell, og det finnes ingen tverr-tenant-visning. For det, bruk kanalgrupper (ovenfor), som deler menneskene i én organisasjon mens en sentral team kan se alt.

17.10.1 Grenser

En plattformoperatør setter hver leierens grenser i Tenants, slik at en kunde ikke kan fortrenge resten av en delt server. La en grense stå tom for ingen.

• Kanaler: hvor mange kanaler leietakeren kan ha. Å opprette en mer blir avvist, med tellingen og grensen.
• Meldinger per minutt: hvor mange meldinger dens kanaler sammen kan motta i ett minutt.
• Lagringsplass: hvor mye lagret meldingsinnhold den kan holde, i megabyte.

Ingen av dem mister en melding. Over raten eller lagringsgrensen, avvises en mottatt melding på samme måte som en opptatt mottaker avviser en, før noe lagres eller leveres: MLLP får ingen bekreftelse (ikke en avvisning, som noen sendere tar som "ikke send på nytt"), HTTP får 429 med Retry-After, SOAP får 503, DICOM får en retrybar status, og en kø, bucket eller fil forblir der den var. Senderen sender på nytt, som hver grensesnittsmotor og EHR gjør. Ingen allerede lagrede data slettes for å gjøre plass. En økt grense treffer i kraft innen en minutt, og hver endring av grenser er registrert i aktivitetloggen.

17.11 Testdata

De genererte meldingene beskrevet i testing eksisterer delvis som en personvernkontroll. Å gjenskape et problem andre steder, sende et eksempel til en leverandør eller fylle en testmiljø er alle ting som ellers gjøres med ekte meldinger.

Generatorens utdata inneholder ingen pasientdata ved konstruksjon heller enn ved redigering. Foretræk det fremfor håndstripede ekte meldinger, som er en prosess som kan gjøres ufullstendig og vanligvis er.

17.12 Enkelt innlogging

Tre mekanismer, og lokale kontoer sammen med alle disse.

OpenID Connect (-oidc), en katalog over LDAP (-ldap), og SAML 2.0 (-saml). Hver er konfigurert fra Administrer → Innlogging og skrevet til filen flaggenavnet, så skjermen og filen er to visninger av ett og samme heller enn to steder å holde i skritt.

Lokale kontoer er alltid tilgjengelige og kan ikke deaktiveres. Det er med vilje: en lokal integrasjonsmotor hvis eneste måte å komme inn er en identitetsleverandør, blir utilgjengelig nettopp når identitetsleverandøren er utilgjengelig, og en klinisk grensesnitt er ikke et godt sted å lære det. Innloggings-skjermen forteller deg hvor mange lokale administratorer eksisterer før den oppmuntrer deg til å avhenge av noe annet.

17.12.1 Hva en gruppetilordning bestemmer

Alle tre kartlegger grupper fra katalogen til Perfuse-roller, og noen i grupper som matcher mer enn én får den mest privilegerte. Det er den eneste trygge retningen å løse det — alternativet er en person som mister tilgang de har rett til fordi de også er i en mindre gruppe.

Noen av de seks rollene kan tildeles: overvåke, viser, operatør, redaktør, admin og plattform.

En gruppe kan også begrenses til noen kanalgrupper, i den andre boksen i raden (channel_groups i filen). Når noen gruppe navngir en, setter hver pålogging personens kanalgrupper fra gruppene som ga deres rolle: noen i en gruppe som redigerer laboratoriets kanaler og i en annen som viser hver kanal er en redaktør av laboratoriets kanaler og ingenting annet. Den sterkeste rollen er aldri koblet til den bredeste rekkevidden, fordi ingen gruppe gir det. En gruppe med en tom boks gir hver kanal. Mens ingen gruppe navngir noen, lar pålogging kanalgrupper være som en administrator har satt dem i Brukere.

Når hver gruppe en person matcher navngir kanalgrupper, får hver kanalgruppe den sterkeste rollen blant gruppene som navngir den: med Lab-Interfaces (redaktør, laboratorium) og Clinical-IT (viser, laboratorium og adt), redigerer personen laboratoriets kanaler og viser adgangene, som om den var satt for hånd. Når en av deres grupper gir hver kanal, finnes det ingen liste å holde en rolle per gruppe, og regelen ovenfor gjelder.

roles:
  editor: [Lab-Interfaces]
  operator: [Night-Desk]
  viewer: [Clinical-IT]
  channel_groups:
    Lab-Interfaces: [lab, pathology]
    Night-Desk: [adt]

Det er OpenID Connect- og SAML-filen. Katalogens fil kartlegger hver gruppe til en rolle (roles: {Lab-Interfaces: editor}), og channel_groups sitter ved siden av roles der.

En mapping som ikke gir noen noen ting, blir avvist i stedet for å bli lagret. En konfigurasjon som autentiserer personer og nekter alle, ser ut som et ødelagt produkt fra utsiden: den runde turen fullføres og alle blir nektet uten at noen forklaring.

Opprettelse av konto ved første pålogging er avslått som standard. Med den avslått, må noen eksistere i Perfuse før de kan logge inn, så katalogen bestemmer hvem de er og Perfuse bestemmer hvem som er tillatt inn.

17.12.2 SAML, spesifikt

Delene som er verdt å vite før du konfigurerer det:

• Kun sertifikatet du konfigurerer, er tillit til. Et sertifikat som er med i en respons, blir aldri brukt. En angriper som kan sende et dokument, kan også legge til sitt eget sertifikat i det, og en verifiserer som leser det, er en hvem som helst kan autentisere til som hvem som helst.
• En respons må svare på en pålogging denne serveren startet. Perfuse husker forespørselen den sendte og avviser en respons som navngir noe annet, eller navngir en forespørsel den allerede har svart på. Uten denne kontrollen er en gyldig respons en bærertoken for hvem som helst som holder den: noen logger inn som seg selv, beholder responsen og posterer den inn i nettleseren din, og du er da innenfor deres konto med en audit-logg som registrerer deres navn.
• Pålogginger startet hos identitetsleverandøren er derfor av som standard. Slå på *Aksepter pålogginger startet hos identitetsleverandøren* bare hvis du trenger en portal-flise, og vite at det er hva som gjør ovennevnte mulig.
• Gruppeattributtet har ingen standardverdi og er påkrevd. Entra sender groups, Okta sender hva som helst applikasjonen ble konfigurert med, ADFS sender en krav-URI. Et gjett ville produsere en pålogging som fungerer og gir ingen noen ting. Hvis en pålogging avvises fordi den mangler en rolle, navngir serverloggen attributtene som ankom — som vanligvis er hele svaret.
• Svar-URLen må matche nøyaktig hva som er registrert hos leverandøren. En respons sier hvor den var bestemt, og en som er adressert et annet sted, avvises, fordi å akseptere den ville bety å akseptere en respons ment for en annen tjeneste.

17.12.3 Hva hver leverandør sender

Gruppeattributtet er der pålogginger går galt, og de tre vanlige leverandørene navngir det forskjellig.

En krav-URI kan angis ved sin endelige segment: å skrive groups finner http://schemas.microsoft.com/ws/2008/06/identity/claims/groups. Et navn som bare ender med ordet, matcher ikke — excluded_groups er ikke groups.

Gruppe-medlemskap som ankommer som en komma-separert verdi, behandles som ett enkelt gruppenavn og matcher ingenting. Dette er den riktige lesningen av standarden, og å splitte på komma ville bety at en gruppe som legitimt inneholder en, blir stille til to. Hvis dette er hva din leverandør sender, endre det der.

Test på påloggings-skjermen sjekker alt som kan sjekkes uten en person: innstillingene, sertifikatet og om en pålogging-forespørsel kan bygges. Den sier åpenbart at den ikke kan bevise at noen kan logge inn, fordi det trenger en ekte påstand om en ekte person og den eneste måten å få en påstand på, er å la dem prøve.

17.13 Kontoer som er etablert av identitetsleverandøren: SCIM

Med -scim (Innstillinger → Pålogging → Automatiske kontoer), oppretter en identitetsleverandør som Okta, Microsoft Entra ID eller Google Workspace Perfuse-kontoer selv på /scim/v2/Users, så en person som forlater organisasjonen mister tilgang når deres katalogkonto er deaktivert, ikke når noen husker. Leverandøren autentiserer med en API-nøkkel som inneholder admin-rollen, laget under Brukere → Maskin-kredensialer, sendt som en bærertoken.

• Deaktivering av en konto avslutter øktene umiddelbart, og serveren sjekker at ingen overlevde før den svarer. En tjenesteleverandør blir

aldri informert om at en konto er deaktivert når den ikke er det, fordi en tjenesteleverandør ikke gjentar hva den ble fortalt var vellykket.

• En sletting deaktiverer først, og deretter sletter, så en feil halvveis etterlater en konto som ingen kan logge inn med. Audithistorikken til

en fjernet konto beholdes.

• Rollen kommer fra personens grupper eller roller, matchede etter navn: en gruppe hvis navn inneholder *admin*, *editor*, *operator*,

*viewer* (eller *read-only*) eller *monitor* gir denne rollen, så APP-Perfuse-Editor og Perfuse Operators fungerer som de er navngitt. Alt annet får -scim-default-role, viser med mindre det er satt til noe annet. Plattform kan aldri tildeles på denne måten.

• Ingen passord. En konto laget av SCIM logger inn gjennom identitetsleverandøren; et annet passord som ingen upstream kjenner til

ville overleve en deaktivering der.

• /scim/v2/ServiceProviderConfig sier hva som støttes: opprette, lese, erstatte, patch og slette av Brukere, og filtre opp til 200

resultater. Bulk-operasjoner, sortering og ETags støttes ikke.

17.14 Hva Perfuse ikke gjør

Det krypterer ikke databasen i ro. Bruk kryptering av filsystem eller volum.

Det håndterer ikke sine egne sertifikater eller fornyer dem. Peke på filer og håndtere disse filene med hva du allerede bruker.

SAML er verifisert mot to uavhengige leverandører, hver med en ekte nettleser-innlogging, en ekte påstand og en ekte sesjon: Keycloak 26 og Microsoft Entra. To saker betyr mer enn dobbelt så mye som en, fordi de to er uenige på en måte som viste seg å være bærende — Keycloak skriver sin påstand med navneromsprefikser og Entra skriver de samme elementene uten dem, og den ene feilen dette området har hatt var i prefikshåndtering.

Start med å lese leverandørens metadata. Innstillinger, deretter Innlogging, deretter SAML-fanen: gi metadata-URL eller lim inn dokumentet, og innloggingsadressen og signatursertifikatet fylles ut for deg. Hver SAML-leverandør publiserer en av disse — Okta, Entra, AWS IAM Identity Center, Keycloak, ADFS — og det er forskjellen på å konfigurere en leverandør og å transkribere en. Å gjøre det manuelt innebærer å finne sertifikatet inne i XML, fjerne linjeskiftene fra base64 og pakke det inn i PEM-overskrifter, der ett enkelt feilplassert mellomrom produserer en signaturfeil som ikke sier noe om formatering.

Hva som kommer tilbake, beskrives heller enn dumpes: hver sertifikats emne, utløpsdato og SHA-256-fingeravtrykk, så du kan sjekke det mot hva leverandørens egen konsoll viser. Et utløpt sertifikat kalles utløpt heller enn å bli latt som en dato å sammenligne med øye. Ingen blir lagret ved å lese — å bruke det på skjemaet er et separat klikk, fordi et dokument noen limte inn ikke er en beslutning om hva som skal tillites.

En metadata-URL hentes over https bare, og adressen sjekkes mot samme politikk som styrer kanaldestinasjoner, så dette kan ikke brukes til å få serveren til å lese skyinstans-credensialer. Omdirigeringer følges ikke, fordi en tillatt adresse som omdirigerer til en blokkert en ville gå rett forbi denne sjekken.

Hvis du konfigurerer Entra, vil fem ting ikke matche hva eksemplene viser deg. Det sender ingen e-post-krav overhode. Dets NameID er en uigennomsiktig identifikator heller enn en adresse. Det sender ingen grupper-krav med mindre applikasjonen er eksplisitt konfigurert til å emitte en, så en rolle-mapping skrevet mot grupper nekter hver innlogging. Når grupper emitieres, er de objekt-GUID-er heller enn navn, med mindre din leier synkroniserer fra lokale Active Directory. Og dens kravnavn bor under schemas.microsoft.com/identity hvor de fleste dokumenter viser schemas.xmlsoap.org. Perfuse håndterer alle fem; de er listet fordi de fire første ellers vil se ut som feil i Perfuse når de er Entra som er Entra.

Denne distinksjonen er ikke teoretisk her. Den første ekte Keycloak-påstanden feilet fullstendig, fordi den kanoniske formen signaturen dekker ble beregnet med navneromsprefikser droppet. Ingen ekte identitetsleverandør kunne ha logget noen inn, og pakkenes egne fem kanoniserings-tester passerte gjennom hele — hver av dem signert og verifisert med samme kode, så de beviste bare at det var enig med seg selv. Hvis du er den første til å peke en annen leverandør mot dette, forvent å finne noe, og serverloggen vil navngi stadiet som feilet.

18 Operasjoner

18.1 Distribusjon

En binær og to stier: en mappe med kanal-filer og en databasefil. Det er ingen applikasjonsserver, ingen separat web-tverr og ingen meldingsformidler påkrevd.

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

Kjør det under hva som overvåker tjenester på verten — systemd, launchd, en container-runtime. Det forventer å bli restartet hvis det avslutter.

18.2 Hvor data kan gå (data-residens)

serve -residency (Innstillinger → Data → Hvor data kan gå) navngir skyregionene som denne serverens data kan sendes til eller leses fra: områder (eea, uk, ch) og region koder (eu-central-1, uksouth, europe-west2), komma-separert. eea er AWS-, Azure- og Google Cloud-regionene i Den europeiske økonomiske sone (Frankfurt, Irland, Paris, Stockholm, Milano, Spania; Nederland, Tyskland, Frankrike, Sverige, Norge, Italia, Polen, Spania; Belgia, Nederland, Tyskland, Italia, Frankrike, Finland, Spania, Polen), uk de i Storbritannia, ch de i Sveits.

Med det satt, nektes en kanal, når den lagres og når den lastes, hvis en konnektor navngir en region utenfor listen: en S3-, SQS- eller SNS-kilde eller destinasjons region (eller dens endpoint, når det er en AWS-hostnavn), eller enhver destinasjon hvis adresse er en AWS-hostnavn som bærer en region (sqs.us-east-1.amazonaws.com, en API Gateway-URL). Serveren nekter å starte med en spor-samler eller varsling-webhook i en annen region. En konnektor pekt på en vert som ikke navngir noen region (et sykehus eget system, MinIO på nettverket) dømmes ikke: posten om behandling på Data-skyttskjermbildet lister hver vert hver kanal sender til, for kontrolleren til å sjekke. Dashbordet og Data-skyttskjermbildet sier hvor data kan gå.

Vert i EU og Storbritannia. deploy/hosted inneholder OpenTofu (eller Terraform) for en vertserver per organisasjon i Frankfurt, Irland eller London: serveren, dens PostgreSQL-database og sikkerhetskopier, en sikkerhetskopibucket, logger og støttesessionsopptak, alt kryptert med en nøkkel i regionen, ingen replikeres til en annen region, støtte gjennom Session Manager bare, og Perfuse kjørt med -residency. Denne README-en sier hva den bygger, hva den ikke dekker, hva som er verifisert (valider, og planlagt mot en ekte konto; ikke ennå aplikert) og hva det koster til listepris i hver region.

18.3 Konfigurasjon som filer

Kanaler er filer, noe som betyr at de kan være i versjonskontroll, gjennomgås før distribusjon og sammenlignes etter en hendelse.

Filer leses på nytt uten omstart. En fil som ikke parseres rapporteres og den tidligere lastede versjonen fortsetter å kjøre, så en syntaksfeil kan ikke ta en fungerende strøm av luften.

18.4 Sikkerhetskopiering

To ting å sikkerhetskopiere, og de har forskjellige egenskaper.

Kanalmappen er liten, endrer sjelden og er det du trenger for å gjenoppbygge tjenesten. Sikkerhetskopier den som konfigurasjon; versjonskontroll er vanligvis tilstrekkelig.

Databasen inneholder meldinger, brukere og revisjonslogg. Den er stor, endrer konstant og inneholder kliniske data — så den må sikkerhetskopieres som kliniske data, med den retensjon og kryptering det innebærer. Å miste den stopper ikke tjenesten, men den mister evnen til å undersøke noe som allerede har skjedd og historikken som rytme-læreren er avhengig av.

18.5 Omstartsvaner

Ved omstart, lastes kanaler og kilder begynner å lytte. Køede leveranser gjenopptas.

Det viktige å forstå er hva som skjer med arbeid i gjennomføring. Under standard on_delivery bekreftelse, blir et melding som ikke har blitt bekreftet enda, ikke bekreftet, så avsenderen vil sende det igjen — som er det riktige resultatet. Under on_receipt, er et melding som ble bekreftet, men ikke levert enda, i køen, og fortsetter; hvis køen er deaktivert, går det tapt. Se meldingsflyt.

18.6 Oppgradering

Erstatt binærfilen og restart. Databasens skjema migreres fremover automatisk ved start.

Migrasjoner er bare fremover. Det finnes ingen nedgradering, så en tilbakeføring til en tidligere binærfil etter at skjemaet har flyttet, trenger den tidligere databasen. Ta en kopi før oppgradering — dette er den eneste operative forsiktighetsforanstaltningen som er verdt å være disiplinert om.

18.7 Overvåking

Varsling fra innen Perfuse er dekket i varsling og er hva som vil fortelle deg at en feed har stoppet.

Utenfra, overvåk prosessen, disken databasen er på, og om nettgrensesnittet svarer. Databasen vokser og en full disk stopper meldingsopptak, som er en feilmodus uten noen annen advarsel.

18.7.1 SNMP

For overvåkingsverktøy som snakker SNMP (Nagios, Zabbix, PRTG, SolarWinds, LibreNMS), kjører Perfuse en skrivebeskyttet SNMPv2c-agent og sender en felle når en varsling utløses eller løses. Sett den under Innstillinger → Overvåking → SNMP, eller med flagg:

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

• Agenten svarer på GET, GETNEXT og GETBULK, og bare fra nettverkene i -snmp-allow: v2c-samfunnet er et passord sendt i

klartekst, så det er aldri åpent for alle. Et samfunn under 6 tegn, eller public/private, stopper serveren ved oppstart.

• Den betjener systemgruppen (sysDescr, sysUpTime, sysName fra flåteetiketten, sysContact, sysLocation), totaler under

BASE.1 (kanaler, kjører, ødelagte, mottatt, levert, feilet, køet) og en kanaltabell under BASE.2.1 (navn, kjører eller stoppet, mottatt, levert, feilet, køet, alderen til den eldste køede meldingen). Tallene er de samme som dashboarden og /metrics viser.

• Feller går til hver manager i -snmp-traps: BASE.0.1 en varsling utløst, BASE.0.2 den løst, med varslingens type,

alvorlighetsgrad, kanal, destinasjon og sammenfatting. Aldri meldingsinnhold. En anerkjent varsling sender ingen felle.

• BASE er 1.3.6.1.4.1.8072.9999.9999.16 (Net-SNMPs eksperimentelle rom) med mindre -snmp-base-oid plasserer det under eget

bedriftsnummer. Last ned MIB på innstillingsiden (eller GET /api/snmp/mib) gir en MIB for basisen i bruk; det samme panelet sier om agenten svarer og hvor mange feller som har gått.

18.7.2 En oversikt over hver grensesnitt

-inventory interfaces.md (Innstillinger → Overvåking → Oversikt) skriver en Markdown-dokument som listar hver kanal - dens format, om den kjører, hva den mottar fra og hva den sender til - etterfulgt av hver kanals egen beskrivelse, og skriver den om hver -inventory-every (en dag som standard). Den er ment å committes ved siden av kanal-filene, eller overleveres til en revisor, og leses uten at applikasjonen kjører.

18.8 Kapasitet

Perfuses gjennomstrømnings tak har ikke blitt målt på ekte maskinvare under ekte trafikk, og denne håndboken vil ikke skrive ut et tall det ikke kan støtte.

Hva som kan sies: arkitekturen er én gorutine per tilkobling med per-destinasjonskøer, så gjennomstrømning skalerer med destinasjoner heller enn å bli serialisert gjennom én arbeider; meldingsopptak er en SQLite-skriving per melding, som gjør disken til den mest sannsynlige første begrensningen; og meldingslagret vokser lineært med trafikken, så retensjon er innstillingen som styrer langtids disken.

Hvis du størrelsesbestemmer dette for en stor strøm, måler du det med din egen trafikk ved hjelp av det genererte testkorpuset beskrevet i testing. Det er det ærlige svaret, og det er også et bedre svar enn et tall fra noen andres maskinvare.

18.9 Hvor denne installasjonen ble stående

Aktivitet bærer et panel, synlig for administratorer, som viser hva Perfuse har nektet å gjøre — gruppert etter melding, mest hyppig først — og hvor langt installasjonen har kommet mot en fungerende kanal.

Det eksisterer fordi hver annen påstand om hvorvidt denne programvaren er lett å bruke, kommer fra de som skrev den. En nektelse gjør ikke det: noen ønsket noe, serveren sa nei, og ingen av partene gjetting.

Trakten navngir steg som ikke har skjedd ennå, i stedet for å la tidsstempeler sammenlignes. Tilstanden som er verdt å se på er meldinger ankommer og ingen har blitt levert til en destinasjon — en kanal kan ta trafikk i uker og levere ingen av dem, og fra hver annen skjerm ser det ut som om det fungerer.

Ingenting noen skrev inn blir registrert. Tabellen inneholder forespørselsruten med identifikatorer erstattet med {id}, status og serverens egen setning. En valideringsmelding navngir et felt og en regel, som er den nyttige delen; verdien som brøt regelen er ofte pasientdata, og en tabell over disse ville være en større risiko enn friksjonen den målte.

To bevisste eksklusjoner. En 5xx er en feil i denne programvaren og blir allerede logget som en — å blande de to ville begrave tilfellene hvor noen ikke kunne finne ut hva de skulle skrive under tilfellene hvor ingenting de skrev ville ha hjulpet. Og en utløpt sesjon produserer en rekke 401-er som ikke sier noe om brukervennlighet og ville drukne hver funn som gjør.

Å lese rapporten trimmer også tabellen til de fem siste tusen radene. Nektelser er 4xx-responser, så den vokser sakte, og lesing er et naturlig øyeblikk å rydde opp: ingen timer og ingenting som kjører når ingen ser på.

GET /api/friction returnerer det samme for noen som heller vil lese det som JSON.

18.10 Logger

Perfuse logger til standardutgang, som er der en overordnet eller containerkjøretid vil samle det inn.

Meldingsnivådetaljer går til meldingslagret i stedet for loggen, med vilje. En logglinne per melding på en travel strøm er støy som skjuler linjene som teller, og lagret er søkbart på måter en loggfil ikke er.

Loggen inneholder det lagret ikke kan: oppstart og nedtagningslogg, konfigurasjonslastresultater, kanaltilstandsforandringer og feil som ikke kan tilskrives en bestemt melding.

18.11 Kjøring av to instanser

To eller flere servere kan kjøre som én klaster: når den som kjører en feed stopper, tar en annen over innen få sekunder, og avsenderens neste forsøk når den. De deler én PostgreSQL-database i stedet for at hver beholder en SQLite-fil, og enes mellom seg, gjennom den, om hvem som kjører hva.

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

Start hver server på samme måte med sitt eget navn og adresse. Databasekontoen trenger å opprette tabeller og, en gang, citext-utvidelsen (eller en administrator kjører CREATE EXTENSION citext først). Hver server beholder sine egne filer i -data: sin logg, sin node-id og sine kopier av konfigurasjonen.

To måter å dele arbeidet på.

• active-passive: lederen kjører hver kanal og hver jobb som må kjøres én gang (FHIR-abonnementsvarslinger). De andre venter.

Det enkleste å forstå, og hva et sted med én travel server og en reserve ønsker.

• active-active: kanalene fordeler seg over de aktive serverne, omtrent jevnt. En server som stopper overfører sine kanaler

til de andre; en som slutter seg til tar sin andel når kanaler blir ledige, én om gangen. Kanaler som ruter til hverandre (en kanaldestinasjon) kjører på én server og flytter sammen, fordi ruting skjer innenfor en server. En administrator kan flytte en kanal manuelt fra Overvåk → Flåte; den blir der den ble plassert så lenge serveren lever.

Hvem kjører hva, og ingen øyeblikk med to. Hver arbeidsenhet er en leie i database, fornyet hver femte del av -cluster-lease (15 s som standard). En server som ikke kan fornye den (den krasjet, dens nettverk feilet, database er utilgjengelig) stopper arbeidet selv én gang dens egen klokke sier leien er nesten ferdig, med en tredel av leien igjen. En annen server tar leien bare etter at dens egen klokke har sett leiens teller stå stille i en hel leie. Ingen klokke sammenlignes med en annen, så serverne og databaseklokke trenger ikke være enige; de trenger bare å kjøre i omtrent samme takt, som hver klokke gjør. Mellom den gamle innehaveren som stopper og den nye som starter er det et kort gap med ingen som lytter, som en avsender ser som en avvist tilkobling og prøver igjen; det er aldri et øyeblikk med to som lytter på én feed eller to arbeidere som tømmer én kø.

En server som lukker seg ned renlig, eller en administrator som velger Tilbake på lederen, overfører umiddelbart i stedet for etter leien.

Hva hver server deler. Meldinger, leveringskøen, kontoer og sesjoner, revisjonsloggen, FHIR-lagret, terminologitabellene og pasientregisteret er i databasen, så uansett hvilken server som kjører en kanal, finner den køen den siste forlot. Kanalfilene, innstillingsfilen, varslingsreglene, enkeltinnloggingsfilene, logoen, Direct-sertifikater og lagrede visninger beholdes like på hver server gjennom databasen: hver beholder sin egen kopi på sin egen disk, en endring på noen server (i konsollen, manuelt, ved en git pull) når de andre innen to sekunder, og en kanal endret på en annen server starter på nytt med sin nye fil. Samme fil endret på to servere samtidig beholder versjonen som nådde databasen først, og den andre ved siden av som NAME.conflict-SERVER. Innstillinger som bare gjelder ved omstart (meldingsdatabasen, portene konsollen lytter på) gjøres av hver server ved neste omstart, og loggen sier det. Navn på noe på én maskin som bare er på den serverens kommandolinje og utenfor den delte filen: sertifikatet og nøkkelen (-tls-cert, -tls-key), SNMP-lytteradressen og serverens navn i spor.

Start og stopp. Å starte eller stoppe en kanal på noen server gjelder for clusteret: serveren som kjører den starter eller stopper den innen én sekund, og svaret sier hvilken server det er.

Lastbalanseren foran. En feeds adresse må nå hvilken server som kjører den. Peke senderen mot en virtuell adresse (en lastbalanser, en flytende IP, et DNS-navn med en kort TTL) og la lastbalanseren sjekke /readyz?channel=NAME, som bare svarer 200 på serveren som kjører den kanalen, og 503 på de andre. For konsollen er /readyz 200 på hver live-server; /readyz?role=leader bare på lederen.

På en AWS Network Load Balancer, bruk en målgruppe per feed med en HTTPS-helsekontroll på /readyz?channel=NAME, et 5-sekunders intervall og en terskel på 2, og slå cross-zone lastbalansering på. Med den av, ser lastbalanserens node i en sone hvor ingen server kjører feeden bare usunne mål, sender til alle likevel, og en sender som ble resolved til den noden venter til feeden kommer tilbake til sin sone (95 sekunder i en test). Sett avregistreringsforsinkelsen til 0, siden en server som stopper å kjøre en feed ikke har noe å drene.

Hva som ble testet. To servere på PostgreSQL 16, en sender som strømmet 300 meldinger, sendte på nytt til svaret kom, og serveren som kjørte feeden ble drept med SIGKILL to ganger (først, så den andre etter den første kom tilbake). Hver bekreftet melding nådde mottakeren, i begge former prøvd: levert før bekreftelsen, og køet i den delte butikken mens mottakeren nektet (185 bekreftede meldinger ventet i køen ved dreping; overlevende leverte alle). Failover tok 3 til 4 sekunder på en 3-sekunders leie. En duplikat er mulig og ble sett én gang på 600: en melding den døende serveren leverte og ikke kunne bekrefte, som senderen sendte på nytt. Koordinatorens egne tester dekker en krasj, en server kuttes fra fra databasen mens den kjører på, step-down, spredning, flyttinger og delt konfigurasjon med konflikter. De kjøres i CI mot PostgreSQL med raske-detektor, med hele suiten.

Det samme ble så gjort på AWS: to Linux-servere (ARM) og en Windows Server 2022 i tre tilgjengelighetssoner, Amazon RDS PostgreSQL 16 over TLS med sertifikatet kontrollert (sslmode=verify-full), en intern Network Load Balancer foran, og sendere som sendte på nytt til svaret kom:

Med den standard 15-sekunders leieutløping, stoppet en server som var koblet fra databasen sin feed 10 sekunder etter sine siste fornyelse, og den neste serveren startet den 6 til 8 sekunder etter det: aldri begge på samme tid. De skjeve klokkeslettene endret ingenting, siden ingen klokke sammenlignes med en annen.

Ikke ennå. Et cluster tjener én organisasjon: -cluster med -multi-tenant er nektet. Lyttere flytter med sin kanal, så lastbalanseren er stedets å tilby.

En server på egen hånd fortsetter å fungere som den alltid har, på SQLite, uten noen cluster.

18.12 Mer enn en server

Et sted med to eksemplarer har et spørsmål ingen enkelt konsoll kan svare på: kjører alt? Mirth beregner for svaret. Dette er flåtevisningen.

Én eksemplar er nominert som stedet du ser. Den avhører de andre og viser hver kanal på hver server i én tabell, med en oppsummering over alle.

18.12.1 Legge til en peer

Innstillinger → Flåte, eller PUT /api/fleet/peers. En peer trenger et navn, en URL og en token utstedt av peeren selv.

Navnet er påkrevd og er ikke URLen, fordi en URL ikke er noe noen gjenkjenner klokken tre om natten.

Token må være opprettet på jevnbyrdige, under Brukere, og bør være viewer-omfattende. Å legge til en jevnbyrdig uten en er nektet, med disse instruksjonene, heller enn å bli akseptert og så feile stille på hver avhøring. Å lese en annen eksemplars helse er den minste privilegiet som finnes, og det er det eneste flåtevisningen trenger.

18.12.2 Kontroll av en peer, som er av

allow_control tillater å starte og stoppe jevnbyrdiges kanaler fra her. Den er av som standard, og hver bruk blir auditedert med navn.

De to privilegiene er bevisst separate. Å lese en annen servers helse er mindre; å stoppe dens kanaler under en transfusjon er ikke det, og det andre bør aldri ankomme stille festet til det første.

18.12.3 Hva rapporten sier

Hver server rapporterer det totale antallet kanaler, hvor mange som kjører, stoppet eller feilet, kødyp og alderen på den eldste ventende meldingen, hvor mange varslinger som utløses, og om den drener for nedstengning.

Sammenfattnings tellingene teller servere på tre måter: tilgjengelig, utilgjengelig og usikker. Den tredje dekker peers hvis helse ingen vet — ikke ennå avhørt, nektet token eller kjører en versjon som denne ikke kan lese. Den holdes adskilt fra utilgjengelig fordi "vi ekke kan si" ikke er "den er nede", og å kombinere de to sammen er hvordan en flåte-side begynner å lyve.

Av samme grunn har sammenfattningsrapporten kjentFra: hvor mange instanser kanal- og køfigurer faktisk ble lest fra. Tolv kanaler som kjører over en flåte betyr noe annet når to av fem servere ikke svarte, og totalen alene kan ikke si det.

En utilgjengelig peer sier hvorfor på en måte en operatør kan handle på. En nektet tilkobling rapporteres som verten er oppe med ingenting som lytter på den porten, som er et annet problem enn en vert som ikke svarer i det hele tatt.

18.12.4 Uravvik

Sammenfattningsrapporten rapporterer den største forskjellen mellom klokkeslettene på serverne i den. Verdt et eget tall: å korrelere en hendelse over to instanser hvis klokkeslett ikke er enige om fire minutter produserer en sekvens av hendelser som ikke skjedde.

18.12.5 Hva en peer lærer om deg

Tall og hastigheter. Rapporten en instans gir en annen inneholder ingen meldingsidentifikatorer, ingen kanal-nivådetalj og ingen pasientdata av noen art.

Det er det som forhindrer en flåte-oversikt fra å være en sentralisering av kliniske data: den aggregerte instansen lærer hvor mange kanaler som kjører og ingenting om hva som strømmet gjennom dem. Hvis du ønsker meldingene åpner du den serverens egen konsoll, hvor audit-loggen registrerer at du gjorde det.

18.12.6 En peer pekt på seg selv

Nektet. En instans som avhører sin egen adresse gjennom sin egen HTTP-stakk vises to ganger i sin egen flåte-oversikt og dobbeltteller hver kanal den har.

18.12.7 TLS på interne nettverk

insecure_skip_verify aksepterer en peers sertifikat uten å verifisere det. Den eksisterer fordi sykehus-infrastruktur kjører på private sertifikat-myndigheter, og å nekte å fungere i det hele tatt ville skyve folk over på vanlig HTTP, som er verre. Den er navngitt så den ikke kan forveksles med en god idé.

19 Kommandolinjen

Alt Perfuse gjør til et kjørende system er tilgjengelig fra webgrensesnittet, og det er bevisst: en funksjon som trenger en terminal behandles som en feil i stedet for en designvalg. Kommandoene her er for arbeidet som skjer *rundt* et kjørende system — før det eksisterer, mens du bestemmer om du skal stole på det, og når du trenger å overføre noe til noen andre.

Flere av dem berører ikke en server i det hele tatt. perfuse explain, perfuse profile, perfuse deident og perfuse translate leser filer og skriver filer, så de er nyttige på en bærbar datamaskin mot en eiendom som fortsatt kjører helt på noe annet.

Kjør noen kommando med -h for flagg. Dette kapitlet sier hva hver enkelt er *for*.

19.1 Kjører kanaler

19.1.1 perfuse serve

Kjører webgrensesnittet og API-et, og kjører som standard også kanalene. Dette er kommandoen en installasjon bruker.

Hver valgmulighet den tar, er listet i Serveralternativer, generert fra programmet. Den nekter å betjene vanlig HTTP til noe annet enn loopback med mindre du passerer -insecure. Dette er ikke konfigurerbar høflighet: klinisk trafikk og en sesjonskake over en ukryptert LAN-tilkobling er en rapporterbar hendelse, og flagget eksisterer så at å si ja er en beslutning noen har tatt, snarere enn en standard de har arvet. Se sikkerhet.

19.1.2 perfuse run

Kjører kanaler fra YAML uten webgrensesnitt og uten database. Nyttig i en container som skal gjøre akkurat én ting, og nyttig når du ønsker å se en kanals atferd uten at noe annet kjører.

19.1.3 perfuse check

Validerer kanaldefinisjoner og skriver ut hva de gjør, uten å kjøre dem. Den andre halvdelen er poenget: en kanal som lastes, er ikke nødvendigvis den kanalen du mente, og å lese en ren-engelsk sammenfatning av hva en fil vil gjøre, fanger en feil som validering ikke kan se.

Avslutter med en ikke-null verdi på en feil, så den hører hjemme i hva som helst sjekker konfigurasjonen din før den når en server. -quiet skriver ut ingenting ved suksess, for dette formålet.

-allow-metadata-egress tillater destinasjoner pekt på skyinstans-metadataadresser. Disse adressene inneholder maskinens egne legitimasjoner, så en kanal som kan overtale til å sende der, er en legitimasjonslekkasje; sjekken nekter dem med mindre du sier noe annet.

19.1.4 perfuse test

Kjører tester skrevet mot kanaldefinisjoner. En test sender en melding gjennom kanalenes faktiske filter, faktiske transformasjoner og faktiske skript, i den faktiske rekkefølgen, med bare nettverket erstattet — så hva som passerer her, er hva kanalen gjør.

Tester bor i *_test.yaml eller *.test.yaml ved siden av kanalene. Se testing.

19.2 Migrering fra en annen motor

Disse tre er de som skal kjøres først, før du bestemmer deg for noe. Se migrering.

19.2.1 perfuse explain

Lese Mirth, Open Integration Engine og BridgeLink-eksporter — en kanal, en kanalgruppe eller en hel serverbackup — og beskriver hva hver kanal gjør og hva som ville blokkere en migrering. Den endrer ingenting og trenger ingen Perfuse-installasjon, noe som gjør det til det billigste mulige første skrittet: peke det mot en eksport av din eiendom og lese hva som kommer tilbake.

-strict avslutter med en ikke-null verdi hvis noe er blokkert, så den kan kontrollere en pipeline. -json emitterer de samme funnene for en maskin.

19.2.2 perfuse translate

Konverterer Mirth, Open Integration Engine og BridgeLink-eksporter til Perfuse-kanalfiler: en kanal, en kanalgruppe, en kode-mal-eksport eller en hel serverbackup.

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

Kode-mal-biblioteker skrives til lib/ ved siden av kanalene, og hver kanal Mirth hadde en bibliotek aktivert for, inkluderer det. Se migrering.

Ingenting blir stille droppet. Hver del av en kanal er enten oversatt, båret over som et skript som kjører uendret, eller rapportert som trengende en menneskelig. Den tredje kategorien er den ærlige — en oversetter som produserte en ren-utseende fil for hver inndata, ville skjule de beslutningene du mest trenger å gjøre.

19.2.3 perfuse compare

Kjører samme trafikk gjennom to motorer og rapporterer hvor de er uenige, gruppert etter felt.

Dette er kommandoen som svarer på "hvorfor skal jeg stole på dette med pasientdata", og den svarer med bevis du har samlet inn, snarere enn et påstand gjort her. Det er det anbefalte siste steget før overgang, og det anbefalte første steget i enhver diskusjon om hvorvidt Perfuse er klar.

19.3 Forstå en feed

19.3.1 perfuse profil

Lese meldinger og rapportere hva som faktisk er i dem: hvilke felt alltid er fylt ut, hvilke aldri er, de faktiske verdiene for kodete felt, gjentakelses tellere og hvilke Z-segmenter som vises.

Verdier rapporteres bare for felt hvis verdier utgjør en liten kode sett, så en profil av ekte trafikk ikke blir en fil full av pasientdata.

Lagring av en profil og sammenligning mot den senere er hvordan du finner ut at en avsender har endret noe:

perfuse profil -lagre siste-måned.json korpus/ perfuse profil -mot siste-måned.json ny/

19.3.2 perfuse kontrakt

Omgjør utdata fra den tenkningen til noe som kan pålegges. En kontrakt sier hva en feed må se ut som, så den dagen den endres, blir du underrettet, snarere enn å finne ut uker senere fra en mottaker som kollapser — meldingene er fortsatt gyldige HL7 når et felt forsvinner, så ingenting annet legger merke til.

perfuse kontrakt fremme -o adt.kontrakt.yaml korpus/ perfuse kontrakt sjekk adt.kontrakt.yaml i-dag/

promote genererer en utgangspunkt, ikke et svar. Les den og slett mesteparten av den: hver linje registrerer om den ble målt eller bestemt, som er det som forteller deg hvilke linjer du skal beholde.

19.4 Produksjon av meldinger

19.4.1 perfuse generer

Produserer syntetiske HL7 v2-meldinger. Alt er oppfunnet — åpenbart fiktive navn, sekvensielle identifikatorer, oppdiktet adresser — så utdata er trygt å committe, sende og vedlegge til en billett.

Den kan sende rett til en kanal i stedet for å skrive en fil, som er den raskeste måten å bevise at en lytter fungerer:

perfuse generer -n 100 -send 127.0.0.1:6661

19.4.2 perfuse deidentifiser

Lese ekte meldinger og skrive en korpus som beholder deres struktur, deres koder og deres intervaller, og ingen av hva som identifiserer en pasient. Dette er forskjellen på å kunne sende noen en reprodusert og ikke.

Det er ikke samme verktøy som perfuse generate og forskjellen betyr noe. Genererte meldinger er oppfunnet og derfor trygge, men urealistiske; et de-identifisert korpus er *avledet fra virkelig trafikk*, så det reproduserer de underlige tingene som faktisk bryter grensesnitt.

To egenskaper verdt å forstå før du bruker det:

• Samme salt alltid produserer samme korpus, så en delt korpus kan regenereres i stedet for å arkiveres.
• Hold salt hemmelig. Pseudonymer er avledet fra ekte verdier, så noen som holder salt kan bekrefte en gjetning om hvem en post refererer til.

19.5 Flytte meldinger for hånd

19.5.1 perfuse lytte

Aksepterer HL7 v2 over MLLP og bekrefter det. En mottaker som eksisterer så lenge du trenger det, for å bevise at en avsender kan nå denne maskinen overhodet.

19.5.2 perfuse send

Sender HL7 v2-meldinger over MLLP fra filer.

19.6 FHIR

19.6.1 perfuse fhir

Konverterer HL7 v2 til FHIR, validerer FHIR eller betjener det, avhengig av underkommandoen.

Valideringsunderkommandoen er nyttig på egen hånd: den vil fortelle deg om en ressurs noen sendte deg oppfyller US Core, som er profilen amerikanske regler er skrevet mot. Å kunne svare på det uten å adoptere en motor er poenget.

19.6.2 perfuse x12

Converts X12 (or other delimited EDI) to the XML Mirth Connect and Open Integration Engine write for it, and back: perfuse x12 xml FILE and perfuse x12 from-xml FILE, standard input when no file is given. The output is what OIE 4.6 writes, byte for byte, so it can be compared with what a Mirth server produced or fed to a system built against it. A channel does the same with x12.arrives_as: xml and a destination's x12_as: xml; see X12.

19.6.3 perfuse sof

Runs a SQL on FHIR ViewDefinition over FHIR files (the NDJSON of a bulk export, Bundles or JSON arrays; - for stdin) and writes the table: -view FILE (required), -format csv|ndjson|json|parquet (csv by default), -header=false, and -o FILE (required for Parquet). See SQL on FHIR views.

19.6.4 perfuse measure

Evaluere en kvalitetsmåling med FHIRPath-kriterier over FHIR-filer (NDJSON fra en bulk-eksport, Bundles eller JSON-arrays; - for stdin) og skriver MeasureReport. Flagger:

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

Se digitale kvalitetsmålinger.

19.6.5 FHIR-flagg på perfuse serve

Butikken beholder dokumenter samt ressurser: et dokument, en samling eller en meldingsBundle PUT til /fhir/Bundle/{id} beholdes hel, lest tilbake med hver enkelt post i utgaven som tilbys, og funnet ved type, identifier, timestamp og composition. En transaksjon PUT der beholdes som en post og ikke anvendes; en POST til /fhir anvender en.

Svar er JSON med mindre klienten ber om XML (Accept: application/fhir+xml, eller _format=xml). Perfuse leser kun JSON: en body sendt som XML får 415. En dokument-Bundle som er POSTet til /fhir beholdes når denne serveren innehar, ved identifikator, pasienten og møtet dens Komposisjon navngir, og avvist med 422 ellers. En Binary lesing med Accept satt til sin egen innholdstype svarer med innholdet selv.

19.7 Oppsett og drift

19.7.1 perfuse init

Oppretter kataloglayouten, et eksempelkanal og en tjenestedefinasjon for operativsystemet det kjøres på. Ingen eksisterende elementer erstattes med mindre du passerer -force.

perfuse init -dir /opt/perfuse -service systemd

19.7.2 perfuse service

Registrerer Perfuse som en Windows-tjeneste, fjerner den eller rapporterer om den er installert og kjører. Kun Windows; på Linux er ekvivalenten enhetsfilen perfuse init kan skrive for deg. Se drift.

19.7.3 perfuse token

Utgir legitimasjon for maskiner i stedet for mennesker. En token utløper ikke og påvirkes ikke av noen som logger ut, som en server som henter fra nabo trenger og som en nettlesersesjon bevisst ikke er.

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

Kun hashen lagres, så en token vises bare én gang når den opprettes og kan ikke gjenopprettes senere. En stjålet database gir derfor ingen brukbar token. Gi en token den laveste rollen som gjør jobben: en flåtevisning trenger viewer, og ingenting som bare leser skal holde noe mer.

-fhir-groups riverside-attributed,riverside-north begrenser en token til disse FHIR-gruppene, for en leverandørs CMS-0057 Provider Access-eksport: på FHIR-endepunktet kan den lese disse gruppene og eksportere dem, og ingenting annet. Se CMS-0057 for betalere.

19.7.4 perfuse athena

Skriver ut Amazon Athena CREATE EXTERNAL TABLE for en S3-arkiv skrevet med format: ndjson, ved å bruke partisjonsprosjeksjon på dt=YYYY-MM-DD-delen av nøkkelen, så ingen crawler trenger å kjøre når dager legges til.

perfuse athena -bucket hospital-arkiv -destination arkiv

Skrevet ut i stedet for å kjøres, fordi opprettelse av en tabell krever Athena- og Glue-tilganger som dette programmet ikke bør ha.

19.7.5 perfuse sbom

Lister opp alt som er koblet til binærfilen, lest fra byggingen selv i stedet for fra go.mod — så den beskriver binærfilen foran deg og ikke hva noen en gang ba om.

-json emitterer CycloneDX og -spdx emitterer SPDX tag-verdi, som vanligvis er hva en innkjøps- eller sikkerhetsgjennomgang faktisk ber om. Browserkoden som er innbygget i binærfilen er inkludert, fordi en gjennomganger som sammenligner en binærfil mot råd må vite at den inneholder en React-applikasjon.

19.7.6 perfuse versjon

Skriver ut versjonen og commit-en det ble bygget fra. Verdt å legge i en billett: "den nåværende" er ikke en versjon, og to maskiner som ble installert en uke apart er ofte ikke kjører samme bygging.

20 Serveralternativer

Hvert alternativ perfuse serve tar, generert fra programmet selv, så denne listen kan ikke navngi et alternativ som ikke eksisterer eller utelate ett. De fleste er også en innstilling i nettgrensesnittet, navngitt i siste kolonne: en verdi som er lagret der seirer over flagget ved neste start, og flagget forblir måten å sette det fra en tjenestedefinisjon. Lytteradressen, databasen og kanal-katalogen forblir bare flagg, fordi de sier hvor serveren finner hva den ville redigere.

Hemmeligheter er aldri flagg. Et alternativ som trenger en passord eller en token navngir en miljøvariabel som holder det.

20.1 Alle alternativer

21 Kanalkreferanse

Hver nøkkel som kan dukke opp på toppnivå i en kanalfil. Disse hentes fra kilde, så dette kapitlet kan ikke beskrive en valgmulighet som ikke finnes eller utelate en som gjør det.

21.1 Kanal

Kanal er en konfigurert meldingsflyt: et sted hvor meldinger ankommer, et valgfritt filter og ett eller flere steder de går.

Definert som Channel i internal/config.

21.1.1 navn

Navn identifiserer kanalen i logger og målinger.

Obligatorisk og unik.

21.1.2 gruppe

Gruppe er hva denne kanalen er en del av, for å organisere en liste som har vokst for lang til å lese.

Kosmetisk ved fem kanaler og strukturell ved to hundre: en steds kanaler deles av systemet de snakker til, eller av teamet som eier dem, og en flat liste av to hundre navn er ubrukelig uansett hvor god resten av grensesnittet er.

En vanlig streng i stedet for en gruppeobjekt med sin egen fil, fordi en gruppe ikke har noen atferd. Øyeblikket det får en fil tilegner det innstillinger, og innstillinger på en gruppe betyr at en kanals atferd avhenger av noe som ikke er skrevet i kanalen - som er egenskapen som gjør Mirth-konfigurasjon hard å forstå.

21.1.3 vedlegg

Vedlegg flytter store nyttelaster ut av meldingen og setter dem tilbake før levering.

Valgfritt per kanal: en strøm av rene ADT-meldinger har ingenting å trekke ut og bør ikke betale for maskineriet.

21.1.4 avgrenset

Avgrenset konfigurerer en avgrenset kanal.

Kun meningsfull når datatypen er avgrenset.

21.1.5 tabeller

Tabellnavn filer av felles kartleggingstabeller en transformasjon kan referere til ved navn.

Felles fordi domenetaksen i stor grad er å gjenskape en kartlegging noen allerede har gjort: en steds kjønnkoder og pasientklasser blir oversatt likt i hver kanal som berører dem, og en tabell inni en kanal er en tabell bare den kanalen kan bruke.

21.1.6 aktivert

Aktivert standarder til true.

En deaktivert kanal er lastet og valideres, men ikke startet, så en fil som midlertidig er av er likevel sjekket av CI.

21.1.7 datatypen

Datatypen er formatet på meldingene denne kanalen mottar.

Standard er hl7, så hver kanal skrevet før denne eksisterte fortsetter å fungere.

21.1.8 x12

X12 inneholder innstillingene som bare betyr noe på en X12-kanal.

Å sette det på noen andre typer nektes heller enn ignoreres.

21.1.9 skript

Skript konfigurerer en NCPDP SCRIPT-kanal.

Dets steg bor her heller enn i toppnivåets transformasjoner for samme årsak som hver andre ikke-v2-format gjør: steptypene varierer per format, så en nøkkel ville bety forskjellige ting avhengig av datatypen.

21.1.10 dicom

Bilde konfigurerer en DICOM-kanals navngitte transformasjonssteg.

Navngitt Bilde heller enn DICOM fordi Kilde og Destinasjon allerede har et DICOM-felt og tre felt med samme navn på forskjellige nivåer er hvordan noen setter feil felt. YAML-nøkkelen er dicom, som er hva en person som skriver filen forventer, og Go-navnet er det som stopper en feil på kallstedet.

21.1.11 filter

Filter er et uttrykk som må være gyldig for at en melding skal videreformidles.

En melding som ikke matcher blir likevel bekreftet: avsenderen gjorde ingenting galt, vi er bare ikke interessert.

21.1.12 transformasjoner

Transformasjoner er deklarative endringer som gjøres på aksepterte meldinger, i rekkefølge, før noen skript kjøres.

Dette er laget som skal bære den vanlige arbeidet: hvert steg valideres når filen lastes, vises i en diff og kan gjennomgås av noen som ikke leser JavaScript.

21.1.13 skript

Skript inneholder JavaScript for tilfellene de deklarative stegene ikke kan uttrykke, og er hva en Mirth-kanals egne skript dropper uendret inn i.

En kanal med et skript er merket som slik i grensesnittet, fordi dens atferd ikke kan fastslås ved å lese konfigurasjonen.

21.1.14 skygge

Skygge kjører en kandidatversjon av denne kanalen ved siden av og rapporterer hvor de forskjeller.

Ingenting den gjør kan nå en mottaker.

22 Kildehenvisning

Hver måte en kanal kan motta meldinger, og hver nøkkel hver enkelt aksepterer. En kanal har nøyaktig én kilde.

22.1 AMQP Kilde

AMQP Kilde mottar fra en kø eller abonnement.

En melding aksepteres bare etter at kanalen har behandlet den. En som ikke kunne behandles, utløses som en feilaktig levering, så brokeren redelerer den og - på Service Bus, forbi køens maksimum leveringsantall - dørkbrev den.

Definert som AMQPSource i internal/config.

22.1.1 prefetch

Prefetch er hvor mange meldinger brokeren kan sende i forveien.

Standard er 10. De behandles likevel én om gangen, i rekkefølge.

22.1.2 reconnect

Reconnect er ventetiden etter en tapt tilkobling.

Defaults to 5s.

22.2 AS2 Kilde

AS2 Kilde mottar AS2 (RFC 4130): EDI postet over HTTP, signert og kryptert med S/MIME, besvart med en kvittering (en MDN) som bærer en digest av hva som ankom.

Nyttelasten er hva kanalen behandler; X12 og EDIFACT er de vanlige.

Definert som AS2Source i internal/config.

22.2.1 path

Path er URL-stien partnere poster til.

Default /as2.

22.2.2 tls

TLS betjener HTTPS.

De fleste partnere krever det i deres avtale, i tillegg til S/MIME.

22.2.3 id

ID er vår AS2-identifikator, som partnere sender i AS2-To.

En melding til noen andre avvises.

22.2.4 partnere

Partnere er de som kan sende her.

En melding fra noen andre blir avvist.

22.2.5 duplikat_window

DuplicateWindow er hvor lenge en partners Message-ID huskes, så en melding som sendes igjen (partnern fikk aldri vår kvittering og prøvde igjen) blir besvart med en kvittering og ikke videreformidlet to ganger (RFC 4130 seksjon 7.5).

Default 30 days.

22.3 Azure Blob Kilde

AzureBlobSource henter blobs fra en container-prefiks.

Definert som AzureBlobSource i internal/config.

22.3.1 flytt_til

FlyttTil er hvor en behandlet blob flyttes.

Standard er prosessert/.

22.3.2 feil_prefiks

FeilPrefiks er hvor en blob som ikke kan behandles flyttes, så den ikke blokkerer resten.

Standard er feil/.

22.3.3 avhøringsintervall

Avhøringsintervall mellom listinger.

Defaults to 30s.

22.3.4 maks_objektstørrelse

MaksObjektStørrelse avviser en større blob, som blir liggende der den er.

Standard er 16 MiB.

22.4 Meglertype Kilde

BrokerSource leser meldinger fra en meldingsmegler.

Mirths JMS-leser, nådd over STOMP fordi JMS er en Java-API og ikke et protokoll. Se internal/stomp for hvorfor STOMP og ikke OpenWire.

Definert som BrokerSource i internal/config.

22.4.1 adresse

Addr er vertens host og port.

Påkrevd. 61613 er den vanlige STOMP-porten.

22.4.2 mottaker

Mottaker er køen eller temaet som leses fra.

Required.

Mellomleddene staver disse forskjellig - /queue/navn på ActiveMQ, et bart navn på RabbitMQ - så det sendes gjennom uendret i stedet for å bli sammensatt her. Å gjette ville bety å arbeide mot ett mellomledd og stille lese ingenting på et annet.

22.4.3 logg inn

Logg inn og passord autentiserer.

De fleste mellomleddene avviser en anonym tilkobling.

22.4.4 passord

Logg inn og passord autentiserer.

De fleste mellomleddene avviser en anonym tilkobling.

22.4.5 vert

Vert er den virtuelle verten.

Standard er adressens vert.

22.4.6 velger

Velger filtrerer meldinger på mellomleddet.

En JMS-velger, sendt gjennom i stedet for å bli tolket. Filtrering på mellomleddet i stedet for her betyr at meldingene denne kanalen ikke ønsker, aldri krysser nettverket - som på en delt kø er forskjellen på å lese hundre meldinger om dagen og hundre tusen.

22.4.7 abonnements_id

AbonnementsID navngir abonnementet.

Standard er kanalnavnet.

Navngitt i stedet for generert, fordi et varig abonnement identifiseres av det: et generert ville opprette et nytt abonnement ved hver omstart og la de gamle samle opp meldinger ingen leser.

22.4.8 hjerteslag

Hjerteslag holder tilkoblingen i live.

Standard er tretti sekunder.

På som standard her, i motsetning til klientens egen standard, fordi en kilde holder en tilkobling åpen i uker. Uten hjerteslag ser en tilkobling gjennom en brannmur som stille har droppet ruten ut perfekt sunn fra denne enden, og meldingene stopper bare, uten at noe logges.

22.4.9 reconnect

Gjenkobling er hvor lenge å vente før gjenkobling etter en feil.

Standard er fem sekunder.

22.4.10 tidsavbrudd

Tidsavbruddsgrenser for tilkobling.

Standard er tretti sekunder.

22.5 DICOM-spørringskilde

DICOMQuerySource spør en arkiv med C-FIND og sender en melding per ny studie.

Mirth har ingen tilsvarende connector. Dets DICOM-støtte er en lytter og en sender - den kan motta bilder som sendes til den og sende dem videre, og det er alt. Å spørre et arkiv hva det inneholder har vært forespurt på deres forum siden 2015.

Hva som gjør det verdt å ha er ikke spørringen, det er automatiseringen: en forhåndshenting som kjører klokken tre om morgenen, en avstemming som legger merke til at arkivet mangler en studie som RIS sier eksisterer, en arbeidsliste bygget fra hva som faktisk ble skannet i stedet for hva som ble bestilt. Disse er jobber som steder i dag gjør med et planlagt skript utenfor motoren, noe som betyr at de er usynlige for den - ingen gjenprøvninger, ingen varsling, ingen meldingslogg.

Definert som DICOMQuerySource i internal/config.

22.5.1 adresse

Adresse er arkivets vert og port.

Required.

Navngitt for å matche DICOM-destinasjonen i stedet for forkortet. De to var "adresse" og "addr" en ettermiddag, noe som er den type inkonsistens noen som skriver en kanal-fil for hånd får feil en gang og deretter mistenker hele formatet over.

22.5.2 called_ae

CalledAE er arkivets AE-tittel.

Obligatorisk i praksis: de fleste arkiver avviser en assosiasjon adressert til noe annet, og den avvisningen leser som et driftsavbrudd i stedet for som en konfigurasjonsfeil.

22.5.3 calling_ae

CallingAE er AE-tittelen Perfuse presenterer.

Arkiver bruker den ofte for tilgangskontroll.

22.5.4 nivå

Nivå er spørringsnivået: PASIENT, STUDIE, SERIE eller BILDE.

Standard er STUDIE.

STUDIE er standard fordi det er hva nesten alle nyttige spørringer ønsker, og fordi alternativene overrasker folk: BILDE-nivå mot en stor CT returnerer en respons per skive, som er hundrevis per studie.

22.5.5 match

Match er spørringstastene.

En verdi filtrerer; en tom verdi ber om feltet skal returneres.

Nøklene er navngitt i stedet for nummerert - "PatientID" ikke "0010,0020" - fordi en kanal-fil leses av mennesker, og en tag-nummer i en konfigurasjonsfil er en oppslag hver lesere må utføre.

22.5.6 returner

Return-felt er felter som skal returneres uten filtrering på dem.

Separat fra Match med en tom verdi, selv om de kodar identisk, fordi intensjonen er forskjellig og en leser kan se hvilke nøkler som begrenser søket og hvilke som samles inn.

22.5.7 intervall

Intervall er hvor ofte polling skal utføres.

Required.

22.5.8 vindu

Vindu er hvor langt tilbake hver polling ser, som et studie-datoområde.

Null deaktiverer dato-filtrering helt.

Et vindu er det som holder dette begrenset. Uten ett, spør hver polling arkivet om alt det har holdt noen gang og kaster så bort hva det har sett før - noe som fungerer på et testarkiv og er usosialt mot et virkelig arkiv som holder millioner av studier.

22.5.9 overlapp

Overlapp gjentar spørringen så langt inn i allerede polla perioden.

Standard er en time.

Nødvendig snarere enn forsiktig. Et studie kan registreres med gårsdagens dato, vår klokke og arkivets trenger ikke å være enige, og en poll-grense som samsvarende med en ankomst mister den. Overlapp-spørringen gjentar, og allerede sett-sjekken stopper duplikatet - så kostnaden av overlapping er en litt større spørring og kostnaden av ikke å overlappe er et stille misset studie.

22.5.10 begrensning

Begrensning begrenser antall treff akseptert fra en polling.

Defaults to 500.

En begrensning snarere enn ingen begrensning fordi en feilskrevet match-nøkkel gjør dette til "gi meg alt", og det første symptomet på det mot et virkelig arkiv er arkivets administrator som spør hvem som banker på det.

22.5.11 tidsavbrudd

Tidsbegrensning begrenser en polling.

Standard er to minutter.

22.5.12 emit_on_first_poll

EmitOnFirstPoll sender meldinger for alt det første pollinget finner.

Standard er false.

False betyr noe. Å peke dette mot et arkiv som allerede holder en million studier og få det til å sende en melding for hver er ikke en nyttig første kjøring, og det er den type feil som merkes nedstrøms snarere enn her. Første polling registrerer hva som finnes og sender ingen melding; andre polling og utover rapporterer hva som er nytt.

22.6 DICOM-kilde

DICOM-kilden mottar bildeobjekter som en C-STORE-tjenesteklasse-tilbyder.

Hva et sykehus peker en modalitet eller et PACS mot. Mirth kaller dette DICOM-lytteren og det gjør C-STORE bare, så dette er likhet snarere enn en undermengde.

Definert som DICOMSource i internal/config.

22.6.1 lytter

Lytt er adressen som betjenes på.

Obligatorisk. 104 er den registrerte DICOM-porten; 11112 er den vanlige alternativet der binding av en privilegert port ikke er mulig.

22.6.2 ae_title

AETitle er hva denne endepunktet kaller seg selv.

Sterkt anbefalt i stedet for obligatorisk, og advart om når fraværende. En steds eneste tilgangskontroll på et DICOM-endepunkt er ofte AE-tittelen, så et endepunkt som aksepterer alle titler aksepterer alt som kan nå det.

22.6.3 allowed_calling_ae

AllowedCallingAE lister AE-tittlene som er tillatt å koble til.

Tomt aksepterer alle kallere.

Dette er tilgangskontrollen DICOM faktisk har. En PACS er vanligvis konfigurert til å akseptere en navngitt kalltittel og avvise alt annet, og denne enden hadde ingen ekvivalent: den kalte tittelen ble sjekket - som er navnet kalleren ringer, så hvem som helst kan sende det riktig - mens hvem som ringte ble logget og ellers ignorert.

Tomt aksepterer fortsatt alt, fordi en modalitet ingen har listet er den normale tilstanden for en første installasjon og å nekte som standard ville bryte hver enkelt distribusjon på dag én. Den advarer i stedet, og advarselen navngir tittelen som har koblet til så noen kan fylle denne inn fra hva som faktisk ankom.

22.6.4 sop_classes

SOPClasses begrenser hvilke typer objekter som aksepteres.

Tomt aksepterer alle.

Tomt er en rimelig standard her fordi denne motoren videreformidler objekter i stedet for å tolke dem, så å nekte en ukjent klasse ville nekte gyldige bilder uten noen fordel.

22.6.5 transfer_syntaxes

TransferSyntaxes begrenser kodningene som aksepteres, i preferanseorden.

Tomt aksepterer de ukomprimerte tre.

22.6.6 max_object_bytes

MaxObjectBytes begrenser ett mottatt objekt.

Null anvender en standard.

22.6.7 idle_timeout

IdleTimeout lukker en assosiasjon som har gått stille.

Null betyr aldri, som vanligvis er riktig - en modalitet holder en assosiasjon åpen mellom studier.

22.6.8 tls

TLS krypterer innkommende assosiasjoner og kan kreve en klient sertifikat.

Verdt å si rett ut: Mirth trenger sin betalte SSL Manager-utvidelse for dette, og community-forkene kan ikke leveres med det i det hele tatt. DICOM inneholder pasientnavn i metadata, så dette er ett av stedene hvor å være en omskrivning heller enn en fork er en reel fordel heller enn en stilistisk en.

22.7 DICO Mweb Kilde

DICOMwebSource aksepterer STOW-RS-forespørsler.

Definert som DICOMwebSource i internal/config.

22.7.1 lytter

Lytt er adressen som betjenes på.

Required.

22.7.2 path

Sti er tjenestens rot.

Objekter aksepteres på Sti/studier og Sti/studier/{uid}. Standard er /dicom-web, som er hva Orthanc og dcm4chee bruker, så en avsender konfigurert for noen av dem trenger bare å endre verten.

22.7.3 token

Token, når det er satt, er påkrevd som en bærertoken.

Brukernavn og passord krever HTTP-basisk autentisering.

22.7.4 brukernavn

Token, når det er satt, er påkrevd som en bærertoken.

Brukernavn og passord krever HTTP-basisk autentisering.

22.7.5 passord

Token, når det er satt, er påkrevd som en bærertoken.

Brukernavn og passord krever HTTP-basisk autentisering.

22.8 Database Kilde

DatabaseSource leser rader fra en database og omdanner hver enkelt til en melding.

Dette er hvordan en stor del av hospitalgrensesnitt faktisk starter. Et avdelingssystem har ingen HL7-kapasitet, så noen skriver rader inn i en midlertidig tabell og grensesnittsmotoren poller den. Det er ikke glamorøst, og det er overalt.

Det er også den vanligste måten en Mirth-kanal blokkerer, og årsaken er nesten alltid av samme form: en rad som ikke kan prosesseres, leses, feiler og leses igjen, for alltid, fordi ingenting markerte den. Kanalen ser levende ut. Køen ser tom ut. Ingen bevegelse, og hver melding bak den dårlige raden venter på en rad som aldri vil lykkes.

Det meste av designet her handler om det.

Definert som DatabaseSource i internal/config.

22.8.1 sjåfør

Sjåfør navngir databasen.

See SupportedDrivers.

22.8.2 dsn

DSN er tilkoblingsstrengen.

Foretræk et miljøvariabelreferanse over en bokstav, fordi dette vanligvis inneholder en passord og kanaler er ment å være i git.

22.8.3 spørring

Spørring velger radene som venter på å bli sendt.

Required.

Den må være en SELECT. En avstemming som stille utfører skriver vil kjøre på en plan med ingen rekord av hva den endret.

22.8.4 etter_spørring

EtterSpørring markerer en rad som prosessert, og kjører med radens nøkkel bundet til den.

Strongly recommended.

Uten dette, gjentar hver avstemming hver rad spørringen fortsatt matcher, så spørringen selv må ekskludere prosesserte rader på en annen måte. Hvis ingen av dem er sann, sender kanalen de samme radene for alltid, hvilket er en duplikatstorm i stedet for en blokkering og er kanskje verre.

22.8.5 nøkkelkolonne