1 Johdanto

Perfuse siirtää kliinisiä viestejä järjestelmien välillä, jotka eivät ole suunniteltu puhumaan toistensa kanssa. Laboratorio lähettää tuloksia HL7 v2: n avulla; potilastietojärjestelmä odottaa niitä eri kenttäkohtaisilla tiedoilla, eri potilastunnisteella ja vahvistuksella viiden sekunnin kuluessa. Jotain on istuttava väliin, ja se jotain on integraatio moottori.

Tämä käsikirja kuvaa, mitä Perfuse tekee, kaikki sen ominaisuudet ja - mikäli päätös ei ole ilmeinen - miksi se toimii tietyllä tavalla.

1.1 Miksi Perfuse on olemassa

Yksittäinen rajapinta kahden kliinisen järjestelmän välillä on yleensä hinnoiteltu kymmenissä tuhansissa, ja 15-20 prosenttia siitä vuosittain ylläpitoon. Suurin osa tästä kustannuksesta ei ole työ; se on, että työ vaatii jonkun, joka on aiemmin työskennellyt HL7: n parissa, ja useimmat sairaalat eivät palkkaa sellaista henkilöä.

Perfuse on rakennettu oletuksella, että sen konfiguroiva henkilö on ongelma, jota hänen on ratkaistava, eikä hänellä ole aiempaa kokemusta HL7: stä. Tämä oletus näkyy tietyissä kohdissa:

• Kaikki on konfiguroitavissa verkkokäyttöliittymästä. Ominaisuus, joka on saatavilla vain terminaalista tai käsin muokatusta tiedostosta, kohdellaan virheenä, ei suunnittelupäätöksenä.
• Viestejä voidaan jäljittää yksi muunnos kerrallaan, näyttäen, mitä kunkin vaiheen lukija luki, mitä se muutti, mitä se ohitti ja miksi.
• Testiliikennettä voidaan generoida, joka vastaa oikean syötteen muotoa ilman sen tietoja.
• Kanava voidaan ehdottaa yhdestä näyteviestistä, jossa on selkeä ilmoitus siitä, mitä näyte ei voi kertoa.
• Ennen kuin olemassa oleva moottori korvataan, sen tulosteen ja Perfuse- tulosteen voidaan vertailla viesti viestin, ja erot ryhmitellään kenttäkohtaisesti.

1.2 Mitä siinä on

Kaikki alla oleva on yhdessä binääritiedostossa. Kunkin rivin nimi on luku, joka kattaa sen.

• Muodot. HL7 v2, FHIR R4, R4B ja R5, DICOM, X12 (837, 835, 270/271, 276/277, 834, 278, 275), C-CDA ja CDA, HL7 v3, NCPDP Telecommunication ja SCRIPT, SMART Health Links ja Cards, rajatut ja raakamuodot. Katso viestin muodot.
• Liitännät. 28 lähde- ja 32 kohdetyyppiä, muun muassa MLLP, tiedostot, SFTP, tietokannat, DICOM, Kafka, AMQP 1.0, MQTT, IBM MQ ja AWS-, Azure- ja Google Cloud -tallennus ja viestintä. Katso lähdeviite ja kohdeviite.
• Viestien muuttaminen. Suodattimet, yksitoista deklaratiivista muunnosvaihetta, JavaScript (Mirthin murre mukaan lukien) ja Lua, jaettavat koodaus- ja muunnostaulukot sekä muunnosehdotukset. Katso suodattaminen ja muunnos.
• Viestien toimittaminen. Luotettava, järjestetty jonotus kullekin kohteelle, uudelleenyritykset, kuolleet kirjeet, jotka säilyttävät viestin, ja vahvistukset, jotka lähetetään toimituksen jälkeen. Katso toimitus ja vahvistukset.
• Järjestelmän valvonta. Hallintapaneelit, tiimihallintapaneelit, prosessikartta, yksitoista hälytystyyppiä, mittaukset, jäljitys ja viestivarasto, joka löytää potilaan viestit eri muodoissa. Katso hälytykset, viestivarasto ja vianmääritys.
• Live-rajapinnan muuttaminen turvallisesti. Varjorajapintamuoto, syöte sopimukset, kanavatestit ja moottorin vertailu. Katso testaus.
• Poistuminen Mirthistä. Mirth, Open Integration Engine ja BridgeLink -kanavat selitetty, käännetty ja viety takaisin. Katso siirtymä Mirthistä.
• Maksajat ja kansanterveys. Neljä CMS-0057 -rajapintaa, Da Vinci CRD, DTR, PAS, PDex ja Plan-Net, CARIN Blue Button, valinnainen päätöspalvelu, eCR ja ELR. Da Vinci CRD, DTR ja PAS vastaavat sekä 2.2.x - että 2.1.0 -julkaisuja. Katso CMS-0057 maksajille.
• Kuka saa tehdä mitä. SAML, OpenID Connect, LDAP, avaimet, SCIM, vastavuoroinen TLS, kuusi roolia, kanavaryhmät roolilla kussakin, vuokralaiset, SMART -valtuutuspalvelin, TEFCA ja UDAP sekä kirjausloki. Katso turvallisuus.
• Järjestelmän suorittaminen. Yksi staattinen binääri Linuxille, macOS:lle ja Windowsille, palveluna, useiden palvelinten laivuekatsauksella. Katso toiminnat, web-käyttöliittymä, komentorivi ja palvelinvaihtoehdot.

1.3 Standardit ja versiot

Mikä Perfusen toteuttama standardin julkaisu on ja miten se on tarkistettu. "Tarkistettu" nimeää ulkoisen työkalun tai viiten, joka arvioi tuloksen; jos mitään ulkopuolista ei ole arvioinut sitä, se sanoo niin. Tulokset ovat testidatalta, ei tuotantopaikalta.

1.3.1 Viestintä ja asiakirjat

1.3.2 FHIR -toteutusoppaat

1.3.3 Kansalliset ja eurooppalaiset profiilit

Tarkistettu muuttamalla julkaistuja tai keksittyjä HL7 v2 -viestejä ja vahvistamalla jokainen resurssi; koko tulokset ja epäonnistumisen syyt ovat conformance/national -kansiossa.

Mitään tätä ei ole sertifioitu. Perfuse ei ole saanut sertifikaatteja ONC:ltä, CMS:ltä, gematikilta, Nictizilta, NHS Englandilta tai keltäkään muulta.

1.4 Mitä se korvaa

Perfuse kattaa Mirth Connectin alueen, ja se voi tuoda Mirth-kanavaviennit suoraan. Luku siirtymä Mirthistä kuvaa, mitä käännetään puhdasesti, mitä tarvitsee päätöksen ja miten todistaa tulos ennen siirtymistä.

Ero, joka on merkittävä päivittäisessä käytössä, on virheenjäljitys ja hiljaisuus. Mirthissa nähdä, mitä transformer teki viestiin, yleensä tarkoittaa kanavan uudelleenjulkaisemista lokien kanssa. Perfusessa jokainen tallennettu viesti voidaan toistaa nykyisen konfiguraation kautta ja tarkastella vaihe vaiheelta ilman koskettavaa suoritetta olevaa kanavaa. Ja siinä, missä Mirth-hälytys "ei liikennettä" on kiinteä kynnysarvo, joka on hyödytön missä tahansa syötteen, joka on hiljainen yöaikaan, Perfuse oppii, miltä kunkin syötteen normaali viikko näyttää, ja hälyttää sitä vastaan.

1.5 Miten tämän käsikirjan lukeminen

Ensimmäiset luvut ovat käsitteellisiä ja niiden on arvoista lukea järjestyksessä: kanavat, viestivirtaus, sitten muunnos. Kaikki muu voidaan lukea tarpeen mukaan.

Viittausluku lopussa listaa jokaisen konfiguraatioavaimen, sen tyypin, onko se pakollinen ja sen oletusarvon. Nämä luvut generoidaan lähdekoodista, joten ne eivät voi kuvailla valintaa, jota ei ole olemassa, tai jättää pois yhtään, joka on olemassa. Jos avain näkyy konfiguraatiotiedostossa, mutta ei hakemistossa, se ei ole Perfuse-avain.

1.6 Konventiot

Konfiguraatio on YAML. Useimmat avaimet ovat snake_case -muodossa viestintäyhteydessä — max_message_size, idle_timeout — ja tämä käsikirja antaa aina viestintäyhteyden muodon, koska se on se, mitä kirjoitat. On yksi vanha poikkeus, dataType kanavalla, joka on camelCase; se on dokumentoitu sillä tavalla kanavaviitteessä ja hyväksytään vain sillä oikeinkirjoituksella.

Kenttäviittaukset HL7:ssä käyttävät tavallista merkintätapaa: PID-5 on PID-segmentin viides kenttä, PID-5.1 sen ensimmäinen komponentti ja PID-3(2) kolmannen kentän toinen toisto. Polku, joka on kirjoitettu ilman toistoa, osoittaa jokaisen toiston (ks. polut)

Kestot kirjoitetaan numerona ja yksikkönä — 30s, 5m, 2h. Paljas numero ei ole kesto, ja se hylätään sen sijaan, että se arvataan.

2 Käynnistäminen

Perfuse on yksittäinen binääri, jossa on sisäänrakennettu web-liittymä. Siinä ei ole sovelluspalvelinta, joka pitäisi asentaa, tietokantaa, joka pitäisi määritellä, eikä erillistä hallintaliittymää.

2.1 Suorittaminen

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

-channels on hakemisto YAML-tiedostoja, yksi tiedosto kunkin kanavan mukaisesti. -db on SQLite-tiedosto, joka sisältää tallennetut viestit, käyttäjät ja auditointihistorian; se luodaan, jos sitä ei ole olemassa.

Kun käynnistetään ensimmäisen kerran ilman määritellyjä käyttäjiä, luodaan ylläpitäjätili, ja sen salasana kirjoitetaan lokitietoihin kerran. Salasanaa ei voi palauttaa myöhemmin.

2.2 Ensimmäinen kanava

Kanavalle tarvitaan nimi, lähde ja vähintään yksi kohde. Pienin hyödyllinen kanava vastaanottaa HL7-viestin MLLP:llä ja kirjoittaa jokaisen viestin tiedostoon:

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

Tallenna se nimellä channels/first-feed.yaml ja se otetaan käyttöön ilman uudelleenkäynnistystä.

Kolme asiaa siinä tiedostossa on huomionarvoista, koska ne ovat jokaisen kanavan muotoa:

• Lähdelohko on tasainen MLLP:lle. listen sijaitsee suoraan source:n alla, eikä sisällä source.mllp-lohkoa. Siirtoprotokollat, jotka tarvitsevat enemmän kuin osoitteen — HTTP, SOAP, DICOM — ovat omassa alilohkossaan, ja ne on lueteltu lähdeviitteessä.
• Tiedostokohteelle tarvitaan sekä root että dir. root on raja, jota vasten polut ratkaistaan eikä sitä voi ylittää; dir on sijainti, mihin viestit laskeutuvat sen sisällä.
• Muodonmuutosta tai suodatinta ei ole. Molemmat ovat valinnaisia, ja kanava, jolla ei ole kumpaakaan, välittää viestit suoraan läpi.

2.3 Kanavan rakentaminen liittymästä

Kaikki edellä mainittu voidaan tehdä web-liittymästä, ja ensimmäisen kanavan osalta se on parempi reitti, koska lomake ei salli virheellisen tiedoston luomista.

Rakentaja tarjoaa kolme tapaa aloittaa:

1. Joltain, joka on lähettänyt viestin. Liitä näyte, jonka laboratorio tai myyjä on lähettänyt. Perfuse lukee sen ja ehdottaa kanavaa, sekä kolmea erillistä luetteloa: mitä näyte osoittaa, mitä on arvioitu ja mitä mikään näyte ei voi kertoa. Tämä on kuvattu testauksessa.
2. Joltain, joka jo toimii. Täydellinen kanavojoukko, jolle tarvitaan vain osoitteen täyttäminen.
3. Tyhjästä. Tyhjä lomake. Se on käytettävissä, mutta se on hitain kolmesta ja helpoin väärä.

2.4 Varmistaminen, että se toimii ennen kuin mitään yhdistetään

Kaksi asiaa voidaan tehdä ennen kuin lähettävä järjestelmä on olemassa.

Lähetä viesti käsin liittymästä — viestilähettäjä hyväksyy liitettyä tekstiä ja raportoi, mitä tapahtui sille, mukaan lukien, mitkä kohteet hyväksyivät sen, ja mitä kunkin muunnos teki.

Tai generoi testiliikennettä. Jos kanava on käsitellyt yhtään viestiä, Perfuse voi oppia niiden muodon ja tuottaa enemmän viestejä samanlaisilla osuuksilla, ilman alkuperäistä sisältöä. Katso testaus.

2.5 Mitä tehdä seuraavaksi

• Kanavat selittää, mitä kanava on ja miten sen osat sopivat yhteen.
• Viestivirtaus seuraa yhtä viestiä saapumisesta toimitukseen, mikä on nopein tapa ymmärtää, minne muutosta tehdään.
• Hälyttäminen on arvoista asettaa ennen kuin syöte menee liveen, eikä vasta ensimmäisen tapauksen jälkeen.

3 Web-käyttöliittymä

Perfuse on rakennettu oletuksella, että kaikki on tehtävissä selaimesta, ja ominaisuus, jota voidaan käyttää vain muokkaamalla tiedostoa, kohdellaan virheenä. Tässä luvussa esitellään, mitä kunkin navigoinnin osan taustalla on, järjestettynä käyttöliittymän mukaisesti: kysymyksen mukaan.

Ylätunniste sisältää Pääsivun ja Kanavat suoraan, koska ne ovat siellä, missä useimmat istunnot alkavat ja loppuvat. Kaikki muu on ryhmitelty, ja ryhmät on nimetty kysymysten mukaan eikä alajärjestelmien mukaan — et mene "lokiin", vaan etsit, kuka muutti jotain.

3.1 Ylätunnisteen lukeminen

Viisi asiaa otsikossa on helppo missata.

Jokaisella näkymällä on osoite. Osoiterivi seuraa näkymää — #/channels, #/messages, #/settings — joten lataus palauttaa sen, kirjanmerkki avaa sen, linkki lähetetty kollegalle avaa sen ja edellinen-painike siirtää näkymien välillä sen sijaan, että poistuisi konsolista. Osoite, joka nimeää näkymän ylemmän roolin, avaa kojussa dashboardin sen sijaan.

Haku, tai ⌘K. Se hakee kanavien, asetusten, viestien ja käyttöohjeen yli, mikä tarkoittaa, että se on yleensä nopeampi kuin navigointi — erityisesti asetukselle, jonka nimeä et muista.

Teema. Kolme niitä: Midnight, Dark ja Light. Midnight on lähes musta ja se on se, mitä palvelimen huoneen seinällä oleva näyttö yleensä haluaa; Dark on pehmeämpi neutraali harmaa; Light on kannettavalle tietokoneelle ikkunan vieressä. Valinta tallennetaan selaimessa eikä tilille, koska teema on istumapaikan ominaisuus, eikä henkilön ominaisuus — sama operaattori haluaa Midnightin seinällä ja Lightin junassa. Koneen oma mieltymys kysytään kerran, jotta voidaan valita järkevä oletus ensimmäisen kerran.

Kieli. Konsoli on saatavilla englanniksi (Iso-Britannian tai Yhdysvaltain päivämääräjärjestys), saksaksi, ranskaksi, hollanniksi, espanjaksi, italiaksi, portugaliaksi, puolaksi, ruotsiksi, tanskaksi, norjaksi tai suomeksi, ja päivämäärät ja numerot kirjoitetaan kyseisen kielen mukaisesti. Valinta tallennetaan selaimen muistiin, ja selaimen oma kieli käytetään, kunnes toisin valitaan. Käännökset on tehty koneella, eivätkä ne ole vielä native puhujien tarkastamia; englanti on viitekieli, ja kielen valitsin ilmoittaa tästä. Koodi, viestit, payloadit, kanavnimet ja mitä tahansa kirjoitettua tekstiä ei koskaan käännetä. Käsikirja on julkaistu samoisilla kielillä osoitteessa https://perfuse.health/manual/<language>/ (tämän palvelimen oma Käsikirja on englanninkielinen).

Käyttöohje. Asiakirja, jota luet, palvelimelta. Se on sama tiedosto, jonka binääri voi kirjoittaa levylle, joten se kuvailee aina version, joka on edessäsi, eikä viimeisintä julkaisua.

3.2 Valvonta — toimii, ja mitä tapahtui

3.2.1 Pääsivu

Jokaisen kanavan tila, läpipääsy ja kaikki, mikä on parhaillaan vikana. Tämä on ruutu, joka pitäisi jättää auki.

3.2.2 Viestit

Jokainen viesti, joka saapui, mitä se muutettiin, kohdekohtaisesti, ja mitä tapahtui sille. Haettavissa, myös suodatinlausekkeen avulla, joten "näytä minulle ne, jotka tulivat tästä lähettäjästä ja jotka hylättiin" on kysely eikä iltapäivä.

Viesti voidaan toistaa täältä, ja käsitellä uudelleen *nykyisen* konfiguraation kautta eikä siitä, joka oli voimassa silloin, kun se menee rikki — joka on tapa vahvistaa, että korjaus toimii liikenteen kanssa, joka murskasi sen. Katso viestivarasto siitä, mitä säilytetään ja kuinka kauan.

3.2.3 Jono

Mitä odottaa toimitusta, ja miksi. Jonotus, joka ei tyhjene, on yksi eniten hyödyllinen varhainen varoitus, jonka integraatiomoottori tuottaa, ja se on arvoista paria hälytysääntöön, jotta kukaan ei tarvitse olla katsomassa. Katso toimitus.

3.2.4 Hälytykset

Mitä on tapahtunut ja mitkä ovat säännöt. Säännöt muokataan täällä eikä tiedostossa. Katso hälyttäminen.

3.2.5 Mittaukset

Läpipääsy, viive ja virheiden määrä ajan myötä. Hyödyllistä kapasiteetin kysymyksiin ja useammin hallitusten pakkauksiin — josta syystä sivuston oma logo näkyy siinä, jos se on ladattu.

3.2.6 SQL FHIR:llä

SQL FHIR-näkymillä: valitse esimerkki tai tallennettu näkymä, tai kirjoita se, suorita se tämän palvelimen FHIR-varastossa (kaikki potilaat tai yksi) tai resursseilla, jotka on liimattu, näe rivit niiden tyypeillä ja lataa CSV, NDJSON tai Parquet. Tallenna säilyttää sen FHIR- päätepisteen $sql-run. Katso viestin muodot.

3.2.7 Laadun mittarit

Digitaaliset laatuindikaattorit: valitse esimerkki tai Mittaus FHIR-kaupasta, tai kirjoita yksi FHIRPath-kriteerien kanssa. Valitse mittausaika ja raportti (yhteenveto, yhteenveto potilasluetteloineen tai yksi potilas) ja arvioi se FHIR-kaupan tai liimatuissa resursseissa. Näytössä näkyy kunkin väestön määrä ja potilaat, pisteet ja strata. Lataa MittausRaportti tallentaa FHIR-tuloksen, ja Tallenna FHIR-kauppaan pitää Mittauksen Measure/$evaluate-measure. Mittaukset CQL: ssä ovat kiellettyjä: Perfusella ei ole CQL-moottoria. Katso digitaaliset laatuindikaattorit.

3.2.8 Virtauskartta

Kuva siitä, miten viestit todella liikkuvat: mitkä lähteet syöttävät mitä kanavia, ja mitä kohteita ne saavuttavat.

Sen arvo ei ole koristelu. Jokainen kiinteistö kertyy kanava, jota kukaan ei muista komissionneensa, ja kohde, jota kukaan ei tajunnut olevan edelleen vastaanottamassa, ja molemmat ovat näkyvissä täällä tavalla, jota ei ole kanavatiedostojen luettelossa.

3.2.9 Tiimien kojut

Koju kullekin viestintätyypille: Toiminta, Yhteydet, Rajapintanalysti, Ennakkovaraukset, Kuvantaminen, Tuloverkko, Laboratorio, Tietosuojelu ja turvallisuus, ja yksinkertainen osastoyhteenveto. Laatat näyttävät määriä, tiloja ja aikoja, ei koskaan viestiä tai potilasta, joten koju voidaan siirtää johtajalle tai seinänäyttöön ilman potilastietojen laajentamista.

Jokainen henkilö avaa kojun, joka on hänen hakemistoryhmälleen tai roolilleen annettu. -dashboards dashboards.yaml kartoittaa ne:

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

Ryhmä voittaa roolin, ja kuka tahansa, joka ei ole ryhmässä, avaa Toiminnan. Järjestä laattoja piilottaa ja uudelleenjärjestää laattoja, kanava-valitsin suodattaa niitä, ja Tallenna omaksi näkymäksi säilyttää sen omaksi kojuksi, kunnes Palauta.

Vie Grafaaniin lataa kojun Grafaani-JSON-muodossa /metrics-kautta, data-lähteen muuttujalla ja kanava-suodattimella, kaikille, jotka tarvitsevat enemmän kuin kevyen konfiguraation. Laatat, joilla ei ole mittaus-taustaa, jätetään pois, ja viennin kuvaus nimeää ne.

Yhteydet-laatta tarkistaa jokaisen verkkoyhteyden kohdekerroksissa. Se etsii nimen, avaa TCP-yhteyden, suorittaa TLS: n, missä se on käytössä, ja lukee kohdekohtaisen viimeisen toimituksen ja epäonnistumisen oikeasta liikenteestä. Kunkin epäonnistumisen selitys esimerkiksi "hylätty: kohdeympäristön moottori on todennäköisesti pysähtynyt", "ajasta umpeutunut: palomuuri tai VPN-tunneli, joka on alas" tai "varmenne, jonka tämä palvelin ei luota". Mitään ei lähetetä kumppanille, yhdellä poikkeuksella: immunisaatiorekisteri, jolla ei ole ollut liikennettä seitsemään päivään, pyytää CDC: n connectivityTest, joka ei lähetä mitään. -vpn tunnels.yaml VPN-tunnelit-laatta sen vieressä lukee kunkin kumppani-tunnelin tilan AWS Site-to-Site VPN: stä, Azure VPN Gateway -yhteydestä tai strongSwanista tämän isäntäjärjestelmän yli, jotta aikakatkaisu voidaan erottaa tunnelista, joka on alas. Se vertailee myös molempien osapuolten IKE- ja IPsec-asetuksia, koska pilvi raportoi meidän ja tiedosto listaa heidän, ja sanoo, missä ne eivät voi olla samaa mieltä. Yhteysarkki lataa kumppanin asetukset vierekkäin Markdown-muodossa lähettämistä varten; se ei koskaan sisällä jaettua avainta. Luvut, joita koju tarvitsee, eivät ole tallennettu, ne luetellaan Mittaus ei tehty vielä -sijaan tyhjien laattojen piirrostavan sijaan.

Osastokojusta lasketaan omat luvut palvelimella, ja kunkin se kertoo, mikä ikkuna ja lähde se kattaa:

• Ennakkohyväksyntä: PAS-pyynnöt päätettiin CMS-0057:n 72 tunnissa (kiireellinen) tai 7 päivässä (vakaa), myöhässä, odottavat ja myöhässä nyt, sekä mediaani-aika päätöksen tekemiseen. Myös miten pyydetyt palvelut hyväksyttiin (hyväksytty, muutettu, hylätty, odottava), kuten ne ovat nyt, 30 päivän ajan.
• Kuvantaminen: C-STORE-palvelimelle vastaanotetut objektit kunkin laitteen mukaan ja ne, joita ei toimitettu. Myös reititysviive kanavaa kohden (mediaani ja 95. prosentti), C-FIND-kyselyt ja epäonnistumiset kunkin kyselykanavan mukaan, sekä kuvantamisraportit (ORU, jonka OBR-24 on kuvantamisjakso, tai MDM), jotka eivät ole saapuneet kaikkiin kohteisiin.
• Tuotantokierros: 999 transaktiokokoonpano hyväksytty, hyväksytty virheillä ja hylätty, sekä 277CA-vaatimukset hyväksytty ja hylätty (A3, A4, A6, A7, A8). Myös 835-vaatimukset, jotka on yhdistetty potilastilille 837: n kautta tähän palvelimeen, sekä yleisimmät hylkäysyritykset.
• Laboratorio: tulosten toimitusaika, vastaanotosta viimeisen kohteen vahvistamiseen, sekä kriittiset tulokset (OBX-8 HH, LL, AA, > tai <), jotka eivät ole saapuneet kaikkiin kohteisiin.
• Yksityisyys ja turvallisuus: Kuka avasi viestit, etsi potilaita tai luki ennakkohyväksyntöjä konsolissa 7 päivän ajan, auditilokista (viestin avaaminen kirjataan message.read-merkinnällä). Myös jokainen aktiivinen API-tunniste ja sen viimeisin käyttöaika; tunniste, jota ei ole käytetty 90 päivään, on merkitty.

3.2.10 Jakaminen siitä, mitä syöte sisältää tosiasiallisesti

Profiili tästä syötteestä kertoo, mitä todella saapuu: mitkä laukaisutapahtumat, mitkä kentät on täytetty ja kuinka usein, miten arvojen muodot ovat, ja mitkä koodit lähettäjä todella käyttää. Viimeksi mainittu on yleensä yksi käytetyin asia siinä.

Profiilia voidaan ladata ja lähettää toiselle henkilölle. Sille tarvitaan nimi ja - pakollinen - järjestelmä, joka tuotti syötteen, koska kysymys, jonka vieras esittää jaetulle profiilille, on, kuvaako se heidän järjestelmäänsä, ja valinnainen kenttä tekisi "Tuntematon" yleisimmäksi vastaukseksi missä tahansa jaetussa kokoelmassa.

Se ei sisällä potilastietoja, ja se tarkistetaan oletuksen sijaan. Profiili on tilastollinen: laskureita, nopeuksia, pituuksia, muotoja. Arvoja säilytetään vain kentille, joita standardi määrittelee kooditauluiksi, koska kooditaulukon arvo ei ole tunniste. Tunnuksen arvoja ei koskaan luetella.

Kahden asian seurauksena on, että tämä on lupaus eikä toive. Palvelin rakentaa profiilin tallennetuista viesteistä, kun sitä viedään, sen sijaan, että se lähettäisi ruudulla näkyvän profiilin — joten se, mikä poistuu rakennuksesta, on koostettu profiililuokittelijalla, jolla on testi, joka osoittaa tämän ominaisuuden, eikä selaimella. Ja vienti kieltäytyy kokonaan, jos profiili koskaan listaa arvoja kentälle, joka ei ole kooditaulukko, nimeämällä kentän, mutta ei arvoja.

Ulkopuolelta saapuva profiili tarkistetaan samalla tavalla sisään tullessa, eri syystä: se on tuotettu jonkun toisen huolenpidon alaisena, ja potilaiden tunnisteenäyttäminen olisi tämän palvelimen paljastus. Sen tuominen muuttaa mitään — profiili kuvaa syötettä, ja sen kanssa tehtävän päätöksen on tehtävä erikseen.

3.3 Kehitä — muuta kanavan toimintaa ja kokeile sitä ennen kuin se on käytössä

3.3.1 Kanavat

Kanavan rakentaja. Lähteet, kohdat, suodattimet, muunnokset, skriptit ja testit, joissa generoitu YAML näkyy lomakkeen vieressä työskennellessä — joten tiedosto ei ole koskaan arvoitus, ja kuka tahansa, joka suosittelee tiedostoa, voi lukea sen mukana.

Katso kanavat osien selityksestä ja muunnos vaiheiden toiminnasta.

3.3.2 Skriptit

Työpöytä skriptejä varten, erillinen rakentajasta, koska skriptin kirjoittaminen ja skriptin liittäminen ovat eri toimintoja.

Kaikki seitsemän paikkaa tarjotaan — suodatin, muunnin, esikäsittelijä, jälkikäsittelijä, kirjoittaja, elinkaari ja lukija — ja oikean paikan valinta on tärkeää, koska paikka päättää, mitä skripti saa ja mitä siitä odotetaan. Skriptin tarkistaminen vääränä tyypinä ei ole kiertotie; se kääntää eri asian.

JavaScript, Lua ja WebAssembly ovat kaikki käytettävissä. Katso muunnos.

3.3.3 Sopimukset

Oletukset siitä, miltä syöte pitäisi näyttää, luodaan ja tarkistetaan täällä sekä perfuse contract-kohtaan. Katso komentorivi.

3.3.4 Taulukot

Hakutaulukot ja koodinjoukot: kartat, jotka muuttavat yhden järjestelmän koodit toisen järjestelmän koodeiksi. Ne voidaan muokata täällä, jotta koodin lisääminen ei vaadi käyttöönottoa.

3.3.5 AI-kartantaja

Ehdottaa kenttäkartoituksia luottamusluokituksella kullekin, ja pidättäytyy arvauksista. Nimestään huolimatta se ei käytä kielimallia eikä tee verkkokutsua: ehdotukset tulevat säännöistä, kenttänimistä ja näytteen sisällöstä, tässä palvelimessa. Se ehdottaa myös kanavaa yhdestä näytteestä, ja ilmoittaa nimenomaisesti, mitä näyte ei voi kertoa. Toinen osa tekee siitä luotettavan — ehdotus, joka näyttää täydelliseltä, kutsuisi sinua uskomaan asioita, joita viesti ei koskaan sanonut.

3.3.6 Leikkikenttä

Väliaikainen työtila viestejä ja muunnoksia varten. Liitä viesti, sovella vaiheita, näe tulos.

Mitään ei lähetetä minnekään kerran sivu on ladataan, mikä on syy, miksi se on olemassa tässä muodossa: se on turvallista liittää jotain todellista, ymmärrettäessä, että se pysyy selaimessa.

3.3.7 Varjo

Ohjaa liikenteen kandidaattikonfiguraation läpi rinnan olemassa olevan konfiguraation kanssa ja raportoi eroista, jotta muutos voidaan todistaa ennen kuin siihen voidaan luottaa. Sama idea kuin perfuse compare, mutta sovellettuna muutokseen sen sijaan, että migraatioon. Katso testaus.

3.4 Vaihto — standardit, joita tämä palvelin puhuu muiden organisaatioiden kanssa

3.4.1 FHIR-laboratorio

Muunna HL7 v2 FHIR:ksi, validoitu resurssi ja tarkastele tulosta. Näytteet kattavat sisäänpääsykertomukset, laboratoriotulokset, tapaamiset, kliiniset muistiinpanot, rokotukset ja ilmoitettavan käynnin. Validointi sisältää US Coren, joka on profiili, jota amerikkalainen sääntely kirjoitetaan, joten tämä vastaa kysymykseen "onko se, mitä he lähettivät meille, todella konformaalinen" ilman mitään omaksumista.

Julkinen terveydenhuollon ilmoitus luo eCR eICR: n ilmoituskohteen, jonka viesti lähettäisi. Se näyttää, mikä laukaisukoodi teki käynnin ilmoitettavaksi, mitä raportti joutui merkitsemään puuttuvaksi ja itse asiakirja. Viesti, jolla ei ole mitään ilmoitettavaa, saa sen sijaan syyn.

3.4.2 Tilaukset

FHIR-tilaukset ja ovatko heidän ilmoitukset saapuneet: tapahtumat, hyväksytyt, odottavat ja viimeisin syy, miksi yksi evättiin. Tilaukset luodaan FHIR-asiakasohjelmilla FHIR-rajapinnan kautta, eivät tästä sivusta, ja tunnistetiedot, jotka ne antoivat palvelimelle, eivät näytetä koskaan. Katso viestin muodot.

3.4.3 Asiakirjat

Kliiniset asiakirjat — CDA ja asiakirjan tulostettava muoto. Käytännöllinen, kun vaihdettava asia on potilaan kotiutusarviointi ei viesti.

3.4.4 Asiakirjojen jakaminen

IHE XDS.b-rekisteri ja varasto aloitettiin -xds:llä: kuinka monta asiakirjaa, potilaita ja lähetyssarjoja se sisältää ja kuinka monta niistä on korvattu; varaston, rekisterin, XCA-portin ja MHD:n osoitteet; potilaan asiakirjojen hakeminen tässä rekisterissä tai toisessa yhteisössä (ITI-18-rekisteri tai ITI-38-portti, jossa on tunniste sille); ja CDA-asiakirjan julkaiseminen käsin, laitoksen tyypin ja toimintaympäristön, joita asiakirja ei kerro. Katso viestiformaatit.

3.4.5 Suora

Suoran turvallisen viestinnän. Tämän palvelimen Direct-osoitteet luetellaan jokainen osoite, jonka kautta kanava lähettää tai vastaanottaa, sen sertifikaatti, kun se vanhenee, sen luotettavat ankkurit ja mitä vikaa (puuttuva tiedosto, vanhentunut sertifikaatti). Osoitekirja pitää kirjaa kirjeenvaihtajista ja heidän sertifikaateistaan, joihin heidän postinsa salataan: liitä yksi heidän HISP:stään tai Tallenna sertifikaatilla DNS:stä; sertifikaatti, joka ei ole osoitteelle tai sen verkkotunnukselle, hylätään. Etsi sertifikaatti DNS:stä kysyy ilman tallentamista. Katso viestiformaatit.

3.4.6 Terveyslinkit

SMART Terveyden linkit ja -kortit, CMS:n *Kill the Clipboard* -ohjelman mukaisesti. Vastaanota SMART Terveyden linkki lukee linkin tai QR-koodin, jonka potilas näyttää sisäänkirjautumisessa, tarkistaa terveydenkortit sisällä ja lähetä se eteenpäin kanavaan. Jaa käyntitietue luo linkin, jonka tämä palvelin isännöi, valinnaisesti salasanalla ja QR-koodilla potilaalle; Käytä potilaan yhteenvetoa täyttää sen potilaan Kansainvälisen PotilasYhteenvedon tämän palvelimen FHIR-kaupasta. Linkit, joita tämä palvelin isännöi luetellaan niiden kanssa, kuinka usein kunkin haettiin, milloin ne vanhenevat ja salasana-yrittämisen jäljellä olevat mahdollisuudet, ja miten yksittäinen linkki perutaan. Tarkista SMART Terveyden kortin allekirjoitus ja myöntäjä omalla. Katso CMS-0057 palvelimen asetuksista, joita se tarvitsee.

3.4.7 Kuvantaminen

Tämä arkisto, jota tämä palvelin pitää, kun se suoritetaan -dicomweb-archive-valinnalla: tutkimusten, sarjojen, instanssien ja käytetyn tilan määrät, DICOMweb-osoite ja tietolähteen lohko OHIF-näkymälle, sekä tutkimuksen haku potilaan nimen, tunnisteen, sairaalahuoneen numeron ja päivämäärän perusteella tehty samalla QIDO-RS-pyynnöllä, jonka näkymä tekee. Tutkimus avautuu sarjoihinsa ja instansseihinsa, ja instanssi ladataan DICOM-tiedostona. Mitään ei renderöidä: Perfuse siirtää kuvat ja näkymä näyttää ne. Ilman arkistoa näytön sanoo, miten sen voi ottaa käyttöön. Katso DICOMweb.

3.4.8 TEFCA

Audit-reitti Terveystalon kautta tapahtuvasta vaihdosta ja säännöt, jotka ohjaavat sitä.

Kaksi kuljetusta, jotka ovat eri vaiheissa, ja näyttö kertoo, kumpi on kumpi. Yksi lippu, joka kattaa molemmat, olisi väärä kummassakin suunnassa, johon se pyöristettäisiin.

Välitetty FHIR on toteutettu, ja se ei ole koskaan puhunut oikean QHIN:n kanssa. Se noudattaa Sequoia Project Standard Operating Procedurea, joka tuli voimaan 8. maaliskuuta 2026: etsi kumppanin UDAP-metadata, tarkista se, rekisteröi dynaamisesti, hanki pääsytoken, joka sisältää käytön tarkoituksen, ja kysely. UDAP on julkisen avaimen infrastruktuuri OAuth 2.0:lle — luottamuksellinen yhteisö myöntää X.509-sertifikaatteja jäsenilleen, ja jäsen todentaa allekirjoittamalla JWT:t yksityisellä avaimella ja liittämällä sertifikaattiketjun.

Turvallisuuskerros on varmistettu jonkun toisen toteutuksen kanssa, mikä on ainoa täällä arvokas varmistus. Tämän rakennuksen allekirjoittama rekisteröinti lähetettiin live-kolmannen osapuolen viitepalvelimelle ja hylättiin unapproved_software_statement — Untrusted: Certificate is not a member of community -virheilmoituksella. Tuottamaan vastausta palvelin purki pyynnön, parsisi ohjelmistolauselman JWT:na, tarkisti sen allekirjoituksen, käveli varmenneketjua ja teki päätöksen jäsenyydestä. Se on eroa siinä, että joko torjutaan ovella tai palautetaan lukukelvoton kirje.

Mitä jäljellä ei voida tehdä täältä. Sertifikaatti, joka osoittaa yhteisön jäsenyyden, tulee QHIN:n rekisteröinnistä eikä se ole mitään, minkä ohjelmisto tuottaa. Kunnes sellainen on olemassa, mikään vaihto oikean kumppanin kanssa ei valmistu.

Kuinka kanava kysyy. Määränpäätyyppi tefca kysyy jokaisen viestin potilaasta Facilitated FHIR -kumppaniryhmältä Asetukset, TEFCA (tefca.partnerFHIRBase): tunnisteella, jos viesti sisältää sellaisen (PID-3 tai FHIR-potilaan tunniste), muutoin sukunimellä ja syntymäpäivämäärällä, ja ei koskaan pelkästään nimellä, koska väärä vastine nimestä palauttaa jonkun toisen henkilön tiedot ilman virhettä. Määränpää asettaa käytön tarkoituksen (hoito, maksu, toiminta, kansanterveys, yksilön pääsy); tarkoitus, jota osallistuja ei ilmoita, evätään ennen kuin mitään lähetetään. Tarkoitukset lähetetään TEFCA-vaihtopurkauksena (T-TRTMNT, T-PYMNT, T-HCO, T-PH, T-IAS, järjestelmä urn:oid:2.16.840.1.113883.3.7204.1.5.2.1), tai tefca.purposeCodes: hl7 -muodossa HL7-käytön tarkoituksena koodina yhteisöille, jotka käyttävät niitä. Löydetty paketti on määränpään vastaus ja voidaan antaa toiselle kanavalle results_to -avaimen kanssa. Jokainen kysely, mukaan lukien evätetyt, on näkyvissä tämän näytön jäljityksessä, joka nimeää kumppanin.

Koko polku, löytämisestä tokeniin, jota kumppanin FHIR-palvelin hyväksyy, testataan udap-dotnet -viitepalvelimia vastaan (ks. vahvistus).

Vanha QHIN-to-QHIN-vaihto, joka perustuu IHE-profiileihin, ei ole toteutettu. Yritys evätään virheilmoituksella, joka sanoo niin, ja evääminen kirjataan epäonnistumisena. Se on tarkoituksellista eikä odottavaa siivooja: pystytetty vaihto, joka ilmoittaa onnistumisesta, lisäisi kirjauksia audit-reitille vaihdoista, jotka eivät koskaan tapahtuneet, ja reitti, joka ei ole sama kuin mitä tapahtui, on pahempi kuin ei mitään, koska reitti on se, mihin uskotaan.

Yleensä, päätepisteet, joita käytetään vaihtoon, tulevat allekirjoitetusta osasta kumppanin metadatasta, ei asiakirjan rungosta. Allekirjoituksen vahvistaminen ja sitten päätepisteiden lukeminen allekirjoittamattomasta kopiosta olisi monimutkainen tapa luottaa verkkoon: hyökkääjä, joka pystyy muokkaamaan vastauksen, jättää allekirjoitetun osan koskemattomaksi, osoittaa tokenin päätepisteen omalle palvelimelleen ja kerää asiakasväitteitä jokaiselta, joka tarkisti allekirjoituksen ja sitten ohitti sen, mitä se kattoi.

Luottamuksellinen pakkauksen sidonta on vaadittu, ja sen puute estetään käynnistyksessä. Tarkistamalla kumppanin allekirjoitetun metatietojen sertifikaatin, joka saapui sen sisällä, osoitetaan vain, että yksi osapuoli teki molemmat - virhe, jonka tämä koodipohja on aiemmin tehnyt SAML:ssä, jossa vahvistaja suosi sisäänrakennettua sertifikaattia ja todisti hyökkääjän järjestelmänvalvojana, vaikka kaikki testit menivät läpi. Sisällytä välisertifikaatit pakkaukseen: UDAP-palvelimen tarvitsee lähettää vain lehtisertifikaattinsa, ja julkinen viitepalvelin tekee juuri niin.

3.5 Maksajat - korvaukset, etukäteisvaltuutukset, lääkkeet ja CMS-maksajan säännöt

3.5.1 Korvaukset ja todennus

Rakenna X12 275 korvausliite 006020 muodossa, jota CMS-0053-F käyttää, liittämällä C-CDA tai lataamalla PDF, TIFF tai JPEG, ja näe se luettavaksi. Lue 275 ja lataa asiakirja sisällä. Muunna X12 278 päätös Da Vinci PAS ClaimResponse muotoon. Mitään tällä sivulla ei tallenneta tai lähetetä. Katso viestin muodot siitä, mitä 275 koostuu ja mitä se ei tee.

3.5.2 Lääkkeet

Lääkevalikoima ladattiin -formulary-komennolla, ja kaksi NCPDP-standardia vastattiin siitä. Lääkevalikoima luetellaan suunnitelmat ja lääkkeet niiden tasojen ja vaatimusten kanssa, ja missä julkinen Da Vinci US Drug Formulary API ja NCPDP-päätepisteet sijaitsevat. Hinnan tarkistus (RTPB) hinnoittelee lääkkeen jäsenelle lääkärin Reaaliaikaisen Reseptin Edun pyynnön mukaisesti: kattavuustilanne, rajoitukset sanoissa niiden koodien kanssa, jäsenen osuus ja suunnitelman osuus, ja edullisemmat vaihtoehdot. Ennakkohyväksyntä (ePA) lähettää SCRIPT-aloituksen tälle palvelimen omalle päätepisteelle, näyttää kysymysryhmän lomakkeena, lähettää vastaukset ja näyttää päätöksen; alla, jokainen tapaus, missä se on ja onko lääkäri ilmoitettu, tapauksen vastaukset, painike lähettämättömän päätöksen uudelleen lähettämiseksi ja lääkekuvaus, jonka CMS-0062-P ehdottaa. Katso CMS-0057.

3.5.3 CMS-0057

Maksajan puoli CMS Interoperability and Prior Authorization -säännöstä, viitenä työkaluna:

• Neljä rajapintaa: onko Potilastietojen käyttöoikeus, Terveydenhuollon tarjoajan käyttöoikeus, Vakuutusyhtiöiden välinen tietojen vaihto ja Ennakkohyväksyntä valmiina tässä instanssissa, ja mitä kullekin edelleen tarvitaan.

- Tarkastelijan jonot: PAS-pyynnöt, jotka odottavat henkilön käsittelyä, ensin kaikkein pianimmassa määräaikassa, asiakirjoineen; hyväksy, hylkää tai vahvista vähemmän yksiköitä. Katso tarkastelijan jonot.

• Vakuutusyhtiöiden välinen tietojen vaihto CARIN BB:hen: 837 ja sen 835 muunnettu CARIN Blue Button -paketteihin.
• Ennakkohyväksyntä PDexiin: PAS-vastaus muunnettu PDex-ennakkohyväksyntään.
• Ennakkohyväksyntätilastot: vuosittainen julkiset ennakkohyväksyntätilastot, esikatseltu CSV-päätöksistä.

Muunnokset eivät tallenna mitään eivätkä lähetä mitään.

3.5.4 CMS Aligned Network

Valmius CMS:n interoperabiliteettikehykselle: jokainen 26 kriteeristä, ryhmiteltyinä CMS:n ryhmittelyn mukaisesti, siinä mitä Perfuse tarjoaa, onyko se on täällä, asetus joka sen käyttää päälle, ja mitä organisaation tulee tehdä. Yläreunassa olevat laskurit suodattavat listaa. Katso CMS-0057.

3.6 Hallitse - kuka voi tehdä mitä, ja miten tämä palvelin on asetettu

3.6.1 Käyttäjät

Tilit, roolit (valvoja, katselija, operaattori, muokkaaja, ylläpitäjä) ja kanavaryhmät. Kunkin henkilön kanavaryhmät muokataan paikallaan luettelossa; tyhjä tarkoittaa kaikkia kanavia, ja lab=editor, adt antaa eri roolin yhdessä ryhmässä. Joitain ryhmiä rajoitettu ylläpitäjä näkee vain näiden ryhmien henkilöt. Otsikko näyttää omat ryhmäsi roolisi vieressä, kun sinulla on ryhmiä. Katso turvallisuus.

Koneen tunnistetiedot ovat myös täällä. Tokeni on koneelle eikä henkilölle: se ei vanhene eikä ole vaikuttunut kenenkään kirjautumisesta, mikä on se, mitä palvelimen naapuriin puhuva palvelin tarvitsee. Vain tiiviste tallennetaan, joten tokenia näytetään kerran, kun se luodaan, eikä sitä voida palauttaa - varastettu tietokanta ei tuota käytettävissä olevaa tokenia. Anna sille alin rooli, joka tekee työn.

MCP-ominaisuuden ollessa käytössä, osio näyttää myös osoitteen, johon tekoälyagentti yhdistää, asiakasohjelman määrityksen kopioimiseen ja kunkin työkalun roolin, jota se tarvitsee; tokenin myöntäminen Anna tekoälyagentin toimia sen avulla antaa sille mcp:write -laajuuden. Katso turvallisuus.

3.6.2 Vuokralaiset

Jaetulla palvelimella, alustan operaattorin luettelo organisaatioista: kunkin kanavien määrä ja tallennettu koko rajoitusten (kanavat, viestit minuutissa, tallennustila) vieressä, jotka asetetaan paikalla. Näytetään vain alustan roolille. Katso turvallisuus kunkin rajoituksen toiminnasta.

3.6.3 Sertifikaatit

Käytössä olevat TLS-sertifikaatit ja niiden voimassaoloajat. Voimassaoloajat ovat se piste: sertifikaatti, joka vanheni sunnuntaina, on yksi luokka katkoista, joka on täysin estettävissä ja jota ei yleensä estetä.

3.6.4 Toiminta

Kuka muutti mitä, ja milloin. Jokainen konfiguraatiomuutos on tallennettu, mikä tekee siitä mahdollisen vastata "se alkoi epäonnistua tiistaina".

3.6.5 Tietosuoja

Henkilön pyynnöt GDPR:n ja UK GDPR:n mukaisesti, oikeudelliset pidätykset, poistoluettelo, säilytys ja rekisteröintikäytäntöjen kirja; vain järjestäjille. Katso tietosuojelu.

3.6.6 Laivasto

Jokainen Perfuse-istanse yhdellä sivulla.

Mirth myy tämän erillisenä tuotteena; täällä se on konfiguraatiotiedosto ja vain lukuoikeudella oleva tunniste. Syy siihen, miksi se on arvokas, on kapea ja tärkeä: kuollut palvelin ei näytä hiljaiselta. Yhden instanssin kojussa ei voida nähdä, onko toisella sivustolla lopetettu raportointi, ja laivaston näkymässä voidaan.

3.6.7 Siirrä

Lisää Mirth- tai OIE-kanavan vienti ja katso, kuinka moni kanavistasi toimisi täällä muuttumattomana. Sama analyysi kuin perfuse explain ja perfuse translate, ilman terminaalia. Katso siirtymisohjeet.

3.6.8 Asetukset

Jokainen palvelimen asetus, jolla on ohjaus kullekin — mukaan lukien ne, jotka perinteisesti elävät vain tiedostossa. Kunkin asetuksen kohdalla näkyy, vaikuttaako se välittömästi vai vaaditaanko uudelleenkäynnistys, ja onko asetus asetettu eksplisiittisesti vai onko se oletusarvo.

Asetukset kattavat jokaisen perfuse serve-vaihtoehdon, joka kytkee toiminnon päälle: FHIR-päätepiste ja sen versio, vakuutusyhtiöiden rajapinnat, PAS ja CRD-säännöt, X12 278 -silta, eCR, SMART-valtuutuspalvelin, TLS ja allekirjoitus, tilastot, laivasto ja VPN. Ne on ryhmitelty FHIR, vakuutusyhtiöt, julkinen terveys, SMART, turvallisuus jne. Kunkin asetuksen kanssa näytetään myös lippu, johon se vastaa.

Käynnistäminen konsolista. Asetus, joka on merkitty *Vaativa uudelleenkäynnistys*, tallennetaan heti, mutta luetaan vain kun palvelin käynnistetään uudelleen. Kun mitään odottaa, Settingsin yläosassa oleva banneri listaa ne Käynnistä palvelin uudelleen -painikkeella (sama painike on tarjolla kirjautumisen muokkaajassa ja asetustiedostossa tallennuksen jälkeen). Se kysyy ensin, koska jokainen kanava pysähtyy muutamaksi sekunniksi: kunkin lopettaa viestin, jonka se käsittelee, kuten se tekee, kun palvelu lopetetaan, ja lähettäjät lähettävät uudelleen mitä tahansa, mikä saapuu sillä välin. Konsoli odottaa sitten, kunnes palvelin vastaa uudelleen ja lukee asetukset uudelleen. Vain järjestelmänvalvoja voi käynnistää uudelleen, ja kunkin uudelleenkäynnistystapahtuman on kirjattu toimintalokiin server.restart -merkinnällä.

Linuxilla ja macOS:lla prosessi korvaa itsensä saman ohjelman ja argumenttien kanssa, säilyttäen prosessin tunnisteen, joten systemd, launchd tai konttien suorittamisen aikana ei tapahdu mitään. Windowsissa palvelin käynnistyy uudelleen saman prosessin sisällä, joka pitää Windows-palvelun palvelunhallinnassa. Jos palvelin ei ole vastannut kahden minuutin kuluttua, konsoli ilmoittaa siitä; syy on palvelimen lokissa.

Liput ja asetustiedosto. Kun palvelin käynnistyy ensimmäisen kerran, liput, joita se sai, kirjoitetaan asetustiedostoon. Sen jälkeen tiedosto voittaa liput, joten asetuksen muuttaminen tehdään konsolissa (tai tiedostossa), ei palvelun komentorivillä muokkaamalla. Lippu, jota tiedosto ei vielä mainitse, tallennetaan, kun palvelin käynnistyy siitä. Lipun poistaminen komentoriviltä myöhemmin ei kuitenkaan sammuta sen ominaisuutta: sammuta se asetuksissa.

SNMP on paneeli asetusten alapuolella: onko agentti vastaamassa ja minkä osoitteen, verkkot, joille se vastaa, kuinka monta hälytysloukkausta on lähetetty tai epäonnistunut, ja Lataa MIB käytössä olevan perusOID:n kanssa. Arvot asetetaan valvontaa varten, SNMP.

Brändäys on myös täällä: sivusto voi asettaa tuotteen nimen, sloganin, korostevärin ja ladata logon. Logo näkyy sitten otsikossa, kirjautumissivulla, kojussa ja raporttinäytöillä. Jos logoa ei ladata, mitään ei korvata — brändätön asennus pysyy brändättömänä eikä hankki koristelua.

3.7 Mitä värit tarkoittavat

Neljä rekisteriä, ja kunkin kohdalla sanotaan jotain erilaista. Ero on mainittava, koska se on eroa välillä, jonka näytössä voi lukea yhdellä silmäyksellä, ja sellaisella, jossa kaikki kilpailevat huomiosta.

Selkeä teksti on tosiasia siitä, miten Perfuse toimii. Suurin osa käyttöliittymästä. Mitään ei ole värjätty tärkeäksi.

Vihreä tarkoittaa, että jotain onnistui juuri, koska teit jotain. Se ilmestyy toiminnon jälkeen eikä jää näkyviin.

Keltainen on varoitus: arvoisa tietää ennen kuin toimit, eikä se ole virhe. Ominaisuus, jota ei ole käytössä, asetus, jonka muutokset ovat auditoitu, muunnos, joka likimääräiseen eikä toista, kuljetus, jonka Perfuse käsittelee, mutta ei voi täysin vahvistaa. Keltainen on väri, joka tarkoittaa "lue tämä ennen kuin jatkat".

Punainen tarkoittaa, että jotain on väärää tässä hetkessä. Arvo, joka on hylätty, pyyntö, joka epäonnistui, varmenne, joka on vanhentunut, kriittinen hälytys, joka laukeaa. Mitään muuta ei käytetä.

Viimeinen sääntö on syy siihen, miksi näyttö ei avaudu punaisena. Punainen on ainoa väri, joka kantaa ohjeen — pysähdy, ja se voi olla jotain, mitä teit — ja näyttö, joka käyttää sitä koristeluun, ei voi sanoa mitään, kun syöte on todella väärä. Tämä ei aina ollut totta: käyttäjien näyttö avautui aiemmin "palvelin lähetti vastauksen, jota ei voitu lukea" jokaisella asennuksella, joka ei ollut määrittänyt passkeyjä, ja asetukset-näyttö merkitsi auditoituja arvoja samalla värillä kuin hylätyn. Testi web/src/RedMeansWrong.test.ts:ssa epäonnistuu nyt, jos lause, joka kuvailee jotain puuttuvaa tai likimääräistä, annetaan punainen tyyli.

Koodiruutu sisällä sanastoa on erilainen. Siellä punainen on tokenin tyyppi — HL7-segmentin nimi, XML-elementti — eikä se kanna mitään arviointia.

4 Kanavat

Kanava on yksi viestivirta: jostakin ne tulevat, valinnaiset muutokset ja yksi tai useampi paikka, minne ne menevät. Se on konfiguraation yksikkö, valvonnan yksikkö ja käyttöönoton yksikkö. Kaikki muu Perfusessa on olemassa kanavien palvelemiseksi.

4.1 Rakenne

Kanavatiedostolla on seuraavat osat, järjestyksessä, jossa ne tulevat voimaan:

Lisäksi useita, jotka koskevat koko kanavaa: scripts, shadow, contract, tables, attachments, group ja enabled. Kukin on kanavaviitteessä.

4.2 Yksi lähde, monta kohdetta

Tämä epäsymmetria on tietoinen ja sen ymmärtäminen on tärkeää alusta alkaen, koska se on yleisin sekoittumisen lähde, kun tulee toisesta moottorista.

Kanavalla on tasan yksi lähde. Jos viestit tulevat kahdesta paikasta, se on kaksi kanavaa. Yrittäminen ilmaista sitä yhtenä kanavana tuottaa konfiguraation, jossa kuljetuksen epäonnistuminen näyttää samalta ulkopuolelta, ja jossa kahden syötteen liikenne sekoittuu tilastoissa — joten toisen lasku piilotetaan toisen alle.

Kanavalla on mikä tahansa määrä kohteita, ja ne ovat riippumattomia. Yhden epäonnistuminen ei estä muita, ja kullakin on oma jononsa, oma uudelleenkokeilupolitiikkansa ja oma toimitusrekisterinsä. Viesti, joka saavutti kolme neljästä kohteesta, merkitään tarkalleen sellaisena, ei onnistumisena tai epäonnistumisena.

4.3 Kohteet eivät ole ketju

Kunkin kohde saa viestin sellaisena, kuin se oli kanavan muunnosten jälkeen. Kohde ei saa edellisen kohden tulostetta.

Tämä on tärkeää, kun kohdella on omat muunnokset, mitä se voi olla. Ne koskevat vain kyseisen kohden kopiota. Yleinen virhe on laittaa muutos ensimmäiseen kohteeseen ja odottaa, että toinen kohteekin näkee sen.

Jos tarvitset todella ketjun — yhden virran tulosteen syöttämistä toiseen — käytä kanavan kohdetta, joka lähettää toiseen kanavaan nimellä. Se on eksplisiittinen, näkyy viestihistoriassa kahtena kanavana ja voidaan valvoa kahtena asioidena, mitä piilotettu ketju ei voi.

4.4 Nimeäminen

Nimi on kanavan identiteetti kaikkialla: tiedostossa, viestivarastossa, hälytyksissä, auditilokissa ja URL-osoitteessa. Sen muuttaminen ei ole uudelleennimeäminen; se on uusi kanava, ja vanhan kanavan historia pysyy vanhan nimisenä.

group on erillinen ja olemassa kanavien järjestämiseksi. Ryhmällä ei ole vaikutusta käyttäytymiseen, ja kanavien ryhmittäminen ei tee niistä jaettavia.

4.5 Käyttöönotto ja pois käytöstä

enabled: false estää kanavan käynnistymisen poistamatta sitä. Sen konfiguraatio, historia ja tilastot säilyvät.

Poissaoleva kanava ei ole keskeytynyt kanava. Sen lähde ei kuuntele, joten yrittävä lähettäjä saa yhteyden epäonnistumisen sijaan kiinni, mikä tarkoittaa, että lähettäjän oma virheloki täyttyy, joten poissaoleva kanava ei ole korvaaja järjestelylle, jonka kanssa lähettäjä on sovittu.

4.6 Missä kanavat sijaitsevat

Yksi YAML-tiedosto per kanava, hakemistossa, jonka määrittää -channels. Tiedostonimi ei ole kanavan nimi; name-avain on. Niiden pitäminen samana on vahvasti suositeltavaa, eikä mitään pakota sitä.

Tiedostot luetaan uudelleen ilman uudelleenkäynnistystä. Tiedosto, joka ei parseudu, raportoidaan ja aiemmin ladattu versio jatkaa suorittamista, joten syntaksivirhe ei voi ottaa toimivan syötteen ilmalta.

4.7 Kanavan oman kuuntelijan salaaminen

Kanava, joka kuuntelee porttia, on itsenäinen palvelin, ja sen TLS on erillinen Perfuse-verkkorajapinnan TLS:stä. Yhden asettaminen ei aseta toista. HTTP-lähteelle asetukset ovat TLS ja rajoitukset -kohdassa lähteessä.

TLS:n käyttöönotto pyytää varmenteen ja yksityisen avaimen. Vaadittavan asiakasvarmenteen käyttöönotto muuttaa sen vastavuoroiseksi TLS:ksi: lähettäjän on esitettävä varmenne, jonka on allekirjoittanut valitsemasi viranomainen, mikä on todennus, joten kuuntelija, jolla se on käytössä, ei tarvitse myös jaettua tunnusta — vaikka niiden yhdistäminen ei ole väärin.

Viranomaisuutta kysytään vain kerran, kun asiakasvarmenne vaaditaan, ja se jätetään tiedostosta pois, kunnes siihen tarvitaan. Kanava, joka nimeää viranomaisuuden, jota ei koskaan kysytä, luetaan kuin lähettäjät olisivat vahvistettu, vaikka he eivät ole.

MLLP-kuuntelija on samanlainen kuin Salaa tämä kuuntelija -asetukset, joissa on yksi mainittava ero: MLLP:llä asiakasvarmenne on ainoa saatavilla oleva todennusmenetelmä. Tokenia tai otsikkoa ei ole, joten kuuntelija ilman sitä hyväksyy viestit kaikilta isännöitsijöiltä, jotka voivat tavoittaa portin.

Kaksi rajoitusta on sen rinnalla. Lopeta lukeminen kestolta, koska lähettäjä, joka avaa yhteyden ja lopettaa kirjoittamisen, muuten pitää yhteyden auki. Ja suurin hyväksytty viesti, tavuissa, koska nolla tarkoittaa, että rajoitusta ei ole, ja rajoitus on muisti — lähettäjä, joka lähettää gigatavun, hylätään sen sijaan, että se imeytyy.

4.8 Validointi

Kanava tarkistetaan, kun se ladataan, ja tarkistukset ovat kieltäviä eikä varoituksia, missä vaihtoehtona olisi kanava, joka toimii ja tekee väärän asian.

Esimerkkejä asioista, jotka evätät suoraan: määränpää ilman tyyppiä, muodonmuutos, joka osoittaa polkua, joka ei voi olla olemassa julkaistussa tietotyypissä, vahvistusmuoto, jota lähde-liikenne ei voi toimittaa, ja aineen II resepti uusimisilla.

Ero, jota Perfuse pyrkii pitämään, on se, että kaikki, mikä voi tuottaa uskottavan näköisen väärän tuloksen, evätään, ja kaikki, mikä on vain epätavallista, sallitaan ja ilmoitetaan. Kanava, joka ei voi olla väärä, on arvokkaampi kuin kanava, joka käynnistyy.

5 Viestin virtaus

Tämä luku seuraa yhtä viestiä siitä hetkestä, kun se saapuu, siihen hetkeen, kun se toimitetaan tai luovutaan. Tiedostaminen tästä järjestyksestä on nopein tapa selvittää, mihin muutos kuuluu, ja miksi jotain ei tapahdu.

5.1 Tapahtumien järjestys

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

5.2 Kun vahvistus lähetetään

Tämä on tärkein asetus kanavassa, koska se päättää, mitä lähettäjälle luvataan. Se on ack.when, ja sillä on kaksi arvoa.

on_delivery on oletusarvo. Vahvistus lähetetään vain sen jälkeen, kun jokainen käytössä oleva määränpää on hyväksynyt viestin. Myönteinen vahvistus tarkoittaa siis, että data on todella saapunut jonnekin, mikä on vahvin väite, jonka välittävä moottori voi rehellisesti tehdä.

on_receipt vahvistaa heti, kun viesti on jäsentetty ja jonottu, ennen kuin määränpäätä on kirjoitettu.

Perfuse käyttää oletusarvoisesti on_delivery -asetusta, koska luvataan toimitus ja sitten menetetään viesti on pahempaa kuin hitaus. on_receipt -asetuksella viesti, joka on vahvistettu, voidaan edelleen menettää, jos prosessi kuolee jonottuneella työllä — lähettäjä uskoo, että se on toimitettu, mitään ylävirran ei uudelleenlähetä sitä, ja ainoa tallennus siitä, että se on olemassa, on Perfuse-omassa varastossaan.

5.3 Milloin valita on_receipt

Tapaus sen puolesta on olemassa, ja se on aikakatkaisut. MLLP-lähettäjä, joka ei saa vahvistusta muutamassa sekunnissa, yleensä lähettää uudelleen, joten hitaalla määränpäällä on_delivery -asetuksella tuottaa duplikaatteja sen sijaan, että se aiheuttaa viivästystä. Jos yksi määränpää on hitaasti arkistoiden tai järjestelmä, joka on säännöllisesti käytössä, on_delivery -asetus sitoo lähettäjän aikakatkaisun kyseisen määränpään huonoon tapaukseen.

Kauppa on eksplisiittinen: on_receipt siirtää riskin duplikaateista menetykseen. Sen valitseminen tarkoittaa sitä, että hyväksytty viesti voidaan menettää kaatumisen yhteydessä, ja se on yhdistettävä jonon syvyyden hälytykseen, jotta huomataan jonon loppuminen. Katso hälytykset.

5.4 Missä viesti tallennetaan

Ennen suodatusta ja siten ennen muodonmuutosta. Kolme seurausta:

• Viestin, jonka suodatin hylkäsi, on edelleen tallennettu. Voit tarkastella, mitä saapui, ja vahvistaa, että suodatin toimi oikein.
• Toistaminen ja uudelleenprosessointi käynnistyy aina siitä, mitä todella saapui, ei osittain muunnetusta versiosta.
• Muutokset muunnoksissa voidaan testata todellista historiallista liikennettä vastaan, koska alkuperäinen on edelleen tallennettu. Katso testing.

Muunnettu muoto tallennetaan myös kohden mukaan tuloksen kanssa. Tallennus sisältää siis saapuneen, lähetetyn ja tapahtuneen — mitä tutkinta tarvitsee.

5.5 Virhe kussakin vaiheessa

Tärkeä epäsymmetria: parsimisvirhe on pysyvä, ja toimitusvirhe yleensä ei ole. Yritettäessä uudelleen epäparsittavaa viestiä ei auta, joten sitä ei yritetä uudelleen. Yritettäessä uudelleen toimitusvirhettä, joka yleensä auttaa, joten sitä yritetään uudelleen.

5.6 Järjestys

Yhden kohden sisällä viestit toimitetaan saapumisjärjestyksessä, ja viesti, joka epäonnistuu ja menee jonoon, pitää paikkansa — myöhemmät viestit odottavat sen takana eivätkä ohita sitä.

Tämä on oikea oletusarvo kliinisiin tietoihin, joissa potilaan sisääntulon ja uloskirjaamisen toimitus väärässä järjestyksessä on huonompi kuin molempien myöhästyminen. Tämä myös tarkoittaa, että yksi myrkytetty viesti voi pitkittää jonon, miksi jonon syvyys on syytä hälyttää.

Kohteiden välillä ei ole järjestysvapautta, koska ne ovat riippumattomia. Kaksi kohdetta eivät välttämättä vastaanota samaa viestiä samaan aikaan, ja nopea kohde voi olla useita viestejä hitaamman edellä.

5.7 Rinnakkaisuus

Lähde voi käsitellä useita yhteyksiä kerran, jota rajoittaa max_connections. Viestit eri yhteyksistä käsitellään rinnakkain.

Tämä tarkoittaa, että kahden samanaikaisesti lähetetyn viestin saapumisjärjestys ei ole määritelty, eikä se voi olla — ne saapuivat todella samaan aikaan. Lähettäjä, joka tarvitsee järjestyksen, on käytettävä yhtä yhteyttä, mikä on se, mitä heistä suurin osa tekee.

6 Muunnos

Muunnokset muuttavat viestiä. Ne ovat luettelo, ne suoritetaan järjestyksessä, ja kunkin edellisen tuloksen näkee seuraava.

Perfusen muunnokset ovat deklaratiivisia: kunkin vaiheen nimi on operaatio ja kenttä, johon se sovelletaan. Tavallisen polun ympärillä ei ole skriptikieltä. Tämä on tietoinen rajoitus ja syyt on selitetty kohdassa miksi ei skripti alla.

6.1 Vaiheet

Jokainen vaihe hyväksyy myös description, joka näkyy jäljityksessä ja käyttöliittymässä, ja when, joka tekee vaiheen ehdolliseksi.

Vaihe kirjoitetaan operaation nimenä, jolla on oma lohko:

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 Tyhjennys, poisto ja ero

clear jättää kentän läsnäolevaksi ja tyhjäksi. remove poistaa sen kokonaan.

HL7:lle tämä ero on todellinen, ja se ulottuu vastaanottajaan. Tyhjä kenttä kertoo, että ”minulla on tämä kenttä, ja sillä ei ole arvoa”. Puuttuva kenttä ei kerro mitään. Jotkut vastaanottajajärjestelmät käsittävät ensimmäisenä ohjeena tyhjentää tallennettu arvo, ja toisen, joka ei mainita sitä, jättää sen koskemattomaksi — mikä on ero potilaan tallennetun allergian poistamisessa ja siitä, ettei sitä mainita.

Jos et tiedä, mitä vastaanottaja haluaa, kysy. Arvauksella on 50 prosentin mahdollisuus tuhota hiljaisesti tietoja kaukana puolella.

6.3 Ehdot

when ottaa lausekkeen ja vaihe suoritetaan vain, jos se on tosi:

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

Vaihe, jonka ehto on epätosi, merkitään ohitettuksi, ja tämä ilmoitetaan erikseen vaiheesta, joka suoritettiin ja ei muuttanut mitään. Tämä ero on step-through debuggerin tarkoitus, ja se käsitellään kohdassa debugging: epätosi ehto ja puuttuva kenttä näyttävät samanlaisilta ulkopuolelta ja tarkoittavat vastakkaisia asioita.

6.4 Polut

Polku osoittaa kentän: PID-5 on PID-kentän viides kenttä, PID-5.1 on sen ensimmäinen komponentti, PID-3(2) on PID-3-kentän toinen toisto ja OBX(3)-5 on kolmannen OBX-segmentin viides kenttä.

Kaksi asiaa, joita kannattaa tietää:

• set luo polun, jota osoittaa, mukaan lukien väliosan rakenteen. Tämä on kätevää, ja se tarkoittaa, että set ei voi koskaan osoittaa, että kenttä puuttui — sen jälkeen se on olemassa. Testataksesi, mitä tapahtuu, kun kenttä puuttuu, käytä copy-toimintoa polusta, jota ei ole.
• Polku ilman indeksiä osoittaa jokaisen toistuvuuden ja jokaisen ilmestyksen, kuten se tekee suodattimessa (jossa PID-3.5 == "SS" on tosi, kun jokin toisto on). Viestillä, jolla on viisi OBX-segmenttiä, set-toiminto OBX-5: ssä muuttaa kaikki viisi, ja set-toiminto PID-3.4: ssä uudelleennimeää jokaisen tunnisteen PID-3: ssa, mukaan lukien kansallisen numeron. Muuttaaksesi yhden, anna sen indeksi: PID-3(1).4, OBX(2)-5.

6.5 Virheet

Useimmat vaiheet eivät voi epäonnistua. Arvon asettaminen, kentän tyhjentäminen tai kopioiminen puuttuvasta polusta oletusarvoon on määritelty jokaiselle syötteelle.

date on poikkeus, koska arvo, jota se ei tunnusta, ei ole oikein muunnettavissa. Se ottaa on_error-parametrin:

• fail — oletusarvo. Viesti pysähtyy ja se merkitään muunnosvirheeksi.
• keep — jätä alkuperäinen arvo koskemattomaksi.
• clear — tyhjennä kenttä.

Oletusarvo on fail, koska aikaleima, joka ei muutu hiljaisesti, on pahempi kuin viesti, joka ei saapunut. Päivämäärä väärässä muodossa näyttää yhä päivämäärältä, joten se menee vastaanottajan validoinnin läpi ja päätyy asiakirjaan vääränä päivämääränä.

keep on legitimi, kun vastaanottaja hyväksyy kummankin muodon, ja kun sitä käytetään, jäljitysmerkintä merkitsee muutoksen tahalliseksi, jotta se ei lueta hiljaisesti epäonnistuneena vaiheena.

6.6 Järjestys on tärkeää, ja jäljitys näyttää sen

Kunkin vaiheen näkee edellisen vaiheen tuloksen. Kaksi seurausta, jotka voivat hämätä:

• map-vaihe case-vaiheen jälkeen näkee case-muunnetun arvon, joten sen taulukon avaimet on oltava muunnetun muodossa. Taulukko, jossa on M/F-arvoja, ei vastaa mitään, jos se on kirjoitettu pienillä kirjaimilla, koska arvoa, jota taulukossa ei ole, jätetään koskemattomaksi.
• copy-vaihe kentästä, jonka myöhempi vaihe poistaa, toimii silti, koska se suoritettiin ensin. Käänteinen ei toimi.

• Molemmat ovat näkyvissä vaiheittaisessa näkymässä, joka näyttää koko viestin jokaisen vaiheen jälkeen eikä vain muutosta. Katso virheenkorjaus.

6.7 Ehdotus kartalle ja mitä tehdä ehdotuksella

AI Mapper ehdottaa kartoituksia lähdekenttien ja kohdekenttien välille. Sen määrittävä käyttäytyminen on, että se kieltäytyy: alle luottamusrajansa se pidättäytyy arvauksista, koska varma väärä kartoitus kliinisessä järjestelmässä on pahempi kuin mikään kartoitus.

6.7.1 Anna sille jotain, josta olla ylpeä

Nimi yksin on heikko todiste, vaikka se vastaa täsmälleen. PatientMRN vastaan PatientMRN saa arvon 68, joka pidättäytyy oletusarvoisesta kynnyksestä 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.

Se saa kartoituksen suurimmaksi osaksi valmiiksi. Lopettaaksesi sen, toimita molemmat puoliskot:

• Esimerkkiarvot lähdekentälle yhtäläisyyden jälkeen: ZPI-1 = MRN00412, MRN00998
• Arvon tyyppi, jota kohdekenttä pitää, samalla tavalla: PID-3.1 = mrn. Tyypit ovat mrn, npi, ssn, phone, date ja email.

Näiden avulla moottori voi nähdä, että arvot ovat samaa mieltä kohdekentän tyypin kanssa, ja ehdotus perustuu siihen enemmän kuin nimeen.

6.7.2 Hyväksyntä on yksi kartoitus kerrallaan

Jokaisella ehdotuksella on oma hyväksymisruutu. Ei ole "hyväksy kaikki yli 80%": moottori on jo käyttänyt luottamusta päättääkseen, tarjotaanko kartoitus ja mikä on jäljellä, on tuomio tästä kentästä tässä syötteessä. Numero ei ole tuomio.

Pidäntitys ei voida hyväksyä lainkaan. Sillä ei ole ruutua, ei edes kytkettynä pois päältä, ja näyttö sanoo, että moottori ei tiedä. Jos tiedät vastauksen, kartoita se käsin — se on eri teko kuin ehdotuksen hyväksyminen.

Ehdotus, joka on alle kynnyksesi, näytetään ilman ruutua, merkitty alle sen. Arvoisa lukea — lähes osumat ovat usein kartoitus, jonka halusit, ja piilottaminen jättäisi ihmettelemään, olisiko moottori koskaan sitä käsittelyssä — mutta ei hyväksyttävä, koska kynnyksesi on raja, jonka piirsit.

6.7.3 Kaksi asiaa, joita voit tehdä hyväksymiesi kanssa

Lisää ne kanavaan muuttaa jokaisen kartoituksen kopioimisväliksi. Tämä toimii vain, kun lähde on polku viestissä, kuten ZPI-1, koska vaihe kopioi yhdestä paikasta toiseen viestissä. Vaiheet menevät kanavatiedostoon ja tulevat voimaan, kun se ladataan seuraavan kerran — liikenteessä ei muutu mitään, kunnes silloin. Jokaisen vaiheen kuvaus tallentaa luottamuksen, jolla se ehdotettiin, ja sen, että ihminen hyväksyi sen, mikä tekee siitä vastuullisen kuuden kuukauden kuluttua.

Lataa se reseptinä on oikea vastaus yleisemmälle tapaukselle: kartoitus sarakkeen nimestä, JSON-avaimesta tai valmistajan omasta kentänimestä. Nämä ovat todellisia kartoituksia, ja kanava ei voi lukea tällaista kenttää suoraan, joten vaihe ei voi ilmaista niitä. Resepti tallentaa ne hyväksytyiksi ja niitä voidaan jakaa.

6.8 Miksi ei skripti

Mirth asettaa JavaScript-muunnoksen jokaisen kanavan keskuksi, ja se on joustavin suunnittelu, joka on saatavilla. Perfuse tarjoaa skriptauksen — katso scripts-avain kanavaviitteessä — mutta ei tee siitä tavallista polkua, kolmen käytännön syyn vuoksi.

Julistava vaihe voidaan tarkastella. Perfuse voi kertoa, että vaihe lukee PID-5 ja kirjoittaa PID-8, ennen kuin se suoritetaan, ja se voi näyttää kenttätason jäljityksen, varoittaa, että vaihe osoittaa polkua, jota julistettu tietotyyppi ei voi sisältää, ja generoida vaihekohtaisen toistamisen. Mikään näistä ei ole mahdollista mielivaltaiselle koodille.

Julistava vaihe voidaan päätellä käyttöliittymästä. Rakentaja voi tarjota kentät, jotka ovat olemassa tämän kanavan liikenteessä, ja vaiheen muutos voidaan tarkistaa todellisten historiallisten viestien kanssa ennen kuin se tallennetaan.

Ja julistava vaihe ei voi tehdä mitään, mikä ei liity viestiin. Skripti voi kutsua verkkoon, lukea tiedostojärjestelmää tai riippua päivästä. Kun kanava, joka toimi kaksi vuotta, alkaa tuottaa väärää tulostetta, syy, joka on viestin ulkopuolella, on vaihin diagnosoida, ja mahdollisuuden poistaminen on arvokkaampaa kuin joustavuus, jonka se maksaa.

Missä aito muunnos ei voida ilmaista julistavasti, käytä skriptiä ja hyväksy, että jäljitys näyttää sen yhtenäisenä vaiheena.

6.9 Mitä skripti saa tehdä

Skripti evätään kaikki viestin ulkopuolella, ellei niille anneta lupaa, ja luvat ovat Skriptit-osiossa rakentajassa. Tämä on tarkoituksella toisin kuin Mirth, joka antaa jokaiselle skriptille kaikki — siellä muunnin voi hiljaisesti alkaa lukea tiedostojärjestelmää kopioimisen jälkeen.

On kolme.

Lue ja kirjoita tiedostoja edellyttää, että määrittelet hakemistot, joita se saa käyttää, ja kanava, joka myöntää tiedostojen pääsyn ilman niitä, evätään latauksen aikana. Tämä vaatimus on koko ero tiedoston pääsyssä ja rajoittamattomassa tiedoston pääsyssä: sen myöntäminen ilman hakemistoja kerran saavutti koko tiedostojärjestelmän, mukaan lukien Perfusen oman tietokannan, joka sisältää salasanan hashit, LDAP-palvelutilin salasanan ja OIDC-asiakas salaisuuden. Kanavan luominen vaatii vain editorin roolin, joten eskalaatio valmistui, kun järjestelmänvalvoja käynnisti kanavan.

Kysely tietokantaan käyttää kanavalle konfiguroiduissa yhteyksissä. Skripti, jolla on tämä, voi lukea mitä tahansa niiden tunnistetietojen kanssa.

Reitittää viestejä muihin kanaviin antaa skriptille mahdollisuuden lähettää viesti toiseen kanavaan, mikä on tapa, jolla kanavien välinen silmukka voidaan tehdä.

Kanavalle, jolla ei ole skriptejä, luvan myöntäminen ei tee mitään, ja generoitu tiedosto jättää koko lohkon pois silloin.

6.10 Päivämäärän käsittely, joka ei vastaa sen muotoa

Päivämäärän vaihe muuttaa yhdestä muodosta toiseen, ja mielenkiintoinen kysymys on, mitä tapahtuu, kun arvo ei vastaa muotoa, jonka se väittää olevansa.

Oletusarvo on pysäyttää viesti, ja se on oikea oletus: aikaleima, joka ei konvertoi hiljaisesti, hyväksytään alavirran ja luetaan väärin, mikä on pahempaa kuin viesti, joka epäonnistui äänekkäästi ja on istuva jossakin, missä joku voi nähdä sen.

Jätä arvo sellaisenaan siirtää sen alkuperäisessä muodossa. Alavirran näkee sitten kaksi muotoa yhdessä kentässä, mikä on epäonnistuminen, jonka vaihe oli olemassa estämään — mutta se on oikea valinta, kun kenttä on valinnainen ja kumppani lähettää sen epäjohdonmukaisesti.

Tyhjennä kenttä on rehellisempi ja parempi kuin väärä muoto, mutta vastaanottaja, joka vaatii kenttää, hylkää viestin sen sijaan.

6.11 Skriptikielen

Kolme kieltä hyväksytään, ja valinta riippuu pääosin siitä, onko tehdään migraatio. Arvo menee skriptin language-avaimen arvoksi:

JavaScript on oletusarvo, ja merkintämätön skripti käsitellään JavaScriptina. Se on täällä yhteensopivuuden vuoksi, eikä se ole suositeltava valinta: Mirthin skriptit ovat JavaScriptia, ja sivusto, joka siirtyy, on tuhansia rivejä siitä. Siihen sisältyy myös E4X-tuen tuki, joka on vanha laajennus kielen XML-käsittelyyn, ja joka on käännettävä ennen kuin mitään voidaan parsia.

Lua (lua) on parempi valinta kenellekään, joka ei tee migraatiota. Pienempi suoritusaika, ei prototyyppiketjua, jota voidaan väärinkäyttää, ja kokonaislukutaulukot, jotka vastaavat segmentin ja kentän osoitetta luonnollisemmin kuin JavaScriptin. Sen standardikirjasto on tarpeeksi pieni, jotta se voidaan luetella, mikä tekee sen hiekkalaatikon helpommin luotettavaksi.

WebAssembly (wasm) ei ole kieli, vaan käännetyssä moduulissa olevat tavut, ja kenttä haluaa .wasm-tiedoston tavut eikä lähdekoodia. Käytä sitä, kun muunnos on jo olemassa käännetyssä kielessä, tai kun se on tarpeeksi raskas, jotta suoritusaika on merkittävä.

Sen sopimus on tarkoituksella yksinkertaisin mahdollinen: moduuli lukee viestin standardisyötteen kautta ja kirjoittaa tuloksensa standardilähtöön. Tavut sisään, tavut ulos - mikä on se, mitä jokainen työkalu jo tekee, ja mitä joku, joka testaa moduulia omalla komentorivillään, jo on.

Mitä tahansa moduuli kirjoittaa standardivirheeseen, tulee lokiriveiksi, joten se voi selittää itsensä samalla tavalla kuin skripti, joka kutsuu logger-funktiota.

6.11.1 Mitä tuloste merkitsee

Säännöt ovat samat kaikille kolmelle kielelle eikä uusia sääntöjä kunkin suoritusaikaympäristölle, joten skriptin havaittavissa oleva käyttäytyminen - mitä se voi nähdä, mitä se voi tehdä, kuinka kauan se voi kestää, mitä suodattimen tuomio merkitsee - on määritelty kerran.

Muunnos-, esikäsittelijä- tai kirjoittajamoduulille tyhjä tuloste merkitsee, että viesti on muuttumaton. Skriptin loppuminen jättää viestin koskemattomaksi; tyhjän tulosteen käsittely "viesti on nyt tyhjä" poistaisi liikenteen teknisyyden vuoksi.

WebAssembly-moduulit käännetyt kanavan lataamisen yhteydessä, ei ensimmäisen viestin yhteydessä. Kääntäminen ei ole ilmaista - moduuli, joka on rakennettu kielestä, joka tuo oman suoritusaikaympäristönsä, voi kestää satoja millisekunteja - ja maksaminen latausaikana tarkoittaa, että kanavan ensimmäinen viesti ei ole mystisesti hitaampi kuin loput.

6.12 Jaetut kääntämistaulukot

Saman ongelman toinen puoli: sivuston sukupuolikoodit ja potilasluokat käännetään samalla tavalla jokaisessa kanavassa, joka niitä koskettaa, ja taulukko kanavassa on taulukko, jota vain kyseinen kanava voi käyttää.

# 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

Provenienssi on pointti. Suurin osa siitä, mikä tekee rajapinnasta hankalan ylläpitää, on se, että kukaan ei tiedä, *miksi* koodaus on tietyllä tavalla, ja henkilö, joka tiesi, on lähtenyt. Koodaus, jolla on syy, voidaan väittää; sellainen, jolla ei ole, muuttuu joksikin, mitä kukaan ei uskalla muuttaa ja mitä kukaan ei uskalla poistaa.

Taulukot tehdään ja muutetaan Build → Tables -sivulla sekä tiedostossa. Tallentaminen voimassa oleva taulukko käynnistää uudelleen kanavat, jotka lataavat sen tiedoston, joten seuraava viesti käyttää sitä; luonnos ei käynnistä mitään uudelleen.

6.12.1 Versiot ja voimassaolopäivämäärät

Taulukko voi pitää useita versioita yhdessä nimessä, kussakin omalla version-lla. Viesti valitsee käytettävän version, kun viesti saapuu: hyväksyttyjen versioiden joukosta, joiden päivämäärät kattavat kyseisen päivän (UTC), valitaan se, joka alkoi viimeksi. Niinpä koodin muutos, joka on sovittu ensi kuun alusta, voidaan merkitä jo nyt ja se tulee voimaan itsestään.

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 on approved (oletus), draft (ei käytetä) tai retired (säilytetään asiakirjana, ei käytetä).

- Kaksi samaa nimeä olevaa versiota, joilla on sama versio, tai kaksi hyväksyttyä versiota, jotka alkavat samana päivänä, evätään, kun tiedosto ladataan. - Uuden version tallentaminen ilman alkamispäivämäärää, kun toinen on hyväksytty, ajoittaa sen tältä päivältä, joten se korvaa voimassa olevan version. Versio, joka itse alkoi vasta tänään, poistetaan, koska kaksi versiota, jotka alkavat samana päivänä, eivät jätä sääntöä. - Karttanuksen omat default ja strict käytetään, kun nuosi asettaa ne; muutoin taulukon. - Taulukkosivulla Näytä versiot listaa jokaisen version statuksen, kuka tallensi ja kuka hyväksyi sen, ja Vertaa voimassa olevaan versioon näyttää, mitä versio lisää, poistaa ja muuttaa.

6.12.2 Hyväksyntä

Kun Settings → Data → Mapping tables "Karttaustaulun muutokset vaativat toisen henkilön hyväksynnän" (data.tableApproval) on käytössä, jokainen tallennus on luonnos, ja henkilö, joka tallensi sen, ei voi hyväksyä sitä: joku toinen tekee sen, ja antaa valinnaisesti päivämäärän, jolloin se tulee voimaan. Hyväksytty versio ei voida muuttaa paikallaan; Uusi versio tästä kopioi sen seuraavaan versioon. Hyväksyminen, poistaminen ja poistaminen luonnoksesta kirjataan audit-lokissa, ja hyväksyminen käynnistää uudelleen kanavat, jotka lataavat tiedoston.

6.12.3 Arvoja ei ole taulukossa

Jokainen arvo, jota karttanuosi etsi ja ei löytänyt, lasketaan taulukon mukaan, kanavien mukaan, jotka se tuli läpi, ja kun se nähtiin ensimmäisen ja viimeisen kerran. Taulukkosivu listaa ne, useimmin nähty ensin. Karttaa avaa taulukon, jossa on jo lisätty rivi kyseisellä arvolla; Hylkää poistaa sen, kunnes se nähdään uudelleen. Arvot, jotka ovat yli 64 merkkiä pitkiä, eivät tallenneta (ne eivät ole koodit), ja lista pitää kirjaa siitä, mitä on nähty viestin säilytysajan kuluessa. Lista tallennetaan terminology.db-tiedostoon pääasiallisen tietokannan vieressä.

6.12.4 Koodijärjestelmät

Julkaistut koodijärjestelmät voidaan tuoda niiden julkaisijoiden omista tiedostoista Code systems -sivulla Taulukkosivulla (ylläpitäjille) tai komennolla POST /api/terminology/import?format=… ja tiedosto ruumiina:

Yksikään niistä ei toimiteta Perfusen kanssa: LOINC, SNOMED CT, RxNorm ja CPT jokainen on omalla lisenssillään, ja näytön pyytää tuojalta vahvistusta siitä, että organisaatio omistaa sen (merkitty tuontiin). Tuodut koodit käytetään kolmella tavalla:

• taulukko, joka nimeää source_system tai target_system, tarkistaa sen sisääntulon, kun se tallennetaan, ja koodit, jotka eivät ole järjestelmässä, luetellaan versiossa;

- Etsi koodi etsii koodin tai sanoja nimessä; - FHIR-palvelin vastaa CodeSystem/$lookup- ja CodeSystem/$validate-code-pyyntöjä niille (ks. FHIR-palvelimen asetukset). ICD-10-CM-koodit hyväksytään pisteellä tai ilman.

Kansalliset painokset ja luokittelut. SNOMED CT -painos tuodaan kokonaisuudessaan RF2-paketista: käsitteet niiden todellisella tilalla, jokainen aktiivinen kuvaus ja kieliviitejoukko. Painos löydetään paketista (kansallinen moduuli, jolla on eniten käsitteitä; edition nimeää sen sijaan) ja se tulee versio-URI:ksi. language valitsee, kuka on kunkin käsitteen näyttönimi (sv, da, nl, de, fr, en-GB, en-US ...; muutoin englanti), ja jokaisen kielen näyttönimi ja täysin määritelty nimi säilytetään nimityksinä: $lookup palauttaa ne, ja sen displayLanguage valitsee yhden (de-CH palautuu de:ksi). Perfusen nimettyjä painoksia (Kansainvälinen, UK, Saksa, Alankomaat, Ruotsi, Tanska, Belgia, Irlanti, Norja, Sveitsi, Viro, Espanja) luetellaan GET /api/terminology/editions -kohdassa, moduulien tunnisteita ei tarkisteta julkaistuun lähdekohtaan, joka on merkitty sellaiseksi; muutkin painokset tuodaan, ja ne nimetään moduulien mukaan.

ClaML-tiedostot luetaan UTF-8-, ISO-8859-1-, ISO-8859-15- tai Windows-1252-merkistöllä, kuten niiden XML-ilmukuvaus sanoo. Kunkin kategorian otsikko on sen suositeltu otsikko (sisältäen sisäkkäiset termit); muuntaja (esimerkiksi murtuman sijaintiin viittaava viides merkki) luo sille lisäkoodit, muuntajan otsikolla kategorian otsikon jälkeen, ellei kategoria estä sitä; blocks=true tuottaa luvut ja lohkot myös. ICD-11-luokittelun sarakkeet löydetään nimien perusteella, koska niiden järjestys on muuttunut julkaisujen välillä, ja yhdysmerkit, jotka osoittavat syvyyden, poistetaan otsikoista. Rajattu tiedosto edellyttää delimiter- (, ; | tai tab), encoding- ( utf-8, iso-8859-1, iso-8859-15, windows-1252) ja noHeader=true -arvoja, jolloin sarakkeet numeroidaan 1:stä alkaen. Konsolissa on asetukset UK ICD-10 5. painoksen ja OPCS-4-tiedostojen (TRUD) sekä Ranskan CIM-10 FR -tunnistetaulukon (ATIH) ja ICD-10-BE-vientien hallintaan; niiden kustantajat eivät aina dokumentoi sarakkeitaan, joten tarkistakaa ne tiedoston otsikkorivin kanssa.

Voimassaolopäivämäärät. effective=YYYY-MM-DD tuottaa version, jota käytetään kyseisestä päivästä alkaen (esim. ICD-10-GM joka vuosi 1. tammikuuta): siihen asti haku, joka ei mainitse versiota, vastataan jo voimassa olevalla versiolla, ja näytön päivämäärä näytetään.

ICD-11 WHO:sta. Asiakas on rekisteröity osoitteeseen icd.who.int (Asetukset → Data → Koodijärjestelmät, serve -icd11-client-id ja -icd11-client-secret; -icd11-release, oletusarvo 2025-01), ICD-11-koodit, joita ei ole tuotu, haetaan WHO ICD API:sta (codeinfo, sitten kohteen otsikko) ja säilytetään päivän ajan. Postkoordinoitu koodi (NC72.2&XK9K) tarkistetaan kokonaisuutena, joten ICD-11 ei salli yhdistelmää, ja sen näyttönimet kullekin osalle ("Reisiluun kaulan murtuma (oikea)").

ICD-11 ilman koodien lähettämistä. WHO julkaisee saman API:n säiliönä (whoicd/icd-api, ilmainen, Intel ja Arm). Suorita se omalla verkkoverkollasi ja anna osoite (serve -icd11-url http://icd-api.local, tai ICD API -osoite samassa asetuksissa); asiakasta ei tarvita eikä koodi poistu verkkoverkostasi. Testattu kyseisen säiliön kanssa (versio 2.6.0, julkaisu 2025-01 englanniksi ja ranskaksi).

7 Suodatus

Suodatin päättää, mitkä viestit kanava hyväksyy. Se on yksi lauseke kanavalla, joka arvioidaan viestin jälkeen, kun se on parsittu ja tallennettu, ennen kuin se muunnetaan.

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

Viesti, jonka suodatin hylkää, merkitään tuloksella suodatettu. Tämä on normaali tulos, ei virhe, eikä se laukaise hälytystä tai tuota negatiivista vahvistusta.

7.1 Suodatettu ei ole epäonnistunut

Tämä ero on tärkeä, koska niiden sekoittaminen voi piilottaa oikean ongelman.

Suodatettu viesti oli oikein hylätty: se ei kuulunut tähän kanavaan. Epäonnistunut viesti oli sellainen, jonka kanava olisi pitänyt käsitellä, mutta ei voinut. Jos molemmat olisivat merkitty samalla tavalla, kanava, joka alkaa epäonnistua jokaisessa viestissä, näyttäisi täsmälleen samalta kuin kanava, joka suodattaa suurimman osan liikenteestään, mikä on monien kanavien normaali tila.

Niinpä tilastot laskevat ne erikseen, hälyttämissäännöt käsittelevät ne eri tavoin, ja käyttöliittymä näyttää ne eri väreissä. Suodatettujen viestien määrän kasvu saattaa tarkoittaa, että lähettäjä on alkanut lähettää jotain uutta; epäonnistumisten määrän kasvu tarkoittaa, että jotain on vikana.

7.2 Mitä suodatin voi lukea

Minkä tahansa kentän viestistä, samojen polkujen kautta kuin muunnokset käyttävät. Suodatin suoritetaan ennen muunnoksia, joten se näkee viestin sellaisenaan, kuin se saapui — ei sellaisena, kuin se lähetetään.

Tämä järjestys on tarkoituksenmukainen. Suodatin, joka lukee muunnosten jälkeisiä arvoja, päättäisi, hyväksytäänkö viesti muutosten perusteella, jotka tehtiin oletuksella, että viesti hyväksytään, mikä on kehäpäätelmä ja tuottaa kanavia, joiden käyttäytyminen riippuu kahden asian järjestyksestä, jotka näyttävät riippumattomilta.

7.3 Lausekkeet

Vertailut: ==, !=, ja luvuille <, <=, >, >=.

Jäsenyys: in ("A01", "A03"), joka on selkeämpää kuin ||-ketju ja on muodossa, jonka rakentaja tuottaa.

Yhdistäminen: &&, ||, ja sulkujen käyttö. Negation !-merkillä.

Puuttuminen: polku, jota ei ole, vertautuu epätasan arvoon, myös tyhjään merkkijonoon. Puuttumisen eksplisiittinen testaaminen edellyttää vertaamista absent-arvoon. Tämä on tärkeää, koska puuttuva kenttä ja tyhjä kenttä ovat eri asia, kuten muunnoksessa on kuvattu, ja suodatin, joka käsittelee ne samalla tavalla, hyväksyy viestejä, joita se oli tarkoitettu estämään.

7.4 Virhe suodattimessa on kieltäytyminen

Jos suodatin itse epäonnistuu arvionnan aikana — virheellinen lauseke, joka pääsi validoinnin ohi, tai vertailu, jota ei voida tehdä — viesti hylätään ja virhe merkitään sille.

Hylkääminen hyväksymisen sijaan on turvallisempi, mutta kumpikaan ei ole hyvä, ja tulos merkitään erikseen tavallisesta suodattimen hylkäyksestä, jotta se voidaan hälyttää. Suodatin, joka virheilee jokaisessa viestissä, pudottaa hiljaisesti koko syötteen, eikä se saa näyttää toimivalta suodattimelta.

7.5 Suodata lähde, missä voit

Suodatin suoritetaan viestin jälkeen, kun se on ylittänyt verkon ja parsittu. Jotkut lähteet voivat suodattaa aikaisemmin ja halvemmalla:

• A broker source takes a selector, which filters at the broker. Messages this channel does not want never cross the network at all. On a shared queue that is the difference between reading a hundred messages a day and a hundred thousand.
• A database source's query decides what it returns.
• A file source's pattern decides which files it picks up.

Suodattaminen lähdekohtaisesti on suorituskykyinen päätös, ei oikeellisuuspäätös, ja sillä on yksi kustannus: viesti, joka suodatetaan välittäjässä, ei koskaan merkitä Perfuseen, joten se ei näy viestivarastossa eikä sitä voida tarkastella myöhemmin. Jos tarvitset pystyä osoittamaan, mitä lähettäjä lähetti, suodata täällä sen sijaan, että siellä.

7.6 Suodattimen testaaminen

Suodatinta voidaan tarkastella todellista historiallista liikennettä vasten ennen sen tallentamista. Käyttöliittymä raportoi, montako viimeisen N tallennetun viestin suodatin hyväksyisi, hylkäisi ja virheellistäisi — mikä on nopein tapa selvittää, että lauseke, joka näyttää oikealta, hyväksyy mitään.

Jäljitys näyttää myös kunkin viestin kohdalla, mitä kenttiä suodatin lukee ja mitä arvoja se löytää. Suodatin, joka odottamattomasti hylkää kaiken, lukee yleensä polkua, jota ei ole tässä syötteessä, ja jäljitys nimeää sen.

8 Viestiformaatit

Kanavan dataType päättää, miten tavut muuttuvat viestiksi. Se vaikuttaa parsimiseen, mihin polut viittaavat, miten viesti kirjoitetaan takaisin ulos, ja mihin muunnokset ovat voimassa.

8.1 HL7 v2

Oletus, ja mitä suurin osa tämän manuaalin esimerkeistä käyttää. Segmentit päättyvät rivinvaihtoon, kentät |:iin, komponentit ^:iin, toistot ~:iin.

Kaksi asiaa koodauksesta on tiedettävä, koska ne aiheuttavat hiljaisia virheitä.

Eroittimet eivät ole kiinteitä. Ne määritellään kunkin viestin MSH-1- ja MSH-2-kentissä, ja Perfuse lukee ne sieltä oletuksen sijaan. Lähettäjä, joka käyttää eri kenttäerotinta, parsitaan oikein.

Seuraamus on, että viestin, jonka erottimet on korvattu — useimmiten jonkin sanakäsittelyohjelman tai sähköpostiohjelman korvatessa typografiset näköisleikkauset — käsittely on täysin oikein kenttiin, jotka ovat kaikki väärät. Mitään virheitä ei ilmene. Tästä syystä testing-kohdassa kuvattu esimerkki lukija ilmoittaa, mikä erottinmerkki se löysi, ja kieltäytyy ilmaisemasta varmuutta, kun se on epätavallinen.

8.2 HL7 v3 ja CDA

XML:ää sijaan eroteltu. Polut ovat elementti- ja attribuuttipolkuja eikä kenttäkohtaisia.

V3:ssa arvo on lähes aina attribuutti eikä elementin teksti. Vertailu, joka lukee vain elementin tekstin, raportoi kaksi dokumenttia samanlaisiksi, vaikka syntymäpäivä, sukupuoli ja jokainen tunniste eroavat. Perfusen vertailu lukee molemmat, ja tämän vuoksi: vaihtoehto onnistuu hiljaisesti.

hl7v3-vaihtoehdot ovat kohdassa muotoilureferenssi.

8.3 X12

Segmentit päättyvät ~-merkkiin perinteisesti, ja erotinmerkit määritellään ISA-segmentissä. Kuten HL7:ssä, ne luetaan viestistä oletuksen sijaan.

X12:n rakenne on kirjekuoria kirjeissä — vaihto, toiminnallinen ryhmä, transaktioryhmä — ja yksi vaihto voi sisältää useita transaktioita.

Oletuksena vaihto on yksi viesti. Koko tiedosto saa yhden rivin, yhden tuloksen ja yhden rivin rajapinnassa, riippumatta siitä, montako transaktiota se sisältää.

8.3.1 Mirthin X12-XML

Mirth Connect ja Open Integration Engine näyttävät X12-XML-muodossa: juurielementti X12Transaction (tai EDIMessage, kun syöte ei ala ISA:lla) sisältää erottimina attribuutteja ja yhden elementin kunkin segmentin ja elementin nimellä ISA.01, NM1.03.1 jne. Kanavat ja vastaanottimet, jotka on rakennettu Mirthille, lukevat ja kirjoittavat tämän muodon. Perfuse lukee ja kirjoittaa saman muodon:

• x12: { arrives_as: xml } X12-kanavalla ottaa kyseisen XML:n sisään ja käsittelee sitä edustamansa X12:nä (rakentajan Se saapuu -valinta);
• x12_as: xml määränpäässä lähettää X12:n eteenpäin kyseisenä XML:nä (rakentajan Lähetä se Mirthin X12 XML:nä -valinta);
• perfuse x12 xml [file] ja perfuse x12 from-xml [file] muuttavat komentorivillä.

Muoto on kirjoitettu Open Integration Engine 4.6:n havaitun tulosteen ja julkaisemun perusteella, ja se on tarkistettu sen kanssa: 25 luotua vaihtoa ja 4 säilytettyä esimerkkiä tulevat bitti bittiin niin kuin OIE kirjoittaa ne, ja takaisin (ks. vahvistus). DOCTYPE -kieltäydytään, kuten kaikki XML, jonka Perfuse lukee.

8.3.2 Vaihdon jakaminen

Asetus split tekee kustakin transaktioryhmästä oman viestin, jolla on oma tietue, oma mittari ja oma rivi. Operaattori, joka etsii yhtä korvausta, löytää yhden korvauksen sen sijaan, että hän löytäisi tiedoston, joka sisältää neljäsataa.

Se on oletuksena pois, koska sen käyttöönotto moninkertaistaa kaiken alirakenteen — viestimäärät, rivit, hälytyskynnykset — ja kynnys, joka on säädetty tiedostoille, ei tarkoita enää sitä, mitä se aiemmin tarkoitti. Se pitäisi olla joku, joka on tehty, eikä oletus, joka on peritty.

8.3.3 Kun määrät eivät täsmää

X12 ilmoittaa oman määränsä — montako segmenttiä, montako transaktiota — ja envelope-avain kertoo, mitä tehdä, kun ne eroavat siitä, mitä on todella läsnä. Nämä määrät ovat ainoa mekanismi, jonka X12:lla on havaitsemaan, että puoli korvaustiedostosta on saapunut.

warn on olemassa todellisessa tilanteessa: joillakin kumppaneilla on ollut virheellisiä määriä vuosia muuten täydellisissä tiedostoissa, ja sivuston, joka on pakotettu prosessoimaan niitä, tarvitsee tavan sanoa se ääneen konfiguraatiossa sen sijaan, että kokonaan poistettaisiin validointi.

8.3.4 Transaktiot, joita Perfuse lukee rakenteellisina tietoina

Mikä tahansa X12-vaihto voidaan reitittää, suodattaa ja osoittaa polun perusteella. Nämä transaktiot parsitaan myös nimetyiksi kentiksi, joten kanava voi kysyä, mitä maksaja päätti, sen sijaan, että mikä elementti on sijalla neljä.

Perfuse luo myös 270 -kelpoisuuskyselyn ja 276 -vastineen tilan pyynnön Payers → Claims & auth -kohdassa tai POST /api/x12/eligibility/build - ja /api/x12/claimstatus/build -kautta. Molemmat ovat HIPAA 5010 -versioita (005010X279A1, 005010X212), ja ne luetaan ja tarkistetaan kirjekuorella ennen kuin ne näytetään, eikä kumpaakaan lähetetä suoraan sivulta: toimittaminen on kanavan tehtävä, jossa on mukana kauppatuttava ja sen tunnistetiedot.

8.3.5 Oikeutus ja CAQH CORE -tietosisällön sääntö

271 on luettelo EB-segmenteistä, joista kunkin muodostaa yksittäinen tosiasia: aktiivinen kattavuus, 30 tyypin palvelun 25 dollarin omavastuuvero verkossa tai 800 dollarin jäljellä oleva yksilöllinen vakuutusmaksu verkossa. Lukija kokoaa ne yhteen etukäteen halutun vastauksen - "kattavuus aktiivinen Gold PPO 2000; omavastuuvero verkossa 25 dollaria; yksilöllinen vakuutusmaksu verkossa 800 dollaria" - ja nimeää hylkäyksen (AAA-segmentti) sanallisesti, kertoen, mitä maksaja sanoo tehtäväksi seuraavaksi.

Se tarkistaa myös vastauksen CAQH CORE -kelpoisuus- ja hyödykekoostosäännön mukaan: terveydenhuollon hyödykevakuutuksen kattavuuskyselyssä (palvelutyyppi 30) aktiivinen vastaus tulisi sisältää suunnitelman päivämäärät, suunnitelman nimen, omavastuuveron, vakuutusmaksun, vakuutusmaksun ja jäljellä olevan vakuutusmaksun sekä perussuunnitelman tyypit (1, 33, 35, 47, 48, 50, 86, 88, 98, AL, MH, UC) sekä verkossa ja verkoston ulkopuolella. Kunkin kohdalla ilmoitetaan, onko se täyttynyt vai puuttuu. Tämä on Perfusen tulkinta säännöstä, ja se on hyödyllinen kysymyksiin siitä, miksi maksaja ei koskaan kerro meille vakuutusmaksua - se ei ole CAQH:n sertifikaatti, jonka CAQH:n valtuutetut testaajat suorittavat.

8.3.6 Ennakkohyväksyntä

Perfuse toteuttaa ennakkohyväksynnän kahdesti, tarkoituksella.

FHIR-puoli on se, mitä CMS-0057-F edellyttää maksajilta 1. tammikuuta 2027 mennessä. 278 on se, mitä maksajat hyväksyvät tänään, ja sääntö ei korvaa sitä — Da Vinci PAS on käytännössä tämän transaktion kartoitus, koska 278 on se, mitä hyödyntämisen hallintajärjestelmä puhuu. Moottori, joka lukee vain FHIR-puolen, voi puhua järjestelmien kanssa, jotka tulevat olemaan ja ei niiden kanssa, jotka ovat.

278 -vastaus sisältää lupanumeron, ja se on kenttä, jonka vuoksi koko transaktio on olemassa. Ilman sitä sertifioitu palvelu ei ole laskutettavissa: vaatimus lähetetään ilman lupanumeroa ja se hylätään lupanumeron puutteen vuoksi, mikä tulkitaan alavirrassa kliinisesti perustelluksi hylkäykseksi.

Eväätys ja kieltäytyminen eivät ole sama asia

Tämä on kallein sekaannus transaktiossa, ja Perfuse raportoi ne erikseen.

Molemmat näyttävät "hyväksymättömiltä" kenelle tahansa skannattaessa, ja oikeat toimet ovat vastakkaiset. Valittaminen asiasta, josta kukaan ei ole päättnyt, ei johtaa mihinkään; hylkäyksen uudelleenlähettäminen tuottaa saman hylkäyksen. Parsitun tuloksen nimet, jotka tapahtuivat — denied vastaan not-considered — ja AAA04 sisältää maksajan oman neuvon siitä, onko pyyntö kokonaan palautettavissa.

Osittainen sertifiointi ilmoitetaan partially-certified -arvona eikä se sisälly hyväksyntään. On olemassa laskutuslupanumero, joten se lasketaan hyväksytyksi, mutta sertifioitu määrä ei ole pyydetyssä määrässä — ja käytäntö, joka varaa kuusi istuntoa kolmen hyväksytyn vastaan, huomaa sen neljännen vaatimuksen kohdalla.

Perfuse ei tunnusta toimintakoodia, joka ilmoitetaan unknown -arvona, ei odottavana. Odottava näyttää "odota", ja odottaminen on väärä toimi useimmiten tunnistamattomalle koodille.

Kanava voi reitittää päätöksen suoraan:

filter: HCR-1 == "A3"

Muunnos näiden kahden välillä

Perfuse muuntaa parsitetun 278:n Da Vinci PAS ClaimResponse -muotoon, ja raportoi jokaisen tuomion, jota muunnos tarvitsi, eikä vain tulosta. Muunnos noudattaa kolmea sääntöä:

• Kumpaan päätöstä ei ylennetä. Osittainen sertifiointi säilyy osittaisena, ja pyynnön, jonka maksaja ei halunnut käsitellä, ei tule kieltävä päätös. Molemmat tiivistämismahdollisuudet ovat saatavilla ilmeisessä määrityksessä, ja molemmat ovat väärin kalliissa suunnassa.
• Mitään ei keksitä täyttämään vaadittua kenttää. Sertifioitu tapahtuma, jolla ei ole valtuutusnumeroa, ilmoitetaan sellaisenaan, eikä sille anneta uskottavaa numeroa — keksitty numero tuottaa vaatimuksen, joka hylätään myöhemmin syystä, jota kukaan ei voi jäljittää.
• Päätös, jota käydään vain rivitasolla, käytetään. Maksaja, joka vastaa palvelun mukaan, voi jättää tapahtuman ilman omaa päätöstä; vain tapahtumatason lukeminen ilmoittaisi sen odottavana, ja toiminta odottaa vastausta, jonka se jo on saanut, kun hyväksyntä vanhenee. Jos rivit ovat erimielisiä, vähiten suotuisa voittaa, koska tapahtuma, jossa on kieltävä rivi, ei ole hyväksyntä.

Kapeentaminen kolmeen tilaan — hyväksytty, hylätty, odottava — on saatavilla ja selkeä siitä, mitä se hylkää. Hylätyksi tulemisen kapeentaminen tuottaa "hylätty" ja sanoo sanoilla, että oikea toimenpide on korjattu uudelleenlähettäminen sen sijaan, että valittaisiin.

Tarkistettu PAS 2.2.1:aa vastaan, ei vain itseään vastaan

ClaimResponse on muotoiltu Da Vinci PAS 2.2.1 -profiilin mukaiseksi ja se on tarkistettu virallisella HL7 -validoijalla, joka on ladattu julkaistulla PAS -pakettilla. Ensimmäinen versio oli tarkistettu vain Perfusen omilla testeillä, ja validoija hylkäsi sen kuudella tai kahdeksalla virheellä kunkin resurssin kohdalla. Jokainen niistä on jotain, mitä maksajan PAS -päätepiste myös hylkäisi:

Korjattu tuloste validoi ilman virheitä sertifioinnille, hylkäykselle ja pysäytykselle. Jäljelle jäävät varoitukset ovat validatorin sanoma, ettei se voi ladata X12:n koodijärjestelmiä, joita X12 lisensoi. Laskutuslupanumero kulkee reviewAction.number -kentässä, missä oppaan oma esimerkki laittaa sen, ja preAuthRef -kentässä, kun vastauksessa on vain yksi.

Validoija ei ole osa make check -komentoa, koska sille tarvitaan Java ja oppaan sekä sen riippuvuuksien lataus. Se, mitä se löysi, on testin hallussa: jokainen sääntö, jonka se pakotti, on vahvistettu, joten muutos, joka palauttaa yhden niistä virheistä, epäonnistuu.

Väitteet ja valtuutukset -näkymä muuttaa liimatun 278 -tiedon ja näyttää päätökset, muistiinpanot ja resurssin.

8.3.7 Liitteet ja miksi niiden käsittely vaatii erityishoitoa

CMS-0053-F tekee 275 -tiedosta HIPAA -standardin vaatimuksille, ja siitä on oltava complianssi 26. toukokuuta 2028 mennessä. Se sisältää asiakirjan — toimintakertomuksen, kuvantamisraportin, skannatun lomakkeen —, joka on kytketty vaatimukseen, jonka se tukee.

277 on keskustelun toinen puoli. Maksaja vastaanottaa vaatimuksen, päättää, että sille tarvitaan asiakirjaa, ja lähettää 277 -pyynnön asiakirjasta; toimija vastaa 275 -tiedolla.

Kanava voi reitittää tilakoodin suoraan, koska STC01 on yhdistetty ja sen toinen komponentti on tila. Kirjoitettu kanoniseen muotoon, koska komponenttia osoitetaan pisteellä ja kahta notaatiota ei voida sekoittaa — STC-1.2 on elementti 1, komponentti 2:

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

Nuo ovat koodit, jotka tarkoittavat yksiselitteisesti, että asiakirjaa halutaan. Tilakategoria STC-1.1: ssä ei käytetä yksinään: R4 tarkoittaa asiakirjapyynnön joissakin toteutusoppaissa ja "esiinlähetetty toisaalle" toisissa, joten suodatin kategoriassa yksinään laittaisi lopulliset vaatimukset jonkun jonoon, jotta joku voisi tarkastella niitä.

Kaksi tunnistetta päättää, liitetäänkö liite koskaan vaatimukseensa, ja molemmat ilmoitetaan: liiteohjausnumero, jonka toimija on laittanut alkuperäiseen vaatimukseen, jotta se ilmoittaisi, että asiakirjaa seuraa, ja jäljitysnumero, joka vastaa maksajan pyyntöä. Liite, joka saapuu kummankaan ilman, tallennetaan ja ei koskaan liitetä mihinkään, kun taas vaatimus vanhenee.

006020 -lomake, joka on sääntö, jota otetaan käyttöön

CMS-0053-F ottaa käyttöön version 006020, ja sen 275 eroaa 005010 -lomakkeesta kahdella tavalla, jotka ovat merkittäviä.

• Lasti on BDS: ssä, ei BIN: ssä. BDS01 nimeää suodattimen, ASC tai B64. BDS02 on pituus ja BDS03 data.
• Lasti on MIME -yksikkö, jossa on otsikot, jotka sanovat, mikä asiakirja on, ja base64 -ruumis. B64: n kanssa yksikkö itse on myös base64.

Perfuse purkaa kohteen ja raportoi asiakirjan sisällön, sen sisältötyypin ja tiedostonimen. Raportoidut tavut ovat täsmälleen ne, jotka lähettäjä on käärittänyt. Kohteet, joita ei voida purkaa, jättävät raakapaketin paikalleen ja ilmoittavat syyn.

Rakentaminen 275. Perfuse myös rakentaa 006020X314 -liitteitä: joko vapaaehtoista liitettä, joka seuraa vaatimusta, tai vastausta maksajalle 277 -pyynnöstä. Ero on BGN01 02 vastaan 11, ja siinä, kantavatko TRN02 vaatimuksen PWK06 vai 277: n TRN02. Jokainen rakennettu vaihto puretaan takaisin ennen kuin se palautetaan, ja vastaus kertoo, onko asiakirjan sisällä se, joka meni sisään.

Rakenne tulee kahdesta julkaistusta ohjeesta 006020X314: CMS esMD -oppaasta ja UnitedHealthcare -oppaasta. Se ei tule X12 -teknisestä raportista, jota X12 lisensoi, ja jota tämä projekti ei omista.

• Missä kaksi oppasta ovat samaa mieltä, Perfuse seuraa niitä.
• Missä ne eroavat, se tyytyy kumpaankin, jos se voi. CAT02 on HL HL7 -dokumentille, jota esMD käyttää, ja IA kuvalle, jota UnitedHealthcare käyttää.
• Muutoin se lähettää vain valinnaisen segmentin, kun se on annettu arvo: esMD: n REF*X1 -vaatimus ja UnitedHealthcare -palvelupäivämäärä DTP*472.

Todennus teknisen raportin vastaisuutta ei ole. Kumppanin ohje ohjaa.

8.3.8 Sähköiset allekirjoitukset liitteissä

CMS-0053-F ottaa myös allekirjoitusstandardin käyttöön 45 CFR 162.2002 (e): HL7 -toteutusopas CDA -julkaisu 2, digitaaliset allekirjoitukset ja oikeuksien delegointi, julkaisu 1. Se koskee allekirjoituksia, jotka laitetaan liitteiden tietoihin, kun ne lähetetään HIPAA -liitännäisissä, 26. toukokuuta 2028 alkaen. Maksaja ei voi pyytää enempää kuin opas tekee.

Perfuse allekirjoittaa C-CDA: n samalla tavalla sen sisäänmenoon 275: ssä ja tarkistaa allekirjoitukset jokaisessa C-CDA: ssä 275: ssä, jonka se lukee.

• Mikä allekirjoitetaan. Koko asiakirja paitsi legalAuthenticator ja authenticator -osallistujat, joten jokainen myöhempi allekirjoittaja jättää aiemmat allekirjoitukset koskemattomiksi. Allekirjoitus kertoo sen XPath Filter 2.0 -muodon kautta, jonka jokainen XML-allekirjoituskirjasto voi arvioida.
• Mihin se menee. Base64-muodossa sdtc:signatureText -kentässä allekirjoittavan osallistujan kanssa ja yhden rivin selkeän tekstin kuvauksella. Allekirjoittaja on asiakirjan oikeudellinen todistaja, jos sillä on allekirjoittamaton, muuten uusi authenticator.
• Mikä se ilmoittaa. Allekirjoittajan sertifikaatti, aika UTC:ssa, rooli NUCC:n tarjoajan taksonomiasta ja tarkoitus ASTM E1762:sta. Tarkoitus oletusarvoisesti *Tekijän allekirjoitus* oikeudelliselle todistajalle ja *Yhteis tekijän allekirjoitus* muutoin, kuten oppaan omassa esimerkissä.
• Kuinka kauan se kestää. Oppaassa pyydetään XAdES-X-L:ää, joka sisältää kaiken, mitä maksaja tarvitsee allekirjoituksen vahvistamiseen verkkoon käsiksi käymättä. Se on sertifikaattipolku, OCSP-vastaus tai CRL CA:sta ja kaksi aikaleimaa aikaleima-auktoriteetilta. Perfuse hakee peruutusdatan sertifikaatin osoitteista ja aikaleimat -tsa-url:sta.

Jos jokin niistä on käytettävissä, allekirjoitus tehdään ja se pitää. Tulos nimeää XAdES -muodon, jonka se saavutti, ja kertoo, mikä esti sen saavuttamasta X-L: ää: esimerkiksi itse allekirjoitettu varmenne (ei CA: ta pyydä) tai ei aikaleima-auktoriteettia.

Avain on -signing-cert ja -signing-key. Laita CA -varmenteet allekirjoittajan jälkeen samassa tiedostossa, jotta polku kulkee allekirjoituksen mukana. Allekirjoitukselle, joka tarkoittaa DSDR: ää, varmenne pitäisi nimetä klinikoitsija, heidän NPI: nsä kanssa, eikä palvelinta. Allekirjoittaminen on hallinnollinen toimi, kuten minkä tahansa asiakirjan allekirjoittaminen.

Oppaassa ei mainita nimeämistilaa omille elementeille. Perfuse laittaa digitalSignature, authorizedSigner ja SignaturePurpose urn:hl7-org:sdtc -nimeämistilaan. Se ilmoittaa myös tarkoituksen XAdESsitoumustyypinä ASTM OID:llä, jota XAdES-työkalut ymmärtävät. Oikeuksien delegointi, jossa edustaja allekirjoittaa SAML-vakuutuksella valtuutetun allekirjoittajan toimesta, ei tuoteta, ja vastaanotettu ilmoitetaan vahvistamattomaksi.

Tarjoajan NPI tarkistetaan sen tarkistusmerkkiä vastaan. Maksaja vastaa liitettä vaatimukseen osittain sen numeron perusteella, ja virheellinen numero jättää liitteen vastaamattomaksi, kun taas vaatimus hylätään puuttuvan dokumentaation vuoksi.

Näkymä Vaatimukset ja todennus luo 275: n liittäen C-CDA: n tai ladatun tiedoston, valinnaisesti allekirjoittaen C-CDA: n, ja lukee yhden takaisin jokaisen allekirjoituksen löydöksillä. Mitään sivulla ei lähetetä mitään: vaihto käännetään takaisin toimittamaan kanavan kautta, jossa on kumppani, tunnistetiedot ja audit-reitti.

8.3.9 Binäärisegmentit

BIN-segmentti sisältää raaka bitejä, ja raaka biteissä on erottimia. Jokainen muu X12-segmentti päättyy segmentin päättymiseen, joten tavallinen parseri löytää segmentit etsimällä yhtä merkkiä; liitetiedostoa ei voida löytää sillä tavoin. PDF-tiedosto, joka sisältää ~-merkin, katkeaa palasiin, ja kunkin palasen muodostaa rakenteellisesti validin segmentin — niin asiakirja katkeaa, jokainen segmentti siitä eteenpäin on epäkohdennettu, eikä mikään raportoi virhettä.

Perfuse lukee segmentin ilmoittaman tavumäärän ja ottaa täsmälleen niin monta tavua. Kaksi seurausta, jotka ovat tiedostettavissa:

• Ilmoitettu pituus, joka ei vastaa dataa, hylätään, mainiten molemmat numerot. Olennainen kysymys on, oliko lähettäjän lukumäärä väärä vai rikkoontuiko tiedosto kuljetuksen aikana, ja vain nämä kaksi numeroa vastaavat siihen.
• BDS, 006020 binäärisegmentti, pitää lukumääränsä BDS02: ssä ja datansa BDS03: ssä. Se hylättiin, kunnes se voitiin vahvistaa julkaisemalla lähteellä eikä muistella, ja nyt kaksi lähdettä vahvistavat sen: CMS esMD Companion Guide - BDS -taulukko ja UnitedHealthcare -opas.

EsMD-opaan oman näytevaihdon ilmoittaa 16 tavua samalle 53-tavuiselle payloadille, jota sen taulukko laskee oikein 53: ksi. Perfuse hylkää tämän näytteen, kuten se pitääkin. Testi pitää sekä taulukon esimerkin että näytteen kirjoitusvirheen, joten muutos kummassakin suunnassa huomataan.

8.4 FHIR

8.4.1 Mikä HL7 v2 -viesti muuttuu

Viestityyppi päättää, mitä tuotetaan, ja jokainen muunnos raportoi tarvittavat arviot muistiinpanoina paketin vieressä.

Kaikki muu tuottaa potilaan ja varoituksen, jossa mainitaan viestityyppi, jota ei ole kartoitettu.

Ajanvaraus. Varaus, uudelleenvaraus, peruutus ja no-show kaikki päätyvät samaan ajanvaraukseen. Sen identiteetti tulee ajanvarauksen omista numeroista SCH-1: ssä ja SCH-2: ssä, ei koskaan viestistä, joten peruutus päivittää varauksen. Vaihtoehto olisi toinen, peruutettu ajanvaraus live-ajanvarauksen rinnalla, joka näyttää potilaan varanneen aikaslotin, joka ei enää ole olemassa.

• Tila. Täyttäjän tila SCH-25: ssä päättää sen, ja laukaisutapahtuma käytetään vain, kun se on tyhjä.
• Estetty aikaslotit. Estetty aikasloti ei ole ajanvaraus potilaalle, eikä se tuota mitään.
• Aloitusajankohta. Se luetaan ensin AIS: stä, AIG: stä, AIL: stä tai AIP: stä, sitten SCH-11: stä, koska versio 2.5 siirsi sen ja syötteet eivät kaikki siirtyneet sen mukana.
• Kesto. Kesto yksikössä, jota Perfuse ei tunnusta, jätetään pois, eikä sitä arvata.

Asiakirjat. Tekstin muistiinpanot (TX, FT, ST) säilyttävät rivivälinsä, myös tyhjät rivit, koska tyhjä toisto muistiinpanossa on kappaleväliraja.

• Upotetut asiakirjat. Upotettu PDF, TIFF tai JPEG (ED) kuljetetaan tavu tavulta. Base64, joka ei ole kelvollista base64: ää, hylätään sen sijaan, että se välitetään eteenpäin.
• Tyypit. Asiakirjan tyyppi TXA-2: ssä säilytetään lähettämällä ja siirretään selkeäksi vastineeksi, jota US Core käyttää.
• Allekirjoitus. Muistiinpano, jota kukaan ei ole allekirjoittanut, on preliminary, ja T11 tekee asiakirjasta entered-in-error.
• Sisältö puuttuu. Ilmoitus, jolla ei ole sisältöä (T01, T03 ja muut parittomat tapahtumat), ei tuota DocumentReferencea. FHIR vaatii sisältöä, ja tyhjä liite näyttäisi muistiinpanolta, mutta se ei sanisi mitään.

Tämä on se, mitä CMS Interoperability Framework -kriteeri 14 pyytää: kaavion muistiinpanot ja kliiniset asiakirjat palautetaan FHIR-liitteinä.

Rokotukset. Annos ei koskaan ilmoiteta annetuksi, kun viesti sanoo toisin.

• Hylätyt annokset. Hylätty tai ei-hallittu annos (RXA-20 RE tai NA) on not-done, ja syy on RXA-18: sta.
• Poistot. Poistettu annos (RXA-21 D) on entered-in-error.
• Historialliset tiedot. Tiedosto, joka on transkriboitu jostakin muualta (RXA-9 muu kuin 00), ei ole ensisijainen lähde.
• Tuntemattomat määrät. Määrä 999 tarkoittaa tuntematonta, ei 999.
• Reitit ja sijainti. Jokainen annos ottaa reitin ja sijainnin RXR: stä sen jälkeen, joten viesti, jossa on kaksi annosta, ei anna toiselle annokselle ensimmäisen annoksen reittiä.

Hankalat syötteet. Kukin näistä ilmoitetaan muistiinpanoissa sen sijaan, että ne päätettäisiin hiljaisesti:

• Tunnisteet. PID-2 ja PID-4, jotka poistettiin v2.7:n jälkeen, mutta jotka lähetetään edelleen, säilytetään kuten PID-3. CX.7 ja CX.8 muuttuvat Identifier.period-muotoon. Sijoittava viranomainen, joka sisältää ISO OID:n (AUSHIC&2.16.840.1.113883.3.879&ISO), muuttuu urn:oid:-muotoon. Tyyppikoodi, joka ei ole HL7-taulukossa 0203, säilytetään tekstinä, eikä se merkitä yhdeksi.
• Yhdistäminen. MRG-yhdistämisessä (esim. A40 ja sen sukulaiset) lähetetään myös vanhentunut tietue, joka on epäaktiivinen, ja Patient.link on molemmin puolin. Muiden tapahtumien, kuten A08, kohdalla ei tehdä yhdistämistä, ja varoitus ilmoittaa, että edellinen tunniste on edelleen aktiivinen.
• Ajat. Syntymäaika PID-7:ssä siirtyy patient-birthTime-laajennukseen. Aikaleima, jolla ei ole offsetia, ottaa määritetyn aikavyöhykkeen, muutoin offsetin MSH-7:stä (v2 olettaa lähettäjän paikallisen ajan), muutoin UTC. Syntymäaika on poikkeus: ilman offsetia mitä tahansa kolmesta jätetään pois sen sijaan, että se merkitään UTC:ksi, koska väärä offset voi siirtää syntymän toiselle päivälle. birthDate säilytetään, ja varoitus ilmoittaa, että aika poistettiin ja että aikavyöhykkeen asettaminen syötteen mukaan säilyttää sen.
• Tulokset. Tekstikokonaisuuksien toistot yhdistetään rivivälilyönneillä. ED-tulos tai koodattu tulos, jonka arvo on ilmiselvästi Base64, muuttuu DocumentReferenceksi, jota Observation viittaa derivedFrom:ssa, koska R4-Observationilla ei ole liitetiedostoa. SN-vertailija = poistetaan tarpeettomana; <> säilyttää tekstin, koska määrä ei voi sanoa "ei yhtä suurta kuin".
• Vierailut. A08-vierailla, jolla on poistumispäivämäärä (PV1-45), on valmis kohtaaminen. Puuttuva tai tuntematon potilasluokka on nulli UNK, koska R4 vaatii luokan.
• Z-segmentit mainitaan varoituksessa, koska niille ei ole standardia kartaa.

• Nimet. Kun lähettäjä jakaa sukunimen (XPN.1, XCN.2) osiin - sukunimen etuliite ja sukunimi, henkilön oma ja puolison, kuten hollantilaiset ja flaamilaiset nimet lähetetään - family on koko nimi ja osat menevät HL7:n sukunimen laajennuksiin (humanname-own-prefix, -own-name, -partner-prefix, -partner-name).
• Toimenpiteet. PR1 muuttuu menettelyksi, jonka tila on unknown, koska ADT ei kerro, suoritettiinko se vai suunniteltiinko; anestesialääkäri (PR1-8) ja kirurgi (PR1-11) ovat suorittajia, joilla on SNOMED CT -roolit. Myös OPS-koodi saa SNOMED CT -kategoriansa luvusta HL7 Deutschlandin OPS-SNOMED-Category -kartan kautta, jota ISiK vaatii.

8.4.2 Mikä sivusto lisää: nipun skripti

Kansallinen profiili usein haluaa, mitä HL7 v2 -viesti ei sisällä: sairaalan IK-numero tai ODS-koodi, mikä on kontaktitason vierailu (ISiK), onko annettu nimi etunimi vai alkukirjain (hollantilainen nl-core). Perfuse ei arva näitä. fhir-kohdepaikan bundle_script on, missä sivusto kirjoittaa ne: JavaScript, jota suoritetaan kullekin muunnetulle Bundlelle, bundle-nimisenä, ennen kuin se validoidaan ja lähetetään. Mitä skripti jättää, se menee ulos, tarkistettuna kuten mikä tahansa muunnos, ja skripti, joka heittää poikkeuksen, epäonnistuu viestin käsittelyssä kuten mikä tahansa muunnin. Konsolissa se on kohdepaikan *Lisää, mitä järjestelmäsi tietää* -kohtaa alla.

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.

Nippu menee Perfusen mallin läpi palatessaan, joten skriptin muutokset tarkistetaan ja kirjataan kohdepaikan FHIR-versioon. Jäseniä, joilla malli ei ole kenttää, säilytetään sellaisena, jollaisena skripti ne kirjoitti, myös tietotyyppien sisällä.

8.4.3 US Core 9.0.0 ja USCDI v6

-us-core (ja claim_us_core fhir-kohdepaikassa) asettaa US Core -profiilin meta.profile-kenttään, mutta vain resursseille, jotka on tarkistettu kyseisen profiilin vastaisuutta ja havaittu täyttävän sen vaatimukset. Resursseja, jotka eivät täytä vaatimuksia, muunnetaan ja lähetetään ilman vaatimusten täyttymistä, ja huomautus ilmoittaa syyn, kuten "US Core vaatii kohtaamisen tyypin, mutta tämä kohtaaminen ei sellaista sisällä". Tarkistukset on transkriboitu US Core 9.0.0:sta, jonka ONC:n 2026 Standards Version Advancement Process on hyväksynyt USCDI v6:lle. Ne kattavat Potilaan, Kohtaamisen, laboratoriotutkimuksen Havainto ja Diagnostiikkiraportti, Näyte, Toimija, Organisaatio, Sijainti, Rokotus, Asiakirjaviranomainen, kohtaamisdiagnoosi ja Yliherkkyys.

Mitä muunnin sisältää USCDI v6 -dataluokan mukaan:

Ei siirretä, koska v2-viestit näistä tyypeistä eivät sisällä niitä tai Perfuse ei kartoita niitä: Lääkkeet, Toimenpiteet, Tavoitteet ja Preferenssit, Terveystilan arviot, Hoitosuunnitelma, Perheen terveyden historia, Lääkinnälliset laitteet (UDI), Terveydenhuollon vakuutustiedot, Elintoimintojen seuranta erillisenä profiilina ja Provenienssi.

8.4.4 R4 molempiin suuntiin

FHIR-palvelin, joka ilmoittaa R4:n, hyväksyy R4:n. Tämä ei ollut totta Kohtaamisille asti tähän julkaisuun. Palvelin muunsi sen, mitä se palveli, R4:ksi, mutta luki sen, mitä se vastaanotti, ikään kuin se olisi jo sisäisessä muodossaan, joten R4 Kohtaaminen hylättiin virheellä 400. Samoin hylättiin jokainen paketti, jonka Perfuse:n oma ADT-muunnos tuotti, koska jokainen sisälsi Encounter.class:n, jonka R4 kirjoittaa yhtenä koodauksena.

Se havaittiin ensimmäisen kerran, kun joku lähetti muunnetun ADT:n Perfuse:n omaan R4-palvelimeen. Testi tekee nyt tämän jokaiselle kartoitetulle viestityypille, ja toinen tarkistaa, että kaikki, mitä kirjoitetaan R4:ksi, luetaan takaisin muuttumattomana.

8.4.5 Kansainvälinen potilaskatsaus

GET /fhir/Patient/{id}/$summary tai GET /fhir/Patient/$summary?identifier=system|value palauttaa Kansainvälisen potilasyleiskatsauksen (HL7 IPS 2.0.0): FHIR document-pakkauksen, jonka Composition luettelee potilaan aktiiviset ongelmat, allergiat, lääkkeet, immunisoinnit, tulokset, elintoimintojen seuranta, toimenpiteet, laitteet, menneet sairaudet, sosiaalinen historia ja hoitosuunnitelmat, kussakin on luettava kertomus. Se on lyhyt tietue, jonka kliinikko, joka ei ole koskaan tavannut potilasta, lukee ensin, ja se on yleiskatsaus, jonka Euroopan terveydenhuollon tietotila vaihtaa maiden välillä vuodesta 2029 alkaen.

Se rakennetaan siitä, mitä FHIR-kauppa sisältää, ja mitään ei keksitä:

• Tietueet, jotka on merkitty entered-in-error, jätetään pois.
• Ratkaistu tila siirtyy menneiden sairauksien alle, eikä se ole ongelma.
• Lääkemääräys, joka on keskeytetty tai valmistunut, on historia, eikä se ole nykyinen lääke.
• Kolme IPS:lle vaadittavaa osiota (ongelmat, allergiat, lääkkeet) ovat aina läsnä. Kun jokin niistä on tyhjä, osio sisältää koodatun tyhjän syyn unavailable ja ilmoittaa, että palvelin ei sisällä tietoa, "mikä ei tarkoita, ettei sitä olisi olemassa". Tyhjä allergialuettelo ei saa koskaan tulkita "ei tunnettuja allergioita".
• Toimijat, organisaatiot, lääkkeet ja sijainnit, joita merkinnät osoittavat, sisällytetään, jotta asiakirja voidaan lukea itsenään.

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.

Vaihda → Terveydenhuollon linkit → Jaa täyttää sisällön potilaan yleiskatsauksella: kirjoita potilaan FHIR-tunniste ja valitse Käytä potilaan yleiskatsausta, sitten lue se ja luo linkki. Sen rakentaminen auditioidaan fhir.summary-muodossa.

8.4.6 Siirtoyhteenvetoja jälkeenhoitoon (PACIO)

Kun potilas lähtee sairaalasta hoitokotiin, kuntoutusyksikköön tai kotihoitoon, sairaalan EHR lähettää C-CDA:n: siirtokatsauksen, lähtökatsauksen tai CCD:n. Perfuse muuttaa tämän asiakirjan PACIO:n siirtokatsauksen ohjeen kuvaamaksi siirtokatsaukseksi (hl7.fhir.us.pacio-toc 1.0.0): yksi FHIR R4 document -paketti, jossa on US Core 8.0.1, jonka vastaanottavan laitoksen järjestelmä voi tallentaa ilman, että kukaan lukisi XML:ää.

• Jokainen oppaan viidestätoista luvusta on läsnä, kussakin on oma teksti, oppaan järjestyksessä: etukäteen annetut ohjeet, allergiat, käyttäytymisen terveys, toimintakyky, rokotukset, potilasohjeet, lääkekuitti, hoitosuunnitelma, ongelmat, toimenpiteet, siirtoon johtaneet syyt, tulokset, sosiaalinen historia ja elintarpeet.
• Luvuksi kutsutaan dokumentin osaa, jota ei ole täytetty. Se lähtee tyhjänä koodatulla syyllä unavailable ja lauseella "Lähetetyn asiakirjan ... kohta puuttuu". Tyhjä allergialuettelo ei saa olla merkitty "ei tunnettuja allergioita".
• Pelkästään tekstiä sisältävä luku säilyttää tekstin ja ei saa kohtia. Proosa ei muutu koodatuksi tietoksi. Toimintakyky, käyttäytymisen terveys (C-CDA:n mielentilan luku), etukäteen annetut ohjeet, lääkekuitti, hoitosuunnitelma, potilasohjeet, siirtoon johtaneet syyt ja sosiaalinen historia lähetetään tällä tavoin tällä hetkellä; huomautukset kertovat niin kullekin.
• Koodatut kohdat muuttuvat resursseiksi samojen sääntöjen mukaan kuin tavallinen muunnos: allergiat (US Core AllergyIntolerance), ongelmat ja lähtödiagnoosit (US Core Condition, ongelmaluettelo tai kohtaamisdiagnoosi), toimenpiteet, rokotukset, tulokset, elintarpeet ja lääkkeet PACIO-lääkeluettelona MedicationStatements (104204-3, lähtölääkkeiden luettelo, lähtölääkkeiden kohdasta; 104202-7, aktiivinen lääkeluettelo, muutoin).
• Elintarpeet FHIR-muodossa. Yhdessä mitattu systolinen ja diastolinen paine muuttuvat yhdeksi verenpaineen paneeliksi (85354-9) kahdella komponentilla, ja tarkempi koodi (mittauksen kehon paino, 3141-9) kantaa myös FHIR:n elintarpeiden profiilin korjausta (29463-7), alkuperäisen ohella.
• Kuka ja mistä. Asiakirjan kirjoittaja muuttuu Compositionin kirjoittajaksi (Practitioner, NPI:n kanssa, kun sen tarkistusmerkki on voimassa), sen haltija haltija-organisaatioksi, sen kattava kohtaaminen sairaalahoitona, jonka yhteenveto sulkee. Asiakirja, jolla ei ole henkilöä kirjoittajana tai haltijana, hylätään: oppaan edellyttää molempia, ja Perfuse ei laita nimeä kliiniseen tietueeseen, jota kukaan ei ole antanut.
• Negation säilyttää merkityksensä. "Ei tunnettuja allergioita" (negatoitu allergia mille tahansa aineelle) lähetetään SNOMED CT 716186003; yhdelle lääkeaineelle negatoitu allergia hylätään, koska FHIR ei voi sitä sanoa ja resurssi sanoisi vastakkaisen; negatoitu ongelma on refuted.

Kolme tapaa tehdä yksi:

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

Tarkistettu virallisen FHIR-vahvistimen kanssa TOC 1.0.0 Bundle-profiilia vasten, HL7:n omia C-CDA-esimerkkejä (siirtoyhteenveto, lähtöyhteenveto ja CCD). Yksi virhe, jonka se ilmoittaa, on oppaassa: jokainen elintarpeet vastaa sekä simple-observation- että vital-signs-Bundle-kohtia, joten se ei voi välttää lähetettävänä. Ei vielä tehty: teksti-kohdien muuttaminen koodatuksi resursseiksi (toimintakyky, mielentila, hoitosuunnitelma, laitteet) ja oppaan TOC DocumentReference, joka indeksoi tallennetun siirtoyhteenveto.

8.4.7 Tilaukset

-fhir-subscriptions-valinnan kanssa FHIR-päätepiste lähettää ilmoituksia, kun Kohtaaminen tai Ajanvaraus luodaan tai muutetaan. Se noudattaa FHIR Subscriptions R5 Backport IG for R4:ää, jota CMS Interoperability Framework -kriteeri 15 ja TEFCA:n FHIR-tiekartta käyttävät ajanvaraus- ja kohtaamisilmoituksissa.

Asiakas luo Subscription-nimisen aiheen ja valinnaisen suodattimen, kuten Encounter?patient=Patient/123. Aiheet on lueteltu kykyilmoituksessa:

Suodatin, joka nimeää jotain muuta, hylätään, ei ohiteta. Ohitettu suodatin on tilaus, joka ilmoittaa jokaisesta potilaasta, kun asiakas pyysi yhdestä.

Toteutuksen perustuvat ominaisuudet:

• An acknowledged change is never a lost notification. The notification is recorded in the same database transaction as the change it describes, and delivered from there, so it survives a restart. A test writes an Encounter, starts a new server on the same database, and checks the notification arrives.
• Notifications arrive in order, and gaps are visible. Event 2 is not sent before event 1 is accepted, and each notification carries the running count, so a receiver can tell when it has missed one.
• The server decides when a subscription is active. A new subscription is requested, and becomes active only when the endpoint accepts a handshake. A client that asks for active gets requested. A refused handshake is tried again four times over about fifteen seconds before the subscription is an error: it goes out the moment the subscription is stored, often before the client that created it is listening.
• A full-resource notification carries the version that changed. A discharge notification carries the discharge, not whatever the Encounter had become by the time delivery succeeded.
• Failure is bounded. A refused delivery is retried with a growing delay. After ten consecutive failures the subscription goes to error: later changes are counted but not queued, and updating the subscription resumes delivery from the oldest held notification. The count then shows how many were missed.

Mikä asiakas voi tehdä palvelimelle, on tarkoituksella rajoitettu:

• Päätepisteet on oltava https, ellei operaattori anna -fhir-subscriptions-allow-http:a, joka on testivastaanottimelle.
• Lähtökäytäntö sovelletaan, kun tilaus luodaan, uudelleen jokaisella toimituksella ja osoitteeseen, johon jokainen yhteys todella yltää (joten nimi, joka muuttaa mitä se ratkaisee välillä tarkistuksen ja yhteyden, on edelleen kielletty); uudelleenohjauksia ei seurata.
• Kuormalle on oletuksena id-only, joka kertoo, mikä muuttui, ja antaa vastaanottajalle noutaa sen omilla tunnistetiedoilla.
• Mitään, mitä vastaanottaja lähettää takaisin, ei näytetä kenellekään, vain sen tilakoodi.

Se on pois, ellei sitä pyydetä, koska kun se on päällä, FHIR-asiakas voi tehdä tämän palvelimen lähettämään potilastietoja URL-osoitteeseen, jonka asiakas on valinnut. Sille tarvitaan R4-päätepiste, joka hyväksyy kirjoitukset, ja se kieltäytyy käynnistymästä muuten.

Toteutukseltaan puuttuu, joten kukaan ei tarvitse selvittää sitä kokeilemalla:

• kanavia muuta kuin rest-hook
• sydämentykytyksiä
• poistamisilmoituksia
• $status- ja $events-operaatiot

Tilausnäkymä näyttää kunkin tilauksen aiheen, suodattimen ja päätepisteen, montako tapahtumaa siinä on ollut, montako niistä on hyväksytty ja montako odottaa, ja viimeisen syyn, miksi se hylättiin. Otsikkoarvoja ja päätepisteen kyselymerkkijonoa ei paljasteta, koska siinä on tilaajien tunnistetiedot.

8.5 NCPDP Telecommunication Standard

Apteekeille lähetettävät korvausvaatimukset. Kiinteän leveyden otsikko, jota seuraa muuttuvat segmentit.

Kaksi yksityiskohtaa, jotka ovat tärkeitä, ja molemmat ovat helppoja väärinkäsittää ja tuottaa uskottavia tuloksia:

Otsikko on tarkalleen 56 tavua ja kiinteäleveyinen. Lyhyt otsikko ei voida havaita pelkästään pituuden perusteella, koska lyhennetty otsikko ja sen jälkeen tulevat segmentit ylittävät edelleen 56 tavun. Havaitsemisen perusteena on se, että oikea otsikko ei sisällä erottimia, joten otsikkoa skannataan erottimen löytämiseksi ja viesti, jossa on erottin, hylätään ja ilmoitetaan montako tavua siinä puuttuu.

0x1E ja 0x1C ovat ryhmän ja kentän alkumerkit, eivät erottimia. Niiden käsittely erottimina siirtää jokaista kenttää yhden paikan vasemmalle, ja useimmat tuloksena olevat arvot säilyvät uskottavina — määrä päätyy paikkaan, jossa odotettiin päivien määrää, ja molemmat ovat numeroita.

8.6 NCPDP SCRIPT

Sähköiset reseptit, XML-muodossa. Sisäinen paketti on nimeltään eprescribe, koska script oli jo varattu JavaScript-moottorille.

Keskeinen turvallisuuskysymys on korvauslippu, ja se lukee vastakkaiseen suuntaan kuin intuitio: langalla 0 tarkoittaa, että korvaus on sallittu, ja 1 tarkoittaa, että lääke annetaan sellaisenaan.

Puuttuva korvauslippu hylätään sen sijaan, että se asetettaisiin oletukseksi. Molemmat mahdolliset oletukset voivat aiheuttaa haittaa potilaalle — toinen voi antaa geneeristä lääkettä, vaikka määrääjä edellytti alkuperäistä tuotetta, ja toinen estää korvauksen, jonka määrääjä salli — joten ei ole turvallista oletusta, ja viesti pysähtyy.

Aikataulun II resepti, jossa on uusintamahdollisuus, hylätään, eja rakentaja ei tuota sellaista.

Hylkäykset ja varoitukset säilytetään erillisinä luetteloina eikä yhtenä luettelo, jossa on merkitty vakavuus, koska lukija, joka on tarkastettava vakavuus kenttä tietääksesi, lähetettiinkö viesti, lopulta ei tarkasta sitä.

Sähköinen etukäteisvaltuutus (PAInitiationRequest, PARequest, PAAppealRequest, PACancelRequest) ja reaaliaikainen reseptietu on vastattu maksajapuolelta osoitteessa /ncpdp/script ja /ncpdp/rtpb, lääkevalikoimasta; ks. CMS-0057.

8.7 DICOM

Kuvantaminen. Perfuse voi vastaanottaa DICOM-objekteja, kysyä etäarkistoa ja tallentaa siihen, sekä perinteisten DICOM-verkkopalvelujen että DICOMwebin kautta, ja se voi pitää omaa arkistoaan näyttöjä varten.

DICOM ei ole viestinmuoto samassa mielessä kuin muut — objektit ovat suuria, ja yhdistelyn käsiviritys on tärkeämpää kuin kuorman käsittely. called_ae ja calling_ae -otsikot ovat yleisimmin syy sille, miksi ensimmäinen yhteys epäonnistuu, ja epäonnistuminen näyttää verkkovirheeltä eikä kokoonpanovirheeltä.

8.7.1 Mikä C-STORE-kuuntelija hyväksyy

Avoinna oleva DICOM-kuuntelija hyväksyy mitä tahansa, kuka tahansa, joka pääsee porttiin. Neljä asetusta Mikä tämä kuuntelija hyväksyy rajoittaa sitä, ja ensimmäinen on se, jota kannattaa ymmärtää.

Hyväksy vain nämä soittajan AE-otsikot on rajoitus. *Kutsuttu* AE-otsikko — se, joka on osoitteen vieressä — on nimi, jonka lähettäjä valitsee, joten se tunnistaa kuuntelijan eikä lähettäjää, eikä se ole rajoitus. Kuka tahansa, joka pääsee porttiin, voi käyttää oikeaa kutsuttua AE-otsikkoa, koska se on julkaistu heille. Ilman sallittujen soittajien luetteloa mikä tahansa isäntä verkkossa voi työntää kuvia kliiniseen kanavaan.

Hyväksy vain nämä SOP-luokat ja hyväksy vain nämä siirtosyntaksit ottavat vastaan pilkuilla erotettuja UID:ejä. Tyhjä hyväksyy jokaisen objektin tyypin ja neuvottelee kaiken pakkaamisen, jonka lähettäjä tarjoaa, mukaan lukien sellaiset, joita tämän kanavan kohteet eivät voi käsitellä. Hylkääminen yhdistelyssä on selkeämpää lähettäjälle kuin objektin hyväksyminen ja sen jälkeen epäonnistuminen.

Suurin hyväksytty objekti on tavuissa, ja nolla tarkoittaa, että ei ole rajoitusta. Kokonaiset liukuvirta- ja pitkät sarjat voivat olla useita gigatavuja, joten rajoitus on muistin mukaan.

8.7.2 DICOMweb

DICOMweb on DICOM HTTP:n yli: QIDO-RS-haut, WADO-RS- ja WADO-URI-haku, STOW-RS-tallennus. Selainkatselijat, kuten OHIF, puhuvat vain DICOMwebiä, ja niin tekevät pilvi-kuvauspalvelut (Google Cloud Healthcare, Azure Health Data Services, AWS HealthImaging). Perfuse käyttää sitä kolmessa paikassa.

Kuvatietokanta. Käynnistä palvelin -dicomweb-archive DIR (Asetukset › Data › Kuvatietokanta) ja se tallentaa tiedostot kyseiseen kansioon, indeksoi ne SQLite-tietokantaan ja tarjoaa ne osoitteessa /dicomweb palvelimen osoitteessa: QIDO-RS tutkimuksen, sarjan ja instanssin tasolla, WADO-RS objekteille, metatiedoille, kehyksille ja massatiedoille, WADO-URI osoitteessa /dicomweb/wado ja STOW-RS. Lukeminen edellyttää katselijan roolia ja tallentaminen operaattorin roolia, istunnon tai API-tunnuksen kanssa; jokainen lukeminen ja tallentaminen on Toiminnassa dicomweb.read tai dicomweb.store. Tili, joka on rajoitettu vuokralle tai kanavaryhmille, evätään, koska arkisto kuuluu koko palvelimelle. Objektit säilytetään sellaisenaan, kuin ne on vastaanotettu, joten se, mitä katselija hakee, on bitti bittiin se, mitä on tallennettu. Kehykset palautetaan siinä siirtosyntaksissa, jossa ne on tallennettu; pyyntö, joka vaatisi koodauksen, vastaa 406 sen sijaan, että se muuttaa kuvaa.

Haku, joka perustuu attribuuttiin, jota arkisto ei indeksoi, vastaa 400 sen sijaan, että se ohittaisi ehdot ja palaisi useammalla tutkimuksella kuin mitä pyydettiin. Indeksoitu: potilaan nimi (wildcards, ja fuzzy-matching fuzzymatching=true:n kanssa), potilaan ID, syntymäaika, sukupuoli, tutkimuspäivämäärä ja -aika (välikappaleet), tutkimusnumero, tutkimusID, kuvaus, lähettävä lääkäri, tutkimus, sarja ja SOP-istanse-UID:t (listat), modaliteetti, kehon osa, sarjanumero ja kuvaus, SOP-luokka, instanssinumero, rivit, sarakkeet ja kehysten määrä.

Lähde. type: dicomweb kuuntelee STOW-RS:ää osoitteessa /dicom-web/studies oletusarvoisesti (polku, jonka Orthanc ja dcm4chee käyttävät), ja lähettää jokaisen objektin kanavan kautta DICOM-viestinä. Kanava tarvitsee dataType: dicom. Määritä kantaväli- tai käyttäjänimi ja salasana: ilman niitä kuka tahansa, joka pystyy käyttämään porttia, voi lähettää kuvia kanavaan. Vastaus luettelee jokaisen objektin tallennettuna tai epäonnistuneena, DICOM-epäonnistumisen syyn, jotta lähettäjä tietää, mitkä ovat uudelleenlähetettäviä.

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}

Määränpää on toimituksessa DICOMweb-arkistojen alla.

Osoittaminen OHIF:lle arkistoon

Käytä DICOMweb-tietolähdettä qidoRoot- ja wadoRoot-arvoilla arkiston osoitteeseen (Kuvat-näyttö näyttää sen, koko data-lähdetoimintosarjan kanssa), wadoUriRoot-arvo arkiston osoitteeseen seuraava /wado, imageRendering ja thumbnailRendering wadors:iin, ja supportsFuzzyMatching tosi. Katselija toisessa alkuperämaassa tarvitsee sen alkuperämaan -dicomweb-cors:ssa (Sallitut selainalkuperät, jotka voivat kutsua sitä), ja sen pyynnöt tarvitsevat API-tunnuksen Authorization-otsikossa, koska selain toisessa alkuperämaassa ei lähetä konsoleiden istunnon evästeitä. OHIF:n palvelu samasta alkuperämaasta kääntämällä palvelimen kautta välttää molemmat.

Testattu Orthancin kanssa sen DICOMweb-liitännäisellä, molempiin suuntiin: määränpää tallentaa Orthanciin, ja Orthancin DICOMweb-asiakas etsii Perfusen arkistoa ja hakee tutkimuksen, joka on bitti bitiltä sama kuin tallennettu. OHIF 3 listaa arkiston tutkimukset ja näyttää niiden kehykset yllä mainittujen asetusten kanssa. OHIF ja useat muut asiakkaat lähettävät type= ilman lainausmerkkejä Accept- ja Content-Type-otsikoissa, mitä RFC 2045 ei salli; Perfuse hyväksyy sen.

8.8 IHE-dokumenttien jakaminen: XDS.b, XCA, XDR, MHD, PIXm ja PDQm

Kliiniset asiakirjat, jotka jaetaan organisaatioiden välillä terveydenhuollon tietojen vaihtotavan, Carequalityn ja eHealth Exchangen tavoin: varasto pitää niitä, rekisteri indeksoi niiden metatietoja, ja yhteisö vastaa muiden yhteisöjen kysymyksiin portin kautta. Käynnistä palvelin -xds REPOSITORY-OID:llä (Asetukset › Data › Asiakirjojen jakaminen) ja se on kaikki kolme, tämän palvelimen tietokannassa, näissä osoitteissa, kunkin ottamalla API-tunnuksen kantavatunnukseksi (katselijan rooli kysymiseen ja hakemiseen, operaattorin rooli lähettämiseen; useimmat sitoutumisalat lisäävät vastakkaisen TLS:n eteen):

SOAP-transaktiot ovat SOAP 1.2:aa WS-Addressingillä ja MTOM/XOP:lla, kun asiakirjat liikkuvat (asiakirja inline-muodossa base64:na on hyväksytty myös). Epäonnistunut transaktio vastataan rekisterivastauksella, joka sisältää IHE:n virhekoodit, ei SOAP-virhettä: XDSDuplicateUniqueIdInRegistry, XDSNonIdenticalHash, XDSPatientIdDoesNotMatch, XDSMissingDocument, XDSRegistryMetadataError (puuttuvalla kentällä), XDSStoredQueryMissingParam, XDSUnknownStoredQuery, XDSUnknownRepositoryId, XDSUnknownCommunity ja UnresolvedReferenceException. Korvaava (RPLC, XFRM_RPLC) vanhentaa korvaamansa asiakirjan, joka vastaa vain kyselyihin, jotka pyytävät vanhentuneita asiakirjoja; APND, XFRM ja signs säilytetään assosiaatioina. Tiiviste ja koko lasketaan varastossa ja tarkistetaan vastaanottajan antamia tietoja vastaan. Tarvittaessa asiakirjat ja metatiedot (ITI-57) eivät ole tuettuja, ja pyyntö niiden hakemiseksi hylätään syyn vuoksi.

MHD on sama rekisteri FHIR:ssä: asiakirja, joka tarjotaan MHD:llä, löytyy ITI-18:lla ja XCA:lla, ja yksi, joka tarjotaan XDS.b:llä, löytyy ITI-67:llä. Asiakirjan viittauksen tunniste on kirjauskentän UUID, sen pääavain on yksilöivä tunniste, ja sen liitteen osoite on ITI-68-osoite asiakirjalle. Potilaat ratkaistaan sidossuhteensa tunnisteeseen FHIR-tallennuksesta: ensimmäinen tunniste, jonka järjestelmä on urn:oid:, tai potilas, joka on mukana paketissa. PIXm vastaa jokaista muuta potilaan tunnistetta annetulla (sourceIdentifier=system|value, kapeampi targetSystem):llä, ja 404:lla, jos se ei tunnusta sitä; PDQm etsii tunnisteella, nimellä, syntymäpäivämäärällä, sukupuolella, osoitteella ja tietoyhteydellä.

Julkaiseminen. Kanavan xds-kohde julkaisee jokaisen saamansa kliinisen asiakirjan XDS.b-rekisteriin ITI-41:llä. Metatiedot luetaan asiakirjasta: potilas (tunniste patient_domain:ssa, sidossuhteen määrittäjä), otsikko, tyyppi (tyyppikoodina ja, ellei ole asetettu, luokkakoodina), luomis- ja palveluaika, tekijä, luottamuksellisuus, kieli ja muoto (C-CDA 2.1 tai 1.1 rakenteinen runko, XDS-SD tai mimeTypeSufficient, sen malleista); ja täydennetään siitä, mitä asiakirja ei kerro: lähettäjän source_id, facility_type ja practice_setting, joita jokainen rekisteri vaatii. Varaston RegistryResponse päättää toimituksen: epäonnistunut toimitus on virheellinen toimitus rekisterin virhekoodeilla.

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. Lisää direct_from (oma Direct-osoite) ja direct_to (vastaanottajien) ja sama kohde lähettää XDR:nä Directin kuljetuksena, kuten Direct-hankkeen *XDR ja XDM Direct-viestinnässä* kuvailee: Direct-osoitelohko (urn:direct:addressing) SOAP-otsakkeessa nimeää lähettäjän ja vastaanottajat, ja lähetetyssä intendedRecipient nimeää kunkin vastaanottajan (||^^Internet^address). Osoita url vastaanottajan XDR-päätepisteeseen tai HISP:hen, joka hyväksyy XDR:n. XDR matkustaa TLS:n yli, yleensä asiakasvarmenteella (tls), ja se ei ole S/MIME. direct-lähde hyväksyy myös XDR:n (ks. Direct alempana).

    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 ja PDQ HL7 version 3:ssa. Potilasrekisterin ollessa käytössä (-mpi), /pixv3 on PIX-hallintaja ja /pdqv3 PDQ-toimittaja SOAP 1.2:n yli, sairaaloille ja vaihtoille, jotka edelleen puhuvat IHE:n v3-profiileja. Lähde syöttää potilaita ITI-44:llä (tallennettu PRPA_IN201301UV02, muokattu PRPA_IN201302UV02, monistetut ratkaistu PRPA_IN201304UV02): potilaan ensimmäinen tunniste on sen tallennus, muut ja asOtherIDs:ssä olevat tunnisteet ovat tunnisteita, joita se kantaa, ja yhdistäminen yhdistää edellisen tallennuksen tunnisteen eloonjäävään, kuten HL7 v2 A40 tekee. ITI-45 (PRPA_IN201309UV02) vastaa henkilön muiden tunnisteiden, jotka omistaa yksi, kapeampaa dataSource:a ja Patient.id:ssä; kysytty tunniste tulee takaisin vain toistuvassa kyselyssä. ITI-47 (PRPA_IN201305UV02) vastaa demografiaa (nimi, sukupuoli, syntymäaika, tunniste, osoite, viestintä) indeksin omalla vastaajalla, minimumDegreeMatch pisteytys 100:sta, otherIDsScopingOrganization rajoittaa verkkotunnukset ja initialQuantity sivuttaa vastauksen: loput tulevat QUQI_IN000003UV01:n kanssa kymmenen minuutin kuluttua tai heittää pois sen peruutuksella. Vastaukset seuraavat transaktioiden tapauksia: tuntematon potilas tai verkkotunnus on AE virheellä 204 ja parametrin sijainti, tunnettu potilas, jolla ei ole mitään pyydetyissä verkkotunnuksissa, on NF. v3 nimeää viranomaisen vain OID:llä, joten tunniste, jonka järjestelmä on URL, jolla ei ole OID:tä (jotkin kansalliset numerot), jätetään pois v3-vastauksista ja annetaan FHIR:lle; aseta yritystunnisteen järjestelmäksi OID:ksi (urn:oid:..., indeksiasetuksissa) EUID:lle ja huoltajalle näkyville. Katselijan rooli kysyy ja operaattorin rooli syöttää; jokainen transaktio auditioidaan tunnisteella, ei koskaan nimellä. Paljas v3-viesti lähetetään application/xml:na, joka on kätevä käsillä testaamiseen.

Vaihto › Asiakirjojen jakaminen näyttää, mitä rekisteri sisältää ja mihin se on saatavilla, etsii potilaan asiakirjoja tässä rekisterissä tai toisessa (rekisterin ITI-18 tai portaalin ITI-38), lataa yhden ja julkaisee CDA-asiakirjan käsin metatiedoilla, jotka kohde antaisi sille.

Varmistettu NIST XDS Toolkit 7.13.0:ia, IHE:n viiteimplementaatio: Perfuse:n ITI-41, ITI-18 ja ITI-43 sen Registry/Repository-simulaattorin (hyväksytty ilman validointivirheitä, asiakirja haettu bitti-tarkasti) ja sen Initiating Gateway -simulaattorin kysely ja hakeminen Perfuse:n Responding Gateway:sta XCA:n kautta ilman virheitä sen lokissa. Jokainen SOAP-viesti, jonka Perfuse kirjoittaa, on validi ebXML Registry 3.0 ja XDS.b -skeemojen mukaan, ja MHD DocumentReference ja SubmissionSet IHE MHD 4.2.2:n mukaan HL7 FHIR -validoijalla. XDR xds-kohteesta, jossa on Direct-osoiteblokki, hyväksyttiin työkalun Document Recipient -simulaattorin toimesta, jonka metadata-validointi löysi yhden virheen, joka on kuvattu docs/verification.md:ssa, ja ONC SITE:n XDR-validoijan toimesta, Direct XDR -tarkistusluettelo (h)(2) -sertifioititestin mukaisesti. PIX- ja PDQ v3 -vastaukset validoidaan IHE:n HL7 V3 -skeemojen (NE2008 multicacheschemas) mukaan, ja IHE:n omat esimerkkiwiksit (ITI-44 -syöte, yhdistäminen, ITI-45 -kysely, ITI-47 -kysely, jatko ja peruutus) ovat vastauksia, jotka julkaistuissa vastauksissa näkyvät. Ei vielä tarkistettu itsenäisen PIX- tai PDQ v3 -toteutuksen, Gazellen tai Connectathonin kanssa.

8.9 Sähköinen turvallinen viestintä

Direct on tapa, jolla US:n tarjoajat lähettävät toisilleen siirtoja, yhteenvetoja ja tuloksia turvallisella sähköpostilla: jokainen viesti on allekirjoitettu lähettäjän varmenteella ja salattu vastaanottajan varmenteella (S/MIME), ja se matkustaa HISPIen (Terveydenhuollon tietopalvelujen tarjoajat) välillä, jotka myöntävät osoitteet ja vakuuttavat niistä. Perfuse on reunajärjestelmä HISP:si vieressä, ei HISP: siinä mielessä, että HISP myöntää sinun osoitteesi, sen varmenne ja avain, ja sinä pidät sen luottamusryhmää (kuten DirectTrustin). Seuraamme Direct-soveltamisohjeita turvallisesta terveydenhuollon kuljetuksesta 1.2, Toimituksen ilmoitusopasta, IHE XDM:ää (ITI TF-1 Annex 15) asiakirjoille metadataa varten, Varmenteen löytämisopasta Direct-hankkeen toteutusoppaassa (DNS ja LDAP), ja XDR ja XDM Direct-viestintää varten.

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

Vastaanotto. direct-lähde on SMTP-palvelin, johon HISP toimittaa osoitteesi postin. Se ottaa vastaan postia vain kyseiselle osoitteelle (muu kieltäytyy RCPT-vaiheessa), edellyttää STARTTLS:ia, kun sertifikaatti on annettu, ja avaa jokaisen viestin ennen kuin se luetaan: salaa sen avaimellasi, tarkistaa allekirjoituksen luotettavien ankkurien vastaisuutta ja tarkistaa, että allekirjoittava sertifikaatti on lähetijän osoitteelle tai sen domeenille. Viesti, joka ei ole salattu S/MIME:llä, on allekirjoitettu lähettäjän toimesta, jota et luota, tai on allekirjoitettu sertifikaatilla, joka kuuluu jollekin muulle, kieltäytyy DATA-vaiheessa syystä, joten HISP pitää sen ja ilmoittaa siitä lähettäjälle; Perfuse ei koskaan hyväksy sitä, mitä se sitten hylkää. XDM-paketin asiakirjat muuttuvat jokainen viestiksi (tarkistetaan paketin metatietojen hajautusarvoa vastaan); muuten jokainen liite muuttuu viestiksi tai tekstiksi, jos liitteitä ei ole. smtp_host-asetuksen ollessa määritettynä jokainen vastaanotettu viesti vastataan allekirjoitettuun ja salattuun "prosessoitu"-ilmoitukseen (MDN), ja ilmoitukset, jotka saapuvat lähettämistesi viestien osalta, kirjataan.

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

HISP:n postilaatikosta. HISP, joka pitää sähköpostia sen sijaan, että toimittaisi sen, antaa osoitteelle IMAP-postilaatikon: imap lukee sen (TLS tai STARTTLS, jokaista kyselyä varten uusi istunto), avaa jokaisen viestin edellä mainittuun tapaan, siirtää mitä otettiin move_to:han (tai poistaa sen) ja mitä ei voitu avata error_folder:iin, jotta mitään ei lueta kahdesti. listen voidaan jättää pois. HISP, jonka sähköpostipalvelimella on yksityinen sertifikaatti, luotetaan tls.ca_file:n (sen sertifikaatti tai sen viranomaisen) ja tls.server_name:n avulla; varmennus ei voida kytkeä pois päältä.

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

XDR. xdr ottaa XDR:in osoitteesta /xdr omalla HTTPS-osoitteellaan, kuten HISP lähettää Directin muunnettuna SOAP:ksi tai kumppani lähettää suoraan: ITI-41 Provide and Register -pyyntö, jonka asiakirjat muuttuvat viestiksi. Lähetys, jonka Direct-osoiteblokki nimeää toisen osoitteen, hylätään, ja sellainen, jota kanava ei hyväksy, vastataan RegistryResponse-virheilmoituksella, jossa kerrotaan syy. client_ca_file edellyttää asiakas sertifikaattia niiden viranomaisten toimesta. XDR on suojattu TLS:llä, ei S/MIME:llä, joten lähde, joka ottaa vain XDR:ää, tarvitsee osoitteen, mutta ei sen sertifikaattia, avainta tai ankkureita. Jokainen asiakirja muuttuu kanavan dataType -viestiksi: CDA-dokumentit tarvitsevat raw (lähetetään sellaisenaan) tai hl7v3, koska oletus, hl7, odottaa HL7 v2:ta ja hylkää ne.

    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

Vaihto › Direct luetellaan kanavien lähettämät ja vastaanottamat Direct-osoitteet niiden sertifikaatteineen, vanhenemisajankohtineen ja ankkureineen; ylläpitää osoitekirjaa (nimi, organisaatio, muistiinpanot ja sertifikaatti, joka on liitetty heidän HISP:stään tai löydetty DNS:stä tai LDAP:stä, ja evätetty, kun se ei ole kyseiselle osoitteelle tai verkkotunnukselle); ja etsii osoitteen sertifikaatteja DNS:stä tai LDAP:stä tallentamatta niitä. Kirja on direct-certs -kansio tietokannan vieressä, yksi PEM-tiedosto kunkin osoitteen tai verkkotunnuksen mukaan, jonka kohde lukee, ellei se mainitse omaa recipient_certs_dir:ää.

Varmistettu OpenSSL 4.0:n cms- ja smime-työkalujen kanssa molempiin suuntiin: mitä Perfuse allekirjoittaa ja salaa, OpenSSL varmistaa ja purkaa (PKCS#1 v1.5 ja OAEP-avainkuljetus), ja Perfuse avaa, mitä OpenSSL allekirjoittaa ja salaa (AES-128 ja AES-256). Viesti, joka on tehty openssl smime-työkalulla ja toimitettu SMTP:llä, vastaanotetaan, avataan ja tallennetaan kanavaan, ja yksi Perfuse lähettää viestin toiselle kanavalle HISP-välikappaleen kautta, joka vastaa MDN:llä, jonka lähettäjä avaa. Sertifikaatit löytyvät OpenLDAP 2.4:stä (osoitekohtaiset ja domainkohtaiset, kirjoitetut OpenLDAP:n omalla ldapadd-työkalulla); Direct-viesti luetaan GreenMail IMAP-postilaatikosta ja avataan, ja yksi, joka ei ole Direct, siirretään virhekirjaan; XDR xds-kohteesta otetaan direct-lähteestä ja hylätään, kun se on osoitettu jollekin toiselle, ja hyväksytään NIST XDS Toolkitin Document Recipientin ja ONC SITE:n XDR-vahvistimen toimesta; SITE:n Direct XDR Edge Test Tool lähetti sekä minimi- että täydelliset metatietoviestit direct-lähteelle, joka otti ne. ONC:n Direct Certificate Discovery Toolin kanssa Direct-kohteella valitaan oikea sertifikaatti tai ei yhtäkään niistä 18 havaintotapauksessa (D1-D18: vanhentuneet, peruutetut ja AIA-myönnetyt sertifikaatit, SRV-prioriteetti ja paino, yhteydenoton estäminen). Direct-lähde lukee viestin SITE:n omasta HISP:stä (Apache James) IMAP:llä STARTTLS:in avulla. Ei vielä testattu: SMTP-vaihto SITE:n HISP:n (AWS pitää lähtevän postin portissa 25 uusille tileille) tai akkreditoitujen HISP:ien kanssa.

8.10 SQL FHIR-näkymät

ViewDefinition (HL7 SQL on FHIR v2) muuttaa jokaisen FHIR-resurssin tietyn tyypin riveiksi nimetyistä sarakkeista, jokainen sarake on FHIRPath-lause, joten FHIR-data voidaan lukea tauluina DuckDB:llä, Athenalla, Sparkilla, data-warehousella tai taulukkolaskentaohjelmalla. Perfuse suorittaa ne omalla FHIRPath-moottorillaan: column, sisäkkäinen select, forEach, forEachOrNull, repeat ja unionAll, where, constant (jokainen arvo[x] -tyyppi), collection-sarakkeet, %rowIndex ja getResourceKey()- ja getReferenceKey(type)-liittymisavaimet.

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

Valvonta › SQL on FHIR suorittaa näkymän tämän palvelimen FHIR-tietokannasta (yksi potilas tai kaikki) tai resursseista, jotka on liitetty (NDJSON massavirheestä, Bundlesta, JSON-taulukosta), näyttää rivit ja lataa ne CSV-, NDJSON- tai Parquet-tiedostona. Se aloittaa viidestä esimerkkinäkymästä (potilaan demografiat, havainnot arvolla, verenpaine, oireet, kohtaamiset) ja tallentaa näkymät views-hakemistoon tietokannan vieressä, yksi JSON-tiedosto kussakin.

FHIR-päätepiste vastaa määrityksen $sql-run-kyselyyn järjestelmätasolla, GET- tai POST-menetelmällä, ViewDefinition-aiheen mukaan annettuna suoraan (subjectResource), subjectReference-kautta (ViewDefinition/<name>, tallennettu näkymä) tai subjectCanonical-kautta (tallennetun näkymän url), _format-kyselyparametrin (csv, ndjson (oletus), json tai parquet) kanssa, header, patient, _since, _limit ja resource suorittamaan resursseja, jotka lähetetään pyynnön mukana sen sijaan, että ne haettaisiin tietokannasta. Se on lukukäyttö: SMART-tunniste tarvitsee lukuoikeuden näkymän resurssityypille, tunniste, joka on sidottu yhteen potilaaseen, saa vain kyseisen potilaan rivit, ja hienorakeiset oikeudet rajoittavat resursseja, joita luetaan, kuten ne rajoittavat hakua. Yli miljoona riviä vaatii _limit-, patient- tai _since-parametria.

perfuse sof -view v.json [-format csv|ndjson|json|parquet] [-o out] files... suorittaa näkymän FHIR-tiedostoja ilman palvelinta: massavirheen NDJSON-tiedostot, Bundle tai taulukot.

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-tiedostot sisältävät yhden riviryhmän ja pakkaamattomat PLAIN-sivut; totuusarvot ovat BOOLEAN, kokonaisluokat INT64, desimaalit DOUBLE ja kaikki muu UTF-8-merkkijonot (kokoelmasarake sen JSON-muodossa).

Varmistettu virallisen SQL on FHIR -testisarjan (sql-on-fhir.js-repositorion tests/-kansiossa olevat 144 testiä, jotka suoritetaan jokaisessa koontiversiossa: kaikki menevät läpi) ja Parquet-tulosteen lukeminen takaisin DuckDB 1.5.6:lla oikeilla tyypeillä ja arvoilla. Ei tueta: SQLQuery- ja SQLView-kirjastot (SQL näkymien tauluilla), $sql-export, _format=fhir ja source- ja group-parametrit; jokainen kieltäytyy syystä.

8.11 Digitaaliset laatusäännökset

Digitaalinen laatusääntö laskee potilaiden määrän kussakin FHIR-Measure-resurssin populaatiossa mittaamisjaksolla (alkuperäinen populaatio, nimittäjä, nimittäjän poissulkemiset ja poikkeukset, ylämäki, ylämäen poissulkemiset) ja pisteyttää tuloksen. Vastaus on FHIR-MeasureReport, joka on muotoiltu Da Vinci Data Exchange for Quality Measures (DEQM) -oppaan mukaisesti. Tässä on, minne CMS:n eCQM-ohjelmat ja NCQA:n digitaalinen HEDIS ovat menossa.

Perfusessa väestön kriteerit ovat FHIRPath ("language": "text/fhirpath"), jotka suoritetaan samalla moottorilla kuin SQL FHIR:lle. Kukin kriteeri arvioidaan kerran potilaakohtaisesti. Sen keskipisteenä on potilaan omat tiedot sisältävä Bundle (Potilas-osio), ja siinä on seuraavat muuttujat: %subject (Potilas), %periodStart ja %periodEnd (aikajakso, dateTime-tyyppisenä) ja %"Measurement Period". Kriteeri palauttaa tosi tai epätosi; yksittäinen olemassaoleva arvo katsotaan tosiksi.

{
  "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()"
  }
}

Väestöt muodostuvat Mittausmäärityksen mukaan. Potilas on oletusarvoisesti ainoastaan nimittäjässä, jos hän on alkuväestössä. Nimittäjäpoisto ottaa potilaan pois ennen kuin nimittäjä arvioidaan. Nimittäjäpoikkeus lasketaan ainoastaan potilaalle, joka ei ole nimittäjässä. Suhteen pisteytys on (nimittäjä - nimittäjäpoistot) / (nimittäjä - poistot - poikkeukset); suhdeluvun pisteytys on nimittäjä / nimittäjä; ryhmässä on laskurit ja ei pisteytystä. Yksikriteeriset stratifikointikriteerit jakavat jokaisen väestön arvonsa mukaan (sukupuoli, esim.).

Perfuse ei ole CQL-moottori. Julkaistut CMS eCQMs ja HEDIS digitaaliset mittaukset on kirjoitettu CQL:llä, joten niitä ei voida suorittaa sellaisenaan. Mittaus, jonka kriteerit ovat CQL, hylätään samalla perusteella. Kirjoita logiikka FHIRPathina sen sijaan. Jatkuva muuttujien pisteytys, monikomponenttisten stratifioijien ja ryhmän tai harjoittajan aiheiden käsittely hylätään samalla tavalla.

Monitor › Laatulaadun mittarit arvioi mittaria tämän palvelimen FHIR-kaupassa tai liitettyjen resurssien yli tietylle ajanjaksolle. Se tarjoaa kolme raporttia: yhteenveto, yhteenveto potilaiden määrällä kussakin väestössä tai yksi potilas. Näyttö näyttää väestöt, pisteytyksen ja stratat, ja lataa MeasureReportin. Se alkaa kolmesta esimerkistä: verenpaine hallinnassa, diabetes HbA1c-testillä ja potilaat, jotka on nähty ajanjaksolla. Ne ovat havainnollistavia, kirjoitettu tätä käsikirjaa varten, eivätkä ne ole CMS eCQMs- tai HEDIS-mittauksia. Tallenna FHIR-kauppaan tarkistaa Mittarin ja tallentaa sen Measure-resursseina.

FHIR-päätepiste vastaa Measure/[id]/$evaluate-measure ja Measure/$evaluate-measure?measure=<url>, joko GET- tai POST-pyynnöllä Parameters-ressurssia. Parametrit:

• periodStart ja periodEnd: vaadittu. Päivämäärä tarkoittaa koko päivää.
• reportType: summary, subject tai subject-list.
• subject: Patient/<id>.
• reporter: Organization/<id>. Kun sitä ei ole, raportti sisältää serve -measure-reporter -nimisen Organizationin.
• measure: mitattu arvo lähetetään sisällössä, POST-parametrina.

Raportti palautetaan, ei tallenneta. Operaatio on lukeminen, joten SMART-tunniste tarvitsee lukuoikeuden Mittaukseen ja Potilaaseen. Potilastunniste, joka on sitoutunut yhteen potilaaseen, saa yksittäisen raportin kyseisestä potilaasta eikä muista.

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... evaluates a measure over FHIR files (a bulk export's NDJSON, Bundles, arrays) without a server. -measure example:example-bp-control runs a shipped example, and -examples lists them.

Vahvistettu. HL7 FHIR-vahvistin tarkistaa toimitetut Mittaukset FHIR R4:ää vasten ilman virheitä. Se tarkistaa yhteenveto-, yksittäisen ja aihe-luettelon MittausRaportin DEQM 5.0.0 yhteenveto-, yksittäisen ja aihe-luettelon profiileja vasten, myös ilman virheitä. Vahvistamaton: vastaavuus mihinkään julkaistuun eCQM:ään, koska niitä ei voida suorittaa ilman CQL:ää.

8.12 Potilasrekisteri (MPI)

Master-potilasrekisteri linkittää jokaisen järjestelmän pidemmän aikaa säilyttämät tiedot henkilöstä (sairaalan MRN, klinikan, laboratorion) yhdeksi yritysosoitteeksi, EUID:ksi. Se on pois käytöstä, kunnes joku päättää pitää sitä, koska se on potilaiden nimien, syntymäpäivien ja tunnisteen taulukko: käytä Asetukset → Data → Potilasrekisteri (tai serve -mpi) ja käynnistä uudelleen. Se sijaitsee mpi.db-tiedostossa päätietokannan vieressä.

Syöttäminen. Lisää kanaviin, jotka kantavat rekisteröintejä, kohde mpi-tyyppi (Potilasindeksi rakentajassa). Se lukee kunkin HL7 v2-viestin PID:n tai FHIR-potilaan raakakanavalla. Oman tunnisteen omat tunnisteet ovat PID-3 toistumisen MR-tyyppi (id_type muuttaa sen); muut, ja PID-19, tulevat sen muiden tunnisteiksi. Universaalin tunnisteen (PID-3.4.2 tyypillä ISO) antaa urn:oid:...; yksin namespace on kartoitettu authorities-avaimella, tai se tulee urn:perfuse:aa:<namespace>. A40, A34, A18 tai A39 yhdistää henkilön, jolla on MRG-1:n tunniste, henkilöön, jolla on PID-3 (no_merge jättää ne huomioimatta).

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

Tunnistaminen. Uusi tietue liitetään seuraavassa järjestyksessä:

1. Luotettavat tunnistimet. Tiedon, joka jakaa tunnistimen luettelossa mainitusta järjestelmästä (kansallinen tunniste, yritystunnus), on sama henkilö, ilman pisteytystä. Älä koskaan mainitse järjestelmää, jota perhe jakaa, kuten vakuuttajan tilaajanumero.
2. Pisteytys. Muutoin henkilöt, joiden tiedot voivat olla samat, löydetään estämällä (saman kuuloinen sukunimi ja syntymävuosi, sama syntymäpäivä tai sama puhelinnumero) ja pisteytetään Fellegi-Sunter-painoilla sukunimi ja etunimi (Jaro-Winkler ja Soundex, aksentit ja pisteet huomioon ottaen, nimet vaihdettuina), syntymäpäivä (päivä ja kuukausi vaihdettu osittainen sopimus), sukupuoli, postinumero, puhelin ja osoite. Vain kentät, joita molemmat tiedot sisältävät, lasketaan. Pisteytys on löydetty todiste osana mahdollista todistetta. Estäminen käyttää viittä avainta, joten yksi virhe ei piilota henkilöä: sukunimiääni ja syntymävuosi, syntymäpäivä, puhelin, molempien nimien äänet (järjestyksessä), ja postinumero etunimen äänellä.
3. Päätös. Oletuksena mitkään tiedot eivät liity pelkästään pisteytykseen. Tiedot, jotka saavuttavat tai ylittävät tarkastelukynnyksen (60%), muodostavat uuden henkilön ja mahdollinen vastine odottaa tarkastusjonossa; ne, jotka ovat tai ylittävät automaattisen kynnyksen (90%) sukunimen ja syntymäpäivän molempien sopiessa, on merkitty *varmaksi*. Kahden henkilön yhdistäminen yhdeksi (ylipäällekkäin) asettaa toisen potilaan tulokset toisen potilaan karttaan, joten automaattinen yhdistäminen on kytkin, jonka ylläpitäjä kääntää (Linkitä varmat vastineet ilman kysymystä) kun jonot on osoittanut, että varmat ovat oikein. Kun se on päällä, varma vastine linkittyy, kun toinen henkilö ei saavuta yhtä korkeaa pisteytystä. Tarkastelukynnyksen alapuolella tieto on uusi henkilö.

Kansalliset numerot. NHS-numero (ja Skotlannin CHI ja Pohjois-Irlannin terveydenhuollon numero), Irlannin PPSN ja IHI, Saksan KVNR, Itävallan SVNR, Sveitsin AHV-numero, Alankomaiden BSN, Belgian kansallinen rekisterinumero, Luxemburgin matricule, Ranskan INS (NIR ja NIA), Italian codice fiscale, Espanjan DNI/NIE ja CIP-SNS, Portugalin SNS-numero, Pohjoismaiden henkilötunnukset (Ruotsi, Tanska, Norja D-numero, Suomi, Islanti), Baltian koodit, Puolan PESEL, Tšekin ja Slovakian syntymänumerot, ja Unkarin, Romanian, Bulgarian, Kroatian, Slovenian ja Kreikan numerot ovat tunnettuja indeksille. Jokainen tallennetaan yhden tavan: sen järjestelmän mukaan, välilyönnit ja pisteet poistettu, joten NHS-numero, joka lähetetään yhden järjestelmän toimittamana urn:oid:2.16.840.1.113883.2.1.4.1|999 000 0018 ja toisen järjestelmän toimittamana https://fhir.nhs.uk/Id/nhs-number|9990000018, on yksi tunniste. HL7 v2 PID-3 toisto, jonka tunnistetyyppi on NN ja maan kolmen kirjaimen koodi (NNDEU, NNNLD), luetaan kyseisen maan päänumerona, ja tyyppi NH NHS-viranomaiselta on NHS-numero. Jokaisen numeron tarkistusmerkki testataan: yksi, joka epäonnistuu, säilytetään sen tiedostossa, raportoidaan (maskattuna) vastauksessa ja ei koskaan käytetä linkittämiseen tai etsimiseen, koska yksi virheellinen numero yleensä tekee toisen henkilön numerosta. Tanskan CPR tarkistetaan vain päivämäärän osalta, koska vuoden 2007 jälkeen myönnetyt numerot eivät tarvitse vanhan modulus 11 -testiä.

Asetukset luettelevat jokaisen scheman sen muodossa, sen tarkistuksessa ja järjestelmässä, jossa se tallennetaan. Järjestelmät, jotka on otettu maan omasta FHIR-oppaasta (UK Core, fhir.de, Nictiz, CH Core, ANS, HL7 Italia, MedCom, Ruotsin, Norjan ja Suomen OID-rekisterit), on merkitty sellaisiksi; muut ovat oletusarvoja, jotka voidaan muuttaa kansalliseen arvoon, jonka sivusto voi tehdä kunkin scheman kohdalla (vanha säilytetään edelleen). Scheman luottaminen on yksi merkintä. Kansalliset numerot näytetään kokonaisuudessaan toimittajille ja ylempänä oletuksena ja maskattuna (viimeiset merkit) muille; Kuka näkee numerot kokonaisuudessaan muuttaa sitä, alaspäin katselijoille tai ylöspäin vain hallinnoitsijoille. Jos maan laki rajoittaa numeron käyttöä (Ranskan Référentiel INS, Irlannin PPSN, Belgian kansallinen rekisterinumero, Saksan §290 SGB V), asetukset sanovat niin. GET /api/mpi/schemes luetellaan schemat ja POST /api/mpi/check tarkistaa yhden numeron tallentamatta sitä. FHIR $match ja PIXm vastaavat valtuutetuille asiakkaille numerot kokonaisuudessaan.

Päivämäärä, joka on kirjoitettu päivä- tai kuukausikohtaisesti (08/15/1972), säilytetään sellaisenaan eikä se vastaa vuosi-kohtaista: Yhdysvallat ja Euroopan järjestelmät ovat erilaisia, ja arvaaminen liittäisi väärät henkilöt.

Potilas-indeksin näyttö (Build) näyttää laskelmia, etsii henkilöitä nimen, numeron, EUID:n tai syntymäpäivämäärän mukaan ja avaa kunkin henkilön: heidän tietonsa, jokainen tunniste ja tapahtumien historia, mitä heille on tapahtunut ja kuka on tehnyt sen. Toimittajat päättävät tarkastuksista (Sama henkilö linkittää ne; Eri henkilöt pitää ne erillään lopullisesti), siirtävät tietueen toiseen henkilöön, poistavat tietueen (Ei tämä henkilö) ja yhdistävät kaksi henkilöä. Hallinnoitsijat asettavat kynnykset, luotettavat tunnistejärjestelmät, kansalliset numerot ja EUID:n järjestelmän. Jokainen haku ja jokainen henkilö, joka luetaan, kirjataan audit-lokiin.

Vastaus muille. POST /fhir/Patient/$match (FHIR:n operaatio, kuten IHE PDQm ITI-119 käyttää sitä) ottaa Potilaan ja palauttaa henkilöt, jotka voivat olla se, parhaat ensin, kunkin Potilaan, jonka tunnus on EUID, jokaisella tunnisteella, search.score ja match-grade-laajennus (certain, probable, possible); onlyCertainMatches ja count otetaan huomioon. PIXm (/mhd/Patient/$ihe-pix, ITI-83) vastaa indeksistä: jokaisen henkilöön liittyvän rekordin jokainen tunniste ja EUID. Samoin tekevät PIX ja PDQ HL7 v3:ssa (/pixv3, /pdqv3; ks. IHE:n asiakirjan jakelu), jotka myös ruokkivat sitä.

Rajapinta on /api/mpi (yhteenveto ja haku), /api/mpi/persons/{euid}, /api/mpi/find, /api/mpi/reviews, /api/mpi/records (rekisteröinti, linkitys, linkin poistaminen), /api/mpi/merge ja /api/mpi/settings.

Painot. Oletusarvon Fellegi-Sunter-painot tulevat rekisteröintitietojen kirjallisuudesta sairaalarekisterin tiedoista. Arvio omista tietueista (asetuksissa, hallinnoitsijat; POST /api/mpi/estimate) sovittaa ne sivuston omiin indeksiin odotus-maksimointimenetelmällä, ei tarvita tarkasteltuja pareja: m (sopimus todellisten vastaavuuksien kesken) pareista, jotka estävät yhteen, u (sopimus sattumalta) 20 000:sta satunnaisesti valitusta parista, koska estetyt parit sopivat nimien ja päivämäärien kanssa rakenteen mukaan. Arvio näytetään käytössä olevien painojen vieressä ja ei muuta mitään, kunnes se käytetään ja tallennetaan. Kenttä, jota verrataan liian vähän parien kanssa, säilyttää oletusarvonsa. Sovitus olettaa, että kentät ovat riippumattomia luokan annettua, mitä ne eivät ole täysin, joten suuri muutos tulee käsitellä epäilyksellä.

Mittaus. FEBRL-aineistossa 3 (5 000 syntetistä tietuetta 2 000 henkilölle, duplikaatit, joissa on kirjoitusvirheitä, vaihdettuja kenttiä, puuttuvia arvoja ja lempinimiä; PERFUSE_TEST_FEBRL), rekisteröity tiedostojärjestyksessä ja tarkastelija vastaa jokaiseen jonoon asetettuun pariin oikein:

Yhtään tietuetta ei koskaan linkitetty väärään henkilöön, ja yhtään uutta henkilöä ei asetettu turhaan jonoon. Hävinneet henkilöt eroavat lähes jokaisessa kentässä (syntymäpäivämäärä ja osoite molemmat virheellisiä, esim.) ja saavat alle tarkastelukynnyksen. FEBRL on syntetistä ja siinä on vähän samannimisiä; todellisessa indeksissä on enemmän, joten sen tarkastelujono on pidempi, ja nämä luvut ovat huolehtimisen alaraja, eivät lupa.

8.13 Rajoitettu

CSV ja sen sukulaiset. Valinnat ovat lähteessä rakentajassa, ja muotoiluviite luetellaan tiedostojen avaimet.

Polut osoittavat sarakkeita. Nimetty sarakkeella on käytettävissä, kun otsikkorivi on julistettu tai nimet on annettu; muuten sarakkeet ovat positiivisia.

8.13.1 Sarakkeiden nimeäminen

On kaksi tapaa, ja ne ovat toisensa poissulkevia. Joko ensimmäinen rivi tiedostosta nimeää ne — ensimmäinen rivi nimeää sarakkeet — tai luettele ne itse, järjestyksessä. Otsikkorivin julistaminen tarkoittaa, että riviä ei käsitellä datana.

Jos kumpaakaan ei ole asetettu, sarakkeita voidaan osoittaa ainoastaan positiivisesti, joten suodatin, joka on kirjoitettu nimen perusteella, ei voi vastata mihinkään. Otsikkorivin käyttöönotto poistaa nimien luettelon sen sijaan, että se pitäisi molemmat: otsikkorivillä nimet tulevat tiedostosta, joten jäljelle jäänyt luettelo olisi huomioon otettava, ja kanava, joka lukee niin, että se valitsi nimet, kun tiedosto valitsi ne, on vaikeampi debugata kuin se, joka kieltäytyy.

8.13.2 Mikä suodattimelle tai käsikirjoitukselle näkyy

Yksi rajoitettu asiakirja muuttuu moniksi viesteiksi, joten tämä on mainittava ennen kuin kirjoitat kumpaakaan.

Jako päällä, kaikki toimii rivin mukaan. Deklaratiiviset vaiheet, suodatin ja muodonmuutoskäsikirjoitus näkevät yhden rivin, ja polku tarkoittaa *tämän* rivin saraketta. Suodatin, joka hylkää rivin, hylkää kyseisen rivin ja ei muita, ja vastaanotettu määrä on rivejä eikä asiakirjoja.

Jako pois, viesti on koko asiakirja ja kirjoitus, joka ylittää rivit, kieltäytyy soveltamasta sitä ensimmäiseen. Tämä kieltäytyminen on tarkoituksellista: hiljainen kirjoittaminen ensimmäiseen riviin on se käyttäytyminen, joka tuottaa muunnetun asiakirjan, joka ei ole todella muunnettu.

8.13.3 Kolme, jotka muuttavat sitä, mikä on virhe

Hyväksy rivit, joilla on väärä määrä sarakkeita on pois oletuksena. Rivi, jolla on liian monta tai liian vähän sarakkeita, on silloin virhe, joka on se, joka havaitsee tiedoston, jonka muoto muuttui ilman varoitusmerkkiä. Sen käyttöönotto hyväksyy rivin ja jättää puuttuvat sarakkeet tyhjiksi.

Leikkaa tyhjät merkit jokaisen arvon ympäriltä korjaa yleisen tapauksen, jossa arvo on täytetty sarakkeen leveyteen. Jätä se pois, missä perämerkit ovat merkittäviä, mikä on joskus tapauksessa tunnisteessa.

Säilytä tyhjät rivit riveinä on pois oletuksena ja yleensä pitäisi. Päällä, tyhjä rivi muuttuu rivi tyhjillä sarakkeilla, mikä on merkittävää ainoastaan, kun laskuri on oltava täsmälleen tiedoston mukainen.

8.14 Raaka

Ei lainkaan parsimista. Viesti on tavuja.

Käytä tätä, kun sisältö ei ole mitään, mitä Perfuse ymmärtää, eikä sitä tarvita: PDF, joka siirretään järjestelmien välillä, omistajaformaatti, jo muodostettu asiakirja, joka välitetään muuttumattomana.

Kustannus on, että mitään, joka riippuu rakenteesta, ei toimi — ei kenttätason muodonmuutos, ei suodatinta kentän perusteella, ei kenttätason vertailua pariteettitarkistimessa. Raaka kanava on putki, ja se on rehellinen siitä, että se on putki.

8.15 Valinta

Jos viesti on HL7 v2, käytä hl7, vaikka aiot vain välittää sen muuttumattomana. Viestin käsittely antaa sinulle jäljityksen, kenttätason tilastot, mahdollisuuden suodattaa myöhemmin ja mahdollisuuden vertailla. raw -käsittely parseable sisällölle ei tarjoa mitään ja menettää kaiken tämän.

Käytä raw -käsittelyä, kun käsittely epäonnistuu tai olisi valhe sisällöstä.

8.16 SMART Terveyden linkit ja kortit

CMS:n *Kill the Clipboard* pyytää tarjoajia hyväksymään potilaan tietueet QR-koodista sisäänkirjautumisen yhteydessä ja antamaan vierailutietueen takaisin samalla tavalla. QR-koodi sisältää SMART Health Linkin (shlink:/...): osoitteen, 256-bittisen avaimen ja valinnaisesti etiketin, vanhenemisen ja salasanan lipun. Vaihto → Terveyden linkit lukee yhden.

Vastaanotto. Liitä linkki tai skannaa se kameralla, jossa selain voi (Chrome ja Edge). Perfuse hakee manifestin, salailee jokaisen tiedoston avaimella linkistä, tiivistää FHIR-pakkauksen - kuka potilas on, kuinka monta kunkin resurssin kopiota - ja tarkistaa SMART Terveydenhuollon Kortin sisällön sen julkaiseman avaimen vastaan. *Toimita kanavaan* luovuttaa FHIR-sisällön kanavalle viestinä, jolla se saavuttaa EHR-järjestelmän. Nouto pidetään egress-käytännössä yhteyden aikana, selkeä HTTP kieltäytyy ja palvelimen vastaus, joka ei ole manifestipalvelin, ei näytetä koskaan, koska osoite tuli vieraan henkilön QR-koodista.

Jakaminen. *Jaa* salailee FHIR-pakkauksen, isännöi sitä ja näyttää linkin ja sen QR-koodin kerran. Palvelin pitää salattua tekstiä eikä avainta - se ei voi avata isännöimäänsä sisältöä eikä näyttää linkkiä uudelleen. Salasana on hashoitu; kymmenen väärää salasanaa estävät linkin. Linkit vanhenevat oletusarvoisesti 30 päivän kuluttua, voivat peruutettaa ja luetella, kuinka usein ja kuka ne on noutanut. Käynnistä palvelin -public-url asetuksella, joka on https-osoite, jota potilaiden puhelimet tavoittavat; manifestin URL, jonka se rakentaa, on oltava 128 merkin määräyksen mukainen.

Kortin vahvistaminen. *Vahvista kortti* ottaa numeron shc:/ QR (yksi palanen tai useita), .smart-health-card tiedoston tai JWS:n ja kertoo, vastaako allekirjoitus julkaisijan avainta.

8.17 UN/EDIFACT

dataType: edifact lukee UN/EDIFACT-vaihtoja (ISO 9735): ORDERS, INVOIC, DESADV, IFTSTA ja loput, mukaan lukien eurooppalaiset terveydenhuollon korvaus- ja laboratoriotiedot. Palvelumerkkijonon neuvot (UNA) otetaan huomioon, julkaisemalla vapautusmerkin ja toistojen erottimen (syntaksiversio 4); toiminnalliset ryhmät (UNG/UNE) ovat valinnaisia. Vaihto toimitetaan täsmälleen sellaisena kuin lähettäjä on kirjoittanut sen.

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

Kirjekuori. UNT-segmentin määrän ja viitteen, UNE-viestin määrän ja viitteen ja UNZ-määrän ja viitteen vertaillaan vaihdon sisällön kanssa. require-asetuksella, joka on oletusarvo, epäsovinnaisuus hylkää vaihdon (se on tapa, jolla keskeytynyt siirto näkyy); warn hyväksyy sen ja kirjaa varoituksen; ignore ei tarkista.

Polut, kanavan ja kohde-suodattimien osalta, lasketaan alkiot ja komponentit yhdestä lähtien siinä järjestyksessä, jossa segmentti on kirjoitettu, kuten toteutusoppaat niitä numeroidaan: BGM-2 (asiakirjan numero), BGM-1.1, NAD(2)-2.1 (toisen NAD:n osapuoli), LIN-3(2).1 (toisto), UNB-2.1 (lähettäjä), UNH-2.1 (viestin tyyppi). Ilman ilmennystä osoitteessa osoitetaan jokainen.

Jakaminen toimittaa yhden vaihdon kunkin viestin kohdalla, kunkin alkuperäisellä UNB:llä (ja ryhmäotsikolla) ja trailerilla, joka laskee yhden, jotta tilaus voidaan suodattaa, etsiä ja yrittää uudelleen omalla tavallaan. Kohde-suodattimet näkevät kunkin palasen. Tiedoston kohde nimeää tiedostot viestityypin mukaan (ORDERS_INVOIC-20261017.edi), ja ${control_id} on vaihdon viite.

CONTRL. acknowledge: contrl-asetuksella lähettäjä, joka lähettää HTTP:n kautta, saa vastaukseksi CONTRL-syntaksin ja palveluraportin: UCI-toiminto 7, kun vaihto luettiin ja toimitettiin, 4, kun se hylättiin tai ei voitu toimittaa (HTTP 400 tai 502 sitten). Sitä ei voida yhdistää split-ominaisuuden kanssa, koska CONTRL vastaa koko vaihtoa. AS2:n yli kumppanin vastaanotto on vahvistus.

Ei tarjota: viestihakemistot (jotka jakavat ORDERS D.96A: n segmentit), joten rakennetta tarkistetaan, ei sisältöä; muunnokset, jotka kirjoittaisivat uudelleen kumppanin asiakirjan; ja suodatin- tai muunnoskriptit (esikäsittelijä ajaa ennen syntaksin tarkistusta). Tarkistettu pydifact 0.1.8: n, riippumattoman parserin, molemmissa suunnissa.

9 Vahvistukset

Vahvistus kertoo lähettäjälle, mitä tapahtui. HL7 v2:lle MLLP-yhteyden kautta se on ACK-viesti; lähettäjä ei lähetä seuraavaa viestiä, ennen kuin se saapuu, ja yleensä lähetetään uudelleen, jos se ei saavu.

Vahvistusten väärät ovat yleisin tapa, jolla integraatio häviää hiljaisesti, koska lähettäjä, jota vahvistetaan, ei ole syytä valittaa.

9.1 Ajoitus

Kattaa viestivirran, ja yhteenveto on: ack.when on oletusarvoisesti on_delivery, mikä tarkoittaa, että vahvistus lähetetään vain silloin, kun jokainen käytössä oleva kohde on hyväksynyt viestin. on_receipt lähettää sen heti, kun viesti on parsittu ja jonottu.

9.2 Mitä Perfuse lähettää

AA, kun viesti hyväksyttiin, AE, kun se hylättiin syystä, johon lähettäjä voi vaikuttaa, ja AR, kun se hylättiin syystä, johon lähettäjä ei voi vaikuttaa.

Ero AE ja AR on kuka on tehtävä. AE tarkoittaa, että viestissä oli ongelma - kenttä, joka ei voitu parsia päivämääräksi, puuttuva vaadittu segmentti - ja lähettäjä voi korjata sen ja lähettää uudelleen. AR tarkoittaa, että Perfuse ei voinut hyväksyä sitä riippumatta sisällöstä, mikä yleensä tarkoittaa konfiguraatio- tai saatavuusongelmaa tässä päässä. Lähettäjä, joka lähettää uudelleen AR:n jälkeen, saa saman vastauksen.

9.3 Tunnistaa tämän moottorin

ack.application ja ack.facility täyttävät MSH-3 ja MSH-4 vahvistuksessa.

Kun molemmat ovat tyhjiä, vahvistus peilaa alkuperäisen vastaanottajan — se käyttää samaa kuin saapuva viesti oli MSH-5 ja MSH-6. Se on se, mitä useimmat lähettäjät odottavat, ja se on oletusarvo juuri siksi.

Aseta ne eksplisiittisesti, kun lähettäjä validoi ne, tai kun useat Perfuse-ekземпляrit käsittelevät samaa syötettä ja tarvitsevat tietää, kuka vastasi.

9.4 Käynnistystapahtuma

ack.include_trigger_event lähettää ACK^A01 sen sijaan, että pelkän ACK:n.

Jotkut vastaanottajat vaativat sitä ja toiset hylkäävät sen, miksi se on eksplisiittinen valinta ilman oletusta. Jos lähettäjä hylkää vahvistuksesi ja sisältö näyttää oikealta, tämä on ensimmäinen asia, jonka kannattaa kokeilla.

9.5 Negatiiviset vahvistukset eivät ole virheitä, joita pitäisi piilottaa

NACK, joka käsitellään onnistuneena, on yksi vaarallisimmista virheellisistä konfiguraatioista, ja se on tarpeeksi yleinen ollakseen arvoinen nimeäminen. Se tapahtuu, kun kohde lähettää takaisin negatiivisen vahvistuksen ja lähettävä puoli merkitsee *siirron* onnistuneeksi, koska tavut menivät ulos ja jotain tuli takaisin.

Perfuse lukee vahvistuksen, jonka se saa MLLP-kohteesta, ja merkitsee tuloksen vastaavasti. AE tai AR alijärjestelmästä on toimitusvirhe, jota yritetään uudelleen kohteen käytännön mukaan, ja se vaikuttaa epäonnistumisnopeuteen, joka laukaisee hälytykset.

9.6 Aikakatkaisut

Vahvistuksen odottaminen on rajattu. Kun se ei saavu ajoissa, toimitus on epäonnistunut ja se on jonottamassa uudelleenkokeilua varten.

Aikakatkaisu ei ole sama kuin hylkäys, ja se merkitään eri tavoin. Hylkäys tarkoittaa, että kaukainen puoli tutki viestin ja hylkäsi sen; aikakatkaisu tarkoittaa, ettei tiedetä, käsiteltiinkö sitä. Se ero päättää, onko uudelleenkokeilu turvallista: uudelleenkokeilu hylkäyksen jälkeen on turhaa, ja uudelleenkokeilu aikakatkaisun jälkeen riski duplicatesta. Perfuse uudelleenkokeilee aikakatkaisun jälkeen, koska puuttuva kliininen viesti on yleensä pahempi kuin duplikaatti, ja vastaanottajajärjestelmä on yleensä kykenevä havaitsemaan toistuvan viestin tunnisteen.

Onko se kauppa oikea tietyn syötteen kohdalla, on arvio, ja se on tehtävä tietoisesti kaikissa tapauksissa, joissa duplikaatti voi johtaa kliiniseen seuraamukseen — tilaus, lääkehoito — sen sijaan, että hyväksytään oletusarvo hiljaisesti.

9.7 Lähteet, jotka eivät vahvista

Kaikilla kuljetuksilla ei ole vahvistuksen käsitettä. Tiedostolähde ei voi lähettää vahvistusta mihinkään; välittäjälähde vahvistaa välittäjälle eikä alkuperäiselle lähettäjälle; HTTP-lähde vastaa tilakoodilla.

Kun lähde ei voi toimittaa vahvistusmuotoa, jonka kanava pyytää, kanava hylätään latauksen aikana eikä se käynnisty ja vahvista hiljaisesti. Kanava, joka uskoo vahvistavansa ja ei tee sitä, on pahempi kuin se, joka ei käynnisty.

9.8 X12-vahvistukset

Kaikki edellä mainittu on HL7 v2:sta. X12:lla on omat vahvistukset, ja toisin kuin v2, ne ovat pois päältä oletuksena: tyhjä asetus tarkoittaa, ettei mitään lähetetä.

Se oletus on turvallinen, koska kauppakumppani, joka ei odota vahvistusta ja saa sen, voi käsitellä sitä pyynnöttömänä vaihtona. acknowledge-avain X12-kanavalla ottaa yhden neljästä arvosta:

Kuka vahvistus lähetetään, on ominaisuus kauppakumppanisuhteelle eikä viestille, miksi se on konfiguroitava ja ei voida johtaa. 999 korvaa 997:n HIPAA-transaktioissa, mutta monilla kumppaneilla — erityisesti vanhemmilla maksajayhteyksillä — on odotus 997:lle, ja he käsittelevät 999:ä tuntemattomana tiedostona.

9.9 HL7 v3-vahvistukset

HL7 v3-kanava lähettää vahvistuksen oletuksena, mikä on vastakkainen kuin X12 ja arvoista tietää.

Syy on kuljetusmuoto eikä standardi: v3-viestintä saapuu yleensä synkronisesti yhteydenottajan odottaessa vastausta, ja lähettäjä, joka ei saa mitään, yrittää yleensä uudelleen. Tämä on tapa, jolla potilas rekisteröityy kolme kertaa.

Sen poistaminen on mahdollista ja se on tehtävä nimenomaisesti — "ei asetettu" ja "asetettu epätodeksi" ovat tarkoituksella erilaisia, joten oletusarvo pysyy voimassa, ellet toisin määrätä.

10 Toimitus, jonotus ja uudelleenyritys

Kohde, jota ei voida tavoittaa, on normaali tapaus, ei poikkeus. Järjestelmät käynnistetään uudelleen, verkkoyhteydet katkeavat, ja sairaalan rajapintamoottori on käyttämätön omassa ylläpitäjäikkunassa. Toimitus perustuu siihen.

10.1 Jono kohdekohtaisesti

Kullakin kohteella on oma jono. Epäonnistunut kohde ei vaikuta muihin, ja kullakin on oma syvyys, ikä ja uudelleenyritystila.

Jonotus on kohdekohtainen eikä kanavakohtainen, koska epäonnistuminen on kohdekohtainen. Kanavakohtainen jono pitäisi pidemmän aikaa toimivien järjestelmien toimituksen, koska neljäs järjestelmä on pois käytöstä, ja kaksi tilannetta — yksi kohde ei ole saatavilla, kaikki neljä eivät ole saatavilla — näyttävät samalta tilastojen mukaan.

10.2 Jono-asetukset

queue on a destination:

Kaksi viimeistä puuttuivat tästä taulukosta ja rakentajasta, ja ne ovat pari, joka estää levyn täyttymisen. Jono, jolla ei ole kumpaakaan, kasvaa, kunnes tiedostojärjestelmä on täynnä, ja tämä epäonnistuminen ilmenee jonkin toisen asian murtumisena — kirjoitusvirhe kokonaan toisaalla — eikä jono-ongelmana.

Uudelleenyritys kasvaa yritysten välillä max_backoff:iin saakka. Kasvava ei ole kiinteä, koska kohde, joka on pois käytöstä, on yleensä pois käytöstä minuuteista sekunteihin, ja uudelleenyritys joka sekunti kymmenen minuutin ajan tuottaa useita satoja lokitapahtumia, jotka hautaavat sen, mikä on tärkeää.

10.3 Järjestys säilyy

Kohteen sisällä viestit toimitetaan saapumisjärjestyksessä, ja viesti, joka epäonnistuu, pitää paikkansa. Myöhemmät viestit odottavat sen takana eivätkä ohita sitä.

Tämä on oikea oletusarvo kliinisille tiedoille — sairaalahoito ja lähtö, jotka sovelletaan väärässä järjestyksessä, ovat huonompia kuin molemmat myöhässä — ja sillä on seuraus, joka on ymmärrettävä: yksi viesti, joka aina epäonnistuu, pitää kaiken sen takana olevan jonossa.

Siksi jonon syvyys ja jonon ikä ovat erilliset hälytysolot. Syvä jono, joka on tyhjenevä, on kiireinen järjestelmä. Jono, jonka vanhin viesti vain vanhenee, on jumissa, ja hälytystyypit queue-depth, queue-age ja queue-stuck erottavat ne toisistaan.

10.4 Kun jonotus on poistettu

Kun queue.enabled on epätosi, epäonnistunut toimitus on epäonnistunut toimitus. Se merkitään ja ei yritetä uudelleen.

Tämä on oikea valinta, kun myöhäinen tieto on pahempaa kuin ei mitään tietoa — reaaliaikainen näyttö, sivuva kuulutusjärjestelmä, mitä tahansa, jossa viesti, joka toimitetaan neljäkymmentä minuuttia tapahtuman jälkeen, olisi harhaanjohtavaa eikä vain myöhässä.

Se on väärä valinta kaikelle, mitä tallennetaan tietueeseen, jossa viesti on yhtä kelvollinen tunnin kuluttua.

10.5 Uudelleenyritys vastaan jono

On kaksi mekanismia, ja ne toimivat eri tasoilla.

retry kohdassa määrittää välittömät yritykset yhden toimituksen sisällä — yhteys, joka epäonnistuu, yritetään uudelleen lyhyen tauon jälkeen ilman poistumista toimitusreitistä. Tämä käsittelee hetkelliset virheet: yhteys, joka on pudonnut, hetkellinen kieltäytyminen.

queue määrää, mitä tapahtuu kun nopeat uudelleenyritykset on lopetettu. Viesti poistuu toimitusreitistä ja yritetään uudelleen myöhemmin pitemmällä aikataululla.

Molemmat ovat olemassa, koska kaksi epäonnistumista ovat erilaisia. Yhteys, joka on resetoitu ensimmäisellä yrityksellä, on yleensä poissa toisella yrityksellä, ja sen kautta jonoa olisi turha lisätä minuutteja viiveitä virheeseen, joka kesti millisekunteja. Kohde, joka on ollut pois käytöstä ylläpidon vuoksi, ei tule takaisin kolmen välittömän yrityksen kuluessa, ja sen hakkaaminen on turhaa.

10.6 Mikä HTTP-päätepisteen kautta lähetetyksi luetaan

HTTP-kohteella on kolme asetusta, jotka päättävät, katsotaanko viesti lähetetyksi, ja kaikki kolme ovat kohteessa rakentajassa.

Status codes that mean delivered. Empty means any 2xx. Some endpoints answer 202 Accepted for something they have not processed yet, and some answer 200 with an error in the body — the second is what *Treat as failed if the reply contains* is for. Setting an explicit list is worth doing when a partner has told you which code means what, because the alternative is discovering the difference from a message that was never delivered and never queued.

Seuraa uudelleenohjauksia. Päällä oletuksena, ja tarkoituksella. Uudelleenohjaus voi osoittaa toiseen isäntään, joten sen seuraaminen lähettää viestin jonnekin, mihin kukaan ei ole määritellyt, ja ilmoittaa onnistumisen.

Kantaja-tunniste. Lähetetään Authorization-otsakkeena. Se tallennetaan kanavan kanssa ja sitä ei koskaan näytetä uudelleen, joten tyhjän ruudun jättäminen, kun muokkaat olemassa olevaa kanavaa, säilyttää jo tallennetun tunnisteen sen sijaan, että se tyhjentäisi sen.

10.7 Nimeäminen ja arkistokansio

Tiedoston kohde liittää oletusarvoisesti yhteen tiedostoon päivittäin ja viestityypin mukaan (20261012-ADT_A01.hl7), MLLP-kehyksessä, jotta tiedosto toistaa perfuse send-käskyllä. Neljä asetusta kohteessa muuttaa sitä.

Tiedostonimi (file_name) luo yhden tiedoston kunkin viestin kohdalla, nimettynä ${date}: n, ${timestamp}: n, ${control_id}: n, ${message_type}: n ja ${destination}: n mukaan. Tiedostonimi, joka on jo olemassa (sama ohjaus-ID kahdesti), saa yksilöivän etuliitteen sen sijaan, että se ylikirjoittaisi viestin siinä.

Liitä (append: true) kirjoittaa jokaisen viestin tiedostoon, jonka Tiedostonimi nimeää, joten ${date}.hl7 on yksi tiedosto päivittäin jokaiselle tyypille.

Etuliite kirjoittamisen aikana (temp_suffix, yksi tiedosto kunkin viestin kohdalla) oletetaan .part ja poistetaan uudelleennimeämällä, kun tiedosto on valmis. Kuka tahansa, joka kerää nämä tiedostot, ei pidä poimia puolivälissä olevaa tiedostoa, ja uudelleennimeäminen kansiossa on atomia. Muuta sitä vain, jos kerääjä suodattaa toisen laajennuksen perusteella.

Poista jonka jälkeen (retain_hours) karsii kansiossa olevia tiedostoja, jotka ovat vanhempia kuin annettu tuntimäärä, tarkistettuna enintään joka kymmenes minuutti, kun viestejä saapuu. Vain suorat tiedostot kansiossa poistetaan, ei koskaan alikansioita. Tyhjä tai nolla pitää ne ikuisesti, mikä on oletusarvo ja on päätös eikä ylihuomio - mutta arkisto, jota kukaan ei karsi, täyttää levykkeen, ja täysi levyke pysäyttää kanavan eikä arkistointia.

10.8 Lähetys FHIR-palvelimeen

Kolme asetusta päättää, kuinka paljon tarkistetaan ennen kuin paketti lähtee.

Väitä US Core -mukautumista lisää profiilin jokaiseen resurssiin. Väitä sitä vain, kun resurssi sisältää, mitä profiili edellyttää, koska vastaanottaja voi validoida väitteen perusteella ja hylätä paketin, joka muuten olisi hyväksytty.

Validoi ennen lähettämistä tarkistaa jokaisen resurssin täällä vastaanottajan sijaan. Hylkäys kaukaisessa päässä kertoo sinulle vähemmän, myöhemmin, ja usein vain lokissa, jota et voi lukea.

Käsittele varoitukset hylkäyksinä vaikuttaa vain, kun validointi on päällä, ja ohjaus on käytettävissä vain, kun se on. Se on tarpeeksi tiukka estämään paketin, jonka vastaanottaja hyväksyisi, joten se kuuluu syötteen, jota otetaan käyttöön, eikä palvelussa olevaan.

10.8.1 Isännöidyt FHIR-palvelut

fhir-kohde auth-lohko kirjautuu hosted-palveluihin, jossa liimattu bearer-token loppuu tunnin kuluttua:

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 allekirjoittaa jokaisen pyynnön AWS HealthLake: lle Allekirjoitusversion 4: llä, alueen lukien URL: sta. azure saa Microsoft Entra -tunnistustodistuksen Azure Health Data Services: stä tenant_id: stä, client_id: stä ja client_secret: stä - sovellusrekisteröinti, joka sisältää FHIR Data -avustajan roolin - FHIR-palvelun URL: n yleisönä. client_credentials tekee saman OAuth 2.0: n token_url: n vastaan. Todistukset uudelleen käytetään, kunnes ne vanhenevat minuutin ennen vanhenemista. Samat valinnat ovat kohteen Isännöity palvelun kirjautuminen kanavan rakentajassa.

10.8.2 Julkinen terveydenhuollon ilmoittaminen

Merkitse ilmoitettavat tilat terveydenhuollon viranomaisille FHIR-kohteessa, ja se lähettää tapausraportteja pinoraporttien sijaan. Jokainen viesti tarkistetaan ilmoitettavan tilan laukaisinkoodin suhteen: diagnosoinnin, laboratoriotestin tai koodatun tuloksen. Jos siinä on yksi, viesti muuttuu HL7 eCR 2.1.2 eICR:ksi, joka on pakattu eCR-viestiin ja lähetetään URL-osoitteen $process-message-osoitteeseen. Jos siinä ei ole yhtään, mitään ei lähetetä, eikä mitään epäonnistu; kohde laskee sen ei-ilmoitettavaksi.

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 on ilmoitettavien tilojen laukaisinkoodit FHIR-arvojoukkona tai eRSD-pakettina. Siihen tarvitaan UMLS-lisenssi, joten sitä ei sisällytetä; ilman sitä käytetään lyhyttä sisäänrakennettua näyteaineistoa vain testaamista varten. source on kohta, jossa virasto lähettää ilmoitettavuusvastauksensa. Laitos on pakollinen, koska eCR pyytää puhelinnumeroa ja osoitetta, ja v2-viesti ei sisällä niitä.

Raportti kertoo, mitä viesti puuttui, eikä keksitä sitä, ja jokainen aukko kirjataan. Yritä viesti FHIR-laboratorion julkisen terveydenhuollon tapausraportti-paneelissa ennen kuin osoitat live-syötteen virastolle.

10.8.3 Laboratoriotulokset julkiselle terveydenhuoltoon: ELR

perfuse elr -config elr.yaml results.hl7 muuttaa laboratorion tulokset HL7 2.5.1 ELR-viesteiksi, jotka osavaltion terveysvirastot vastaanottavat, yksi kullekin viestille, jossa on ilmoitettava tulos, ja vain ne tilaukset, jotka sisältävät yhden: täydellinen verikoe positiivisen SARS-CoV-2-testin rinnalla ei ole julkisen terveydenhuollon asia. Laukaisinkoodit ovat samat kuin tapausraportoinnissa, RCTC, jonka lataat tai sisäänrakennettu näyteaineisto.

ELR nimeää kaikki OID: n tai CLIA-numeron mukaan, mitä kuitenkaan mikään laboratorion syöte ei sisällä lähettäjälle ja vastaanottajalle, joten ne tulevat tiedostosta:

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}

Tilauksen tekijä, suorittava laboratorio ja määräävät viranomaiset käytetään ainoastaan siinä tapauksessa, että laboratorion viesti jättää ne pois, ja jokainen käyttö on muistiinpano. Se, mitä vain laboratorio tietää, ei koskaan täytetä: tulos, jolla ei ole näyte-tyyppiä, menee SPM-4 tyhjänä ja muistiinpanona, koska arvattu näyte julkisen terveydenhuollon raportissa on pahempi kuin aukko, jonka osavaltio voi kysyä. Aloita processing: T:lla, kun osavaltion käyttöönoton tiimi testaa syötettä.

Se, mitä laboratorio teki oikein, säilytetään sellaisenaan, kuin se lähetettiin. Lapsitilaus (herkkyysohjelma tai refleksitesti, jonka OBR-29 nimeää vanhempansa ja jolla ei ole omaa ORC:ää) menee vastaanotettuna, ilman että sille keksitään ORC:ää tai näytettä, ja lapsi, jolla ei ole omaa ilmoitettavaa tulosta, menee vanhempansa kanssa, koska herkkyysohjelma ei merkitse mitään ilman siihen kuuluvaa kulttuuria. Muistiinpano PID:n jälkeen pysyy potilaan kanssa, ja ORC-14, palautepuhelinnumero, kopioituu OBR-17:stä, kun laboratorio on laittanut sen sinne. Kaikki 28 esimerkkiviestiä, jotka ONC julkaisee ELR-sertifioinnin työkaluun, tulevat voimassa ilman virheitä.

MSH-2 kirjoitetaan ^~\&#, viisi merkkiä, jotka ELR-julkaisun 1 virhekorjaukset vaativat ja ONC:n sertifioinnin työkalu tarkistaa. Jos osavaltion opas näyttää vanhemman neljän merkin, lisää encoding_characters: "^~\\&" tiedostoon.

Lähettääksesi ne kanavan kautta komentorivin sijaan, anna kohteelle, joka ylettyy osavaltioon, elr-lohko, joka nimeää saman tiedoston. Jokainen laboratoriotulos muotoillaan uudelleen lähtiessä, ja sellainen, jolla ei ole mitään ilmoitettavaa, ei lähetetä ollenkaan, mikä lasketaan toimitetuksi, ei epäonnistuneeksi: osavaltio pyysi ainoastaan ilmoitettavia tuloksia.

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

Lohko soveltuu HL7 v2 -kanavaan, joka toimittaa viestin itse (mllp, http, tcp, tiedosto, sftp, ftp, S3, Azure Blob, soap, viestinvälittäjät tai toinen kanava); kanava kieltäytyy lataamasta muuten, ja kun tiedosto puuttuu tai siitä puuttuu lähettävä laitos, vastaanottava sovellus tai vastaanottava laitos. Muistiinpanot kirjoitetaan lokitiedostoon viestin ohjaus-ID:n kanssa.

ELR-tiedosto on kanavan kumppani, ei kanava: perfuse check ja kanavien näyttö ohittavat sen sen sijaan, että ne ilmoittaisivat kanavan, joka ei lataudu. Kanavan rakentajassa samat kaksi asetusta ovat kohteen alla Laboratorioraportointi (ELR 2.5.1); laukaisinkoodien kenttä avautuu, kun ELR-tiedosto on nimeämistilassa, ja tallentaminen kieltäytyy tiedostosta, joka ei ole kanavan vieressä.

10.8.4 DICOMweb-arkistot

type: dicomweb tallentaa kunkin kohteen STOW-RS: Orthanc, dcm4chee, pilvi-kuvauspalvelut tai Perfuse-palvelimen oma arkisto. Anna palvelun juuri (https://pacs.example/dicom-web); /studies lisätään, ja URL, joka jo päättyy /studies-merkkijonoon, hylätään sen sijaan, että se postittaisiin /studies/studies. Todenna token (kantavatunniste) tai username ja password avulla; headers lisää muita, kuten pilvipalvelun projektiotsikkoa. Kanava tarvitsee dataType: dicom.

Palvelimen vastaus päättää tuloksen, ei ainoastaan sen tilakoodi. Kohde, jonka vastaus luettelee epäonnistuneeksi, on epäonnistunut toimitus DICOM-epäonnistumissyytä vastaavasti, ja sama koskee 202-koodia, joka ei luettele mitään tallennettua: palvelin otti pyynnön ja piti siitä mitään. Aikakatkaisu oletusarvoisesti on kaksi minuuttia, koska suuri sarja on hidasta.

10.8.5 Asiakirjarekisterit (IHE XDS.b)

type: xds julkaisee kunkin kliinisen asiakirjan XDS.b-repositorioon ITI-41 Provide and Register -menetelmällä: CDA-asiakirja tai sellainen, jonka HL7 v2 -viesti (MDM, ORU) sisältää. Metatiedot tulevat asiakirjasta ja kohteen asetuksista (source_id, patient_domain, facility_type, practice_setting), ja repositorion RegistryResponse päättää toimituksen. Katso IHE asiakirjojen jakaminen.

10.8.6 Rokotusten rekisterit

Jokainen Yhdysvaltain osavaltion immunisaatiorekisteri (IIS) ottaa vastaan HL7 2.5.1 -viestejä samalla SOAP-rajapinnalla, jonka CDC julkaisi vuonna 2011 (nimiavaruus urn:cdc:iisb:2011). Siinä on kaksi toimintoa: connectivityTest, joka osoittaa päätepisteen, ja submitSingleMessage, joka sisältää viestin. VXU^V04 -viesti ilmoittaa rokotuksesta ja tulee takaisin ACK-viestinä; QBP^Q11 -viesti kysyy potilaan historiasta ja ennusteesta ja tulee takaisin RSP^K11 -viestinä.

Valitse Rokotusten rekisteri (CDC IIS web-palvelu) kohteen palveluna tai kirjoita 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 luo kirjekuoren, joten viestiin ei ole kirjoitettavaa. Käyttäjänimi ja salasana sijoitetaan pyynnön sisään, CDC WSDL:n määrittelemään paikkaan, eikä HTTP-autentikointiin. Versio on SOAP 1.2, WSDL:n sidonta, ellet aseta version: "1.1" rekisteriä varten, jonka opas pyytää sitä. Jos rekisteri vaatii asiakasvarmenteen, aseta kohteen tls kuten mihin tahansa HTTPS-puheluun.

Rekisterin vahvistus päättää, toimittaako viesti, ei HTTP-tila. Rekisteri vastaa hylätyn kuvauksen HTTP 200 ja AR:n sisällä, joten kohde, joka luotti tilaan, ilmoittaisi hävinneen immunisaation toimitetuksi.

warnings_are_errors: true (Käsittele varoitukset virheinä) tekee jokaisen AE: n odottavan henkilöä. Vastaus, jota vastauskriptit ja HTTP-kutsuja, joka odottaa kanavaa, lukee, on rekisterin HL7-viesti: ACK tai RSP historiassa ja ennusteessa. examples/iis sisältää kolme kanavaa, joista aloittaa: VXU EHR: stä MLLP: n yli, QBP-kyselyt HTTP: n yli ja paikallinen stand-in rekisteriä varten.

Yhteydet-kojussa kysytään rekisteriltä connectivityTest, kun mitään ei ole lähetetty seitsemään päivään. Tämä toiminto on olemassa tätä tarkoitusta varten ja lähettää mitään, joten se on ainoa sovellustason tarkistus, jonka Perfuse tekee. Se osoittaa osoitteen, TLS: n ja SOAP-sidonnan, ei käyttäjänimeä ja salasanaa; vain oikea lähetyksen testaa ne.

SOAP-lähde voi vastata samalla tavalla: Vastaa immunisaatiorekisterinä, tai profile: cdc-iis lähde. Se toistaa connectivityTest, ottaa viestin submitSingleMessage: sta, palauttaa kanavan vahvistuksen return: iin ja palvelee CDC WSDL: ää ?wsdl: ssä. Käyttäjänimi ja salasana, kun ne on asetettu, tarkistetaan pyynnön arvoja vastaan, ja väärä pari saa WSDL: n SecurityFault: in. Viesti, jonka kanava hylkää, palautuu aina NAK: na, ei koskaan virheenä, kuten CDC-opas sanoo. Käytä sitä testiduplikaattina tai vastaanottamaan lähetyksiä rekisterin tavoin.

Ei käsitellä: osavaltiokohtaiset osat rekisteröinnissä. Jokaisella rekisterillä on oma päätepiste, tili prosessi ja paikallinen profiili 2.5.1-opasta (vaaditut RXA- ja OBX-kentät, VFC-kelpoisuus, kieltäytymiskoodit). Nämä ovat viestien sisältöä, jonka kanavan muunnokset muotoilee; mikään osavaltion päätepiste ei ole sisäänrakennettu. Perfuse on testattu itseään ja tallennettuja rekisterivastauksia vastaan, ei elävää osavaltion rekisteriä vastaan.

10.9 Kun kuljetus sanoo kyllä ja viesti ei saapunut

"Tuli tämä perille" on usein kysymys, jota kuljetus ei voi vastata. MLLP-vastaanottaja palauttaa sovelluksen vahvistuksen, jonka merkitys on sen tekstin mukainen. HTTP-vastaanottaja palauttaa 200 virhedokumentin kanssa. Molemmissa tapauksissa kuljetus onnistui ja viesti ei saapunut.

Tarkastele vastausta kohdistuu määränpäähän, joka ottaa vastaan kriittisen vastauksen. Palauta false tai heitä, ja toimitus on merkitty epäonnistuneeksi — mikä tarkoittaa, että se yritetään uudelleen, se laitetaan jonoon ja se näkyy epäonnistumisen määrässä sen sijaan, että se olisi hiljaisesti laskee toimitetuksi.

Se tarjotaan vain määränpäille, jotka voivat vastaanottaa vastauksen. Määränpäähän, joka ei voi, se hylätään latauksessa sen sijaan, että se jätettäisiin koskaan suorittamatta.

10.10 Mikä toimituksen tulos merkitsee

Nämä ovat tallennettu kohden mukaan kullekin viestille, joten viesti, joka saapui kolme neljästä kohdesta, on tallennettu tarkalleen siten. Kanavatasolla ei ole "onnistuminen", koska se ei merkitsisi mitään.

10.11 Hidas toimitus

Määränpää, joka hyväksyy viestejä, mutta vie niiden käsittelyyn kauan aikaa, on erillinen ongelma verrattuna siihen, joka epäonnistuu, ja se on helppo missata, koska jokainen tulos on onnistuminen.

slow-delivery -varoituslaji on olemassa tätä varten. On syytä asettaa se kaikille, joilla lähettäjän vahvistus odottaa toimitusta, koska kohde, jonka vastausajan on hiljalleen kaksinkertaistunut, ylittää lopulta lähettäjän aikakatkaisun ja alkaa tuottaa uudelleenlähettyksiä - ja siinä vaiheessa oire ilmenee ylempänä, järjestelmässä, jota et välttämättä hallitse.

10.12 Kirjoittaminen tietokantaan

type: database suorittaa lauseen kullekin viestille arvoja sitoen viestistä.

Vastaa paikkoja on ajurin oma — $1 postgresille, ? mysqlille ja sqlite: lle, @p1 sqlserverille — ja Perfuse ei kirjoita niitä uudelleen. Se on tarkoituksella: käännöskerros, joka sai paikan väärin, sitoisimme potilaan nimen väärään sarakkeeseen, ja tuloksena olisi näyttäisi kelvolliselta datalta eikä virheeltä.

Lause, joka on kirjoitettu väärässä murteessa, hylätään, kun se tallennetaan, ja mainitaan tyyli, jonka ajuri haluaa. Ennen kuin tämä tarkistus oli olemassa, virhe ilmenee syntax error at or near "," palvelimelta, kun viesti saapuu, joka mainitsee lauseen, jonka olet kirjoittanut, ja se lähettää etsimään kirjoitusvirhettä sen sijaan, että etsisi murteella.

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

Merkitty parametri on vakio eikä polku, joka on tapa, jolla kanava kirjoittaa oman nimensä tai lähdejärjestelmän koodin rinnalla viestidatan.

Arvot sitoutuvat aina parametreina. ${...}-viittaus lauseessa hylätään: nimi, joka sisältää heittomerkin, rikkoisi lauseen, ja vihamielinen arvo kirjoittaisi sen uudelleen.

10.13 Lähetys raakasokkeliin

type: tcp kirjoittaa päätepuolelle valitsemasi kehyksen, joka on se, mitä laite tai laboratoriolaite yleensä haluaa. MLLP on yksi useista kehyksistä; tämä kohde tarjoaa muut.

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

Kehys on määritettävä. Väärän kehyksen kanssa kirjoittaminen ei epäonnistu. Vastaanottava järjestelmä lukee viestit väärissä kohdissa tai odottaa päättymistunnistetta, jota ei koskaan tule, ja oire ilmenee vastaanottavassa järjestelmässä eikä täällä.

Vain valitun kehyksen asetukset hyväksytään. Tietueen pituus erotellussa virrassa hylätään sen sijaan, että se olisi huomiotta, koska asetus, joka on hiljaisesti ohitettu, on joku, joka uskoo, että se on voimassa.

expect_reply muuttaa sitä, mitä toimitettu tarkoittaa. Ilman sitä, onnistuminen tarkoittaa, että tavut saavuttivat käyttöjärjestelmän lähetyspuskurin — jonka peeri, joka kaatui hetkeä myöhemmin, ei koskaan lukenut.

10.14 Amazon S3, SQS ja SNS

Kanava voi lukea SQS-jonosta tai S3-bucketti-etuliitteen ja toimittaa SQS: ään, SNS: ään tai S3: een. Kaikki viisi ovat allekirjoitettu HTTP ilman AWS SDK: ta binääritiedostossa, ja kaikki viisi ottavat samat pääsyasetukset: region, access_key_id, secret_access_key (kirjoita ${AWS_SECRET_ACCESS_KEY} ympäristöön), valinnainen session_token ja endpoint LocalStackia, MinIO: ta tai VPC-päätepistettä varten. Valitse Kanavat → Uusi kanava, valitse *Luemme Amazon SQS -jonosta*, *Keräämme objekteja Amazon S3 -bucketista* tai SQS-, SNS- ja S3-kohteen tyypit.

Mitään ei vahvisteta AWS: lle, ennen kuin kanava on käsitellyt sen. SQS-viesti poistetaan sen jälkeen ja muutoin ilmestyy uudelleen, kun sen näkyvyysaika päättyy, joten jonon uudelleenohjauspolitiikka on se, joka siirtää yhden, joka jatkuvasti epäonnistuu, kuolleeseen kirjeen jonoon. S3-objekti siirtyy processed/: een sen jälkeen tai error/: een, jos sitä ei voitu käsitellä, joten yksi huono tiedosto ei estä loput.

FIFO-jonossa tai aiheessa viestit ryhmitellään potilaan mukaan oletusarvoisesti - SQS säilyttää järjestyksen ryhmän sisällä ja muualla - ja deduplikaatiot sisällön mukaan, joten uudelleenkäynnistys ei toimiteta kahdesti.

S3-arkisto voidaan kirjoittaa suoraan Glacieriin storage_class: n avulla ja JSON-riveiksi Amazon Athenan format: ndjson: n avulla; perfuse athena tulostaa taulun. Viittaus sisältää jokaisen asetuksen.

10.15 AMQP 1.0 ja Azure

AMQP 1.0 is what Azure Service Bus and Event Hubs speak, and RabbitMQ 4, ActiveMQ and Artemis beside their other protocols. An amqp source receives from a queue or a subscription and accepts each message only once the channel has handled it; one that could not be handled is released as a failed delivery, so the broker redelivers it and, past the queue's limit, dead-letters it. An amqp destination reports success only when the broker accepts the message. For Service Bus: addr is <namespace>.servicebus.windows.net:5671 with tls, username the shared access policy name, password its key, and address the queue name, or <topic>/subscriptions/<name> to receive.

Azure Blob Storage: azure_blob-kohteella kirjoitetaan blobi kullekin viestille valitussa pääsytasossa - Hot, Cool, Cold tai Archive - ja azure_blob-lähde poimii blobit etuliitteestä, siirtäen ne processed/: een tai error/: een, kuten S3-lähde tekee. Suositellaan SAS-tunnistetta, joka on rajoitettu säiliöön, enemmän kuin tiliavainta.

10.16 MQTT

Tämä mqtt-lähde tilaa aiheen suodattimen (+ vastaa yhtä tasoa, # kaikkia alempia tasoja) millä tahansa MQTT 3.1.1-välittäjällä: Mosquitto, EMQX, HiveMQ, AWS IoT Core, Azure Event Grid. Oletuksena QoS 1:llä kunkin viestin käsittely vahvistetaan vain kerran. MQTT:llä ei ole mahdollista hylätä yksittäistä viestiä, joten se, jota ei voida käsitellä, jätetään vahvistamatta ja yhteys muodostetaan uudelleen; välittäjä pitää istuntoa asiakastunnisteella (perfuse-<channel>, ellei client_id määrittele toisin) ja lähettää sen uudelleen ensimmäisenä jonossa. QoS 0 on enintään kerran: mitä tahansa lähetetään Perfusen ollessa alas, se häviää. mqtt-kohde julkaisee ja ilmoittaa onnistumisesta QoS 1:llä, kun välittäjä on vastaanottanut viestin.

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 vaatii asiakasvarmenne: anna tls.cert_file ja tls.key_file.

10.17 IBM MQ

ibm_mq lukee ja kirjoittaa IBM MQ -jonoja jonon hallinnan viestintä-REST-rajapinnan (mqweb) kautta, jonka IBM MQ 9.1.5 ja myöhemmät toimittavat jokaisella alustalla, mukaan lukien z/OS, joten MQ-asiakasohjelmaa ei asenneta Perfusen viereen. Käyttäjän on oltava MQWebUser-rooli ja asetuksen, haun ja selausvaltuus jonossa. Lähde selailee ensimmäisen viestin, antaa sen kanavalle ja poistaa sen vain viestin tunnisteen kautta, kun se on käsitelty; viesti, joka epäonnistuu, pysyy jonon ensimmäisenä. Suorita yksi lukija per jono. Kohde asettaa pysyvät viestit (ellei non_persistent), HL7-ohjaus-ID: n korrelaatio-ID: nä.

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 on v3 MQ 9.3: lle ja myöhemmille (oletus), v2 9.1.5: lle - 9.2: lle. Jonon hallitsija, jolla on AMQP-kanava, voidaan myös tavoittaa amqp-liitännän kautta.

10.18 Google Cloud Pub/Sub ja Cloud Storage

pubsub-lähde vetää viestin tilauksesta ja vahvistaa jokaisen viestin, kun se on käsitelty; se, joka epäonnistuu, annetaan takaisin heti (sen vahvistamisajan määräaika nolla), loput erästä, joten Pub/Sub toimittaa sen uudelleen ja, tilauksen kuolemansanomapolitiikan jälkeen, kuolemansanoo sen. pubsub-kohde julkaisee HL7-viestityypin ja ohjaus-ID: n attribuutteina; order_by: patient asettaa järjestysavaimen PID-3.1: stä, joten tilaus, jolla on viestin järjestys, pitää jokaisen potilaan viestit järjestyksessä.

gcs-kohde kirjoittaa yhden objektin per viesti, nimettynä S3-avaimen kaltaiseksi, valitussa tallennusluokassa (STANDARD, NEARLINE, COLDLINE, ARCHIVE). gcs-lähde poimii objekteja etuliitteestä ja siirtää ne processed/- tai error/-kansioon, kuten S3-lähde tekee.

Molemmat kirjaavat sisään palvelutilillä: credentials_file on sen JSON-avain. Jätä se tyhjäksi Google Cloudissa (VM, GKE tai Cloud Run) käyttääksesi siellä liitettynä olevaa palvelutiliä. endpoint nimeää emulaattorin (Pub/Sub-emulaattori, fake-gcs-server), joka ei vaadi tunnisteita.

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

10.19 Sähköpostilaatikon lukeminen (IMAP ja POP3)

email-lähde lukee postilaatikon ja muuttaa sen, mitä se löytää, viesteiksi: jokainen liite (take: attachments, oletus, kapeampi attachment_names-kuvioilla), sähköpostin teksti (take: body) tai koko sähköposti (take: raw) käsikirjoitukselle, joka purkaa sen. Laboratoriot, kuvantamiskeskukset ja pienet harjoittelualueet lähettävät edelleen tuloksia tällä tavoin.

Jokainen tarkistus kirjautuu sisään, lukee lukemattoman postin vanhimmasta alkaen ja kirjautuu ulos. IMAP: n yli sähköposti haetaan ilman, että se merkitään luetuksi, annetaan kanavalle ja vain kerran, kun jokainen viesti siitä on hyväksytty, se siirretään move_to-kansioon (Käsitelty), merkitään luetuksi (after_read: flag) tai poistetaan. Posti, joka epäonnistui tai jota ei otettu (lähettäjä allowed_senders- ulkopuolella, ei liitettä, joka vastaa attachment_names-kuviota, suurempi kuin max_message_size), siirretään error_folder-kansioon (Virhe) syyn kanssa lokissa. Molemmat kansiot luodaan, kun ne puuttuvat. POP3: lla ei ole kansioita tai lippuja, joten se poistaa: poistot vahvistetaan QUIT: n lopussa tarkistuksen lopussa, joten istunto, joka katkeaa, poistaa mitään ja käsitelty sähköposti voidaan lukea uudelleen (ei koskaan katoa). POP3-posti, jota ei oteta, pysyy palvelimella ja ilmoitetaan kerran.

Sisäänkirjautuminen on salasana (${MAIL_PASSWORD}; sovellussalasana Gmailiin) tai OAuth 2.0 SASL XOAUTH2: n yli, jota Microsoft 365 vaatii (se on sammuttanut salasanakirjautumisen) ja Gmail suosittelee:

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]

With client_secret and no refresh_token, Microsoft 365 app-only access is used (the client-credentials grant, scope https://outlook.office365.com/.default): an administrator registers the app, grants it IMAP.AccessAsApp and limits it to the one mailbox with an Exchange service principal. With a refresh_token (a person's consent), the delegated scope IMAP.AccessAsUser.All or POP.AccessAsUser.All is used, and a rotated refresh token is kept for the life of the process. Gmail needs a refresh_token: Google offers no app-only access to a mailbox.

allowed_senders ottaa osoitteita ja verkkotunnuksia. Sähköpostin From-rivi voidaan väärentää, joten se pitää esteettömänä onnettomuudet ja harhaanjohtavan postin, ei hyökkääjää; luotettava syöte kuuluu Directiin (S/MIME allekirjoitettu), SFTP: hen tai VPN: ään. security on tls (993 tai 995, oletus), starttls (143 tai 110) tai none, joka on sallittu vain localhost-osoitteelle. Tarkistukset ovat vähintään 10 sekunnin välein (60 oletuksena), koska sähköpostipalvelut rajoittavat tilit, jotka tarkistavat nopeammin.

Testattu GreenMail 2.1.3: ää (IMAPS, IMAP, POP3S ja POP3: kirjautuminen hylätään väärällä salasanalla, nouto ilman lukuun merkitsemistä, SIIRRÄ, lippu, poista, liian suuri sähköposti hylätään ennen kuin se luetaan) ja Gmailin IMAP: n kanssa sovellussalasanalla (luo kansio, liitä, nouto, SIIRRÄ, poista). OAuth testattiin vain stand-in-tunnisteiden päätepisteeseen: ei Microsoftia tai Googlea vastaan.

10.20 AS2

AS2 (RFC 4130) on tapa, jolla useat maksajat, välittäjät ja toimittajat vaihtavat EDI-tietoja: HTTP POST -pyyntö, jonka sisältö on allekirjoitettu lähettäjän varmenneksi ja salattu vastaanottajan varmenneksi, ja johon vastataan kuittauksella (MDN), joka nimeää saapuneen viestin tiiviste. S/MIME on sama koodi, jota käytetään suorassa viestinnässä. Molemmat päät ovat kanavan rakentajalla: Liikekumppanit lähettävät meille EDI-tiedot AS2: n kautta lähteenä, Liikekumppani AS2: n kautta kohdekohtaisesti.

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

Vastaanotto. Viesti, joka on osoitettu jollekin muulle AS2-To: lle tai joka tulee lähettäjältä, jota ei ole partners -luettelossa, hylätään 403 -virheilmoituksella ja ilman kuittauksia. Liikekumppanin viestin on oltava allekirjoitettu ja salattu, jollei sen luetteloon allow_unsigned tai allow_unencrypted ole asetettu. Viestin sisältö salataan, sen allekirjoitus tarkistetaan liikekumppanin varmenneksi (liikekumppanit vaihtavat yleensä itse allekirjoitetut varmenteet, mikä on hyväksytty: varmenne on luottamus), ja se toimitetaan kanavalle sen määrittelemässä viestimuodossa. Liikekumppani saa pyytämänsä kuittauksen: vastauksessa tai lähettämällä sen Receipt-Delivery-Option -osoitteeseen; allekirjoitettu, kun se on pyytänyt allekirjoitettua. Viesti, joka epäonnistuu, saa kuittauksen, joka nimeää syyn (decryption-failed, authentication-failed, insufficient-message-security, unexpected-processing-error).

Lähetys. Jokainen viesti on allekirjoitettu (SHA-256) ja salattu (AES-256-CBC). receipt: sync -asetuksella, joka on oletusarvo, se katsotaan toimitetuksi vain, kun kuittaus on verifioitu partner_cert_file -tiedostoa vasten, sanoo processed, ja sisältää saman tiiviste (MIC) kuin mitä lähetettiin; muu on epäonnistunut toimitus ja se yritetään uudelleen. receipt: async pyytää kuittauksen receipt_url -osoitteesta, joka on oltava AS2-lähde tässä palvelimessa, joka luetellaan liikekumppani: viesti katsotaan toimitetuksi, kun liikekumppani hyväksyy pyynnön, ja myöhempi kuittaus, joka ei ole sama, kirjataan virheeksi. receipt: none ei pyydä mitään. unsigned, unencrypted ja unsigned_receipt -asetukset poistavat kunkin osan, jos sopimus niin sanoo; username ja password lisäävät HTTP-perusautentikoinnin portille, joka vaatii sitä. Sisällön tyyppi seuraa kanavan muotoa (application/edi-x12 X12: lle) ellei content_type aseta sitä.

Triple DES, AES-128 ja AES-192 luetaan yhtä hyvin kuin AES-256, koska liikekumppanit lähettävät niitä edelleen, ja myös Java-porttien kirjoittama streaming BER (määrittelemättömät pituudet) luetaan.

Pakkaus (RFC 5402). Pakattu viesti luetaan kummallakin tavalla, jolla se on rakennettu: pakattu ennen allekirjoittamista tai salaamista, tai allekirjoitettu viesti pakattu kokonaisuudessaan. Kuittauksen MIC noudattaa RFC: ä: allekirjoitettua, kun se on allekirjoitettu, ja pakkaamattoman sisällön, kun se ei ole allekirjoitettu. Viesti, joka laajenee yli kymmenkertaiseksi lähdekohtaisen max_message_size -arvon, hylätään decompression-failed -virheilmoituksella, jotta muutamia kilotavuja ei voida väittää gigatavuiksi muistia. Kohde pakkaa compress: true -asetuksella, ennen allekirjoittamista ja salaamista, kuten useimmat portit tekevät; kysy liikekumppanilta ensin.

Viesti lähetetään kahdesti. Liikekumppani, joka ei ole koskaan saanut meidän kuittauksemme, lähettää viestin uudelleen samalla Message-ID: llä (RFC 4130, osa 7.5). Lähde muistaa kunkin liikekumppanin Message-ID: t duplicate_window -ajaksi (oletusarvo 720h, 30 päivää; vähintään tunti) ja vastaa uudelleenlähetykseen processed -kuittauksella ilman viestin uudelleenlähetystä. Tietue pidetään tietokannassa, joten uudelleenkäynnistys ei unohda sitä. Viestin prosessointi epäonnistui, eikä sitä muisteta, joten liikekumppanin uudelleenyritys menee läpi. Samanaikaisesti saapuvat kopiot odottavat toisiaan, ja vain ensimmäinen lähetetään eteenpäin. Jos tietuetta ei voida lukea, viesti hylätään unexpected-processing-error -virheilmoituksella, ja liikekumppani yrittää uudelleen myöhemmin, sen sijaan että riskittäisiin toisen kopion lähetyksessä. Viesti, jolla ei ole Message-ID: tä, ei voida tunnistaa, ja se kirjataan sellaisena.

Yhteensopivuus testataan pyas2lib 1.4.3: ää vastaan molemmissa suunnissa, Triple DES: n ja AES-256: n, pakattujen ja epäpakattujen, allekirjoitettujen synkronisten kuittauksien kanssa.

10.21 OpenPGP

Maksajat, välittäjät ja valtion virastot ottavat usein ja lähettävät tiedostoja vain OpenPGP: n avulla. pgp -lohko lähdekohtaisesti avaa saapuvan tiedoston; yksi kohdekohtaisesti suojaa lähtevän tiedoston. Molemmat ovat kanavan rakentajalla: Avaa PGP-salaus lähteen alla, Salaa OpenPGP: llä kussakin kohteessa.

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}

Avain tiedostot luetaan kanavatiedoston suhteen, ja ne luetaan ja avataan, kun kanava ladataan: puuttuva avain tai väärä salasana pysäyttää kanavan siinä, eikä ensimmäisessä tiedostossa.

• Lähteenä, koko tiedosto, objekti, sähköpostiliite tai pyynnön sisältö avataan ensin ja sitten jaetaan viesteiksi, joten eräässä tiedostossa salattu erä toimii. Tiedosto, jota ei voida avata, hylätään: tiedostolähteessä se siirretään virhelokeroon, HTTP-lähettimelle vastataan 400 virhesyötteen kanssa. require_signature hylkää viestin, jota ei ole allekirjoittanut yksikään verify_with:n avaimista; allow_unencrypted hyväksyy viestin, joka on vain allekirjoitettu; pass_plain päästää viestin, joka ei ole lainkaan PGP-viesti, muuttumattomana, kansioon, joka vastaanottaa molempia.
• Kohde, se, mitä olisi toimitettu, salataan (mihin tahansa encrypt_to:n avaimista) ja allekirjoitetaan (avaimella sign_with), jokaisen muun vaiheen jälkeen. Tiedosto-, SFTP-, FTP-, S3-, Azure Blob- tai GCS-kohde nimeää edelleen tiedoston salamattoman viestin mukaan, joten ${control_id} toimii, ja kehys on salauksen sisällä. armor: true kirjoittaa .asc-tekstin sijaan binääritiedoston; no_compress poistaa pakkaamisen; file_name on nimi, joka kulkee viestin sisällä.

Viestit kirjoitetaan AES-256: lla RFC 4880 -muodossa, jota vanhemmat vastaanottimet lukevat, ja uudempi RFC 9580 -muoto luetaan myös. Salakirjoitus on ProtonMail/go-crypto; Perfuse ei toteuta primitiivejä. Yhteensopivuus testataan GnuPG: ää vastaan molemmissa suunnissa: gpg salaa ja verifioi, mitä Perfuse kirjoittaa, ja Perfuse avaa ja verifioi, mitä gpg kirjoittaa.

10.22 Toimitus toiseen kanavaan

Kanavan kohde luovuttaa viestin toiselle kanavalle nimeltä. Vastaanottava kanava käsittelee sen kuten minkä tahansa saapumisen: se merkitsee sen, suodattaa sen, muuttaa sen ja jakaa sen.

Tämä on tuettu tapa rakentaa ketju. Se on tietoisesti näkyvä — kaksi kanavaa, kaksi joukkoa tilastoja, kaksi merkintää viestihistoriassa — koska ketju, joka on piilotettu yhden kanavan sisään, on ketju, jota kukaan ei voi valvoa.

Viesti luovutetaan muistissa eikä verkon yli, joten siinä ei ole kehystystä, vahvistusta eikä aikakatkaisua kahden kanavan välillä.

10.23 Mitä tapahtuu, kun prosessi tapetaan

Se, joka on ajettu rajapintamoottoria, kysyy ensimmäiseksi, ja se on vastaus, jota harvoin saadaan, koska rehellinen vastaus on yleensä nolo.

Se vastattiin tappamalla prosessi SIGKILL: llä erän aikana — mikä on sama kuin virran katkeaminen, muistin loppuminen ja hypervisorin resetointi — ja laskemalla, mitä selvisi verrattuna siihen, mitä oli luvattu.

Testattava ominaisuus ei ole "ei mitään menetetä". Se ei ole saavutettavissa, ja sen väittäminen olisi valhe. Se on kapeampi lupaus, johon lähettäjä todella luottaa: viesti, joka on vahvistettu myönteisesti, on viesti, joka on saapunut.

Kun ack.when: on_delivery (joka on oletus), jokainen kohde kirjoitetaan ennen kuin vahvistus lähetetään, joten AA on lausunto kohdesta eikä jonosta. Viesti, joka tapetaan ennen vahvistusta, voi hyvin hävitä, ja se on oikein: lähettäjälle ei ollut luvattu mitään, ja se lähettää sen uudelleen.

10.23.1 Vahvistus toimituksen yhteydessä

Viisi suoritusta, tapettu 5, 25, 40, 75 ja 110 viestin jälkeen 120:sta.

Lupaus pidettiin jokaisessa tapauksessa, eikä mitään toistettu. Toisto olisi ollut hyväksyttyvä, ja menetys ei: uudelleen lähetetty A08 on häiriö, jonka vastaanottajat voivat hyväksyä, ja laboratoriotulos, joka ei saapunut hiljaa, on potilasturvallisuuden tapahtuma.

10.23.2 Vahvistus vastaanotossa

on_receipt vastaa heti, kun viesti on jonossa, ennen kuin kohde on kirjoitettu. Tämä luku on aina sanonut, että vahvistettu viesti voidaan edelleen hävittää tällä tavoin.

Periaatteessa kaikki lentokoneessa. Asetus ei ole vika, ja on olemassa syötteitä, joissa se on oikea valinta, mutta se pitäisi valita tietäen, että kaatuminen hylkää sen, mitä on vahvistettu ja mitä ei ole kirjoitettu, ja että se on melkein kaikki räjähdys.

Ei mitään palautettu käynnistyskerran jälkeen, koska perfuse run ei ole kestävää tallennusta. Kohde, joka ei saa menettää viestejä katkoksen aikana, tarvitsee queue.enabled, joka tarvitsee tietokantaa, jonka perfuse serve tarjoaa — ja perfuse run kieltäytyy nyt tällaisen kanavan käynnistämisestä sen sijaan, että se käynnistäisi sen ilman jonoa.

10.23.3 Lähettäjä, joka kuolee puolivälissä viestiä

Näistä virheistä vaarallisimman, koska HL7-viesti, joka on katkaistu, yleensä kuitenkin parseataan. Ennen katkosta olevat segmentit ovat täydellisiä ja hyvin muotoiltuja, joten vastaanottajalla ei ole mitään keinoa tietää, onko PID ja PV1 saapunut ja OBX-segmentit, jotka sisältävät tulokset, eivät.

Runko avattiin, kuusi kymmenesosaa viestistä lähetettiin, ja yhteys resetoitui sen sijaan, että se suljettiin. Osittainen viesti ei toimitettu, kuuntelija selvisi, ja hyvin muotoiltu viesti, joka lähetettiin heti sen jälkeen, hyväksyttiin normaalisti, joten fragmentti ei kulkeutunut seuraavaan viestiin.

Yhteysloki ilmoittaa nyt, monta tavua keskeneräistä kehyksestä hylättiin, jokaisessa virhetilanteessa eikä ainoastaan siistissä sulkemistilanteessa. Aikaisemmin kaatunut lähettimelle, prosessi, joka tapettiin, ja irrotettu kaapeli kaikki ilmoittivat messages=0 ja mitään muuta, mikä ei voi erottaa tyhjää terveystarkastelua laboratoriotuloksesta, joka heitettiin pois yhdeksän kymmenesosaa läpi.

10.23.4 Täysi levy

Tilan loppuminen havaitaan ja kirjataan sen sijaan, että se niellään. Kaksi asiaa siitä on arvoista tietää.

Lähettäjä ei saa välitöntä hylkäystä. Toimitus yrittää uudelleen normaalilla aikataululla — yksi sekunti, kaksi, neljä, kahdeksan — ja kielteinen vahvistus saapuu noin viidentoista sekunnin kuluttua. Lähettäjä, jonka omien aikakatkaisujen aika on lyhyempi kuin se, näkee jumittuneen yhteyden sen sijaan, että se näkisi AE: n, ja se johtaa siihen, että verkko on vikainen eikä levy.

Ja volyymi, joka ilmoittaa nolla vapaita tavuja, voi silti hyväksyä pieniä lisäyksiä jonkin aikaa, koska muutaman sadan tavun lisääminen tiedostoon, jonka viimeinen lohko on tilaa, ei vaadi uutta varaamista. Ensimmäinen kirjoitusvirhe tapahtuu myöhemmin kuin hetkellä, jolloin levy täyttyi.

10.23.5 Mitä ei testattu

Kohdekansio menetti kirjoitusoikeuden. Sitä ei voitu injektoida chmod: n avulla: moottori pitää tulostiedostoa auki, ja tiedoston tilan muuttaminen ei vaikuta aikaisemmin avattuun kuvaajaan. Sen kokeileminen oikein vaatii volumen uudelleen kiinnittämistä vain luku-tilassa tai poistamista prosessin alta, mitä ei ole tehty. Se mainitaan tässä sen sijaan, että se jätettäisiin mainitsematta, koska aukko, josta kukaan ei mainitse, luetaan aukoksi, jota kukaan ei etsi.

11 Hälytykset

Mitään Perfusen ulkopuolella ei kerro, että syöte on loppunut. Lähettäjä on vahvistettu ja tyytyväinen; vastaanottajalla ei ole mitään keinoa tietää, onko viesti lähetetty. Hälytykset ovat ainoa asia, joka erottaa rikkinäisen rajapinnan ja jonkun, joka huomaa sen viikoja myöhemmin.

11.1 Hälytystyypit

Nämä neljä viimeistä tarkkailevat potilastietojen pääsyä ja niistä kerrotaan seuraavassa.

11.2 Hiljaisuus on vaikein asia havaita

Kanava, joka on lopettanut viestien vastaanottamisen, ei tuota virheitä. Siinä ei ole mitään lukittavaa. Tämän vuoksi no-traffic on olemassa, ja siksi se ei ole tarpeeksi hyvä yksinään.

no-traffic on kiinteä kynnysarvo: hälytä, jos mitään ei ole saapunut, sanotaan, kahden tunnin ajan. Syötössä, joka ei todella koskaan ole hiljainen, se toimii. Klinikan laboratoriosyötössä se on hyödytön — syöte on hiljainen joka yö ja viikonloppuisin, joten kahden tunnin kynnysarvo hälyttää jonkun kello 1 aamulla joka yö, ja kynnysarvo, joka on tarpeeksi pitkä selviytymään viikonlopun yli, ei huomaa tiistai-aamun katkoa ennen tiistai-iltapäivää.

Ei ole yhtä numeroa, joka on molemmat. Tämä ei ole säätöongelma; se on, että kysymys "onko tämä syöte lopettanut" ei voida vastata vakioarvolla, kun syötteen normaali vaihtelee satakertaisesti viikon aikana.

11.3 Rytmitietoinen havaitseminen

below-rhythm vertaa nykyistä liikennettä siihen, mitä tämä kanava normaalisti tekee tässä tunnissa tässä päivässä viikossa.

Perfuse oppii kunkin kanavan viikon omasta tallennetusta historiasta: 168 tunnin kokonaista, maanantai ensin, jotta työviikko on yhtenäinen. Kussakin kokonaistunnissa se pitää mediaania, matalaa ja korkeaa, lattiaa ja montako havaintoa se perustuu.

Kynnysarvo on osuus normaalista, oletusarvo 0.8 (80 prosenttia konsolissa) — hälytä, kun liikenne laskee alle neljännesosan siitä, mikä on normaalia tässä tunnissa.

11.3.1 Mediaani, ei keskiarvo

Yksittäinen viiveen puhdistus 40 000 viestistä normaalin 300 viestin vastaan siirtää keskiarvon tarpeeksi siirtymään, jotta syöte voi mennä täysin hiljaiseksi ilman, että se koskaan laskee alle sen.

11.3.2 Lattia on prosentti, ei vähin

Päätetäänkö kanavan rytmistä, onko se luotettava hälyttämiseen, sen matala päättää, ei sen korkea pää. Hälytys vajaasta liikenteestä laukaisee, kun liikenne on *matala*, joten vain matala pää voi kertoa, aiheuttaako se väärän positiivisen tuloksen. Aikaisemmassa versiossa vertailtiin korkeaa mediaania ja se meni väärin molemmissa suunnissa: se hylkäsi täysin vakaan syötteen kuukauden ajaksi yhden viiveen jälkeen, ja se hyväksyi oikeasti epätasaisen syötteen, joka vaihteli kahden ja yhdeksän sadan viestin välillä samassa tunnissa, koska sen korkea oli vain kolme kertaa sen mediaani.

Lattia on kahdenkymmenes prosentti, ei vähin, koska vähin vetää yksittäinen pankkien loma nollaan. Ja prosentti ei ole interpoloitu — jokainen luku hälytyksessä kello 2 aamulla pitäisi olla laskelma, jonka syöte on todella tuottanut, ei keskiarvo laskelmista, joita se ei ole tuottanut.

11.3.3 Se kertoo, kun se ei voi sanoa

Kanava, jolla ei ole lainkaan historiaa, jätetään kokonaan pois sen sijaan, että se kohdellaan kanavana, joka on lopettanut. Uusi kanava ei saa näyttää rikkoontuneelta.

Missä historia on liian ohut tai liian epätasainen tukeakseen päätöstä, sääntö kieltäytyy laukaisemasta sen sijaan, että se arvaisi. "En voi rehellisesti sanoa" on ensiluokkainen vastaus tässä, ja se on mieluummin valittu hälytyksestä, joka on oikein hieman useammin kuin sattuma.

Poissa olevat tunnit oppimisikkunassa merkitään oikeasti nollaksi, ei puuttuvaksi dataksi. Puoli signaalia klinikan syötössä on *siitä, milloin se on laillista hiljainen*, ja niiden tuntien käsittely puuttuvana datana heittäisi sen pois.

11.4 Hälytysten asettaminen

Käyttöliittymästä, Valvontaa-välilehdeltä, kunkin kanavan tai kaikkien kanavien osalta. Jokaisella säännöllä on tyyppi, kynnysarvo ja määränpää, johon hälytys lähetetään. Säännöt tallennetaan tiedostoon alerts.yaml tietokannan vieressä (tai tiedostoon, jonka nimi on -alerts) ja ne tulevat voimaan välittömästi; kunnes ensimmäinen tallennus tehdään, käytetään sisäänrakennettuja sääntöjä. Tiedostoa voidaan myös muokata käsin: muutos otetaan käyttöön 30 sekunnin kuluessa, ja tiedosto, jota ei enää voi ladata, ilmoitetaan lokissa ja voimassa olevat säännöt säilytetään.

Arvoa tehdä ennen kuin syöte menee liveen sen sijaan, että se tehdään ensimmäisen tapahtuman jälkeen. Tietty joukko, joka on arvokasta millä tahansa kliinisellä syötöllä:

1. below-rhythm — syöte on mennyt hiljaiseksi, kun se ei pitäisi olla hiljainen.
2. error-rate — viestit saapuvat ja epäonnistuvat.
3. queue-age — jokin on jumissa eikä vain kiireinen.
4. channel-down — kanavaa ei suoriteta lainkaan.

Ensimmäinen on se, joka sieppaa epäonnistumisen, jota kukaan muu ei ilmoita.

11.5 Potilastietojen pääsyä valvotaan

Tietoturvaloukkaus ilmoittaa itseään harvoin. Se näyttää siltä, että syöte kuljettaa enemmän kuin tavallisesti, liikennettä kello kolme aamulla kanavalla, joka toimii vain päiväsaikaan, määränpäähän, jota kukaan ei ole määritellyt, tai yhden henkilön avaamassa potilas toisensa perään. Perfuse valvoo näitä neljää, ja ne ovat käytössä oletusarvoisesti (serve -watch-access=false poistaa ne käytöstä), ja se ilmoittaa havaintonsa yllä mainittujen hälytysääntöjen kautta, joten se on määritetty, vahvistettu ja toimitettu kuten mikä tahansa muu hälytys.

• Purkaukset (phi-volume). Kunkin kanavan nopeus verrataan sen omiin historiatietoihin samalta tunnilta, joten kiireinen aamu ei ole uutinen. Kynnysarvo on kerroin kanavan normaalista nopeudesta, oletusarvoisesti kolme. Purkaus on yleensä jono, joka on vapautunut palvelun katkoksen jälkeen, ja se on myös näin, miten tietojen poisto kanavan kautta näyttää.
• Yöliikenne päiväkanavalla (phi-after-hours). Kanava lasketaan päiväsaikaiseksi, kun alle 2 prosenttia siitä, mitä se on kuljettanut, on ollut ulkona kello 7 ja 19 välisenä aikana palvelimen aikavyöhykkeessä.
• Uusi määränpää (phi-new-destination). Osoite on se, mihin määränpää on nimetty: isäntä ja portti, URL, kansio. Määränpään uudelleennimeäminen ei ole uutinen; osoittaminen uuteen isäntään on. Kunkin kanavan lähettämät osoitteet säilytetään tiedostossa access-watch.json tietokannan vieressä, joten määränpää, joka on muutettu palvelimen ollessa pois käytöstä, ilmoitetaan edelleen.
• Joukkolukeminen (phi-bulk-reads). Lasketaan audit-reitistä: viestejä avataan, potilaita etsitään tai tarkastellaan (PDQm, PIXm, henkilöhaku), asiakirjoja ja kuvia luetaan (XDS, MHD, DICOMweb), aiemmat valtuudet luetaan, yhteenvetoja ja näkymien suoritetaan. Saman tiedon uudelleen lukeminen ei laske kahteen kertaan. Kynnysarvo on montako eri tietoa yhden tilin ja yhden osoitteen kautta minuutissa, oletusarvoisesti kymmenen.

Mitään kanavaa ei arvioida, kunnes se on kuljettanut 200 viestiä, koska "epätavallinen" tarkoittaa mitään ilman mallia. Malli opitaan viimeisen kahden viikon aikana tallennetuista viesteistä, kun palvelin käynnistyy, joten palvelimen uudelleenkäynnistäminen ei tee kaikista kanavista uusia. Mitä tahansa havaitaan, se pidetään 15 minuutin ajan, minkä jälkeen hälytys tyhjenee itsestään.

Se vain valvoo ja ilmoittaa. Se ei koskaan pidättele viestiä tai kiellä lukemista: nämä ovat heuristiikkaa, ja syötteiden pysäyttäminen, koska arvaus oli väärä, on kliininen ongelma. Kussakin hälytyksessä kerrotaan, mitä on havaittu ja mitä se voi olla viattoman.

Järjestelmänvalvojat näkevät, mitä valvonta on oppinut Valvontanäytöllä, Potilastietojen pääsy -osiossa: kunkin kanavan malli (edelleen oppimassa, vain päiväsaika, tai sekä päivä- että yöaika), montako määränpäätä se tuntee, ja kaikki, mitä on havaittu viimeisen 15 minuutin aikana, mukaan lukien se, mikä on alle kynnysarvon.

11.6 Mihin hälytykset menevät

Hälytykset voidaan lähettää JSON-muodossa webhookiin (-alert-webhook: Slack, Teams, Mattermost, PagerDuty, Alertmanager tai mikä tahansa, joka hyväksyy POST-pyynnön), lähettää SNMPv2-ansoittimina SNMP-hallitsijoille (-snmp-traps, ks. SNMP) tai kirjoittaa lokitiedostoon kerääjän noutamista varten. Sähköpostitoimitusta ei ole: osoita webhook sähköpostireleelle, jos hälytykset on toimitettava sähköpostitse.

Hälytys, joka on kirjoitettu lokitiedostoon, jota kukaan ei lue, ei ole hälytys. Jos Perfuse on ainoa, joka huomaa lopetetun syötteen, hälytys on saada se henkilölle.

12 Viestivarasto

Jokainen Perfuseen saapuva viesti tallennetaan sellaisenaan, ennen kuin siihen tehdään muutoksia. Samoin tallennetaan se, mitä lähetettiin kuhunkin määränpäähän ja mitä sille tapahtui. Varasto on SQLite-tiedosto, joka määritellään -db-valinnalla.

12.1 Mikä tallennetaan

Jokaisen viestin osalta: raakabitit, kun ne saapuivat, kumpi kanava, parsittu viestityyppi ja laukaiseva tapahtuma, sekä suodatusulos.

Jokaisen määränpään osalta jokaiselle viestille: lähetetyt bitit, tulos, kulunut aika ja mahdolliset virheet tai kielteiset vahvistukset.

Tämä on tutkimuksen tarvitsema muoto. "Mitä he lähettivät meille", "mitä me lähettimme heille" ja "mitä he sanoivat siitä" ovat kolme eri kysymystä, ja kullekin niistä löytyy vastaus.

12.2 Haku

Kanavan, aikavälin, tuloksen, viestityypin ja laukaisevan tapahtuman, sekä kentän arvon perusteella.

Kenttähaku toimii parsitun viestin kanssa, joten esimerkiksi ennusteenumeron haku löytää sen siitä, mihin kohtaan viesti sijoittuu, eikä se vastaa pelkästään numeroiden osumia tekstissä. Tekstihaku 12345 viestissä, joka sisältää määrän 12345, löytää viestin, jolla ei ole mitään tekemistä etsimäsi potilaan kanssa.

12.3 Toisto ja uudelleenprosessointi

Siksi, että alkuperäinen viesti säilytetään, viesti voidaan ajaa uudelleen nykyisen konfiguraation läpi.

Jäljitys ottaa tallennetun viestin ja näyttää, mitä kanava tekisi siitä nyt, ilman että mitään lähetetään. Käsitellään kohdassa virheenjäljitys.

Uudelleenprosessointi ajaa viestin uudelleen, mukaan lukien toimitus. Tämä korjaa viestipaketteja, jotka epäonnistuivat, koska määränpää oli väärin määritetty: korjaa määränpään konfiguraatio, valitse vaikuttavat viestit ja uudelleenprosessoi.

12.4 Vanheneminen

Vanhan viestin jäljitys nykyistä konfiguraatiota vasten vastaa hypoteettista kysymystä: mitä *tapaisi* nyt. Tämä on yleensä se, mitä haluat, mutta ei aina — jos tutkit, mitä meni pieleen edellisenä tiistaina, kanava saattaa olla muuttunut sen jälkeen.

Perfuse havaitsee tämän ja ilmoittaa siitä. Vanhan viestin jäljitys, joka saapui ennen kuin kanavaa viimeksi muokattiin, on merkitty sellaiseksi, jotta vastausta ei sekoiteta todelliseen tapahtumakuvaan.

12.5 Säilytys

Varasto kasvaa. cleanup.periodDays-ominaisuus määrittää, kuinka kauan viestejä säilytetään.

Kaksi asiaa, jotka on painotettava. Kliiniset viestit saattavat kuulua pidemmän säilytysajan alaisuuteen kuin mitä valitsisit operatiivisista syistä, ja varasto ei ole järjestelmän virallinen rekisteri — vastaanottava järjestelmä on. Perfusen kopio on olemassa diagnosoida ja uudelleenprosessoida, ja molemmat tarpeet vähenevät terävästi muutaman viikon jälkeen.

Säilytys määrittää myös, kuinka paljon historiaa rytmin oppimiselle on käytettävissä. Katso alerting: säilytysikkuna, joka on muutamia viikkoja lyhyempi, jättää sen kykenemättömäksi erottamaan hiljaisen sunnuntain lopetetusta syötteestä.

12.6 Varasto sisältää kliinisiä tietoja

Tämä on Perfusen osa, joka sisältää potilastietoja, ja sitä tulisi kohdella asianmukaisesti: se tulisi säilyttää salatulla tallennuksella, varmuuskopioitu kuten kliiniset tiedot ja pääsy on kontrolloitu. Katso turvallisuus.

Luodut testiviestit, jotka on kuvattu kohdassa testing, ovat osittain olemassa, jotta näitä tietoja ei tarvitse viedä ympäristön ulkopuolelle jotta voidaan toistaa ongelma jossakin muualla.

13 Virheenjäljitys

Kysymys on lähes aina sama: tämä viesti tuli sisään, jokin meni pieleen, missä vaiheessa se muuttui? Perfuse vastaa siihen toistamalla tallennetun viestin nykyisen konfiguraation kautta ja näyttämällä jokaisen vaiheen.

Mitään ei lähetetä jäljittäessä. Kanava toimii muuttumattomana, eikä uudelleen käyttöönottoa tarvita.

13.1 Viestin jäljittäminen

Valitse mikä tahansa tallennettu viesti ja jäljitä se. Tulokset näytetään järjestyksessä:

• Mikä suodatin luki. Mitkä kentät se tarkasteli ja mitä arvoja se löysi. Suodatin, joka hylkää kaiken, lukee yleensä polkua, jota tässä syötteessä ei ole, ja se nimeää sen.
• Kukin muunnos. Mitä se muutti, mistä mihin.
• Mikä kussakin kohde päätti. Hyväksyikö se viestin ja miksi ei, jos se ei hyväksynyt.
• Lopputulos. Viesti kuten kunkin kohde lähettäisi sen.

13.2 Askelttain

Askeltava näkymä suorittaa kunkin muunnoksen erikseen ja ottaa valokuvan koko viestistä sen jälkeen. Numeroiden raitisilla askelmuodoilla, joissa on väri, joka kertoo, mitä tapahtui, ja viesti kuten se oli kussakin vaiheessa.

Koko viesti muutoksen sijaan, koska ongelma ei usein ole siinä, missä muutos on — askel, joka muutti kohdistetun kentän oikein, viestillä, jolla aiempi askel oli jo asettanut väärän asian sinne, näyttää täydelliseltä eristetyssä.

13.3 Neljä lopputulosta ja se ero, joka on merkittävä

no-effect ja skipped ilmoitetaan erikseen, ja tämä on koko ominaisuuden pointti.

Ulkopuolelta ne ovat identtisiä: viesti on sama molemmissa tapauksissa. Ne tarkoittavat vastakkaisia asioita. skipped tarkoittaa, että ehto toimi kirjoitettuna ja tämä viesti ei ollut sellainen, johon se sovelsi — yleensä oikein. no-effect tarkoittaa, että askeltapahtuma suoritettiin ja se ei löytänyt mitään tekemistä, mikä yleensä tarkoittaa, että se on kohdistettu kenttään, jota ei ole.

Moottori, joka ilmoittaa molemmat vain "ei tapahtunut mitään", jättää sinut kykenemättömäksi tunnistamaan toimivan ehdollisen ja rikkoontuneen polun välillä, ja se on yleisin muunnosvirhe, joka on olemassa.

13.4 Muutoksen testaaminen ennen tallentamista

Rakentaja voi suorittaa ehdokaskaavan tallennetun liikenteen kautta ja ilmoittaa, mitä se eroaisi. Tämä on turvallisin tapa muuttaa live-kanavaa: tee muutos, katso, mitä se tekee viimeisten muutaman sadan oikean viestin kanssa, ja tallenna sitten.

Se on myös keino selvittää, että muutos, joka näyttää selvästi oikealta, vaikuttaa viesteihin, joista et ollut ajatellut — askel, joka on ehdollistettu yhdelle laukaisevalle tapahtumalle, syötteellä, joka osoittautuu kantavan neljää.

13.5 Mitä jäljittäminen ei voi kertoa

Se suorittaa nykyisen konfiguraation. Jos kanavaa on muokattu viestin saapumisen jälkeen, jäljitys on hypoteettinen eikä rekonstruktio, ja Perfuse merkitsee sen sellaisena eikä anna eroa kulkeutua hiljaa.

Se ei myöskään harjoita kuljetusta. Jäljitys näyttää, mitä lähetettäisiin, eikä sitä, hyväksyisikö kohde sen — viesti, joka on oikein, ja kohde, joka kieltäytyy yhteyksistä, tuottavat puhdasjäljityksen ja epäonnistuneen toimituksen. Ne ovat näkyvissä toimitusrekisterissä sen sijaan.

13.6 Skriptit

Skripti on yksi epäselvä askel jäljityksessä. Perfuse voi näyttää, mitä tuli sisään ja mitä tuli ulos, eikä se voi näyttää, mitä tapahtui välimaastossa tai mitä kenttiä luettiin.

Tämä on kirjoitetun koodin käytön konkreettinen kustannus verrattuna deklaratiivisiin vaiheisiin, ja se on syytä punnita valinnan tekemisen yhteydessä. Katso muunnos.

14 Testaus

Vakaa neuvonta liittymän testaamiseksi on rakentaa näyteviestejä, jotka heijastelevat omaa ympäristöäsi — laboratoriokoodisi, tapausvalintasi, lähettäjäsi tavat — ja poistaa potilastiedot käsin. Se on hidasta, ja tekeminen epätäydellisesti on normaali tulos.

Perfuse tarjoaa kolme asiaa sen sijaan: generoitu liikenne, joka vastaa syötteen muotoa sen sisällön sijaan, kanava, joka on ehdotettu näyteviestistä, jonka joku on lähettänyt sinulle, ja vertailu korvaavan moottorin kanssa.

14.1 Luotu testiliikenne

Jos kanava on käsitellyt viestejä, Perfuse voi tuottaa enemmän viestejä, jotka muistuttavat niitä.

Mikä on uskollinen:

• Lausahdukset laukaistaan todellisten havaintojen suhteessa, ja jokaisella on ainakin yksi harvinainen tapahtuma, jotta se näkyisi.
• Kentät täytetään todellisilla täyttöasteilla — joten tapaus, jossa kenttä puuttuu, testataan, mikä on se asia, joka rikkoo asioita.
• Toistot, joissa toistot esiintyvät, yhdistetty rakenne, jossa se esiintyy.
• Koodit piirretään todellisista kooditauluista.

Mikä ei ole uskollinen, ja tämä on ilmoitettu sen sijaan, että se olisi implisiittinen: kliininen johdonmukaisuus. Luodun potilaan tiedot ovat irralliset, nimiksi muodostettu merkkijono ja diagnosoitu, jolla ei ole suhdetta havaintoon. Nämä viestit harjoittelevat rajapintaa. Ne eivät ole kliininen testijoukko eivätkä voida käyttää kliinisen logiikan vahvistamiseen.

14.1.1 Miksi siinä ei ole oikeaa dataa

Väite on rakenteellinen eikä vaatinnaisuuden väite. Generaattorin ainoa syöte on kanavan liikenneprofiili, ja profiili sisältää täyttöasteet, muodot, pituudet, toistojen määrät ja segmenttien taajuudet. Siinä ei ole arvoja.

Ainoa poikkeus on koodikentät, ja koodi ei tunnista ketään.

Tämä on vahvempi takuu kuin oikeiden viestien de-identifioiminen, joka on prosessi, jota voidaan tehdä epätäydellisesti ja jota yleensä tehdään. Tässä ei ole polkua, jota kautta nimi voisi päätyä tulosteeseen, koska nimeä ei ollut syötteenä.

Jokainen luotu viesti parsitaan ennen kuin se palautetaan — epäparsittava korpus lähettäisi jonkun etsimään virhettä rajapinnasta, joka on itse asiassa generaattorin virhe — ja jokaiselle on merkintä T MSH-11:ssa, tarkoituksella luodulla lähettäjällä ja laitoksella.

14.2 Kanavan rakentaminen näytteestä

Liitä viesti, jonka laboratorio, sairaala tai myyjä on lähettänyt sinulle, ja Perfuse ehdottaa kanavaa sille. Mitään ei tarvitse olla käynnissä ensin.

Se käsittelee sitä, mitä ihmiset todella liittävät: useita viestejä yhdessä lohkossa, mitä tahansa rivin loppumista, MLLP-kehyksen, joka on säilynyt kopioinnissa, ja peittävän muistiinpanon yläpuolella viestin. Viestin hylkääminen, koska se saapui Windows-rivin loppumisilla, olisi este eikä tarkastus.

14.2.1 Kolme luetteloa

Ehdotus tulee mukana siitä, mitä näyte näyttää, mitä on arvattu, ja mitä näyte ei voi kertoa — kolme erillistä luetteloa, jotka on painotettu tasapuolisesti rajapinnassa.

Ne ovat erillisiä, koska lukija, joka ei voi sanoa, mikä on mikä, joutuu vahvistamaan kaiken tai luottamaan kaikkeen, ja molemmat ovat huonompia kuin tietäminen, mihin kannattaa katsoa.

Yhdestä viestistä rajoitukset on nimetty nimenomaan eikä yleisesti: mitkä kentät ovat valinnaisia, mitkä segmentit toistuvat, mitkä koodit ovat olemassa siitä, mitä tässä on, lähetetäänkö eri laukaiseva tapahtuma. Yleinen varoitus on sana, jota ihmiset vilkaisevat.

Luottamus on sana — alhainen, kohtuullinen, järkevä — ei koskaan prosentti. Prosentti implikoi laskelmaa, ja tämä on arvio siitä, kuinka monta näytettä on.

Z-segmentit mainitaan nimeltä, koska paikallinen segmentti on se asia, josta määritys ei mainitse, ja yleisin syy sille, että kanava, joka on rakennettu standarditemplatista, ei toimi.

14.2.2 Erottimen varoitus

Jos näytteen kenttäerotin ei ole tavallinen |, se näkyy ensin, ja luottamus laskee alhaiseksi.

Syy on aito hiljainen virhe. HL7 ottaa kenttänsä erottimen itse viestistä, joten näyte, jonka putkit on korvattu typografisilla näköisillä — mitä sanomistoimisto tekee — parsitaan täydellisesti kenttiin, jotka ovat kaikki väärin. Mitään virhettä ei esiinny missään.

Tällaisen näytteen hylkääminen olisi väärin, koska lähettäjä voi laillisesti käyttää toista erottinta. Sen vuoksi se on merkitty, ja merkintä on nimetty, ja pyydetään ehdotus siitä, että pyydettäisiin plain text -liite.

14.3 Vertaaminen vanhaan moottoriin

Ennen kuin siirrät live-syötteen, kysymys on, tuottaako Perfuse saman tulosteen kuin se, joka on ollut käynnissä vuosia. Mikään suunnittelun laatu ei vastaa tähän. Katso migration.

14.4 Varmistaminen oikean asian kanssa, konteinereissa

Kolme tarkastusta suoritetaan oikeiden toteutusten kanssa eikä Perfusen omien protokollan määrittelyn kanssa. Ne sijaitsevat konttien ulkopuolella make check -käskystä, koska ne tarvitsevat konttien suoritusympäristön, ja tarkastus, joka tarvitsee Dockerin, on tarkastus, jonka ihmiset lopettavat suorittamasta.

scripts/interop-up.sh käynnistää kaikki nämä ja tulostaa, mitä kunkin tarkastus löytää.

Jokainen tarkastus ohittaa kontin puuttumisen sijaan, joten make check menee läpi koneella, jolla ei ole Dockeria.

Miksi tämä on erillinen muusta joukosta. Jokainen muu näiden ominaisuuksien testi oli kirjoitettu täällä: asiakirja, jonka tämä koodipohja allekirjoitti, luettiin takaisin koodilla, joka allekirjoitti sen. Se on sopimus itsensä kanssa, ja se on vähemmän arvokasta kuin se näyttää.

SAML-kanoninen muotoilu on tapaus, joka osoittaa asian. Se sisälsi tuhannen rivin testejä, viisi niistä oli erityisesti kanonisen muotoilun suhteen, ja kaikki ne menivät läpi, vaikka mikään todellinen tunnistuspalvelu ei voinut allekirjoittaa ketään — kanoninen muoto, jota allekirjoitus kattaa, laskettiin ilman nimirakenteen etuliitteitä, ja ainoa tapa löytää se oli antaa sille asiakirja, jonka Perfuse ei ollut kirjoittanut.

Kaksi kahdeksasta tarkastuksesta löysi virheitä suoraan, ja kolmas aiheutti todellisen parannuksen. Kolme ei löytänyt mitään vikaa. Tuo suhde on argumentti kaikkien niiden säilyttämiseksi: tarkastus, joka menee läpi, on kertonut sinulle jotain, mitä et muuten olisi tiennyt, ja ei ollut mitään tapaa tietää etukäteen, mitkä ne olisivat.

Yksi kuvaamisen arvoinen malli, koska se ilmestyi molemmissa virheissä: hyväksyntä ei ole vahvistus. HAPI hyväksyi viallisen tunnistejärjestelmän ja tallensi sen; virhe ilmestyi vasta, kun resurssi luettiin takaisin. Vastaanottaja, joka sallii jotain, ei ole todiste siitä, että se on oikein, vaan vain se, että tämä vastaanottaja oli lempeä.

Kaksi tallennettua väittämää on tallennettu internal/saml/testdata/keycloak-assertion.xml ja entra-response.xml -tiedostoihin, ja niiden yli on testejä — joten tämä tietty takaisinmenetelmä on kiinni ilman konttia.

Molemmat ovat tarpeen eikä toista voi korvata toisella. Keycloak etuliitteet väittämänsä ja allekirjoituksensa, Entra ei tee sitä, ja ne ovat kaksi vastakkaista tapausta kanonisen muotoilun suhteen — joka on tarkalleen se, missä virhe oli. Testi vahvistaa kummankin asiakirjan edelleen oman tapauksensa, koska korvaava tallennus, joka sattumalta on etuliitetty, voisi hiljaisesti puolittaa kattavuuden ilman, että se epäonnistuu.

14.5 Oireiden määrittäminen testille, joka epäonnistuu kerran eikä enää

Testi, joka epäonnistuu täydessä suorituksessa ja menee läpi yksin kuusitoista kertaa, ei ole epävakaa testi. Se on testi, joka jakaa jotain suorituksen kanssa, ja tapa löytää se on mitata jaettua asiaa eikä testiä.

Kaksi välinettä on olemassa, ja molemmat on tarkoitettu suoritettavaksi täyden suorituksen rinnalla:

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

Kumpikaan niistä havaitsee suorituksen porteista asetuksen oman tilatiedoston ja ottaa näytteitä joka 500 millisekuntia, kunnes palvelin lopettaa. Ne kirjaavat jokaisen näytteen eikä vain epäonnistumisia, mikä tekee niistä hyödyllisiä: piikki näkyy suorituksessa, jossa mitään ei epäonnistunut, joten virhe, joka ilmenee kerran kolmessa suorituksessa, tulee mitattavaksi jokaisella suorituksella.

Aseta PERFUSE_E2E_KEEP=1 säilyttääksesi väliaikaisen hakemiston, joka sisältää tietokannan sellaisenaan ja palvelimen lokin koko suorituksen ajan. Palvelinloki on yleensä vastaus. Yhdessä tutkitussa tapauksessa se tallensi kanavan pysähtymisen ja sen kuuntelijan uudelleensitoutumisen 421 millisekunnin kuluttua, ja anturin yhden hylätyn yhteyden sattui kyseiseen aikanaan.

Lue jäljitys error-context.md -tiedoston sijaan, joka on ollut tyhjä useammin kuin kerran, kun jäljitys sisälsi oikean viestin.

Kopioi artefaktit ulos ennen kuin ajat mitään uudelleen. Menestyksekäs suoritus tyhjentää test-results -hakemiston, joten epäonnistuneen suorituksen jäljitys katoaa hetkeä ennen kuin yrität toistaa sitä. Kadonneen jäljityksen avulla voitaisiin vastata kysymyksiin, joita se olisi voinut vastata.

Pysäytä interop-containers ensin. Pysäytä ne ennen täydellistä selainajoa ja käynnistä ne ./scripts/interop-up.sh -komennolla myöhemmin, jos niitä tarvitset edelleen.

Kahdeksan konttia vie noin 9,8 GB muistia, ja koneella, jolla ei ole paljon enempää, on liian vähän jäljellä Chromiumin prosessien, solmun ja Go-työkalurivien yhteiskäytölle. Se tuottaa ei-muistivirheen, vaan renderöijä lopettaa aikataulutuksen: yksi tallennettu jäljitys näyttää 60,2 sekunnin aukon ilman kehysraameja, jonka aikana Playwright odotti, että painike tulisi "näkyväksi, käytettäväksi ja vakaaksi" ja ei voinut saada kahta peräkkäistä animaatiokehystä vertailemalla. Palvelin oli koko ajan terve, ja hitain pyyntö koko suorituksessa kesti 154 millisekuntia.

Se epäonnistuminen näyttää siltä, kuin kyseessä olisi vikaa kokeessa, joka sattui suorittamaan. On arvoa tietää sen muoto: jokainen pyyntö nopea, sivu visuaalisesti jäätyneenä, toisto silmukka ei koskaan saavuta toista iteraatiota, ja koko asia menee läpi eristetyssä tilassa.

Vain yksi suoritus kerran. Pakkaus jakaa yhden palvelimen, yhden kirjautuneen istunnon web/e2e/.auth/admin.json -tiedostossa ja yhden tilatiedoston, joka nimeää palvelimen prosessin. Mikään näistä ei ole suoritusspesifi, joten toinen suoritus, joka alkaa, kun ensimmäinen on menossa, ylittää tilatiedoston, ja kumpi tahansa puhdistus, joka päättyy ensin, tappaa toisen suorituksen palvelimen ja poistaa sen istunnon.

Miltä se näyttää, ei ole mitään sellaista kuin syy. Se tuotti 279 epäonnistumisen sarjan, jonka ensimmäinen viesti oli ENOENT: no such file or directory, open './e2e/.auth/admin.json', sarja joka pysähtyi kesken ilmoittaen 217 onnistunutta ja kaksi epäonnistunutta testiä bind: address already in use -virheellä — mikä ei viittaa siihen, että kaksi suoritusta taistelisivat. Testisarja ottaa nyt lukon ja kieltäytyy käynnistymästä, mainiten prosessin, joka pitää lukkoa. Keskeytetyssä suorituksessa jäänyt lukko otetaan haltuun sen sijaan, että se estäisi toiminnan ikuisesti, koska turvallisuustoimi, joka jumittaa testisarjan, on sellainen, jonka joku poistaa turvallisuuden mukana.

Läheinen ansa, joka on nyt korjattu: kaksi määritystä nimesi kuunteluporttinsa suoraan, joten palvelin, joka oli jäänyt keskeytetyssä suorituksessa, sai ne epäonnistumaan asiassa, johon ne eivät olleet osallisia. Portit pyydetään nyt käyttöjärjestelmältä.

Älä vastaa tähän uudelleenyrityksillä. Testi, joka menee läpi toisella yrittämällä, löysi oikean kilpailun ja piilotti sen, ja playwright.config.ts asettaa retries: 0 tästä syystä.

Yksi varoitus: otos joka 100 millisekuntia synnytti kaksikymmentä prosessia sekunnissa, venytti suoritusaikaa puoleen, ja epäonnistui kahdessa testissä aikakatkaisuilla, joilla ei ollut mitään vikaa. Mittalaite, joka muuttaa sitä, mitä se mitata, tuottaa havaintoja itsestään.

14.6 Mitä tarvitaan edelleen oikeaan infrastruktuuriin

Useat osat Perfusesta on toteutettu, mutta ne eivät ole koskaan olleet testattuina oikeaa asiaa vastaan. Ne on lueteltu tässä sen sijaan, että ne jätettäisiin löytämättä:

• SMB oikeaa Windows-jakoa vastaan — protokollakoodi on valmis ja testattu polun turvallisuuden ja argumenttien käsittelyn osalta, mutta mikään testi ei avaa sokettia domain-liitetylle palvelimelle.
• Oikea sarjaportti.
• Mirth-merkintä oikeaa Mirthin tuottamaa XML:ää vastaan. Testattu Mirth 4.5.2:aa kontissa, ja havainto oli tästä repositoriosta: ainoa siirtymälaite, joka on kirjoitettu käsin, Mirth ei lata sitä — se tallentaa kanavan virheelliseksi ja hylkää jokaisen liittimen. Se, mitä sovittiin, on, että version -attribuutit, jotka oikea Mirth kirjoittaa jokaiselle elementille, parsitaan samalle kanavalle, joten ne eivät ole vaaraksi; se, mitä ei sovittu, on kaikki muu, mitä oikea vienti sisältää.
• SAML vastaan isännöityä kaupallista identiteettipalvelinta. Keycloak on vahvistettu; yksi tarjoaja osoittaa, että toteutus vastaa yhtä myyjää.
• NCPDP-vaatimus oikean apteekin vaihtuvan kautta.
• SCRIPT-viesti Surescriptsin kautta, jossa sertifiointi on kaupallinen prosessi eikä tekninen prosessi.

Ominaisuudet tässä luvussa ja seuraavassa luvussa ovat olemassa, jotta voit kerätä oman näytön sen sijaan, että ottaisit jonkun sanan.

14.7 Mitattu julkisia yhdenmukaisuuskokoelmia vastaan

Testisarja, jonka kiinnikkeet on kirjoitettu täällä, osoittaa sopimuksen itsensä kanssa. Nämä ovat muiden ihmisten dataa.

14.7.1 FHIR R4, määrityksen omat esimerkit

Kaikki 2 912 esimerkkitiedostoa, jotka on julkaistu FHIR R4-määrityksen kanssa — jokainen esimerkki, jonka standardin kirjoittajat ovat kirjoittaneet.

Yksikään resurssi ei validoitunut väärin. Jokainen epäonnistuminen on eksplisiittinen kieltäytyminen, joka nimeää sen tyyppiä, jota se ei voi lukea — 672 ValueSet, 80 ConceptMap ja yksi Parameters. Validointityökalu, joka hiljaa hyväksyy sen, mitä se ei ymmärrä, on huonompi kuin sellainen, joka sanoo sen.

Korpus löysi virheen, joka on syy sen suorittamiseen. Bundle-validoiminen tulosti "Bundle-validoiminen tiedostosta ei ole vielä tuettu" ja jatkoi. Se oli väärä kummassakin suunnassa: bundleja, joiden kirjaukset sattuivat olemaan tyyppejä, joita parseri pystyi pitämään, validoidaan jo, ja bundle, joka oli todella virheellinen, tuotti saman rivin, laskee mitään ja poistuu nollaan — myös -strict-valitsimella, joka on olemassa, jotta se voi portaan rakentaa. 42 määrityksen omista bundleista ohitettiin.

Pakettiin kuuluvat tiedot validoidaan yksitellen, ja niistä muodostuu kolme eri tulosta: virheellinen tieto epäonnistuu ja nimeää kentän, tieto, jota tämä versio ei pysty lukemaan, luetaan yli ja raportoidaan, ja paketti, joka ei sisällä resurssien runkoja, ei ole kumpaakaan. Sama aineisto kasvoi 2 100 tarkistetusta resurssista 13 723:een.

14.7.2 HL7 v2, HAPI-testikorpus

HAPI: n viestin esimerkit, Java HL7 v2 -viittausmenetelmä — tarkoituksella epäkäytännöllinen materiaali, joka sisältää uuencode-paketit, paennut erotinmerkit ja toistuvat ryhmät.

59 viestiä, 59 parsittu, mitään ei hylätty. Seitsemän viestityyppiä joukossa, jota yksittäinen järjestelmä kuvaisi yhtenä asiana, mikä on se syy, miksi perfuse profile on olemassa.

14.7.3 Mitä ei ole ajettu

DICOM julkisessa mukautumisjoukossa ja X12 julkaisemassa aineistossa. Kumpaakaan ei ole tehty, eikä kumpaakaan pitäisi päätellä kahdesta edellisestä.

15 Siirtymä Mirthistä

Kaksi asiaa tarvitaan toimivan moottorin korvaamiseen: kanavat on siirrettävä, ja joku on näytettävä, että korvaava tuottaa saman tuloksen. Perfuse tekee ensimmäisen tuomalla Mirthin omat viennit, ja toisen vertaamalla kahta moottoria omassa liikenteessäsi.

Kaikki tässä luvussa sanottu koskee yhtä lailla Open Integration Engineä ja BridgeLinkiä. Mirth Connect lakkasi olemasta avoimen lähdekoodin ohjelma versiossa 4.6 maaliskuussa 2025; OIE (isäntänä Eclipse Foundation) ja BridgeLink (Innovar Healthcare) ovat forkkeja, jotka jatkavat avoimen lähdekoodin linjaa, ja molemmat kirjoittavat samat vientiformaatit. Tuonti on testattu kaikkia kolmea alla.

15.1 Kanavien tuonti

Perfuse lukee jokaisen näiden moottorien kirjoittaman viennin:

Osoita perfuse translate missä tahansa niistä, tai pudota yksi Hallinta → Siirrä:

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

Kooditemplattekirjasto muuttuu lib/<library>.js:ksi kanavien vieressä, ja jokaiselle kanavalle, jolle kirjasto on otettu käyttöön, tulee scripts.include: [lib/<library>.js] — joten transformer, joka kutsuu sivufunktiota, kuten formatMRN(), löytää sen edelleen. Kanava, jolle kirjastoa ei ole otettu käyttöön, ei sisällä sitä, koska sen skriptit eivät voi nähdä sitä Mirthissäkään. Raahaa-ja-pudota -palat jätetään pois: Mirth liittää ne aina vain käsin askelkohtaisesti, joten ne eivät ole itsenään suoritettavaa koodia. Selaimessa kanavan tuominen tallentaa ensin sen sisältämät kirjastot.

Kanavan kirjoittaja nimeää kanavan, johon se toimittaa, tunnisteella. Ryhmässä tai varalla kohde on samassa asiakirjassa, joten se tulee channel-kohdeksi, joka nimeää kyseisen kanavan; yhden kanavan viennistä se ilmoitetaan sinun täyttämään. Palvelimen laajuiset globaalit skriptit eivät ole Perfusen vastaavia, ja ne ilmoitetaan sen sijaan, että ne hylätään.

Raportti kertoo kanava kohden, onko se käännetty puhtaasti, käännetty varoituksin vai ei se voitu lukea.

Otsikko on murto-osa, jonka nimittäjä on — "37 40:stä valmis" — koska "37 valmis" ei kerro sinulle mitään siitä, mitä sinun on vielä tehtävä.

Kanava, jota ei voitu lukea , on eri ongelma kuin kanava, jota ei voitu käännetä . Ensimmäinen tarkoittaa, että itse XML ei parseerunut ja on yleensä katkaistu tai osittainen vienti; jälkimmäinen tarkoittaa, että kanavan sisältö sisältää jotain, jolla ei ole Perfusen vastaavaa. Tuonti erottaa ne.

15.2 Mitä käännetään ja mitä tarvitaan päätös

Lähteet, kohde, suodattimet ja tavalliset transformer-vaiheet käännetään suoraan. Liitännäiset, jotka käännetään: TCP/MLLP (ja raaka TCP sen kehyksineen), HTTP, Tiedosto, Tietokanta, JavaScript, DICOM, Web-palvelu (SOAP), SMTP ja Kanava Kirjoittaja/Lukija. JMS ja Asiakirja Kirjoittaja eivät käänny, ja ne ilmoitetaan esteinä.

Mapper-vaihe, joka asettaa muuttujan, laittaa sen karttaan, jonka sen piiri nimeää — channelMap oletusarvoisesti — täsmälleen kuten Mirth tekee, joten myöhemmät vaiheet, jotka lukevat sen $('name'):lla, löytävät sen.

JavaScript-transformerit eivät yleensä. Mirth-kanavat sisältävät usein merkittäviä koodinpätkiä transformerissa, eikä ole olemassa automaattista muunnosta mielivaltaisesta JavaScriptistä deklaratiivisiksi vaiheiksi. Tuonti ilmoittaa ne sen sijaan, että se yrittäisi kääntää sitä, mikä voisi olla häikäisevästi väärin: väärin käännetty transformer on huonompi kuin sellainen, joka on merkitty ihmisen tarkastettavaksi, koska se suoritetaan.

Siinä tapauksessa, että skripti on oikeasti jäävä skriptiksi, Perfuse voi suorittaa sen — katso scripts-avain kanavaviitteessä — hävittäen vaihekohtaisen jäljityksen, josta on kerrottu virheenjäljityksessä

15.3 Mitä tuonti on testattu vastaan

Viisi moottoria, joista kunkin kirjoittaa omat asiakirjansa: Mirth 4.5.2, OIE 4.5.2, 4.6.0 ja 4.7.0, sekä BridgeLink 26.9.0. scripts/mirth-engine-corpus.sh kokoaa pienen ohjelman kunkin moottorin omiin jar-tiedostoihin ja kirjoittaa sen oman serialisoijan avulla kolme tavallista kanavaa — MLLP-syötteen, jossa on kartturi, skripti, joka kutsuu kooditemplatesekirjastoa ja suodatinta; HTTP-syötteen tietokantaan; tiedoston tarkkailu MLLP:n yli — sekä kirjaston ja kanavaryhmän. Se lataa ne suorittavaan moottoriin ja lataa moottorin oman palvelimen varmuuskopion. Tulokset tallennetaan internal/mirth/testdata/engines/ - alle, ja testisarja pitää tuojaa jokaisessa niistä jokaisella rakennuksella: kunkin varmuuskopion luetaan, käännetään, ladataan ja ADT-kanava suoritetaan kahdella viestillä tarkistamaan, että kirjasto täyttää asiakirjan numeron ja suodatin pudottaa tuloksen.

Perfusen omat viennit menevät toiseen suuntaan — Perfuse-kanavat tuodaan jokaiseen suorittavaan moottoriin ja tarkistetaan, ettei moottori tallentanut niitä virheellisinä. Kaikki viisi hyväksyvät jokaisen Perfusen viennin kuljetuksen. Open Integration Engine 4.7.0 lisäsi kaksi HTTP-asetusta, joilla ei ole tässä vastinetta: HTTP-lähetin, joka on sitoutunut valittuun paikalliseen osoitteeseen, ilmoitetaan varoituksena, ja HTTP-kuuntelijan pyynnön otsikko rajoitus vain, kun se ylittää 1 MB, jonka Perfuse hyväksyy.

Ensimmäinen suoritus tätä korpusoimaa löysi neljä virhettä, jotka kaikki on korjattu: kääntäjä kieltäytyi HTTP- ja tiedostolähteistä "vain MLLP on tuettu" pitkän aikaa sen jälkeen, kun Perfuse oli jo molemmat; se luki HTTP-lähettäjän osoitteen kentästä, jota kukaan moottoreista ei kirjoita; se käänsi Mirthin soketin puskurin koon 64 KB viestin rajaksi; ja kartan muuttuja tuli JavaScriptin globaaliksi, jota $('mrn') ei koskaan nähnyt, joten kirjasto täytti tyhjän merkkijonon.

The single-channel fixture that started this was also exported by Mirth 4.5.2, authored by Mirth itself rather than written here. That distinction earned its place: the only fixture in this repository used to be hand-written, and a real Mirth will not load it — the API accepts the POST and then stores the channel as This channel is invalid. Verify all required extensions are loaded correctly, with every destination connector discarded.

Käsin kirjoittaminen ei koskaan toiminut, ja syy on arvokas tietäminen, jos tuotat omia vientejäsi. Mirthin serialisoija ignooraa tuntemattomia elementtejä, joten väärä elementin nimi ei tuota virhettä lainkaan — liitännäinen on vain poissa lopputuloksesta. Ei ole mitään luettavaa eikä mitään korjattavaa.

scripts/mirth-author-channel.sh rakentaa yhden Mirthin omien malliluokkien ja serialisoijan avulla, ja lähettää sen suorittavaan palvelimeen ja epäonnistuu, jos palvelin hylkää sen. Perfusen tuonti lukee tuloksen: nimi, lähdetransportti ja kohdekaistat kaikki säilyvät.

15.4 Osoittaminen, että se vastaa

Tämä on osa, joka päättää, tapahtuuko migraatio, ja se tarvitsee näyttöä sen sijaan, että olisi vain luottamus.

Perfuse vertaa omaa tulostettaan vanhan moottorin tulokseen, viesti viestin jälkeen, liikenteessäsi. Se tarvitsee parit: viesti, joka saapui, ja viesti, jonka vanha moottori tuotti siitä. Molemmat ovat Mirthin omassa viestivarastossa ja voidaan viedä sen viestiselaimesta.

15.4.1 Neljä lukua, ei läpäisyprosentti

Ne ovat neljä lukua, koska ne tarkoittavat neljää eri asiaa, ja niiden yhdistäminen piilottaa ne, jotka tarvitsevat päätöksen.

Identtinen tarkoittaa bitti bittien jälkeen, ei vastaavaa. Heikompi testi antaisi erojen segmentin järjestyksessä tai peräkkäisten erottimien kautta, ja ne ovat juuri sitä, mitä tarkka järjestelmä hylkää.

Kosmeettiset erot lasketaan erikseen eikä niitä yhdistetä hyvään sarakkeeseen. Ne eivät kanna tietoa, joten niiden käsittely virheinä haudottaisi oikeat löydökset tuhansiin mitättömiin — mutta ne eivät ole identtisiäkään, ja vastaanottaja, joka tekee oman tiukkojen parsimisen, voi olla eri mieltä.

"Ei suoritettu" on erillinen "eroaa"-kohdasta, koska se on yleensä konfiguraatio-aukko, jonka tuonti ei voinut täyttää, eikä kartoituspäätös. Jos kaikki on siinä sarakkeessa, lausunto sanoo sen ja kehottaa tarkastelemaan konfiguraatiota ennen kuin lukee mitään muuta.

15.4.2 Erot ryhmitellään kentän mukaan

Suoritus 50 000 viestin yli, joka ilmoittaa 4 000 eroa, on kertonut sinulle mitään, jota voit tehdä. Sama suoritus, joka ilmoittaa, että PID-8 eroaa jokaisessa viestissä, koska vanha moottori kirjoitti Male siinä, missä Perfuse kirjoittaa M, on kertonut sinulle yhden asian, jonka voit päättää.

Jokainen löytö on kenttä, jolla on laskuri, ja se kertoo, onko ero järjestelmällinen — sama arvopari joka kerta — vai onko kentän sisältö erilainen.

Tämä ero on hyödyllisin asia raportissa. Yksi erillinen arvopari 4 000 viestin yli on yksittäinen kartoituspäätös. 4 000 erillistä paria on sisällön ero, joka on erilainen ja paljon huonompi ongelma, ja ne eivät saa olla samanlaisia.

Löydöt on järjestetty siinä järjestyksessä, kuinka monta viestiä ne vaikuttavat, joten suurin yksittäinen syy on ensin.

15.4.3 Lausunto ei pyöristä

Se antaa tarkat luvut: 49 993 50 000:sta, ei "yli 99 %". Ne seitsemän ovat koko suorituksen pääasia.

Se on kirjoitettu siten, että se voidaan siteerata muutospyyntöasiakirjassa, koska siinä luvut lopulta päättyvät.

15.5 Ehdotettu järjestys

1. Tuominen kanavia ja ratkaiseminen kaikki, mitä ilmoitetaan lukukelvottomaksi.
2. Kunkin kanavan kohdalla tarkastellaan varoituksia. Useimmat ovat skriptejä.
3. Viedään muutamia tuhansia viestipareja Mirthista ruuhkaisimmasta kanavasta ja suoritetaan vertailu.
4. Työskennellään löydösten parissa. Järjestelmälliset ovat yksi päätös kussakin.
5. Suoritetaan uudelleen, kunnes ainoat erot ovat ne, jotka olet päättänyt olevan oikein.
6. Suoritetaan Perfuse varjona Mirthin rinnalla liven liikenteessä, toimittamatta minnekään, ja vertaillaan uudelleen jakson aikana, joka kattaa viikonlopun ja kuun lopun.
7. Leikataan yksi kanava, ei kaikkia.

15.6 Mitä toimii vain yhden valmistajan ohjelmistolla

Siirtymänäkymä vastaa toiseen kysymykseen, ja se on arvokasta kysyä ennen kuin sinulla on mielipidettä Perfusesta: kuinka paljon integraatiologiikkasi voi toimia vain ohjelmistollasi.

Jokaiselle kanavalle annetaan Siirrettävyys -tuomio, samasta skannauksesta, joka tuottaa siirtymismerkinnät. Se suoritetaan kanavan viennissä, joten siihen ei tarvita mitään asennusta eikä se muuta mitään.

15.6.1 Ero on koko asian pointti

Useimmat Java-kielet Mirth-skripteissä eivät ole lukkoja. SimpleDateFormat, HashMap, Apache Commons — kaikki toimivat JavaScript-moottorin ympärillä vuodelta 2009, kaikki ovat tavallisia, kaikki niistä on suoria vastineita. Kanava, jossa on kolmesataa viittauksia, on täysin siirrettävä, ja työkalu, joka ilmoittaa "300 Java-viittauksia, olet lukittu" olisi valehtelemassa sinulle.

Lukko on nimenomaan soittopyynnöt, jotka tarvitsevat valmistajan omaa palvelinta: com.mirth.connect.* ja valmistajan jar-tiedostot. Viisi niistä ja olet jumiutunut. Viisisataa muun tyyppistä ja olet vapaa.

Joten tuomio alkaa luvulla, joka on tärkeintä, ja sanoo samassa lauseessa, että suurempi luku ei ole se. Kun on valmistajan soittopyyntöjä, ne luetellaan nimeltä — laskenta on väite, ja luettelo on jotain, mitä oma insinööri voi tarkistaa.

Kolmas kategoria pidetään erillään: ominaisuus, joka on olemassa, mutta ei skriptistä. Kanavan käynnistäminen JavaScriptistä ei ole vastaavaa täällä, ja on API-päätepiste, joka tekee samaa asiaa. Kutsuminen lukitsemiseksi olisi liioittelua.

15.6.2 Java-soittopyynnöt, jotka toimivat muuttumattomina

Näistä Java-luokista yleisimmät suoritetaan sellaisenaan. Perfusella ei ole Java-ajonaikaa, joten nämä ovat JavaScript-luokat, joilla on samat nimet ja menetelmät, riittävästi kanavaskriptien käyttöä varten; importPackage(java.util) ja importClass(...) tuovat ne laajuuteen lyhyillä nimillä, kuten Rhinossa (JavaScriptin omat Date, Map, Set, Math, String ja Boolean eivät koskaan korvata: Java-versiot ovat edelleen käytettävissä täydellisillä nimillä). Siirtoraportti laskee jokaisen näistä kutsuista jo olemassa olevaksi.

Ne käyttäytyvät Java: n tavoin, kun skriptit riippuvat siitä: Integer.parseInt("x") heittää NumberFormatException, String.replaceAll ja split ottavat säännöllisiä lausekkeita, kun taas replace on kirjaimellinen, kartat avainmerkkijonoja arvon mukaan, TreeMap ja TreeSet iteroidaan järjestyksessä, ja SimpleDateFormat.parse palauttaa päivämäärän, jolle getTime() toimii. Menetelmä, jonka skripti kutsuu, ja jota vastaava puuttuu, epäonnistuu kyseisellä rivillä, nimeää sen; mikä tahansa muu Java-luokka epäonnistuu nimen perusteella, kuten aiemmin. BigDecimal on täällä double, joten se ei säilytä Java: n tarkkaa desimaalilaskentaa: tarkista skriptit, jotka käyttävät sitä rahaa varten.

15.6.3 Ulkopuoliset skriptit ilmoitetaan tuntemattomiksi

Askeltapa, joka suorittaa ulkoisen skriptitiedoston, viittaa polkuun vanhassa palvelimessa, ja tiedostoa ei ole viennissä. Mitään ei voida sanoa siitä, mitä se sisältää, joten se lasketaan tuntemattomaksi eikä oleteta kumpaakaan suuntaa. Nouda nämä tiedostot ennen kuin teet mitään johtopäätöksiä — molempiin suuntiin.

15.6.4 Perfusen oma lukko, ilmoitettu samassa henkäyksessä

Tämä osio olisi epärehellinen ilman sitä.

Perfuse on Apache 2.0, joka on peruuttamaton jo julkaistuun koodiin. Voit forkata mitä on olemassa tänään, ja kukaan ei voi peruuttaa sitä. Kanavat ovat YAML-tiedostoja, ja skriptit ovat tavallisia JavaScript-tiedostoja, joten siinä ei ole mitään omisteisia pintoja, joita kutsutaan — Mirthin Java-riippuvuuden maku on rakenteellisesti saatavissa täällä, mikä on aito ominaisuus.

Mitä se ei luvaa: että tuleva versio pysyy avoimena, että isännöity palvelu on olemassa edulliseen hintaan, tai että Perfusen siirtäminen maksaa mitään. Minkä tahansa integraatiokerroksen siirtäminen tarkoittaa jokaisen kanavan uudelleentestaamista todellista liikennettä vastaan. Mitä valitset, onko rakennettavien artefaktien luettavissa ja siirrettävissä, ja riippuuko poistuminen lisenssistä, jonka joku muu hallitsee.

15.6.5 Asetus kuudennen vaiheen

Varjo -osio aloittaa vertailun. Valitse kanava, joka on käynnissä, valitse kohde, jota vastaan vertaillaan luettelosta, ja aloita.

Kolme asiaa siitä on arvoa tietää ennen kuin luotat numeroihin.

Vastaus valitaan luettelosta, eikä kirjoiteta. Varjo nimittää kanavatiedoston, ja nimi, joka ei ratkea, tekee *aktiivisen* kanavan virheelliseksi — Perfuse hylkää koko kanavan, kun mitään siihen viittaavaa on rikkoontunut. Virheellinen kirjoitus ei siis aiheuta varoitusta, vaan saa aikaan, että suoritettava kanava katoaa.

Osuus on prosentteja. Laske sitä ainoastaan kiireisellä syötteellä, ja tiedä, mitä se maksaa: otos vähentää työtä ja luottamusta samassa suhteessa, ja viesti, joka olisi osoittanut eroa, on epätavallinen.

Ohitettavat kentät ovat yleensä tarpeen. Kanava, joka merkitsee aikaleiman tai järjestysnumeron, eroaa jokaisessa viestissä, mikä ilmoittaa 100 %:n eroavuuden ja kertoo sinulle mitään. MSH-7 ja MSH-10 ovat yleinen pari.

Vertailu kirjoitetaan kanavatiedostoon, kun sen käynnistät, ja alkaa havainnoida, kun kanava seuraavan kerran ladataan — näyttö kertoo sen sijaan, että se on jo käynnissä. Vertailun lopettaminen jättää kandidaattikanavan paikoilleen, koska kandidaatti on se, mitä on tarkoitus ottaa käyttöön.

Vaihe 6 on se, jota ei voida lyhentää. Merkittävät erot ovat yleensä liikenteessä, joka näkyy vain toisinaan — harvinainen laukaiseva tapahtuma, kuukauden lopun erä, lähettäjä, joka käyttäytyy eri tavoin keskiyön jälkeen — ja otos, joka otetaan iltapäivällä, ei sisällä niitä.

15.7 Meneminen toiseen suuntaan

Kanava voidaan viedä Mirth-kanavatiedostona selaimen kautta: Kanavat, sitten Mirthiin haluamallasi kanavalla.

Tämä on olemassa, koska vastalause korvaavan toimivan moottorin harvinainen on harvoin se, onko korvaava hyvä. Se on, mitä tapahtuu, jos päätös osoittautuu vääräksi, ja vie viennin takaisin menneiltä on halvin vastaus siihen.

Lue, mitä vuoropuhelu kertoo, ennen kuin otat tiedoston. Mirthin muotoilussa ei ole tilaa Perfuse-suodattimelle, muunnosketjulle, sopimukselle tai varjoverroinnille, joten viety kanava tekee vähemmän kuin se, mistä se tuli. Siirtämisen ja osoitteiden muunnokset; logiikka ei. Jokainen tappio on lueteltu nimellä ennen kuin tiedosto tarjotaan, ja sama luettelo menee kanavan kuvauskohtaan, jotta se, joka tuo sen, näkee sen myös.

Kanavaa, jota Mirth ei voi ilmaista, hylätään sen sijaan, että se approksimoidaan. S3-kohteella ei ole Mirth-vastinetta, ja kanava, joka tuodaan puhdistettuna toimittamalla jonnekin muualle kuin bucketiin, olisi huonompi kuin mikään tiedosto.

Liittymän määritykset eivät ole kirjoitettu Mirthin muodon lukemisesta. scripts/mirth-dump-connector-templates.sh sisältää Mirthin oman sarjoittimen, joka tuottaa oletukset kullekin liittymäluokalle, ja Perfuse korvaa arvot näissä asiakirjoissa — hylkäämällä kaikki asetukset, joita mallipohja ei jo sisällä. Tämä on tärkeää, koska Mirth vastaa kanavaa, jota se ei voi käsittää: se ei hylkää tuontia. Se tallentaa kanavan, jonka kuvaus on korvattu "Tämä kanava on virheellinen. Varmista, että kaikki vaaditut laajennukset on ladattu oikein" ja jonka kohteet on vaikenetesti hylätty. Viejä, joka on tarkistettu omasta tulostuksestaan eikä palvelimesta, läpäisee jokaisen testin ja tuottaa asiakirjoja, jotka heitetään pois, mikä on täsmälleen se, mitä tapahtui täällä ennen kuin viennit yritettiin suorittaa Mirthillä.

Mitä ylittää tänään: MLLP ja TCP molemmissa suunnissa, HTTP molemmissa suunnissa, tiedoston lukeminen ja kirjoittaminen, tietokannan lukeminen ja kirjoittaminen, DICOM molemmissa suunnissa, ja SMTP, SOAP ja JavaScript-kohteet. Kukin pari on vahvistettu tuomalla se todelliseen Mirth 4.5.2:een ja tarkistamalla, ettei palvelin ole vaikenetesti korvannut kanavaa.

16 CMS-0057 vakuutusyhtiöille

CMS Interoperability and Prior Authorization -loppusääntö (CMS-0057-F) edellyttää vaikuttuneilta vakuutusyhtiöiltä — Medicare Advantage -organisaatioilta, osavaltion Medicaid- ja CHIP-ohjelmilta ja niiden hallinnoimilta hoitosuunniteluilta, sekä QHP-vakuutusyhtiöiltä liittovaltion vaihtoehtoja — suorittaa neljä FHIR-Rajapintaa 1. tammikuuta 2027 alkaen, ja julkaista etukäteen hyväksyttyjä metriikoita julkisella verkkosivustollaan joka vuosi vuodesta 2026 alkaen.

Perfuse tarjoaa neljä rajapintaa FHIR-päätepisteessään ja muunnokset, jotka täyttävät ne: vakuutetut vaatimukset CARIN Blue Button -muodossa, etukäteen hyväksytyt metriikat Da Vinci PDex -muodossa, ja vuosittaiset metriikat CMS:n oman mallipohjan asettelussa. CMS-0057-näkymä, Exchange-alaisuudessa, kertoo, mitkä neljästä tämä instanssi voi vastata, ja mitä kullekin vielä puuttuu, ja tekee kaikki kolme muunnosta selaimessa.

Lääkkeet ovat koko ajan laajuisesti ulkopuolella, kuten ne ovat myös etukäteen hyväksyttyjen säännösten osana: ei farmaseuttisia vaatimuksia, ei lääkevalikoimaa, ja metriikka, joka mainitsee lääkkeen, hylätään sen sijaan, että se lasketaan.

16.1 Neljä rajapintaa

Potilastason API:lla ei tarvita omaa toimintoa: se on FHIR-päätepisteen tavallinen lukuoikeus ja hakuoikeus, jota SMART suojaa, ja siinä on CARIN- ja PDex-resursseja tallennuksessa. ExplanationOfBenefit-hakeminen tukee CARIN-nimien parametreja — patient, identifier, type, service-date, billable-period-start, provider, insurer, coverage — ja Coverage tukee subscriber-id, identifier ja payor.

16.1.1 Kaksi oppaan julkaisua: 2.1.0 ja 2.2.x

CMS-0057-F suosittelee CRD: tä, DTR: ä ja PAS 2.0.1 ja 2.1.0. 2.0.1-julkaisut perustuvat US Core 3.1.1: een, joka vanheni 1. tammikuuta 2026, joten 2.1.0 on todennäköisesti versio, jota EHR, joka on rakennettu säännön mukaan, puhuu; uusimmat ovat CRD 2.2.1, DTR 2.2.0 ja PAS 2.2.1. Perfuse vastaa molempiin. Se selvittää, mitä versiota soittaja puhuu, ensin tarkimmasta:

1. pyynnöstä: CRD: n CDS Hooks -laajennus davinci-crd.requestedVersion ("2.1"), tai versio Da Vinci -profiilissa, jonka DTR- tai PAS-syöte vaatii (profile-pas-request-bundle|2.1.0);
2. soittajan rekisteröinnistä: davinci_version: "2.1" SMART-asiakkaalla (-smart-clients) tai CDS-asiakkaalla (-cds-clients);
3. palvelimelta: serve -davinci-version 2.1; oletus on 2.2.

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

Jokainen vastaus määritetään ja säilytetään 2.2.x-muodossa ja kirjoitetaan uudelleen 2.1.0-soittajalle, kun se lähetetään, joten säännöt, tarkastusjono, X12 278 -linkki ja mittarit ovat samat molemmille. Uudelleenkirjoitus kattaa, mitä julkaisut merkitsevät eri tavoin: CRD 2.1.0: lla ei ole indeterminate (Perfuse sanoo ehdollinen, syystä) eikä kategoriaa kattavuksen yksityiskohdassa; DTR 2.1.0 nimeää paketin PackageBundle ja jättää QuestionnaireResponse-sovelluksen; PAS 2.1.0: n $inquire vastaa yhdellä Bundlella, ja siinä puuttuu tarkastelija- ja lähetyseksensiot. Täydellinen luettelo ja tarkistus kunkin 2.1.0-oppaan omien esimerkkien kanssa on conformance/davinci21: ssä. PAS-ilmoitus seuraa -davinci-version, koska tilaus ei kerro, mikä versio omistajansa lukee.

16.2 Kattavuusvaatimukset ja dokumentaatio: CRD ja DTR

Prior Authorization API on käytännössä kolme Da Vincin opasta yhdessä. CRD kertoo klinikoitsijalle, kun tilaus on vielä luonnos, onko se kattavuus, tarvitaanko ennakkovaltuutus ja mitä asiakirjoja halutaan. DTR antaa EHR:lle kyselylomakkeen, joka kerää kyseisen asiakirjan. PAS lähettää pyynnön ja palauttaa päätöksen. Perfuse palvelee kaikkia kolmea maksajana.

-crd-rules rules.yaml tarjoaa CRD:n CDS Hooks -yli /cds-services: kaikki kuusi CRD:n hookkia, order-sign, order-select, order-dispatch, appointment-book, encounter-start ja encounter-discharge, kullakin on esihaku potilaan aktiiviselle vakuutukselle. Kaksi tapaamishookkia esihakee myös tapaamisen, ja vastaa itse tapaamisesta, joka on vastattu sen tyypin ja palvelun tyypin mukaan, kuten appointment-book vastaa tapaamisesta. Säännöt ovat vakuuttajan käytäntö, jotka säilytetään tiedostossa, koska ne muuttuvat ilman ohjelmistojulkaisuja:

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

Jokaiselle tilaukselle tehdään systemActions-päivitys, joka sisältää CRD:n kattavuustietojen laajennuksen - jonka EHR tallentaa tilaukseen ja lähettää myöhemmin eteenpäin ennakkovaltuutuksessa - ja kortin, jonka klinikkotyöntekijä lukee. Tilaukselle, jonka koodi ei ole säännössä, annetaan vastaus conditional, eikä sitä koskaan oleteta olevan katettu; pyynnöille, joilla ei ole lainkaan kattavuutta, annetaan kortti, jossa tämä ilmoitetaan. examples/crd/-kansiossa on sääntötiedosto ja siihen liittyvä kyselylomake.

Sääntö voi myös sisältää loput siitä, mitä CRD sallii maksajalle:

• billing_codes: laskutettavat koodit.
• details: rajoitukset ja kustannukset, kuten allowed-period tai in-network-copay.
• contact: kenelle ottaa yhteyttä.
• expiry_days: kuinka kauan vastaus on voimassa.
• depends_on: muiden tilausten koodit, joihin vastaus liittyy, jotta EHR kysyy uudelleen, jos ne muuttuvat.
• doc_purpose: mihin dokumentaatio on tarkoitettu (withclaim, withorder, retain-doc). withpa kieltäydytään, koska CRD 2.2.1:n

oma invariantti crd-ci-q4 hylkää sen.

Mikä EHR ei ollut esihakenu, Perfuse lukee EHR:n fhirServer-palvelimesta lähetetyllä tunnisteella. Jos tämä epäonnistuu, vastaus on indeterminate CRD:n technical-syyllä, ei koskaan arvaus. Kattavuus, joka on päättynyt tai ei ole aktiivinen, vastataan not-covered, no-active-coverage.

members: fhir sääntötiedostossa ratkaisee kattavuuden maksajan omien tietojen perusteella tämän palvelimen FHIR-tietokannassa (käynnistä se -fhir-valinnalla), samat tiedot, mitä $member-match lukee:

• potilas, joka ei ole jäsen, vastaus on no-member-found;
• jäsen, jonka kattavuus ei vastaa, vastaus on coverage-not-found;
• ennakkovaltuutus, joka on jo hyväksytty siellä palvelulle (ClaimResponse, jossa on preAuthRef), vastaus on satisfied,

ja siinä on se numero.

Havaitseminen ilmoittaa davinci-crd.version ja coverage-info -konfiguraatiovaihtoehdon. Kun asiakas sammuttaa vaihtoehdon, vastaus on tyhjä. EHR JWT: t tarkistetaan CDS Hooks -määrittelyn mukaan, iss, aud, exp, iat ja jti ja ilman sub, ja toistuva jti hylätään.

Kutsut tunnistautuvat JWT:llä, jonka EHR allekirjoittaa kutsuun, jonka lähettäjä on nimetty -cds-clients-valinnassa sen JWKS-URLin kanssa - joka on se, miten CDS Hooks kuvailee sen - tai Perfusen API-tunnuksella. Etsintä on avoin, kuten CDS Hooks vaatii.

DTR: lataa kyselyt FHIR-päätepisteeseen, ja POST /fhir/Questionnaire/$questionnaire-package palauttaa ne DTR-pakettipaketteina, joissa on CQL-kirjastot, joita ne nimeävät. Pyynnössä voidaan nimeää kysely, tai lähettää tilaus ja antaa sen kattavuustiedon kertoa, mikä.

Kokeile sitä: Vakuuttajat → Väittämät ja valtuutukset → Kattavuusvaatimukset (CRD) lähettää tilauksen tälle palvelimelle säännöille, tai vakuuttajan CDS-palvelun URL: lle, ja näyttää kortit ja kattavuustiedot.

16.3 Väitteet CARIN Blue Button -muodossa

perfuse cms0057 carinbb parittaa kunkin väitteen 837-tiedostossa sen maksun 835-tiedostossa potilaan tilinumeron mukaan, jonka 835 on velvollinen palauttamaan, ja kirjoittaa FHIR-transaktion kullekin: ExplanationOfBenefit-potilaan, Kattavuuden, Organisaatioiden ja Ammattilaisten kanssa, joita se viittaa.

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

Profiili seuraa väitettä: ammattiväitteet (837P) muuttuvat C4BB-ExplanationOfBenefit-Professional-NonClinician-muotoon, ja laitoshoidon väitteet (837I) sairaalahoitoon tai päivystyskäyttöön laskutuksen tyypin mukaan. Jokainen merkintä on PUT-pyyntö, jonka tunniste on otettu lähtötunnisteista, joten saman väitteen lataaminen kahdesti päivittää sen sen sijaan, että tekee toisen kopion.

Kolme asiaa eivät ole kummassakaan X12-tiedostossa, ja kullekin niistä on omat käsittelytavat, jotka toteutetaan sanomalla niistä sen sijaan, että arvaillaan:

• Tunnistejärjestelmä. CARIN edellyttää, että jäsenen tunniste mainitsee maksajan nimitilan. -system on pakollinen; ei ole oletusarvoa, koska oletusarvo antaisi jokaiselle Perfusen käyttävälle maksajalle saman nimitilan.
• Verkkotilanne. Kumpikaan transaktio ei kerro, onko laskuttava palveluntarjoaja verkossa, ja se päättää, mitä jäsen maksaa. Ilman -network-valintaa hyöty maksamisen tila on other ja muunnos huomauttaa siitä.
• Väite, jota 835-tiedosto ei mainitse. CARIN ExplanationOfBenefit on väite, joka on ratkaistu. Ilman 835-tiedostoa ei ole maksajan väitettä, ei maksua eikä jäsenen vastuuta, joten väite ilmoitetaan ohitettavaksi eikä sitä muunneta.

Diagnoosit kirjoitetaan desimaalipisteen kanssa (J02.9, ei J029), koska se on siten kuin koodijärjestelmä julkaisee ne ja terminologiapalvelin, jolta kysytään toisesta oikeinkirjoitustavasta, sanoo, ettei se ole olemassa. Riippuvaisen jäsenen tunniste on saman kuin tilaajan, ja huomautukset sanovat niin. NPI, jonka tarkistusmerkki on väärä, ilmoitetaan ennen kuin US Core hylkää sen.

16.4 Ennakkovaltuutukset PDex-muodossa

perfuse cms0057 priorauth muuttaa Da Vinci PAS ClaimResponse:n — tai PAS-vastepakettin, joka sisältää yhden — PDex-enimmäkseen etukäteen hyväksytyn ExplanationOfBenefitiksi, jota kaikki kolme data-API:aa palvelevat.

perfuse cms0057 priorauth pas-response.json pas-claim.json

PAS-Claim on valinnainen ja lähes aina tarvitaan. ExplanationOfBenefit on sanottava, kuka kattaa päätöksen, ja vain pyynnössä on se; ilman sitä muunnos pysähtyy ja sanoo sen. Tarkastus-toimenpide — hyväksytty, hylätty, odottaa, sen valtuutusnumero ja syy — siirtyy PAS:n laajennuksesta PDex:iin, ja X12-palvelun tyyppi pitää koodinsa URI:n alla, johon PDex sitoutuu.

16.5 Tarjoajan pääsy- ja vakuutusyhtiöiden välinen API

Käyttäen -fhir-payer-apis FHIR-päätepiste vastaa kolmea lisäoperaatiota:

• POST /fhir/Patient/$member-match — HRex-jäsenen vastine. Kattavien tunnisteiden kapeentuminen muutamiin ehdokkaisiin, ja sukunimi ja syntymäaika on sitten sama; etunimi vertaillaan alkukirjaimen mukaan, ja sukupuoli vain, kun molemmat osapuolet ilmoittavat sen. Useampi kuin yksi selviytyjä ei ole vastine, ja vastaus on 422 eikä arvaus, koska arvaus paljastaa vierashenkilön vaatimukset. Aktiivinen Suostumus, joka sallii paljastamisen, vaaditaan, koska vakuutusyhtiöiden välinen API on opt-in jäsenelle; -fhir-member-match-without-consent kytkee sen pois testaamista varten.
• GET tai POST /fhir/Group/{id}/$davinci-data-export — Da Vinci:n bulk-vienti ryhmän nykyisistä jäsenistä. exportType valitsee yleisön: hl7.fhir.us.davinci-pdex#provider-download tai #provider-delta tarjoajan pääsyä varten, #payertopayer vakuutusyhtiöiden välistä API:aa varten.
• GET /fhir/Group/{id}/$export — standardi Bulk Data -ryhmän vienti, jota käsitellään tarjoajan pääsyä.

Viennit soveltavat poissulkuja poistuessa. Väitteet menettävät maksun ja kaikki maksujakosumman ja maksukirjeen määrät, ja säilyttävät palvelut, koodit, päivämäärät ja tarjoajat; CARIN-profiili poistetaan meta.profile-kentästä, koska resurssi ei enää täytä sitä. Payer-to-Payer jättää myös pois hylätyt etukätehyväksynnät. Aktiivisen PDex Provider Access -opt-out-suostumuksen omistavat jäsenet jätetään pois tarjoajan viennistä, ja lokimerkintä tallentaa montako niitä on. patient-parametri voi vain rajoittaa ryhmän jäseniin; kenenkään muun nimeäminen ei ole sallittua.

Ryhmän viennin käyttöoikeus määräytyy päätepisteen todennuksen perusteella. SMART-luvat määrittävät, mitä resursseja tokeni voi lukea, eikä mihin ryhmään, joten kunkin tarjoajan on oltava tokeni, joka voi tavoittaa vain oman attribuutioluettelon. API-tokeneita voidaan rajoittaa ryhmiin, kun ne luodaan — perfuse token create -label riverside-provider-access -fhir-groups riverside-attributed, tai Rajoita FHIR-ryhmiin -kenttä Käyttäjät → Konemääräiset tunnistetiedot — ja FHIR-päätepisteessä niitä voidaan lukea, suorittaa $davinci-data-export tai $export niiden kanssa ja noutaa mitä vienti tuottaa, ja mitään muuta. Toisen tarjoajan ryhmä vastaa ei löydy, eikä tokeni opi, mitä muita attribuutioluetteloita on olemassa; kaikki muut pyynnöt, mukaan lukien jäsenen vastaavuus ja tavallinen haku, evätään. Rajoitus koskee API-tokeneita; SMART-issuerin tokenissa ei ole ryhmärajoitusta. Kun SMART on määritetty, API-tokeneita evätään, ellei Asetukset → FHIR → Hyväksy Perfuse API -tokenit SMART-tokenien lisäksi ole käytössä (ks. Turvallisuus, *Kuka voi soittaa FHIR-päätepistettä*); tarjoajan ryhmärajoitettu token tarvitsee sen.

16.6 Tarjoajahakemisto: Plan-Net

CMS-0057 pyytää myös vakuutusyhtiöiltä tarjoajaluetteloa, ja FHIR-päätepiste palvelee sitä Da Vinci Plan-Net 1.1.0:lle ilman vaihtoehtoa käyttää: lataa tarjoajat, tarjoajan roolit, organisaatiot, organisaatioiden jäsenyydet, sijainnit, terveydenhuollon palvelut, vakuutussuunnitelmat ja päätepisteet, ja jäsenten sovellukset voivat etsiä niitä. Jokainen Plan-Net-hakuparametri on indeksoitu - roolin verkosto ja palvelu, suunnitelman kattavuusalue, jäsenyyden osallistuva organisaatio, organisaation partof - sekä oppaan kyselyiden käyttämät sisällytykset ja käänteiset ketjut (_has), ja CapabilityStatement -luetteloi Plan-Net-profiilit.

Infernon Plan-Net -sarja läpäisee 199 testiä. 10 testiä, joita se epäonnistuu, ovat eteenpäin ketjut, joissa paketti ottaa hakuarvonsa ensimmäisestä organisaatiosta, jonka se on nähnyt, eikä resursseista, joita haetaan; tämä on ilmoitettu paketille (sen ongelma 34), ja palvelin vastaa näihin kyselyihin oikein, kun sille annetaan arvo, jota data sisältää.

16.7 Etukäteen hyväksytyn mittarit

perfuse cms0057 metrics lukee CSV-tiedoston, joka on viety käytöstä poistetusta hyödykkeen hallintajärjestelmästä, ja tuottaa julkaistun sivun, jonka CMS vaatii, sen *Etukäteen hyväksytyn mittausraportoinnin — Yleiskatsaus ja malli* -layoutissa.

perfuse cms0057 metrics -year 2025 -org "Springfield Health Plan" -services services.csv \
    decisions.csv > prior-authorization-metrics-2025.html

Sarakkeet löydetään otsikosta: priority, received, decided ja decision ovat vaadittuja, ja request_id, line_of_business, extended, appealed, appeal_decision, service_code ja service_description luetaan, kun ne ovat läsnä. Pyynnöllä on vuosi, jolloin se päätettiin; yksi, joka on edelleen odottamassa, on lueteltu pois suljetuksi, ei koskaan laskettu. Jokainen rivi, jota ei voida lukea, ilmoitetaan rivinumeronsa kanssa.

Laskenta seuraa mallia: standardi- ja kiireellisten pyyntöjen erikseen, hyväksytyn ja hylätyn osuus, hyväksytty ja hylätty päätösaikataulun mukaan, hyväksytty arvion jälkeen, kun tarkasteluaika oli pidennetty, ja hyväksytty valitusten jälkeen — valituksista, ei pyynnöistä — keskiarvon ja mediaanin mukaan, aika vastaanotosta päätökseen. Mediaani, joka on alle päivän, kirjoitetaan tunteina eikä pyöristetä „0 päivää“, jota malli pyytää nimenomaisesti. Osittain hyväksytyt pyynnöt lasketaan hyväksytyiksi, koska mallissa ei ole luokkaa niille, ja sivu kertoo, kuinka monta niitä oli. Mittaukset ilmoitetaan liiketoimintalinjoittain, joka on CMS:n vaatima taso.

Sivu on itsenäinen — siinä ei ole skriptejä, ulkoisia tyylitaulukoita tai fontteja — koska se on julkaistu julkisella verkkosivustolla, ja mikä tahansa siitä ladattu on erillinen asia, joka voi hajota tai seurata vierailijaa. -format csv ja -format json antavat samat numerot muille käyttökohteille. Ilman -services-valitsinta sivu sisältää ilmoituksen, jonka mukaan luettelo kohteista ja palveluista, jotka edellyttävät ennakkohyväksyntää, puuttuu, koska CMS vaatii sitä samalla sivulla.

16.8 Lääkkeet: lääkevalikoima, reaaliaikainen lääkehyöty ja sähköinen ennakkohyväksyntä

CMS-0062-P (ehdotettu 14. huhtikuuta 2026) tuottaisi lääkkeet etukäteen: vaikuttavat vakuutusyhtiöt tuottaisivat NCPDP SCRIPT -sähköisen etukäteen hyväksynnän, NCPDP Formulary & Benefit -standardin ja NCPDP Real-Time Prescription Benefit -palvelun 1. lokakuuta 2027 alkaen, päättäisivät lääkepyynnöt 24 tunnin (kiireellinen) ja 72 tunnin (vakaa) kuluessa, antaisivat tarkan syyn jokaiselle evästyksestä ja ilmoittaisivat lääkekohtaiset tiedot vuonna 2028. Medicare Part D vaatii jo SCRIPT ePA:ta. Yksi tiedosto, formulari, vastaa kaikkea tähän liittyvää:

perfuse serve -fhir -pas -crd-rules payer-rules.yaml -formulary formulary.yaml

examples/formulary/formulary.yaml on esimerkki, jonka lääkkeet ovat todellisia RxNorm-käsitteitä NDC:iden kanssa RxNorm-listoja varten (tarkistettu RxNavia vasten). Tiedosto nimeää maksajan, sen suunnitelmat (jokainen suunnitelma, jolla on käytössään formulario, ryhmän tunnukset ja kustannusjaot apteekin hyödyksi ja tasolla) ja sen formulariot. Jokainen lääke on RxNorm SCD tai SBD, jolla on RxNorm-ryhmä (SCDG tai SBDG, jonka Drug Formulary API vaatii), NDC:t, taso, ja rajoitukset: prior_authorization, step_therapy, quantity_limit (määrä tietyssä päivien määrässä, ja päivittäinen enimmäismäärä), not_covered, alternatives (RxNorm-koodit, suosituimmasta ensin), notes, ja questionnaire, FHIR Questionnaire -kyselylomakkeen kanoninen URL, jota priorisointi pyytää. cost_30_day on suunnitelman kustannus 30 päivän tarpeesta, josta vakuutusmaksu on prosenttiosuus; ilman sitä vakuutusmaksu ilmoitetaan prosentteina, ei keksittyynä summaksi. Koko tiedosto tarkistetaan, kun se ladataan, ja kaikki ongelmat luetellaan kerran. Jäsen löytyy tiedoston members-listasta, ryhmittäin tai FHIR-kaupasta: Coverage, jonka subscriberId on jäsenen tunnus ja jonka class-tyyppi on plan on suunnitelman tunnus. Maksajat › Lääkkeet näyttää formularion, hinnoittelee lääkkeen ja suorittaa priorisoinnin loppuun asti.

16.8.1 Da Vinci US Drug Formulary API

Julkaistu /formulary/fhir -osoitteessa Da Vinci US Drug Formulary 2.1.0: kunkin suunnitelman PayerInsurancePlan, kunkin formularion Formulary (molemmat InsurancePlan), kunkin lääkkeen FormularyDrug (MedicationKnowledge) ja kunkin kohteen FormularyItem (Basic). Oppaan haut ovat käytettävissä (Basic?code=formulary-item&formulary=...&drug-tier=...&pharmacy-benefit-type=...&period=..., subject:MedicationKnowledge.code, InsurancePlan?formulary-coverage=..., coverage-type, MedicationKnowledge?code=...&doseform=...) _include=Basic:subject, Basic:formulary ja InsurancePlan:formulary-coverage kanssa. Se on julkinen, ilman tunnistetietoja, kuten CMS vaatii vakuutusyhtiön formulariolta: se palvelee erillisestä, muistissa olevasta kaupasta, joka sisältää vain formularion, joten sen avaaminen ei voi päästä potilaan tietoihin. Se on vain luettavissa. Poistettu lääke ei julkaista, koska API luettelee, mitä formulario kattaa; RTPB ja ePA vastaavat sille, että se ei ole kattavuudessa.

16.8.2 Reaaliaikainen lääkehyöty

POST /ncpdp/rtpb ottaa RTPBRequest-pyynnön (NCPDP RTPB v13) operaattorin roolin API-tunnisteella ja vastaa RTPBResponse-viestillä formulariosta: kattavuustila, formulariotila, jäsenen arvioitu osuus ja suunnitelman osuus sekä kattavuusrajoitukset, joissa on jopa viisi kohdetta, jotka on hinnoiteltu samalla tavalla. Rajoituskoodit ja kunkin tilaan liittyvä tila noudattavat NCPDP:n julkisia RTPB-toteutussuositukset: 75 edellyttää etukäteen hyväksyttyä, 608 askelhoidon, 76 suunnitelman rajoitukset ylitetty, 7X päivien tarjoamisen ylittäminen suunnitelman rajoituksista (esim. lääke, jota ei voi toimittaa postitse), 70 ei kuulu kattavuuteen, kaikki *kattavuudella varustetut* (CR) paitsi 70 (NC). Jäsen, jolla on hyväksytty etukäteen hyväksytty, saa CC- ja AB8-vastauksen, kuten Surescripts-opas pyytää, jotta määrääjä ei joutuisi pyytämään uudelleen. Pyynnön, jota ei voida hinnoitella, vastaus on NotProcessed NCPDP:n hylkäyskoodilla: 52 jäsenen tuntemattomuuden vuoksi, E7 ja 19 puuttuvan määrän tai päivien tarjoamisen vuoksi. Apteekeille myönnettävä etu luetaan pyynnöstä: täyttö yli 34 päivää on kolmen kuukauden tarjoaminen, ja apteekin tyyppi M on postimyynti.

16.8.3 Sähköinen ennakkohyväksyntä (NCPDP SCRIPT)

POST /ncpdp/script ottaa PAInitiationRequest-, PARequest-, PAAppealRequest- ja PACancelRequest-pyynnöt operaattorin roolin API-tunnisteella ja vastaa kullekin pyynnölle vastaavalla vastauksella:

Kysymysryhmä on lääkkeen FHIR-kysymyslista FHIR-kaupasta, sama kuin DTR täyttää: totuusarvo muuttuu kyllä/ei-valinnaksi, valinta valinnaksi, numero numeeriseksi, päivämäärä päivämääräksi ja muu vapaa teksti; ryhmät laajennetaan järjestyksessä ja enableWhen-ominaisuutta ei siirretä, koska SCRIPT jakautuu valinnan mukaan eikä ehdolla. Lääke, jolla ei ole kysymyslistaa, kysytään kolmea vapaa-tekstikysymystä: diagnosi, mitä on kokeiltu ja miksi tämä lääke. PARequest muuttuu Da Vinci PAS-pyynnöksi: Claim-pyyntö lääkkeestä (RxNorm ja NDC), MedicationRequest-pyyntö, jota se pyytää, potilas, määrääjä, maksaja ja kattavuus sekä vastaukset QuestionnaireResponse-muodossa, ja liitteet DocumentReference-muodossa. Sitten päätetään kuten kaikki etukäteen hyväksytyt tässä palvelimessa: sääntötiedosto, päätöspalvelu (-pas-decider-url), tai arvioijan jono, jossa se on merkitty Lääke ja pidetään lääkeajan rajoituksissa. Päätöspalvelu näkee lääkepyynnön täsmälleen samalla tavalla kuin se näkee sen EHR:n PAS-asiakkaalta. Suosittelemme Vagliota, BioDreamin avoimen lähdekoodin (PolyForm Shield) päätösmootoria, jossa on lääkepolitiikat askelhoidolla; maksajan oma moottori liittyy samaan -pas-decider-url-osoitteeseen, eikä mitään moottoria tarvita sääntötiedostolle ja arvioijille päätöksen tekemiseen.

Päätös, joka tehdään pyynnön jälkeen (arvioijan tai valittajan), lähetetään määrääjälle pyynnöttömänä PAResponse- tai PAAppealResponse-viestinä, joka reititetään kanavaan, jonka nimi on -epa-reply-channel, joka toimittaa sen verkkoon. Ilman kanavaa tai kun toimitus epäonnistuu, tapaus kertoo, ettei määrääjää ole ilmoitettu, ja näyttö lähettää sen uudelleen.

Maksajat › Lääkkeet › Etukäteen hyväksytyt lähettää viestit, jotka määrääjän järjestelmä lähettäisi tälle palvelimelle (aloitus, vastaus kysymyksiin, nähdään päätös), luetellaan jokainen tapaus, mitä määrääjälle on kerrottu, ja näytetään lääketilastot, jotka CMS-0062-P ehdottaa: pyynnöt hyväksytty, hylätty ja odottava, valitukset ja hyväksytty tai hylätty valituksessa, keskiarvo ja mediaani tuntia pyynnöstä päätökseen, ja kuinka monta niistä päätettiin myöhässä. Lääkkeet, jotka on pyydetty lääkärin etuuden kautta (HCPCS J-koodi MedicationRequest-pyynnöllä tai RxNorm- tai NDC-koodilla), lasketaan lääkkeiksi myös PAS-luvuissa.

Mikä tämä perustuu, selkeästi sanottuna. NCPDP:n schemat ja toteutusoppaat ovat lisensoituja. Elementtien nimet ja järjestys seuraavat julkisia Surescripts ePA- ja RTPB-oppaita ja niiden esimerkkejä, sekä NCPDP:n julkisia RTPB-suositukset. Kaksi elementtiä, joita julkiset materiaalit eivät näytä, on kirjoitettu SCRIPT-malliin, jota käytetään muualla, ja ne tulisi tarkistaa lisensoituun kopioon ennen sertifiointia: Closed/ReasonCode ja Denied/DenialReason. Yhtään viestiä ei ole tarkistettu NCPDP:n XSD:ää tai verkon sertifioinnin vastaisuutta. NCPDP Formulary & Benefit -tiedostoa ei tuoteta: sen täydellinen rakenne on NCPDP:n lisensoitussa oppaassa, ja osittainen tiedosto hylätään verkkoon, joka lataa sen.

16.9 Mitä tarkistettiin ja mihin

CARIN- ja PDex-tulosteet on validoituna virallisella HL7 FHIR-validoimisohjelmalla, joka on ladattu julkaisemalla paketteja (hl7.fhir.us.carin-bb#2.2.0, hl7.fhir.us.davinci-pdex#2.2.0): ammattimaiset, sairaalahoito- ja ulkosairaalahoitopyynnöt ja kaksi PAS-päätöstä, ilman virheitä. PDex-syötteet olivat PAS-oppaan omat esimerkit eikä tässä kirjoitettuja muotoja, jotka ovat yhtensopivia muuntimien kanssa. Validoija löysi viisi virhettä ensimmäisellä suorituksella — muun muassa, että CARIN vaatii profiilin version meta.profile- ja vaatii korvauslajikoodin version laitosten korvauspyynnöissä — ja jokainen on korjattu ja testattu.

Tämän rakentaminen paljasti vanhemman virheen: FHIR-kauppa pudotti jokaisen elementin, jota sen sisäinen malli ei ollut määritellyt, joten ExplanationOfBenefit menetti kohteensa, diagnosoinnit, sovittelun ja maksun sisääntullessa. Kauppa säilyttää nyt mitä tahansa resurssi kuljettaa, ja testi lataa CARIN-korvauspyynnön palvelimen kautta ja lukee sen takaisin kokonaisena.

CRD:n tuloste - päivitetty tilaus ja CDS Hooks -vastaus CRD:n omassa loogisessa mallissa - ja DTR:n pakkaustuloste validoidaan virallisessa HL7-validoimisohjelmassa CRD 2.2.1:een ja DTR 2.2.0:aan ilman virheitä.

DTR tässä on maksajan puoli 2.2.0:sta. $questionnaire-package ottaa kysymyslistat, jotka on nimetty, CRD:n nimettyjä tilauksia tai CRD:n palauttamaa kattavuusväittämän tunniste (context, kun sama prosessi palvelee CRD:ä), ja palauttaa kunkin niistä pakkauspinona, jossa on QuestionnaireResponse, jota täytetään, ja kirjastot, joita sen CQL tarvitsee ja niiden riippuvuudet. Arvojoukon arvot, joita vastaukset käyttävät, matkustavat pakkauksessa, kun ne ladataan (PUT /fhir/ValueSet/{id}), ja $expand listaa niiden koodit. $log-questionnaire-errors kirjoittaa, mitä DTR-sovellus raportoi palvelimen lokitiedostoon.

Soveltuvat kysymyslistat: kirjoita koko kysymyslista kerran SDC:n questionnaireAdaptive-laajennuksella ja enableWhen-ominaisuudella kysymyksillä, jotka koskevat vain joskus. Pakkaus antaa sovellukselle tyhjän kuoren, ja kunkin $next-question-kutsun kutsuu seuraavan kysymyksen, joka koskee vastauksia tähän asti, kunnes ei ole enää mitään kysyttävää ja vastaus on merkitty valmiiksi. Järjestys ja haarautuminen ovat maksajan omat säännöt; kysymyksiä, jotka eivät koske, ei näytetä koskaan.

Kirjautuminen asiakkaana: DTR- ja PAS-asiakkaat tavoittavat maksajan SMART Backend Services -palvelun kautta, jossa allekirjoitettu JWT vaihdetaan tokeniin maksajan valtuutuspalvelimella. Osoita Perfuse tähän palvelimeen -smart-issuer-valinnalla (ja -smart-jwks-valinnalla, jos osoite ei voi selvittää Perfusen kautta), ja anna -smart-backend-services-valinta, jotta löytödokumentti ilmoittaa tämän. Inferno DTR -paketti käy tämän kautta Keycloak-valtuutuspalvelimen kanssa.

Perfuse voi toimia itse valtuutuspalvelimena: serve -fhir -smart-clients clients.yaml antaa Backend Services -tokenit osoitteessa /auth/token luetteloiduille asiakkaille, joilla on julkiset avaimet, joilla ne allekirjoittavat väitteensä, ja järjestelmän laajuudet, joita niille voidaan myöntää, ja FHIR-päätepiste hyväksyy ne. Erillistä tunnistuspalvelinta ei tarvita maksajan koneiden väliseen viestintään.

With -smart-users users.yaml as well, members and clinicians sign in there to authorize apps, which the Patient Access API needs: the app sends the person to /auth/authorize, they sign in, a clinician chooses the patient, and both see what the app asks for and can untick any of it. A member is only ever given their own record, whatever the app asks for. Each person in the file names the FHIR resource they are, Patient/… or Practitioner/…, and a password hash from perfuse smart hash; the password itself is never written down.

Ihmiset voivat kirjautua sisään myös organisaation oman tunnistuspalvelimen kautta: -smart-oidc oidc.yaml nimeää sen (julkaisija, asiakas-tunnus ja salaisuuden sijainti), ja kirjautumissivu tarjoaa "Kirjaudu sisään"-vaihtoehdon sen rinnalla. Jokainen henkilö on linkitetty palveluntarjoajan aiheen mukaan, oidc_subject käyttäjätiedostossa, joten tiedosto päättää edelleen, kuka voi valtuuttaa sovelluksia ja minkä FHIR-resurssin he ovat; tili, joka ei ole linkitetty kenenkään kanssa, evätään. Koodit, päivitämistunnukset ja peruutukset tallennetaan tietokantaan, joten uudelleenkäynnistys ei kirjaa ketään ulos.

Käyttäjät → SMART-sovellukset-konsolissa luetteloidaan rekisteröidyt sovellukset ja henkilöt, ja niitä voidaan lisätä, muokata ja poistaa. Jokainen tallennus tarkistetaan kuten tiedostot käynnistyksen yhteydessä, kirjoitetaan niihin ja käytetään heti. Salainen sovellus, joka tallennetaan ilman salaisuutta, saa yhden, joka näytetään kerran; salasana asetetaan siellä ja sitä ei koskaan näytetä uudelleen. Sovelluksen tai henkilön poistaminen lopettaa välittömästi jo myönnettyjen pääsytokenien ja heidän myöntämiensä pääsytokenien käytön, eikä odota niiden vanhenemista, ja niiden päivitämistunnukset niiden kanssa.

Laajuudet voivat olla hienorakeisia, kuten SMART App Launch 2 ja US Core määrittelevät ne: patient/Observation.rs?category=laboratory lukee vain havainnot, jotka hakukysely löytää. Sallinta, joka on suodatettu tietyn tyyppisille, soveltaa suodatinta kaikkiin kyseisen tyyppisten hakuihin ja lukuihin; suodattamaton sallinta kyseiselle tyypille tai * poistaa sen. Suodatin, jota ei voida lukea, ei myönnä mitään sen sijaan, että se myöntäisi kaiken.

16.10 Päättäminen ennakkovaltuutuspyynnöistä: PAS

serve -fhir -pas -crd-rules rules.yaml vastaa Da Vinci PAS 2.2.1:ia osoitteissa POST /fhir/Claim/$submit ja POST /fhir/Claim/$inquire. Päätökset perustuvat samaan sääntöihin kuin CRD:n vastaukset, joten clinician käyttöön tarvittava hyväksyntä määräytyy säännön mukaan, joka niin päätti:

  - 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

Jokaiselle kohteelle annetaan X12-arviointitoimi: A1 sertifioitu, A3 ei sertifioitu, A4 odottaa, A6 muutettu, C peruutettu (sertifiointityyppi 3). Rivi, joka ei mainitse palvelua, ei ole päätetty, mutta se vastaa virheellä (X12 901 AG, oikein ja lähetä uudelleen). Vastaus toistaa sen, mitä 278-vastaus toistaa — kohdekoodit, pyydetyt palvelupäivämäärät, kohtaamisen päivämäärät, siirtotunnisteet lähettäjän ja vastaanottajan kanssa vaihdettuna — ja antaa kullekin riville maksajan oman hallinnollisen viitenumeron. Palvelu, jota ei mainita, odottaa aina, eikä sitä hyväksytä: päätös, jota kukaan ei ole kirjoittanut, on päätös, joka vaatii ihmisen toimintaa.

Odottavat pyynnöt odottavat arvioijaa, joka vastaa POST /fhir/Claim/$decide :lla:

{"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 voi myös olla modify: sertifioitu, mutta ei pyydetyssä muodossa, quantity (valueDecimal, sertifioitu arvo) ja/tai alternative (valueCoding, hyväksytty palvelu) kanssa. Vastaus kertoo sitten A6 Modified, sertifioitu yksityiskohta tai vaihtoehto lisätynä kohtana ja autorisaatiotunniste. item (valueInteger, toistuva) rajoittaa päätöksen tiettyihin kohtiin. Päätös muodostaa uuden version vastauksesta, joka on merkitty tarkistetuksi henkilön toimesta, ja se toimitetaan -fhir-subscriptions avainsanalla PAS-aiheeseen (PASSubscriptionTopic, suodatettu org-identifier avainsanalla, pyytäjäorganisaation tunniste) kokonaisena PAS-vastausryppäänä, samassa transaktiossa, jossa se tallennetaan. $inquire palauttaa nykyisen vastauksen jokaiselle pyynnölle, jonka tarjoaja on tehnyt kyseisestä jäsenestä; toisen tarjoajan kysely ei löydä mitään. $decide vaatii kirjoitusoikeuden; $inquire on lukuoikeus.

Pyynnöt ja niiden vastausten kaikki versiot säilytetään pas_requests- ja pas_responses-tietokannoissa palvelimen tietokannassa.

16.10.1 Arvioijan jono

Verkkokonsolissa Payers → CMS-0057 → Reviewer queue luetellaan odottavat pyynnöt niiden määräaikojen mukaan: kiireinen pyyntö (Claim.priority stat) on määräaikainen 72 tuntia sen saapumisesta, standardipyynnölle 7 päivää. Valitsemalla yhden näytetään jäsen, tarjoaja, jokainen palvelu pyydetyillä yksiköillä ja sen tila, mitä vastaus pyysi, ja jokainen asiakirja, joka on vastaanotettu siitä, ja jokainen asiakirja näytetään selkeästi. Muokkain tallentaa päätöksen siellä: hyväksy, hylkää tai muuta (sertifioitu arvo tai toinen hyväksytty palvelu), syyn ja arvostelijan NPI:n kanssa. Muutos on oltava vähemmän yksiköitä kuin mitä pyydettiin; yhtä monta tai enemmän on hyväksyntä, ja se hylätään muutoksena. Hyväksytty palvelu alkaa pyydetyssä koodijärjestelmässä. Se on sama päätös, jonka $decide tekee, joten tarjoajan tilaus toimittaa sen. Pyyntöjen lukeminen ja päätöksen tekeminen ovat molemmat kirjoitettu lokitietoihin.

Monitor → Tiimikohtaiset työpöydät → Ennakkohyväksyntä näyttää viimeisten 30 päivän aikana, kuinka monta standardia ja kiireellistä pyyntöä päätettiin CMS-0057:n aikatauluissa, myöhässä, odottaa vielä aikataulun puitteissa ja on myöhässä, sekä median päätösaika ja miten pyydetyt palvelut käsiteltiin: hyväksytty, muutettu, hylätty tai edelleen odottaa. Nämä kaksi tiiltä luetaan pyynnöistä itsestään, joten ne eivät ole työpöydän Grafana-vienti, joka mainitaan kuvauskohtaisesti.

16.10.2 Vastaanottaminen asiakirjoja, joita kesken oleva pyyntö pyytää

A pended response asks for documents with a Task and one CommunicationRequest per document. A questionnaire is asked for as PAS describes it: a CommunicationRequest with the single LOINC code 102089-0, under the trace number of the line it is for (itemTraceNumber, which the ClaimResponse echoes; a line sent without one is given one). That trace number is the DTR context: $questionnaire-package with only context set to it returns the questionnaire. The provider sends what was asked for with Da Vinci CDex $submit-attachment (POST /fhir/$submit-attachment): the TrackingId is the request's own trace number (the ClaimResponse's first identifier, which is also the Task's), or a CommunicationRequest's identifier, AttachTo is preauthorization, and MemberId must be the request's member. Each attachment's DocumentReference or QuestionnaireResponse is kept with the request and shown to its reviewer; a document arriving decides nothing.

16.10.3 Päätöksenteko X12-käytön hyödyntämisessä

Useimmat maksajat päättävät etukäteen valtuutukset UM-järjestelmässä, joka käyttää X12 278:aa. -pas-278-url:n avulla Perfuse toimii FHIR-etuena tämän järjestelmän kanssa: jokainen $submit lähetetään yhtenä 278-pyynnönä (005010X217), ja jokainen kohteena oleva potilastapahtuma. Jokainen pyyntö sisältää PAS:n antamat tiedot: tarkastelutyyppi (extension-serviceItemRequestType, UM01: terveydenhuollon palvelut, sairaalahoito tai erikoistuva hoito), sertifioinnin tyyppi (extension-certificationType, UM02), palvelun tyyppi, palvelun sijainti (UM04), palvelun taso (extension-levelOfServiceCode, UM06: valinnainen, kiireellinen tai hätätilanne; stat-prioriteetti korvaa kiireellisen), päivämäärä, sairaalahoitotarkastuksen sairaalaan ottamisen ja lähtemisen päivämäärät, diagnoosit, hoitotiimin tarjoaja, joka suorittaa palvelun, ja menettely ja määrä, ammattimaisena (SV1) tai sairaalavaatimuksena (SV2) palvelulinjana. 278-vastauksen toimintakoodi ja valtuutusnumero muuttuvat kohteen tarkastustoiminnoksi: vahvistettu, osittain vahvistettu, muutettu, hylätty, keskeytetty tai ei käsitelty (keskeytetty arvioijalle, hylkäysyllä perusteilla). Paikalliset säännöt eivät ole otettu huomioon.

perfuse serve -fhir -pas -pas-278-url https://um.example/x12/278 -pas-278-receiver ACMEUM \
  -pas-278-token-env UM_TOKEN

UM-järjestelmä, joka odottaa ensin ja päättää myöhemmin, lähettää myöhemmän 278-vastauksensa POST /fhir/Claim/$decide-278:een; jokainen tapahtuma vastaa pyyntöä Perfusen lähettämän jäljitysnumeron perusteella, ja se päätetään kuten $decide päättäisi sen. Jos UM-järjestelmää ei voida tavoittaa tai se vastaa jollakin, joka ei ole 278-vastaus, jokainen kohta odottaa katselijaa ja tarjoajalle ilmoitetaan vain siitä; syy on palvelimen lokissa.

Kyselyt, joita UM-järjestelmä vastaa

Tarjoajan $inquire-pyynnön on löydettävä valtuutus, riippumatta siitä, miten se pyydettiin: faksilla, maksajaportaalissa, puhelimitse tai 278-lomakkeella, jonka toinen lähettäjä on lähettänyt. Perfuse tallentaa vain pyynnöt, jotka tulivat sen kautta; UM-järjestelmä tallentaa ne kaikki. Joten UM-järjestelmällä, joka vastaa reaaliajassa (jokainen kuljetus sftp:n lisäksi), jokainen $inquire lähetetään sinne myös 278-kyselynä (005010X215: BHT02 28, jäsen, tarjoaja, valtuutusnumero Claimin insurance.preAuthRef:stä, kun sellainen on, ja tapahtumapäivämäärät billablePeriod:sta tai palvelupäivämäärät, muutoin vuosi ennen tai jälkeen tätä). Jokainen valtuutus, jota vastaus sisältää ja Perfuse ei (yhdistetty lähettämistään jäljitysnumeroista ja antamistaan valtuutusnumeroista), tulee takaisin yhtenä Claim Inquiry Response Bundle: UM-järjestelmän päätös kullekin palveluriville, valtuutusnumero ja -jakso, sekä huomautus, jossa kerrotaan, missä se löytyi. Mitään Claimia ei luoda valtuutukselle, jota kukaan ei ole lähettänyt FHIR:issä: sen ClaimResponse.request sisältää data-absent-reason, kuten PAS-profiili sallii. Kysely lukee vain; mitään Perfusen omia tietoja ei muuteta. Jos UM-järjestelmä on alhaalla tai vastaa TA1:llä tai 999:llä, tarjoaja saa sen, mitä Perfuse sisältää, ja linkin tila kertoo, miksi.

Miten 278:t saapuvat UM-järjestelmään

UM-järjestelmän yhteysopas kertoo, miten se ottaa 278:t vastaan, ja -pas-278-transport (Asetukset, Vakuuttajat, Käytön hallinta -linkki) seuraa sitä:

Asiakasvarmenne on -pas-278-cert ja -pas-278-key; -pas-278-ca luottaa maksajan omalle varmenneviranomaiselle. OAuth on -pas-278-oauth-token-url, -pas-278-oauth-client-id ja salaisuus, joka haetaan asiakasvirran myöntämisen kautta ja säilytetään yksi minuutti ennen vanhenemista. Salasanat, tokenit ja salaisuudet eivät koskaan ole liput: kunkin nimi on ympäristömuuttuja (-pas-278-password-env, -pas-278-token-env, -pas-278-oauth-secret-env, -pas-278-sftp-password-env), tai kirjoitetaan asetussivulle, missä se säilytetään asetustiedostossa (vain palvelimen tilillä luettavissa) ja ei koskaan näytetä uudelleen.

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

SFTP:n yli jokainen pyyntö pidetään odottamassa, kunnes vastaus saapuu: 278-vastaus päättää kohteet, ja Perfuse laittaa 999 hyväksymisen lähetettäväksi ulosmenokansioon. Tiedosto, jota ei voida lukea, pysyy saapumiskansiossa henkilölle, ja se tarjotaan uudelleen seuraavalla lukukerralla.

Kun UM-järjestelmä ei voi lukea pyyntöä

UM-järjestelmä, joka ei voi lukea 278:aa, vastaa TA1:llä (kuorella) tai 999:llä (transaktiolla) päätöksen sijaan. Perfuse tutkii, mikä ja mitä se sanoo, pidättelee jokaisen kohteen ("käyttöjohtamista ei voitu lukea pyyntöä"), ja merkitsee sen. Payer, CMS-0057, Reviewer-jono näyttää linkin: mitä viimeisen viikon aikana lähetettiin, kunkin vaihdon mukaan sen ohjausnumeron, ja mitä siitä tuli (vastattu; tunnustettu, vastaus tulee; hylätty, 999:n segmentin, elementin ja koodin mukaan; ei tavoitettu). Kunkin vaihdon oma ohjausnumero on yksi enemmän kuin edellinen, joka on se, mitä TA1 tai 999 nimeää vastauksena.

16.10.4 Päätöksenteko kliinisen näytön perusteella päätöspalvelun avulla

Sääntötiedosto päättää palvelukoodin perusteella: koodi ei tarvitse hyväksyntää, ei kuulu korvauksiin tai menee katselijalle. Onko tämä potilas kelpoinen sille, on eri kysymys, joka vastataan ehdosta, kyselyvastauksista ja asiakirjoista, jotka tarjoaja lähetti pyynnön kanssa. -pas-decider-url-valinnan kanssa jokainen kohta, jonka säännöt jättävät katselijalle, lähetetään ensin päätöspalveluun, kuten Vaglioon, joka lukee saman PAS-pyynnön paketin Perfusen julkaiseman pas-paketin kautta. Julkinen Vaglio, joka toimii keksittyjen pyyntöjen kanssa, toimii Perfusen testitilanteen rinnalla osoitteessa https://vaglio.perfuse.health:8443 (kirjaudu sisään demo-tunnuksella, salasana try-vaglio-demo; se voi tarkastella kaikkea ja muuttaa mitään): jokainen päätös siellä on perusteltu, selkeäkielinen kirje ja kuitti, jonka kuka tahansa voi tarkastaa.

perfuse serve -fhir -pas -crd-rules payer-rules.yaml -pas-decider-url https://vaglio.example/api/pas/decide \
  -pas-decider-token-env VAGLIO_TOKEN

URL on oltava https, tai pelkästään http tähän laitteeseen (localhost, 127.0.0.1), koska se sisältää potilaan tiedot ja tokenin. Vaglio itse vastaa vain https:lla; kun se käyttää omasta viranomaisestaan peräisin olevaa varmenne, anna se -pas-decider-ca DATA/tls/ca.crt (tai mikä tahansa maksajan sisäinen viranomainen, jonka palvelun varmenne on peräisin). Palvelu saa pyynnön paketin sellaisena, kuin tarjoaja lähetti sen, POST <url>?item=<sequence> (application/fhir+json), ja vastaa {"decision": "approve" | "deny" | "pend", "why": "...", "requested": ["..."]}, tai 404, kun se ei päättä mitään kyseiselle kohteelle, jolloin sääntöjen vastaus pysyy voimassa. why on vastauksen prosessimuistiinpano ja vaaditaan hylkäykselle, joka muuten odottaa; requested ilmoitetaan tarjoajalle odottavan pyynnön tarvitseman tiedon. Odottaminen voi myös sisältää "questionnaire": "<canonical>" ja "attachments": ["<LOINC>", ...], jotka pyydetään vastauksen CDex-tehtävässä ja viestintäpyynnöissä DTR-kyselylomakkeen ja liitetiedostojen lisäksi (säännön kyselylomake voittaa, koska tehtävä pyytää yhtä; koodi, joka ei ole LOINC:n muotoa, hylätään ja kirjataan lokitietoihin). Sääntö, joka hyväksyy tai hylkää, on maksajan korvauspolitiikka eikä lähetetä palveluun. Virhe, aikakatkaisu tai vastaus, joka ei ole yksi kolmesta päätöksestä, odottaa kohdetta katselijalle, ja syy on palvelimen lokissa: mitään tässä ei muuteta hyväksynnäksi. Tätä ei voida yhdistää -pas-278-url:iin, jossa UM-järjestelmä vastaa jokaiselle kohteelle.

Neuvonta ennen lähettämistä. -crd-advisor-url-valinnan kanssa -crd-rules-valinnan rinnalla CRD pyytää myös päätöspalvelulta, mitä ennakkohyväksyntäpyyntö kullekin tarvitsisi, ja näyttää vastauksen yhtenä lisäkorttina: "Ennen kuin lähetät: pyyntö tähän vaatisi: ...", tai "hyväksytään", ja mitä se edellyttää, kyselylomake, joka pyytää sitä, ja mitä se hyväksyisi. Vaglio vastaa /api/pas/advise-osoitteessa, samalla tokenilla ja viranomaisella kuin edellä:

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 lähettää POST <url>:n {"service": {"system": "...", "code": "..."}, "resources": [ ... ]}, resursseina haun etukäteisnoudon (potilas ensin, kattavuus jätettiin pois), ja lukee {"decides": true, "answer": "approve" | "pend" | "deny", "summary": "...", "missing": [...], "questionnaire": "...", "toApprove": [[...]], "policyTitle": "..."}. Se on neuvo, eikä se muuta mitään: katteentiedot, muut kortit ja PAS-päätös ovat sääntöjen mukaan. Se odottaa enintään kolme sekuntia, ja vastaamattomuus, epäonnistuminen tai "decides": false jättää vastauksen sellaisenaan ilman sitä. Perfuse ei koskaan tarvitse päätöspalvelua.

Pyyntö sisältää X-PAS-Request-Id-tunniste, jolla vastaus tunnetaan. Palvelu, jolla on omat katselijansa, joka odottaa kohdetta, voi lähettää heidän päätöksensä myöhemmin kuten katselijan: Claim/$decide-pyyntö, jossa on se id claimResponse-kohtana, kohdekohtainen järjestys ja päätös ja syy. Tarjoajan tilaus toimittaa sen kuten yhden, jonka on tehty katselijan jonossa.

Tilaus, jossa on id-only -sisältö, kertoo tarjoajalle, kumpi vastaus on muuttunut, ilman kertomista, mitä se on: ilmoituksen keskipiste on Bundle/<id>. GET /fhir/Bundle/<id> palauttaa viimeisimmän PAS-vastausryhmän, GET /fhir/Bundle/<id>/_history/<n> version, jonka ilmoitus lähetti, ja GET /fhir/ClaimResponse/<id> ClaimResponse-vastauksen yksin. Tokeni, joka on sitoutunut yhteen potilaaseen, kerrotaan, ettei heitä ole olemassa, kuten minkä tahansa ulkopuolisen potilaan tapauksessa.

Varmistettu virallisella Inferno PAS Server v2.2.1 -sarjalla (ks. varmistus). Ei lähetetty, vaikka PAS merkitsee niitä tukevia: ClaimResponse.adjudication tarkastus-toiminnolla, ClaimResponse.extension:authorizedProvider ja ClaimResponse.item.extension:communicatedDiagnosis, koska laajennukset, joita ne tarvitsevat, eivät ole sallittuja siellä omassa kontekstissaan PAS 2.2.1:ssä ja validatori hylkää vastauksen, joka sisältää ne; ja request.extension:DataAbsentReason, koska Perfuse aina tietää pyynnön. 278:t, jotka lähetetään käyttöjohtamisjärjestelmään (yllä), tarkistetaan PAS 2.2.1:n omien pyyntöesimerkkien, CMS:n julkaisemien esMD 278 -näytteiden ja 278-tarkistimen kautta, joka on kirjoitettu julkisista käsikirjoista, ja jokainen siirtotapa on tarkistettu CAQH:n yhteyden muodostamissääntöjen mukaisella UM-järjestelmällä (ks. varmistus); ei vielä oikeaa UM-järjestelmää tai välittäjää vastaan, eikä CORE-sertifioitu. Ei toteutettu: liitteet, jotka palautetaan CDex:llä.

Sääntötiedosto tarkistetaan CRD: n omia invariantteja vastaan, kun se ladataan: kyselylomake tarvitsee dokumentaation, palvelu, jota ei ole katettu, ei voi vaatia valtuutusta, satisfied kuuluu yhteen tapaukseen eikä sääntöön, ja kaikki ehdolliset asiat on annettava syy.

Ei varmistettu: vienti ja jäsenen vastaavuus toisen maksajan toteutukseen, mittarit maksajan julkaisemiin lukuihin ja CRD todellisen EHR: n CDS Hooks -asiakkaaseen.

16.11 Lähettää ennakkohyväksyntäpyynnöt maksajalle (palveluntarjoajille)

Kaikki edellä mainittu vastaa pyynnöksiin maksajana. Palveluntarjoajan puolella on toisin: EHR- tai DTR-sovellus luo Da Vinci PAS -pyyntöpaketin, ja jotakin on lähetettävä maksajalle, säilytettävä vastaus ja välitetty eteenpäin. pas -kohde tekee tämän.

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

Jokaisen viestin on oltava kokonainen PAS-pyyntöpaketti raakakanavalla. Perfuse lähettää sen muuttamattomana {payer}/Claim/$submit :lle: maksaja päättää korvauksesta potilaan, korvaus- ja tukevia resursseja paketissa ja korvaus uudelleenrakennettuna yhteenvetoon menettäisi ne. Tämän laitteen ulkopuolella maksajan osoitteen on oltava https.

Päätös on toimitettu pyyntö, olkoon se mitä tahansa. Hyväksyntä, hylkäys ja odottaminen kaikki merkitään ja yhtäkään niistä ei yritetä uudelleen, koska hylkäyksen uudelleenyritys toimittaa saman pyynnön kahdesti. Se, mikä epäonnistuu toimituksessa ja yritetään uudelleen, on maksaja, joka ei ole tehnyt päätöstä: virhetila, OperationOutcome (sen teksti on virhe) tai ClaimResponse, jonka tulos on error. Päätös luetaan kohde kohden PAS:n tarkastustoimien koodeista (X12 306: A1 hyväksytty, A2 osittain, A3 hylätty, A4 odottaa, A6 muutettu); vastaus, jossa ei ole koodia, luetaan "ei päätöskoodia" eikä sitä oteta hyväksymisenä. Hylkäys, jossa ei ole minkäänlaista syytä, hylätään, koska se ei täytä CMS-0057 -vaatimusta.

Maksajan vastaus on kohdekohtaisen vastauksen, joten Tarkastele vastausta voi arvioida sitä, ja results_to antaa sen toiselle kanavalle. Jokainen pyyntö on lueteltu CMS-0057, pyynnöt lähetetty maksajalle: kun se lähetettiin, potilas, palvelu, päätös ja maksajan viite (preAuthRef), jonka myöhempi tiedustelu nimeää. Luettelo säilytetään prior-auth.json -tiedostossa tietokannan vieressä (enintään 10 000 pyyntöä; vanhimmat päätetyt pyynnöt poistetaan ensin, pendattu pyyntö ei koskaan poistu); ja kunkin vuokralaisen näkyvät vain heidän omat pyynnöt.

Varmistettu HL7 Da Vinci PAS -maksajan viitekäyttöönottoon (docker-kuva hlseven/davinci-prior-auth ): pyyntö lähetetty toiminnassa olevan kanavan kautta pendataan siinä sen viitteen kanssa, ja vastaus näkyy näytöllä (ks. varmistus). Ei vielä kokeiltu tuotantomaksajaa vastaan. Ei rakennettu: pendentin pyynnön seuraaminen $inquire :lla tai maksajan myöhemmän vastauksen vastaanotto tilauksella; kanava voi tehdä molemmat tänään http - tai fhir -kohteen kanssa.

16.12 CMS -verkkoyhteydet

CMS Interoperability Framework (CMS Health Technology Ecosystem) pyytää terveydenhuollon tietoverkkoja itsearvioimaan 26 kriteeriä ja listataan CMS Aligned Networks -verkkoon; EHR: t, tarjoajat, maksajat ja sovellukset yhdistävät niihin. Kriteerit 13-16 ovat olleet voimassa 4. heinäkuuta 2026 lähtien: FHIR-rajapinnat US Core: n kanssa täydellisellä CapabilityStatementilla ja Bulk Data -ominaisuudella, asiakirjat ihmisen luettavina FHIR-liitteidenä, ajanvaraus- ja kohtaamisilmoitukset FHIR-tilauksella ja tietorekisterin sijainti.

Hallinnoi › CMS Aligned Network luetellaan jokainen kriteeri siitä, mitä Perfuse tarjoaa sille ja mihin tämä palvelin on kytketty, luettu siitä, mitä on kytketty täällä:

Neljä voimassa olevaa kriteeriä, joita tämä palvelin tarvitsee:

Näyttö on työlehti itsearviointiin, ei sertifioinnin: CMS tarkistaa verkkoja, joita epäillään ei täyttävän kriteerejä, ja kehyksen omat tekstit ovat viranomainen. Ei rakennettu tänään: avoimet laatusarakkeiden kyselyt (kriteeri 8), maksajan kysely kohtaamisdatan hakemiseksi (9), raporttikyselymittaukset Kansalliseen tarjoajarekisteriin (19), tarjoajien tarkistaminen kyseisessä hakemistossa (6), matkustajien mobiilien ajokorttien tai digitaalisten vakuutuskorttien lukeminen (3, 23) ja yleisen suostumuspolitiikan noudattaminen jokaisessa lukemisessa (5). IAL2-todennus on identiteetinpalvelun; Perfuse hyväksyy valitun identiteetin tokenit.

17 Turvallisuus

Perfuse käsittelee kliinisiä tietoja. Tämä luku kertoo, mitä se tekee niiden kanssa ja mitä se jättää tehtäväksi sinulle.

17.1 Siirtoturva

TLS on web-käyttöliittymässä määritetty -tls-cert ja -tls-key -valinnoilla. Ilman niitä käyttöliittymä on pelkkä HTTP, mikä on hyväksyttyvää silmukkaosoitteessa ensimmäistä katselua varten ja muualla - se sisältää tunnistetietoja ja viestin sisältöä, jotka molemmat ovat luettavissa langalla.

TLS-kanavien siirroilla on määriteltävä tls -lohko kunkin lähteen ja kunkin kohteen osalta. Saatavilla olevat asetukset ovat lähde - ja kohde -viittauksissa.

insecure_skip_verify hyväksyy minkä tahansa varmenne. Se on olemassa, koska sairaalajärjestelmät esittävät usein varmenteita, jotka eivät vahvista, ja yhteyden kieltäminen merkitsisi integraation kieltämistä. Se on nimetty näkyväksi, ja sen käyttäminen tarkoittaa, että yhteys on salattu, mutta ei todennettu — sinulla on suojaa passiivista kuuntelua vastaan, mutta ei väliintulija-palvelinta vastaan.

17.2 Tunnistus ja roolit

Käyttäjät ovat tietokannassa. Jokaisella on yksi viidestä roolista, ja jokainen rooli sisältää kaiken edellisten roolien sisällön:

Kuudes rooli, Alusta, kuuluu sille, joka pyörittää jaettua palvelinta: se luo vuokralaisia ja asettaa heidän rajoituksensa, ja se ei omista kanavia.

Valvonta on tarkoitettu päivystäjälle tai toiminnan näytölle seinällä: kaikki tarvittava nähdä, onko syöte loppunut, ja mitään, mikä mainitsee potilaan nimen. Katselija voi lukea viestin sisältöä, joka on kliinistä tietoa; se on matalan etuoikeuden rooli *konfiguraatiolle*, ei yksityisyydelle. Toiminnanjohtaja erottaa epäonnistuneen toimituksen korjaamisen yöllä siitä, mitä syöte tekee: henkilö, joka uudelleen lähettää, ei tarvitse pystyä uudelleenkirjoittamaan kanavaa.

17.2.1 Toistuvat väärät salasanat

Väärät salasanat ja epäonnistuneet avainnimi-kirjautumiset lasketaan osoitteen mukaan, josta yhteys tulee, ja usean peräkkäisen jälkeen tämä osoite odottaa ennen kuin se voi yrittää uudelleen (vastaus on 429, Retry-After): tilit eivät lukitse nimeä, koska se antaisi kenelle tahansa mahdollisuuden lukita ylläpitäjä tarkoituksella.

Osoite on yhteyden oma, ei koskaan se, mitä pyyntö väittää X-Forwarded-For: ssä, jonka lähettäjä kirjoittaa. Kääntävän proxyn takana samalla koneella Perfuse käyttää viimeistä X-Forwarded-For-merkintää, proxyn lisäämää, joten kunkin asiakkaan lasketaan erikseen. Toisella koneella oleva proxy tavoittaa Perfusen yhdestä osoitteesta, ja kaikki sen asiakkaat jakavat yhden laskurin: rajoita kirjautumisia proxyn kautta.

17.2.2 Kanavaryhmät

Henkilö (tai API-tunniste) voidaan rajoittaa tiettyihin kanavaryhmiin: he näkevät ja toimivat vain niillä kanavilla, joiden group on yksi heidän ryhmistään. Tämä on sairaalaryhmän järjestely yhdellä palvelimella, jossa jokaisen laitoksen analyytikot huolehtivat omista syötteistään ja keskustiimi, jolla ei ole rajoituksia, huolehtii niistä kaikista. Rhapsody kutsuu tätä lukosta.

Rajoitus koskee kaikkia samanaikaisesti, koska se on sovellettavissa pyynnölle eikä muisteta kunkin näytön mukaan: kanavaluetteloa, kojua, virtauskarttaa, viestejä ja niiden hakua, laskelmia ja kaavioita, jonot, hälytykset, mittarit, todistukset, sopimukset ja koodauskäytön. Kanava, joka ei ole henkilön ryhmissä, ei ole olemassa heille; pyytäminen sen nimeä vastaa *ei löydy*, joten sen nimeä ei vahvisteta. Kanava, jolla ei ole ryhmää, nähdään vain henkilöillä, joilla ei ole rajoitusta.

Kanavan tallentaminen pitää sen henkilön ryhmissä: he eivät voi luoda kanavaa toiseen ryhmään tai siirtää sitä omasta ryhmästään. Mitä jokainen laitos jakaa - kooditaulukot, skriptikirjastot, etukäteen hyväksyttyjä päätöksiä - he voivat lukea, mutta eivät muuttaa. Palvelimen laajuiset luvut (etukäteen hyväksytty, tokenin käyttö, tunnelit) näytetään vain henkilöille, joilla ei ole rajoitusta, ja niin ovat mittarit ja hälytykset koko palvelimesta eikä kanavasta.

Rajoitettu hallinnoija on laitoksen oma hallinnoija. He hallinnoivat ihmisiä ja tokenia omista ryhmistään, käynnistävät ja lopettavat kanavansa ja tyhjentävät jononsa. Heidän lisäämänsä kollega saa heidän ryhmänsä, ellei he mainitse niitä, he eivät voi antaa ryhmää, jota he eivät omista, ja he eivät näe tai muuta ketään, jolla ei ole rajoitusta. Kaikki muu, minkä hallinnoija voi tehdä, muuttaa koko palvelinta - asetukset, kirjautuminen, uudelleenkäynnistys, hälytysäännöt, brändäys, laivasto, SMART-palvelin - ja se evätetään heiltä.

Ryhmät määritellään Käyttäjissä (ja tokenien kohdalla Tokeneissa), pilkulla erotettuna luettelona. Jokainen muutos kirjataan toimintalokiin ja tulee voimaan henkilön seuraavassa pyynnössä.

Eri rooli kussakin ryhmässä

Henkilö voi olla eri roolissa kussakin ryhmässään: lab=editor, adt Käyttäjät-osiossa muokkaa laboratorion kanavia ja on valittu rooli - esimerkiksi viewer - sairaaloiden ryhmissä. He näkevät molempien ryhmien kanavat jokaisella näytöllä. Tallentaminen, käynnistäminen tai uudelleenlähettäminen ryhmässä, jossa heidän roolinsa on liian alhainen, evätään heidän roolinsa perusteella; se ei tee näytön puuttuvaksi, koska he voivat nähdä sen. Heidän roolinsa näytön yläreunassa on vahvin, jonka heillä on, joka avaa näytöt, joita roolia käytetään, ja jokainen toiminto näillä näytöillä on edelleen rajoitettu ryhmiin, joissa heillä on se.

Vain ihmiset, jotka ovat rajoitettu kanavaryhmiin, voivat olla niissä. Joku, joka näkee jokaisen kanavan, on yksi rooli, koska "laboratorion kanavien muokkaaja" henkilölle, jolla ei ole rajoitusta, olisi muokkaaja kaikista, jotka eivät kuulu mihinkään ryhmään, ja palvelimen laajuisilla sivuilla. Laitoksen ylläpitäjä voi antaa roolin ryhmässä vain ryhmissä, joita he hallinnoivat, ja koskaan heidän oman roolinsa yläpuolella.

17.3 Kuka voi soittaa FHIR-päätepistettä

FHIR-päätepiste (serve -fhir) tarkistaa yhden kahdesta tunnistetyypistä:

• Perfuse API -tokenit, jotka tehdään Käyttäjät → Konemerkinnät tai perfuse token create -komennolla. Jokainen kantaa roolin ja voidaan rajoittaa FHIR-ryhmiin. Tämä on oletus, kun SMART -valtuutuspalvelin ei ole määritetty.
• SMART -pääsytokensit, Perfusen omasta valtuutuspalvelimesta (-smart-clients) tai ulkopuolelta (-smart-issuer). Jokainen kantaa laajuudet, ja päätepiste pitää jokaisen pyynnön niille.

Kun SMART on määritetty, vain SMART -tokenit hyväksytään, joten jokainen soittaja on sitoutunut niiden laajuuteen. API -tokenilla on rooli ja ei laajuutta: viewer -tokeni voi lukea jokaisen potilaan tiedot. Maksaja, joka käytti SMARTia rajoittaakseen jokaisen sovelluksen siihen, mitä sille on myönnetty, ei pitäisi olla pääsy, joka ei ole rajoitettu.

Jotkut sivustot tarvitsevat molempia - sisäisen korvausvirran, joka pitää API -tokenia ja ei ole SMART -asiakas, rinnalla sovelluksia, jotka kirjaavat sisään SMARTin kautta. Niille Asetukset → FHIR → Hyväksy Perfuse API -tokenit SMART -tokenien rinnalla (-fhir-api-tokens käynnistysajassa) sallii API -tokenit myös. Se on pois päältä oletuksena, se tulee voimaan seuraavassa pyynnössä kummassakin suunnassa, ja muutoksen tekeminen kirjataan auditilokiin. Tokeni voidaan erottaa muodosta: SMART -tokeni on allekirjoitettu JWT, ja API -tokeni ei koskaan ole, joten yhtä ei koskaan tarkisteta toisena. Missä voit, anna tällaiselle järjestelmälle SMART -taustapalveluasiakas, jolla on vain ne laajuudet, joita se tarvitsee.

17.3.1 FHIR-päätepiste, joka on avoinna muille

Julkinen testipalvelin antaa tunnistetietoja, jotka voivat kirjoittaa, koska aiemman valtuutuksen testaaminen tai tilaukset vaativat kirjoittamista. Kaksi rajoitusta estää yhden asiakkaan pilaa sen kaikille, molemmat Asetukset → FHIR -osiossa ja molemmat pois päältä oletuksena:

• Kirjoittaa minuutissa yhdestä asiakkaasta (-fhir-writes-per-minute): luo, päivittää ja poistaa yhdestä asiakasosoitteesta. Ylittäessä kirjoitus vastataan 429 ja Retry-After: 60. Lukemiset ja haut, myös POST-haut, eivät koskaan lasketa.
• Enimmillään pidettävät resurssit (-fhir-max-resources): ylittäessä uudet resurssit evätään 507-koodilla, kun taas päivitykset ja poistot toimivat edelleen.

Sairaalan oma päätepiste ei tarvitse kumpaakaan.

17.4 Sairaalan oma päätepiste ei tarvitse kumpaakaan.

Käyttämällä Asetukset › Turvallisuus › Tekoälyagentit (MCP) (tai serve -mcp), Perfuse tarjoaa Model Context Protocolin osoitteessa /mcp, jotta tekoälyagentti, kuten Claude, ChatGPT tai IDE-avustaja, voi kysyä siitä, mitä tapahtuu. Oletuksena se on pois päältä, ja sen poistaminen lopettaa jokaisen agentin seuraavalla kutsulla.

Välikäsittäjä muodostaa yhteyden Hallinta › Käyttäjät › Konetunnisteet -API-tunnuksella kuin kantaja-tunnuksena, ei koskaan henkilön selainistunnussa (jota ei hyväksytä, joten välikäsittäjä ei koskaan toimi henkilön koko pääsyoikeuden kanssa). Asiakasasetus näyttää tältä:

{ "mcpServers": { "perfuse": { "type": "http", "url": "https://perfuse.example/mcp",
    "headers": { "Authorization": "Bearer <token>" } } } }

Jokainen työkalu vastaa samalla reitillä tai FHIR-haulla, jota henkilön näyttö käyttää, ja sitä kutsutaan agentin omalla tunnisteella, joten tunnisteiden rooli, kanavaryhmät ja vuokraaja päättävät, mitä se näkee, täsmälleen kuten ne tekevät konsoleissa; ja fhir_search hankkii tunnisteiden oman pääsyn FHIR-päätepisteessä (joka voi kieltää API-tunnisteet kokonaan; ks. yllä oleva FHIR-osio). Agentille tarjotaan vain työkalut, joita sen tunniste voi käyttää. Oletuksena on lukeminen: työkalu, joka muuttaa jotain, tarvitsee myös tunnisteiden mcp:write -laajuuden ("Anna tekoälyagentin toimia sen kanssa", kun tunniste voidaan myöntää), joten raportointiagentille myönnetty tunniste ei voida saada toimimaan ohjelmoinnin kautta. Valvontatunnisteen vastauksissa poistetaan viestin sisällöt, riippumatta siitä, mitä reitti palauttaa.

Jokainen kutsu on Toiminta-loossa mcp.tool-merkinnössä, jossa on tokenin nimi, työkalu, sen argumentit ja tulos (ok, refused, invalid, rate-limited tai HTTP-tilakoodi); mcp.connect merkitsee, mikä asiakas on yhdistetty. Jokainen token voi tehdä 60 työkalukutsua minuutissa (Työkalukutsut minuutissa yhdestä tokenista); ylittäessä kutsuun vastataan virheellä, jonka agentti voi lukea, eikä mitään tehdä. Pyynnöstä selainikkunasta toisesta alkuperästä kieltäydytään, mikä MCP pyytää palvelinta lopettamaan DNS-uudelleenmäärityksen. Siirto on MCP:n Streamable HTTP, johon vastataan JSON-muodossa ilman tapahtumavirrää; hyväksytään protokollaversiot 2025-06-18, 2025-03-26 ja 2024-11-05. Viestit ja FHIR-resurssit sisältävät potilastietoja: agentin vastaukset menevät sille mallille, jota se ajaa, joten anna tokeni agentille vain siinä tapauksessa, että malli on sallittu nähdä ne, ja anna sille alin rooli, joka tekee työn.

17.5 | --- | --- | --- |

serve -demo-account demo:PASSWORD luo jaetun tilin julkiselle esittelypalvelimelle, ja kirjautumissivu näyttää käyttäjänimen ja salasanan painikkeen, joka kirjautuu sisään niiden avulla. Tili on katselija, joten se voi tarkastella kaikkea ja muuttaa mitään. Toisin kuin mikä tahansa muu katselija, se voi myös avata järjestelmänvalvojien näytöt (käyttäjät, koneen tunnukset, asetukset, tietosuojelu, laivueen vertaiset), vain luku -muodossa: esittely arvioidaan sen näytöistä. Se lukee niitä katselijan kanavien tavoin, jokainen tunniste näytetään asetettuna tai ei, koskaan sen arvoa, ja jokainen muutos hylätään. Se voi myös painaa tarkistuksia, jotka eivät muuta mitään ja eivät pääse ulos palvelimesta: skriptin tarkistus ja kanavaeditorin validointi ja parsiminen. Se ei voi muuttaa salasanaansa tai lisätä avainparia, koska ensimmäinen vierailija, joka tekee sen, lukitsee kaikki muut sen jälkeen. Kunkin käynnin aikana se palautuu katselijaksi julkaistulla salasanalla. Salasanan on oltava vähintään 12 merkkiä pitkä, kuten muillakin. Käytä sitä vain testitietojen sisältävällä palvelimella: kuka tahansa, joka lukee kirjautumissivun, voi lukea jokaisen viestin palvelimella.

17.6 Tarkastus

Konfiguraatiomuutokset, kirjautumiset ja pääsy viestisisällön ovat tallennettu, jossa on mukana kuka, mitä ja milloin.

Tarkastusloki on samassa tietokannassa kuin viestit. Se on kätevää, mutta se on myös rajoitus: joku, joka voi muuttaa tietokantaa, voi muuttaa tarkastuslokin. Jos vaatimukset sisältävät väärentämisen esto, loki tarvitsee lähetyksen jonnekin, jossa se on vain lisättävissä, ja Perfusen oma loki on tapa tehdä se.

17.7 Salaisuudet konfiguraatiossa

Salasanat, salakoodit ja avaimet näkyvät kanavan konfiguraatiossa, mikä tarkoittaa, että ne ovat YAML-tiedostoissa.

Kaksi seurausta. Tiedostojen on oltava tiedostojärjestelmän käyttöoikeudet, jotka heijastavat niiden sisältöä, ja jos ne ovat versiohallinnassa — mikä on muuten suositeltavaa — repositio sisältää tunnistetiedot ja on käsiteltävä sen mukaisesti.

Kun arvo on salaisuus, käyttöliittymä näyttää sen salaisuutena ja API ei palauta sitä tallennuksen jälkeen. Se suojaa sitä siitä, että se luetaan jonkun olkapään yli tai vuotaa näyttökuvaan. Se ei suojaa tiedostoa.

17.8 Mitä on tietokannassa

Viestivarasto sisältää viestit sellaisenaan, mitä ne on vastaanotettu, mikä tarkoittaa kliinistä syötettä. Se on oltava salatulla tallennuksella, varmuuskopioitava kliinisen tiedon kanssa, joka merkitsee sen säilyttämistä, ja pääsy on ohjattava tiedostojärjestelmän tasolla sekä Perfuse-omien roolien kautta.

cleanup.periodDays rajoittaa, kuinka kauan niitä säilytetään. Katso viestivarasto jännitystä sen ja riittävän historian välillä, joka on tietoinen rytmistä hälytyksestä.

17.9 Tietosuojelu (GDPR ja UK GDPR)

Tietosuojan näyttö (Hallinnoi, ainoastaan hallinnoitsijoille) vastaa henkilön pyynnöille GDPR:n ja UK GDPR:n mukaisesti. Se ei tee päätöksiä valvontaviranomaisen puolesta: onko pyyntö hyväksyttävä ja onko poikkeus sovellettavissa, on valvontaviranomaisen päätös, joka tallennetaan pyynnön kanssa.

Mikä on tallennettu. Henkilö on nimetty tunnisteilla: system|value (NHS-numero, MRN sen myöntävällä viranomaisella) tai numero yksin. Potilasindeksin kanssa nämä laajenevat jokaisen rekisterin jokaiseen numeroon, joka on linkitetty samaan henkilöön, joten pyynnössä, joka mainitsee sairaalnummeron, löytyvät muissa rekistereissä olevat tiedot. Näe, mitä on tallennettu etsii kaikki tallennukset, jotka sisältävät potilastietoja:

Mikä siihen ei ylety, siitä se sanoo: jäljet lähetetään kerääjälle (-trace-endpoint), audit-lokiin (se säilytetään: se on kirjaus kuka teki mitä, mukaan lukien tämä pyyntö), ja varmuuskopioihin.

Pyynnöt. Pyyntö tallennetaan pyynnön tyypin (pääsy, 15 artikla; siirrettävyys, 20 artikla; poistaminen, 17 artikla; rajoitus, 18 artikla), pyynnön lähettäjän, tunnisteiden ja huomautuksen (tunnistamistapa, laajennus ja syy) kanssa. Se on määräaikainen kuukauden kuluttua vastaanotosta (12(3) artikla); myöhässä oleva pyyntö näytetään punaisella.

• Pääsy ja siirrettävyys: Lataa kopiointi antaa zip-tiedoston: jokainen viesti vastaanotettuna tallenteineen, jokainen FHIR-resurssi jokaisella tallennetulla versiolla, aiemmat valtuutuspyynnöt ja niiden vastaukset, sekä potilasindeksin tiedot, JSON-muodossa, README-tiedoston kanssa, joka kertoo, mitä kunkin osan on. Merkitse vastatukseksi sulkee sen.
• Poistaminen: toinen hallinnoitsija hyväksyy sen (se, joka tallensi sen, ei voi).

Poista nyt poistaa kaiken löydetyt tiedot: viestit kokonaisuudessaan (tallenne, runko, toimitukset, tunnisteet, liitteet, joita ei käytetä muiden viestien kanssa), jonotut toimitukset (niitä ei lähetetä), FHIR-resurssit niiden historiallisine versioineen, aiemmat valtuutuspyynnöt ja niiden vastaukset, liitteet ja seurant-numerot, sekä henkilö potilasindeksistä jokaisine linkitetyine tietoineen ja historiallisine versioineen (yksi tapahtuma merkitsee, että poistaminen on tapahtunut, ja kuka on tehnyt sen).

• Rajoitus: tallennetaan lailliseksi pidätykseksi, joten mitään ei poisteta tai vanhene, kunnes se on voimassa.
• Hylkää sulkee pyynnön syytä, jonka henkilön on kerrottava.

Suljettu pyyntö säilyttää ainoastaan henkilön numeroiden viimeiset merkit: se säilyy vastauksen merkkinnänä ilman, että se on toinen kappale niistä. Jokainen vaihe on audit-lokissa numeroiden maskien kanssa.

Lailliset pidätykset. Pidätyksen nimi on henkilöllä tunnisteilla, sen syyn ja vapaaehtoisen päättymispäivämäärän kanssa. Kun se on voimassa, poistaminen hylätään suoraan, ja viestivaraston säilytysikkuna säästää henkilön viestit (tallenteet ja rungot) kunnes pidätyksestä luoputaan.

Varmuuskopiot ja poistamisloki. Ennen poistamista tehty varmuuskopio sisältää edelleen poistetut tiedot, kunnes se vanhenee. Jokainen poistaminen kirjataan lokitiedostoon: milloin, kuka, kuka hyväksyi sen, paljonko kussakin tallennuspaikassa poistettiin, ja henkilön tunnisteet suolattuina SHA-256-hašina eikä selkeästi. Varmuuskopion palauttamisen jälkeen Sovella poistamisia uudelleen hašaa palautettujen tallennusten tunnisteet kunkin kirjauskohdan suolan kanssa ja poistaa jokaisen henkilön, jonka lokitiedosto mainitsee. Lyhyet numerot voidaan löytää niiden hašien avulla kokeilemalla jokaista arvoa, joten lokitiedosto on itsessään henkilötietoja ja säilytetään tietokannan omalla suojauksella.

Säilytys. Näyttö listaa, kuinka kauan kunkin tietotyyppi säilytetään täällä ja mitä muutoksia se saa: viestitallenteet ja -rungot niiden säilytysikkunoiden mukaan, jonotusjonossa kunnes toimitetaan tai poistetaan, FHIR-tallennus, aiemmat valtuutuspyynnöt ja potilasindeksi kunnes ne poistetaan (kliiniset tiedot eivät poisteta aikataulun mukaan), audit-loki säilytetään.

Käsittelyrekisteri (30 artikla). Käsittelyrekisteri lataa Markdown- tai CSV-muodossa, mitä tämä palvelin tietää siitä: valvontaviranomainen, tietosuojavastaava ja missä tiedot säilytetään (Asetukset → Tiedot → Tietosuojelu), kunkin tietotyyppiin liittyvä säilytys, ja yksi käsittelytoiminto kunkin kanavan kohdalla, mitä se vastaanottaa, mistä se tulee, mihin kohteisiin se lähetetään, ja mihin isäntiin se lähetetään. Tarkoitukset, lailliset perusteet ja tietosuojan kohteet jätetään valvontaviranomaisen täyttämiksi, ja niistä kerrotaan. CSV-solu, joka alkaa =, +, - tai @ -merkillä, kirjoitetaan johtavalla apostrofin kanssa, jotta taulukkolaskentaohjelma ei suorita sitä.

Missä tiedot säilytetään. Missä tiedot säilytetään (Asetukset → Tiedot → Tietosuojelu) ilmoittaa sanoissa, joita valvoja voi tarkastaa, missä palvelin, sen tietokanta ja varmuuskopiot sijaitsevat; Tietosuojelu-näyttö ja käsittelyrekisteri näyttävät sen. Luonnos tietosuojasopimukseksi organisaatioille, joita BioDream isännöi, on docs/legal/dpa-template.md -tiedostossa; se on luonnos lakimiehelle, ei lakineuvontaa.

Rajapinta on /api/privacy (yhteenveto), /api/privacy/find, /api/privacy/requests (ja /{id}/approve, /{id}/export, /{id}/erase, /{id}/close), /api/privacy/holds, /api/privacy/reapply ja /api/privacy/register.

17.10 Vuokralaiset

Virtuaalipalvelin on eristysraja: kanavat, viestit, käyttäjät ja asetukset kuuluvat yhteen, eikä mitään ylitä sitä.

Tämä on olemassa palveluntarjoajalle, joka suorittaa useiden praktiikkojen syötteitä. Älä käytä sitä erottamaan osastoja yhden organisaation sisällä, jotka tarvitsevat toistensa liikenteen näkemistä: eristys on todellista, eikä ole minkäänlaista yleiskatsausta asiakkaan välillä. Sen sijaan käytä kanavaryhmiä (yllä), jotka jakavat yhden organisaation henkilöstöä, kun taas keskitiimi näkee kaiken.

17.10.1 Rajoitukset

Alustan operaattori asettaa kunkin asiakkaan rajoitukset Asiakkaissa, jotta yksi asiakas ei voi syrjäyttää muuta jaettua palvelimen osaa. Jätä raja tyhjäksi, jos sitä ei ole.

• Kanavat: montako kanavaa vuokralainen voi hallita. Yhden kanavan lisääminen epäonnistuu, ja palautetaan kanavien lukumäärä ja raja.
• Viestit minuutissa: montako viestiä kanavat yhdessä voivat vastaanottaa minuutissa.
• Tallennus: kuinka paljon tallennettua viestisisältöä se voi pitää tallessa megatavuina.

Yksikään niistä ei menetä viestiä. Ylittäessäsi siirtomäärän tai tallennustilaa, vastaanotettu viesti hylätään samalla tavalla kuin kiireinen vastaanottaja hylkäisi sen, ennen kuin mitään tallennetaan tai toimitetaan: MLLP ei saa vahvistusta (ei hylkäystä, jota jotkut lähettäjät pitävät "älä lähetä uudelleen"-merkkinä), HTTP saa 429 ja Retry-After-merkinnän, SOAP saa 503, DICOM saa uudelleenyritystilanteen, ja jono, bucket tai tiedosto jätetään siihen, mihin se oli. Lähettäjä lähettää uudelleen, kuten jokainen rajapintamoottori ja EHR tekee. Mitään jo tallennettua ei poisteta, jotta tilaa vapautuu. Korotettu raja astuu voimaan minuutin kuluessa, ja jokainen rajojen muutos tallennetaan toimintalokiin.

17.11 Testitiedot

Luodut viestit, jotka on kuvattu kohdassa testing, ovat osittain olemassa yksityisyydensuojana. Jonkin ongelman toistaminen muualla, esimerkin lähettäminen valmistajalle tai testiympäristön täyttäminen ovat kaikki asioita, jotka muuten tehdään oikeilla viesteillä.

Generaattorin tuotos ei sisällä potilastietoja rakenteen vuoksi eikä sensuroinnin vuoksi. Suosittelemme sitä käytettäväksi käsin poistettujen oikeiden viestien sijaan, joka on prosessi, joka voidaan tehdä epätäydellisesti ja yleensä tehdään.

17.12 Yksinkertainen kirjautuminen

Kolme mekanismia ja paikalliset tilit niiden rinnalla.

OpenID Connect (-oidc), hakemisto LDAP:n yli (-ldap) ja SAML 2.0 (-saml). Kukin niistä konfiguroidaan Hallinnoi → Kirjautuminen -näytöltä ja kirjoitetaan tiedostoon, jonka liput nimeävät, joten näyttö ja tiedosto ovat kaksi näkymää samasta asiasta eikä kaksi paikkaa, joita on pidettävä yhdenmukaisina.

Paikalliset tilit ovat aina käytettävissä eivätkä ne voida poistaa käytöstä. Se on tietoisesti tehty: paikallinen liitäntämoottori, jonka ainoa tapa sisään on identiteettipalveluntarjoaja, tulee saavuttamattomaksi juuri silloin, kun identiteettipalveluntarjoaja on saavuttamaton, eikä kliininen liitäntä ole hyvä paikka oppia siitä. Kirjautumisnäyttö kertoo, montako paikallista ylläpitäjää on ennen kuin se kehottaa sinua luottamaan muihin.

17.12.1 Mihin ryhmän määritys päättää

Kaikki kolme kartuttaa ryhmiä hakemistosta Perfuse-rooleihin, ja joku, joka on useamman kuin yhden ryhmän jäsen, saa etuoikeutetuin roolin. Se on ainoa turvallinen suunta, jossa se voidaan ratkaista — vaihtoehto on henkilö, joka menettää pääsyn, jota hän on oikeutettu saamaan, koska hän on myös alempiarvoisessa ryhmässä.

Mihin tahansa kuudesta roolista voidaan myöntää: seuranta, katselu, operaattori, muokkaaja, ylläpitäjä ja alusta.

Ryhmä voidaan myös rajoittaa joillekin kanavaryhmille toisessa ruudussa (channel_groups tiedostossa). Kun ryhmä mainitsee jotain, jokainen kirjautuminen asettaa henkilön kanavaryhmät niistä ryhmistä, jotka myöntävät heidän roolinsa: joku, joka kuuluu ryhmään, joka muokkaa laboratorion kanavia, ja toiseen ryhmään, joka näkee jokaisen kanavan, on laboratorion kanavien muokkaaja ja mitään muuta. Voimakkain rooli ei koskaan yhdistetä laajimpaan ulottuvuuteen, koska mikään ryhmä ei myönnä sitä. Ryhmä, jolla on tyhjä ruutu, antaa jokaisen kanavan. Kun mikään ryhmä ei mainitse mitään, kirjautuminen jättää kanavaryhmät sellaisiksi, kuin ylläpitäjä on asettanut Käyttäjissä.

Kun jokainen ryhmä, johon henkilö kuuluu, mainitsee kanavaryhmät, kunkin kanavaryhmän saa voimakkain rooli niistä ryhmistä, jotka mainitsevat sitä: Lab-Interfaces (muokkaaja, laboratorio) ja Clinical-IT (näkijä, laboratorio ja adt), henkilö muokkaa laboratorion kanavia ja näkee adt-kanavat, niin kuin ne olisivat asetettu käsin. Kun yksi heidän ryhmistään antaa jokaisen kanavan, ei ole listaa, joka pitäisi roolia kunkin ryhmän mukaan, ja yllä mainittu sääntö pätee.

roles:
  editor: [Lab-Interfaces]
  operator: [Night-Desk]
  viewer: [Clinical-IT]
  channel_groups:
    Lab-Interfaces: [lab, pathology]
    Night-Desk: [adt]

Tuo on OpenID Connect- ja SAML-tiedosto. Hakemiston tiedosto kartoittaa kunkin ryhmän yhteen rooliin (roles: {Lab-Interfaces: editor}), ja channel_groups on roles-kentän vieressä.

Karttamuoto, joka ei anna kenellekään mitään, hylätään sen sijaan, että se tallennettaisiin. Konfiguraatio, joka todentaa ihmisiä ja estää heidän pääsynsä, näyttää ulkoisesti samalta kuin rikkinäinen tuote: pyyntö ja vastaus kulkevat läpi, ja kaikki evätetään ilman selitystä, miksi.

Tilin luominen ensimmäisellä kirjautumiskerralla on oletuksena pois päältä. Kun se on pois, joku on olemassa Perfusessa ennen kuin he voivat kirjautua sisään, joten hakemisto päättää, kuka he ovat, ja Perfuse päättää, kuka on sallittu.

17.12.2 SAML, nimenomaan

Osat, jotka on hyvä tietää ennen kuin konfiguroit sitä:

• Vain konfiguroimasi varmenne on luotettava. Varmenne, joka on sisällytetty vastaukseen, ei koskaan käytetä. Hyökkääjä, joka voi lähettää asiakirjan, voi myös lisätä oman varmennettaan siihen, ja tarkistaja, joka lukee sen, on kuka tahansa, joka voi todentaa itsensä keneksi tahansa.
• Vastauksen on vastattava tähän palvelimeen lähetettyä kirjautumispyyntöä. Perfuse muistaa pyynnön, jonka se lähetti, ja hylkää vastauksen, joka nimeää jotain muuta tai jotain, mihin se on jo vastannut. Ilman tätä tarkistusta voimassa oleva vastaus on kantaja-tunniste kenelle tahansa, joka sitä hallitsee: joku kirjautuu sisään itsensä nimissä, pitää vastauksen ja lähettää sen selaimellesi, ja sinä olet sitten heidän tilillään, ja tapahtumaloki merkitsee heidän nimensä.
• Kirjautumiset, jotka aloitetaan tunnistepalvelussa, ovat siis oletuksena pois päältä. Käytä *Hyväksy kirjautumiset, jotka aloitetaan tunnistepalvelussa* vain, jos tarvitset portal-ruutua, ja tiedä, että se on se, mikä tekee edellä mainitun mahdolliseksi.
• Ryhmäattribuutilla ei ole oletusarvoa, ja se on vaadittu. Entra lähettää groups, Okta lähettää sovelluksen määrittelyn mukaisen arvon, ADFS lähettää claim-URIn. Arvauksella saataisiin kirjautuminen, joka toimii ja ei anna kenellekään mitään. Jos kirjautuminen hylätään roolin puutteen vuoksi, palvelimen lokitiedot nimeävät attribuutit, jotka saapuivat — mikä on yleensä koko vastaus.
• Vastaus-URL on oltava täsmälleen sama kuin mitä on rekisteröity palveluntarjoajalle. Vastaus kertoo, mihin se oli tarkoitettu, ja vastaus, joka on osoitettu toisaalle, hylätään, koska sen hyväksyminen merkitsisi toisen palvelun vastauksen hyväksymistä.

17.12.3 Kunkin palveluntarjoajan lähettämät tiedot

Ryhmäattribuutti on se, missä kirjautumiset menevät pieleen, ja kolme yleisintä palveluntarjoajaa nimeävät sen eri tavoin.

Claim-URI voidaan syöttää sen viimeisen segmentin kautta: kirjoittamalla groups löytyy http://schemas.microsoft.com/ws/2008/06/identity/claims/groups. Nimi, joka päättyy vain sanaan, ei vastaa — excluded_groups ei ole groups.

Ryhmän jäsenyys, joka saapuu yhtenä pilkuin erotettuna arvona, kohdellaan yhtenä ryhmän nimenä ja ei vastaa mitään. Tämä on oikea tulkinta standardista, ja pilkun käyttäminen ryhmän erottimena merkitsisi, että ryhmä, joka laillisesti sisältää yhden, muuttuu hiljaisesti kahteen. Jos palveluntarjoajasi lähettää sen, muuta sitä palveluntarjoajassa.

Testaa kirjautumisnäytöllä tarkistaa kaikki, mitä voidaan tarkistaa ilman henkilöä: asetukset, varmenne ja se, voidaanko kirjautumispyyntö luoda. Se sanoo suoraan, ettei se voi todistaa, että joku voi kirjautua sisään, koska siihen tarvitaan todellinen vakuutus todellisesta henkilöstä, ja ainoa tapa saada se on antaa heidän yrittää.

17.13 Tunnistepalvelun tarjoamat tilit: SCIM

Valitsemalla -scim (Asetukset → Kirjaudu sisään → Automaattiset tilit), identiteettipalveluntarjoaja, kuten Okta, Microsoft Entra ID tai Google Workspace, luo, päivittää ja poistaa Perfuse-tilit itse osoitteessa /scim/v2/Users, joten henkilö, joka poistuu organisaatiosta, menettää pääsyn, kun hänen hakemistotilinsä on poistettu, eikä kun joku muista. Tarjoaja todentaa API-tunnuksella, joka sisältää admin-roolin, luodaan Käyttäjät → Konetunnisteet-kohdassa ja lähetetään bearer-tunnuksena.

• Tilin poistaminen lopettaa istunnot välittömästi, ja palvelin tarkistaa, ettei yksikään istunto selvinnyt ennen vastaamista. Palveluntarjoajalle ei koskaan kerrota, että tili on poistettu, jos sitä ei ollut, koska palveluntarjoaja ei yritä uudelleen mitä on kerrottu onnistuneen.
• Poistaminen poistaa ensin ja sitten poistaa, joten epäonnistuminen puolivälissä jättää tilin, johon kukaan ei voi kirjautua. Poistetun tilin audit-historia säilytetään.
• Rooli tulee henkilön ryhmistä tai rooleista, jotka vastaavat nimeä: ryhmä, jonka nimi sisältää *admin*, *editor*, *operator*, *viewer* (tai *read-only*) tai *monitor*, antaa kyseisen roolin, joten APP-Perfuse-Editor ja Perfuse Operators toimivat niiden nimien mukaan. Kaikki muu saa -scim-default-role, eli viewer, jollei ole asetettu toisin. Alustan roolia ei voida myöntää tällä tavoin.
• Ei salasanoja. SCIM:in kautta tehty tili kirjautuu sisään identiteettipalvelun kautta; toinen salasana, jota kukaan ylempänä ei tiedä, selviäisi poistamisesta.
• /scim/v2/ServiceProviderConfig kertoo, mitä tuetaan: Käyttäjien luominen, lukeminen, korvaaminen, muokkaaminen ja poistaminen, sekä suodattimet jopa 200 tulokseen. Joukkotoiminnot, lajittelu ja ETagit eivät ole käytössä.

17.14 Mitä Perfuse ei tee

Se ei salaa tietokantaa levossa. Käytä tiedostojärjestelmän tai asemaverkkotallennuksen salausta.

Se ei hallitse omia varmenteitaan tai uusia niitä. Osoita se tiedostoihin ja hallitse näitä tiedostoja jo olemassa olevilla työkaluilla.

SAML on verifioitu kahden riippumattoman tarjoajan kanssa, joilla on todellinen selainkirjautuminen, todellinen väittämä ja todellinen istunto: Keycloak 26 ja Microsoft Entra. Kaksi asiaa on enemmän kuin kaksi kertaa yksi, koska nämä kaksi eroavat tavalla, joka osoittautui kuormittavaksi — Keycloak kirjoittaa väittämänsä nimirajauksilla ja Entra kirjoittaa samat alueet ilman niitä, ja yksi vika, joka tässä alueella on ollut, on ollut etuliitteen käsittelyssä.

Aloita lukemalla palveluntarjoajan metatietoja. Asetukset, sitten Kirjaudu sisään, sitten SAML-välilehti: anna metatietojen URL-osoite tai liitä asiakirja, ja kirjautumisosoite ja allekirjoitusvarmenne täytetään automaattisesti. Jokainen SAML-palveluntarjoaja julkaisee yhden näistä — Okta, Entra, AWS IAM Identity Center, Keycloak, ADFS — ja se on ero konfiguroinnin ja kopioidun konfiguraation välillä. Tekeminen käsin tarkoittaa varmenne etsimistä XML-tiedostosta, rivien poistamista base64:stä ja käärimistä PEM-otsikkeisiin, jossa yksittäinen virheellinen välilyönti tuottaa allekirjoitusvirheen, joka ei kerro mitään muodosta.

Mitä takaisin tulee, kuvaillaan kuin dumppaamalla: kunkin varmenne aihe, vanhenemispäivämäärä ja SHA-256-sormenjälki, jotta voit tarkistaa sen palveluntarjoajan oman hallintapaneelin näytön kanssa. Vanhentunut varmenne kutsutaan vanhentuneeksi eikä jätetä vertailtavaksi päivämääräksi. Mitään ei tallenneta lukemalla — soveltaminen lomakkeeseen on erillinen napsautus, koska asiakirja, jonka joku liittää, ei ole vielä päätös siitä, mitä luottaa.

Metatietojen URL-osoite haetaan vain https:llä, ja osoite tarkistetaan samalla käytännöllä, joka ohjaa kanavakohteita, joten tätä ei voida käyttää palvelimen lukemiseen pilviviestintätunnuksista. Uudelleenohjauksia ei seurata, koska sallittu osoite, joka uudelleenohjaa estettyyn, kulkee suoraan ohi tämän tarkistuksen.

Jos konfiguroit Entraa, viisi asiaa eivät vastaa esimerkkejä. Se ei lähetä sähköpostiväittämää lainkaan. Sen NameID on läpinäkymätön tunniste eikä osoite. Se ei lähetä ryhmäväittämää, ellei sovellus ole nimenomaisesti konfiguroitu lähettämään sitä, joten roolikartta, joka on kirjoitettu ryhmien perusteella, hylkää jokaisen kirjautumisen. Kun ryhmät lähetetään, ne ovat objekti-GUID:t eikä nimiä, ellei vuokralaisen tila synkronoida paikallisesta Active Directorysta. Ja sen väittämän nimet elävät schemas.microsoft.com/identity -alihakemistossa, missä suurin osa asiakirjoista näytää schemas.xmlsoap.org. Perfuse käsittelee kaikki viisi; ne on lueteltu, koska neljä ensimmäistä näyttäytyvät muutoin virheiltä Perfusessa, kun ne ovat Entraa olemassa.

Ero ei ole teoreettinen tässä. Ensimmäinen aito Keycloak-väittämä epäonnistui suoraan, koska allekirjoituksen kattama kanoninen muoto laskettiin nimirajauksia pudottamalla. Mikään todellinen tunnistepalvelu ei olisi voinut allekirjoittaa ketään, ja paketin omat viisi kanonisen muodon testit menivät läpi koko ajan — kunkin heistä allekirjoitettiin ja vahvistettiin samalla koodilla, joten ne osoittivat vain, että se oli samaa mieltä itsensä kanssa. Jos olet ensimmäinen, joka osoittaa toisen tarjoajan tähän, odota löytäväsi jotain, ja palvelimen lokitila nimeää vaiheen, joka epäonnistui.

18 Toiminnot

18.1 Käyttöönotto

Yksi binääri ja kaksi polkua: kanavatiedostojen hakemisto ja tietokantatiedosto. Sovelluspalvelinta, erillistä web-tasoa tai viestinvälittäjää ei vaadita.

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

Suorita se isännän palvelunvalvontatyökalulla — systemd, launchd, konttien suorittamistyökalu. Se odottaa uudelleenkäynnistystä, jos se lopettaa.

18.2 Mihin data voi mennä (datan sijainti)

serve -residency (Asetukset → Data → Mihin dataa saa lähettää) määrittää pilvipalvelun alueet, joille tämän palvelimen dataa voidaan lähettää tai lukea: alueet (eea, uk, ch) ja aluekoodit (eu-central-1, uksouth, europe-west2), pilkuin eroteltuina. eea on AWS-, Azure- ja Google Cloud -pilvipalvelujen alueet Euroopan talousalueella (Frankfurt, Irlanti, Pariisi, Tukholma, Milano, Espanja; Alankomaat, Saksa, Ranska, Ruotsi, Norja, Italia, Puola, Espanja; Belgia, Alankomaat, Saksa, Italia, Ranska, Suomi, Espanja, Puola), uk niistä Yhdistyneessä Kuningaskunnassa, ch niistä Sveitsissä.

Kun se on asetettu, kanava kieltäydytään, kun se tallennetaan ja kun se ladataan, jos liitännäisnimiää alueen ulkopuolelta: S3-, SQS- tai SNS-lähteen tai kohteen region (tai sen endpoint, kun se on AWS-isäntänimi), tai minkä tahansa kohteen, jonka osoite on AWS-isäntänimi, joka sisältää alueen (sqs.us-east-1.amazonaws.com, API Gateway -URL). Palvelin kieltäytyy käynnistymästä, jos seuraaja tai hälytyswebhook on toisessa alueessa. Liitännäinen, joka osoittaa isäntään, joka ei nimeä aluetta (sairaalan oma järjestelmä, MinIO paikallisverkossa), ei arvioida: tietojen käsittelyn rekisteri tietosuojasivulla listaa jokaisen isäntäkohteen, johon kunkin kanavan käsittely on lähetetty, jotta valvoja voi tarkistaa. Koontinäyttö ja tietosuojasivu kertovat, mihin data voi mennä.

Isäntäpalvelu EU:ssa ja UK:ssa. deploy/hosted sisältää OpenTofu (tai Terraform) yhden isäntäpalvelimen kunkin organisaation käyttöön Frankfurtissa, Irlannissa tai Lontoossa: palvelin, sen PostgreSQL-tietokanta ja varmenteet, varmuuskopio-astiasto, lokit ja tukisessioiden tiedot, kaikki salattuina alueen avaimella, eikä mitään replikoida toiseen alueeseen, tuki vain Session Managerin kautta, ja Perfuse suoritetaan -residency-valinnalla. Sen README kertoo, mitä se rakentaa, mitä se ei kata, mitä on verifioitu (validoitu ja suunniteltu oikean tilin perusteella; ei vielä sovellettu) ja mitä se maksaa jokaisessa alueessa luettelon mukaan.

18.3 Konfiguraatio tiedostoina

Kanavat ovat tiedostoja, mikä tarkoittaa, että ne voidaan tallentaa versiohallintaan, tarkastella ennen käyttöönottoa ja vertailla tapahtuman jälkeen.

Tiedostot luetaan uudelleen ilman uudelleenkäynnistystä. Tiedosto, joka ei parseudu, raportoidaan ja aiemmin ladattu versio jatkaa suorittamista, joten syntaksivirhe ei voi ottaa toimivan syötteen ilmalta.

18.4 Varmuuskopio

Kaksi asiaa, joita on varmistettava, ja niillä on erilaiset ominaisuudet.

Kanavakansio on pieni, se muuttuu harvoin, ja se on se, mitä tarvitset palvelun uudelleenrakentamiseen. Varmuuskopioi se konfiguraationa; versiohallinta on yleensä riittävä.

Tietokanta sisältää viestit, käyttäjät ja tapahtumahistorian. Se on suuri, se muuttuu jatkuvasti, ja se sisältää kliinisiä tietoja — joten se vaatii varmuuskopioinnin kliinisinä tiedoina, johon sisältyy myös säilytysaika ja salaaminen. Sen menettäminen ei pysäytä palvelua, mutta se menettää kyvyn tutkia mitä tahansa, mikä on jo tapahtunut, ja historian, josta rytmioppi riippuu.

18.5 Käynnistyskäyttäytyminen

Käynnistettäessä kanavat ladataan ja lähteet alkavat kuunnella. Jonotetut toimitukset jatkuvat.

Asia, joka täytyy ymmärtää, on mitä tapahtuu lentävään työhön. Oletusarvoisessa on_delivery vahvistuksessa viesti, jota ei ole vielä vahvistettu, ei vahvisteta, joten lähettäjä lähettää sen uudelleen — mikä on oikea tulos. on_receipt -vahvistuksessa viesti, joka on vahvistettu, mutta ei vielä toimitettu, on jonossa, ja se jatkuu; jos jono on poistettu käytöstä, se katoaa. Katso viestivirta.

18.6 Päivittäminen

Korvaa binääri ja käynnistä uudelleen. Tietokantaskeema siirretään eteenpäin automaattisesti käynnistyksen yhteydessä.

Siirrot ovat vain eteenpäin. Ei ole alaspäin siirtoa, joten edellisen binäärisen jälkeen tapahtuneen skeeman siirtäminen edellyttää edellistä tietokantaa. Ota kopiointi ennen päivittämistä — tämä on ainoa toiminnallinen varotoimi, josta on syytä olla kurinalainen.

18.7 Valvonta

Hälytykset Perfusen sisällä on käsitelty kohdassa alerting ja se kertoo, kun syöte on loppunut.

Ulkopuolelta, valvo prosessia, levyä, jolla tietokanta on, ja vastaako verkkokäyttöliittymä. Tietokanta kasvaa, ja täysi levy pysäyttää viestin tallennuksen, mikä on vikamuoto, jolla ei ole muuta varoitusta.

18.7.1 SNMP

Välineille, jotka tukevat SNMP:ää (Nagios, Zabbix, PRTG, SolarWinds, LibreNMS), Perfuse ajaa vain-luku SNMPv2c-väylän ja lähetää ansan, kun hälytys laukeaa tai ratkeaa. Aseta se Asetukset → Valvonta → SNMP:n kautta tai lipuilla:

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

• Vastaanotin vastaa GET-, GETNEXT- ja GETBULK-pyyntöjä, ja vain -snmp-allow: n verkoista: v2c-yhteisön salasana lähetetään selkeästi, joten se ei ole koskaan avoin kaikille. Alle 6 merkin pituinen yhteisö tai public/private lopettaa palvelimen käynnistyksen.
• Se palvelee järjestelmäryhmää (sysDescr, sysUpTime, sysName laivueen tunnisteen mukaan, sysContact, sysLocation), yhteenvetoja BASE.1: ssä (kanavat, suoritetaan, rikkoontuneet, vastaanotetut, toimitetut, epäonnistuneet, jonossa) ja kanavataulukko BASE.2.1: ssä (nimi, suoritetaan tai pysäytetään, vastaanotetaan, toimitetaan, epäonnistuu, jonossa, vanhimman jonossa olevan viestin ikä). Numerot ovat ne, jotka kojussa ja /metrics-sivulla näkyvät.
• Ansaitset menevät jokaiselle hallitsijalle -snmp-traps: BASE.0.1 hälytys laukaistu, BASE.0.2 se ratkaistu, kantaa hälytyksen tyyppi, vakavuus, kanava, kohde ja yhteenveto. Ei koskaan viestisisältöä. Vahvistettu hälytys ei lähetä ansaitse.
• BASE on 1.3.6.1.4.1.8072.9999.9999.16 (Net-SNMP: n kokeellinen tila) ellei -snmp-base-oid aseta sen omalle yrityksen tunnisteelle. Lataa MIB asetussivulla (tai GET /api/snmp/mib) antaa MIB: n käytössä olevan perusteen; sama paneeli kertoo, vastaako vastaanotin ja kuinka monta ansaitse on lähetetty.

18.7.2 Inventointi jokaisesta liittymästä

-inventory interfaces.md (Asetukset → Valvonta → Inventointi) kirjoittaa Markdown-dokumentin, jossa luetellaan jokainen kanava - sen muoto, onko se käynnissä, mitä se vastaanottaa ja mihin se lähettää - ja seuraavat kunkin kanavan omat kuvaukset, ja kirjoittaa sen uudelleen joka -inventory-every (oletuksena päivä). Se on tarkoitettu liitettäväksi kanavatiedostojen viereen tai annettavaksi tarkastelijalle, ja luettavaksi ilman sovelluksen suorittamista.

18.8 Kapasiteetti

Perfusen läpäisykattoa ei ole mitattu oikealla laitteistolla oikean liikenteen alla, ja tämä käsikirja ei tulosta numeroa, jota se ei voi tukea.

Mitä voidaan sanoa: arkkitehtuuri on yksi goroutine-yhteys kohti, jolla on kohdekohtaiset jonot, joten läpäisy kasvaa kohteiden mukaan eikä ole sarjavoitu yhden työntekijän kautta; viestin tallennus on SQLite-kirjoitus viesti kohden, mikä tekee levyn todennäköisimmäksi ensimmäiseksi rajoitukseksi; ja viestivarasto kasvaa lineaarisesti liikenteen mukaan, joten säilytysaika on asetus, joka määrää pitkän aikavälin levyn käytön.

Jos mitataan suuren syötteen kokoamista varten, mitata se omalla liikenteellä käyttäen generoituja testikorpuksia, kuten kuvattu testauksessa. Se on rehellinen vastaus, ja se on myös parempi vastaus kuin joku toisen laitteiston luku.

18.9 Missä tämä asennus jumittui

Toiminta sisältää paneelin, joka on näkyvissä ylläpitäjille, ja joka näyttää, mitä Perfuse on kieltäytynyt tekemästä — ryhmitelty viestin mukaan, useimmin ensin — ja kuinka pitkällä asennus on edennyt toimivan kanavan luomisessa.

Se on olemassa, koska jokainen muu väite siitä, onko tämä ohjelmisto helppokäyttöinen, tulee ohjelmiston kehittäjiltä. Kieltäytyminen ei ole: joku halusi jotain, palvelin sanoi ei, eikä kumpikaan osapuoli arvannut. Se on ainoa todiste tuotteessa, joka ei tule BioDream LLC:ltä.

Imu nimittää askelen, jota ei ole vielä tapahtunut, eikä jätä aikaleimoja vertailtavaksi. Tilaa, jota kannattaa seurata, on viestit saapuvat, mutta yhtäkään ei ole toimitettu määränpäähän — kanava voi ottaa liikenteen vastaan useiden viikkojen ajan ja toimittaa sitä yhtäkään, ja muilta näytöiltä se näyttää toimivan.

Mitään kirjoitettua ei tallenneta. Taulu sisältää pyynnön reitin, jossa tunnistimet on korvattu {id}:llä, tilan ja palvelimen oman lauseen. Validointiviesti nimeää kentän ja säännön, joka on hyödyllinen osa; arvo, joka rikkoi sääntöä, on usein potilastietoa, ja taulu niistä olisi huonompi vastuu kuin kitka, jonka se mitatti.

Kahden tarkoituksellisen poiston vuoksi. 5xx on virhe tässä ohjelmistossa ja kirjataan jo valmiiksi virheeksi — sekoittaminen kahteen aiheuttaisi, että tapaukset, joissa joku ei voinut selvittää, mitä kirjoittaa, peittäisivät tapaukset, joissa mitään kirjoitettua ei auttanut. Vanhentunut istunto tuottaa 401-sarjan, joka ei kerro mitään käytettävyydestä ja hukuttaisi jokaisen löydön, joka kertoo.

Raportin lukeminen leikkaa taulun viimeisimpiin 5000 riviin. Kieltäytyminen on 4xx-vastaus, joten se kasvaa hitaasti, ja lukeminen on luonnollinen hetki siivota: ei ajastinta eikä mitään, mikä suoritettaisiin, kun kukaan ei katsele.

GET /api/friction palauttaa saman asian kaikille, jotka haluavat lukea sen JSON-muodossa.

18.10 Lokit

Perfuse kirjaa lokit standarditulosteeseen, jonne valvoja tai konttien suoritusaika kerää sen.

Viestotasoinen yksityiskohta menee viestivarastoon lokin sijaan tarkoituksella. Yksi lokirivi per viesti kiireisellä syötteellä on melua, joka peittää rivit, jotka ovat tärkeitä, ja varasto on haettavissa tavoilla, joita lokitiedosto ei ole.

Loki sisältää, mitä varasto ei voi: käynnistys- ja sammutus-, konfiguraatiolataustulokset, kanavatilamuutokset ja virheet, jotka eivät ole attribuutteja tietyn viestin osalta.

18.11 Kahden instanssin suorittaminen

Kaksi tai useampi palvelin voi toimia yhtenä ryhmänä: kun yksi, joka suorittaa syötteen, lopettaa, toinen ottaa sen haltuunsa muutamassa sekunnissa, ja lähettäjän seuraava yritys saavuttaa sen. Ne jakavat yhden PostgreSQL-tietokannan sen sijaan, että kunkin palvelimen olisi oma SQLite-tiedosto, ja ne sopivat keskenään sen kautta, kuka suorittaa mitä.

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

Käynnistä kunkin palvelimen samalla tavalla omalla nimellään ja osoitteellaan. Tietokanta-tili tarvitsee luoda taulukkoja ja kerran citext-laajennus (tai järjestelmänvalvoja suorittaa CREATE EXTENSION citext ensin). Kunkin palvelimen omat tiedostot ovat -data: sen lokit, sen solmun tunniste ja sen määritysten kopiot.

Kahden tavan jakaa työ.

• active-passive: johtaja suorittaa jokaisen kanavan ja jokaisen työn, joka on suoritettava kerran (FHIR-tilausilmoitukset). Muut odottavat. Se on yksinkertaisin järjetellä, ja se on se, mitä yksi sivusto, jolla on yksi kiireinen palvelin ja yksi varapalvelin, haluaa.
• active-active: kanavat jakautuvat aktiivisten palvelimien kesken, noin tasaisesti. Palvelin, joka lopettaa, antaa kanavansa muille; palvelin, joka liittyy, ottaa osuutensa kanavista yksi kerrallaan. Kanavat, jotka reitittävät toisiinsa (kanavan kohde), suoritetaan yhdellä palvelimella ja siirtyvät yhdessä, koska reititys tapahtuu palvelimen sisällä. Järjestelmänvalvoja voi siirtää kanavan käsin Valvonta → Laivue-sivulta; se pysyy siinä, mihin se on asetettu, kunnes palvelin elää.

Kuka suorittaa mitä, ja ei koskaan kaksi. Jokainen työ on vuokra tietokannassa, joka uusitaan joka viides -cluster-lease: n (15 s oletuksena). Palvelin, joka ei voi uusia sitä (se kaatui, sen verkkoyhteys epäonnistui, tietokanta on yhteyden ulottumattomissa), lopettaa työn itse, kun sen oma kello sanoo, että vuokra on melkein valmis, kolmannen vuokran osan verran. Toinen palvelin ottaa vuokran vasta, kun sen oma kello on katsonut vuokran laskuria seisseen kokonaisen vuokran ajan. Kelloja ei verrata toisiinsa, joten palvelimien kellot ja tietokannan kellot eivät tarvitse olla samaa mieltä; ne tarvitsevat vain toimia noin samalla nopeudella, mikä jokainen kello tekee. Vanhan haltijan lopettamisen ja uuden haltijan aloittamisen välillä on lyhyt aukko, jolloin kukaan ei kuuntele, minkä lähettäjä näkee yhteyden epäonnistumisena ja yrittää uudelleen; ei koskaan ole hetkeä, jolloin kaksi kuuntelee yhdellä syötteellä tai kaksi työntekijää tyhjentää yhtä jonoa.

Palvelin, joka sulkeutuu siististi, tai järjestelmänvalvoja, joka valitsee Siirry alas johtajalta, luovuttaa heti sen sijaan, että odottaa vuokran umpeenmenoa.

Mikä on jaettu jokaisen palvelimen kesken. Viestit, toimitusjono, tilit ja istunnot, audit-loki, FHIR-kauppa, terminologiataulukot ja potilasindeksi ovat tietokannassa, joten kumpi tahansa palvelin, joka ajaa kanavaa, löytää jonon, jonka edellinen jätti. Kanavatiedostot, asetustiedosto, hälytysäännöt, yksittäiset kirjautumistiedostot, logo, Direct-varmenteet ja tallennetut näkymät pidetään samana jokaisella palvelimella tietokannan kautta: kunkin palvelimen omalla levyllä on oma kopiansa, ja muutos missä tahansa palvelimessa (konsolissa, käsin, git pull-kautta) tavoittaa muut palvelimet kahdessa sekunnissa, ja kanava, joka on muutettu toisella palvelimella, käynnistyy uudelleen uudella tiedostollaan. Saman tiedoston muutos kahdella palvelimella samanaikaisesti säilyttää version, joka tavoitti tietokannan ensin, ja toisen version NAME.conflict-SERVER-nimen alla. Asetukset, jotka koskevat vain käynnistystä (viestitietokanta, portit, joille konsoli kuuntelee), ovat voimassa kunkin palvelimen seuraavassa käynnistyksessä, ja lokitila kertoo niistä. Mitä tahansa, mikä nimeää jotakin yhdellä koneella, pysyy kyseisen palvelimen komentorivillä ja poissa jaetusta tiedostosta: varmenne ja avain (-tls-cert, -tls-key), SNMP-kuunteluoite ja palvelimen nimi jäljityksissä. Asetukset näyttävät ne asetuksina kunkin palvelimen mukaan.

Käynnistäminen ja lopettaminen. Kanavan käynnistäminen tai lopettaminen millä tahansa palvelimella koskee kokonaista klusteria: palvelin, joka suorittaa kanavan, käynnistää tai lopettaa sen yhden sekunnin kuluessa, ja vastaus kertoo, mikä palvelin se on.

Latauspalvelin edessä. Syötteen osoitteen on oltava se, joka saavuttaa sen palvelimen, joka ajaa sitä. Osoita lähettäjä virtuaali-osoitteeseen (latauspalvelin, liukuväli-IP, DNS-nimi lyhyellä TTL:llä) ja anna latauspalvelimen tarkistaa /readyz?channel=NAME, joka vastaa 200:lla vain palvelimella, joka ajaa kyseistä kanavaa, ja 503:lla muilla. Konsolille /readyz on 200 jokaisella elävällä palvelimella; /readyz?role=leader vain johtajalla.

AWS-verkkopalkkasääteilijällä käytä kohdekryhmää kunkin syötteen kanssa HTTPS-terveystarkistuksella osoitteessa /readyz?channel=NAME, 5 sekunnin väliajoin ja kynnyksellä 2, ja käytä vyöhykkeiden välistä kuormituksen tasapainotusta. Kun se on pois päältä, lataussääteilijän solmu vyöhykkeessä, jossa ei ole palvelinta, joka suorittaa syötettä, näkee vain epäterveellisiä kohteita, lähettää niille kaikille silti, ja lähettäjä, joka ratkaisi kyseiseen solmuun, odottaa, kunnes syöte palaa vyöhykkeeseensä (95 sekuntia testissä). Aseta rekisteröintidelay 0:ksi, koska palvelin, joka lopettaa syötteen suorittamisen, ei voi tyhjentää mitään.

Mitä on testattu. Kaksi palvelinta PostgreSQL 16:lla, lähettäjä, joka lähettää 300 viestiä, uudelleenlähettää, kunnes vastataan, ja palvelin, joka suorittaa syötteen, tapettiin SIGKILL:llä kahdesti (ensin, sitten toisen jälkeen, kun ensimmäinen tuli takaisin). Jokainen vahvistettu viesti saapui vastaanottajalle, kummassakin muodossa, jota yritettiin: toimitettiin ennen vahvistusta, ja jonossa jaetussa kaupassa, kun vastaanottaja kieltäytyi (185 vahvistettua viestiä odotti jonossa tapauksessa; selviytyjä toimitti ne kaikki). Vaihto kesti 3-4 sekuntia 3 sekunnin vuokrauksella. Moninkertainen on mahdollinen ja nähtiin kerran 600:ssa: viesti, jonka kuoleva palvelin toimitti ja ei voinut vahvistaa, jonka lähettäjä uudelleenlähetti. Koordinaattorin omat testit kattavat kaatumisen, palvelimen, joka on leikattu tietokannasta, kun se suorittaa, siirtymisen, levittämisen ja jaetun konfiguraation ristiriidoilla. Ne suoritetaan CI:ssä PostgreSQL:llä kilpailun havainnitsijalla, koko sarjan kanssa.

Sama tehtiin sitten AWS:llä: kaksi Linux-palvelinta (ARM) ja yksi Windows Server 2022 kolmessa saatavuusvyöhykkeessä, Amazon RDS PostgreSQL 16 yli TLS:in, varmenne tarkistettuna (sslmode=verify-full), sisäinen verkkotasauspalvelin edessä, ja lähettäjät uudelleenlähettävät, kunnes vastataan:

Oletuksena 15 sekunnin vuokrauksella palvelin, joka on leikattu tietokannasta, lopettaa syötteen 10 sekuntia sen jälkeen, kun se on uusittu viimeksi, ja seuraava palvelin käynnistää sen 6-8 sekuntia sen jälkeen: ei koskaan molemmat samanaikaisesti. Kellonajan epätarkkuus ei muuttanut mitään, koska kellonaikaa ei verrata toiseen.

Ei vielä. Klusteri palvelee yhtä organisaatiota: -cluster -multi-tenant -vaihtoehto on evätty. Kuuntelijat siirtyvät kanavansa mukaan, joten tasauspalvelin on sivuston tarjoama.

Palvelin yksinään toimii edelleen samalla tavalla kuin aina, SQLite:llä, ilman klusteria.

18.12 Useampi kuin yksi palvelin

Sivustolla, jolla on kaksi instanssia, on kysymys, jota yksikin konsoli ei voi vastata: onko kaikki käynnissä? Mirth veloittaa vastauksesta. Tämä on laivaston näkymä.

Yksi instanssi on nimetty paikaksi, jonne katsotaan. Se kysyy muilta ja näyttää jokaisen kanavan jokaisella palvelimella yhdessä taulukossa, jossa on yhteenveto kaikista.

18.12.1 Vertaisten lisääminen

Asetukset → Laivue, tai PUT /api/fleet/peers. Peerin on oltava nimi, URL-osoite ja peerin itsensä myöntämä tunniste

Nimi on vaadittu ja se ei ole URL, koska URL ei ole mitään, minkä kukaan tunnistaa kolme aikoihin aamulla.

Token on luotava vastapuolella, Käyttäjien alla, ja sen on oltava katselijan laajuinen. Vastapuolen lisääminen ilman sitä on evätty, ja sen sijaan annetaan ohjeet, eikä sitä hyväksytä ja se ei epäonnistu myöhemmin hiljaisesti jokaisella kyselyllä. Toisen instanssin terveyden lukeminen on pienin etuoikeus, ja se on ainoa, minkä laivaston näkymä tarvitsee.

18.12.2 Peerin hallinta, joka on pois päältä

allow_control sallii kyseisen vastapuolen kanavien käynnistämisen ja lopettamisen täältä. Se on oletuksena pois päältä, ja jokainen käyttö on kirjattu nimellä.

Kaksi etuoikeutta on tietoisesti erillisiä. Toisen palvelimen terveyden lukeminen on vähäpätöistä; sen kanavien lopettaminen siirtymisen aikana ei ole, eikä jälkimmäistä saa ikinä liittää hiljaisesti ensimmäiseen.

18.12.3 Mikä raportissa sanotaan

Jokainen palvelin ilmoittaa kanavien kokonaismäärän, kuinka monta niistä on käynnissä, pysäytetty tai virheellisiä, jonon syvyyden ja vanhimman odottavan viestin iän, kuinka monta hälytystä on aktiivisia, ja onko se on tyhjentymässä sammuttamista varten.

Rullausumman laskurit palvelimia kolmella tavalla: saavutettavissa, saavuttamattomissa ja määrittämättömissä. Kolmas kattaa vertaiset, joiden terveydestä kukaan ei tiedä — eivät vielä kysyneet, kieltäytyvät tunnisteesta tai suorittavat version, jota tämä ei voi lukea. Se pidetään erillään saavuttamattomista, koska "me emme voi sanoa" ei ole "se on alas", ja näiden yhdistäminen on se, miten laivueen sivu alkaa valehdella.

Saman vuoksi rullausumma sisältää tunnettuja: niin monta kappaletta, joista kanava- ja jonotilastot oli todella luettu. Kaksitoista kanavaa, jotka suoritetaan laivueen yli, tarkoittavat jotain muuta, kun kaksi viidestä palvelimesta ei vastannut, ja yhteensä ei voi sanoa sitä.

Saavuttamaton vertainen kertoo syyn, josta operaattori voi toimia. Hylätty yhteys ilmoitetaan isäntänä, joka on ylös, mutta jolla ei ole mitään kuuntelemassa kyseisessä portissa, mikä on eri ongelma kuin isäntä, joka ei vastaa lainkaan.

18.12.4 Kellon viive

Rullausumma ilmoittaa suurimman eron palvelimien kellonaikojen välillä. Se on arvonsa verkossa: korreloimalla tapahtumaa kahden instanssin välillä, joiden kellot ovat eri aikaa neljä minuuttia, tuottaa tapahtumien sarjan, jota ei ole tapahtunut.

18.12.5 Mikä peer oppii sinusta

Määrät ja nopeudet. Raportti, jonka yksi instanssi antaa toiselle, ei sisällä viestitunnisteita, kanavatasoista yksityiskohtia eikä potilastietoja millään tavoin.

Se estää laivueen näkymän olemasta kliinisen datan keskittäminen: aggregoiva instanssi oppii, kuinka monta kanavaa on käynnissä, ja mitään siitä, mitä niiden kautta virtaa. Jos haluat viestit, avaat kyseisen palvelimen oman konsolin, jossa audit-loki merkitsee, että teit sen.

18.12.6 Peer, joka osoittaa itseään

Hylätty. Instanssi, joka kysyy omaa osoitettaan omassa HTTP-pinossa, näkyy kahdesti omassa laivueen näkymässä ja kaksinkertaistaa jokaisen kanavansa.

18.12.7 TLS sisäverkoissa

insecure_skip_verify hyväksyy vertaisen varmenneen ilman sen todentamista. Se on olemassa, koska sairaalan infrastruktuuri toimii yksityisillä varmenneviranomaisilla, ja kieltäytyminen toimimasta kokonaan ajaisi ihmisiä yksinkertaisen HTTP:n käyttöön, mikä on huonompi. Se on nimetty siten, että sitä ei voida sekoittaa hyvään ajatukseen.

19 Komentorivi

Kaikki, mitä Perfuse tekee käynnissä olevaan järjestelmään, on saatavilla web-käyttöliittymästä, ja se on tietoinen suunnittelupäätös: ominaisuus, joka tarvitsee terminaalia, kohdellaan virheenä eikä suunnittelupäätöksenä. Komennot täällä ovat työlle, joka tapahtuu *järjestelmän ympärillä* — ennen kuin se on olemassa, kun päättelyssäsi, voitko luottaa siihen, ja kun sinun on annettava jotain toiselle.

Useista niistä ei koskaan kosketa palvelinta lainkaan. perfuse explain, perfuse profile, perfuse deident ja perfuse translate lukevat tiedostoja ja kirjoittavat tiedostoja, joten ne ovat hyödyllisiä kannettavassa tietokoneessa laitteistoa vastaan, joka edelleen toimii kokonaan jossain muussa.

Suorita mikä tahansa komento -h-valitsimella sen lipuille. Tämä luku kertoo, mihin kunkin tarkoitus on.

19.1 Kanavien suorittaminen

19.1.1 perfuse serve

Suorittaa web-liittymän ja API:n, ja oletuksena myös kanavat. Tämä on komento, jonka asennus käyttää.

Jokainen valinta, jonka se hyväksyy, on lueteltu Palvelinvalinnat -osiossa, joka on generoitu ohjelmasta. Se kieltäytyy palvelemasta selkeää HTTP:ä muille kuin loopback-osoitteille, ellei -insecure-valintaa anneta. Tämä ei ole mukautuvaa kohteliaisuutta: kliininen liikenne ja istuntotunniste salaamattomassa lähiverkkoyhteydessä on ilmoitettava tapahtuma, ja lippu on olemassa, jotta kyseessä on joku tekemä päätös eikä periytyvä oletusarvo. Katso turvallisuus.

19.1.2 perfuse run

Suorittaa kanavia YAML-tiedostosta ilman web-liittymää ja tietokantaa. Käytännöllinen kontissa, joka pitäisi tehdä vain yksi asia, ja käytännöllinen, kun haluat nähdä kanavan käyttäytymisen ilman mitään muuta suorittamista.

19.1.3 perfuse check

Tarkistaa kanavamäärittelyt ja tulostaa, mitä ne tekevät, ilman niiden suorittamista. Jälkimmäinen on pointti: kanava, joka latautuu, ei välttämättä ole kanava, jota halusit, ja ymmärrettävän summaryn lukeminen siitä, mitä tiedosto tekee, löytää virheen, jonka validointi ei voi nähdä.

Lopettaa epänollaan virheen sattuessa, joten se kuuluu mihin tahansa tarkastuksiin, jotka tarkistavat konfiguraatiotasi ennen kuin ne pääsevät palvelimelle. -quiet tulostaa mitään onnistumisen sattuessa, tätä varten.

-allow-metadata-egress sallii kohteiden osoittamisen pilvipalvelun metatietojen osoitteisiin. Nämä osoitteet sisältävät koneen omat tunnistetiedot, joten kanava, joka voidaan saada lähettämään sinne, on tunnistetietojen vuoto; tarkistus kieltäytyy niistä, ellei toisin valita.

19.1.4 perfuse test

Suorittaa testit, jotka on kirjoitettu kanavamäärittelyjen vastaisesti. Testi lähettää viestin kanavan todellisen suodattimen, todellisten muunnosten ja todellisten skriptien kautta, todellisessa järjestyksessä, vain verkko on korvattu — joten mitä täällä menee läpi, se on kanavan toiminta.

Testit sijaitsevat *_test.yaml tai *.test.yaml -tiedostossa kanavien vieressä. Katso testaus.

19.2 Siirtäminen toisesta moottorista

Nämä kolme ovat ne, jotka suoritetaan ensin, ennen kuin mitään päätetään. Katso siirtäminen.

19.2.1 perfuse explain

Lukee Mirth-, Open Integration Engine- ja BridgeLink-vientejä — kanava, kanavaryhmä tai koko palvelimen varmuuskopio — ja kuvaa, mitä kunkin kanava tekee ja mitä estäisi siirtymisen. Se ei muuta mitään ja ei tarvitse Perfuse-asennusta, mikä tekee siitä edullisimman mahdollisen ensimmäisen askeleen: osoita se omalle viennille ja lue, mitä se palauttaa.

-strict lopettaa epänollaan, jos mitään estetään, joten se voidaan käyttää putken portilla. -json lähettää samat löydökset koneelle.

19.2.2 perfuse translate

Muuttaa Mirth-, Open Integration Engine- ja BridgeLink-vientejä Perfuse-kanavatiedostojen muotoon: yksi kanava, kanavaryhmä, kooditemplaatin vienti tai koko palvelimen varmuuskopio.

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

Kooditempaikkakirjastot kirjoitetaan lib/ -kansioon kanavien vieressä, ja kunkin kanavan Mirthilla oli kirjasto, joka sisältyy siihen. Katso siirtäminen.

Mitään ei hävitetä hiljaisesti. Jokainen osa kanavasta joko käännetään, siirretään skriptinä, joka suoritetaan muuttumattomana, tai ilmoitetaan vaativan ihmisen. Kolmas kategoria on rehellinen — kääntäjä, joka tuottaa puhdas näköisen tiedoston jokaiselle syötteelle, piilottaisi päätökset, joita tarvitset eniten.

19.2.3 perfuse compare

Suorittaa saman liikenteen kahden moottorin läpi ja raportoi, missä ne eroavat, ryhmitelty kenttä kerrallaan.

Tämä on komento, joka vastaa kysymykseen "miksi minun pitäisi luottaa tähän potilastietojen kanssa", ja se vastaa siihen keräämällä näyttöä sen sijaan, että tehtäisiin väite täällä. Se on suositeltu viimeinen vaihe ennen siirtymistä, ja suositeltu ensimmäinen vaihe minkä tahansa keskustelun aloittamiseen siitä, onko Perfuse valmis.

19.3 Ymmärtäminen syötettä

19.3.1 Perfuse-profiili

Lukee viestejä ja raportoi, mitä niissä todella on: mitkä kentät ovat aina täytetty, mitkä eivät koskaan ole, koodatun kentän todelliset arvojoukot, toistomäärät ja mitkä Z-segmentit ilmestyvät.

Arvoja raportoidaan vain kentille, joiden arvot muodostavat pienen koodijoukon, joten todellisen liikenteen profiili ei muutu potilastietojen täyttämäksi tiedostoksi.

Profiilin tallentaminen ja vertaaminen myöhemmin siihen on tapa, jolla selvität, että lähettäjä muutti jotain:

Perfuse-profiili -tallenna edellinen-kuu.json korpus/ Perfuse-profiili -vastaa edellinen-kuu.json uusi/

19.3.2 Perfuse-sopimus

Muuttaa tuon ajattelun tulosta voimaansaattavaksi. Sopimus kertoo, miltä syötteiden on oltava, jotta sinä päivänä, kun se muuttuu, sinä ilmoitetaan siitä, eikä sinun tarvitse kuulla siitä viikkoja myöhemmin vastaanottajalta, joka kaatui — viestit ovat edelleen voimassa olevia HL7-viestejä, kun kenttä katoaa, joten muu ei huomaa.

Perfuse-sopimus edistä -o adt.sopimus.yaml korpus/ Perfuse-sopimus tarkista adt.sopimus.yaml tänään/

promote luo aloituspisteen, ei vastausta. Lue se ja poista suurin osa siitä: jokainen rivi merkitsee, mitä on mitattu tai päätetty, mikä kertoo, mitkä rivit on säilytettävä.

19.4 Viestien tuottaminen

19.4.1 Perfuse tuottaa

Tuottaa synteettisiä HL7 v2 -viestejä. Kaikki on keksitty — selvästi kuvitteelliset nimet, peräkkäiset tunnistimet, keksityt osoitteet — joten tuloste on turvallista lähettää, liittää viestiin ja liittää tikettiin.

Se voi lähettää suoraan kanavaan kirjoittamisen sijaan, mikä on nopein tapa todistaa, että kuuntelija toimii:

Perfuse tuottaa -n 100 -lähettä 127.0.0.1:6661

19.4.2 Perfuse de-identifioi

Lukee todellisia viestejä ja kirjoittaa korpuksen, joka säilyttää niiden rakenteen, koodit ja väliajat, ja mitään, mikä tunnistaa potilaan. Tämä on ero siinä, voitko lähettää jollekulle jäljennöksen ja et.

Se ei ole sama työkalu kuin perfuse generate, ja ero on merkittävä. Generoidut viestit ovat keksittyjä ja siten turvallisia, mutta epärealistisia; de-identifioitu aineisto on *johdettu todellisesta liikenteestä*, joten se toistaa niitä omituisuuksia, jotka todella rikkoavat rajapintoja.

Kaksi ominaisuutta, joita kannattaa ymmärtää ennen sen käyttämistä:

• Sama suola aina tuottaa saman korpuksen, joten jaettu korpus voidaan uudelleenluoda sen sijaan, että se arkistoidaan.
• Pidä suola salassa. Pseudonyymit ovat johdettu todellisista arvoista, joten kuka tahansa, joka pitää suolaa, voi vahvistaa arvauksensa siitä, kuka tietue viittaa.

19.5 Viestien siirtäminen käsin

19.5.1 Perfuse kuuntele

Hyväksyy HL7 v2 MLLP:n yli ja vahvistaa sen. Vastaanottaja, joka on olemassa niin kauan kuin sinun tarvitsee, todistaaksesi, että lähettäjä voi tavoittaa tämän koneen lainkaan.

19.5.2 Perfuse lähetys

Lähettää HL7 v2 -viestit MLLP: n kautta tiedostoista.

19.6 FHIR

19.6.1 Perfuse FHIR

Muuntaa HL7 v2: n FHIR: ksi, validoi FHIR: n tai palvelee sitä subkomennon mukaan.

Validointialikomento on hyödyllinen ominaisuutena: se kertoo, onko resurssi, jonka joku on lähettänyt sinulle, US Core -profiilin mukainen, joka on profiili, jota amerikkalainen sääntely on kirjoitettu vastaan. Pystyä vastaamaan siihen ilman moottorin omaksumista on pointti.

19.6.2 perfuse x12

Muuntaa X12 (tai muun rajatun EDI): n Mirth Connectin ja Open Integration Engine -kirjoittaman XML: n, ja takaisin: perfuse x12 xml FILE ja perfuse x12 from-xml FILE, vakio syöte ilman tiedostoa. Tuloste on se, mitä OIE 4.6 kirjoittaa, bitti bittien, joten se voidaan verrata siihen, mitä Mirth-palvelin tuotti tai syötti järjestelmään, joka on rakennettu sitä vastaan. Kanava tekee saman x12.arrives_as: xml :n ja kohdekohtaisen x12_as: xml :n kanssa; ks. X12.

19.6.3 Perfuse sof

Suorittaa SQL-kyselyn FHIR ViewDefinition yli FHIR-tiedostojen (NDJSON massaladatun, Bundle tai JSON-joukko; - stdin): -view FILE (vaadittu), -format csv|ndjson|json|parquet (csv oletuksena), -header=false ja -o FILE (vaadittu Parquet-tiedostolle). Katso SQL on FHIR-näkymät.

19.6.4 Perfuse mittaus

Arvioi laadun mittausta FHIRPath-kriteerien avulla FHIR-tiedostojen yli (NDJSON massavirheen, Bundle- tai JSON-taulukot; - merkki standarditulosteen sijaan) ja kirjoittaa MeasureReportin. Liput:

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

Katso digitaaliset laadun mittaukset.

19.6.5 FHIR-liput Perfuse-palvelimella

Varasto pitää asiakirjoja sekä resursseja: asiakirja, kokoelma tai viestipaketti Bundle, joka on asetettu /fhir/Bundle/{id}:iin, säilytetään kokonaisuutena, luetaan takaisin jokaisen sisäänkirjautumisen kanssa julkaistussa versiossa ja löydetään type, identifier, timestamp ja composition avulla. Transaktio, joka on asetettu sinne, säilytetään tallenteena eikä sovelleta; POST /fhir:iin soveltaa yhden.

Vastaukset ovat JSON-muodossa, ellei asiakas pyydä XML:ää (Accept: application/fhir+xml tai _format=xml). Perfuse lukee vain JSON:ia: XML-muodossa lähetetty runko saa 415. Asiakirja-bundle, joka lähetetään POST-pyynnöllä /fhir-sivulle, säilytetään, kun palvelin pitää, tunnisteella, potilaan ja kohtaamisen, jonka koostus nimeää, ja se hylätään 422-virheellä muutoin. Binääri, joka luetaan Accept-arvon ollessa sen oma sisältötyyppi, vastaa sisällön itsensä kanssa.

19.7 Asetukset ja toiminta

19.7.1 Perfuse alku

Luo hakemistorakenteen, esimerkki-kanavan ja palvelumääritelmän käyttöjärjestelmälle, jolla se suoritetaan. Mitään olemassa olevaa ei korvata, ellei -force-valintaa ole annettu.

Perfuse alku -hakemisto /opt/perfuse -palvelu systemd

19.7.2 Perfuse-palvelu

Rekisteröi Perfusen Windows-palveluna, poistaa sen tai raportoi, onko se asennettu ja käynnissä. Vain Windows; Linuxissa vastaava on yksikkötiedosto, jonka perfuse init voi kirjoittaa puolestasi. Katso operations.

19.7.3 Perfuse-merkki

Myöntää koneille tarkoitetut tunnistetiedot, ei ihmisille. Merkki ei vanhene eikä se ole vaikuttunut kenenkään kirjautumisesta ulos, mikä on se, mitä palvelimen naapuriin kysyvälle palvelimelle tarvitaan ja mikä on tarkoituksella selainistunnossa.

Perfuse-merkki luo -tietokanta perfuse.db -etiketti laivasto-sivustolta -rooli katselija Perfuse-merkki lista -tietokanta perfuse.db Perfuse-merkki peruuta -tietokanta perfuse.db -etiketti laivasto-sivustolta

Vain tiiviste tallennetaan, joten tokeni näytetään kerran, kun se luodaan, eikä sitä voida palauttaa myöhemmin. Varastettu tietokanta ei siis tuota käytettävissä olevaa tokenia. Anna tokenille alin rooli, joka tekee työn: laivueen näkymä tarvitsee viewer, ja mitään, joka lukee vain, ei pidä pitää mitään enempää.

-fhir-groups riverside-attributed,riverside-north rajoittaa tokenin näihin FHIR-ryhmiin CMS-0057 Provider Access -vientiä varten: FHIR-päätepisteessä se voi lukea nämä ryhmät ja viedä ne, ja mitään muuta. Katso CMS-0057 maksajille.

19.7.4 Perfuse athena

Tulostaa Amazon Athenan CREATE EXTERNAL TABLE -kyselyn S3-arkistolle, joka on kirjoitettu format: ndjson -muodossa ja joka käyttää ositusta dt=YYYY-MM-DD -osaa avaimesta, jotta mitään ryntäystä ei tarvitse suorittaa, kun päiviä lisätään.

Perfuse athena -bucket sairaala-arkisto -destination arkisto

Tulostetaan sen sijaan, että suoritettaisiin, koska taulun luominen vaatii Athenan ja Gluen oikeudet, joita tämä ohjelma ei pitäisi omistaa.

19.7.5 Perfuse sbom

Luettelee kaiken, mikä on linkitetty binääriin, luettu itse rakennuksesta eikä go.mod -tiedostosta — joten se kuvaa binääriä, joka on edessä, eikä sitä, mitä joku on kerran pyytänyt.

-json lähettää CycloneDX:n ja -spdx lähettää SPDX-merkkiarvon, joka on yleensä se, mitä hankinta- tai tietoturvakatselu todella pyytää. Selainkoodi, joka on upotettu binääriin, on mukana, koska katselija, joka vertaa binääriä varoituksiin, tarvitsee tietää, että se sisältää React-sovelluksen.

19.7.6 Perfuse versio

Tulostaa version ja commitin, josta se on rakennettu. Arvoinen mainita lipussa: "nykyinen" ei ole versio, ja kaksi konetta, jotka asennettiin viikko toisensa jälkeen, eivät usein suorita samaa rakennusta.

20 Palvelinvalinnat

Jokainen valinta, jonka perfuse serve ottaa, generoitu itse ohjelmasta, joten tämä luetteloa ei voi nimetä valintaa, jota ei ole olemassa, tai jättää yhtä pois. Useimmat ovat myös asetus verkkokäyttöliittymässä, nimetty viimeisessä sarakkeessa: arvo, joka on tallennettu siellä, voittaa lippua seuraavassa käynnissä, ja lippu on edelleen tapa asettaa se palvelun määritelmästä.

Salaisuuksia ei koskaan ole lipuksia. Valinta, joka tarvitsee salasanan tai tunnuksen, nimeää ympäristömuuttujan, joka pitää sitä.

20.1 Kaikki valinnat

21 Kanavaviite

Jokainen avain, joka voidaan esittää kanavatiedoston ylimmällä tasolla. Nämä poimitaan lähdekohteesta, joten tämä luku ei voi kuvata valintaa, jota ei ole olemassa, tai jättää yhtä pois.

21.1 Kanava

Kanava on yksi konfiguroidtu viestivirta: jonne viestit saapuvat, valinnainen suodatin ja yksi tai useampi paikka, jonne ne menevät.

Määritelty Channel-nimisenä internal/config-tiedostossa.

21.1.1 nimi

Nimi tunnistaa kanavan lokit ja mittaukset.

Vaadittu ja yksilöivä.

21.1.2 ryhmä

Ryhmä on se, mihin tämä kanava kuuluu, järjestelmän kanavien luettelointia varten, joka on kasvanut liian pitkäksi.

Kosmeettinen viidellä kanavalla ja rakenteellinen kahdellasadalla: sivuston kanavat jakautuvat järjestelmien mukaan, joille ne puhuvat, tai tiimin mukaan, joka omistaa ne, ja tasainen luettelo kahdensadan nimen kanssa on käyttökelvoton, riippumatta siitä, kuinka hyvä muu käyttöliittymä on.

Yksinkertainen merkkijono ryhmäobjektin sijaan, jolla on oma tiedostonsa, koska ryhmällä ei ole käyttäytymistä. Hetkeä, jolloin se saa tiedoston, se hankkii asetukset, ja asetukset ryhmässä tarkoittavat, että kanavan käyttäytyminen riippuu jostakin, jota ei ole kirjoitettu kanavaan - mikä on ominaisuus, joka tekee Mirth-konfiguraation vaikeaksi ymmärtää.

21.1.3 liitteet

Liitteet siirtää suuret kuormat viestin ulkopuolelle ja palauttaa ne ennen toimittamista.

Valinnainen kunkin kanavan osalta: suora ADT-viestien syöte ei tarvitse mitään poimittavaa ja ei pitäisi maksaa laitteiston käytöstä.

21.1.4 rajattu

Rajattu konfiguroi rajatun kanavan.

Vain merkityksellinen, kun tietotyyppi on rajattu.

21.1.5 taulukot

Taulukot nimittävät jaettuja käännöstaulukoita, joihin viittataan nimellä.

Jaettu, koska verotus on suurelta osin uudelleenjohdettu käännös, jonka joku on jo johtanut: sivuston sukupuolikoodeja ja potilasluokkia käännetään identtisesti jokaisessa kanavassa, joka koskettaa niitä, ja taulukko kanavassa on taulukko, jota vain kyseinen kanava voi käyttää.

21.1.6 käytössä

Käytössä oletusarvo on tosi.

Poistettu kanava on ladattu ja validoituu, mutta ei käynnistetä, joten tiedosto, joka on tilapäisesti pois, on edelleen tarkistettu CI: n avulla.

21.1.7 datatyyppi

Datatyyppi on kanavan vastaanottamien viestien muoto.

Oletuksena on hl7, joten jokainen ennen tämän olemassaoloa kirjoitettu kanava toimii edelleen.

21.1.8 x12

X12 sisältää asetukset, jotka ovat merkityksellisiä vain X12-kanavalla.

Muiden kanavatyypien asettaminen ei ole sallittua, vaan se hylätään sen sijaan, että se ohitettaisiin.

21.1.9 skripti

Skripti määrittää NCPDP SCRIPT -kanavan.

Sen vaiheet sijaitsevat täällä sen sijaan, että ne olisivat ylätason muunnoksissa, samasta syystä kuin jokaisen muun non-v2-muodon: vaiheiden tyypit eroavat muodosta riippuen, joten yksi avain voisi tarkoittaa eri asioita riippuen datatyypistä.

21.1.10 dicom

Kuvantaminen määrittää DICOM-kanavan nimettyjä muunnosvaiheita.

Nimetty Kuvantaminen sen sijaan, että DICOM, koska lähde ja kohde jo ovat DICOM-kenttiä ja kolme kenttää samalla nimellä eri tasoilla on tapa, jolla joku asettaa väärän kentän. YAML-avain on dicom, joka on se, minkä henkilö, joka kirjoittaa tiedoston, odottaa, ja Go-nimi on se, joka estää virheen kutsusivulla.

21.1.11 suodatin

Suodatin on lauseke, joka on voimassa, jotta viesti voidaan välittää.

Viesti, joka ei vastaa suodatinta, on edelleen vahvistettu: lähettäjä ei ole tehnyt mitään väärää, me vain emme ole kiinnostuneita.

21.1.12 muunnokset

Muunnokset ovat deklaratiivisia muutoksia, jotka sovelletaan hyväksyttyihin viesteihin, järjestyksessä, ennen kuin skripti suoritetaan.

Tämä on kerros, joka on tarkoitettu kantamaan tavallinen työ: jokainen vaihe on validoitava, kun tiedosto ladataan, se näkyy diffissä ja se voidaan tarkastella henkilöltä, joka ei lue JavaScriptiä.

21.1.13 skriptit

Skriptit sisältävät JavaScript-koodin tapauksille, joita deklaratiiviset vaiheet eivät voi ilmaista, ja se on se, mihin Mirth-kanavan omat skriptit päätyvät muuttumattomina.

Kanava, jolla on skripti, on merkitty sellaisena käyttöliittymässä, koska sen käyttäytyminen ei voida määrittää lukemalla konfiguraatiota.

21.1.14 varjokanava

Varjokanava suorittaa kanavan ehdotettua versiota rinnakkain ja raportoi, missä ne eroavat.

Mitään, mitä se tekee, ei voi tavoittaa vastaanottajaa.

22 Lähdeviite

Jokainen tapa, jolla kanava voi vastaanottaa viestejä, ja jokainen avain, jonka kunkin kanava hyväksyy. Kanavalla on tarkalleen yksi lähde.

22.1 AMQP Lähde

AMQP Lähde vastaanottaa jonosta tai tilauksesta.

Viesti hyväksytään vasta, kun kanava on käsitellyt sen. Se, jota ei voitu käsitellä, vapautetaan epäonnistuneena toimituksena, jotta välittäjä toimittaa sen uudelleen ja - Service Busissa, jonon enimmäistoimitusmäärän ylittävässä tapauksessa - merkitsee sen kuolleeksi.

Määritelty AMQPSource-na internal/config:ssa.

22.1.1 prefetch

Prefetch on se, montako viestiä välittäjä voi lähettää eteenpäin.

Oletusarvo on 10. Ne käsitellään kuitenkin yksi kerrallaan, järjestyksessä.

22.1.2 reconnect

Reconnect on odotusaika yhteyden menetettyä.

Defaults to 5s.

22.2 AS2 Lähde

AS2 Lähde vastaanottaa AS2 (RFC 4130): EDI lähetetään HTTP:n yli, allekirjoitetaan ja salataan S/MIME:llä, ja vastataan kuittauksella (MDN), joka sisältää saapuneen sisällön tiiviste.

Kanavan käsiteltävä kuorma on X12 ja EDIFACT.

Määritelty AS2Source-na internal/config:ssa.

22.2.1 polku

Polku on URL-polku, johon kumppanit lähettävät.

Default /as2.

22.2.2 tls

TLS tarjoaa HTTPS:n.

Useimmat kumppanit vaativat sitä sopimuksessaan S/MIME:n lisäksi.

22.2.3 id

ID on meidän AS2-tunniste, jonka kumppanit lähettävät AS2-To:ssa.

Viesti mihin tahansa muuhun kieltäytyy.

22.2.4 kumppanit

Kumppanit ovat ne, jotka voivat lähettää tänne.

Viesti kenenkään muun lähettäjältä hylätään.

22.2.5 duplicate_window

DuplicateWindow on ajanjakso, jonka aikana kumppanin Message-ID muistetaan, jotta viesti, joka lähetetään uudelleen (kumppani ei saanut meidän vastaanottoa ja yritti uudelleen), vastaanotetaan ja ei välitetä kahteen kertaan (RFC 4130, jakso 7.5).

Default 30 days.

22.3 Azure Blob -lähde

AzureBlobSource poimii blobit säiliön etuliitteestä.

Määritelty AzureBlobSource -kohtaa internal/config.

22.3.1 siirrä

Siirrä on mihin käsitelty blob siirretään.

Oletusarvo on prosessoidut/.

22.3.2 virhe_etuliite

VirheEtuliite on mihin blob, jota ei voida käsitellä, siirretään, jotta se ei estä muuta toimintaa.

Oletusarvo on virhe/.

22.3.3 tarkastusväli

Tarkastusväli listauksien välillä.

Defaults to 30s.

22.3.4 maksimikokoa

Maksimikokoa kieltää isomman blobin, joka jätetään paikoilleen.

Oletusarvo on 16 MiB.

22.4 Välittäjälähde

BrokerSource lukee viestejä viestinvälittäjästä.

Mirthin JMS-lukija, jota voidaan käyttää STOMP-protokollaa, koska JMS on Java-rajapinta eikä protokolla. Katso internal/stomp, miksi STOMP ja ei OpenWire.

Määritelty BrokerSource -kohtaa internal/config.

22.4.1 osoite

Addr on is välittäjän isäntä ja portti.

Pakollinen. 61613 on yleensä käytetty STOMP-portti.

22.4.2 kohde

Kohde on jono tai aihe, josta luetaan.

Required.

Välittäjät kirjoittavat nämä eri tavoin - /queue/nimi ActiveMQ: ssä, paljas nimi RabbitMQ: ssä - joten se välitetään muuttumattomana sen sijaan, että se koostettaisiin täällä. Arvauksen tekeminen merkitsisi työskentelyä yhden välittäjän kanssa ja hiljaisesti lukemista toisella.

22.4.3 kirjautuminen

Kirjautuminen ja salasana tunnistavat.

Useimmat välittäjät kieltävät anonyymin yhteyden.

22.4.4 salasana

Kirjautuminen ja salasana tunnistavat.

Useimmat välittäjät kieltävät anonyymin yhteyden.

22.4.5 isäntä

Isäntä on virtuaalinen isäntä.

Oletusarvoisesti osoitteen isäntä.

22.4.6 valitsin

Valitsin suodattaa viestejä välittäjässä.

JMS-valitsin, joka välitetään muuttumattomana sen sijaan, että se tulkitstaan. Suodatus välittäjässä sen sijaan, että täällä, tarkoittaa, että viestit, joita tämä kanava ei halua, eivät koskaan ylittäkö verkkoa - mikä jaetussa jonossa on ero lukea sata viestiä päivässä ja sata tuhatta.

22.4.7 tilaus_id

TilausID nimeää tilauksen.

Oletusarvoisesti kanavan nimi.

Nimetty sen sijaan, että generoitu, koska kestävä tilaus tunnetaan sen avulla: generoitu luo uuden tilauksen jokaisella käynnistyksellä ja jättää vanhat tilaukset kasaamaan viestejä, joita kukaan ei lue.

22.4.8 syke

Syke pitää yhteyden elossa.

Oletusarvoisesti kolmekymmentä sekuntia.

Päällä oletuksena täällä, toisin kuin asiakkaan oman oletusarvon, koska lähde pitää yhden yhteyden auki viikkoja. Ilman sykettä yhteys palomuurin kautta, joka on hiljaisesti pudottanut reitin, näyttää täältä täydelliseltä ja viestit vain loppuvat saapumasta, eikä mitään kirjata.

22.4.9 reconnect

Uudelleenmuodostus on se, kuinka kauan odottaa ennen uudelleenmuodostusta epäonnistumisen jälkeen.

Oletusarvoisesti viisi sekuntia.

22.4.10 aikakatkaisu

Yhteyden muodostamisen aikarajoitukset.

Oletusarvoisesti kolmekymmentä sekuntia.

22.5 DICOM-kyselylähdde

DICOMQuerySource kysyy arkistoa C-FIND:llä ja lähettää viestin jokaisesta uudesta tutkimuksesta.

Mirthilla ei ole vastaavaa liitintä. Sen DICOM-tuki on kuuntelija ja lähettäjä - se voi vastaanottaa arkistosta pushattuja kuvia ja lähettää ne eteenpäin, ja se on kaikki. Arkistoon kysymistä, mitä se sisältää, on pyydetty heidän foorumeillaan vuodesta 2015 lähtien.

Se, mikä tekee siitä arvokkaan, ei ole kysely, vaan automaatio: ennakkoaja, joka suoritetaan kolmen aikaan aamulla, tarkistus, joka huomaa arkiston puuttuvan tutkimuksen, jonka RIS sanoo olevan olemassa, työlista, joka on rakennettu siitä, mitä on todella skannattu sen sijaan, mitä on tilattu. Nämä ovat tehtäviä, joita sivustot tällä hetkellä tekevät aikataulutetulla skriptillä moottorin ulkopuolella, mikä tarkoittaa, että ne ovat sille näkymättömiä - ei uudelleenyrityksiä, ei hälytyksiä, ei viestihistoriaa.

Määritelty DICOMQuerySource -kohtaa internal/config.

22.5.1 osoite

Osoite on arkiston isäntä ja portti.

Required.

Nimetty vastaamaan DICOM-kohdetta lyhentämisen sijaan. Nämä kaksi olivat "osoite" ja "addr" iltapäiväksi, mikä on sellainen epäjohdonmukaisuus, jonka joku käsin kirjoittava kanavatiedosto tekee väärin kerran ja sitten epäilee koko tiedostomuotoa.

22.5.2 kutsuttu_ae

KutsuttuAE on arkiston AE-otsikko.

Vaadittu käytännössä: useimmat arkistot kieltäytyvät yhdistymisestä, joka on osoitettu muuhun kuin arkistoon, ja tämä kieltäytyminen luetaan poisjääntinä eikä konfiguraation virheenä.

22.5.3 kutsuva_ae

KutsuvaAE on AE-otsikko, jonka Perfuse esittää.

Arkistot käyttävät yleensä sitä pääsytarkasteluun.

22.5.4 taso

Taso on kyselyn taso: POTILAS, TUTKIMUS, SARJA tai KUVA.

Oletuksena TUTKIMUS.

TUTKIMUS on oletusarvo, koska se on se, mitä melkein jokainen hyödyllinen kysely haluaa, ja koska vaihtoehdot yllättävät ihmisiä: KUVA-tason kysely suurelle CT:lle palauttaa yhden vastauksen jokaista viillettä kohden, mikä on satoja tutkimuksia kohden.

22.5.5 vastaa

Vastaa ovat kyselyavaimet.

Arvo suodattaa; tyhjä arvo pyytää kentän palauttamista.

Avaimet on nimetty eikä niitä ole numeroitu - "PotilasID" eikä "0010,0020" - koska kanavatiedosto luetaan ihmisille, ja taginumero konfiguraatiotiedostossa on hakemisto, jonka jokainen lukija on suorittanut.

22.5.6 palauta

Paluuarvot ovat kentät, jotka haetaan ilman niiden suodattamista.

Eroon Matchista tyhjällä arvolla, vaikka ne koodataan identtisesti, koska tarkoitus eroaa ja lukija voi nähdä, mitkä avaimet kaventavat hakua ja mitkä kerätään.

22.5.7 väli

Väli on, kuinka usein haetaan tietoja.

Required.

22.5.8 ikkuna

Ikkuna on, kuinka pitkälle taaksepäin kunkin haun katsotaan, tutkimuspäivämääränä.

Nolla poistaa päivämääräsuodatuksen kokonaan.

Ikkuna on se, mikä pitää tämän rajattuna. Ilman sitä jokainen haku kysyy arkistolta kaiken, mitä se on koskaan pitänyt, ja sitten hylkää sen, mitä se on aiemmin nähnyt - mikä toimii testiarkistossa ja on epäsopiva vastaan oikeaa arkistoa, joka pitää miljoonia tutkimuksia.

22.5.9 leikkaus

Leikkaus uudelleenhaa tämän verran jo haetun ajanjaksosta.

Oletusarvo on yksi tunti.

Välttämätön ei varovainen. Tutkimus voidaan rekisteröidä edellisen päivän päivämäärällä, meidän kellomme ja arkiston kellon ei tarvitse olla samaa mieltä, ja haun raja, joka linjaa täsmälleen saapumisen kanssa, menettää sen. Leikkaus uudelleenhaa, ja jo nähty tarkistus estää duplikaatin - joten leikkaamisen kustannus on hieman suurempi kysely ja ei-leikkaamisen kustannus on hiljaisesti väärä tutkimus.

22.5.10 raja

Raja asettaa yhden haun vastaavien määrän.

Defaults to 500.

Raja ei ole raja, koska virheellinen vastaavuusavain muuttaa tämän "anna minulle kaikki", ja ensimmäinen oire siitä vastaan oikeaa arkistoa on arkiston ylläpitäjän kysyminen, kuka on hakemassa sitä.

22.5.11 aikakatkaisu

Aikakatkaisu rajoittaa yhden haun.

Oletusarvo on kaksi minuuttia.

22.5.12 emit_on_first_poll

EmitOnFirstPoll lähettää viestit kaikista ensimmäisen haun löytämistä.

Oletusarvo on epätosi.

Epätosi on merkittävä. Osoittaminen tätä arkistoon, joka jo pitää miljoona tutkimusta, ja sen lähettäminen viesti kullekin niistä, ei ole hyödyllinen ensimmäinen suoritus, ja se on virhe, joka huomataan alavirrassa eikä täällä. Ensimmäinen haku merkitsee, mitä on olemassa, ja ei lähettä mitään; toinen haku alkaen raportoi, mitä on uutta.

22.6 DICOM-lähde

DICOM-lähde vastaanottaa kuvantamistiedostoja C-STORE-palveluluokan tarjoajana.

Se, mihin sairaala osoittaa laitteen tai kuvantamisjärjestelmän. Mirth kutsuu tätä DICOM-kuuntelijaksi, ja se tekee vain C-STORE-toiminnon, joten tämä on tasapuolisuutta eikä alijoukkoa.

Määritelty DICOMSource-nimisenä internal/config-tiedostossa.

22.6.1 kuuntele

Kuuntele on osoite, jota palvelin kuuntelee.

Vaadittu. 104 on rekisteröity DICOM-portti; 11112 on yleinen vaihtoehto, kun etuoikeutetun portin sitominen ei ole mahdollista.

22.6.2 ae_title

AETitle on se nimi, jolla tämä päätepiste kutsuu itseään.

Vahvasti suositeltu, vaikka ei välttämätöntä, ja varoitetaan poissaolosta. Sivuston ainoa päätepisteen pääsykontrolli on usein AE-nimi, joten päätepiste, joka hyväksyy minkä tahansa nimen, hyväksyy kaiken, minkä saa tavoittaa.

22.6.3 allowed_calling_ae

AllowedCallingAE luettelee sallitut AE-nimet, jotka voivat muodostaa yhteyden.

Tyhjä luettelo hyväksyy minkä tahansa soittajan.

Tämä on DICOMin todellinen pääsykontrolli. PACS on yleensä konfiguroitu hyväksymään yksi nimetty soittaja ja hylkäämään kaikki muut, ja tässä päässä ei ollut vastaavaa: haettu nimi tarkistettiin - joka on se nimi, jonka soittaja valitsee, joten kuka tahansa voi lähettää sen oikein - kun taas soittajan nimi kirjattiin lokitiedostoon ja muutoin jätettiin huomiotta.

Tyhjä luettelo hyväksyy edelleen kaiken, koska modality, jota kukaan ei ole luetellut, on normaali tila ensimmäisessä asennuksessa, ja oletusarvoisesti estäminen rikkoisi jokaisen käyttöönoton ensimmäisenä päivänä. Sen sijaan varoitetaan, ja varoitus mainitsee nimet, jotka ovat yhdistyneet, jotta joku voi täyttää tämän tiedon siitä, mitä on todella saapunut.

22.6.4 sop_classes

SOPClasses rajoittaa hyväksyttyjä objektien tyyppejä.

Tyhjä luettelo hyväksyy minkä tahansa.

Tyhjä on järkevä oletusarvo tässä, koska tämä moottori välittää objekteja sen sijaan, että tulkitsee niitä, joten tutkimattoman luokan hylkääminen hylkäisi vain validit kuvat ilman hyötyä.

22.6.5 transfer_syntaxes

TransferSyntaxes rajoittaa hyväksyttyjä koodauksia, järjestyksessä.

Tyhjä luettelo hyväksyy pakkaamattomat kolme.

22.6.6 max_object_bytes

MaxObjectBytes asettaa ylärajan yhden vastaanotetun objektin koolle.

Nolla asettaa oletusarvon.

22.6.7 idle_timeout

IdleTimeout sulkee yhteyden, joka on mennyt hiljaiseksi.

Nolla tarkoittaa ei koskaan, mikä on yleensä oikein - modaliteetti pitää yhteyden auki tutkimusten välillä.

22.6.8 tls

TLS salaa saapuvat yhteydet ja voi vaatia asiakasvarmenteen.

On syytä mainita selvästi: Mirth tarvitsee maksullisen SSL Manager -laajennuksen tähän, ja yhteisöforkit eivät voi toimittaa sitä ollenkaan. DICOM sisältää potilasnimet metatietoihinsa, joten tämä on yksi paikoista, joissa olla uudelleenkirjoitus forksin sijaan on todellinen etu tyylin sijaan.

22.7 DICO Mweb Lähde

DICOMwebSource hyväksyy STOW-RS-pyynnöt.

Määritelty DICOMwebSource-na internal/config: ssä.

22.7.1 kuuntele

Kuuntele on osoite, jota palvelin kuuntelee.

Required.

22.7.2 polku

Polku on palvelun juuri.

Objektit hyväksytään Polku/tutkimukset ja Polku/tutkimukset/{uid}: ssä. Oletusarvo on /dicom-web, jota Orthanc ja dcm4chee käyttävät, joten lähettäjä, joka on määritetty jompaakumpaa varten, tarvitsee vain isäntänimi muutettuna.

22.7.3 token

Token, kun se on asetettu, vaaditaan bearer-merkkinä.

Käyttäjänimi ja salasana vaativat HTTP-perusautentikointia.

22.7.4 käyttäjänimi

Token, kun se on asetettu, vaaditaan bearer-merkkinä.

Käyttäjänimi ja salasana vaativat HTTP-perusautentikointia.

22.7.5 salasana

Token, kun se on asetettu, vaaditaan bearer-merkkinä.

Käyttäjänimi ja salasana vaativat HTTP-perusautentikointia.

22.8 Tietokantalähde

DatabaseSource lukee rivit tietokannasta ja muuttaa kunkin niistä viestiksi.

Tämä on tapa, jolla monet sairaalaliitännäiset tosiasiallisesti alkavat. Osastojärjestelmällä ei ole HL7-kapasiteettia, joten joku kirjoittaa rivit väliaikaiseen taulukkoon ja liitäntämootorin kysely.

Se on myös yleisin tapa, jolla Mirth-kanava jumittuu, ja syy on lähes aina sama: rivi, jota ei voida prosessoida, luetaan, epäonnistuu ja luetaan uudelleen ikuisesti, koska mitään ei ole merkitty. Kanava näyttää elävältä. Jonossa näyttää olevan tyhjä. Mitään ei liiku, ja jokainen viesti huonon rivin takana odottaa rivia, joka ei koskaan onnistu.

Suurin osa suunnittelusta tässä on siitä.

Määritelty DatabaseSource-na internal/config: ssä.

22.8.1 ajuri

Ajuri nimeää tietokannan.

See SupportedDrivers.

22.8.2 dsn

DSN on yhteysmerkkijono.

Suosittelemme ympäristömuuttujan viittausta kirjaimellisen arvon sijaan, koska tämä sisältää yleensä salasanan ja kanavat on tarkoitettu olevan Gitissä.

22.8.3 kysely

Kysely valitsee rivit, jotka odottavat lähetystä.

Required.

Se on oltava SELECT-kysely. Äänetön kirjoitus, joka suoritetaan aikataulun mukaan, ei jätä jälkeensä mitään muistiinpanoja siitä, mitä se muutti.

22.8.4 after_query

AfterQuery merkitsee rivin käsitellyksi ja suorittaa sen rivin avaimen kanssa.

Strongly recommended.

Ilman tätä jokainen kysely lukee uudelleen jokaisen rivin, joka kysely edelleen vastaa, joten itse kyselyyn on löydettävä tapa poistaa käsitellyt rivit. Jos kumpaakaan ei ole totta, kanava lähettää samat rivit loputtomiin, mikä on duplikaattimyrsky eikä tukos, ja se on perusteltavasti huonompi.

22.8.5 avain_sarake

AvainSarake tunnistaa rivin AfterQuery:lle, karanteenille ja duplikaattien poistamiselle.

Vaaditaan, kun AfterQuery on asetettu.

22.8.6 malli

Malli rakentaa viestin rivistä.

Joko tämä tai Sarake on vaadittu.

Sarakkeen viittaukset käyttävät ${sarakkeen_nimeä}. Puuttuvat sarakkeet ovat virhe loadauksessa eikä tyhjä merkkijono kliinisessä viestissä.

22.8.7 erä_koko

EräKoko asettaa ylärajan rivien määrälle kyselyssä.

Defaults to 100.

Rajoitettu, koska rajoittamaton ensimmäinen kysely taulukkoon, jota joku on täyttänyt vuoden ajan, lukee koko sen muistiin ja lähettää sen, mikä on tapa, jolla migratio tulvii live-vastaanottajaa.

22.8.8 max_yritykset

MaxYritykset on montako kertaa yksittäinen rivi saa epäonnistua ennen kuin se karanteenissa ja kysely siirtyy eteenpäin.

Defaults to 3.

Tämä on asetus, joka estää tukkeutumisen. Ikuiset uudelleenyritykset eivät ole kestävyyttä; se on yksi huono rivi, joka pysäyttää sairaalavirran.

22.8.9 kysely_aikakatkaisu

KyselyAikakatkaisu asettaa yksittäisen kyselyn ylärajan.

Defaults to 30s.

22.9 Suora Lähde

SuoraLähde vastaanottaa Suoran postin, jonka HISP toimittaa: SMTP-kuuntelija tämän osoitteen postille.

Jokainen viesti salakirjoitetaan, sen allekirjoitus tarkistetaan ankkureita ja allekirjoittajaa vastaan From, ja sen sisältö välitetään eteenpäin: XDM-paketin asiakirjat, muutoin jokainen liite, muutoin teksti.

Määritelty DirectSource-nimisenä internal/config-tiedostossa.