1 Introduzione

Perfuse sposta messaggi clinici tra sistemi che non sono stati progettati per comunicare tra loro. Un laboratorio invia risultati in HL7 v2; il sistema di gestione della pratica si aspetta di riceverli con posizioni di campo diverse, un identificatore di paziente diverso e un acknowledgement entro cinque secondi. Qualcosa deve essere posizionato al centro, e quel qualcosa è un motore di integrazione.

Questo manuale descrive cosa fa Perfuse, ogni opzione che accetta e — dove una decisione non è ovvia — perché funziona in quel modo.

1.1 A cosa serve Perfuse

Un'interfaccia singola tra due sistemi clinici è solitamente costosa, con un prezzo che varia dalle decine di migliaia di euro, con il 15-20% di quel costo aggiuntivo ogni anno per la manutenzione. Gran parte di quel costo non è il lavoro; è che il lavoro richiede qualcuno che abbia già lavorato con HL7, e la maggior parte delle pratiche non assume qualcuno con queste competenze.

Perfuse è stato costruito sull'assunzione che la persona che lo configura abbia un problema da risolvere e non abbia esperienza precedente con HL7. Quell'assunzione si manifesta in luoghi specifici:

• Tutto è configurabile dall'interfaccia web. Una funzionalità raggiungibile solo da un terminale o da un file modificato manualmente è trattata come un difetto, non come una scelta di progettazione.
• I messaggi possono essere tracciati un trasformazione alla volta, mostrando cosa ogni passaggio abbia letto, cosa abbia modificato e cosa abbia saltato e perché.
• È possibile generare traffico di test che corrisponda alla forma di un flusso reale senza contenere alcun dato.
• Un canale può essere proposto da un singolo messaggio di esempio, con una dichiarazione esplicita di cosa il campione non possa dirti.
• Prima di sostituire un motore esistente, la sua uscita e quella di Perfuse possono essere confrontate messaggio per messaggio, con le differenze raggruppate per campo.

1.2 Cosa contiene

Tutto ciò che segue è nel singolo file binario. Ogni riga nomina il capitolo che lo copre.

• Formati. HL7 v2, FHIR R4, R4B e R5, DICOM, X12 (837, 835, 270/271, 276/277, 834, 278, 275), C-CDA e CDA, HL7 v3, NCPDP Telecommunication e SCRIPT, SMART Health Links e Cards, delimitati e grezzi. Vedi formati di messaggio.
• Collegamenti. 28 tipi di sorgente e 32 tipi di destinazione, tra cui MLLP, file, SFTP, database, DICOM, Kafka, AMQP 1.0, MQTT, IBM MQ e archiviazione e messaggistica AWS, Azure e Google Cloud. Vedi la documentazione della sorgente e la documentazione della destinazione.
• Modifica dei messaggi. Filtri, undici passaggi di trasformazione dichiarativi, JavaScript (incluso il dialetto di Mirth) e Lua, tabelle di mappatura condivise e insiemi di codici, e suggerimenti di mappatura. Vedi filtraggio e trasformazione.
• Consegna. Una coda durevole e ordinata per destinazione, ritentativi, lettere morte che mantengono il messaggio e conferme inviate dopo la consegna. Vedi consegna e conferme.
• Monitoraggio. Dashboard, dashboard di squadra, mappa di flusso, undici tipi di allarme, metriche, tracciamento e un archivio di messaggi che trova i messaggi di un paziente tra formati. Vedi allarmi, l'archivio di messaggi e debugging.
• Modifica di un'interfaccia live in modo sicuro. Modalità ombra, contratti di alimentazione, test di canale e confronto del motore. Vedi testing.
• Abbandono di Mirth. Canali Mirth, Open Integration Engine e BridgeLink spiegati, tradotti ed esportati nuovamente. Vedi migrazione.
• Pagatori e sanità pubblica. Le quattro API CMS-0057, Da Vinci CRD, DTR, PAS, PDex e Plan-Net, CARIN Blue Button, un servizio di decisione opzionale, eCR e ELR. Da Vinci CRD, DTR e PAS rispondono sia alle loro versioni 2.2.x che 2.1.0. Vedi CMS-0057.
• Chi può fare cosa. SAML, OpenID Connect, LDAP, passkeys, SCIM, TLS reciproco, sei ruoli, gruppi di canali con un ruolo in ciascuno, tenant, un server di autorizzazione SMART, TEFCA e UDAP e un registro di audit. Vedi sicurezza.
• Esecuzione. Un binario statico per Linux, macOS e Windows, come servizio, con una visualizzazione della flotta di più server. Vedi operazioni, l'interfaccia web, la riga di comando e opzioni del server.

1.3 Standard e versioni

Quale versione di ogni standard Perfuse implementa e come è stata verificata. "Verificata" nomina lo strumento o la fonte esterna che ha giudicato il risultato; se nulla all'esterno lo ha giudicato, dice così. I risultati provengono da dati di test, non da un sito di produzione.

1.3.1 Messaggistica e documenti

1.3.2 Guide all'implementazione di FHIR

1.3.3 Profili nazionali e europei

Verificato convertendo messaggi HL7 v2 pubblicati o inventati e convalidando ogni risorsa; i risultati completi e le ragioni di ogni fallimento sono nella cartella conformance/national del repository.

Nessuno di questi è un certificato. Perfuse non è stato certificato da ONC, CMS, gematik, Nictiz, NHS England o da chiunque altro.

1.4 Cosa sostituisce

Perfuse copre il terreno occupato da Mirth Connect e può importare direttamente le esportazioni dei canali Mirth. Il capitolo su migration descrive cosa si traduce in modo pulito, cosa richiede una decisione e come dimostrare che il risultato corrisponde prima di passare alla versione definitiva.

Le differenze che contano nell'uso quotidiano sono il debugging e il silenzio. In Mirth, vedere cosa un trasformatore abbia fatto a un messaggio solitamente significa ridistribuire il canale con la registrazione aggiunta. In Perfuse, qualsiasi messaggio registrato può essere riprodotto attraverso la configurazione corrente e ispezionato passo dopo passo, senza toccare il canale in esecuzione. E dove un allarme Mirth su "nessun traffico" è una soglia fissa che è inutile su qualsiasi flusso che è silenzioso di notte, Perfuse apprende cosa cada flusso normale settimanale sembri e si allarma contro di esso.

1.5 Come leggere questo manuale

I primi capitoli sono concettuali e vale la pena leggerli in ordine: canali, flusso di messaggi, quindi trasformazione. Tutto ciò che segue può essere letto come necessario.

I capitoli di riferimento vicino alla fine elencano ogni chiave di configurazione, il suo tipo, se è richiesta e il valore predefinito. Quei capitoli sono generati dal codice sorgente, quindi non possono descrivere un'opzione che non esiste o omettere una che esiste. Se una chiave appare in un file di configurazione e non nell'indice, non è una chiave di Perfuse.

1.6 Convenzioni

La configurazione è in YAML. La maggior parte delle chiavi sono in snake_case sulla rete — max_message_size, idle_timeout — e questo manuale fornisce sempre la forma sulla rete, perché è quello che si digita. C'è un'eccezione storica, dataType su un canale, che è in camelCase; è documentata in quel modo nel riferimento del canale e accettata solo con quella ortografia.

I riferimenti ai campi in HL7 utilizzano la notazione usuale: PID-5 è il quinto campo del segmento PID, PID-5.1 è il suo primo componente e PID-3(2) è la seconda ripetizione del terzo campo. Un percorso scritto senza una ripetizione si riferisce a ogni ripetizione (vedere percorsi).

Le durate sono scritte come un numero e un'unità — 30s, 5m, 2h. Un numero senza unità non è una durata e verrà rifiutato piuttosto che essere oggetto di congetture.

2 Guida introduttiva

Perfuse è un singolo file eseguibile con un'interfaccia web incorporata. Non c'è un server di applicazioni da installare, non c'è un database da configurare e non c'è una console di amministrazione separata.

2.1 Esecuzione

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

-channels è una directory di file YAML, uno per canale. -db è un file SQLite che contiene i messaggi registrati, gli utenti e la cronologia di audit; viene creato se non esiste.

Al primo avvio senza utenti configurati, viene creata un'account amministratore e la sua password viene scritta nel log una volta. Quella password non è più recuperabile dopo.

2.2 Il primo canale

Un canale necessita di un nome, una sorgente e almeno una destinazione. Il più piccolo canale utile riceve HL7 su MLLP e scrive ogni messaggio su un file:

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

Salva ciò come channels/first-feed.yaml e verrà caricato senza riavvio.

Tre cose di quel file sono degne di nota, perché sono la forma di ogni canale:

• Il blocco sorgente è piatto per MLLP. listen si trova direttamente su source, non all'interno di un blocco source.mllp. I trasporti che necessitano di più di un indirizzo — HTTP, SOAP, DICOM — hanno il loro proprio blocco secondario, e quelli sono elencati nel riferimento della sorgente.
• Una destinazione file necessita sia di root che di dir. root è il confine che i percorsi sono risolti contro e non possono uscire; dir è dove i messaggi arrivano all'interno di esso.
• Non c'è trasformazione e non c'è filtro. Entrambi sono opzionali, e un canale con nessuno dei due passa semplicemente i messaggi.

2.3 Creare un canale dall'interfaccia

Tutto ciò che è stato fatto sopra può essere fatto dall'interfaccia web invece, e per un primo canale è la via migliore perché il modulo non ti lascerà produrre un file che non carica.

Il costruttore offre tre modi per iniziare:

1. Da un messaggio che qualcuno ti ha inviato. Incolla il campione che il laboratorio o il fornitore ti ha inviato via email. Perfuse legge e propone un canale, insieme a tre elenchi separati: ciò che il campione mostra, ciò che è stato indovinato e ciò che nessun campione può dirti. Ciò è descritto in testing.
2. Da qualcosa che già funziona. Un set di canali completi che necessitano solo degli indirizzi compilati.
3. Da nulla. Un modulo vuoto. Disponibile, ma è il più lento dei tre e il più facile da sbagliare.

2.4 Verificare che funzioni prima di collegare qualcosa

Due cose possono essere fatte prima che il sistema di invio esista.

Inviare un messaggio a mano dall'interfaccia — il mittente del messaggio accetta testo incollato e riporta cosa gli è successo, compresi quali destinazioni l'hanno accettato e cosa ogni trasformazione ha fatto.

O generare traffico di test. Se il canale ha gestito alcuni messaggi, Perfuse può imparare la loro forma e produrre più messaggi simili, nelle stesse proporzioni, senza alcun contenuto originale. Vedi testing.

2.5 Cosa fare dopo

• Canali spiega cosa è un canale e come si incastrano le sue parti.
• Flusso di messaggio segue un messaggio dall'arrivo alla consegna, che è il modo più veloce per capire dove inserire una modifica.
• Allarmi vale la pena configurarli prima che un flusso vada live piuttosto che dopo il primo incidente.

3 L'Interfaccia Web

Perfuse è costruito sull'assunzione che tutto sia possibile da eseguire dal browser e una funzionalità che può essere raggiunta solo modificando un file è trattata come un difetto. Questo capitolo è una panoramica di ciò che si trova dietro ogni parte della navigazione, organizzato nel modo in cui è l'interfaccia: per la domanda che si sta ponendo.

La barra contiene Dashboard e Canali direttamente, perché sono dove la maggior parte delle sessioni inizia e termina. Tutto il resto è raggruppato e i gruppi sono nominati dopo le domande piuttosto che dopo i sottosistemi — non si va al "sottosistema di audit", si va a scoprire chi ha modificato qualcosa.

3.1 Lettura dell'intestazione

Ci sono cinque cose nell'intestazione che è facile perdere.

Ogni vista ha un indirizzo. La barra degli indirizzi segue la vista — #/channels, #/messages, #/settings — quindi un reload ritorna ad esso, un segnalibro lo apre, un collegamento inviato a un collega li porta su di esso e il pulsante indietro si sposta tra le viste invece di uscire dalla console. Un indirizzo che nomina una vista al di sopra del proprio ruolo apre il cruscotto invece.

Ricerca, o ⌘K. Cerca attraverso canali, impostazioni, messaggi e il manuale, il che significa che è solitamente più veloce della navigazione — in particolare per un'impostazione il cui nome si ricorda a metà.

Tema. Tre di essi: Midnight, Dark e Light. Midnight è quasi nero ed è ciò che una visualizzazione a muro in una stanza dei server di solito vuole; Dark è un grigio neutro più morbido; Light è per un laptop accanto a una finestra. La scelta è archiviata nel browser piuttosto che contro l'account, perché un tema è una proprietà di dove qualcuno si trova, non di chi è — lo stesso operatore vuole Midnight sul muro e Light sul treno. La preferenza della macchina stessa viene consultata una volta, per scegliere un default sensibile la prima volta.

Lingua. La console in inglese (ordine di data UK o US), tedesco, francese, olandese, spagnolo, italiano, portoghese, polacco, svedese, danese, norvegese o finlandese, con date e numeri scritti nel modo in cui la locale li scrive. La scelta viene mantenuta nel browser e la lingua del browser viene utilizzata fino a quando non se ne sceglie una. Le traduzioni sono state eseguite da una macchina e non sono ancora state revisionate da madrelingua; l'inglese è il riferimento e il selettore lo indica. Il codice, i messaggi, i payload, i nomi dei canali e tutto ciò che viene digitato non vengono mai tradotti. Il manuale viene pubblicato nelle stesse lingue all'indirizzo https://perfuse.health/manual/<language>/ (il Manuale di questo server è quello inglese).

Manuale. Il documento che si sta leggendo, servito dal server in esecuzione. È lo stesso file che il binary può scrivere su disco, quindi descrive sempre la versione di fronte a voi piuttosto che l'ultima versione rilasciata.

3.2 Monitor — se funziona e cosa è successo

3.2.1 Dashboard

Lo stato di ogni canale, il throughput e tutto ciò che è attualmente sbagliato. Questo è lo schermo da lasciare aperto.

3.2.2 Messaggi

Ogni messaggio che è arrivato, cosa è stato trasformato, per destinazione e cosa gli è successo. Ricerchabile, compreso tramite un'espressione di filtro, quindi "mostrami quelli da questo mittente che sono stati rifiutati" è una query piuttosto che un pomeriggio.

Un messaggio può essere riprodotto da qui e rielaborato attraverso la *configurazione corrente* piuttosto che quella che era live al momento — che è il modo in cui si conferma che una correzione funziona contro il traffico che lo ha rotto. Vedi l'archivio di messaggi per cosa viene mantenuto e per quanto tempo.

3.2.3 Coda

Cosa sta aspettando di essere consegnato e perché. Una coda che non si svuota è l'avvertimento precoce più utile che un motore di integrazione produce e vale la pena accoppiarlo con una regola di allarme in modo che nessuno debba essere in ascolto. Vedi consegna.

3.2.4 Allertamenti

Cosa è stato attivato e quali sono le regole. Le regole vengono modificate qui piuttosto che in un file. Vedi allarmi.

3.2.5 Metriche

Throughput, latenza e tassi di errore nel tempo. Utile per le domande di capacità e, più spesso, per i pacchetti di amministrazione — il che è il motivo per cui il logo del sito appare su di esso se ne è stato caricato uno.

3.2.6 SQL su FHIR

SQL su viste FHIR: seleziona un esempio o una vista salvata, o scrivine una, eseguila sullo store FHIR di questo server (tutti i pazienti o uno) o su risorse incollate, vedi le righe con i loro tipi e scarica CSV, NDJSON o Parquet. Salva la conserva per l'endpoint FHIR $sql-run. Vedi formati di messaggio.

3.2.7 Misure di qualità

Misure di qualità digitali: seleziona un esempio o una Misura nello store FHIR, o scrivine una con criteri FHIRPath. Scegli un periodo di misurazione e un report (riassunto, riassunto con elenchi di pazienti o un paziente) e valuta su lo store FHIR o risorse incollate. Lo schermo mostra il conteggio di ogni popolazione e i pazienti, il punteggio e gli strati. Scarica MeasureReport salva il risultato FHIR e Salva nello store FHIR conserva la Misura per Measure/$evaluate-measure. Le Misure in CQL sono rifiutate: Perfuse non ha un motore CQL. Vedi misure di qualità digitali.

3.2.8 Mappa del flusso

Un'immagine di come i messaggi si muovono effettivamente: quali sorgenti alimentano quali canali e quali destinazioni raggiungono.

Il suo valore non è una decorazione. Ogni proprietà accumula un canale che nessuno ricorda di aver commissionato e una destinazione che nessuno si è reso conto di essere ancora in ricezione, e entrambi sono visibili qui in un modo che non lo sono in un elenco di file di canali.

3.2.9 Cruscotti di squadra

Un dashboard per ogni tipo di persona che guarda le interfacce: Operazioni, Connessioni, Analista di interfaccia, Autorizzazione preventiva, Imaging, Ciclo di fatturazione, Laboratorio, Privacy e sicurezza e un riassunto del dipartimento in parole semplici. I riquadri mostrano conteggi, stati e tempi, mai un messaggio o un paziente, quindi un dashboard può essere inviato a un manager o a uno schermo di parete senza allargare chi vede i dati dei pazienti.

Ogni persona apre il cruscotto del proprio gruppo di directory o ruolo. -dashboards dashboards.yaml li mappa:

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

Un gruppo vince su un ruolo e chiunque non corrisponda si apre su Operazioni. Organizza riquadri nasconde e riordina i riquadri, il selettore di canale li filtra e Salva come mia vista li conserva come proprio dashboard fino a Reset.

Esporta in Grafana scarica il cruscotto come JSON di Grafana su /metrics, con una variabile di origine dei dati e un filtro di canale, per chiunque abbia bisogno di più della configurazione leggera. I riquadri senza metriche alle spalle vengono esclusi e la descrizione dell'esportazione nomina questi ultimi.

La piastrella Connessioni controlla ogni destinazione in rete in strati. Cerca il nome, apre una connessione TCP, completa il TLS dove viene utilizzato e legge l'ultimo recapito e fallimento del destinatario dal traffico reale. Ogni fallimento indica cosa significa, ad esempio "rifiutato: il motore del partner è probabilmente fermato", "scaduto: un firewall o un tunnel VPN che è down" o "un certificato da un'autorità che questo server non si fida". Nulla viene inviato al partner, con un'eccezione: un registro di immunizzazione che non ha avuto traffico per sette giorni viene chiesto il suo CDC connectivityTest, che non invia nulla. Con -vpn tunnels.yaml la piastrella Tunnel VPN accanto ad esso legge lo stato di ogni tunnel del partner da AWS Site-to-Site VPN, una connessione Azure VPN Gateway o strongSwan su questo host, in modo che un timeout possa essere distinto da un tunnel che è down. Confronta anche le impostazioni IKE e IPsec di entrambi i lati, poiché la nuvola segnala le nostre e il file elenca le loro, e indica dove non possono concordare. La scheda di connessione scarica le impostazioni di un partner affiancate come Markdown per inviarle; non memorizza mai una chiave condivisa pre-condivisa. Le figure che un dashboard necessita che non sono ancora registrate vengono elencate sotto Non misurate ancora invece di essere disegnate come piastrelle vuote.

I cruscotti di dipartimento calcolano le proprie figure sul server, e ognuno dice quale finestra e quale sorgente copre:

• Autorizzazione preventiva: richieste PAS decise entro 72 ore (accelerato) o 7 giorni (standard) di CMS-0057, decise in ritardo, in attesa e scadute adesso, con il tempo mediano di decisione. Inoltre, come sono state risposte le richieste di servizi (approvate, modificate, negate, sospese), come stanno adesso, nell'arco di 30 giorni.
• Immagini: oggetti ricevuti da C-STORE per modalità e quelli non consegnati. Inoltre, il ritardo di routing per canale (mediana e percentuale del 95%), query C-FIND e fallimenti per canale di query, e referti di immagini (un ORU il cui OBR-24 è una sezione di immagini o un MDM) che non hanno raggiunto ogni destinazione.
• Ciclo di fatturazione: insiemi di transazioni 999 accettati, accettati con errori e rifiutati, e richieste di rimborso 277CA accettate e rifiutate (A3, A4, A6, A7, A8). Inoltre, richieste di rimborso 835 abbinate al numero di account del paziente alle 837 inviate tramite questo server e le ragioni di rifiuto più comuni.
• Laboratorio: tempo di consegna dei risultati, dalla ricezione all'acknowledgement dell'ultima destinazione, e risultati critici (OBX-8 HH, LL, AA, > o <) che non hanno raggiunto ogni destinazione.
• Privacy e sicurezza: chi ha aperto messaggi, cercato pazienti o letto autorizzazioni preventive nella console negli ultimi 7 giorni, dal registro di audit (l'apertura di un messaggio è registrata come message.read). Inoltre, ogni token API attivo e quando è stato utilizzato l'ultima volta; un token non utilizzato per 90 giorni è contrassegnato.

3.2.10 Condividere cosa contiene effettivamente un flusso

Profilo di questo flusso segnala cosa sta realmente arrivando: quali eventi di trigger, quali campi sono popolati e con quale frequenza, quali forme assumono i valori, e quali codici un mittente utilizza effettivamente. Quell'ultimo è di solito il fatto più utile in esso.

Un profilo può essere scaricato e inviato a qualcun altro. Ha bisogno di un nome e — obbligatorio — quale sistema ha prodotto il flusso, perché la domanda che uno sconosciuto fa a un profilo condiviso è se descrive il proprio sistema, e un campo opzionale renderebbe "Sconosciuto" la risposta più comune in qualsiasi raccolta condivisa.

Non contiene dati del paziente, e ciò viene verificato piuttosto che assunto. Un profilo è statistico: conteggi, tassi, lunghezze, forme. I valori vengono mantenuti solo per i campi che lo standard definisce come tabelle di codici, perché un valore della tabella dei codici non è identificativo. I valori degli identificatori non vengono mai elencati.

Due a questo essere una promessa piuttosto che una speranza, seguono due cose. Il server ricostruisce il profilo dai messaggi archiviati quando lo esporti, piuttosto che inviare quello visualizzato sullo schermo — quindi ciò che esce dall'edificio è stato assemblato dal profiler, che ha un test che prova questa proprietà, e non da un browser. E l'esportazione rifiuta categoricamente se un profilo elenca mai valori per un campo che non è una tabella di codici, nominando il campo ma non i valori.

Un profilo che arriva da altrove viene controllato allo stesso modo all'ingresso, per un motivo diverso: è stato prodotto da qualcuno la cui cura è sconosciuta, e mostrare gli identificatori dei suoi pazienti sarebbe una violazione di questa server. Importare uno non cambia nulla — un profilo descrive un feed, e decidere cosa farne è una decisione separata.

3.3 Crea — modifica cosa fa un canale e prova prima che sia attivo

3.3.1 Canali

Il costruttore di canali. Sorgenti, destinazioni, filtri, trasformazioni, script e test, con il file YAML generato visualizzato accanto al modulo mentre si lavora — quindi il file non è mai un mistero, e chiunque preferisca il file può leggere insieme.

Vedi canali per cosa sono le parti e trasformazione per cosa fanno i passaggi.

3.3.2 Script

Un'area di lavoro per script, separata dal costruttore perché scrivere uno script e collegare uno script sono attività diverse.

Tutti e sette gli slot sono offerti — filtro, trasformatore, pre-elaboratore, post-elaboratore, scrittore, ciclo di vita e lettore — e scegliere quello giusto è importante, perché lo slot decide cosa lo script riceve e cosa si aspetta che restituisca. Controllare uno script come il tipo sbagliato non è una soluzione; compila una cosa diversa.

Sono disponibili JavaScript, Lua e WebAssembly. Vedere transformation.

3.3.3 Contratti

Aspettative su come debba apparire un feed, create e verificate qui, nonché da perfuse contract. Vedi la riga di comando.

3.3.4 Tabelle

Tabelle di ricerca e set di codici: le mapping che trasformano i codici di un sistema in quelli di un altro. Modificabili qui in modo che aggiungere un codice non sia una distribuzione.

3.3.5 AI Mapper

Propone mapping di campi con un punteggio di confidenza per ciascuno e si astiene dal fare supposizioni. Nonostante il nome, non utilizza alcun modello linguistico e non effettua alcuna chiamata di rete: le suggerimenti provengono da regole, nomi di campi e contenuti del campione, su questo server. Propone inoltre un canale da un singolo messaggio di esempio e afferma esplicitamente cosa il campione non può dirgli. Questa seconda parte è quella che lo rende affidabile - una proposta che sembra completa potrebbe invitarti a credere a cose che il messaggio non ha mai detto.

3.3.6 Area di prova

Un blocco note per messaggi e trasformazioni. Incolla un messaggio, applica passaggi, vedi il risultato.

Nessun messaggio viene inviato da nessuna parte una volta caricata la pagina, che è il motivo per cui esiste in questa forma: è sicuro incollare qualcosa di reale, con la comprensione che rimane nel browser.

3.3.7 Ombra

Esegue il traffico attraverso una configurazione candidata accanto a quella live e segnala le differenze, in modo che una modifica possa essere dimostrata prima di essere considerata attendibile. Lo stesso concetto di perfuse compare, applicato a una modifica piuttosto che a una migrazione. Vedi testing.

3.4 Scambio — gli standard che questo server parla ad altre organizzazioni

3.4.1 Laboratorio FHIR

Converte HL7 v2 in FHIR, convalida una risorsa e ispeziona il risultato. I campioni coprono ammissioni, risultati di laboratorio, appuntamenti, note cliniche, immunizzazioni e una visita segnalabile. La convalida include US Core, che è il profilo contro cui è scritta la regolamentazione americana, quindi questo risponde a "è ciò che ci hanno inviato effettivamente conforme" senza adottare nulla.

Caso di report pubblico costruisce l'eCR eICR che una destinazione di segnalazione dei casi invierebbe per il messaggio. Mostra quale codice di attivazione ha reso la visita segnalabile, cosa il report doveva contrassegnare come mancante e il documento stesso. Un messaggio con nulla di segnalabile ottiene il motivo al posto suo. Nulla viene inviato da qui.

3.4.2 Abbonamenti

Abbonamenti FHIR e se le loro notifiche stanno arrivando: eventi, accettati, in attesa e l'ultimo motivo per cui uno è stato rifiutato. Gli abbonamenti sono creati da client FHIR attraverso l'API FHIR, non da questa pagina, e le credenziali che hanno fornito al server non vengono mai visualizzate. Vedere formati di messaggio.

3.4.3 Documenti

Documenti clinici — CDA e la forma stampabile di un documento. Utile quando l'oggetto scambiato è una sintesi di dimissione piuttosto che un messaggio.

3.4.4 Condivisione di documenti

Il registro e il repository IHE XDS.b iniziato con -xds: quanti documenti, pazienti e insiemi di invio contiene e quanti sono stati sostituiti; gli indirizzi del repository, del registro, della porta XCA e di MHD; una ricerca dei documenti di un paziente in questo registro o in un altro della comunità (un registro ITI-18 o una porta ITI-38, con un token per esso); e la pubblicazione di un documento CDA a mano, con il tipo di struttura e l'impostazione della pratica che un documento non specifica. Vedi formati dei messaggi.

3.4.5 Direct

Messaggistica sicura diretta. Gli indirizzi Direct di questo server elenca ogni indirizzo che un canale invia o riceve, con il suo certificato, quando scade, gli anchor di trust e qualsiasi problema (un file mancante, un certificato scaduto). La Rubrica mantiene i corrispondenti e i certificati con cui la loro posta è crittografata: incolla uno dal loro HISP, o Salva con il certificato da DNS; un certificato che non è per l'indirizzo o il suo dominio viene rifiutato. Trova un certificato in DNS chiede senza salvare. Vedi formati di messaggio.

3.4.6 Collegamenti sanitari

SMART Health Links e Cards, per CMS's *Kill the Clipboard*. Ricevere un link di salute SMART legge il link o il codice QR che un paziente mostra al check-in, verifica le carte di salute all'interno e le invia a un canale. Condividere un record di visita crea un link ospitato da questo server, opzionalmente con un codice di accesso, e un codice QR per il paziente; Utilizzare il riassunto del paziente lo riempie con il riassunto del paziente International Patient Summary dall'archivio FHIR di questo server. Link ospitati da questo server elenca i link con la frequenza di accesso, la data di scadenza e i tentativi di accesso rimanenti, e revoca uno di essi. Verificare una carta di salute SMART controlla la firma e l'emittente della carta in modo autonomo. Vedere CMS-0057 per le opzioni del server necessarie.

3.4.7 Immagini

L'archivio che questo server mantiene quando viene eseguito con -dicomweb-archive: conta degli studi, serie, istanze e spazio utilizzato, l'indirizzo DICOMweb e il blocco di dati di origine per un visualizzatore OHIF, e una ricerca di studio per nome del paziente, ID, accessione e data effettuata con la stessa richiesta QIDO-RS che effettua un visualizzatore. Uno studio si apre alle sue serie e istanze, e un'istanza viene scaricata come file DICOM. Nulla viene renderizzato: Perfuse sposta le immagini e un visualizzatore le visualizza. Senza un archivio, lo schermo indica come attivarne uno. Vedi DICOMweb.

3.4.8 TEFCA

La traccia di audit per lo scambio attraverso una Rete di informazioni sanitarie qualificata, e le regole di utilizzo che la governano.

Due trasporti, in fasi effettivamente diverse, e lo schermo dice quale è quale. Una bandiera che copre entrambi sarebbe errata in qualsiasi direzione fosse arrotondata.

FHIR facilitato è implementato e non ha mai parlato con un QHIN reale. Segue la Procedura operativa standard di Sequoia Project in vigore dall'8 marzo 2026: scopre i metadati UDAP del partner, li verifica, si registra dinamicamente, ottiene un token di accesso che trasporta lo scopo dell'uso e interroga. UDAP è un'infrastruttura a chiave pubblica su OAuth 2.0 — una comunità di fiducia rilascia certificati X.509 ai suoi membri, e un membro si autentica firmando JWT con la chiave privata e allegando la catena di certificati.

Il livello di sicurezza viene verificato contro l'implementazione di qualcun altro, che è l'unica verifica che valga la pena qui. Una registrazione firmata da questa build è stata inviata a un server di riferimento terzo live e rifiutata con unapproved_software_statement — Untrusted: Certificate is not a member of community. Per produrre quella risposta, il server ha decodificato la richiesta, analizzato l'affermazione del software come JWT, verificato la sua firma, percorso la catena di certificati e preso una decisione sulla membership. È la differenza tra essere respinti alla porta e ricevere una lettera illeggibile.

Ciò che rimane non può essere fatto da qui. Il certificato che prova la membership della comunità esce dal processo di onboarding QHIN e non è qualcosa che il software produce. Fino a quando non ne esiste uno, nessuno scambio con un partner reale si completa.

Come un canale chiede. Una destinazione di tipo tefca chiede all'insieme di partner FHIR facilitati nelle Impostazioni, TEFCA (tefca.partnerFHIRBase) per ogni messaggio del paziente: per identificatore quando il messaggio ne ha uno (PID-3, o un identificatore del paziente FHIR), altrimenti per cognome con data di nascita, e mai solo per nome, perché una corrispondenza errata su un nome restituisce il record di un'altra persona senza errore. La destinazione imposta lo scopo di utilizzo (trattamento, pagamento, operazioni, salute pubblica, accesso individuale); uno scopo che il partecipante non dichiara viene rifiutato prima che venga inviato qualcosa. Gli scopi vengono come codici di scambio TEFCA (T-TRTMNT, T-PYMNT, T-HCO, T-PH, T-IAS, sistema urn:oid:2.16.840.1.113883.3.7204.1.5.2.1), o con tefca.purposeCodes: hl7 come codici di utilizzo HL7 per le comunità che li utilizzano. Il Bundle trovato è la risposta della destinazione e può essere passato a un altro canale con results_to. Ogni query, incluse quelle rifiutate, è nella traccia su questo schermo, che nomina il partner.

L'intero percorso, dalla scoperta a un token che il server FHIR del partner accetta, viene testato contro il server di riferimento udap-dotnet (vedi verifica).

L'exchange QHIN-to-QHIN più vecchio costruito sui profili IHE non è implementato. Un tentativo viene rifiutato con un errore che lo dice, e il rifiuto viene registrato come un fallimento. Ciò è deliberato piuttosto che in attesa di una pulizia: un exchange stub che segnala il successo metterebbe voci nella traccia di audit per scambi che non sono mai avvenuti, e una traccia che non è d'accordo con ciò che è accaduto è peggiore di nessuna, perché la traccia è ciò che viene creduto.

In tutto, gli endpoint utilizzati per lo scambio provengono dalla parte firmata dei metadati di un partner, mai dal corpo del documento. Verificare una firma e poi leggere gli endpoint dalla copia non firmata sarebbe un modo elaborato per fidarsi della rete: un attaccante in grado di riscrivere la risposta lascia l'elemento firmato da parte, punta l'endpoint del token al proprio server e raccoglie affermazioni client da tutti coloro che hanno verificato la firma e poi ignorato ciò che copriva.

Un bundle di anchor di trust è richiesto e la sua assenza è rifiutata all'avvio. Verificare i metadati firmati di un partner contro il certificato che è arrivato all'interno di esso prova solo che una parte ha fatto entrambi — un errore che questo codicebase ha fatto in precedenza, in SAML, dove il verificatore ha preferito il certificato incorporato e ha autenticato un attaccante come amministratore mentre ogni test è stato superato. Includere gli intermedi in il bundle: un server UDAP ha bisogno di inviare solo il suo certificato foglia, e il server di riferimento pubblico fa esattamente questo.

3.5 Pagatori — richieste, autorizzazioni preventive, farmaci e regole del pagatore CMS

3.5.1 Richieste e autenticazioni

Crea un allegato di richiesta X12 275 nel formato 006020 adottato da CMS-0053-F, da un C-CDA incollato o un PDF, TIFF o JPEG caricato, e vedi come viene letto. Leggi un 275 e scarica il documento all'interno. Converte una decisione X12 278 in una risposta Da Vinci PAS ClaimResponse. Nulla in questa pagina viene memorizzato o inviato. Vedi formati di messaggio per cosa viene costruito il 275 e cosa non fa.

3.5.2 Farmaci

La formulary dei farmaci caricata con -formulary, e gli standard NCPDP risposti da essa. Formulary elenca i piani e i farmaci con il loro livello e requisiti, e dove si trovano l'API pubblica Da Vinci US Drug Formulary e gli endpoint NCPDP. Controllo del prezzo (RTPB) prezza un farmaco per un membro come richiesta di beneficio prescrittivo in tempo reale: lo stato di copertura, le restrizioni in parole con i loro codici, la quota del membro e del piano, e le alternative più economiche. Autorizzazione preventiva (ePA) invia un'inizializzazione SCRIPT all'endpoint di questo server, visualizza l'insieme di domande come un modulo, invia le risposte e visualizza la decisione; di seguito, ogni caso con dove si trova e se il prescrittor è stato informato, le risposte del caso, un pulsante per inviare nuovamente una decisione non inviata e le figure del farmaco che CMS-0062-P propone. Vedere CMS-0057.

3.5.3 CMS-0057

Il lato pagatore della regola di interoperabilità e autorizzazione preventiva CMS, come cinque strumenti:

• Le quattro API: se Patient Access, Provider Access, Payer-to-Payer e Prior Authorization sono pronte in questa istanza,

e cosa ancora necessita ciascuna.

• Coda di revisione: le richieste PAS in attesa di un operatore, elencate in base alla scadenza, con i documenti inviati per ciascuna; approvare, negare o

certificare meno unità. Vedi la coda di revisione.

• Richieste di rimborso a CARIN BB: un 837 e il suo 835 convertiti in bundle CARIN Blue Button.
• Autorizzazione preventiva a PDex: una risposta PAS convertita in un'autorizzazione preventiva PDex.
• Metriche di autorizzazione preventiva: la pagina delle metriche pubbliche annuali di autorizzazione preventiva, anticipata da un CSV di decisioni.

Le conversioni non memorizzano nulla e non inviano nulla.

3.5.4 Rete allineata CMS

Prontezza per il CMS Interoperability Framework: ogni uno dei suoi 26 criteri, raggruppati come li raggruppa il CMS, con ciò che Perfuse fornisce, se è attivato qui, l'impostazione che lo attiva e cosa deve fare l'organizzazione. I conteggi in alto filtrano l'elenco. Vedere CMS-0057.

3.6 Amministra — chi può fare cosa, e come questo server è configurato

3.6.1 Utenti

Account, ruoli (monitor, viewer, operator, editor, admin) e gruppi di canali. I gruppi di canali di ogni persona vengono modificati direttamente nell'elenco; vuoto significa ogni canale e lab=editor, adt assegna un ruolo diverso in un gruppo. Un amministratore limitato a alcuni gruppi vede solo le persone di quei gruppi. L'intestazione mostra i tuoi gruppi accanto al tuo ruolo quando ne hai alcuni. Vedi security.

Credenziali di macchina sono anche qui. Un token è per una macchina piuttosto che per una persona: non scade e non è influenzato da qualcuno che si disconnette, il che è ciò di cui un server che interpella il suo vicino ha bisogno. Solo un hash viene memorizzato, quindi un token viene mostrato una volta quando viene creato e non può essere recuperato — un database rubato non produce alcun token utilizzabile. Assegnare un ruolo il più basso che faccia il lavoro.

Con MCP attivato, la sezione mostra anche l'indirizzo a cui un agente AI si connette, una configurazione del client da copiare e ogni strumento con il ruolo di cui ha bisogno; rilasciare un token con Lascia che un agente AI agisca con esso gli dà l'ambito mcp:write. Vedi sicurezza.

3.6.2 Tenant

Su un server condiviso, l'elenco dell'operatore della piattaforma di organizzazioni: per ognuna, il numero di canali e la dimensione archiviata accanto ai propri limiti (canali, messaggi al minuto, archiviazione), che sono impostati in posizione. Mostrato solo al ruolo della piattaforma. Vedere security per cosa fa ogni limite.

3.6.3 Certificati

I certificati TLS in uso e quando scadono. Le date di scadenza sono il punto: un certificato scaduto di domenica è una classe di guasto che è interamente prevenibile e di routine non è prevenuto.

3.6.4 Attività

Chi ha modificato cosa, e quando. Ogni modifica di configurazione viene registrata, il che è ciò che rende "ha iniziato a non funzionare martedì" rispondibile.

3.6.5 Protezione dei dati

Le richieste di una persona ai sensi del GDPR e del GDPR del Regno Unito, le richieste di blocco legale, il registro di cancellazione, la conservazione e il registro delle attività di elaborazione; solo amministratori. Vedi protezione dei dati.

3.6.6 Flotta

Ogni istanza Perfuse in una pagina.

Mirth vende questo come un prodotto separato; qui è un file di configurazione e un token di sola lettura. Il motivo per cui vale la pena averlo è limitato e importante: un server morto non sembra uno quieto. Il cruscotto di un'istanza singola non può dirti che un secondo sito ha smesso di segnalare e una vista flotta non può.

3.6.7 Migra

Inserisci un'esportazione di un canale Mirth o OIE e vedere quanti dei tuoi canali funzionerebbero qui senza modifiche. La stessa analisi di perfuse explain e perfuse translate, senza la necessità di un terminale. Vedi migration.

3.6.8 Impostazioni

Ogni impostazione del server, con un controllo per ognuna — comprese quelle che tradizionalmente vivono solo in un file. Ognuna indica se ha effetto immediato o richiede un riavvio e se è stata impostata esplicitamente o se è impostata sul valore predefinito.

Le impostazioni coprono ogni opzione perfuse serve che attiva una funzionalità: l'endpoint FHIR e la sua versione, le API dei pagatori, PAS e le regole CRD, il ponte X12 278, eCR, il server di autorizzazione SMART, TLS e firma, metriche, flotta e VPN. Sono raggruppati come FHIR, Payer, Sanità pubblica, SMART, Sicurezza e così via. Ognuno è visualizzato anche con la bandiera a cui corrisponde.

Riavvio dalla console. Un'impostazione contrassegnata *Richiede riavvio* viene salvata immediatamente ma letta solo quando il server si avvia. Finché alcune sono in attesa, una barra nella parte superiore delle Impostazioni elenca quelle con un pulsante Riavvia il server (l'editor di accesso e i file di impostazioni offrono lo stesso pulsante dopo un salvataggio). Chiede prima, perché ogni canale si ferma per alcuni secondi: ogni canale termina il messaggio che sta gestendo, come fa quando il servizio viene interrotto, e i mittenti rinvianno qualsiasi cosa arrivi nel frattempo. La console attende quindi che il server risponda di nuovo e legge le impostazioni di nuovo. Solo un amministratore può riavviare e ogni riavvio viene registrato nel registro delle attività come server.restart.

Su Linux e macOS, il processo si sostituisce con una copia fresca dello stesso programma e degli stessi argomenti, mantenendo il suo ID di processo, quindi systemd, launchd o un runtime del contenitore non nota nulla. Su Windows, il server si riavvia all'interno dello stesso processo, che mantiene un servizio Windows sotto il gestore dei servizi. Se il server non ha risposto dopo due minuti, la console lo dice; il motivo è nel log del server.

Flag e file di impostazioni. La prima volta che il server si avvia, le flag che gli sono state date vengono scritte nel file di impostazioni. Da allora in poi, il file vince sulle flag, quindi la modifica di un'impostazione viene eseguita nella console (o nel file), non modificando la riga di comando del servizio. Una flag che il file non menziona ancora viene registrata quando il server si avvia con essa. Rimuovere una flag dalla riga di comando in seguito non disattiva la funzionalità: disattivarla nelle Impostazioni.

SNMP ha un pannello sotto le impostazioni: se l'agente sta rispondendo e su quale indirizzo, le reti a cui risponde, quanti alert trap sono stati inviati o non sono riusciti e Scarica il MIB per l'OID di base in uso. I valori vengono impostati sotto Monitoraggio, SNMP.

Branding è qui anche: un sito può impostare il nome del prodotto, un tagline, un colore di accentuazione e caricare un logo. Il logo appare quindi nell'intestazione, nella pagina di accesso, nel cruscotto e negli schermi di reporting. Se non viene caricato, nulla viene sostituito — un'installazione non marchiata rimane non marchiata piuttosto che acquisire una decorazione.

3.7 Cosa significano i colori

Quattro registri e ognuno dice qualcosa di diverso. La distinzione vale la pena di essere dichiarata perché è la differenza tra uno schermo che puoi leggere a colpo d'occhio e uno in cui tutto compete per l'attenzione.

Testo normale è un fatto su come funziona Perfuse. La maggior parte dell'interfaccia. Nulla è colorato per dirti che è importante.

Verde significa che qualcosa è riuscito proprio adesso, a causa di qualcosa che hai fatto. Appare dopo un'azione e non persiste.

Arancione è un avvertimento: vale la pena di saperlo prima di agire e non è un errore. Una funzionalità che non è attivata, un'impostazione le cui modifiche sono registrate, una conversione che approssima piuttosto che riprodurre, un trasporto che Perfuse gestisce ma non può verificare completamente. L'arancione è il colore di "leggi questo prima di continuare".

Rosso significa che qualcosa è sbagliato in questo momento. Un valore che è stato rifiutato, una richiesta che non è riuscita, un certificato che è scaduto, un allarme critico che si sta attivando. Nulla altro lo utilizza.

Quell'ultima regola è il motivo per cui uno schermo non si apre rosso. Il rosso è l'unico colore che porta un'istruzione — fermati, e potrebbe essere qualcosa che hai fatto — e uno schermo che lo spende per la decorazione non ha nulla da dire quando l'input è effettivamente sbagliato. Ciò non è sempre stato vero: lo schermo degli utenti usava un tempo aprire con "il server ha inviato una risposta che non poteva essere letta" su ogni installazione che non aveva configurato le passkey, e lo schermo delle impostazioni contrassegnava i valori registrati con lo stesso colore di uno rifiutato. Un test in web/src/RedMeansWrong.test.ts ora fallisce se una frase che descrive qualcosa di assente o approssimativo viene data uno stile rosso.

All'interno di una casella di codice il vocabolario è diverso. Lì, il rosso è un tipo di token — un nome di segmento HL7, un elemento XML — e non porta alcun giudizio.

4 Canali

Un canale è un flusso di messaggi: da qualche parte arrivano, opzionali modifiche e uno o più posti in cui vanno. È l'unità di configurazione, l'unità di monitoraggio e l'unità di distribuzione. Tutto il resto in Perfuse esiste per servire i canali.

4.1 Anatomia

Un file di canale ha queste parti, nell'ordine in cui hanno effetto:

Più diverse che si applicano all'intero canale: scripts, shadow, contract, tables, attachments, group e enabled. Ognuno è nel riferimento canale.

4.2 Una sorgente, molte destinazioni

Questa asimmetria è deliberata e vale la pena capirla presto, perché è la fonte di confusione più comune quando si proviene da un altro motore.

Un canale ha esattamente una sorgente. Se i messaggi arrivano da due posti, sono due canali. Tentare di esprimerlo come un canale produce una configurazione in cui un errore in uno dei trasporti sembra lo stesso dall'esterno e in cui il traffico dei due feed è mescolato insieme nelle statistiche — quindi una caduta in uno è nascosta dall'altro.

Un canale ha un numero qualsiasi di destinazioni e sono indipendenti. Uno che fallisce non ferma gli altri e ognuno ha la sua propia coda, la sua propia politica di ritentativi e il suo proprio record di consegna. Un messaggio che ha raggiunto tre delle quattro destinazioni è registrato come tale, non come un successo o un fallimento.

4.3 Le destinazioni non sono una catena

Ogni destinazione riceve il messaggio come stava dopo le trasformazioni del canale. Una destinazione non riceve l'output della destinazione precedente.

Ciò è importante quando una destinazione ha le sue propre trasformazioni, cosa che può fare. Queste si applicano solo alla copia di quella destinazione. Un errore comune è mettere un cambiamento sulla prima destinazione e aspettarsi che la seconda lo veda.

Se si ha veramente bisogno di una catena — l'output di un flusso che alimenta un altro — si utilizza una destinazione del canale, che invia a un altro canale per nome. Ciò è esplicito, appare nella storia del messaggio come due canali e può essere monitorato come due cose, cosa che una catena nascosta non può.

4.4 Denominazione

Il nome è l'identità del canale ovunque: nel file, nel message store, negli avvisi, nel registro di controllo e nell'URL. Cambiarlo non è un rinominamento; è un nuovo canale e la storia del vecchio canale rimane sotto il vecchio nome.

group è separato ed esiste per organizzare l'interfaccia. Un gruppo non ha effetto sul comportamento e raggruppare canali non li fa condividere nulla.

4.5 Abilitazione e disabilitazione

enabled: false ferma un canale senza eliminarlo. La sua configurazione, la sua storia e le sue statistiche rimangono.

Un canale disabilitato non è un canale in pausa. La sua sorgente non è in ascolto, quindi un mittente che tenta di connettersi ottiene una connessione rifiutata invece di una connessione bloccata. Per MLLP questo è il comportamento corretto — il mittente metterà in coda e ritenterà — ma significa che il registro degli errori del mittente si riempirà, quindi un canale disabilitato non è un sostituto per organizzare un'interruzione con chi sta inviando.

4.6 Dove vivono i canali

Un file YAML per canale, nella directory data da -channels. Il nome del file non è il nome del canale; la chiave name lo è. È fortemente consigliato mantenerli uguali e nulla li obbliga a farlo.

I file vengono riletto senza riavvio. Un file che non si analizza viene segnalato e la versione precedentemente caricata continua a funzionare, quindi un errore di sintassi non può interrompere un feed funzionante.

4.7 Cifrare l'ascoltatore proprio del canale

Un canale che ascolta su una porta è il suo proprio server e il suo TLS è separato dal TLS sull'interfaccia web di Perfuse. Impostare uno non imposta l'altro. Per una sorgente HTTP le impostazioni si trovano sotto TLS e limiti sulla sorgente.

Attivare il TLS richiede un certificato e una chiave privata. Richiedere un certificato client lo trasforma in TLS reciproco: il mittente deve presentare uno firmato da un'autorità che si nomina, che è un'autenticazione, quindi un listener con esso attivato non ha anche bisogno di un token condiviso — anche se avere entrambi non è sbagliato.

L'autorità viene richiesta solo una volta che viene richiesto un certificato client e viene omessa dal file fino ad allora. Un canale che nomina un'autorità che non viene mai consultata sembra come se i mittenti stessero venendo verificati quando in realtà non lo sono.

Un listener MLLP ha le stesse impostazioni sotto Cifrare questo listener, con una differenza degna di nota: su MLLP un certificato client è l'unica autenticazione disponibile. Non c'è token e non c'è intestazione, quindi un listener senza uno accetta messaggi da qualsiasi host che possa raggiungere la porta.

Due limiti si trovano accanto ad esso. Smettere di leggere dopo una durata, perché un mittente che apre una connessione e smette di scrivere altrimenti la tiene aperta. E messaggio più grande accettato, in byte, perché zero significa nessun limite e il limite è quindi la memoria — un mittente che invia un gigabyte viene rifiutato piuttosto che assorbito.

4.8 Convalida

Un canale viene verificato quando viene caricato e le verifiche sono rifiuti piuttosto che avvertimenti dove l'alternativa sarebbe un canale che funziona e fa la cosa sbagliata.

Esempi di cose rifiutate apertamente: una destinazione senza tipo, una trasformazione che indirizza un percorso che non può esistere nel tipo di dati dichiarato, una modalità di ack che il trasporto di origine non può consegnare e una prescrizione di classe II con riempimenti.

La distinzione che Perfuse cerca di mantenere è che qualsiasi cosa che potrebbe produrre un risultato errato plausibile viene rifiutata e qualsiasi cosa che sia semplicemente insolita viene consentita e segnalata. Un canale che non può essere errato è più prezioso di un canale che inizia.

5 Flusso di messaggi

Questo capitolo segue un messaggio dal momento in cui arriva al momento in cui viene consegnato o abbandonato. Sapere questo ordine è il modo più veloce per capire dove appartiene un cambiamento e perché qualcosa non sta accadendo.

5.1 L'ordine degli eventi

1. Arrivo. La sorgente accetta i byte. Per un trasporto a flusso, ciò include la de-quadrazione — trovare dove termina un messaggio e inizia il successivo.
2. Analisi. I byte diventano un albero in base al tipo di dati (dataType) del canale. Un messaggio che non può essere analizzato si ferma qui e viene registrato come fallimento di analisi.
3. Registrazione. Il messaggio viene scritto nell'archivio dei messaggi così come ricevuto, prima che venga modificato. Ciò rende possibile la riproduzione e l'elaborazione nuovamente.
4. Filtro. Se il canale ha un filtro (filter), decide se accettare il messaggio. Un messaggio rifiutato viene registrato come filtrato, il che è un esito normale e non un errore.
5. Trasformazione. Le trasformazioni (transformations) del canale vengono eseguite in ordine, ciascuna contro il risultato dell'ultima.
6. Distribuzione. Ogni destinazione riceve una copia del messaggio trasformato, applica le proprie trasformazioni se ne ha, e consegna.
7. Registrazione dell'esito. Per ogni destinazione: consegnato, in coda, fallito o filtrato.
8. Conferma. Se la sorgente si aspetta una conferma, viene generata e inviata. Di default, ciò avviene qui, dopo la consegna — vedi sotto.

5.2 Quando viene inviato l'ack

Questo è l'impostazione più importante in un canale, perché decide cosa viene promesso al mittente. È ack.when e ha due valori.

on_delivery è il valore predefinito. L'ack viene inviato solo dopo che ogni destinazione abilitata ha accettato il messaggio. Un ack positivo significa quindi che i dati sono effettivamente arrivati da qualche parte, il che è la promessa più forte che un motore in mezzo può onestamente fare.

on_receipt ack come appena il messaggio viene analizzato e messo in coda, prima che qualsiasi destinazione sia stata scritta.

Perfuse utilizza on_delivery di default perché promettere la consegna e poi perdere il messaggio è peggio che essere lento. Sotto on_receipt, un messaggio che è stato ack può comunque essere perso se il processo muore con lavoro in coda — il mittente crede che sia stato consegnato, nulla a monte lo rinvierebbe e l'unico record che esiste è nel negozio di messaggi di Perfuse.

5.3 Quando scegliere on_receipt

Il caso per esso è reale ed è i timeout. Un mittente MLLP che non riceve un ack entro pochi secondi di solito rinvierebbe, quindi una destinazione lenta sotto on_delivery produce duplicati piuttosto che ritardi. Se una destinazione è un archivio lento o un sistema che è regolarmente non disponibile, on_delivery accoppia il timeout del mittente al caso peggiore di quella destinazione.

Lo scambio è esplicito: on_receipt sposta il rischio dalle duplicazioni alla perdita. Sceglierlo significa accettare che un messaggio confermato possa essere perso in caso di crash, ed è consigliabile abbinarlo con un allarme sulla profondità della coda in modo che venga notata una coda che ha smesso di svuotarsi. Vedi alerting.

5.4 Dove viene registrato il messaggio

Prima del filtro e quindi prima di qualsiasi trasformazione. Tre conseguenze:

• Un messaggio che il filtro ha rifiutato è ancora presente nell'archivio. È possibile vedere cosa è arrivato e confermare che il filtro abbia agito correttamente.
• La riproduzione e l'elaborazione ripetuta partono sempre da ciò che è effettivamente arrivato, non da una versione parzialmente trasformata.
• Una modifica alle trasformazioni può essere testata contro il traffico storico reale, perché l'originale è ancora presente. Vedi testing.

La forma trasformata viene registrata anche, per ogni destinazione, insieme all'esito. Quindi l'archivio contiene ciò che è arrivato, ciò che è stato inviato e cosa è successo — che è ciò di cui ha bisogno un'indagine.

5.5 Guasto a ogni stadio

L'asimmetria importante: un fallimento di analisi è permanente e un fallimento di consegna di solito non lo è. Ritentare un messaggio non analizzabile non servirà a nulla, quindi non viene ritentato. Ritentare una destinazione irraggiungibile di solito servirà, quindi viene ritentato.

5.6 Ordinamento

All'interno di una sola destinazione, i messaggi vengono consegnati nell'ordine in cui sono arrivati, e un messaggio che fallisce e entra nella coda mantiene la sua posizione — i messaggi successivi aspettano dietro di esso invece di superarlo.

Questo è il comportamento predefinito giusto per i dati clinici, dove un ricovero seguito da una dimissione consegnati nell'ordine sbagliato è peggiore che se entrambi fossero in ritardo. Significa anche che un messaggio dannoso può bloccare una coda, ed è per questo che la profondità della coda vale la pena di essere segnalata.

Tra le destinazioni non c'è garanzia di ordinamento, perché sono indipendenti. Due destinazioni non riceveranno necessariamente lo stesso messaggio allo stesso tempo, e una destinazione veloce potrebbe essere diversi messaggi avanti rispetto a una lenta.

5.7 Concorrenza

Una sorgente può gestire più connessioni contemporaneamente, limitate da max_connections. I messaggi da connessioni diverse vengono elaborati contemporaneamente.

Ciò significa che l'ordine di arrivo di due messaggi inviati contemporaneamente su due connessioni non è definito e non può esserlo — sono effettivamente arrivati allo stesso tempo. Un mittente che necessita di ordinamento deve utilizzare una sola connessione, il che è ciò che fanno quasi tutti.

6 Trasformazione

Le trasformazioni modificano un messaggio. Sono una lista, vengono eseguite in ordine e ogni passaggio vede il risultato del passaggio precedente.

Le trasformazioni di Perfuse sono dichiarative: ogni passaggio nomina un'operazione e il campo a cui si applica. Non c'è un linguaggio di scripting nel percorso normale. Questa è una limitazione deliberata e la motivazione è in why not a script di seguito.

6.1 I passaggi

Ogni passaggio accetta anche description, che appare nella traccia e nell'interfaccia, e when, che rende il passaggio condizionale.

Un passaggio è scritto come il nome dell'operazione con il proprio blocco:

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 Svuotamento, rimozione e la differenza

clear lascia il campo presente e vuoto. remove lo rimuove completamente.

Per HL7 questa distinzione è reale e raggiunge il ricevente. Un campo vuoto dice "ho questo campo e non ha valore". Un campo assente non dice nulla. Alcuni sistemi riceventi trattano il primo come un'istruzione per cancellare il valore memorizzato e il secondo come un'istruzione per lasciarlo invariato — che è la differenza tra l'eliminazione di un'allergia registrata del paziente e il non menzionarla.

Se non si sa quale il ricevente desidera, è necessario chiedere. Indovinare ha una probabilità del 50% di distruggere silenziosamente i dati sul lato opposto.

6.3 Condizioni

when prende un'espressione e il passaggio viene eseguito solo se è vera:

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

Un passaggio la cui condizione è falsa viene registrato come skipped e ciò viene segnalato separatamente da un passaggio che è stato eseguito e non ha modificato nulla. Questa distinzione è l'obiettivo del debugger passo-passo e viene trattata in debugging: una condizione falsa e un campo assente appaiono identici dall'esterno e significano cose opposte.

6.4 Percorsi

Un percorso si riferisce a un campo: PID-5 è il quinto campo di PID, PID-5.1 è il suo primo componente, PID-3(2) è la seconda ripetizione di PID-3 e OBX(3)-5 è il quinto campo del terzo segmento OBX.

Due comportamenti da conoscere:

• set crea il percorso che indica, compresa la struttura intermedia. Ciò è comodo e significa che set non può mai dimostrare che un campo era assente — dopo il passaggio esiste. Per testare cosa succede quando un campo è mancante, utilizzare copy da un percorso che non esiste.
• Un percorso senza indice si riferisce a tutte le ripetizioni e a tutte le occorrenze, come fa in un filtro (dove PID-3.5 == "SS" è vero quando qualsiasi ripetizione lo è). Su un messaggio con cinque segmenti OBX, set su OBX-5 modifica tutti e cinque, e set su PID-3.4 rinomina ogni identificatore in PID-3, compreso quello del numero nazionale. Per modificare uno solo, fornire il suo indice: PID-3(1).4, OBX(2)-5.

6.5 Errori

La maggior parte dei passaggi non ha nulla che possa fallire. Impostare un valore, cancellare un campo o copiare da un percorso assente con un valore predefinito sono tutti definiti per ogni input.

date è l'eccezione, perché un valore che non è una data che riconosce non ha una conversione corretta. Accetta on_error:

• fail — il valore predefinito. Il messaggio si ferma e viene registrato come un fallimento di trasformazione.
• keep — lasciare il valore originale intatto.
• clear — svuotare il campo.

Il valore predefinito è fail perché un timestamp che non si converte silenziosamente è peggiore di un messaggio che non arriva. Una data nel formato sbagliato appare comunque come una data, quindi supera la convalida del ricevitore e atterra nel record come il giorno sbagliato.

keep è legittimo quando il ricevitore tollera entrambi i formati e, quando utilizzato, la traccia segna il cambiamento come deliberato in modo che non appaia come un passaggio che è fallito silenziosamente.

6.6 L'ordine conta e la traccia lo mostra

Ogni passaggio vede l'output del passaggio precedente. Due conseguenze che colgono le persone:

• Un map dopo un case vede il valore convertito dal caso, quindi le chiavi della sua tabella devono corrispondere alla forma convertita. Una tabella di M/F dopo un passaggio in minuscolo non corrisponde a nulla, silenziosamente, perché un valore non nella tabella viene lasciato invariato.
• Un copy da un campo che un passaggio successivo rimuove funziona comunque, perché è stato eseguito per primo. Il contrario non è vero.

Entrambi sono visibili nella visualizzazione passo-passo, che mostra l'intero messaggio dopo ogni passaggio piuttosto che solo il cambiamento. Vedi debugging.

6.7 Suggerire mapping e cosa fare con una suggerimento

L'AI Mapper propone mapping tra un set di campi sorgente e un set di destinazioni. Il suo comportamento caratteristico è che rifiuta: al di sotto della sua soglia di confidenza, si astiene piuttosto che indovinare, perché un mapping errato in un sistema clinico è peggiore di nessun mapping.

6.7.1 Dargli qualcosa di cui essere sicuri

Un nome da solo è una prova debole, anche quando corrisponde esattamente. PatientMRN contro PatientMRN punteggia 68, che si astiene alla soglia predefinita del 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.

Ciò ottiene un mapping per la maggior parte del percorso. Per finirlo, fornisci entrambe le metà:

• Valori di esempio per un campo sorgente, dopo un segno di uguaglianza: ZPI-1 = MRN00412, MRN00998
• Il tipo di valore che un campo di destinazione tiene, nello stesso modo: PID-3.1 = mrn. I tipi sono mrn, npi, ssn, phone, date e email.

Con quelli, il motore può vedere che i valori concordano con il tipo di destinazione e una suggerimento si basa su più di un nome.

6.7.2 L'approvazione avviene una mappatura alla volta

Ogni suggerimento ha la sua propia casella di approvazione. Non esiste un "accetta tutto sopra l'80%", deliberatamente: il motore ha già utilizzato la fiducia per decidere se offrire la mappatura e ciò che rimane è un giudizio su questo campo in questo feed. Un numero non è quel giudizio.

Un'astensione non può essere approvata affatto. Non ha una casella, nemmeno disabilitata, e lo schermo dice che il motore non conosce. Se conosci la risposta, mappa manualmente — è un atto diverso dall'accettare un suggerimento.

Un suggerimento al di sotto della tua soglia è mostrato senza una casella anche, contrassegnato come al di sotto di essa. Vale la pena leggerlo — una mancanza di poco è spesso la mappatura desiderata e nasconderla lascerebbe a chiedersi se il motore l'abbia considerata — ma non approvabile, perché la tua soglia è la linea che hai tracciato.

6.7.3 Due cose da fare con ciò che hai approvato

Aggiungerli a un canale trasforma ogni mappatura in un passaggio di copia. Ciò funziona solo dove la sorgente è un percorso nel messaggio, come ad esempio ZPI-1, perché un passaggio copia da un posto in un messaggio a un altro. I passaggi vanno nel file del canale e hanno effetto quando viene caricato nuovamente — nulla cambia nel traffico fino ad allora. La descrizione di ogni passaggio registra la fiducia con cui è stato suggerito e che una persona l'ha approvato, il che lo rende responsabile sei mesi dopo.

Scaricare come ricetta è la risposta giusta per il caso più comune: una mappatura da un nome di colonna, una chiave JSON o un nome di campo del fornitore. Sono mappature reali e un canale non può leggere direttamente un tale campo, quindi un passaggio non può esprimerle. La ricetta registra le mappature come approvate e può essere condivisa.

6.8 Perché non uno script

Mirth mette un trasformatore JavaScript al centro di ogni canale e rappresenta il design più flessibile disponibile. Perfuse offre la possibilità di scripting — vedere la chiave scripts nel riferimento al canale — ma non lo rende il percorso ordinario, per tre motivi che derivano da ciò che va storto nella pratica.

Un passaggio dichiarativo può essere ispezionato. Perfuse può dirti che un passaggio legge PID-5 e scrive PID-8, prima di eseguirlo, e può quindi mostrare una traccia a livello di campo, avvertire che un passaggio indirizza un percorso che il tipo di dati dichiarato non può contenere e generare una riproduzione per passaggio.

Un passaggio dichiarativo può essere ragionato dall'interfaccia. Il costruttore può offrire i campi che esistono nel traffico di questo canale e un cambiamento a un passaggio può essere verificato contro messaggi storici reali prima di essere salvato.

E un passaggio dichiarativo non può fare qualcosa di non correlato al messaggio. Uno script può chiamare la rete, leggere il file system o dipendere dall'orario del giorno. Quando un canale che ha funzionato per due anni inizia a produrre output errato, la causa che si trova al di fuori del messaggio è il caso più difficile da diagnosticare e rimuovere la possibilità vale più della flessibilità che costa.

Dove una trasformazione genuina non può essere espressa in modo dichiarativo, utilizzare uno script e accettare che la traccia lo mostrerà come un passaggio opaco.

6.9 Cosa è consentito a uno script

Uno script è rifiutato tutto ciò che si trova al di fuori del messaggio a meno che non gli sia concesso e le concessioni sono nella sezione Scripts del costruttore. Ciò è deliberatamente diverso da Mirth, che concede a ogni script tutti i diritti — quindi, lì, un trasformatore può iniziare a leggere il file system dopo un copia-incolla.

Ce ne sono tre.

Leggere e scrivere file richiede di nominare le directory che può utilizzare e un canale che concede l'accesso ai file senza di esse viene rifiutato al caricamento. Quella richiesta è l'unica differenza tra l'accesso ai file e l'accesso ai file non limitato: concederlo senza directory una volta raggiungeva l'intero file system, compreso il database di Perfuse, che contiene hash di password, la password del servizio account LDAP e il segreto client OIDC. La creazione di un canale richiede solo il ruolo di editore, quindi l'escalation si è completata nel momento in cui un amministratore ha avviato il canale.

Query su un database utilizza le connessioni configurate sul canale. Uno script con questo può leggere tutto ciò che queste credenziali possono.

Inviare messaggi ad altri canali consente a uno script di inviare un messaggio in un altro canale, il che è il modo in cui un ciclo tra due canali diventa possibile.

Concedere una capacità a un canale senza script non fa nulla e il file generato omette l'intero blocco in quel caso.

6.10 Gestione di una data che non corrisponde al suo formato

Un passaggio di data converte da un formato all'altro e la domanda interessante è cosa succede quando un valore non corrisponde al formato che afferma.

Il valore predefinito è interrompere il messaggio e rappresenta il valore predefinito giusto: un timestamp che non si converte silenziosamente è accettato a valle e poi letto male, il che è peggio di un messaggio che fallisce rumorosamente e si trova dove qualcuno può vederlo.

Lasciare il valore com'è lo passa attraverso nel suo formato originale. A valle, quindi, si vedono due formati in un campo, il che è il fallimento che il passaggio esisteva per prevenire — ma è la scelta giusta dove il campo è opzionale e un partner lo invia in modo non coerente.

Svuotare il campo è onesto e meglio di un formato errato, ma un ricevitore che richiede il campo rifiuta quindi il messaggio al suo posto.

6.11 I linguaggi di scripting

Se ne accettano tre e la scelta di quale utilizzare dipende principalmente dal fatto che si stia eseguendo una migrazione. Il valore va inserito nella chiave language di uno script:

JavaScript è il valore predefinito e uno script non contrassegnato viene trattato come JavaScript. È presente come obbligo di compatibilità piuttosto che come preferenza: gli script di Mirth sono JavaScript e un sito che si sposta ha migliaia di righe di codice. Ciò include il supporto per E4X, un'estensione obsoleta del linguaggio che gli script di Mirth utilizzano per XML e che deve essere tradotta prima che qualcosa possa essere analizzato.

Lua (lua) è la scelta migliore per chi non esegue una migrazione. Un runtime più piccolo, nessuna catena di prototipi da utilizzare in modo errato e tabelle con indici interi che corrispondono all'indirizzamento dei segmenti e dei campi in modo più naturale rispetto a JavaScript. La sua libreria standard è sufficientemente piccola da poter essere elencata, il che è ciò che rende più facile avere fiducia nella sua sandbox.

WebAssembly (wasm) non è un linguaggio, ma un modulo compilato, e il campo vuole i byte di un file .wasm invece del codice sorgente. Utilizzalo quando la trasformazione esiste già in un linguaggio compilato o quando è sufficientemente pesante da rendere importante il costo di runtime.

Il suo contratto è deliberatamente il più semplice disponibile: un modulo legge il messaggio sul canale di input standard e scrive il risultato sul canale di output standard. Byte in ingresso, byte in uscita — che è ciò che ogni strumento già fa e che qualcuno che testa un modulo sulla propria riga di comando già ha. L'alternativa era una funzione esportata su memoria lineare, che è più veloce e richiede che ogni autore di moduli concordi sull'allocazione, la codifica delle stringhe e su chi dealloca cosa; per qualcosa che viene eseguito una volta per messaggio, questo scambio non vale la pena.

Qualsiasi cosa un modulo scriva sul canale di errore standard diventa una riga di log, quindi può spiegarsi nel modo in cui uno script che chiama logger può.

6.11.1 Cosa significa l'output

Le regole sono le stesse per tutti e tre i linguaggi piuttosto che nuove regole per ogni runtime, quindi il comportamento osservabile di uno script — cosa può vedere, cosa può fare, quanto tempo può impiegare, cosa significa un verdetto di filtro — è definito una volta.

Per un trasformatore, un preelaboratore o uno scrittore, un output vuoto significa che il messaggio non è stato modificato. Cadere alla fine di uno script lascia il messaggio invariato; trattare la mancanza di output come "il messaggio è ora vuoto" discarderebbe il traffico per una questione tecnica.

I moduli WebAssembly vengono compilati quando il canale viene caricato, non al primo messaggio. La compilazione non è gratuita — un modulo costruito da un linguaggio che porta il proprio runtime può richiedere centinaia di millisecondi — e pagare questo costo al momento del caricamento significa che il primo messaggio che passa attraverso un canale non è misteriosamente più lento degli altri.

6.12 Tabelle di mappatura condivise

L'altra metà dello stesso problema: i codici di sesso e le classi di pazienti di un sito vengono tradotti in modo identico in ogni canale che li tocca, e una tabella all'interno di un canale è una tabella che solo quel canale può utilizzare.

# 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

La provenienza è il punto. La maggior parte di ciò che rende un'interfaccia difficile da mantenere è che nessuno sa *perché* un mapping sia fatto in un certo modo, e la persona che lo sapeva se n'è andata. Un mapping con una ragione può essere discusso; uno senza diventa qualcosa che nessuno osa cambiare e nessuno osa eliminare.

Le tabelle vengono create e modificate in Build → Tabelle nonché nel file. Salvare una tabella in vigore riavvia i canali in esecuzione che caricano il suo file, in modo che il prossimo messaggio lo utilizzi; una bozza non riavvia nulla.

6.12.1 Versioni e date di efficacia

Un tableau può tenere diverse edizioni sotto un solo nome, ognuna con la sua versione version. L'edizione che un messaggio utilizza viene scelta quando il messaggio arriva: tra le edizioni approvate le cui date coprono quel giorno (UTC), quella che è iniziata più di recente. Quindi, un cambiamento del codice concordato per il primo giorno del prossimo mese viene inserito ora e diventa effettivo automaticamente.

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 è approved (predefinito), draft (utilizzato da nulla) o retired

(conservato per la registrazione, utilizzato da nulla).

• Due edizioni di uno stesso nome con la stessa versione, o due edizioni approvate

che iniziano lo stesso giorno, vengono rifiutate quando il file viene caricato.

• Salvare una nuova versione senza data di inizio mentre un'altra è approvata la data

a partire da oggi, quindi sostituisce quella in vigore. Quella che era stata avviata solo oggi viene ritirata, poiché due edizioni che iniziano lo stesso giorno non lasciano alcuna regola.

• I propri default e strict di un passaggio di mappatura vengono utilizzati quando il passaggio li imposta;

altrimenti vengono utilizzati quelli della tabella.

• Nello schermo Tabelle, Mostra versioni elenca ogni edizione con il suo stato,

chi l'ha salvata e chi l'ha approvata, e Confronta con la versione in vigore mostra cosa un'edizione aggiunge, rimuove e modifica.

6.12.2 Firma

Con Impostazioni → Dati → Tabelle di mapping "Le modifiche a una tabella di mapping richiedono l'approvazione di una seconda persona" (data.tableApproval) attivate, ogni salvataggio è una bozza e la persona che lo ha salvato non può approvarlo: qualcun altro lo fa, eventualmente fornendo il giorno in cui entra in vigore. Un'edizione approvata non può essere modificata sul posto; Nuova versione da questa la copia nella prossima versione. L'approvazione, il ritiro e la cancellazione di una bozza vengono scritti nel registro di controllo e l'approvazione riavvia i canali in esecuzione che caricano il file.

6.12.3 Valori senza tabella di mapping

Ogni valore che un passaggio di mappatura ha cercato e non ha trovato viene conteggiato, per tabella, con i canali attraverso cui è passato e quando è stato visto per la prima e l'ultima volta. Lo schermo delle tabelle elenca i valori, in ordine di frequenza. Mappa apre la tabella con quel valore già aggiunto come riga; Dismiss lo rimuove fino a quando non viene visto di nuovo. I valori più lunghi di 64 caratteri non vengono registrati (non sono codici) e l'elenco mantiene ciò che è stato visto all'interno del periodo di conservazione dei messaggi. L'elenco viene mantenuto in terminology.db accanto al database principale.

6.12.4 Sistemi di codici

I sistemi di codici pubblicati possono essere importati dai file dei loro editori, sotto Sistemi di codici sullo schermo Tabelle (amministratori) o con POST /api/terminology/import?format=… e il file come corpo:

Nessuno viene fornito con Perfuse: LOINC, SNOMED CT, RxNorm e CPT hanno ciascuno la propria licenza e lo schermo chiede all'importatore di confermare che l'organizzazione la possiede (registrata con l'importazione). I codici importati vengono utilizzati in tre modi:

• una tabella che nomina source_system o target_system ha le sue voci controllate quando

viene salvata e i codici che non sono nel sistema vengono elencati nella versione;

• Trova un codice cerca per codice o per parole nel nome;
• il server FHIR risponde a CodeSystem/$lookup e CodeSystem/$validate-code

per essi (vedere le opzioni del server FHIR). I codici ICD-10-CM vengono accettati con o senza il punto.

Edizioni e classificazioni nazionali. Un'edizione di SNOMED CT viene importata dal suo intero pacchetto RF2: concetti con il loro stato reale, ogni descrizione attiva e gli insiemi di riferimento linguistici. L'edizione viene trovata dal pacchetto (il modulo nazionale con il maggior numero di concetti; edition lo nomina invece) e diventa l'URI della versione. language sceglie il termine preferito per ogni concetto (sv, da, nl, de, fr, en-GB, en-US ...; inglese altrimenti) e ogni termine preferito e nome completamente specificato vengono mantenuti come designazioni: $lookup li restituisce e il suo displayLanguage ne sceglie uno (de-CH ricade su de). Le edizioni che Perfuse nomina (Internazionale, Regno Unito, Germania, Paesi Bassi, Svezia, Danimarca, Belgio, Irlanda, Norvegia, Svizzera, Estonia, Spagna) sono elencate da GET /api/terminology/editions, i cui ID modulo non vengono verificati contro una fonte pubblicata contrassegnata come tale; qualsiasi altra edizione viene importata anche, nominata dal suo modulo.

I file ClaML vengono letti in UTF-8, ISO-8859-1, ISO-8859-15 o Windows-1252, come dichiarato nella loro dichiarazione XML. Il titolo di ogni categoria è il suo rubrico preferito (termini annidati inclusi); un modificatore (un quinto carattere per il sito di una frattura, ad esempio) crea i codici che aggiunge, con il titolo del modificatore dopo quello della categoria, a meno che la categoria non lo escluda; blocks=true importa anche capitoli e blocchi. Le colonne della tabulazione ICD-11 vengono trovate per nome, poiché il loro ordine è cambiato tra le versioni, e i trattini che mostrano la profondità vengono rimossi dai titoli. Un file delimitato richiede delimiter (, ; | o tab), encoding (utf-8, iso-8859-1, iso-8859-15, windows-1252) e noHeader=true, con colonne numerate da 1. La console offre impostazioni per i file UK ICD-10 5a Edizione e OPCS-4 (TRUD), la tabella di etichette CIM-10 FR della Francia (ATIH) e un'esportazione ICD-10-BE; i loro editori non documentano tutte le colonne, quindi controllatele contro l'intestazione del file.

Date di efficacia. effective=YYYY-MM-DD importa una versione ora e la utilizza da quel giorno (ad esempio ICD-10-GM, ogni 1 gennaio): fino ad allora una ricerca che non nomina una versione viene risposta dalla versione già in vigore e lo schermo mostra la data.

ICD-11 dall'OMS. Con un client registrato su icd.who.int (Impostazioni → Dati → Sistemi di codici, serve -icd11-client-id e -icd11-client-secret; -icd11-release, 2025-01 per impostazione predefinita), i codici ICD-11 che non sono importati vengono cercati nell'API ICD dell'OMS (codeinfo, quindi il titolo dell'entità) e conservati per un giorno. Un codice postcoordinato (NC72.2&XK9K) viene verificato per intero, quindi una combinazione ICD-11 non consentita viene rifiutata, e i suoi nomi di visualizzazione ogni parte ("Frattura del collo del femore (Destro)").

ICD-11 senza inviare codici. L'OMS pubblica la stessa API come un contenitore (whoicd/icd-api, gratuito, Intel e Arm). Esegui su rete locale e fornisci l'indirizzo (serve -icd11-url http://icd-api.local, o Indirizzo API ICD nelle stesse impostazioni); nessun client è necessario e nessun codice lascia la rete. Testato contro quel contenitore (versione 2.6.0, rilascio 2025-01 in inglese e francese).

7 Filtraggio

Un filtro decide quali messaggi un canale accetta. È un'espressione sul canale, valutata dopo che il messaggio è stato analizzato e registrato, prima di qualsiasi trasformazione.

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

Un messaggio che il filtro rifiuta viene registrato con l'esito filtered. Ciò è un risultato normale, non un errore, e non genera un allarme o una conferma negativa.

7.1 Filtered non è fallito

Questa distinzione è importante perché confonderli può nascondere un problema reale.

Un messaggio filtrato è stato correttamente rifiutato: non era per questo canale. Un messaggio fallito è uno che questo canale avrebbe dovuto gestire e non ha potuto. Se entrambi fossero stati registrati allo stesso modo, un canale che inizia a fallire ogni messaggio sembrerebbe esattamente come un canale che sta filtrando la maggior parte del suo traffico, che è lo stato normale di molti canali.

Quindi le statistiche li contano separatamente, le regole di allarme li trattano in modo diverso e l'interfaccia li visualizza in colori diversi. Un aumento dei messaggi filtrati potrebbe significare che il mittente ha iniziato a inviare qualcosa di nuovo; un aumento dei fallimenti significa che qualcosa è rotto.

7.2 Ciò che un filtro può leggere

Qualsiasi campo nel messaggio analizzato, tramite gli stessi percorsi utilizzati dalle trasformazioni. Il filtro viene eseguito prima delle trasformazioni, quindi vede il messaggio come è arrivato — non come verrà inviato.

Quell'ordine è deliberato. Un filtro che legge valori post-trasformazione sarebbe in grado di decidere se accettare un messaggio in base alle modifiche apportate sull'ipotesi che fosse stato accettato, il che è circolare e produce canali il cui comportamento dipende dall'ordine di due cose che sembrano indipendenti.

7.3 Espressioni

Confronti: ==, != e per i numeri <, <=, >, >=.

Appartenenza: in ("A01", "A03"), che è più chiaro di una catena di || ed è la forma che il costruttore produce.

Combinazione: &&, || e parentesi. Negazione con !.

Assenza: un percorso che non è presente si confronta in modo diverso con qualsiasi valore, compresa la stringa vuota. Per testare l'assenza in modo esplicito, confrontare con absent. Ciò è importante perché un campo assente e un campo vuoto sono diversi, come descritto in transformation, e un filtro che li tratta nello stesso modo accetterà messaggi che era stato scritto per escludere.

7.4 Un errore nel filtro è un rifiuto

Se il filtro stesso non riesce a valutare — un'espressione malformata che è passata alla convalida, o un confronto che non può essere effettuato — il messaggio viene rifiutato e l'errore viene registrato contro di esso.

Rifiutare piuttosto che accettare è la scelta più sicura delle due, ma nessuna delle due è buona, e l'esito viene registrato in modo distinto da un rifiuto di filtro ordinario in modo che possa essere segnalato. Un filtro che si verifica un errore su ogni messaggio sta silenziosamente eliminando l'intero flusso di dati e non deve sembrare un filtro che funziona.

7.5 Filtra alla sorgente quando possibile

Un filtro viene eseguito dopo che il messaggio ha attraversato la rete e viene analizzato. Alcune sorgenti possono filtrare prima e più a buon mercato:

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

Il filtraggio alla sorgente è una decisione di prestazioni, non di correttezza, e ha un costo: un messaggio filtrato al broker non viene mai registrato da Perfuse, quindi non appare nel negozio dei messaggi e non può essere ispezionato in seguito. Se è necessario essere in grado di dimostrare cosa ha inviato il mittente, filtrare qui piuttosto che lì.

7.6 Test di un filtro

Un filtro può essere verificato contro il traffico storico reale prima di essere salvato. L'interfaccia segnala quanti dei messaggi registrati negli ultimi N il filtro accetterebbe, rifiuterebbe ed errore — che è il modo più veloce per scoprire che un'espressione che sembra giusta non accetta nulla.

La traccia mostra anche, per messaggio, quali campi il filtro ha letto e quali valori ha trovato. Un filtro che rifiuta inaspettatamente tutto è solitamente un percorso che non esiste in questo flusso di dati e la traccia lo nomina.

8 Formati di messaggio

Il dataType di un canale decide come i byte diventano un messaggio. Ciò influisce sull'analisi, su cosa significano i percorsi, su come il messaggio viene scritto di nuovo e su quali trasformazioni sono valide.

8.1 HL7 v2

Il valore predefinito, e ciò che la maggior parte degli esempi di questo manuale utilizza. I segmenti terminati da ritorno a capo, i campi da |, i componenti da ^, le ripetizioni da ~.

Due cose sull'encoding sono degne di nota perché causano errori silenziosi.

I delimitatori non sono fissi. Vengono dichiarati in MSH-1 e MSH-2 di ogni messaggio, e Perfuse li legge da lì anziché supporre pipe. Un mittente che utilizza un separatore di campo diverso viene parsato correttamente.

La conseguenza è che un messaggio i cui separatori sono stati sostituiti — più spesso da un elaboratore di testi o un client di posta elettronica che sostituisce i caratteri con look-alike tipografici — viene parsato perfettamente in campi che sono tutti errati. Nessun errore si verifica. Questo è il motivo per cui il lettore di esempio descritto in testing segnala quale carattere di separatore ha trovato e rifiuta di esprimere fiducia quando è insolito.

8.2 HL7 v3 e CDA

XML anziché delimitato. I percorsi sono percorsi di elementi e attributi anziché posizioni di campo.

In v3 un valore è quasi sempre un attributo anziché testo di elemento. Un confronto che legge solo il testo di elemento segnalerà due documenti come identici quando la data di nascita, il genere e ogni identificatore differiscono. Il confronto di Perfuse legge entrambi, ed è per questo: l'alternativa ha successo silenziosamente.

Le opzioni hl7v3 sono nel format reference.

8.3 X12

I segmenti terminati da ~ per convenzione, con delimitatori dichiarati nel segmento ISA. Come HL7, vengono letti dal messaggio anziché supposti.

La struttura di X12 è costituita da buste all'interno di buste — scambio, gruppo funzionale, set di transazioni — e un singolo scambio può contenere molte transazioni.

Per default, uno scambio è un messaggio. L'intero file ottiene un record, un esito e una riga nell'interfaccia, indipendentemente da quante transazioni contiene.

8.3.1 L'X12 XML di Mirth

Mirth Connect e Open Integration Engine mostrano X12 come XML: una radice X12Transaction (o EDIMessage quando l'input non inizia con ISA) che trasporta i delimitatori come attributi, e un elemento per segmento ed elemento denominato ISA.01, NM1.03.1 e così via. I canali e i ricevitori costruiti per Mirth leggono e scrivono questa forma. Perfuse legge e scrive la stessa forma:

• x12: { arrives_as: xml } su un canale X12 prende quell'XML e lo gestisce come l'X12 che rappresenta (la scelta Arriva come del costruttore);
• x12_as: xml su una destinazione invia l'X12 come quell'XML (la scelta Invia come X12 XML di Mirth del costruttore);
• perfuse x12 xml [file] e perfuse x12 from-xml [file] convertono a riga di comando.

Il formato è stato scritto a partire dall'output osservato e dal formato pubblicato di Open Integration Engine 4.6, e viene verificato contro di esso: 25 scambi generati e 4 esempi conservati vengono fuori byte per byte come OIE li scrive, e viceversa (vedi verifica). Un DOCTYPE viene rifiutato, come in ogni XML che Perfuse legge.

8.3.2 Dividere uno scambio

Impostare split rende ogni set di transazioni un messaggio a sé stante, con il proprio record, le proprie metriche e la propria riga. Un operatore che cerca una richiesta di rimborso trova una richiesta di rimborso anziché un file di quattrocento.

È disattivato per default perché attivarlo moltiplica tutto ciò che si trova a valle — conteggi dei messaggi, righe, soglie di allarme — e una soglia tarata per i file che conta improvvisamente le richieste di rimborso non significherà più ciò che significava in precedenza. Ciò dovrebbe essere una decisione presa da qualcuno anziché un valore predefinito ereditato.

8.3.3 Quando i conteggi non corrispondono

X12 dichiara i propri conteggi — quanti segmenti, quante transazioni — e la chiave envelope dice cosa fare quando essi non corrispondono a ciò che è effettivamente presente. Quei conteggi sono l'unico meccanismo che X12 ha per rilevare che metà di un file di richieste di rimborso è arrivata.

warn esiste per una situazione reale: alcuni software dei partner hanno generato conteggi errati per anni in file altrimenti completi, e un sito che deve elaborare quei file ha bisogno di un modo per dirlo a voce alta nella configurazione anziché disattivare la convalida nel suo complesso.

8.3.4 Transazioni Perfuse legge come dati strutturati

Ogni scambio X12 può essere instradato, filtrato e indirizzato per percorso. Queste transazioni vengono inoltre analizzate in campi denominati, in modo che un canale possa chiedere cosa abbia deciso un pagatore piuttosto che quale elemento si trova nella posizione quattro.

Perfuse costruisce anche la richiesta di eleggibilità 270 e la richiesta di stato della richiesta 276, sotto Payer → Richieste e autorizzazioni o attraverso POST /api/x12/eligibility/build e /api/x12/claimstatus/build. Entrambe sono le versioni HIPAA 5010 (005010X279A1, 005010X212), lette indietro e controllate prima di essere visualizzate, e nessuna delle due viene inviata da quella pagina: consegnare una di esse è un lavoro di canale, dove il partner commerciale e le relative credenziali sono.

8.3.5 Eleggibilità e regola di contenuto dei dati CAQH CORE

Un 271 è un elenco di segmenti EB, ognuno un singolo fatto: copertura attiva, o un co-pagamento di 25 dollari per tipo di servizio 30 in rete, o 800 dollari del deducibile individuale rimanente. Il lettore li assembla nella risposta che un banco desidera - "copertura attiva sotto Gold PPO 2000; co-pagamento in rete 25 dollari; deducibile individuale rimanente in rete 800 dollari" - e nomina un rifiuto (un segmento AAA) in parole, con cosa il pagatore dice di fare dopo.

Verifica anche la risposta contro la regola di contenuto dei dati di idoneità e benefici CAQH CORE: per un'indagine sulla copertura del piano di beneficenza sanitaria (tipo di servizio 30), una risposta attiva dovrebbe trasportare date di piano, nome del piano, co-pagamento, co-assicurazione, deducibile e deducibile rimanente sia in rete che fuori rete, e i tipi di servizio base (1, 33, 35, 47, 48, 50, 86, 88, 98, AL, MH, UC). Ognuno viene elencato come soddisfatto o mancante. Questa è la lettura di Perfuse della regola, utile per "perché questo pagatore non ci dice mai il deducibile?" - non è una certificazione CORE, che i vendor di test autorizzati da CAQH eseguono.

8.3.6 Autorizzazione preventiva

Perfuse implementa l'autorizzazione preventiva due volte, di proposito.

Il lato FHIR è ciò che CMS-0057-F richiede ai pagatori di esporre entro il 1° gennaio 2027. Il 278 è ciò che i pagatori accettano oggi, e la regola non lo sostituisce — Da Vinci PAS è in pratica un mapping su questa transazione, perché un 278 è ciò che un sistema di gestione dell'utilizzo parla. Un motore che legge solo la metà FHIR può parlare con i sistemi che esisteranno e non con quelli che esistono.

Una risposta 278 trasporta il numero di autorizzazione, e questo è il campo per cui esiste l'intera transazione. Senza di esso un servizio certificato non è fatturabile: la richiesta va in con nessun numero di autorizzazione e viene negata per la mancanza di esso, che legge a valle come una negazione clinica.

Un rifiuto e un rifiuto di considerazione non sono la stessa cosa

Questa è la confusione più costosa nella transazione, e Perfuse segnala le due separatamente.

Entrambe vengono lette come "non approvate" da chiunque esegua la scansione e le azioni corrette sono opposte. Fare appello a qualcosa su cui nessuno ha preso una decisione non produce alcun risultato; rinviare un rifiuto produce lo stesso rifiuto. I nomi dell'esito parsificato che si sono verificati — denied contro not-considered — e AAA04 contiene il consiglio del pagatore stesso su se la richiesta sia recuperabile o meno.

La certificazione parziale viene segnalata come partially-certified anziché essere incorporata nell'approvazione. Esiste un numero di autorizzazione per addebitare, quindi conta come approvato, ma la quantità certificata non è la quantità richiesta — e uno studio che prenota sei sedute contro tre approvate lo scopre alla quarta richiesta di rimborso.

Un codice di azione che Perfuse non riconosce viene segnalato come unknown, non come pendente. Pendente si legge come "wait" e attendere è l'azione sbagliata per la maggior parte di ciò che potrebbe essere un codice non riconosciuto.

Un canale può instradare sulla decisione direttamente:

filter: HCR-1 == "A3"

Conversione tra i due

Perfuse converte un 278 analizzato in una risposta Da Vinci PAS ClaimResponse, e segnala ogni giudizio che la conversione ha richiesto piuttosto che solo il risultato. La conversione segue tre regole:

• Nessuna decisione viene aggiornata. La certificazione parziale rimane parziale e una richiesta che il pagatore ha rifiutato di considerare non diventa un rifiuto. Entrambe le compressioni sono disponibili nella mappatura ovvia e entrambe sono errate nella direzione costosa.
• Nessun campo obbligatorio viene inventato. Un evento certificato senza numero di autorizzazione viene segnalato come tale, non gli viene assegnato un numero plausibile — un numero inventato produce una richiesta che viene successivamente rifiutata per un motivo che nessuno può rintracciare.
• Viene utilizzata una decisione portata solo a livello di riga. Un pagatore che risponde per servizio può lasciare l'evento senza una decisione propria; leggere solo il livello dell'evento lo segnalerebbe come in sospeso e un'attività aspetta una risposta che già ha mentre l'approvazione scade. Quando le righe sono in disaccordo, vince la meno favorevole, perché un evento con una riga rifiutata non è un'approvazione.

La riduzione a un vocabolario a tre stati — approvato, rifiutato, in sospeso — è disponibile ed esplicita su ciò che scarta. La riduzione di un rifiuto a considerare produce "rifiutato" e dice a parole che l'azione corretta è una risottomissione corretta piuttosto che un appello.

Verificato contro PAS 2.2.1, non solo contro se stesso

La ClaimResponse è modellata sul profilo Da Vinci PAS 2.2.1 e è stata verificata con il validator ufficiale HL7 caricato con il pacchetto PAS pubblicato. La prima versione era stata verificata solo con i test di Perfuse e il validator l'ha rifiutata con sei o otto errori per risorsa. Ognuno di essi è qualcosa che un endpoint PAS di un pagatore avrebbe anche rifiutato:

La risposta corretta valida senza errori per una certificazione, un rifiuto e un rifiuto. Gli avvertimenti che rimangono sono il validator che dice di non poter caricare i sistemi di codici X12, che X12 concede in licenza. Il numero di autorizzazione è riportato in reviewAction.number, dove l'esempio della guida lo mette, e in preAuthRef quando la risposta ha solo uno.

Il validator non fa parte di make check, perché richiede Java e un download della guida e delle sue dipendenze. Ciò che ha trovato è mantenuto da un test: ogni regola che ha applicato è affermata, quindi un cambiamento che reintroduce uno di quegli errori fallisce.

La vista Richieste e autorizzazioni converte un 278 incollato e mostra le decisioni, le note e la risorsa.

8.3.7 Allegati e perché richiedono un trattamento speciale

CMS-0053-F rende il 275 uno standard HIPAA per gli allegati alle richieste, con la conformità richiesta entro il 26 maggio 2028. Trasporta un documento — una nota operativa, un referto di imaging, un modulo scannerizzato — legato alla richiesta che supporta.

Il 277 è l'altra metà della stessa conversazione. Un pagatore riceve una richiesta, decide di aver bisogno di documentazione e invia un 277 per richiederla; il fornitore risponde con un 275.

Un canale può instradare direttamente sul codice di stato, perché STC01 è un composito e il suo secondo componente è lo stato. Scritto in forma canonica, perché un componente è indirizzato con un punto e le due notazioni non possono essere mescolate — STC-1.2 è l'elemento 1, componente 2:

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

Questi sono i codici che significano inequivocabilmente che un documento è richiesto. La categoria di stato in STC-1.1 non viene utilizzata da sola: R4 significa una richiesta di documentazione in alcune guide di implementazione e "inoltrato altrove" in altre, quindi un filtro sulla categoria sola metterebbe le richieste finalizzate nella coda per qualcuno da inseguire.

Due identificatori decidono se un allegato è mai associato alla sua richiesta e entrambi vengono segnalati: il numero di controllo dell'allegato, che il fornitore ha messo sulla richiesta originale per dire che la documentazione sarebbe seguita, e il numero di traccia, che corrisponde alla richiesta del pagatore. Un allegato che arriva senza nessuno dei due viene archiviato e mai collegato a nulla, mentre la richiesta invecchia.

Il modulo 006020, che è quello adottato dal regolamento

CMS-0053-F adotta la versione 006020 e il suo 275 differisce dal modulo 005010 in due modi che contano.

• Il payload è in BDS, non BIN. BDS01 nomina un filtro, ASC o B64. BDS02 è la lunghezza e BDS03 i dati.
• Il payload è un'entità MIME, con intestazioni che dicono cosa è il documento e un corpo base64. Con B64 l'entità stessa è anche base64.

Perfuse rimuove l'entità e segnala il documento al suo interno, con il suo tipo di contenuto e nome del file. I byte che segnala sono esattamente quelli che il mittente ha avvolto. Un'entità che non può essere rimossa lascia il payload grezzo al suo posto, con una nota che spiega il motivo.

Creazione di un 275. Perfuse costruisce anche allegati 006020X314: uno non sollecitato per accompagnare una richiesta di rimborso, o una risposta a una richiesta 277 di un pagatore. La differenza è BGN01 02 contro 11, e se TRN02 trasporta il PWK06 della richiesta di rimborso o il TRN02 della 277. Ogni scambio costruito viene analizzato nuovamente prima di essere restituito e la risposta indica se il documento all'interno è lo stesso che è stato inserito.

La struttura deriva dalle due guide compagne pubblicate per 006020X314: la guida esMD del CMS e quella di UnitedHealthcare. Non deriva dal rapporto tecnico X12, che X12 concede in licenza e che questo progetto non detiene.

• Dove le due guide concordano, Perfuse le segue.
• Dove differiscono, soddisfa entrambe se possibile. CAT02 è HL per un documento HL7, che esMD utilizza, e IA per un'immagine, che UnitedHealthcare utilizza.
• Altrimenti, invia il segmento opzionale solo quando viene fornito il valore: l'identificatore di richiesta di rimborso REF*X1 di esMD e la data di servizio DTP*472 di UnitedHealthcare.

Non esiste una convalida contro il rapporto tecnico. La guida compagna del partner governa.

8.3.8 Firme elettroniche sugli allegati

CMS-0053-F adotta anche uno standard di firma, al 45 CFR 162.2002(e): la guida di implementazione HL7 per CDA Release 2, firme digitali e delega di diritti, Release 1. Si applica alle firme apposte alle informazioni sugli allegati quando vengono inviate in una transazione di allegato HIPAA, a partire dal 26 maggio 2028. Un pagatore non può chiedere più di quanto previsto dalla guida.

Perfuse firma un C-CDA in quel modo mentre viene inserito in un 275, e controlla le firme su ogni C-CDA in un 275 che legge.

• Cosa viene firmato. L'intero documento tranne i partecipanti legalAuthenticator e authenticator, in modo che ogni firmatario successivo lasci intatte le firme precedenti. La firma lo afferma con un filtro XPath 2.0 di trasformazione che ogni libreria di firme XML può valutare.
• Dove va. In base64 in sdtc:signatureText sul partecipante firmatario, con una descrizione in testo normale su una riga. Il firmatario è l'autenticatore legale del documento se ne ha uno non firmato, altrimenti un nuovo authenticator.
• Cosa afferma. Il certificato del firmatario, l'ora in UTC, un ruolo dalla tassonomia dei fornitori NUCC e uno scopo da ASTM E1762. Lo scopo predefinito è *Firma dell'autore* per un autenticatore legale e *Firma del coautore* altrimenti, come nell'esempio della guida.
• Quanto dura. La guida chiede XAdES-X-L, che trasporta tutto ciò che un pagatore necessita per verificare la firma anni dopo senza raggiungere la rete. Ciò include il percorso di certificazione, una risposta OCSP o CRL dal CA e due timestamp da un'autorità di timestamp. Perfuse recupera i dati di revoca dagli indirizzi nel certificato e i timestamp da -tsa-url.

Se qualcosa di ciò non è disponibile, la firma viene comunque creata e mantiene la sua validità. Il risultato nomina la forma XAdES raggiunta e indica cosa l'ha fermata prima di raggiungere X-L: ad esempio un certificato autofirmato (nessun CA da interrogare) o nessun'autorità di timestamp.

La chiave è -signing-cert e -signing-key. Metti i certificati CA dopo quello del firmatario nello stesso file in modo che il percorso viaggi con la firma. Per una firma che significa ciò che significa DSDR, il certificato dovrebbe nominare il clinico, con il suo NPI, piuttosto che il server. La firma è un'azione amministrativa, come la firma di qualsiasi documento.

La guida non nomina uno spazio dei nomi per i suoi elementi. Perfuse mette digitalSignature, authorizedSigner e SignaturePurpose in urn:hl7-org:sdtc. Afferma anche lo scopo come un tipo di impegno XAdES con l'OID ASTM, che gli strumenti XAdES comprendono. La delega dei diritti, dove un delegato firma con un'asserzione SAML dall'autore autorizzato, non viene prodotta e una ricevuta viene segnalata come non verificata.

Il numero NPI del fornitore viene controllato contro il suo cifra di controllo. Un pagatore associa un allegato alla sua richiesta di rimborso in parte su quel numero e un numero errato lascia l'allegato non associato mentre la richiesta di rimborso viene negata per documentazione mancante.

La vista Richieste di rimborso e autenticazione costruisce un 275 da un C-CDA incollato o un file caricato, opzionalmente firmando il C-CDA, e legge uno con i risultati di ogni firma. Nulla su quella pagina invia nulla: lo scambio viene restituito per essere consegnato attraverso un canale, che è dove appartengono il partner, le credenziali e la traccia di audit.

8.3.9 Segmenti binari

Un segmento BIN trasporta byte grezzi e i byte grezzi contengono delimitatori. Ogni altro segmento X12 termina al terminatore di segmento, quindi un parser ordinario trova i segmenti cercando un byte; un allegato non può essere trovato in quel modo. Un PDF che contiene un ~ verrebbe diviso in pezzi e ogni pezzo è un segmento strutturalmente valido — quindi il documento viene troncato, ogni segmento dopo di esso è fuori allineamento e nulla segnala un errore.

Perfuse legge il conteggio dei byte che il segmento dichiara e prende esattamente quei byte. Due conseguenze degne di nota:

• Una lunghezza dichiarata che non corrisponde ai dati viene rifiutata, nominando entrambi i numeri. La domanda utile è se il conteggio del mittente era errato o se il file è stato troncato durante il trasferimento, e solo i due numeri forniscono la risposta.
• BDS, il segmento binario 006020, mantiene il proprio conteggio in BDS02 e i propri dati in BDS03. È stato rifiutato fino a quando non è stato possibile confermarlo da una fonte pubblicata piuttosto che ricordata, e due fonti lo confermano ora: la tabella BDS della guida esMD dei CMS e la guida di UnitedHealthcare.

La guida esMD presenta un proprio esempio di scambio che dichiara 16 byte per lo stesso payload di 53 byte che la sua tabella conta correttamente come 53. Perfuse rifiuta quell'esempio, come dovrebbe. Un test mantiene sia l'esempio della tabella che l'errore di battitura dell'esempio, quindi un cambiamento in entrambe le direzioni viene notato.

8.4 FHIR

8.4.1 In cosa si trasforma un messaggio HL7 v2

Il tipo di messaggio decide cosa viene prodotto e ogni conversione segnala le decisioni che ha dovuto prendere come note accanto al bundle.

Qualsiasi altra cosa produce il Paziente e un avviso che nomina il tipo che non è stato mappato.

Prenotazione. Una prenotazione, una riprenotazione, una cancellazione e un no-show atterranano tutti sullo stesso Appuntamento. La sua identità deriva dai numeri dell'appuntamento in SCH-1 e SCH-2, mai dal messaggio, quindi una cancellazione aggiorna la prenotazione. L'alternativa sarebbe un secondo appuntamento cancellato accanto a uno vivo, il che mostra il paziente prenotato in uno slot che non esiste più.

• Stato. Lo stato del filler in SCH-25 decide, e l'evento trigger viene utilizzato solo quando quello è vuoto.
• Fasce orarie bloccate. Una fascia oraria bloccata non è un appuntamento con un paziente e non produce nulla.
• Ora di inizio. Viene letta da AIS, AIG, AIL o AIP per prima, poi SCH-11, perché la versione 2.5 lo ha spostato e i feed non lo hanno fatto tutti.
• Durate. Una durata in un'unità che Perfuse non riconosce viene omessa, non indovinata.

Documenti. Le note di testo (TX, FT, ST) mantengono i propri a capo, comprese le righe vuote, perché una ripetizione vuota in una nota è una pausa di paragrafo.

• Embedded documents. An embedded PDF, TIFF or JPEG (ED) is carried byte for byte. Base64 that is not valid base64 is refused rather than passed on.
• Types. The document type in TXA-2 is kept as sent and, where there is a clear equivalent, given the LOINC code US Core uses.
• Signing. A note nobody has signed is preliminary, and T11 makes the document entered-in-error.
• No content. A notification with no content (T01, T03 and the other odd-numbered events) produces no DocumentReference. FHIR requires content, and an empty attachment would look like the note while saying nothing.

Questo è ciò che il criterio 14 del CMS Interoperability Framework chiede: note di cartella clinica e documenti clinici restituiti come allegati FHIR.

Immunizzazioni. Una dose non viene mai segnalata come somministrata quando il messaggio dice il contrario.

• Dosi rifiutate. Una dose rifiutata o non somministrata (RXA-20 RE o NA) è not-done, con il motivo da RXA-18.
• Cancellazioni. Una cancellazione (RXA-21 D) è entered-in-error.
• Registri storici. Un registro trascritto da un'altra fonte (RXA-9 diverso da 00) non è una fonte primaria.
• Quantità sconosciute. Una quantità di 999 significa sconosciuta, non 999.
• Route e siti. Ogni dose prende la route e il sito da RXR successivo, quindi un messaggio con due dosi non assegna la route della prima dose alla seconda.

Input scomodo. Ognuno di questi viene segnalato nelle note piuttosto che deciso silenziosamente:

• Identificatori. PID-2 e PID-4, ritirati dopo la versione 2.7 ma ancora inviati, vengono mantenuti come PID-3. CX.7 e CX.8 diventano Identifier.period. Un'autorità di assegnazione che trasporta un OID ISO (AUSHIC&2.16.840.1.113883.3.879&ISO) diventa urn:oid:. Un codice di tipo al di fuori della tabella HL7 0203 viene mantenuto come testo, non etichettato come tale.
• Unioni. MRG su un evento di unione (A40 e suoi simili) invia anche il record ritirato, inattivo, con Patient.link in entrambe le direzioni. Su qualsiasi altro evento, come un A08, nulla viene unito e un avviso indica che l'identificatore precedente è ancora attivo.
• Tempi. Un'ora di nascita in PID-7 va all'estensione patient-birthTime. Un timestamp senza offset prende il fuso orario configurato, altrimenti l'offset su MSH-7 (v2 presume il tempo locale del mittente), altrimenti UTC. Un'ora di nascita è l'eccezione: senza offset da uno dei tre viene omessa piuttosto che etichettata come UTC, perché un offset errato può spostare una nascita in un altro giorno. birthDate viene mantenuto e un avviso indica che l'ora è stata eliminata e che impostare un fuso orario per il feed la mantiene.
• Risultati. Le ripetizioni di un risultato di testo vengono unite con interruzioni di riga. Un risultato ED, o un risultato codificato il cui valore è chiaramente Base64, diventa un DocumentReference che l'Osservazione punta in derivedFrom, poiché un'Osservazione R4 non ha un valore di allegato. Un comparatore SN di = viene eliminato come ridondante; <> mantiene il testo, perché nessuna quantità può dire "non uguale".
• Visite. Un A08 con una data di dimissione (PV1-45) è un incontro terminato. Una classe di paziente mancante o sconosciuta è il sapore nullo UNK, perché R4 richiede una classe.
• Segmenti Z vengono nominati in un avviso, poiché non esiste una mappa standard per essi.

• Nomi. Quando il mittente divide un cognome (XPN.1, XCN.2) nelle sue parti - un prefisso del cognome e un cognome, quello della persona e quello del partner, come vengono inviati i nomi olandesi e fiamminghi - family è il nome completo e le parti vanno nelle estensioni del cognome di HL7 (humanname-own-prefix, -own-name, -partner-prefix, -partner-name).
• Procedure. PR1 diventa una Procedura con stato unknown, poiché un ADT non specifica se è stata eseguita o pianificata; l'anestesista (PR1-8) e il chirurgo (PR1-11) sono esecutori con ruoli SNOMED CT. Un codice OPS ottiene anche la sua categoria SNOMED CT dal suo capitolo, tramite la mappa OPS-SNOMED-Category di HL7 Deutschland, richiesta da ISiK.

8.4.2 Cosa aggiunge un sito: lo script del bundle

Un profilo nazionale spesso richiede ciò che un messaggio HL7 v2 non trasporta: il numero IK di un ospedale o il codice ODS, il livello di contatto di una visita (ISiK), se un nome è un nome proprio o un'iniziale (il nl-core olandese). Perfuse non indovina questi valori. La destinazione fhir ha uno script bundle_script dove un sito può scrivere questi valori: uno script JavaScript eseguito su ogni Bundle convertito, come bundle, prima della convalida e dell'invio. Ciò che lo script lascia è ciò che viene inviato, verificato come qualsiasi conversione, e uno script che genera un'eccezione fa fallire il messaggio come qualsiasi trasformatore. La console lo trova sotto la voce *Aggiungi ciò che i tuoi sistemi conoscono* della destinazione.

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 esegue lo stesso script, quindi un sito può provarlo sui propri messaggi per primo. Due esempi funzionanti sono nel repository: examples/isik/bundle-script.js (IKNR, Kontaktebene, numero di paziente MR, Diagnosetyp) e examples/nictiz/bundle-script.js (nomi propri e iniziali). Con essi i messaggi tedeschi e olandesi inventati in conformance/national passano da 18 a 42 risorse valide su 47 rispetto a ISiK e da 12 a 18 su 24 rispetto a nl-core; ciò che rimane è nei messaggi o nel server di terminologia, ed è elencato lì.

Il Bundle passa attraverso il modello di Perfuse sulla sua strada di ritorno, quindi le modifiche apportate da uno script vengono controllate e scritte nella versione FHIR della destinazione. I membri per i quali il modello non ha un campo vengono mantenuti come li ha scritti lo script, all'interno dei tipi di dati anche.

8.4.3 US Core 9.0.0 e USCDI v6

-us-core (e claim_us_core su una destinazione fhir) inserisce un profilo US Core in meta.profile, ma solo su una risorsa che è stata controllata contro quel profilo e trovata conforme. Una che non soddisfa è comunque convertita e inviata senza la pretesa, e una nota fornisce il motivo, come ad esempio "US Core richiede un tipo di incontro e questo Incontro non ne ha nessuno". I controlli sono trascritti da US Core 9.0.0, la versione che il processo di avanzamento delle norme 2026 di ONC approva per USCDI v6. Essi coprono Paziente, Incontro, l'osservazione e la relazione di laboratorio, Specimen, Operatore sanitario, Organizzazione, Località, Immunizzazione, DocumentReference, la diagnosi di incontro e AllergyIntolerance.

Ciò che il convertitore trasporta, per classe di dati USCDI v6:

Non trasportati, poiché i messaggi v2 di questi tipi non li contengono o Perfuse non li mappa: Farmaci, Procedure, Obiettivi e Preferenze, Valutazioni dello stato di salute, Piano di cura, Storia sanitaria familiare, Dispositivi medici (UDI), Informazioni sull'assicurazione sanitaria, Segni vitali come profilo distinto e Provenienza.

8.4.4 R4 in entrambe le direzioni

Un server FHIR che dichiara R4 accetta R4. Ciò non era vero per gli Incontri fino a questa versione. Il server convertiva ciò che serviva in R4 ma leggeva ciò che riceveva come se fosse già nella sua forma interna, quindi un Incontro R4 veniva rifiutato con un 400. Lo stesso valeva per ogni bundle che la conversione ADT di Perfuse produceva, poiché ognuno trasporta Encounter.class, che R4 scrive come un singolo codice.

È stato scoperto la prima volta che qualcosa ha pubblicato un ADT convertito sul server R4 di Perfuse. Un test ora lo fa per ogni tipo di messaggio mappato e un altro controlla che tutto ciò che viene scritto come R4 venga letto indietro invariato.

8.4.5 Riepilogo internazionale del paziente

GET /fhir/Patient/{id}/$summary, or GET /fhir/Patient/$summary?identifier=system|value, returns an International Patient Summary (HL7 IPS 2.0.0): a FHIR document Bundle whose Composition lists the patient's active problems, allergies, medicines, immunizations, results, vital signs, procedures, devices, past illnesses, social history and care plans, each with a readable narrative. It is the short record a clinician who has never met the patient reads first, and the summary the European Health Data Space exchanges between countries from 2029.

È costruito da ciò che il negozio FHIR contiene e nulla viene inventato:

• Le registrazioni contrassegnate come entered-in-error sono escluse.
• Una condizione risolta rientra sotto le malattie passate, non i problemi.
• Un ordine di medicinale che è stato interrotto o completato è storia, non un medicinale corrente.
• Le tre sezioni richieste dall'IPS (problemi, allergie, medicinali) sono sempre presenti. Quando una di esse non contiene nulla, la sezione

contiene il motivo codificato unavailable e indica che il server non dispone di informazioni, "il che non significa che non ce ne siano". Un elenco di allergie vuoto non deve mai essere interpretato come "nessuna allergia nota".

• I professionisti sanitari, le organizzazioni, i medicinali e le località a cui si riferiscono le voci sono inclusi, in modo che il documento possa essere letto autonomamente.

L'accesso segue $everything: un token limitato a un solo paziente ottiene un 403 per un altro, e un identificatore che corrisponde a due pazienti viene rifiutato piuttosto che indovinato. Viene costruito solo il profilo IPS; chiedere un altro profile viene rifiutato. Il documento che Perfuse produce dai suoi record di test valida contro il profilo IPS 2.0.0 Bundle con il validator HL7, senza errori. Un record costruito da feed reali può ancora fallire dove i codici del feed stesso falliscono (ad esempio, un nome visualizzato che il sistema di codici non utilizza), perché il riepilogo passa i dati come sono stati ricevuti.

Scambio → Collegamenti sanitari → Condividi riempie il contenuto con un riepilogo del paziente: digita l'ID FHIR del paziente e scegli Usa il suo riepilogo del paziente, quindi leggilo e crea il collegamento. La sua costruzione viene registrata come fhir.summary.

8.4.6 Riepiloghi di trasferimento per la cura post-acuta (PACIO)

When a patient leaves hospital for a nursing home, a rehabilitation unit or home health, the hospital's EHR sends a C-CDA: a transfer summary, a discharge summary or a CCD. Perfuse turns that document into the transfer summary PACIO's Transitions of Care guide describes (hl7.fhir.us.pacio-toc 1.0.0): one FHIR R4 document Bundle, US Core 8.0.1 inside, that the receiving facility's system can file without anyone reading XML.

• Ogni una delle quindici sezioni della guida è presente, ognuna con il proprio testo, nell'ordine della guida: direttive anticipate, allergie, salute comportamentale, stato funzionale, immunizzazioni, istruzioni di dimissione, dispositivi medici, farmaci, piano di cura, problemi, procedure, motivo di rimando, risultati, storia sociale e segni vitali.
• Una sezione del documento che non è presente viene indicata come mancante, mai compilata. Viene inviata vuota, con il motivo codificato unavailable e la frase "Il documento di invio non aveva una sezione ...". Una sezione di allergie vuota non deve essere interpretata come "nessuna allergia nota".
• Una sezione trasportata come testo solo mantiene il proprio testo e non riceve voci. La prosa non viene convertita in dati codificati. Stato funzionale, salute comportamentale (la sezione di stato mentale del C-CDA), direttive anticipate, dispositivi medici, piano di cura, istruzioni di dimissione, motivo di rimando e storia sociale vengono inviati in questo modo attualmente; le note lo specificano per ognuna.
• Le voci codificate diventano risorse secondo le stesse regole della conversione ordinaria: allergie (US Core AllergyIntolerance), problemi e diagnosi di dimissione (US Core Condition, elenco dei problemi o diagnosi di incontro), procedure, immunizzazioni, risultati, segni vitali e farmaci come un elenco di farmaci PACIO di MedicationStatements (104204-3, elenco dei farmaci dimessi, da una sezione di farmaci di dimissione; 104202-7, elenco dei farmaci attivi, altrimenti).
• Segni vitali nella forma FHIR. Una pressione sistolica e una pressione diastolica prese insieme diventano un pannello di pressione sanguigna (85354-9) con due componenti, e un codice più specifico (peso corporeo misurato, 3141-9) porta anche il codice dei profili dei segni vitali di FHIR (29463-7), oltre all'originale.
• Chi e da dove. L'autore del documento diventa l'autore della Composizione (un Practitioner, con il NPI quando il suo cifra di controllo è valido), il suo custode l'organizzazione custode, l'incontro che la comprende il soggiorno che la sintesi chiude. Un documento senza un autore o senza un custode viene rifiutato: la guida richiede entrambi, e Perfuse non metterà un nome su un record clinico che nessuno ha fornito.
• La negazione mantiene il proprio significato. "Nessuna allergia nota" (un'allergia negata a qualsiasi sostanza) viene inviata come SNOMED CT 716186003; un'allergia negata a un farmaco viene rifiutata, perché FHIR non può dirlo e la risorsa direbbe il contrario; un problema negato è refuted.

Tre modi per crearne uno:

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

Verificato con il validator ufficiale FHIR contro il profilo Bundle TOC 1.0.0, sugli esempi C-CDA di HL7 (un sommario di trasferimento, un sommario di dimissione e un CCD). L'unico errore che segnala è nella guida: ogni segno vitale corrisponde sia alla sua voce simple-observation che alla sua voce vital-signs nel Bundle, quindi non può essere evitato da nessun mittente. Non ancora completato: la trasformazione delle voci delle sezioni di solo testo (stato funzionale, stato mentale, piano di assistenza, dispositivi) in risorse codificate e il DocumentReference della guida TOC che indice un sommario di trasferimento archiviato.

8.4.7 Abbonamenti

Con -fhir-subscriptions, l'endpoint FHIR invia notifiche quando viene creato o modificato un Incontro o un Appuntamento. Segue le linee guida FHIR Subscriptions R5 Backport IG per R4, che è ciò che il CMS Interoperability Framework criterion 15 e la roadmap FHIR di TEFCA utilizzano per le notifiche di appuntamento e incontro.

Un client crea una Subscription che nomina un argomento e, facoltativamente, un filtro come Encounter?patient=Patient/123. Gli argomenti sono elencati nella dichiarazione di capacità:

Un filtro che nomina qualsiasi altra cosa viene rifiutato, non ignorato. Un filtro ignorato è una sottoscrizione che notifica su ogni paziente quando il client ha chiesto informazioni su uno solo.

Le proprietà attorno alle quali è costruita l'implementazione:

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

Ciò che un client può far fare al server è limitato di proposito:

• Gli endpoint devono essere https a meno che l'operatore non passi -fhir-subscriptions-allow-http, che è per un ricevitore di test.
• La politica di uscita viene applicata quando una sottoscrizione viene creata, nuovamente ad ogni consegna e sull'indirizzo che ogni connessione raggiunge effettivamente (quindi un nome che cambia ciò a cui si risolve tra il controllo e la connessione viene comunque rifiutato); i reindirizzamenti non vengono seguiti.
• Il payload predefinito è id-only, che indica cosa è cambiato e consente al ricevitore di recuperarlo con le proprie credenziali.
• Nulla di ciò che un ricevitore invia indietro viene mostrato a chicchessia, solo il suo codice di stato.

È disattivato a meno che non venga richiesto, perché una volta attivato, un client FHIR può far inviare a questo server i dati dei pazienti a un URL scelto dal client. Richiede un endpoint R4 che accetti scritture e si rifiuta di avviarsi altrimenti.

Non implementato, quindi nessuno deve scoprirlo provando:

• canali diversi da rest-hook
• battiti cardiaci
• notifiche su cancellazione
• le operazioni $status e $events

La vista Sottoscrizioni mostra l'argomento di ogni sottoscrizione, il filtro e l'endpoint, quanti eventi ha avuto, quanti sono stati accettati e quanti sono in attesa, e l'ultimo motivo per cui uno è stato rifiutato. I valori dell'intestazione e la stringa di query dell'endpoint vengono trattenuti, poiché è lì che vivono le credenziali del sottoscrittore.

8.5 Standard di telecomunicazione NCPDP

Richieste di rimborso farmaceutico. Intestazione a larghezza fissa seguita da segmenti variabili.

Due dettagli che contano, entrambi facili da sbagliare e produrre risultati plausibili:

L'intestazione è esattamente di 56 byte e ha una larghezza fissa. Un'intestazione breve non può essere rilevata solo dalla lunghezza, perché un'intestazione troncata più i segmenti successivi supera comunque i 56 byte. La rilevazione avviene nel fatto che un'intestazione corretta non contiene mai un byte separatore, quindi l'intestazione viene scansionata per uno e un messaggio che ne contiene uno viene rifiutato con il numero di byte che mancano.

0x1E e 0x1C sono marker di inizio di gruppo e campo, non separatori. Trattarli come separatori sposta ogni campo di un posto a sinistra e la maggior parte dei valori risultanti rimane plausibile — una quantità si trova dove ci si aspettava una fornitura giornaliera e entrambi sono numeri.

8.6 NCPDP SCRIPT

Ricette elettroniche, in XML. Il pacchetto interno si chiama eprescribe perché script era già stato preso dal motore JavaScript.

La principale preoccupazione di sicurezza è il flag di sostituzione e si legge al contrario dell'intuizione: sul filo, 0 significa che la sostituzione è consentita e 1 significa che la dispensazione deve essere eseguita come scritta.

Un flag di sostituzione assente viene rifiutato piuttosto che utilizzato come valore predefinito. Entrambi i valori predefiniti possibili raggiungono il paziente — uno potrebbe dispensare un generico dove il prescrittore richiedeva il marchio, l'altro potrebbe impedire una sostituzione che il prescrittore ha permesso — quindi non c'è un'ipotesi sicura e il messaggio si ferma.

Una prescrizione di classe II con confezioni è rifiutata e il costruttore non ne produrrà una.

I rifiuti e gli avvertimenti vengono mantenuti come elenchi separati piuttosto che come un elenco unico con tag di gravità, perché un lettore che deve controllare un campo di gravità per sapere se il messaggio è stato inviato alla fine non controllerà.

L'autorizzazione preventiva elettronica (PAInitiationRequest, PARequest, PAAppealRequest, PACancelRequest) e il beneficio della prescrizione in tempo reale vengono risposti dal lato del pagatore a /ncpdp/script e /ncpdp/rtpb, dal formulario del farmaco; vedere CMS-0057.

8.7 DICOM

Immagini. Perfuse può ricevere oggetti DICOM, richiedere un archivio remoto e memorizzarli in uno, tramite i servizi di rete DICOM classici o tramite DICOMweb, e può mantenere un archivio proprio per i visualizzatori.

DICOM non è un formato di messaggio nello stesso senso degli altri — gli oggetti sono grandi e la stretta di mano dell'associazione è più importante dell'analisi del payload. I titoli called_ae e calling_ae sono la ragione più comune per cui una prima connessione fallisce e il fallimento sembra un problema di rete piuttosto che di configurazione.

8.7.1 Ciò che un ascoltatore C-STORE accetta

Lasciato aperto, un ascoltatore DICOM accetta qualsiasi cosa da chiunque possa raggiungere la porta. Quattro impostazioni sotto Ciò che questo ascoltatore accetta restringono questo, e la prima è quella che vale la pena capire.

Accetta solo questi titoli AE chiamanti è la restrizione. Il titolo AE *chiamato* — quello accanto all'indirizzo — è il nome che un mittente compone, quindi identifica questo ascoltatore piuttosto che il mittente, e non è una restrizione. Chiunque possa raggiungere la porta può utilizzare il titolo AE chiamato corretto, perché è pubblicato per loro. Senza un elenco di chiamanti consentiti, qualsiasi host nella rete può spingere immagini in un canale clinico.

Accetta solo queste classi SOP e accetta solo queste sintassi di trasferimento accettano UID separati da virgole. Vuoto accetta ogni tipo di oggetto e negozia qualsiasi compressione offerta dal mittente, che include tipi che le destinazioni di questo canale non possono gestire. Rifiutare all'associazione è più chiaro per il mittente che accettare l'oggetto e fallire in seguito.

Oggetto più grande accettato è in byte e zero significa nessun limite. Le immagini a tutto schermo e le serie lunghe possono raggiungere i gigabyte, quindi il limite è altrimenti la memoria.

8.7.2 DICOMweb

DICOMweb è DICOM su HTTP: le ricerche QIDO-RS, WADO-RS e WADO-URI recuperano, STOW-RS archivia. I visualizzatori del browser come OHIF supportano solo DICOMweb, così come i servizi di imaging cloud (Google Cloud Healthcare, Azure Health Data Services, AWS HealthImaging). Perfuse lo utilizza in tre punti.

L'archivio di imaging. Avvia il server con -dicomweb-archive DIR (Impostazioni › Dati › Archivio di imaging) e mantiene oggetti nella cartella specificata, indicizzati in SQLite, e li serve a /dicomweb sull'indirizzo della console stessa: QIDO-RS ai livelli di studio, serie e istanza, WADO-RS per oggetti, metadati, frame e dati bulk, WADO-URI a /dicomweb/wado, e STOW-RS. La lettura richiede il ruolo di visualizzatore e l'archiviazione il ruolo di operatore, con una sessione o un token API; ogni lettura e archiviazione è registrata in Attività come dicomweb.read o dicomweb.store. Un account limitato a un tenant o a gruppi di canali viene rifiutato, poiché l'archivio appartiene all'intero server. Gli oggetti vengono mantenuti esattamente come ricevuti, quindi ciò che un visualizzatore recupera è byte per byte esattamente ciò che è stato archiviato. I frame vengono restituiti nella sintassi di trasferimento in cui sono stati archiviati; una richiesta che richiederebbe una trascodifica risponde con 406 anziché un'immagine convertita.

Una ricerca su un attributo che l'archivio non indicizza risponde con 400 anziché ignorare la condizione e restituire più studi di quanti richiesti. Indicizzati: nome del paziente (con caratteri jolly e corrispondenza fuzzy con fuzzymatching=true), ID del paziente, data di nascita, sesso, data e ora di studio (intervalli), numero di accesso, ID di studio, descrizione, medico di riferimento, studio, serie e istanza SOP UIDs (elenco), modalità, parte del corpo, numero e descrizione della serie, classe SOP, numero di istanza, righe, colonne e numero di frame.

La sorgente. type: dicomweb ascolta STOW-RS, a /dicom-web/studies per default (il percorso utilizzato da Orthanc e dcm4chee), e invia ogni oggetto attraverso il canale come messaggio DICOM. Il canale necessita di dataType: dicom. Imposta un token bearer o un nome utente e una password: senza uno di questi, chiunque possa raggiungere la porta può inviare immagini nel canale. La risposta elencare ogni oggetto come archiviato o fallito, con il motivo di fallimento DICOM, in modo che il mittente sappia quali inviare nuovamente.

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}

La destinazione si trova in delivery, sotto gli archivi DICOMweb.

Puntare OHIF all'archivio

Utilizza una sorgente di dati DICOMweb con qidoRoot e wadoRoot impostati sull'indirizzo dell'archivio (lo schermo Imaging lo mostra, con l'intero blocco di dati da copiare), wadoUriRoot su quell'indirizzo seguito da /wado, imageRendering e thumbnailRendering su wadors, e supportsFuzzyMatching su true. Un visualizzatore su un'altra origine necessita di quell'origine in -dicomweb-cors (Origin consentite a chiamarlo), e le sue richieste necessitano di un token API nell'intestazione Authorization, poiché un browser su un'altra origine non invia il cookie di sessione della console. La fornitura di OHIF dalla stessa origine attraverso un reverse proxy evita entrambi.

Testato contro Orthanc con il suo plugin DICOMweb, in entrambe le direzioni: la destinazione archivia in Orthanc, e il client DICOMweb di Orthanc cerca l'archivio di Perfuse e recupera uno studio byte-identico a quello archiviato. OHIF 3 elenca gli studi dell'archivio e visualizza i loro frame con le impostazioni sopra. OHIF e diversi altri client inviare type= non virgolettato nelle intestazioni Accept e Content-Type, il che RFC 2045 non consente; Perfuse lo accetta.

8.8 Condivisione di documenti IHE: XDS.b, XCA, XDR, MHD, PIXm e PDQm

Documenti clinici condivisi tra organizzazioni come fanno gli scambi di informazioni sanitarie, Carequality ed eHealth Exchange: un repository li conserva, un registro indice i loro metadati e una comunità risponde alle query di altre comunità attraverso un gateway. Avvia il server con -xds REPOSITORY-OID (Impostazioni › Dati › Condivisione di documenti) e sarà tutti e tre, nel database di questo servidor, agli indirizzi seguenti, ognuno dei quali accetta un token API come token bearer (il ruolo viewer per interrogare e recuperare, il ruolo operator per inviare; la maggior parte dei domini di affinità aggiunge TLS reciproco davanti)

Le transazioni SOAP sono SOAP 1.2 con WS-Addressing, e MTOM/XOP dove i documenti viaggiano (un documento in linea come base64 è accettato anche). Una transazione fallita risponde con una RegistryResponse che trasporta i codici di errore IHE, non una fault SOAP: XDSDuplicateUniqueIdInRegistry, XDSNonIdenticalHash, XDSPatientIdDoesNotMatch, XDSMissingDocument, XDSRegistryMetadataError (con il campo mancante), XDSStoredQueryMissingParam, XDSUnknownStoredQuery, XDSUnknownRepositoryId, XDSUnknownCommunity, e UnresolvedReferenceException. Un sostituto (RPLC, XFRM_RPLC) deprecia il documento che sostituisce, che quindi risponde solo alle query che chiedono documenti deprecati; APND, XFRM e signs vengono mantenuti come associazioni. Hash e dimensione vengono calcolati dal repository e verificati contro ciò che la presentazione afferma. I documenti e i metadati su richiesta (ITI-57) non sono supportati, e una presentazione che li richiede viene rifiutata con il motivo.

MHD è lo stesso registro in FHIR: un documento fornito tramite MHD viene trovato da ITI-18 e tramite XCA, e uno fornito tramite XDS.b viene ritrovato da ITI-67. L'ID di un DocumentReference è l'UUID dell'elemento, il suo masterIdentifier è l'uniqueId, e l'URL dell'allegato è l'indirizzo ITI-68 del documento. I pazienti vengono risolti nell'identificatore del dominio di affinità dal negozio FHIR: il primo identificatore il cui sistema è urn:oid:, o il Paziente trasportato nel Bundle. PIXm risponde con ogni altro identificatore del Paziente con quello fornito (sourceIdentifier=system|value, ristretto da targetSystem), e 404 per uno che non conosce; PDQm cerca per identificatore, nome, data di nascita, genere, indirizzo e telecom.

Pubblicazione. Una destinazione xds di un canale pubblica ogni documento clinico che riceve, un documento CDA o uno trasportato in un messaggio HL7 v2, in qualsiasi repository XDS.b con ITI-41. I metadati vengono letti dal documento: il paziente (l'identificatore in patient_domain, l'autorità di assegnazione del dominio di affinità), titolo, tipo (come typeCode e, a meno che non sia impostato, classCode), creazione e tempi di servizio, autore, riservatezza, lingua e formato (corpo strutturato C-CDA 2.1 o 1.1, XDS-SD o mimeTypeSufficient, dai suoi modelli); e completato da ciò che un documento non dice: l'source_id del mittente, il facility_type e il practice_setting che ogni registro richiede. La risposta del registro decide la consegna: un fallimento o un errore in un PartialSuccess è una consegna fallita con i codici di errore del registro.

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. Aggiungi direct_from (il tuo indirizzo Direct) e direct_to (quello dei destinatari) e lo stesso destinatario invia XDR come trasporto Direct, come descritto nel progetto Direct *XDR e XDM per Direct Messaging*: un blocco di indirizzamento Direct (urn:direct:addressing) nell'intestazione SOAP nomina il mittente e i destinatari e la intendedRecipient della presentazione nomina ogni destinatario (||^^Internet^address). Punta url all'endpoint XDR del destinatario o a un HISP che accetta XDR. XDR viaggia su TLS, di solito con un certificato client (tls), e non è S/MIME. Una sorgente direct accetta anche XDR (vedi Direct sotto).

    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 e PDQ in HL7 versione 3. Con l'indice dei pazienti attivato (-mpi), /pixv3 è un gestore PIX e /pdqv3 un fornitore PDQ tramite SOAP 1.2, per gli ospedali e gli scambi che ancora utilizzano i profili v3 di IHE. Una sorgente alimenta i pazienti con ITI-44 (record aggiunto PRPA_IN201301UV02, rivisto PRPA_IN201302UV02, duplicati risolti PRPA_IN201304UV02): il primo identificatore del paziente è il suo record, gli altri e quelli in asOtherIDs sono identificatori che porta, e una fusione incorpora l'identificatore del record precedente in quello sopravvissuto, come fa un A40 di HL7 v2. ITI-45 (PRPA_IN201309UV02) risponde con gli altri identificatori della persona che detiene uno, limitati da dataSource, in Patient.id; l'identificatore richiesto torna indietro solo nella query ripetuta. ITI-47 (PRPA_IN201305UV02) abbina le informazioni demografiche (nome, genere, data di nascita, identificatore, indirizzo, telecom) con il matcher dell'indice, minimumDegreeMatch come punteggio su 100, otherIDsScopingOrganization limita i domini e initialQuantity impagina la risposta: il resto arriva con QUQI_IN000003UV01 per dieci minuti, o viene eliminato dal suo annullamento. Le risposte seguono i casi delle transazioni: un paziente o dominio sconosciuto è AE con errore 204 e la posizione del parametro, un paziente noto con nulla nei domini richiesti è NF. v3 nomina un'autorità solo con OID, quindi un identificatore il cui sistema è un URL senza OID (alcuni numeri nazionali) è lasciato fuori dalle risposte v3 ed è fornito tramite FHIR; impostare il sistema dell'identificatore aziendale su un OID (urn:oid:..., nelle impostazioni dell'indice) per l'EUID e il custode da visualizzare. Il ruolo del visualizzatore richiede e il ruolo dell'operatore alimenta; ogni transazione è registrata con un identificatore, mai un nome. Un messaggio v3 nudo inviato come application/xml è risposto allo stesso modo, il che è utile per i test manuali.

Scambio › Condivisione di documenti mostra cosa contiene il registro e dove può essere raggiunto, trova i documenti di un paziente in questo registro o in un altro (il registro ITI-18 o il gateway ITI-38), scarica uno, e pubblica un documento CDA manualmente con i metadati che una destinazione gli fornirebbe.

Verificato contro il NIST XDS Toolkit 7.13.0, l'implementazione di riferimento IHE: Perfuse's ITI-41, ITI-18 e ITI-43 contro il suo simulatore di Registro/Repository (accettato senza errori di convalida, il documento recuperato byte-identico), e il suo simulatore di Initiating Gateway che interroga e recupera da Perfuse's Responding Gateway su XCA, senza errori nel suo log. Ogni messaggio SOAP che Perfuse scrive convalida contro gli schemi ebXML Registry 3.0 e XDS.b, e il DocumentReference e SubmissionSet MHD contro IHE MHD 4.2.2 con il convalidatore HL7 FHIR. XDR da una destinazione xds con un blocco di indirizzamento Direct è stato accettato dal simulatore di Document Recipient dello strumento, la cui convalida dei metadati ha trovato il difetto descritto in docs/verification.md, e dal convalidatore XDR di ONC SITE, la checklist Direct XDR del test di certificazione (h)(2) applicato. Le risposte PIX e PDQ v3 convalidano contro gli schemi HL7 V3 IHE (NE2008 multicacheschemas) e i messaggi di esempio IHE (l'alimentazione ITI-44, unione, query ITI-45, query ITI-47, continuazione e annullamento) vengono risposti come mostrano le loro risposte pubblicate. Non ancora verificato contro un'implementazione PIX o PDQ v3 indipendente, Gazelle o un Connectathon.

8.9 Messaggistica sicura diretta

Direct è il modo in cui i fornitori di assistenza sanitaria statunitensi si inviano reciprocamente richieste di consulto, riassunti e risultati tramite posta elettronica sicura: ogni messaggio è firmato con il certificato del mittente e crittografato per il certificato del destinatario (S/MIME), e viaggia tra i fornitori di servizi di informazione sanitaria (HISP) che rilasciano gli indirizzi e garantiscono per essi. Perfuse è il sistema di bordo accanto al tuo HISP, non un HISP: il HISP rilascia il tuo indirizzo, il suo certificato e la sua chiave, e tu mantieni il suo bundle di trust (come DirectTrust). Segue la Dichiarazione di applicabilità Direct per il trasporto sanitario sicuro 1.2, la Guida all'implementazione per la notifica di consegna, IHE XDM (ITI TF-1 Allegato 15) per i documenti con metadati, la Guida all'implementazione della scoperta dei certificati per il progetto Direct (DNS e LDAP), e XDR e XDM per la messaggistica Direct.

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

Ricezione. Una sorgente direct è il server SMTP a cui il HISP consegna la posta dell'indirizzo del mittente. Accetta la posta solo per quell'indirizzo (qualsiasi altra cosa è rifiutata al RCPT), richiede STARTTLS quando viene fornito un certificato, e apre ogni messaggio prima che qualcosa lo legga: lo decrittografa con la chiave del mittente, verifica la firma contro gli anchor del mittente, e controlla che il certificato di firma sia per l'indirizzo del mittente o il suo dominio. Un messaggio che non è crittografato S/MIME, è firmato da un mittente che non si fida, o è firmato da un certificato per qualcun altro è rifiutato al DATA con il motivo, quindi il HISP lo mantiene e lo segnala al mittente; Perfuse non accetta mai ciò che poi rifiuta. Un pacchetto XDM diventa un messaggio (verificato contro gli hash nei suoi metadati); altrimenti ogni allegato diventa un messaggio, o il testo quando non ce ne sono. Con smtp_host impostato, ogni messaggio preso in carico è risposto con una notifica "elaborato" firmata e crittografata (MDN), e le notifiche in arrivo per ciò che è stato inviato sono registrate.

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

Dalla casella di posta del HISP. Un HISP che conserva la posta invece di consegnarla dà all'indirizzo una casella di posta IMAP: imap la legge (TLS o STARTTLS, ogni poll una sessione fresca), apre ogni messaggio come sopra, sposta ciò che è stato preso in move_to (o lo elimina) e ciò che non poteva essere aperto in error_folder, quindi nulla viene letto due volte. listen può quindi essere omesso. Un HISP il cui server di posta ha un certificato privato è considerato attendibile con tls.ca_file (il suo certificato, o quello della sua autorità) e tls.server_name; la verifica non può essere disattivata.

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

XDR. xdr accetta XDR su /xdr sul proprio indirizzo HTTPS, come un HISP invia Direct convertito in SOAP o un partner invia punto a punto: una richiesta ITI-41 Provide and Register il cui documento diventa un messaggio. Una presentazione il cui blocco di indirizzamento Direct nomina un altro indirizzo viene rifiutata e uno che il canale non accetta viene risposto con una risposta di Registro con un messaggio di fallimento che spiega il motivo. client_ca_file richiede un certificato client da quelle autorità. XDR è protetto da TLS, non da S/MIME, quindi una sorgente che accetta solo XDR necessita dell'indirizzo ma non del certificato, della chiave o degli anchor. Ogni documento diventa un messaggio del tipo di dati dataType del canale: i documenti CDA necessitano di raw (passati come sono) o hl7v3, poiché il valore predefinito, hl7, si aspetta HL7 v2 e li rifiuta.

    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

Exchange › Direct elenca gli indirizzi Direct che i canali inviano e ricevono, con i loro certificati, scadenze e anchor; mantiene il registro degli indirizzi dei corrispondenti (nome, organizzazione, note e certificato, incollato dal loro HISP o trovato in DNS o LDAP e rifiutato se non è per quell'indirizzo o dominio); e cerca i certificati di un indirizzo in DNS o LDAP senza salvarli. Il registro è la directory direct-certs accanto al database, un file PEM per ogni indirizzo o dominio, che una destinazione legge a meno che non specifichi la propria directory recipient_certs_dir.

Verificato contro OpenSSL 4.0 con cms e smime in entrambe le direzioni: ciò che Perfuse firma e crittografa OpenSSL verifica e decrittografa (trasporto di chiavi PKCS#1 v1.5 e OAEP), e Perfuse apre ciò che OpenSSL firma e crittografa (AES-128 e AES-256). Un messaggio creato con openssl smime e consegnato tramite SMTP viene ricevuto, aperto e archiviato da un canale, e uno inviato da Perfuse a un altro attraverso un sostituto HISP, che risponde con un MDN che il mittente apre. I certificati sono trovati in OpenLDAP 2.4 (associati a indirizzi e domini, scritti dal comando ldapadd di OpenLDAP); un messaggio Direct viene letto da una casella di posta IMAP GreenMail e aperto, e uno che non è Direct viene spostato nella cartella degli errori; XDR da una destinazione xds viene preso da una sorgente direct e rifiutato quando indirizzato a qualcun altro, e accettato dal toolkit di documenti NIST XDS e dal validator XDR del sito ONC; lo strumento di test Edge XDR Direct del sito ONC ha inviato sia il messaggio di metadati minimo che quello completo a una sorgente direct, che li ha accettati. Contro lo strumento di scoperta dei certificati Direct di ONC, una destinazione Direct sceglie il certificato giusto, o nessuno, in tutti e 18 dei casi di scoperta (D1 a D18: certificati scaduti, revocati e rilasciati AIA, priorità e peso SRV, directory non raggiungibile). Una sorgente Direct legge un messaggio dalla HISP del sito ONC (Apache James) tramite IMAP con STARTTLS. Non ancora testato: scambio SMTP con la HISP del sito ONC (AWS tiene la posta in uscita sulla porta 25 per i nuovi account) o con una HISP accreditata.

8.10 SQL su viste FHIR

Una ViewDefinition (HL7 SQL su FHIR v2) trasforma ogni risorsa FHIR di un tipo in righe di colonne nominate, ogni colonna un'espressione FHIRPath, in modo che i dati FHIR possano essere letti come tabelle da DuckDB, Athena, Spark, un data warehouse o un foglio di calcolo. Perfuse esegue queste operazioni con il suo own motore FHIRPath: column, select annidati, forEach, forEachOrNull, repeat e unionAll, where, constant (ogni tipo di valore[x]), colonne collection, %rowIndex, e le chiavi di join getResourceKey() e getReferenceKey(type).

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

Monitor › SQL on FHIR esegue una vista su questo server FHIR (un paziente, o tutti) o su risorse incollate (NDJSON da un'esportazione bulk, un Bundle, un array JSON), mostra le righe e le scarica come CSV, NDJSON o Parquet. Inizia con cinque viste di esempio (dati demografici del paziente, osservazioni con un valore, pressione sanguigna, condizioni, incontri) e salva le viste nella directory views accanto al database, un file JSON per ogni vista.

The FHIR endpoint answers the specification's $sql-run at the system level, by GET or POST, for a ViewDefinition subject given inline (subjectResource), by subjectReference (ViewDefinition/<name>, a saved view) or by subjectCanonical (a saved view's url), with _format (csv, ndjson (the default), json or parquet), header, patient, _since, _limit, and resource to run over resources sent with the request instead of the store. It is a read: a SMART token needs read scope for the view's resource type, a token bound to one patient gets that patient's rows only, and granular scopes narrow the resources read, as they do a search. More than a million rows needs _limit, patient or _since.

perfuse sof -view v.json [-format csv|ndjson|json|parquet] [-o out] files... esegue una vista su file FHIR senza un server: I file NDJSON di un'esportazione bulk, Bundles o array.

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"

I file Parquet hanno un gruppo di righe e pagine PLAIN non compressi; i booleani sono BOOLEAN, i tipi interi INT64, i decimali DOUBLE e tutto il resto stringhe UTF-8 (una colonna di raccolta come il suo JSON).

Verificato con la suite di test ufficiale SQL on FHIR (i 144 test del repository sql-on-fhir.js tests/, eseguiti su ogni build: tutti superati), e l'output Parquet letto nuovamente da DuckDB 1.5.6 con i tipi e i valori corretti. Non supportati: SQLQuery e SQLView Libraries (SQL sulle tabelle delle viste), $sql-export, _format=fhir e i parametri source e group; ogni uno viene rifiutato con il motivo.

8.11 Misure di qualità digitali

Una misura di qualità digitale conta i pazienti in ogni popolazione di una misura FHIR Measure su un periodo di misurazione (popolazione iniziale, denominatore, esclusioni e eccezioni del denominatore, numeratore, esclusioni del numeratore) e valuta il risultato. La risposta è un rapporto di misura FHIR MeasureReport, modellato come richiesto dalla guida Da Vinci Data Exchange per le misure di qualità (DEQM). È qui che si stanno dirigendo i programmi eCQM di CMS e le misure digitali HEDIS di NCQA.

In Perfuse i criteri di popolazione sono FHIRPath ("language": "text/fhirpath"), eseguiti dallo stesso motore di SQL on FHIR. Ogni criterio viene valutato una volta per paziente. Il suo focus è un Bundle del record del paziente (la compartment del Paziente), e ha queste variabili: %subject (il Paziente), %periodStart e %periodEnd (il periodo, come dateTimes) e %"Measurement Period". Un criterio restituisce true o false; un singolo valore esistente conta come true.

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

Le popolazioni si annidano come specifica la specifica della misura. Un paziente è nel denominatore solo se è nella popolazione iniziale. Un'esclusione del denominatore rimuove il paziente prima che venga valutato il numeratore. Un'eccezione del denominatore conta solo per un paziente non nel numeratore. Il punteggio di una proporzione è (numeratore - esclusioni del numeratore) / (denominatore - esclusioni - eccezioni); il punteggio di un rapporto è numeratore / denominatore; un cohort ha conteggi e non ha punteggio. Gli stratificatori a singolo criterio dividono ogni popolazione in base al loro valore (sesso, ad esempio).

Perfuse non ha un motore CQL. Le misure eCQM di CMS e le misure digitali HEDIS pubblicate sono scritte in CQL, quindi non possono essere eseguite così come sono. Una misura il cui criterio è CQL viene rifiutata con quel motivo. Scrivere la logica come FHIRPath invece. Il punteggio di variabili continue, gli stratificatori multicomponente e i soggetti Gruppo o Operatore vengono rifiutati nello stesso modo.

Monitor → Misure di qualità valuta una misura su questo server FHIR o su risorse incollate, per un periodo. Offre tre rapporti: un riassunto, un riassunto con i pazienti in ogni popolazione o uno per paziente. Lo schermo mostra le popolazioni, il punteggio e gli strati e scarica il MeasureReport. Inizia da tre esempi: pressione sanguigna sotto controllo, diabete con un test HbA1c e pazienti visti nel periodo. Sono illustrativi, scritti per questo manuale e non sono misure eCQM di CMS o HEDIS. Salva nel negozio FHIR controlla la misura e la memorizza come risorsa Measure.

L'endpoint FHIR risponde a Measure/[id]/$evaluate-measure e Measure/$evaluate-measure?measure=<url>, tramite GET o POST di una risorsa Parameters. Parametri:

• periodStart e periodEnd: obbligatori. Una data significa l'intera giornata.
• reportType: summary, subject o subject-list.
• subject: Patient/<id>.
• reporter: Organization/<id>. Quando è assente, il report contiene un'organizzazione denominata da serve -measure-reporter.
• measure: una misura inviata in linea, come parametro POST.

Il report viene restituito, non memorizzato. L'operazione è una lettura, quindi un token SMART necessita di accesso in lettura a Measure e a Patient. Un token legato a un paziente ottiene un report individuale su quel paziente e nessun altro.

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... valuta una misura su file FHIR (un'esportazione bulk in NDJSON, Bundles, array) senza un server. -measure example:example-bp-control esegue un esempio predefinito, e -examples li elenca.

Verificato. Il validatore HL7 FHIR controlla le misure fornite contro FHIR R4, senza errori. Controlla un riassunto, un individuale e un MeasureReport di elenco di soggetti contro i profili riassuntivi, individuali e di elenco di soggetti DEQM 5.0.0, anch'essi senza errori. Non verificato: equivalenza con qualsiasi eCQM pubblicato, poiché nessuno può essere eseguito qui senza CQL.

8.12 L'indice dei pazienti (MPI)

Un indice dei pazienti master collega i record che ogni sistema mantiene per una persona (il MRN dell'ospedale, quello della clinica, quello del laboratorio) in un unico identificatore aziendale, l'EUID. È disattivato fino a quando qualcuno decide di mantenerlo, poiché è una tabella dei nomi dei pazienti, delle date di nascita e degli identificatori: attiva Impostazioni → Dati → Indice dei pazienti (o serve -mpi) e riavvia. Vive in mpi.db accanto al database principale.

Alimentarlo. Aggiungi una destinazione di tipo mpi (L'indice dei pazienti nel costruttore) ai canali che trasportano le registrazioni. Legge il PID di ogni messaggio HL7 v2 o un paziente FHIR su un canale grezzo. L'identificatore del record è la ripetizione PID-3 di tipo MR (id_type lo modifica); gli altri, e PID-19, diventano i suoi altri identificatori. Un'autorità di assegnazione con un identificatore universale (PID-3.4.2 con tipo ISO) diventa urn:oid:...; uno con solo uno spazio dei nomi viene mappato da authorities, o diventa urn:perfuse:aa:<namespace>. Un A40, A34, A18 o A39 unisce la persona che detiene l'identificatore MRG-1 con la persona che detiene PID-3 (no_merge li ignora).

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

Abbinamento. Un nuovo record è collegato in questo ordine:

1. Identificatori attendibili. Un record che condivide un identificatore da un sistema elencato come attendibile (un identificatore nazionale, un numero aziendale) è la stessa persona, senza punteggi. Non elencare mai un sistema condiviso da una famiglia, come un numero di abbonato di un'assicurazione.
2. Punteggio. Altrimenti, le persone le cui registrazioni potrebbero corrispondere vengono trovate tramite blocco (lo stesso cognome e anno di nascita, la stessa data di nascita o lo stesso numero di telefono) e valutate con pesi Fellegi-Sunter su nome e cognome (Jaro-Winkler e Soundex, accenti e punteggiature ignorati, nomi scambiati notati), data di nascita (un giorno e un mese scambiati sono parzialmente concordi), sesso, codice postale, telefono e indirizzo. Solo i campi presenti in entrambi i record vengono conteggiati. Il punteggio è la prova trovata come percentuale della prova possibile. Il blocco utilizza cinque chiavi, quindi un errore non nasconde una persona: suono del cognome e anno di nascita, data di nascita, telefono, suono dei nomi (in qualsiasi ordine) e codice postale con il suono del nome.
3. Decisione. Per impostazione predefinita, nulla viene collegato in base al punteggio solo. Un record con un punteggio pari o superiore alla soglia di revisione (60%) diventa una nuova persona e la possibile corrispondenza attende nella coda di revisione; quelli con un punteggio pari o superiore alla soglia automatica (90%) con cognome e data di nascita entrambi concordi vengono contrassegnati come *certi*. Collegare due persone in una (un sovrapposizione) mette i risultati di un paziente nel grafico di un altro, quindi il collegamento automatico è un interruttore che un amministratore attiva (Collega le corrispondenze certe senza chiedere a nessuno) una volta che la coda ha mostrato che le corrispondenze certe sono corrette. Con esso attivato, una corrispondenza certa si collega quando non c'è una seconda persona con un punteggio altrettanto alto. Al di sotto della soglia di revisione, il record è una nuova persona.

Numeri nazionali. Il numero NHS (e il CHI della Scozia e il numero sanitario e assistenziale dell'Irlanda del Nord), il PPSN e l'IHI dell'Irlanda, il KVNR della Germania, il SVNR dell'Austria, il numero AHV della Svizzera, il BSN dei Paesi Bassi, il numero di registro nazionale del Belgio, il matricule del Lussemburgo, l'INS (NIR e NIA) della Francia, il codice fiscale dell'Italia, il DNI/NIE e il CIP-SNS della Spagna, il numero SNS del Portogallo, i numeri personali nordici (Svezia, Danimarca, Norvegia con il numero D, Finlandia, Islanda), i codici baltici, il PESEL della Polonia, i numeri di nascita ceca e slovacca e i numeri ungheresi, rumeni, bulgari, croati, sloveni e greci sono noti all'indice. Ognuno viene memorizzato in un solo modo: sotto il sistema del proprio schema, spazi e punti rimossi, quindi il numero NHS inviato come urn:oid:2.16.840.1.113883.2.1.4.1|999 000 0018 da un sistema e come https://fhir.nhs.uk/Id/nhs-number|9990000018 da un altro è un solo identificatore. Una ripetizione PID-3 HL7 v2 il cui tipo di identificatore è NN e un codice di tre lettere di un paese (NNDEU, NNNLD) viene letto come il numero principale di quel paese, e il tipo NH dall'autorità NHS come il numero NHS. Il cifra di controllo di ogni numero viene verificato: uno che fallisce viene mantenuto nel proprio record, segnalato (mascherato) nella risposta e mai utilizzato per collegare o trovare qualcuno, poiché un errore di battitura di un solo cifra di solito crea il numero di un'altra persona. Il CPR della Danimarca viene verificato solo per la data, poiché i numeri emessi dal 2007 non devono superare l'antico modulo 11.

Le impostazioni elencano ogni schema con il proprio formato, il proprio controllo e il sistema in cui viene memorizzato. I sistemi presi dalla guida FHIR del paese (UK Core, fhir.de, Nictiz, CH Core, ANS, HL7 Italia, MedCom, i registri OID svedesi, norvegesi e finlandesi) sono contrassegnati come tali; gli altri sono impostazioni predefinite che possono essere modificate nel valore nazionale, che un sito può fare per schema (il vecchio viene ancora riconosciuto). L'attendibilità di uno schema è un solo segno di spunta. I numeri nazionali vengono mostrati per intero agli editor e agli amministratori per impostazione predefinita e mascherati (gli ultimi caratteri) a tutti gli altri; Chi vede i numeri per intero cambia questo, fino ai visualizzatori o fino agli amministratori soltanto. Dove la legge di un paese limita l'uso di un numero (Référentiel INS della Francia, PPSN dell'Irlanda, numero di registro nazionale del Belgio, §290 SGB V della Germania), le impostazioni lo dicono. GET /api/mpi/schemes elenca gli schemi e POST /api/mpi/check verifica un numero senza memorizzarlo. FHIR $match e PIXm rispondono ai client autorizzati con numeri per intero.

Una data scritta giorno- o mese-prima (08/15/1972) viene mantenuta come scritta e non corrisponde a una scritta anno-prima: gli ordini degli Stati Uniti e dell'Europa non concordano, e supporre sarebbe collegare le persone sbagliate.

La schermata dell'indice dei pazienti (Build) mostra i conteggi, trova le persone per nome, numero, EUID o data di nascita e apre ogni persona: i propri record, ogni identificatore e la storia di ciò che è accaduto loro e chi l'ha fatto. Gli editor decidono le revisioni (La stessa persona le collega; Persone diverse le mantiene separate per sempre), spostano un record in un'altra persona, rimuovono un record (Non questa persona) e fondono due persone. Gli amministratori impostano le soglie, i sistemi di identificatori attendibili, i numeri nazionali e il sistema EUID. Ogni ricerca e ogni persona letta vengono scritte nel registro di controllo.

Rispondere agli altri. POST /fhir/Patient/$match (l'operazione FHIR, come IHE PDQm utilizza ITI-119) accetta un Paziente e restituisce le persone che potrebbero essere, meglio in primo luogo, ogni Paziente il cui ID è l'EUID, con ogni identificatore, search.score e l'estensione del grado di corrispondenza (certain, probable, possible); onlyCertainMatches e count vengono onorati. PIXm (/mhd/Patient/$ihe-pix, ITI-83) risponde dall'indice: ogni identificatore di ogni record collegato alla persona e l'EUID. Lo fanno anche PIX e PDQ in HL7 v3 (/pixv3, /pdqv3; vedere la condivisione dei documenti IHE).

L'API è /api/mpi (riassunto e ricerca), /api/mpi/persons/{euid}, /api/mpi/find, /api/mpi/reviews, /api/mpi/records (registro, collegamento, scollegamento), /api/mpi/merge e /api/mpi/settings.

Pesi. I pesi predefiniti di Fellegi-Sunter provengono dalla letteratura sull'abbinamento dei record per i dati di registrazione ospedaliera. Stima dai nostri record (nelle impostazioni, amministratori; POST /api/mpi/estimate) li adatta all'indice del sito con la massimizzazione dell'attesa, senza richiedere coppie revisionate: m (accordo tra true match) dalle coppie che il blocco riunisce, u (accordo casuale) da 20.000 coppie estratte a caso, poiché le coppie bloccate concordano sui nomi e sulle date per costruzione. La stima è visualizzata accanto ai pesi in uso e non modifica nulla fino a quando non viene utilizzata e salvata. Un campo confrontato su troppo poche coppie mantiene il valore predefinito. L'adattamento presume che i campi siano indipendenti dato la classe, il che non è del tutto vero, quindi si deve trattare un grande cambiamento con sospetto.

Misurato. Sul set di dati FEBRL 3 (5.000 record sintetici di 2.000 persone, i duplicati con errori di digitazione, campi scambiati, valori mancanti e nomi abbreviati; PERFUSE_TEST_FEBRL), registrati in ordine di file con un revisore che risponde correttamente a ogni coppia in coda:

Nessun record è stato mai collegato alla persona sbagliata e nessuna delle 2.000 nuove persone è stata messa in coda inutilmente. Quelli mancanti differiscono quasi in ogni campo (una data di nascita e un indirizzo entrambi errati, ad esempio) e hanno un punteggio inferiore alla soglia di revisione. FEBRL è sintetico e ha pochi omonimi; un indice reale ne ha di più, quindi la sua coda di revisione sarà più lunga e questi numeri sono un limite inferiore per la cura, non una promessa.

8.13 Delimitato

CSV e i suoi parenti. Le opzioni sono sulla sorgente nel costruttore e la referenza del formato elenca le chiavi del file.

I percorsi indirizzano le colonne. Una colonna denominata è disponibile quando viene dichiarata una riga di intestazione o vengono forniti i nomi; altrimenti le colonne sono posizionali.

8.13.1 Denominazione delle colonne

Ci sono due modi e sono esclusivi. O la prima riga del file li denomina — la prima riga denomina le colonne — o li elenchi manualmente, in ordine. Dichiarare un'intestazione significa che la riga non viene trattata come dati.

Se nessuna delle due opzioni è impostata, le colonne possono essere indirizzate solo per posizione, quindi un filtro scritto contro un nome non ha nulla da confrontare. L'attivazione dell'intestazione rimuove l'elenco dei nomi invece di mantenerli entrambi: con un'intestazione i nomi provengono dal file, quindi un elenco lasciato indietro verrebbe ignorato e un canale che legge come se avesse scelto i nomi quando il file li ha scelti è più difficile da debuggare di uno che rifiuta.

8.13.2 Cosa vede un filtro o uno script

Un documento delimitato diventa molti messaggi, quindi questo deve essere dichiarato prima di scrivere entrambi.

Con la divisione attivata, tutto funziona per riga. I passaggi dichiarativi, il filtro e lo script di trasformazione vedono una riga, e un percorso significa *la colonna di questa* riga. Un filtro che rifiuta una riga rifiuta solo quella riga e il conteggio ricevuto è righe invece di documenti.

Con la divisione disattivata, il messaggio è l'intero documento e una scrittura che attraversa le righe viene rifiutata invece di essere applicata alla prima. Questo rifiuto è deliberato: scrivere silenziosamente sulla prima riga è il comportamento che produce un file che sembra trasformato e non lo è.

8.13.3 I tre che cambiano cosa conta come errore

Accetta righe con il numero di colonne errato è disattivato per impostazione predefinita. Una riga con troppe o troppe poche colonne è quindi un errore, il che è ciò che cattura un file il cui formato è cambiato senza preavviso. Attivarlo accetta la riga e lascia le colonne mancanti vuote.

Rimuovi gli spazi intorno a ogni valore risolve il caso comune di un valore riempito con una larghezza di colonna. Lascialo disattivato dove gli spazi finali sono significativi, il che a volte accade in un identificatore.

Mantieni le righe vuote come righe è disattivato per impostazione predefinita e di solito dovrebbe esserlo. Attivato, una riga vuota diventa una riga di colonne vuote, il che conta solo quando un conteggio deve corrispondere esattamente al file.

8.14 Grezzo

Nessun parsing. Il messaggio è byte.

Utilizza questo quando il contenuto non è qualcosa che Perfuse comprende e non ha bisogno di: un PDF spostato tra sistemi, un formato proprietario, un documento già formato inoltrato invariato.

Il costo è che nulla che dipende dalla struttura funziona — nessuna trasformazione a livello di campo, nessun filtro su un campo, nessun confronto a livello di campo nel controllo di parità. Un canale grezzo è una pipe e è onesto nel dire di esserlo.

8.15 Scegliere

Se il messaggio è HL7 v2, utilizza hl7, anche se si intende inoltrarlo invariato. L'analisi fornisce la traccia, le statistiche a livello di campo, la possibilità di filtrare in seguito e la possibilità di confrontare. raw su contenuti analizzabili non offre nulla e perde tutto ciò.

Utilizza raw quando l'analisi fallirebbe o sarebbe una menzogna sul contenuto.

8.16 Collegamenti e carte di salute SMART

*Kill the Clipboard* di CMS chiede ai fornitori di accettare i record di un paziente da un codice QR al momento del check-in e di restituire il record della visita allo stesso modo. Il codice QR contiene un SMART Health Link (shlink:/...): un indirizzo, una chiave a 256 bit e, opzionalmente, un'etichetta, una data di scadenza e una bandiera di passcode. Exchange → Health links legge uno.

Ricezione. Incolla il link o scansionalo con la fotocamera dove il browser può (Chrome e Edge). Perfuse recupera il manifesto, decrittografa ogni file con la chiave dal link, riassume eventuali bundle FHIR - chi è il paziente, quanti di ogni risorsa - e controlla eventuali SMART Health Card all'interno contro la chiave pubblicata dell'issuer. *Consegna al canale* consegna il contenuto FHIR a un canale come messaggio, che è come raggiunge il sistema di gestione sanitaria. La richiesta è limitata alla politica di uscita al momento della connessione, l'HTTP semplice è rifiutato e la risposta di un server che non è un server di manifesto non viene mai visualizzata, perché l'indirizzo proveniva da un codice QR di uno sconosciuto.

Condivisione. *Condividi* crittografa un bundle FHIR, lo ospita e visualizza il link e il suo codice QR una volta. Il server mantiene il testo cifrato e non la chiave - non può aprire ciò che ospita e non può visualizzare il link nuovamente. Un passcode viene hashato; dieci errori disabilitano il link. I link scadono dopo 30 giorni per impostazione predefinita, possono essere revocati e elencano quante volte e da chi sono stati recuperati. Avvia il server con -public-url impostato sull'indirizzo https raggiunto dai telefoni dei pazienti; l'URL del manifesto che costruisce deve adattarsi ai 128 caratteri della specifica.

Verifica di una carta. *Verifica una carta* prende un codice QR numerico shc:/ (un blocco o più), un file .smart-health-card o un JWS e dice se la firma corrisponde alla chiave dell'issuer.

8.17 UN/EDIFACT

dataType: edifact legge gli scambi UN/EDIFACT (ISO 9735): ORDERS, INVOIC, DESADV, IFTSTA e il resto, compresi i messaggi di assistenza sanitaria europei e di laboratorio. La stringa di servizio consiglia (UNA) è onorata, con il carattere di rilascio e, per la versione della sintassi 4, il separatore di ripetizione; i gruppi funzionali (UNG/UNE) sono opzionali. Lo scambio è consegnato esattamente come lo ha scritto il mittente.

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

La busta. Il conteggio dei segmenti UNT e il riferimento, il conteggio dei messaggi UNE e il riferimento e il conteggio UNZ e il riferimento sono confrontati con ciò che contiene lo scambio. Con require, il valore predefinito, una discrepanza rifiuta lo scambio (è come se un trasferimento interrotto mostrasse); warn accetta e registra un avvertimento; ignore non controlla.

Percorsi, per i filtri del canale e della destinazione, contano elementi e componenti a partire da 1 nell'ordine in cui il segmento è scritto, come le guide di implementazione li numerano: BGM-2 (il numero del documento), BGM-1.1, NAD(2)-2.1 (la seconda parte di NAD), LIN-3(2).1 (una ripetizione), UNB-2.1 (il mittente), UNH-2.1 (il tipo di messaggio). Un percorso senza un'occorrenza si riferisce a ogni occorrenza.

Dividere consegna uno scambio per messaggio, ognuno con l'UNB originale (e l'intestazione del gruppo) e trailer che contano uno, in modo che un ordine possa essere filtrato, cercato e ritentato da solo. I filtri di destinazione visualizzano ogni pezzo. Una destinazione del file nomina i file per tipo di messaggio (ORDERS_INVOIC-20261017.edi), e ${control_id} è il riferimento dello scambio.

CONTRL. Con acknowledge: contrl, un mittente che invia tramite HTTP riceve una risposta con sintassi CONTRL e rapporto di servizio: azione UCI 7 quando lo scambio è stato letto e consegnato, 4 quando è stato rifiutato o non poteva essere deliverato (allora HTTP 400 o 502). Non può essere combinato con split, poiché un CONTRL risponde a un intero scambio. Su AS2 la ricevuta del partner è l'acknowledgement.

Non offerto: i directory dei messaggi (che segmenta ORDERS D.96A consente), quindi la struttura è controllata, non il contenuto; le trasformazioni, che riscriverebbero un documento del partner; e script di filtro o trasformatore (un preelaboratore esegue, prima dell'analisi). Controllato contro pydifact 0.1.8, un parser indipendente, in entrambe le direzioni.

9 Conferme

Una conferma dice al mittente cosa è successo. Per HL7 v2 su MLLP è un messaggio di conferma; il mittente non invierà il prossimo messaggio fino a quando non arriva, e di solito lo rinvierebbe se non arriva.

Sbagliare le conferme è il modo più comune in cui un'integrazione perde silenziosamente i dati, perché un mittente che sta ricevendo conferme non ha motivo di lamentarsi.

9.1 Temporizzazione

Coperto in flusso di messaggi, e il riassunto è: ack.when è on_delivery per impostazione predefinita, il che significa che la conferma viene inviata solo dopo che ogni destinazione abilitata ha accettato il messaggio. on_receipt la invia non appena il messaggio viene analizzato e messo in coda.

9.2 Cosa invia Perfuse

Un AA quando il messaggio è stato accettato, un AE quando è stato rifiutato per un motivo per cui il mittente poteva agire, e un AR quando è stato rifiutato per un motivo per cui il mittente non poteva.

La distinzione tra AE e AR è chi deve fare qualcosa. AE significa che il messaggio aveva un problema - un campo che non poteva essere analizzato come data, un segmento richiesto mancante - e il mittente può correggerlo e rinviarlo. AR significa che Perfuse non poteva accettarlo indipendentemente dal contenuto, il che di solito significa un problema di configurazione o di disponibilità a questo livello. Un mittente che rinvierebbe dopo un AR otterrebbe la stessa risposta.

9.3 Identificazione di questo motore

ack.application e ack.facility popolano MSH-3 e MSH-4 dell'acknowledgement.

Quando entrambi sono vuoti, l'acknowledgement riflette il ricevitore originale — utilizza ciò che il messaggio in entrata aveva in MSH-5 e MSH-6. È ciò che la maggior parte dei mittenti si aspetta e rappresenta il valore predefinito per questo motivo.

Impostarli esplicitamente quando il mittente li valida, o quando più istanze di Perfuse gestiscono lo stesso feed e è necessario sapere quale di esse ha risposto.

9.4 L'evento trigger

ack.include_trigger_event invia ACK^A01 anziché un semplice ACK.

Alcuni ricevitori lo richiedono e altri lo rifiutano, il che è il motivo per cui rappresenta un'opzione esplicita senza un valore predefinito intelligente. Se un mittente sta rifiutando le vostre acknowledgement e il contenuto sembra corretto, questa è la prima cosa da provare.

9.5 Le acknowledgement negative non sono fallimenti da nascondere

Un NACK trattato come un successo rappresenta una delle configurazioni più dannose possibili e si verifica abbastanza frequentemente da essere degno di essere menzionato. Si verifica quando un destinatario invia un'acknowledgement negativa e il lato di invio registra la *trasmissione* come riuscita perché i byte sono stati inviati e qualcosa è tornato.

Perfuse legge l'acknowledgement che riceve da un destinatario MLLP e registra l'esito di conseguenza. Un AE o AR da un sistema a valle rappresenta un fallimento di consegna, viene ritentato in base alla politica del destinatario e contribuisce al tasso di fallimento che attiva gli avvisi.

9.6 Timeout

L'attesa di un'acknowledgement è limitata. Quando non arriva in tempo, la consegna rappresenta un fallimento e viene messa in coda per il ritento.

Un timeout non è lo stesso di un rifiuto e viene registrato in modo diverso. Un rifiuto significa che il lato remoto ha considerato il messaggio e lo ha rifiutato; un timeout significa che non si sa se sia stato elaborato. Quella distinzione decide se un ritento sia sicuro: ritentare dopo un rifiuto è inutile, e ritentare dopo un timeout rischia di generare un duplicato. Perfuse ritenta dopo un timeout, perché un messaggio clinico mancante è generalmente peggiore di un duplicato e il sistema di ricezione è generalmente in grado di rilevare un ID di controllo del messaggio ripetuto.

Se quel compromesso sia giusto per un determinato feed rappresenta un giudizio e vale la pena di effettuarlo deliberatamente per tutto ciò che ha una conseguenza clinica per un duplicato — un ordine, un'amministrazione di farmaci — anziché accettare il valore predefinito in silenzio.

9.7 Sorgenti che non inviano acknowledgement

Non tutti i trasporti hanno il concetto. Una sorgente file non ha dove inviare un'acknowledgement; una sorgente broker la invia al broker anziché al mittente originale; una sorgente HTTP risponde con un codice di stato.

Quando la sorgente non può consegnare la modalità di acknowledgement richiesta da un canale, il canale viene rifiutato al caricamento anziché avviarsi e non inviare acknowledgement in silenzio. Un canale che crede di inviare acknowledgement e non lo fa è peggiore di uno che non si avvia.

9.8 Acknowledgement X12

Tutto ciò che precede riguarda HL7 v2. X12 ha le proprie acknowledgement, e a differenza di v2 sono disattivate per impostazione predefinita: un'impostazione vuota significa nessuna.

Quel valore predefinito è il più sicuro, perché un partner commerciale che non si aspetta un'acknowledgement e la riceve potrebbe trattarla come un'intercambio non sollecitato. La chiave acknowledge su un canale X12 può avere uno dei quattro valori:

Quale inviare è una proprietà della relazione del partner commerciale piuttosto che del messaggio, il che è il motivo per cui deve essere configurato e non può essere dedotto. Un 999 sostituisce un 997 per le transazioni HIPAA, ma molti partner — soprattutto le connessioni dei pagatori più vecchie — sono configurati per aspettarsi un 997 e tratteranno un 999 come un file non riconosciuto.

9.9 Acknowledgement HL7 v3

Un canale HL7 v3 invia un'acknowledgement per impostazione predefinita, il che è l'opposto di X12 e vale la pena conoscerlo.

La ragione è il trasporto piuttosto che lo standard: un'interazione v3 arriva generalmente su una connessione sincrona con l'applicazione di invio in attesa di una risposta, e un mittente che non riceve nulla riproverà solitamente. È così che un paziente viene registrato tre volte.

Disabilitarlo è possibile e deve essere fatto esplicitamente — "non impostato" e "impostato su false" sono deliberatamente diversi, quindi l'impostazione predefinita rimane a meno che qualcuno non dica diversamente.

10 Consegna, messa in coda e ritentativo

Una destinazione che non può essere raggiunta è il caso normale, non l'eccezione. I sistemi si riavviano, le reti si interrompono e un motore di interfaccia ospedaliera è indisponibile durante la propria finestra di manutenzione. La consegna è costruita intorno a questo.

10.1 Coda per destinazione

Ogni destinazione ha la sua coda. Una destinazione che sta fallendo non influisce sulle altre e ognuna ha la sua profondità, età e stato di ritentativo.

La messa in coda è per destinazione piuttosto che per canale perché il fallimento è per destinazione. Una coda a livello di canale bloccerebbe la consegna a tre sistemi funzionanti perché un quarto è disattivato, e le due situazioni — una destinazione non disponibile, tutte e quattro non disponibili — sembrerebbero le stesse nelle statistiche.

10.2 Impostazioni coda

queue on a destination:

Gli ultimi due mancavano da questa tabella e dal costruttore, e sono la coppia che impedisce al disco di riempirsi. Una coda senza entrambi cresce fino a quando il file system non è pieno, e quel fallimento arriva come qualcosa di non correlato che si rompe — un write che fallisce da qualche altra parte — piuttosto che come un problema di coda.

Il backoff cresce tra i tentativi fino a max_backoff. Cresce piuttosto che fisso, perché una destinazione che è disattivata è solitamente disattivata per minuti piuttosto che secondi, e ritentare ogni secondo per dieci minuti produce diverse centinaia di voci di log che seppelliscono quella che conta.

10.3 L'ordinamento è preservato

All'interno di una destinazione, i messaggi sono consegnati nell'ordine di arrivo, e un messaggio che fallisce mantiene la sua posizione. I messaggi successivi aspettano dietro di esso piuttosto che superarlo.

Questo è il default giusto per i dati clinici — un'ammissione e una dimissione applicate nell'ordine sbagliato è peggio che entrambi essere in ritardo — e ha una conseguenza degna di essere compresa: un messaggio che fallisce sempre bloccherà tutto ciò che lo segue.

È per questo che la profondità della coda e l'età della coda sono condizioni di allarme separate. Una coda profonda che si sta svuotando è un sistema impegnato. Una coda il cui messaggio più vecchio continua a invecchiare è bloccata, e i tipi di allarme queue-depth, queue-age e queue-stuck li distinguono.

10.4 Quando la messa in coda è disabilitata

Con queue.enabled false, una consegna non riuscita è una consegna non riuscita. Viene registrata e non ritentata.

È la scelta giusta quando i dati in ritardo sono peggiori dei dati mancanti — un display in tempo reale, un sistema di paging, qualsiasi cosa in cui un messaggio consegnato quaranta minuti dopo l'evento sarebbe fuorviante piuttosto che semplicemente ritardato.

È la scelta sbagliata per qualsiasi cosa che vada in un record, dove il messaggio è altrettanto valido un'ora dopo.

10.5 Ritentativo versus coda

Ci sono due meccanismi e operano a livelli diversi.

retry su una destinazione governa i tentativi immediati all'interno di una consegna — una connessione che fallisce viene ritentata dopo una breve pausa, senza lasciare il percorso di consegna. Ciò gestisce i guasti transitori: una connessione interrotta, un rifiuto momentaneo.

queue governa cosa succede una volta che i tentativi immediati sono esauriti. Il messaggio lascia il percorso di consegna e viene ritentato più tardi su una programmazione più lunga.

Entrambi esistono perché i due fallimenti sono diversi. Un reset di connessione nel primo tentativo è solitamente scomparso nel secondo, e passare attraverso la coda per esso aggiungerebbe minuti di latenza a un guasto che è durato millisecondi. Una destinazione che è stata disattivata per la manutenzione non tornerà online entro tre tentativi immediati, e martellare è inutile.

10.6 Cosa un endpoint HTTP considera consegnato

Un endpoint HTTP ha tre impostazioni che decidono se un messaggio è trattato come inviato e tutte e tre sono sull'endpoint nel costruttore.

Codici di stato che significano consegnato. Vuoto significa qualsiasi 2xx. Alcuni endpoint rispondono 202 Accepted per qualcosa che non hanno ancora elaborato, e alcuni rispondono 200 con un errore nel corpo — il secondo è ciò per cui *Tratta come fallito se la risposta contiene* è previsto. Impostare un elenco esplicito vale la pena di farlo quando un partner ha detto quale codice significa cosa, perché l'alternativa è scoprire la differenza da un messaggio che non è stato consegnato e non è stato messo in coda.

Segui reindirizzamenti. Disattivato per impostazione predefinita e intenzionalmente. Un reindirizzamento può puntare a un host diverso, quindi seguirlo invia il messaggio da qualche parte che nessuno ha configurato e segnala il successo.

Token Bearer. Inviato come intestazione Authorization. Viene archiviato con il canale e non viene più visualizzato, quindi lasciare la casella vuota durante la modifica di un canale esistente mantiene il token già salvato anziché cancellarlo.

10.7 Denominazione e potatura di una cartella di archiviazione

Una destinazione del file aggiunge a un file per giorno e tipo di messaggio per impostazione predefinita (20261012-ADT_A01.hl7), inquadrato MLLP in modo che il file possa essere riprodotto con perfuse send. Quattro impostazioni sulla destinazione modificano questo.

Nome del file (file_name) crea un file per messaggio invece, nominato da ${date}, ${timestamp}, ${control_id}, ${message_type} e ${destination}. Un nome che è già stato preso (lo stesso ID di controllo due volte) ottiene un suffisso univoco invece di sovrascrivere il messaggio lì.

Aggiungi (append: true) scrive ogni messaggio nel file Nome file denominato, quindi ${date}.hl7 è un file al giorno per ogni tipo.

Suffix durante la scrittura (temp_suffix, un file per messaggio solo) predefinito su .part e rimosso da un rename una volta che il file è completo. Chiunque raccoglie questi file non dovrebbe raccogliere uno scritto a metà, e un rename all'interno di una cartella è atomico. Cambiarlo solo se il collector filtra un'estensione diversa.

Elimina dopo (retain_hours) pota i file nella cartella più vecchi del numero di ore dato, controllato al massimo ogni dieci minuti mentre arrivano messaggi. Solo i file semplici direttamente nella cartella vengono eliminati, mai una sottocartella. Vuoto o zero li mantiene per sempre, che è il valore predefinito ed è una decisione piuttosto che un errore — ma un archivio che nessuno pota riempie il disco e un disco pieno ferma il canale piuttosto che l'archiviazione.

10.8 Invio a un server FHIR

Tre impostazioni decidono quanto viene verificato prima che un bundle parta.

Dichiara la conformità US Core aggiunge il profilo a ogni risorsa. Dichiara solo quando la risorsa trasporta ciò che il profilo richiede, perché un ricevente può convalidare contro la dichiarazione e rifiutare un bundle che altrimenti sarebbe stato accettato.

Convalida prima dell'invio controlla ogni risorsa qui anziché apprendere dal ricevente. Un rifiuto all'estremità remota ti dice meno, più tardi e spesso solo in un registro che non puoi leggere.

Tratta gli avvertimenti come rifiuti ha effetto solo quando la convalida è attiva e il controllo non è disponibile fino ad allora. È abbastanza rigoroso da fermare un bundle che un ricevente accetterebbe, quindi appartiene a un feed che sta venendo avviato piuttosto che a uno in servizio.

10.8.1 Servizi FHIR ospitati

Un endpoint fhir con il blocco auth si connette ai servizi ospitati, dove un token bearer incollato smette di funzionare entro un'ora:

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 firma ogni richiesta per AWS HealthLake con Signature Version 4, con la regione letta dall'URL. azure ottiene un token Microsoft Entra ID per Azure Health Data Services da tenant_id, client_id e client_secret - una registrazione dell'app che detiene il ruolo di contributore dei dati FHIR - con l'URL del servizio FHIR come pubblico. client_credentials fa lo stesso contro qualsiasi URL del token OAuth 2.0 token_url. I token vengono riutilizzati fino a un minuto prima della loro scadenza. Le stesse opzioni sono disponibili sotto il Servizio di accesso ospitato della destinazione nel costruttore del canale.

10.8.2 Segnalazione dei casi di salute pubblica

Selezionare Segnalare le condizioni segnalabili alla sanità pubblica su una destinazione FHIR e invierà rapporti di casi invece di bundle. Ogni messaggio viene controllato per un codice di attivazione della condizione segnalabile: una diagnosi, un test di laboratorio o un risultato codificato. Se ne ha uno, il messaggio diventa un eICR HL7 eCR 2.1.2, avvolto in un messaggio eCR e inviato all'URL $process-message. Se non ne ha nessuno, nulla viene inviato e nulla fallisce; la destinazione lo conta come non segnalabile.

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 è il set di codici di attivazione delle condizioni segnalabili, come un ValueSet FHIR o il bundle eRSD. Richiede una licenza UMLS, quindi non è incluso; senza di essa, viene utilizzato un campione di esempio breve integrato, solo per test. source è dove l'agenzia invia la sua risposta alla segnalazione. La struttura sanitaria è obbligatoria perché eCR richiede il suo numero di telefono e l'indirizzo, e un messaggio v2 non li ha.

Un rapporto indica cosa mancava nel messaggio piuttosto che inventarlo, e ogni lacuna viene registrata. Provare un messaggio nel pannello Rapporto di casi di sanità pubblica del laboratorio FHIR prima di puntare un flusso live a un'agenzia.

10.8.3 Risultati di laboratorio alla salute pubblica: ELR

perfuse elr -config elr.yaml results.hl7 trasforma i risultati di un laboratorio nei messaggi ELR HL7 2.5.1 che i dipartimenti di sanità statale ricevono, uno per ogni messaggio con un risultato segnalabile, e solo gli ordini che ne trasportano uno: un esame del sangue completo accanto a un test SARS-CoV-2 positivo non è affare della sanità pubblica. I codici di attivazione sono gli stessi della segnalazione dei casi, il RCTC che si carica o il campione integrato.

ELR nomina tutti con OID o numero CLIA, che nessun feed di laboratorio trasporta per il mittente e il destinatario, quindi questi provengono dal file:

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}

La struttura che effettua l'ordine, il laboratorio che esegue e le autorità di assegnazione vengono utilizzate solo dove il messaggio del laboratorio le omette, e ogni utilizzo è una nota. Ciò che solo il laboratorio sa non viene mai compilato: un risultato senza tipo di campione va con SPM-4 vuoto e una nota che lo dice, perché un campione ipotizzato in un rapporto alla sanità pubblica è peggiore di una lacuna che lo stato può chiedere. Iniziare con processing: T mentre il team di onboarding dello stato testa il flusso.

Ciò che il laboratorio ha fatto correttamente viene mantenuto com'è stato inviato. Un ordine figlio (un pannello di sensibilità o un test di riflessione il cui OBR-29 nomina il genitore e che non ha un ORC proprio) va come ricevuto, senza ORC o campione inventato, e un figlio senza risultato segnalabile proprio va con quello del genitore, poiché una sensibilità non significa nulla senza la coltura a cui appartiene. Una nota dopo il PID rimane con il paziente, e ORC-14, il numero di telefono di richiamo, viene copiato da OBR-17 quando il laboratorio lo mette solo lì. Tutti i 28 messaggi di esempio che ONC pubblica per il suo strumento di certificazione ELR escono validi senza errori.

MSH-2 viene scritto come ^~\&#, i cinque caratteri richiesti dall'errata di ELR Release 1 e verificati dallo strumento di certificazione di ONC. Se la guida del tuo stato mostra i quattro caratteri più vecchi, aggiungere encoding_characters: "^~\\&" al file.

Per inviarli da un canale invece che dalla riga di comando, dare alla destinazione che raggiunge lo stato un blocco elr che nomina lo stesso file. Ogni risultato del laboratorio viene riorganizzato durante l'invio, e uno con nulla di segnalabile non viene inviato affatto, il che viene conteggiato come consegnato, non fallito: lo stato ha chiesto solo risultati segnalabili.

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

Il blocco si applica a un canale HL7 v2, alle destinazioni che consegnano il messaggio stesso (mllp, http, tcp, file, sftp, ftp, S3, Azure Blob, soap, i broker di messaggi o un altro canale); il canale rifiuta di caricare altrimenti, e quando il file è mancante o manca della struttura di invio, dell'applicazione ricevente o della struttura ricevente. Le note vengono scritte nel log con l'ID di controllo del messaggio.

Il file ELR è il compagno del canale, non un canale: perfuse check e lo schermo dei canali lo saltano invece di segnalare un canale che non verrà caricato. Nel costruttore di canali, le stesse due impostazioni sono sotto la destinazione, in Segnalazione del laboratorio (ELR 2.5.1); il campo dei codici di attivazione si apre una volta che viene nominato un file ELR, e il salvataggio rifiuta un file che non si trova accanto al canale.

10.8.4 Archivi DICOMweb

type: dicomweb archivia ogni oggetto con STOW-RS: Orthanc, dcm4chee, i servizi di imaging cloud o l'archivio di un server Perfuse. Fornire la radice del servizio (https://pacs.example/dicom-web); /studies viene aggiunto, e un URL che termina già con /studies viene rifiutato invece di essere inviato a /studies/studies. Autenticare con token (un token bearer) o username e password; headers aggiunge altri, come l'intestazione del progetto di un servizio cloud. Il canale necessita di dataType: dicom.

La risposta del server decide l'esito, non solo il suo codice di stato. Un oggetto che la risposta elenca come fallito è una consegna fallita con il motivo di fallimento DICOM, e lo è anche un 202 che non elenca nulla come archiviato: il server ha preso la richiesta e non ne ha mantenuto nessuna. Il timeout predefinito è di due minuti, perché una serie grande è lenta.

10.8.5 Repository di documenti (IHE XDS.b)

type: xds pubblica ogni documento clinico in un repository XDS.b con ITI-41 Provide and Register: un documento CDA o un messaggio HL7 v2 (MDM, ORU) che lo trasporta. I metadati provengono dal documento e dalle impostazioni del destinatario (source_id, patient_domain, facility_type, practice_setting), e la risposta del repository RegistryResponse decide la consegna. Vedi condivisione di documenti IHE.

10.8.6 Registry di immunizzazione

Ogni registro di immunizzazione statale (IIS) accetta messaggi HL7 2.5.1 sulla stessa interfaccia SOAP, quella pubblicata dal CDC nel 2011 (namespace urn:cdc:iisb:2011). Ha due operazioni: connectivityTest, che verifica l'endpoint, e submitSingleMessage, che trasporta il messaggio. Un VXU^V04 segnala un vaccino e torna come un ACK; un QBP^Q11 chiede la storia e la previsione di un paziente e torna come un RSP^K11.

Scegliere Registry di immunizzazione (servizio web CDC IIS) come servizio di un destinatario SOAP, o scrivere 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 costruisce la busta, quindi non c'è corpo da scrivere. Il nome utente e la password vanno all'interno della richiesta, dove il CDC WSDL li posiziona, non nell'autenticazione HTTP. La versione è SOAP 1.2, il binding del WSDL, a meno che non si imposti version: "1.1" per un registro che richiede una guida specifica. Dove un registro richiede un certificato client, impostare il tls del destinatario come per qualsiasi chiamata HTTPS.

L'acknowledgement del registro decide se il messaggio è stato consegnato, non lo stato HTTP. Un registro risponde a un rifiuto con HTTP 200 e un AR all'interno, quindi una destinazione che si fidava dello stato segnalerebbe un'immunizzazione persa come consegnata.

warnings_are_errors: true (Tratta i warning come fallimenti) fa attendere ogni AE a una persona. La risposta, che gli script di risposta e un chiamante HTTP in attesa sul canale leggono, è il messaggio HL7 del registro: l'ACK o la RSP con la storia e la previsione. examples/iis contiene tre canali da cui partire: VXU da un EHR su MLLP, query QBP su HTTP e un sostituto locale per un registro.

La dashboard Connessioni chiede a un registro il suo connectivityTest quando non è stato inviato nulla per sette giorni. Quell'operazione esiste a questo scopo e non invia nulla, quindi è il solo controllo a livello di applicazione che Perfuse esegue. Dimostra l'indirizzo, il TLS e il binding SOAP, non il nome utente e la password; solo una reale invio li testa.

Una sorgente SOAP può rispondere allo stesso modo: Rispondi come un registro di immunizzazione, o profile: cdc-iis sulla sorgente. Ripete connectivityTest, prende il messaggio da submitSingleMessage, restituisce l'acknowledgement del canale in return e serve il WSDL del CDC a ?wsdl. Un nome utente e una password, quando impostati, vengono verificati contro quelli nella richiesta, e una coppia errata ottiene la SecurityFault del WSDL. Un messaggio che il canale rifiuta torna indietro come un NAK, mai come una fault, come dice la guida del CDC. Usalo come doppio di test o per ricevere invii nel modo in cui li riceve un registro.

Non coperto: le parti specifiche dello stato del processo di onboarding. Ogni registro ha il proprio endpoint, processo di account e profilo locale della guida 2.5.1 (campi RXA e OBX richiesti, idoneità VFC, codici di rifiuto). Quelli sono il contenuto dei messaggi, che le trasformazioni del canale plasmano; nessun endpoint di stato è integrato. Perfuse è stato testato contro se stesso e contro risposte di registro registrate, non contro un registro di stato live.

10.9 Quando il trasporto dice sì e il messaggio non è arrivato

"È arrivato questo" è spesso una domanda che il trasporto non può rispondere. Un ricevitore MLLP restituisce un acknowledgement di applicazione il cui significato è nel testo. Un ricevitore HTTP restituisce 200 con un documento di errore. In entrambi i casi il trasporto è riuscito e il messaggio non è arrivato.

Ispeziona la risposta su una destinazione prende uno script dato dalla risposta del ricevitore. Restituisci false, o lancia un'eccezione, e la consegna viene contrassegnata come fallita — il che significa che si ritenta, si mette in coda e appare nel conteggio degli errori invece di essere conteggiato silenziosamente come consegnato.

Viene offerto solo sulle destinazioni che ricevono una risposta. Su una che non può, viene rifiutato al caricamento invece di essere lasciato in esecuzione.

10.10 Cosa significa l'esito di una consegna

Questi vengono registrati per destinazione per messaggio, quindi un messaggio che ha raggiunto tre delle quattro destinazioni viene registrato esattamente come tale. Non c'è un "successo" a livello di canale, perché non significherebbe nulla.

10.11 Consegna lenta

Una destinazione che sta accettando messaggi ma ci mette molto tempo è un problema distinto da uno che sta fallendo, ed è facile perderlo di vista perché ogni esito è un successo.

Esiste un tipo di allarme slow-delivery per questo. Vale la pena impostarlo su tutto ciò per cui l'acknowledgement del mittente attende la consegna, perché una destinazione il cui tempo di risposta è aumentato silenziosamente raddoppierà alla fine e inizierà a produrre ritardi — e a quel punto il sintomo appare a monte, in un sistema che potresti non amministrare.

10.12 Scrittura su un database

type: database esegue uno statement per messaggio con valori vincolati dal messaggio.

I segnaposto sono propri del driver — $1 per postgres, ? per mysql e sqlite, @p1 per sqlserver — e Perfuse non li riscrive. È deliberato: uno strato di traduzione che sbagliasse un segnaposto li leggerebbe come dati validi invece di un errore.

Uno statement scritto nel dialetto sbagliato viene rifiutato quando viene salvato, nominando lo stile che il driver vuole. Prima che esistesse questo controllo, l'errore emergeva come syntax error at or near "," dal server quando arrivava un messaggio, che nomina uno statement che hai scritto e quindi ti fa cercare un refuso invece di guardare al dialetto.

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

Un parametro tra virgolette è una costante piuttosto che un percorso, che è come un canale scrive il proprio nome o un codice di sistema sorgente in una riga accanto ai dati del messaggio.

I valori vengono sempre vincolati come parametri. Un riferimento ${...} all'interno dello statement viene rifiutato: un nome che contiene un apostrofo romperebbe lo statement, e un valore ostile lo riscriverebbe.

10.13 Invio a un socket grezzo

type: tcp scrive su un socket con framing scelto dall'utente, che è ciò che un dispositivo o uno strumento di laboratorio vuole solitamente. MLLP è uno dei framing disponibili; questa destinazione offre anche gli altri.

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

Il framing non ha un valore predefinito, intenzionalmente. Scrivere con il framing errato non fallisce. Il sistema di ricezione legge i messaggi divisi nei punti sbagliati o attende un terminatore che non arriva mai, e il sintomo appare nel sistema di ricezione piuttosto che qui.

Vengono accettate solo le impostazioni utilizzate dal framing scelto. Una lunghezza di record in un flusso delimitato viene rifiutata piuttosto che ignorata, perché un'impostazione ignorata silenziosamente è una impostazione che qualcuno ritiene essere in vigore.

expect_reply modifica ciò che significa recapitato. Senza di esso, il successo significa che i byte hanno raggiunto il buffer di invio del sistema operativo — che un peer crashato un attimo dopo non ha mai letto.

10.14 Amazon S3, SQS e SNS

Un canale può leggere da una coda SQS o da un prefisso di bucket S3 e consegnare a SQS, SNS o S3. Tutti e cinque utilizzano HTTP firmato senza SDK AWS nel binario e tutti e cinque accettano le stesse impostazioni di accesso: region, access_key_id, secret_access_key (scrivere ${AWS_SECRET_ACCESS_KEY} per leggere l'ambiente), un facoltativo session_token e endpoint per LocalStack, MinIO o un endpoint VPC. Sotto Canali → Nuovo canale, scegliere *Leggiamo da una coda Amazon SQS*, *Raccogliamo oggetti da un bucket Amazon S3* o i tipi di destinazione SQS, SNS e S3.

Nessun messaggio viene confermato ad AWS fino a quando il canale non lo ha gestito. Un messaggio SQS viene eliminato successivamente e altrimenti riappare quando il timeout di visibilità termina, quindi una politica di riavvio della coda è ciò che sposta un messaggio che continua a non riuscire in una coda di lettere morte. Un oggetto S3 si sposta in processed/ successivamente, o in error/ se non poteva essere gestito, quindi un singolo file non blocca gli altri.

In una coda o un argomento FIFO, i messaggi sono raggruppati per paziente per impostazione predefinita - SQS mantiene l'ordine all'interno di un gruppo e da nessun'altra parte - e deduplicati per contenuto, quindi un retry non viene consegnato due volte.

Un archivio S3 può essere scritto direttamente su Glacier con storage_class, e come JSON linee per Amazon Athena con format: ndjson; perfuse athena stampa la tabella. Il riferimento contiene ogni impostazione.

10.15 AMQP 1.0 e Azure

AMQP 1.0 è ciò che Azure Service Bus e Event Hubs parlano, e RabbitMQ 4, ActiveMQ e Artemis oltre ai loro altri protocolli. Un' origine amqp riceve da una coda o una sottoscrizione e accetta ogni messaggio solo una volta che il canale lo ha gestito; uno che non poteva essere gestito viene rilasciato come consegna non riuscita, quindi il broker lo ridistribuisce e, oltre il limite della coda, lo invia alla coda di lettere morte. Una destinazione amqp segnala il successo solo quando il broker accetta il messaggio. Per Service Bus: addr è <namespace>.servicebus.windows.net:5671 con tls, username il nome della politica di accesso condiviso, password la sua chiave, e address il nome della coda, o <topic>/subscriptions/<name> per ricevere.

Azure Blob Storage: una destinazione azure_blob scrive un blob per messaggio nel livello di accesso scelto - Hot, Cool, Cold o Archive - e un'origine azure_blob raccoglie i blob da un prefisso, spostandoli in processed/ o error/ come l'origine S3 fa. Preferire un token SAS generico limitato al contenitore piuttosto che la chiave dell'account.

10.16 MQTT

Un'origine mqtt si iscrive a un filtro di argomento (+ corrisponde a un livello, # a tutti i livelli inferiori) su qualsiasi broker MQTT 3.1.1: Mosquitto, EMQX, HiveMQ, AWS IoT Core, Azure Event Grid. Con QoS 1, il valore predefinito, ogni messaggio viene confermato solo una volta che il canale lo ha gestito. MQTT non ha modo di rifiutare un singolo messaggio, quindi uno che non poteva essere gestito rimane non confermato e la connessione viene stabilita nuovamente; il broker mantiene la sessione sotto l'ID client (perfuse-<channel> a meno che client_id non specifichi diversamente) e lo invia nuovamente, per primo in linea. QoS 0 è al massimo una volta: qualsiasi cosa inviata mentre Perfuse è disconnesso è persa. Una destinazione mqtt pubblica e, con QoS 1, segnala il successo quando il broker ha il messaggio.

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 vuole un certificato client: fornire tls.cert_file e tls.key_file.

10.17 IBM MQ

ibm_mq legge e scrive code IBM MQ attraverso l'API REST di messaggistica del gestore di code (mqweb), che IBM MQ 9.1.5 e successive forniscono su ogni piattaforma, incluso z/OS, quindi non è necessario installare un client MQ accanto a Perfuse. L'utente necessita del ruolo MQWebUser e dell'autorità di inserimento, recupero e navigazione sulla coda. Una sorgente esamina il primo messaggio, lo passa al canale e lo rimuove in base al suo ID messaggio solo una volta che è stato gestito; un messaggio che ha esito negativo rimane in cima alla coda. Eseguire un lettore per coda. Una destinazione inserisce messaggi persistenti (a meno che non_persistent non sia impostato), con l'ID di controllo HL7 come ID di correlazione.

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 è v3 per MQ 9.3 e successivi (il valore predefinito), v2 per 9.1.5 a 9.2. Un gestore di code con un canale AMQP può essere raggiunto anche con il connettore amqp.

10.18 Google Cloud Pub/Sub e Cloud Storage

Una sorgente pubsub recupera da un abbonamento e conferma ogni messaggio una volta gestito; uno che ha esito negativo viene restituito immediatamente (la sua scadenza di conferma è impostata su zero), con il resto del suo batch, quindi Pub/Sub lo consegna nuovamente e, oltre alla politica di dead-letter dell'abbonamento, lo invia alla coda di dead-letter. Una destinazione pubsub pubblica con il tipo di messaggio HL7 e l'ID di controllo come attributi; order_by: patient imposta la chiave di ordinamento da PID-3.1, quindi un abbonamento con ordinamento dei messaggi mantiene i messaggi di ogni paziente in ordine.

Una destinazione gcs scrive un oggetto per messaggio, denominato come una chiave S3, nella classe di archiviazione scelta (STANDARD, NEARLINE, COLDLINE, ARCHIVE). Una sorgente gcs recupera oggetti da un prefisso e li sposta in processed/ o error/ come fa la sorgente S3.

Entrambe si connettono come account di servizio: credentials_file è la sua chiave JSON. Lasciarla vuota su Google Cloud (una VM, GKE o Cloud Run) per utilizzare l'account di servizio collegato lì. endpoint nomina un emulatore (l'emulatore Pub/Sub, fake-gcs-server), che non richiede credenziali.

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

10.19 Lettura di una casella di posta (IMAP e POP3)

Una sorgente email legge una casella di posta elettronica e trasforma ciò che trova in messaggi: ogni allegato (take: attachments, il valore predefinito, limitato da modelli attachment_names), il testo dell'email (take: body) o l'intera email (take: raw) per un script che li smonti. Laboratori, centri di imaging e piccole strutture sanitarie inviano ancora i risultati in questo modo.

Ogni controllo si collega, legge la posta non letta più vecchia per prima, e si disconnette. Su IMAP, un'e-mail viene recuperata senza essere contrassegnata come letta, consegnata al canale, e solo una volta ogni messaggio da essa accettato viene spostata in move_to (Elaborata), contrassegnata come letta (after_read: flag) o eliminata. La posta che non è riuscita o che non è stata presa (un mittente al di fuori di allowed_senders, nessun allegato che corrisponda a attachment_names, più grande di max_message_size), si sposta nella cartella error_folder (Errore) con il motivo nel log. Entrambe le cartelle vengono create quando mancano. POP3 non ha cartelle o flag, quindi elimina: le eliminazioni vengono confermate dal QUIT alla fine del controllo, quindi una sessione che si interrompe non elimina nulla e un'e-mail gestita potrebbe essere letta di nuovo (mai persa). La posta POP3 che non è stata presa rimane sul server e viene segnalata una volta.

La connessione è una password (${MAIL_PASSWORD}; una password dell'app per Gmail) o OAuth 2.0 tramite SASL XOAUTH2, che Microsoft 365 richiede (ha disattivato la connessione con password) e Gmail preferisce:

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]

Con client_secret e senza refresh_token, viene utilizzato l'accesso app-only di Microsoft 365 (la concessione di credenziali client, ambito https://outlook.office365.com/.default): un amministratore registra l'app, gli concede l'accesso IMAP.AccessAsApp e lo limita a una sola casella di posta con un principale di servizio Exchange. Con un refresh_token (un consenso di una persona), viene utilizzato l'ambito delegato IMAP.AccessAsUser.All o POP.AccessAsUser.All, e un token di aggiornamento ruotato viene mantenuto per la durata del processo. Gmail richiede un refresh_token: Google non offre l'accesso app-only a una casella di posta.

allowed_senders accetta indirizzi e domini. La riga From di un'email può essere contraffatta, quindi tiene fuori gli incidenti e la posta vagante, non un attaccante; un feed che deve essere considerato attendibile appartiene a Direct (S/MIME firmato), SFTP o una VPN. security è tls (993 o 995, il valore predefinito), starttls (143 o 110) o none, che è consentito solo a localhost. I controlli sono separati da almeno 10 secondi (60 per impostazione predefinita), perché i servizi di posta elettronica limitano gli account che controllano più velocemente.

Testato contro GreenMail 2.1.3 (IMAPS, IMAP, POP3S e POP3: rifiuto di accesso con password errata, recupero senza contrassegnare come letto, SPOSTA, flag, eliminazione, un'email troppo grande rifiutata prima di essere letta) e contro l'IMAP di Gmail con una password dell'app (creazione di una cartella, aggiunta, recupero, SPOSTA, eliminazione). OAuth è stato testato contro un endpoint di token di sostituzione solo: non contro Microsoft o Google.

10.20 AS2

AS2 (RFC 4130) è il modo in cui molti pagatori, centri di smistamento e fornitori scambiano EDI: un POST HTTP il cui corpo è firmato con il certificato del mittente e crittografato per il ricevente, risposto con una ricevuta (un MDN) che nomina un digest di ciò che è arrivato. Il S/MIME è lo stesso codice utilizzato dalla messaggistica Direct. Entrambe le estremità sono sul costruttore di canali: I partner commerciali ci inviano EDI su AS2 come sorgente, Un partner commerciale su AS2 come destinazione.

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

Ricezione. Un messaggio a qualsiasi altro AS2-To, o da un mittente non in partners, viene rifiutato con 403 e senza ricevuta. Il messaggio di un partner deve essere firmato e crittografato a meno che la sua voce non imposti allow_unsigned o allow_unencrypted. Il payload viene decrittografato, la sua firma verificata contro il certificato del partner (i partner di solito scambiano certificati autofirmati, che va bene: il certificato è la fiducia), e consegnato al canale come dice il formato del messaggio. Il partner riceve la ricevuta che ha richiesto: nella risposta, o inviata all'URL della sua Receipt-Delivery-Option; firmata quando ha richiesto una firmata. Un messaggio che non riesce ottiene una ricevuta che nomina il motivo (decryption-failed, authentication-failed, insufficient-message-security, unexpected-processing-error).

Invio. Ogni messaggio è firmato (SHA-256) e crittografato (AES-256-CBC). Con receipt: sync, il valore predefinito, viene considerato consegnato solo quando la ricevuta verifica contro partner_cert_file, dice processed e contiene lo stesso digest (MIC) di quello inviato; qualsiasi altra cosa è una consegna fallita e viene ritentata. receipt: async richiede la ricevuta a receipt_url, che deve essere una sorgente AS2 su questo server che elenchi il partner: il messaggio viene considerato consegnato una volta che il partner accetta la richiesta e una ricevuta che in seguito non è d'accordo viene registrata come errore. receipt: none non richiede nulla. unsigned, unencrypted e unsigned_receipt rilassano ogni parte per un accordo che lo dice; username e password aggiungono l'autenticazione di base HTTP per le porte che lo richiedono. Il tipo di contenuto segue il formato del canale (application/edi-x12 per X12) a meno che content_type non ne imposti uno.

Triple DES, AES-128 e AES-192 vengono letti così come AES-256, poiché i partner li inviano ancora, e anche il flusso BER (lunghezze indefinite) che le porte Java scrivono.

Compressione (RFC 5402). Un messaggio compresso viene letto in qualsiasi modo sia stato costruito: compresso prima della firma o della crittografia, o un messaggio firmato compresso interamente. Il MIC del ricevuto segue la RFC: su ciò che è stato firmato quando è firmato, sul contenuto non compresso quando non è firmato. Un messaggio che si espanderebbe oltre dieci volte la dimensione massima del messaggio della sorgente (max_message_size) viene rifiutato con decompression-failed, in modo che pochi kilobyte non possano richiedere gigabyte di memoria. Una destinazione comprime con compress: true, prima della firma e della crittografia, come fanno la maggior parte delle porte di accesso; chiedere al partner per prima.

Un messaggio inviato due volte. Un partner che non ha mai ricevuto la nostra ricevuta invia nuovamente il messaggio con lo stesso Message-ID (RFC 4130 sezione 7.5). La sorgente ricorda ogni Message-ID del partner per duplicate_window (predefinito 720h, 30 giorni; almeno un'ora) e risponde a una rinviata con una ricevuta processed senza passarla di nuovo. Il record viene mantenuto nel database, quindi un riavvio non lo dimentica. Un messaggio il cui elaborazione è fallita non viene ricordato, quindi il retry del partner passa. Le copie che arrivano allo stesso momento si attendono a vicenda e solo la prima viene passata. Se il record non può essere letto, il messaggio viene rifiutato con unexpected-processing-error e il partner ritenta più tardi, piuttosto che rischiare una copia seconda. Un messaggio senza Message-ID non può essere riconosciuto e viene registrato come tale.

L'interoperabilità è testata contro pyas2lib 1.4.3 in entrambe le direzioni, con Triple DES e AES-256, compressi e non, ricevute firmate sincrone incluse.

10.21 OpenPGP

I pagatori, le casse di compensazione e le agenzie statali spesso accettano e inviano file solo sotto OpenPGP. Un blocco pgp su una sorgente apre ciò che arriva; uno su una destinazione protegge ciò che esce. Entrambi sono sul costruttore di canali: Messaggi crittografati con Open PGP sotto la sorgente, Crittografare con OpenPGP su ogni destinazione.

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}

I file delle chiavi vengono letti relativamente al file del canale e vengono letti e sbloccati quando il canale viene caricato: una chiave mancante o una passphrase errata ferma il canale lì, non sul primo file.

• Su una sorgente, l'intero file, oggetto, allegato di posta elettronica o corpo della richiesta viene

aperto per primo e quindi diviso in messaggi, quindi un batch crittografato come un file funziona. Uno che non può essere aperto viene rifiutato: una sorgente file lo sposta nella sua cartella degli errori, un inviante HTTP risponde 400 con il motivo. require_signature rifiuta un messaggio non firmato da uno di verify_with; allow_unencrypted accetta uno che è solo firmato; pass_plain lascia passare un messaggio che non è PGP affatto invariato, per una cartella che riceve entrambi.

• Su una destinazione, ciò che sarebbe stato consegnato viene crittografato (con uno di

encrypt_to) e firmato (con sign_with), dopo ogni altro passaggio. Una destinazione file, SFTP, FTP, S3, Azure Blob o GCS nomina ancora il file dal messaggio piano, quindi ${control_id} funziona, e qualsiasi cornice è all'interno della crittografia. armor: true scrive .asc testo invece di binario; no_compress disattiva la compressione; file_name è il nome trasportato all'interno del messaggio.

I messaggi vengono scritti con AES-256 nel formato RFC 4880 che i ricevitori più vecchi leggono, e il formato RFC 9580 più recente viene letto anche. La crittografia è ProtonMail/go-crypto; Perfuse non implementa alcun primitivo. L'interoperabilità è testata contro GnuPG in entrambe le direzioni: gpg decripta e verifica ciò che Perfuse scrive, e Perfuse apre e verifica ciò che gpg scrive.

10.22 Consegna a un altro canale

Una destinazione del canale consegna il messaggio a un altro canale per nome. Il canale ricevente lo tratta come qualsiasi altra arrivata: lo registra, lo filtra, lo trasforma e lo diffonde.

Questo è il modo supportato per costruire una catena. È deliberatamente visibile — due canali, due set di statistiche, due voci nella cronologia del messaggio — perché una catena nascosta all'interno di un canale è una catena che nessuno può monitorare.

Il messaggio viene consegnato in memoria piuttosto che su una rete, quindi non c'è cornice, non c'è ack e non c'è timeout tra i due.

10.23 Cosa succede quando il processo viene ucciso

La domanda che chiunque abbia eseguito un motore di interfaccia chiede per primo, e quella che raramente viene risposta, perché la risposta onesta è di solito imbarazzante.

È stata risposta uccidendo il processo con SIGKILL a metà di un batch — che è ciò che un guasto di alimentazione, un kill out-of-memory e un reset dell'ipervisore sembrano all'interno — e contando ciò che è sopravvissuto contro ciò che era stato promesso.

La proprietà in prova non è "nulla va perso". Ciò non è realizzabile e affermarlo sarebbe una bugia. È la promessa più stretta su cui un mittente fa effettivamente affidamento: un messaggio che è stato positivamente confermato è un messaggio che è arrivato.

Con ack.when: on_delivery, che è il valore predefinito, ogni destinazione viene scritta prima che venga inviata la conferma, quindi un AA è una dichiarazione sulla destinazione piuttosto che sulla coda. Un messaggio eliminato prima della sua conferma potrebbe essere perso e ciò è corretto: il mittente non ha mai ricevuto alcuna promessa e lo invierà di nuovo.

10.23.1 Conferma alla consegna

Cinque esecuzioni, eliminate dopo 5, 25, 40, 75 e 110 messaggi su 120.

La promessa è mantenuta in ogni punto di eliminazione e nulla è stato duplicato. Una duplicazione sarebbe stata accettabile e una perdita no: un A08 rinviato è un fastidio che i ricevitori assorbono e un risultato di laboratorio che non arriva silenziosamente è un evento di sicurezza per il paziente.

10.23.2 Conferma alla ricezione

on_receipt risponde non appena il messaggio viene messo in coda, prima che qualsiasi destinazione sia stata scritta. Questo capitolo ha sempre detto che un messaggio confermato può ancora essere perso in questo modo. Ecco la dimensione di esso.

Praticamente tutto ciò che è in volo. L'impostazione non è un difetto e ci sono feed in cui è la scelta giusta, ma dovrebbe essere scelta sapendo che un crash scarta ciò che è stato confermato e non ancora scritto, e che ciò è quasi tutto di un burst.

Nessun recupero al riavvio, perché perfuse run non ha un archivio duraturo. Una destinazione che non deve perdere messaggi durante un'interruzione richiede queue.enabled, che richiede il database che perfuse serve fornisce — e perfuse run ora rifiuta un tale canale invece di avviarlo senza la coda.

10.23.3 Un mittente che muore a metà di un messaggio

Il più pericoloso di questi difetti, perché un messaggio HL7 troncato di solito è comunque parsabile. I segmenti prima del taglio sono completi e ben formati, quindi un ricevitore non ha modo di sapere che PID e PV1 sono arrivati e i segmenti OBX che trasportano i risultati non sono arrivati.

Un frame è stato aperto, sei decimi di un messaggio inviati e la connessione resettata invece di chiusa. Il messaggio parziale non è stato consegnato, l'ascoltatore è sopravvissuto e un messaggio ben formato inviato subito dopo è stato accettato normalmente, quindi il frammento non è stato portato nel messaggio successivo.

Il registro di connessione segnala ora quanti byte di un frame non completato sono stati abbandonati, per ogni modalità di errore e non solo per una chiusura pulita. In precedenza, un mittente crashato, un processo interrotto e un cavo estratto segnalavano tutti messages=0 e nulla altro, il che non consente di distinguere un controllo di salute vuoto da un risultato di laboratorio scartato nove decimi del percorso.

10.23.4 Un disco pieno

L'esaurimento dello spazio viene rilevato e registrato invece di essere inghiottito. Due cose su di esso valgono la pena di essere conosciute.

Il mittente non riceve un rifiuto immediato. La consegna ritenta secondo il solito programma — un secondo, due, quattro, otto — e la conferma negativa arriva circa quindici secondi dopo. Un mittente il cui timeout è più breve di quello vede una connessione bloccata invece di un AE e concluderà che la rete è in errore invece del disco.

E un volume che segnala zero byte liberi può ancora accettare piccoli aggiornamenti per un po' di tempo, because l'aggiunta di un paio di centinaia di byte a un file il cui ultimo blocco ha spazio non richiede una nuova allocation. Il primo errore di scrittura si verifica più tardi del momento in cui il disco si è riempito.

10.23.5 Ciò che non è stato testato

Una directory di destinazione che perde l'autorizzazione di scrittura. Non poteva essere iniettato con chmod: il motore tiene aperto il file di output e il cambio della modalità di un file non influenza un descrittore già aperto su di esso. Testarlo correttamente richiede il volume rimontato in sola lettura o rimosso sotto il processo, il che non è stato fatto. È nominato qui invece di essere omesso, perché una lacuna che nessuno menziona legge come una lacuna che nessuno ha cercato.

11 Allarme

Niente al di fuori di Perfuse ti dirà che un flusso si è interrotto. Il mittente sta ricevendo conferme e ne è soddisfatto; il ricevitore non ha modo di sapere che un messaggio è stato inviato. L'allarme è l'unica cosa che si trova tra un'interfaccia rotta e qualcuno che se ne accorge settimane dopo.

11.1 I tipi di allarme

Gli ultimi quattro controllano l'accesso ai dati dei pazienti e vengono descritti di seguito.

11.2 Il silenzio è la cosa più difficile da rilevare

Un canale che ha smesso di ricevere non produce errori. Non c'è nulla da contare. È per questo che esiste no-traffic e perché non è sufficiente da solo.

no-traffic è una soglia fissa: allerta se nulla è arrivato per, ad esempio, due ore. Su un feed che non si ferma mai, funziona. Su un feed di laboratorio di una clinica è inutile — il feed è silenzioso ogni notte e durante tutto il fine settimana, quindi una soglia di due ore allerta qualcuno alle 1 del mattino ogni notte, e una soglia abbastanza lunga da superare il fine settimana non noterà un guasto del martedì mattina fino al pomeriggio del martedì.

Non esiste un numero singolo che sia entrambi. Non è un problema di regolazione; è che la domanda "questo feed si è fermato" non può essere risposta da una costante quando il feed normale varia di un fattore di cento durante la settimana.

11.3 Rilevamento consapevole del ritmo

below-rhythm confronta il traffico attuale con ciò che questo canale fa normalmente in quest'ora di questo giorno della settimana.

Perfuse apprende la settimana di ogni canale dalla sua storia registrata: 168 bucket orari, lunedì per primo in modo che la settimana lavorativa sia contigua. Per ogni bucket, tiene un valore mediano, un valore basso e un valore alto, un minimo e quante osservazioni è basato su.

La soglia è una quota del normale, che di default è 0.8 (80 per cento nella console) — allerta quando il traffico scende al di sotto di quattro quinti di ciò che è normale per quest'ora.

11.3.1 Mediana, non media

Un singolo scarico di backlog di quarantamila messaggi contro un normale di trecento sposta la media abbastanza lontano da far sì che il feed possa andare completamente silenzioso senza mai scendere al di sotto di essa. La mediana non è influenzata da un'ora straordinaria, che è esattamente la proprietà necessaria.

11.3.2 Il minimo è un percentile, non il minimo

Se il ritmo di un canale è abbastanza affidabile da allertare è deciso dal suo estremo inferiore, non dal suo estremo superiore. Un allarme di carenza si attiva quando il traffico è *basso*, quindi solo l'estremo inferiore può dirti se produrrà falsi positivi. Una versione precedente di questo confrontava l'alto con la mediana e si sbagliava in entrambe le direzioni contemporaneamente: disqualificava un feed perfettamente stabile per un mese dopo un backlog e passava un feed genuinamente erratico che oscillava tra due e novecento messaggi nella stessa ora perché il suo alto era solo tre volte la sua mediana.

Il minimo è il ventesimo percentile piuttosto che il minimo, perché il minimo è trascinato a zero da una sola festa nazionale. E il percentile non è interpolato — ogni numero in un allarme alle 2 del mattino dovrebbe essere un conteggio che il feed ha effettivamente prodotto, non una media di due conteggi che non ha prodotto.

11.3.3 Dirà quando non può dire

Un canale senza storia alcuna è omesso completamente piuttosto che trattato come uno che si è fermato. Un nuovo canale non deve sembrare rotto.

Dove la storia è troppo sottile o troppo erratico per supportare un giudizio, la regola rifiuta di attivarsi piuttosto che indovinare. "Non posso onestamente dire" è una risposta di prima classe qui, e viene preferita a un allarme che è giusto leggermente più spesso del caso.

11.4 Impostazione degli allarmi

Dall'interfaccia, sotto Avvisi, per canale o per tutti. Ogni regola ha un tipo, una soglia e dove inviare l'avviso. Le regole vengono salvate in alerts.yaml accanto al database (o il file -alerts nomina) e hanno effetto immediato; fino al primo salvataggio le regole predefinite si applicano. Il file può anche essere modificato manualmente: il cambiamento viene raccolto entro trenta secondi e un file che non carica più viene segnalato nel log e le regole in vigore vengono mantenute.

Vale la pena farlo prima che un feed vada live piuttosto che dopo il primo incidente. L'insieme specifico di allarmi che vale la pena avere su qualsiasi feed clinico:

1. below-rhythm — il feed si è fermato quando non dovrebbe essere silenzioso.
2. error-rate — i messaggi stanno arrivando e fallendo.
3. queue-age — qualcosa è bloccato piuttosto che semplicemente occupato.
4. channel-down — il canale non sta funzionando affatto.

Il primo è quello che cattura il guasto che nessun altro segnalerà.

11.5 Controllare l'accesso ai dati dei pazienti

Una violazione raramente si annuncia. Sembra un flusso che trasporta più del solito, traffico alle tre del mattino su un canale che funziona solo durante le ore di ufficio, una destinazione che nessuno ha impostato o una persona che apre un paziente dopo l'altro. Perfuse controlla questi quattro aspetti, abilitati per default (serve -watch-access=false li disabilita), e segnala ciò che vede attraverso le regole di allarme sopra, in modo che sia configurato, confermato e consegnato come qualsiasi altro allarme.

• Picchi (phi-volume). La velocità di ogni canale viene confrontata con la sua storia alle stesse ore del giorno, quindi una mattina impegnata non è una notizia. La soglia è un multiplo della velocità normale, tre per default. Un picco è solitamente un ritardo rilasciato dopo un'interruzione e assomiglia anche a come vengono estratti i record attraverso un flusso.
• Traffico notturno su un canale diurno (phi-after-hours). Un canale viene considerato diurno quando meno del 2 per cento di ciò che ha trasportato è caduto al di fuori delle ore 07:00-19:00, nel fuso orario del server.
• Una nuova destinazione (phi-new-destination). L'indirizzo è ciò che la destinazione nomina: un host e una porta, un URL, una cartella. Rinominare una destinazione non è una notizia; puntarla verso un nuovo host è. Gli indirizzi a cui ogni canale ha inviato sono conservati in access-watch.json accanto al database, quindi una destinazione modificata mentre il server era spento viene comunque segnalata.
• Lettura in blocco (phi-bulk-reads). Conteggiate dal registro di controllo: messaggi aperti, pazienti cercati o cercati (PDQm, PIXm, ricerca di identità), documenti e immagini letti (XDS, MHD, DICOMweb), autorizzazioni precedenti lette, riassunti e viste eseguite. La lettura dello stesso record più volte non viene conteggiata due volte. La soglia è il numero di record diversi in un minuto, dieci per default, per un account da un indirizzo.

Nessun canale viene giudicato fino a quando non ha trasportato 200 messaggi, perché "insolito" non significa nulla senza un modello. Il modello viene appreso dall'ultimo fortnight del negozio di messaggi quando il server si avvia, quindi un riavvio non fa sì che ogni canale diventi nuovamente nuovo. Tutto ciò che viene visto viene conservato per quindici minuti, poi l'allarme si cancella da solo.

Esso controlla e segnala solo. Non trattiene mai un messaggio o rifiuta una lettura: queste sono euristiche e un flusso fermato a causa di un'ipotesi errata è un problema clinico. Ogni allarme dice ciò che è stato visto e cosa potrebbe essere innocente, perché la maggior parte di essi sarà innocente.

Gli amministratori vedono ciò che il monitor ha appreso sullo schermo degli allarmi, sotto Controllo dell'accesso ai dati dei pazienti: il modello di ogni canale (ancora in fase di apprendimento, solo diurno o sia diurno che notturno), quanti destinatari conosce e tutto ciò che è stato visto negli ultimi quindici minuti, compreso ciò che è al di sotto della soglia di una regola.

11.6 Dove vanno gli allarmi

Gli avvisi possono essere inviati come JSON a un webhook (-alert-webhook: Slack, Teams, Mattermost, PagerDuty, Alertmanager o qualsiasi cosa che accetti un POST), inviati come trappole SNMPv2 a gestori SNMP (-snmp-traps, vedere SNMP), o scritti nel registro per un collector. Non c'è una consegna di posta elettronica di per sé: puntare il webhook a un relay se gli avvisi devono arrivare come posta elettronica.

Un allarme che è scritto solo nel log che nessuno legge non è un allarme. Se Perfuse è l'unica cosa che noterà un feed fermato, l'allarme deve raggiungere una persona.

12 L'archiviazione dei messaggi

Ogni messaggio che Perfuse riceve viene registrato, così come ricevuto, prima che venga modificato. Viene registrato anche ciò che è stato inviato a ogni destinazione e cosa gli è successo. L'archivio è un file SQLite specificato da -db.

12.1 Cosa viene conservato

Per messaggio: i byte grezzi così come sono arrivati, quando sono arrivati, quale canale, il tipo di messaggio parsato e l'evento di trigger, e l'esito del filtro.

Per destinazione per messaggio: i byte inviati, l'esito, il tempo impiegato e eventuali errori o risposte negative ricevute.

Questa è la forma che un'indagine richiede. "Cosa ci hanno inviato", "cosa abbiamo inviato loro" e "cosa hanno detto al riguardo" sono tre domande diverse e ognuna di esse viene posta.

12.2 Ricerca

Per canale, per intervallo di tempo, per esito, per tipo di messaggio e evento di trigger, e per valore di campo.

La ricerca per campo funziona sul messaggio parsato, quindi la ricerca di un numero di record lo trova ovunque nel messaggio che vive quel campo, piuttosto che corrispondere ai numeri in qualsiasi punto del testo. Una ricerca di testo per 12345 in un messaggio che contiene una quantità di 12345 trova un messaggio che non ha nulla a che fare con il paziente che si sta cercando.

12.3 Riproduzione e riprocessamento

Poiché l'originale viene conservato, un messaggio può essere eseguito nuovamente con la configurazione attuale.

Traccia prende un messaggio registrato e mostra cosa farebbe il canale con esso ora, senza inviare nulla. Coperto in debugging.

Riprocessa esegue effettivamente nuovamente il messaggio, compresa la consegna. Questo è ciò che risolve un batch di messaggi che non sono riusciti a causa di una destinazione configurata in modo errato: correggere la configurazione, selezionare i messaggi interessati, riprocessare.

12.4 Stagnazione

Una traccia di un messaggio vecchio contro la configurazione attuale risponde a un'ipotesi: cosa *sarebbe* successo ora. Quello è solitamente ciò che si vuole, ma non sempre — se si sta indagando su cosa è andato storto l'ultima volta, il canale potrebbe essere cambiato da allora.

Perfuse rileva questo e lo segnala. Una traccia di un messaggio che è arrivato prima dell'ultima modifica del canale è contrassegnata come tale, in modo che la risposta non venga scambiata per una ricostruzione di ciò che è effettivamente successo.

12.5 Ritenzione

L'archivio cresce. cleanup.periodDays controlla per quanto tempo vengono conservati i messaggi.

Due cose da considerare. I messaggi clinici possono essere soggetti a requisiti di ritenzione più lunghi di quelli che si sceglierebbero per motivi operativi, e l'archivio non è il sistema di registrazione — il sistema di ricezione lo è. La copia di Perfuse esiste per diagnosticare e riprocessare, e entrambe queste esigenze diminuiscono drasticamente dopo alcune settimane.

La ritenzione decide anche quanto storia il ritmo dell'apprendimento abbia a disposizione. Vedi alerting: una finestra di ritenzione più breve di alcune settimane lascia che non sia in grado di distinguere una domenica tranquilla da un flusso interrotto.

12.6 L'archivio contiene dati clinici

Questa è la parte di Perfuse che contiene informazioni sui pazienti e dovrebbe essere trattata come tale: su archiviazione crittografata, backup come dati clinici e accesso controllato. Vedi security.

I messaggi di test generati descritti in testing esistono in parte in modo che questi dati non debbano lasciare l'ambiente per riprodurre un problema altrove.

13 Debugging

La domanda è quasi sempre la stessa: questo messaggio è arrivato, qualcosa è andato storto, dove è cambiato? Perfuse risponde riproducendo un messaggio registrato attraverso la configurazione attuale e mostrando ogni passaggio.

Nessun messaggio viene inviato durante la tracciatura. Il canale continua a funzionare senza modifiche e non è necessario ridistribuire.

13.1 Tracciare un messaggio

Selezionare qualsiasi messaggio registrato e tracciarlo. Il risultato mostra, in ordine:

• Cosa legge il filtro. Quali campi ha esaminato e quali valori ha trovato. Un filtro che rifiuta tutto di solito legge un percorso che non esiste in questo flusso di dati e questo lo indica.
• Ogni trasformazione. Cosa ha modificato, da cosa a cosa.
• Cosa decide ogni destinazione. Se accetterebbe il messaggio e perché no se non lo accetterebbe.
• L'output. Il messaggio come ogni destinazione lo invierebbe.

13.2 Passo dopo passo

La visualizzazione passo-passo esegue ogni trasformazione singolarmente e cattura l'intero messaggio dopo di essa. Una guida numerata dei passaggi, colorata in base a cosa è successo, e il messaggio come si presentava in ogni punto.

L'intero messaggio piuttosto che solo il cambiamento, perché il cambiamento spesso non è dove si trova il problema — un passaggio che ha modificato correttamente il campo a cui era destinato, in un messaggio in cui un passaggio precedente aveva già inserito la cosa sbagliata, sembra perfettamente corretto in isolamento.

13.3 Quattro esiti e la distinzione che conta

no-effect e skipped vengono segnalati separatamente, ed è questo il punto di tutta la funzionalità.

Dall'esterno sono identici: il messaggio è lo stesso dopo di che in entrambi i casi. Significano cose opposte. skipped significa che la condizione funziona come scritta e questo messaggio non è uno a cui si applica — di solito corretto. no-effect significa che il passaggio è stato eseguito e non ha trovato nulla da fare, il che di solito significa che è destinato a un campo che non c'è.

Un motore che segnala entrambi come "non è successo nulla" ti lascia incapace di distinguere una condizione funzionante da un percorso rotto, e questo è il bug di trasformazione più comune che esista.

13.4 Testare una modifica prima di salvarla

Il costruttore può eseguire una configurazione candidata contro il traffico registrato e segnalare cosa sarebbe diverso. Questo è il modo più sicuro per modificare un canale live: apportare la modifica, vedere cosa fa ai primi pochi messaggi reali, quindi salvare.

È anche il modo per scoprire che una modifica che sembra ovviamente corretta influisce su messaggi che non avevi pensato — un passaggio condizionato su un evento di trigger, su un flusso di dati che si scopre trasportare quattro.

13.5 Cosa la tracciatura non può dirti

Esegue la configurazione attuale. Se il canale è stato modificato dal momento in cui il messaggio è arrivato, la traccia è ipotetica piuttosto che una ricostruzione, e Perfuse la segnala come tale piuttosto che lasciare che la distinzione passi inosservata.

Non esercita anche il trasporto. Una traccia mostra cosa verrebbe inviato, non se la destinazione lo accetterebbe — un messaggio corretto e una destinazione che rifiuta le connessioni producono una traccia pulita e una consegna fallita. Quelli sono visibili nel record di consegna invece.

13.6 Script

Uno script è un passaggio opaco nella traccia. Perfuse può mostrare cosa è entrato e cosa ne è uscito, e non può mostrare cosa è successo nel mezzo o quali campi sono stati letti.

Questo è il costo concreto dell'utilizzo di uno script invece di passaggi dichiarativi, e vale la pena di valutarlo quando si sceglie. Vedere transformation.

14 Test

Il consiglio standard per testare un'interfaccia è costruire messaggi di esempio che riflettono il proprio ambiente — i codici del proprio laboratorio, la miscela di casi, le abitudini del mittente — e rimuovere i dati dei pazienti manualmente. Questo è lento, e farlo in modo incompleto è il risultato normale.

Perfuse offre tre cose al posto di questo: traffico generato che corrisponde alla forma di un flusso di dati senza il suo contenuto, un canale proposto da un esempio che qualcuno ti ha inviato, e un confronto con il motore che stai sostituendo.

14.1 Traffico di test generato

Se un canale ha gestito messaggi, Perfuse può produrre più messaggi simili

Cosa è fedele:

• Attiva eventi di trigger nelle proporzioni effettivamente osservate, con almeno uno di ciascuno in modo che un evento raro appaia ancora.
• Campi popolati alle velocità in cui sono effettivamente popolati — quindi il caso in cui un campo è *assente* viene testato, che è il caso che rompe le cose.
• Ripetizioni dove si verificano ripetizioni, struttura composita dove si verifica.
• Codici tratti dalle tabelle di codici effettivamente visualizzate.

Cosa non è fedele, e questo è affermato piuttosto che implicito: coerenza clinica. Un paziente generato ha un numero di record non correlato, una stringa a forma di nome e una diagnosi senza alcuna relazione con l'osservazione. Questi messaggi esercitano un'interfaccia. Non sono un set di test clinici e non possono essere utilizzati per convalidare la logica clinica.

14.1.1 Perché non contiene dati reali

L'argomento è strutturale piuttosto che una pretesa di sforzo. L'unico input del generatore è il profilo del canale, e un profilo contiene tassi di riempimento, forme, lunghezze, conteggi di ripetizione e frequenze di segmenti. Non contiene valori.

L'unica eccezione sono i campi delle tabelle di codici, e un codice non identifica nessuno.

Questa è una garanzia più forte rispetto all'anonimizzazione dei messaggi reali, che è un processo che può essere eseguito in modo incompleto e di solito lo è. Qui non c'è alcun percorso attraverso il quale un nome potrebbe raggiungere l'output, perché il nome non era mai nell'input.

Ogni messaggio generato viene analizzato prima di essere restituito — un corpus non analizzabile manderebbe qualcuno a caccia di un bug nella propria interfaccia che in realtà è un bug del generatore — e ogni uno è contrassegnato con T in MSH-11, con un'applicazione e una struttura di invio sintetiche deliberate.

14.2 Creazione di un canale da un campione

Incolla il messaggio che un laboratorio, un ospedale o un fornitore ti ha inviato per posta elettronica e Perfuse propone un canale per esso. Nulla deve essere in esecuzione prima.

Gestisce ciò che le persone effettivamente incollano: più messaggi in un blocco, qualsiasi terminazione di riga, framing MLLP che ha superato la copia e la nota di copertura sopra il messaggio. Rifiutare un campione perché è arrivato con terminazioni di riga Windows sarebbe un ostacolo piuttosto che un controllo.

14.2.1 Tre elenchi

La proposta viene con ciò che il campione mostra, ciò che è stato indovinato, e ciò che il campione non può dirti — tre elenchi separati, ponderati equamente nell'interfaccia.

Sono separati perché un lettore che non può dire quale è quale deve verificare tutto o fidarsi di tutto, e entrambi sono peggio che sapere dove cercare.

Da un singolo messaggio i limiti sono nominati specificamente piuttosto che in generale: quali campi sono opzionali, quali segmenti si ripetono, quali codici esistono oltre a quelli qui, se il mittente invia mai un evento di trigger diverso. Un avvertimento generale è qualcosa che le persone scorrono.

La fiducia è una parola — bassa, moderata, ragionevole — mai una percentuale. Una percentuale implica un calcolo, e questo è un giudizio su quanti campioni ci sono.

I segmenti Z vengono chiamati per nome, perché un segmento locale è la cosa che nessuna specifica menziona e la ragione più comune per cui un canale costruito da un modello standard non funziona.

14.2.2 L'avvertimento del separatore

Se il separatore di campo del campione non è il solito |, questo appare primo, e la fiducia scende a bassa.

Il motivo è un vero fallimento silenzioso. HL7 prende il separatore di campo dal messaggio stesso, quindi un campione i cui pipe sono stati sostituiti da look-alike tipografici — che è ciò che fa un elaboratore di testi — viene analizzato perfettamente in campi che sono tutti sbagliati. Nessun errore si verifica da nessuna parte.

Rifiutare un tale campione sarebbe sbagliato, perché un mittente può legittimamente utilizzare un altro separatore. Quindi viene segnalato, il carattere viene nominato e viene suggerito di chiedere un allegato di testo semplice.

14.3 Confronto con il vecchio motore

Prima di spostare un flusso live, la domanda è se Perfuse produce lo stesso output della cosa che è stata in esecuzione per anni. Nessuna quantità di qualità del design risponde a ciò. Vedi migration.

14.4 Verificare contro la cosa reale, nei contenitori

Tre controlli vengono eseguiti contro implementazioni reali piuttosto che contro l'idea di Perfuse di un protocollo. Essi vivono al di fuori di make check perché richiedono un runtime di contenitori e un controllo che richiede Docker è un controllo che le persone smettono di eseguire.

scripts/interop-up.sh avvia tutti e stampa cosa ognuno sblocca.

Ognuno salta piuttosto che fallire quando il suo contenitore è assente, quindi make check passa su una macchina senza Docker.

Perché questo è separato dal resto della suite. Ogni altro test di queste funzionalità aveva entrambe le metà scritte qui: un documento che questo codice firmava, letto nuovamente dal codice che lo firmava. Questo è un accordo con se stessi, e vale meno di quanto sembri.

Il canonicalizzatore SAML è il caso che dimostra il punto. Portava mille righe di test, cinque di loro specificamente sulla canonicalizzazione, e tutti passavano mentre nessun vero fornitore di identità avrebbe potuto firmare qualcuno — la forma canonica che una firma copre era calcolata con prefissi di namespace eliminati, e l'unico modo per scoprirlo era consegnargli un documento che Perfuse non aveva scritto.

Due dei otto controlli hanno trovato difetti diretti, e un terzo ha sollecitato un miglioramento reale. Tre non hanno trovato nulla di sbagliato. Questa proporzione è l'argomento per mantenere tutti: un controllo che passa ha detto qualcosa che non si sarebbe potuto sapere altrimenti, e non c'era modo di sapere in anticipo quali sarebbero stati.

Un modello degno di nota, perché è apparso in entrambi i difetti: l'accettazione non è verifica. HAPI ha accettato il sistema di identificatore malformato e lo ha archiviato; il difetto è apparso solo leggendo la risorsa nuovamente. Un ricevitore che tollera qualcosa non è una prova che sia giusto, solo che questo ricevitore era indulgente.

Due affermazioni catturate sono state commitate, in internal/saml/testdata/keycloak-assertion.xml e entra-response.xml, con test su entrambi — quindi quella particolare regressione viene catturata senza un contenitore.

Entrambi sono necessari piuttosto che uno essere di riserva. Keycloak antepone il suo assert e la firma, Entra no, e questi sono i due casi opposti nella canonicalizzazione — che è esattamente dove si trova il difetto. Un test afferma che ogni documento copre ancora il proprio caso, perché una cattura di sostituzione che è accaduta per caso è stata prefissata e avrebbe dimezzato la copertura senza fallire nulla. La lezione generale non si generalizza così a buon mercato: per qualsiasi altra cosa, il contenitore è il controllo.

14.5 Diagnosi di un test che fallisce una volta e non più

Un test che fallisce in un'esecuzione completa e passa sedici volte da solo non è un test instabile. È un test che condivide qualcosa con l'esecuzione, e il modo per scoprire cosa è misurare la cosa condivisa piuttosto che il test.

Due strumenti esistono per questo, e entrambi sono destinati a essere eseguiti accanto a una suite completa:

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

Ognuno scopre i porti dell'esecuzione dal file di stato della configurazione e campiona ogni 500 millisecondi fino a quando il server esce. Registrano ogni campione piuttosto che solo i fallimenti, che è ciò che li rende utili: un picco si verifica in un'esecuzione in cui nulla è fallito, quindi un difetto che appare una volta in tre esecuzioni diventa misurabile in ognuna.

Impostare PERFUSE_E2E_KEEP=1 per mantenere la directory temporanea, che contiene il database così come è stato lasciato e il log del server per l'intera esecuzione. Il log del server è di solito la risposta. In un caso investigato, ha registrato l'arresto di un canale e la riassociazione del suo listener 421 millisecondi dopo, e la connessione rifiutata della sonda è caduta all'interno di quella finestra.

Leggere la traccia invece di error-context.md, che è stato vuoto in più di un'occasione in cui la traccia conteneva il messaggio reale.

Copiare gli artefatti prima di eseguire nuovamente qualsiasi cosa. Un'esecuzione superata cancella test-results, quindi la traccia del fallimento che si sta indagando scompare nel momento in cui si tenta di riprodurlo. Una volta perso, la domanda che avrebbe risposto non può essere più risposta.

Fermare i contenitori di interop prima. Fermarli prima di un'esecuzione completa del browser e avviarli con ./scripts/interop-up.sh in seguito se sono ancora necessari.

Otto contenitori occupano circa 9,8 GB di memoria e su una macchina senza molto più di quello c'è troppo poco spazio per i processi di Chromium, node e la catena di strumenti Go insieme. Ciò che produce non è un errore di memoria esaurita, ma un renderer che smette di essere pianificato: una traccia registrata mostra un intervallo di 60,2 secondi senza frame, durante il quale Playwright ha atteso che un pulsante diventasse "visibile, abilitato e stabile" e non ha potuto ottenere due frame di animazione consecutivi da confrontare. Il server era sano durante l'intera esecuzione, la richiesta più lenta dell'intera esecuzione essendo di 154 millisecondi.

Quel fallimento si legge come un difetto nel test che è capitato di eseguire. Vale la pena conoscere la forma di esso: ogni richiesta veloce, la pagina visivamente congelata, il ciclo di ritentativi che non raggiunge mai una seconda iterazione e l'intera cosa che passa in isolamento.

Una sola esecuzione alla volta. La suite condivide un server, una sessione di accesso in web/e2e/.auth/admin.json e un file di stato che nomina il processo del server. Nessuno di questi è per esecuzione, quindi una seconda esecuzione che inizia mentre la prima è in corso sovrascrive il file di stato e qualsiasi teardown che finisce per primo uccide il server dell'altra esecuzione e cancella la sua sessione.

Ciò che sembra non è affatto la causa. Ha prodotto un'esecuzione di 279 fallimenti il cui primo messaggio era ENOENT: no such file or directory, open './e2e/.auth/admin.json', un'esecuzione che si è fermata presto segnalando 217 passati e due test falliti con bind: address already in use — nessuno di questi suggerisce due esecuzioni in lotta. La suite ora prende un lucchetto e rifiuta di avviarsi, nominando il processo che lo detiene. Un lucchetto lasciato da un'esecuzione interrotta è preso in carico piuttosto che bloccare per sempre, perché una misura di sicurezza che blocca la suite è una cosa che qualcuno cancella insieme alla sicurezza.

Una trappola correlata, ora risolta: due specifiche hanno nominato i loro porti di ascolto direttamente, quindi un server lasciato indietro da un'esecuzione interrotta li ha fatti fallire su qualcosa con cui non avevano nulla a che fare. I porti sono ora richiesti al sistema operativo.

Non rispondere a nessuna di queste con ritentativi. Un test che passa al secondo tentativo ha trovato una vera corsa e l'ha nascosta, e playwright.config.ts imposta retries: 0 per questo motivo.

Un'avvertenza: campionare ogni 100 millisecondi ha generato venti processi al secondo, allungato un'esecuzione della metà e fallito due test su timeout che non avevano nulla di sbagliato. Uno strumento che cambia ciò che misura produce risultati su se stesso.

14.6 Ciò che ancora necessita di infrastrutture reali

Diverse parti di Perfuse sono implementate e non sono mai state esercitate contro la cosa reale. Sono elencate qui piuttosto che lasciate alla scoperta:

• SMB contro una condivisione Windows reale — il codice del protocollo è completo e testato per la sicurezza del percorso e la gestione degli argomenti, ma nessun test apre un socket a un server associato a un dominio.
• Un portale seriale reale.
• L'importatore Mirth contro XML di un Mirth reale. Testato contro Mirth 4.5.2 in un contenitore, e il risultato è stato su questo repository: l'unico fixture di migrazione qui presente è stato scritto a mano e Mirth non lo caricherà — memorizza il canale come non valido e scarta ogni connettore. Ciò che è stato stabilito è che gli attributi version che il Mirth reale scrive su ogni elemento analizzano lo stesso canale, quindi non sono un pericolo; ciò che non è stabilito è tutto il resto che un'esportazione reale contiene.
• SAML contro un provider di identità commerciale ospitato. Keycloak è verificato; un provider dimostra che un'implementazione corrisponde a un fornitore.
• Una richiesta NCPDP attraverso un interruttore di farmacia reale.
• Un messaggio SCRIPT attraverso Surescripts, dove la certificazione è un processo commerciale piuttosto che tecnico.

Le funzionalità in questo capitolo e nel prossimo esistono in modo che possiate raccogliere le vostre prove piuttosto che prendere la parola di qualcun altro.

14.7 Misurato contro corpora di conformità pubblici

Una suite di test il cui fixture è stato scritto qui dimostra l'accordo con se stessi. Questi sono i dati di altre persone.

14.7.1 FHIR R4, gli esempi della specifica

Tutti i 2.912 file di esempio pubblicati con la specifica FHIR R4 — ogni esempio che gli autori dello standard hanno scritto.

Nessuna risorsa è stata convalidata in modo errato. Ogni fallimento è un rifiuto esplicito che nomina il tipo che non può leggere — 672 ValueSet, 80 ConceptMap e un Parameters. Un convalidatore che passa silenziosamente ciò che non capisce è peggiore di uno che lo dice.

Il corpus ha trovato un difetto, che è il motivo per cui viene eseguito. La convalida di un bundle ha stampato "La convalida del bundle da un file non è ancora supportata" e ha continuato. Ciò era falso in entrambe le direzioni: i bundle le cui voci sono casualmente dei tipi che il parser può tenere sono già stati convalidati e un bundle che era genuinamente non valido ha prodotto la stessa riga, non ha contato nulla e ha uscito zero — compreso sotto -strict, che esiste in modo che questo possa bloccare una build. Quarantadue dei bundle della specifica stessa sono stati saltati.

I bundle sono ora convalidati voce per voce, con tre risultati tenuti separati: una voce che è errata fallisce e nomina il campo, una voce di un tipo che questa build non può leggere è contata come saltata e segnalata e un bundle che trasporta nessun corpo di risorsa non è né. Lo stesso corpus è passato da 2.100 risorse controllate a 13.723.

14.7.2 HL7 v2, il corpus di test HAPI

I fixture di messaggio da HAPI, l'implementazione Java di riferimento HL7 v2 — materiale deliberatamente scomodo, compresi payload uuencoded, delimitatori sfuggiti e gruppi ripetuti.

59 messaggi, 59 parsati, nulla rifiutato. Sette tipi di messaggio in un corpus che ogni singolo sistema descriverebbe come una cosa, che è il punto perfuse profile esiste per fare.

14.7.3 Ciò che non è stato eseguito

DICOM contro un set di conformità pubblico e X12 contro un corpus pubblicato. Nessuno dei due è stato fatto e nessuno dei due dovrebbe essere inferito dai due precedenti.

15 Migrazione da Mirth

Due cose sono necessarie per sostituire un motore funzionante: i canali devono essere trasferiti e qualcuno deve essere in grado di dimostrare che il sostituto produce lo stesso output. Perfuse esegue la prima importando le esportazioni di Mirth e la seconda confrontando i due motori con il proprio traffico.

Tutto ciò che è contenuto in questo capitolo si applica ugualmente a Open Integration Engine e BridgeLink. Mirth Connect ha smesso di essere open source alla versione 4.6 nel marzo 2025; OIE (ospitato dalla Eclipse Foundation) e BridgeLink (Innovar Healthcare) sono le fork che continuano la linea open-source e entrambi scrivono gli stessi formati di esportazione. L'importatore è testato contro tutti e tre, di seguito.

15.1 Importazione dei canali

Perfuse legge ogni esportazione scritta da questi motori:

Puntare perfuse translate su uno di essi o rilasciarne uno su Amministra → Migra:

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

Una libreria di modelli di codice diventa lib/<library>.js accanto ai canali e ogni canale per cui Mirth aveva abilitata la libreria ottiene scripts.include: [lib/<library>.js] — quindi un trasformatore che chiama una funzione del sito come formatMRN() la trova ancora. Un canale per cui la libreria non era abilitata non la include, perché i suoi script non potevano vederla in Mirth. I frammenti di trascinamento e rilascio vengono esclusi: Mirth li incolla solo manualmente in un passaggio, quindi non sono codice che viene eseguito autonomamente. Nel browser, l'importazione di un canale salva prima le librerie che include.

Un Channel Writer nomina il canale a cui consegna per id. In un gruppo o in un backup, l'obiettivo è nello stesso documento, quindi diventa una destinazione channel che nomina quel canale; da un'esportazione a canale singolo viene segnalato per essere compilato. Gli script globali a livello di server non hanno un equivalente in Perfuse e vengono segnalati anziché eliminati.

La relazione dice, per canale, se è stato tradotto correttamente, tradotto con avvisi o non può essere letto.

Il titolo è una frazione con il denominatore — "37 di 40 pronti" — perché "37 pronti" non dice nulla su ciò che si deve ancora fare.

Un canale che non può essere letto è un problema diverso da uno che non può essere tradotto. Il primo significa che il XML stesso non è stato analizzato e di solito è un'esportazione troncata o parziale; il secondo significa che il contenuto del canale ha qualcosa senza un equivalente in Perfuse. L'importazione li separa.

15.2 Ciò che si traduce e ciò che richiede una decisione

Le sorgenti, le destinazioni, i filtri e i passaggi del trasformatore ordinario si traducono direttamente. I connettori che si traducono: TCP/MLLP (e TCP grezzo con il framing), HTTP, File, Database, JavaScript, DICOM, Web Service (SOAP), SMTP e Channel Reader/Writer. JMS e il Document Writer non si traducono e sono segnalati come blocchi.

Un passaggio Mapper che imposta una variabile la inserisce nella mappa con il nome del suo ambito — channelMap per default — esattamente come fa Mirth, in modo che passaggi successivi che la leggono con $('name') la trovino.

I trasformatori JavaScript non lo fanno in generale. I canali Mirth contengono spesso codice sostanziale in un trasformatore e non c'è una conversione automatica da JavaScript arbitrario a passaggi dichiarativi. L'importatore li segnala piuttosto che tentare una traduzione che potrebbe essere sottilmente errata: un trasformatore mal tradotto è peggiore di uno segnalato per un essere umano, perché verrà eseguito.

Dove uno script deve effettivamente rimanere uno script, Perfuse può eseguirlo — vedere la chiave scripts nel riferimento canale — al costo della traccia a livello di passaggio descritta in debugging.

15.3 Ciò che l'importatore è stato testato

Cinque motori, ognuno che scrive i propri documenti: Mirth 4.5.2, OIE 4.5.2, 4.6.0 e 4.7.0, e BridgeLink 26.9.0. scripts/mirth-engine-corpus.sh compila un piccolo programma contro i jar di ogni motore e utilizza il proprio serializzatore per scrivere tre canali ordinari — un flusso MLLP con un mapper, uno script che chiama una libreria di modelli di codice e un filtro; un flusso HTTP in un database; un sondaggio file su MLLP — più la libreria e un gruppo di canali. Li carica nel motore in esecuzione e scarica il backup del server del motore. I risultati vengono commitati in internal/mirth/testdata/engines/, e la suite di test controlla l'importatore per ognuno di essi in ogni build: ogni backup viene letto, tradotto, caricato e il canale ADT viene eseguito con due messaggi per verificare che la libreria riempia il numero di record e il filtro scarti il risultato.

Le esportazioni di Perfuse vanno nell'altro senso — i canali Perfuse importati in ogni motore in esecuzione e verificati che il motore non li memorizzi come non validi. Tutti e cinque accettano ogni trasporto esportato da Perfuse. Open Integration Engine 4.7.0 ha aggiunto due impostazioni HTTP senza equivalente qui: un mittente HTTP legato a un indirizzo locale scelto viene segnalato come avvertimento, e un limite di intestazione di richiesta dell'ascoltatore HTTP solo quando è superiore al 1 MB accettato da Perfuse.

La prima esecuzione contro questo corpus ha trovato quattro difetti, tutti risolti: il traduttore rifiutava le sorgenti HTTP e File come "solo MLLP è supportato" molto tempo dopo che Perfuse aveva entrambi; leggeva l'indirizzo di un mittente HTTP da un campo che nessuno dei motori scrive; traduceva la dimensione del buffer di socket di Mirth come un limite di messaggio di 64 KB; e una variabile di un Mapper diventava una globale JavaScript che $('mrn') non vedeva mai, quindi la libreria riempiva una stringa vuota.

La fixture a canale singolo che ha iniziato questo è stata esportata anche da Mirth 4.5.2, autore di Mirth stesso e non scritta qui. Questa distinzione ha guadagnato il suo posto: l'unica fixture in questo repository utilizzata era scritta a mano e un vero Mirth non la caricherà - l'API accetta il POST e quindi archivia il canale come This channel is invalid. Verify all required extensions are loaded correctly, con ogni connettore di destinazione scartato.

Scrivere a mano non avrebbe mai funzionato, e il motivo vale la pena di conoscerlo se si stanno producendo esportazioni proprie. Il serialiser di Mirth ignora gli elementi che non riconosce, quindi un nome di elemento errato non produce alcun errore - il connettore semplicemente non c'è dopo.

scripts/mirth-author-channel.sh costruisce uno utilizzando le classi di modello di Mirth e il suo own serialiser, poi lo invia a un server in esecuzione e fallisce se il server lo rifiuta. L'importatore di Perfuse legge il risultato: nome, trasporto di origine e destinazioni tutte sopravvivono.

15.4 Dimostrare che corrisponde

Questa è la parte che decide se una migrazione avviene, e ha bisogno di prove piuttosto che di fiducia.

Perfuse confronta la sua own uscita contro quella del vecchio motore, messaggio per messaggio, sul traffico. Ciò di cui ha bisogno sono coppie: il messaggio come è arrivato, e il messaggio che il vecchio motore ha prodotto da esso. Entrambi sono nel message store di Mirth e possono essere esportati dal browser dei messaggi.

15.4.1 Quattro numeri, non una percentuale di passaggio

Sono quattro numeri perché significano quattro cose diverse e collassarli nasconde quelli che hanno bisogno di una decisione.

Identico significa byte per byte, non equivalente. Un test più debole permetterebbe differenze nell'ordine dei segmenti o separatori alla fine, e quelli sono esattamente ciò che un sistema a valle pignolo rifiuta.

Le differenze cosmetiche sono contate separatamente piuttosto che piegate nella colonna dei buoni. Portano veramente informazioni, quindi trattarle come fallimenti seppellirebbe le scoperte reali sotto migliaia di nulla - ma non sono identiche nemmeno, e un ricevitore che fa la sua own analisi rigorosa può non essere d'accordo.

"Non eseguibile" è separato da "diverso" perché è solitamente una lacuna di configurazione che l'importatore non poteva riempire, non una decisione di mappatura. Se tutto è in quella colonna, il verdetto dice così e dice di guardare la configurazione prima di leggere qualsiasi altra cosa.

15.4.2 Le differenze sono raggruppate per campo

Un'esecuzione su cinquantamila messaggi che segnala quattromila differenze non ha detto nulla che si possa agire. La stessa esecuzione che segnala che PID-8 differisce in ogni messaggio perché il vecchio motore scriveva Male dove Perfuse scrive M ha detto esattamente una cosa da decidere.

Quindi ogni scoperta è un campo, con un conteggio, e dice se la differenza è sistematica - la stessa coppia di valori ogni volta - o se il contenuto del campo differisce.

Quella distinzione è la cosa più utile nel report. Una coppia di valori distinti su quattromila messaggi è una singola decisione di mappatura. Quattromila coppie di valori distinte è il contenuto che differisce, che è un problema diverso e molto peggiore, e i due non devono leggere allo stesso modo.

Le scoperte sono ordinate per quanti messaggi influenzano, quindi la causa singola più grande è prima.

15.4.3 Il verdetto non arrotonda

Fornisce conteggi esatti: 49.993 su 50.000, non "oltre il 99%". I sette sono il punto di eseguire.

È scritto per essere citabile in una richiesta di modifica, perché è lì che finisce il numero.

15.5 Una sequenza suggerita

1. Importare i canali e risolvere tutto ciò che viene segnalato come illeggibile.
2. Per ogni canale, esaminare gli avvisi. La maggior parte saranno script.
3. Esportare alcune migliaia di coppie di messaggi da Mirth per il canale più trafficato e eseguire il confronto.
4. Lavorare sui risultati. Quelli sistematici sono una decisione ciascuno.
5. Eseguire nuovamente fino a quando le sole differenze sono quelle che si sono deciso siano corrette.
6. Eseguire Perfuse in modalità ombra accanto a Mirth su traffico live, consegnando da nessuna parte, e confrontare nuovamente su un periodo che include un fine settimana e una fine mese.
7. Passare a un canale, non a tutti.

15.6 Ciò che funziona solo sul software di un fornitore

La schermata di migrazione risponde a una seconda domanda, e vale la pena chiederla prima di avere un'opinione su Perfuse: quanto della logica di integrazione può funzionare solo sul software che si possiede.

Ogni canale ottiene un verdetto di Portabilità, dalla stessa scansione che produce le note di migrazione. Esegue contro un'esportazione del canale, quindi non richiede nulla installato e non modifica nulla.

15.6.1 La distinzione è l'intero punto

La maggior parte del Java nei script di Mirth non è di blocco. SimpleDateFormat, HashMap, Apache Commons — tutto funziona intorno a un motore JavaScript del 2009, tutto è ordinario, tutto ha equivalenti diretti. Un canale con trecento di quelle referenze è completamente portabile, e uno strumento che riporta "300 referenze Java, siete intrappolati" starebbe mentendo.

Il blocco è specificamente le chiamate che necessitano del server del fornitore: com.mirth.connect.* e jar del fornitore. Cinque di quelle e si è bloccati. Cinquecento dell'altro tipo e si è liberi.

Quindi il verdetto inizia con il numero che conta e dice nella stessa frase che il numero più grande non è quello. Dove ci sono chiamate del fornitore, sono elencate per nome — un conteggio è un'asserzione, e un elenco è qualcosa che il proprio ingegnere può andare a controllare.

Una terza categoria è tenuta separata: capacità che esiste ma non da uno script. Avviare un canale da JavaScript non ha equivalente qui, e c'è un endpoint API che fa esattamente la stessa cosa. Chiamare quel blocco sarebbe esagerare il risultato.

15.6.2 Chiamate Java che funzionano invariati

Le classi Java più comuni vengono eseguite come sono scritte. Perfuse non ha un runtime Java, quindi queste sono classi JavaScript con gli stessi nomi e metodi, sufficienti per il modo in cui gli script del canale li utilizzano; importPackage(java.util) e importClass(...) li portano nell'ambito dei loro nomi brevi, come in Rhino (i Date, Map, Set, Math, String e Boolean di JavaScript non vengono mai sostituiti: quelli Java sono ancora lì con il nome completo). Il rapporto di migrazione conta ogni chiamata a questi come già supportata.

Si comportano come Java dove gli script dipendono da esso: Integer.parseInt("x") lancia NumberFormatException, String.replaceAll e split accettano espressioni regolari mentre replace è letterale, le mappe chiave stringhe per valore, TreeMap e TreeSet iterano in ordine, e SimpleDateFormat.parse restituisce una data getTime() funziona su. Un metodo che uno script chiama che l'equivalente manca fallisce in quella riga, nominandolo; qualsiasi altra classe Java fallisce per nome, come prima. BigDecimal è un doppio qui, quindi non mantiene l'aritmetica decimale esatta di Java: controllare gli script che lo utilizzano per il denaro.

15.6.3 Gli script esterni vengono segnalati come sconosciuti

Un passaggio che esegue un file di script esterno fa riferimento a un percorso sul vecchio server, e il file non è nell'esportazione. Non si può dire nulla su cosa contenga, quindi viene conteggiato come sconosciuto piuttosto che assunto in un modo o nell'altro. Recuperare quei file prima di concludere qualcosa — in entrambe le direzioni.

15.6.4 Il blocco di Perfuse, dichiarato nella stessa frase

Questa sezione sarebbe disonesta senza di esso.

Perfuse è Apache 2.0, che è irrevocabile per il codice già rilasciato. È possibile forkare ciò che esiste oggi e nessuno può revocare quello. I canali sono file YAML e gli script sono JavaScript ordinari, quindi non c'è una superficie proprietaria da chiamare — il sapore di Java di Mirth è structuralmente non disponibile qui, che è il posto in cui una limitazione è genuinamente una funzione.

Ciò che non promette: che una versione futura rimanga aperta, che un servizio ospitato esista a un prezzo che si desidera, o che la migrazione da Perfuse non costi nulla. Spostare qualsiasi livello di integrazione significa ritestare ogni canale contro traffico reale. Ciò che si sta scegliendo è se gli artefatti che si costruiscono sono leggibili e portabili, e se l'uscita dipende da una licenza che qualcun altro controlla.

15.6.5 Impostazione del passaggio 6

La sezione Shadow avvia un confronto. Scegliere il canale che è in esecuzione, scegliere il candidato da confrontare contro dall'elenco e avviare.

Tre cose su di esso valgono la pena di sapere prima di affidarsi ai numeri.

Il candidato è scelto da un elenco, non digitato. Un'ombra nomina un file di canale e un nome che non si risolve rende il canale *live* non valido — Perfuse rifiuta un canale nel suo complesso quando qualcosa a cui fa riferimento è rotto. Quindi un errore di digitazione non produce un avvertimento, ma fa scomparire il canale in esecuzione.

La quota è una percentuale. Ridurla solo su un feed occupato e conoscere i costi: il campionamento riduce il lavoro e la fiducia nella stessa proporzione, e il messaggio che avrebbe mostrato la differenza è quello insolito.

I campi da ignorare sono solitamente necessari. Un canale che stampa un timestamp o un numero di sequenza differisce in ogni singolo messaggio, che segnala un tasso di differenza del 100% e non ti dice nulla. MSH-7 e MSH-10 sono la coppia comune.

Un confronto viene scritto nel file del canale non appena lo si avvia e inizia l'osservazione quando il canale viene caricato nuovamente — lo schermo lo dice invece di affermare che è già in esecuzione. Interrompere un confronto lascia il canale candidato al suo posto, perché il candidato è la cosa destinata a essere messa in linea.

Il passo 6 è quello che non può essere abbreviato. Le differenze che contano sono solitamente nel traffico che appare solo occasionalmente — un evento di trigger raro, un batch di fine mese, un mittente che si comporta diversamente a mezzanotte — e un campione preso nel pomeriggio non le conterrà.

15.7 Tornare indietro dall'altra parte

Un canale può essere esportato come file di canale Mirth, dal browser: Canali, quindi A Mirth sul canale desiderato.

Ciò esiste perché l'obiezione a sostituire un motore funzionante raramente riguarda se il sostituto sia buono. È ciò che accade se la decisione si rivela sbagliata, e un'esportazione che torna indietro dal modo in cui è arrivata è la risposta più economica a ciò.

Leggere ciò che il dialogo ti dice prima di prendere il file. Il formato di Mirth non ha posto per un filtro Perfuse, una catena di trasformazione, un contratto o un confronto di ombra, quindi un canale esportato fa meno di quello da cui proviene. I trasporti e i loro indirizzi si convertono; la logica no. Ogni perdita è elencata per nome prima che il file venga offerto, e la stessa lista viene inserita nella descrizione del canale in modo che chi lo importa lo veda anche.

Un canale che Mirth non può esprimere viene rifiutato piuttosto che approssimato. Una destinazione S3 non ha un equivalente Mirth, e un canale che importa pulito mentre consegna da qualche altra parte oltre al bucket sarebbe peggiore di nessun file affatto. Il rifiuto nomina la destinazione in colpa.

Le definizioni dei connettori non vengono scritte da una lettura del formato di Mirth. scripts/mirth-dump-connector-templates.sh ha il serializzatore di Mirth che produce i valori predefiniti per ogni classe di connettori, e Perfuse sostituisce i valori in quei documenti — rifiutando ogni impostazione che il modello non contenga già. Ciò conta a causa di come Mirth risponde a un canale che non può analizzare: non rifiuta l'importazione. Memorizza un canale la cui descrizione è stata sostituita con "Questo canale non è valido. Verificare che tutte le estensioni richieste siano caricate correttamente" e le cui destinazioni sono state eliminate silenziosamente. Un esportatore verificato contro la sua stessa uscita piuttosto che contro un server supera ogni test mentre produce documenti che vengono scartati, che è esattamente ciò che è successo qui prima che le esportazioni venissero provate contro un Mirth in esecuzione.

Ciò che attraversa oggi: MLLP e TCP in entrambe le direzioni, HTTP in entrambe le direzioni, lettura e scrittura di file, lettura e scrittura di database, DICOM in entrambe le direzioni, e destinazioni SMTP, SOAP e JavaScript. Ogni coppia viene verificata importando in un Mirth 4.5.2 reale e verificando che il server non abbia sostituito silenziosamente il canale.

16 CMS-0057 per i pagatori

La regola finale di interoperabilità e autorizzazione preventiva del CMS (CMS-0057-F) richiede ai pagatori interessati — organizzazioni Medicare Advantage, programmi Medicaid e CHIP statali e i loro piani di assistenza sanitaria gestita, e gli emittenti QHP sui mercati federali — di eseguire quattro API FHIR a partire dal 1° gennaio 2027, e di pubblicare le metriche di autorizzazione preventiva sul loro sito web pubblico ogni anno a partire dal 2026.

Perfuse fornisce le quattro API nel suo endpoint FHIR e le conversioni che le riempiono: reclami liquidati come CARIN Blue Button, autorizzazioni preventive come Da Vinci PDex, e le metriche annuali nel layout del modello del CMS. La vista CMS-0057, sotto Exchange, dice quali delle quattro questa istanza può rispondere e cosa ogni ancora necessita, e esegue tutte e tre le conversioni nel browser.

I farmaci sono fuori dall'ambito in tutto, come lo sono nelle disposizioni di autorizzazione preventiva della regola: nessuna richiesta di farmaci, nessun formulari, e una riga di metriche che nomina un farmaco viene rifiutata piuttosto che conteggiata.

16.1 Le quattro API

L'API di accesso ai pazienti non richiede un'operazione propria: si tratta del normale lettura e ricerca dell'endpoint FHIR, protetto da SMART, con risorse CARIN e PDex nel negozio. La ricerca di ExplanationOfBenefit supporta i parametri con nomi CARIN — patient, identifier, type, service-date, billable-period-start, provider, insurer, coverage — e Coverage supporta subscriber-id, identifier e payor.

16.1.1 Due versioni delle guide: 2.1.0 e 2.2.x

CMS-0057-F raccomanda CRD, DTR e PAS 2.0.1 e 2.1.0. Le versioni 2.0.1 si basano su US Core 3.1.1, che è scaduto il 1° gennaio 2026, quindi la versione 2.1.0 è la versione che un sistema di registrazioni elettroniche sanitarie costruito per la regola probabilmente parlerà; le più recenti sono CRD 2.2.1, DTR 2.2.0 e PAS 2.2.1. Perfuse risponde in entrambe. Determina quale versione parla il chiamante, più specifica per prima:

1. dalla richiesta: estensione CDS Hooks di CRD davinci-crd.requestedVersion ("2.1"), o la versione su un profilo Da Vinci di un input DTR o PAS (profile-pas-request-bundle|2.1.0);
2. dalla registrazione del chiamante: davinci_version: "2.1" su un client SMART (-smart-clients) o un client CDS (-cds-clients);
3. dal server: serve -davinci-version 2.1; il valore predefinito è 2.2.

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

Ogni risposta è decisa e mantenuta nella forma 2.2.x e riscritta per un chiamante 2.1.0 come viene inviata, quindi le regole, la coda di revisione, il collegamento X12 278 e le metriche sono le stesse per entrambi. La riscrittura copre ciò che le versioni scrivono in modo diverso: CRD 2.1.0 non ha indeterminate (Perfuse dice condizionale, con il motivo) e non ha una categoria in un dettaglio di copertura; DTR 2.1.0 nomina il pacchetto PackageBundle e lascia la risposta del questionario all'app; PAS 2.1.0 risponde con un solo Bundle alla richiesta $inquire e manca delle estensioni del revisore e della trasmissione. L'elenco completo e il controllo con ogni guida 2.1.0 è in conformance/davinci21. Una notifica PAS segue -davinci-version, poiché un abbonamento non specifica quale versione il suo proprietario legge.

16.2 Requisiti e documentazione di copertura: CRD e DTR

L'API di autorizzazione preventiva è in pratica tre guide Da Vinci insieme. CRD dice al clinico, mentre l'ordine è ancora uno schema, se è coperto, se necessita di autorizzazione preventiva e quale documentazione è richiesta. DTR consegna all'EHR il questionario che raccoglie quella documentazione. PAS invia la richiesta e restituisce la decisione. Perfuse serve tutti e tre come pagatore.

-crd-rules rules.yaml serve CRD tramite CDS Hooks all'indirizzo /cds-services: tutti e sei degli hook di CRD, order-sign, order-select, order-dispatch, appointment-book, encounter-start e encounter-discharge, ciascuno con un prefetch per la copertura attiva del paziente. I due hook di encounter prefetchano anche l'incontro e rispondono riguardo all'incontro stesso, abbinato per tipo e tipo di servizio, come appointment-book risponde riguardo a un appuntamento. Le regole sono le politiche del pagatore, mantenute in un file perché cambiano senza rilasci software:

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

Ogni ordine riceve un aggiornamento systemActions che trasporta l'estensione delle informazioni di copertura del CRD - che il sistema EHR memorizza sull'ordine e invia successivamente con l'autorizzazione preventiva - e una carta che il clinico legge. Un ordine il cui codice non ha regole viene risposto come conditional, mai assunto come coperto; una richiesta senza copertura alcuna riceve una carta che lo indica. La cartella examples/crd/ contiene un file di regole e un questionario corrispondente.

Una regola può anche trasportare il resto di ciò che CRD consente a un pagatore di dire:

• billing_codes: i codici da addebitare.
• details: limiti e costi, come ad esempio allowed-period o in-network-copay.
• contact: chi contattare.
• expiry_days: per quanto tempo la risposta rimane valida.
• depends_on: codici di altri ordini di cui la risposta dipende, in modo che il sistema EHR richieda nuovamente se cambiano.
• doc_purpose: lo scopo della documentazione (withclaim, withorder, retain-doc). withpa viene rifiutato, poiché l'invariante crd-ci-q4 di CRD 2.2.1 lo rifiuta.

Ciò che il registro elettronico dei pazienti (EHR) non ha prelevato in anticipo, Perfuse legge dal fhirServer dell'EHR con il token che ha inviato. Se fallisce, la risposta è indeterminate con il motivo technical di CRD, mai un'ipotesi. Una Copertura che è terminata o non è attiva viene risposta come not-covered, no-active-coverage.

members: fhir nel file di regole risolve la copertura contro i propri record del pagatore in questo server FHIR (avviarlo con -fhir), gli stessi record che $member-match legge:

• un paziente che non è un membro riceve la risposta no-member-found;
• un membro la cui copertura non corrisponde riceve la risposta coverage-not-found;
• un'autorizzazione preventiva già approvata per il servizio (una ClaimResponse con un preAuthRef) fa si che la risposta sia satisfied,

con quel numero.

La discovery dichiara davinci-crd.version e un'opzione di configurazione coverage-info. Quando un client disattiva l'opzione, la risposta è vuota. I JWT EHR vengono verificati come li definisce CDS Hooks, con iss, aud, exp, iat e jti e senza sub, e un jti ripetuto viene rifiutato.

Le chiamate si autenticano con il JWT che un EHR firma per ogni chiamata, da un emittente nominato in -cds-clients con il suo URL JWKS - che è come CDS Hooks lo descrive - o con un token API Perfuse. La scoperta è aperta, come richiede CDS Hooks.

DTR: caricare i questionari nel punto di terminazione FHIR e POST /fhir/Questionnaire/$questionnaire-package li restituisce come bundle di pacchetti DTR, con le librerie CQL che nominano. La richiesta può nominare il questionario o inviare l'ordine e lasciare che le informazioni di copertura dicano quale.

Provarlo: Payers → Claims & auth → Coverage requirements (CRD) invia un ordine alle regole di questo server o all'URL del servizio CDS di un pagatore e mostra le carte e le informazioni di copertura.

16.3 Reclami come CARIN Blue Button

perfuse cms0057 carinbb accoppia ogni reclamo in un 837 con il suo pagamento in un 835, in base al numero di account del paziente che l'835 è richiesto di restituire, e scrive una transazione FHIR per ciascuno: l'ExplanationOfBenefit con il paziente, la copertura, le organizzazioni e i professionisti che fa riferimento.

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

Il profilo segue il reclamo: i reclami professionali (837P) diventano C4BB-ExplanationOfBenefit-Professional-NonClinician, e quelli istituzionali (837I) inpatient o outpatient in base al tipo di fattura. Ogni voce è un PUT con un id preso dagli identificatori di origine, in modo che caricare due volte lo stesso reclamo lo aggiorna invece di crearne una seconda copia.

Tre cose non sono presenti in nessuno dei file X12 e ciascuna viene gestita dicendo che non ci sono invece di ipotizzare:

• Il sistema di identificatori. CARIN richiede che l'identificatore del membro nomini lo spazio dei nomi del pagatore. -system è richiesto; non c'è un valore predefinito, perché un valore predefinito darebbe a ogni pagatore che utilizza Perfuse lo stesso spazio dei nomi.
• Lo stato di rete. Nessuna delle due transazioni dice se il fornitore di fatturazione è in rete e decide cosa paga il membro. Senza -network lo stato di pagamento del beneficio è other e la conversione nota il motivo.
• Un reclamo che l'835 non menziona. Un ExplanationOfBenefit CARIN è un reclamo giudicato. Senza l'835 non c'è un numero di reclamo del pagatore, non c'è pagamento e non c'è responsabilità del membro, quindi il reclamo viene segnalato come saltato e non convertito.

Le diagnosi vengono scritte con il loro punto decimale (J02.9, non J029), perché è così che il sistema di codici li pubblica e un server di terminologia chiesto sulla grafia diversa dice che non esiste. L'identificatore del membro di un dipendente è quello dell'iscritto, che è ciò che l'837 trasporta, e le note lo dicono. Un NPI il cui cifra di controllo è errata viene segnalato prima che US Core lo rifiuti.

16.4 Autorizzazioni preventive come PDex

perfuse cms0057 priorauth converte una risposta Da Vinci PAS ClaimResponse — o il bundle di risposta PAS che la trasporta — in una spiegazione PDex di autorizzazione preventiva ExplanationOfBenefit, che è ciò che servono tutti e tre i dati API.

perfuse cms0057 priorauth pas-response.json pas-claim.json

La richiesta PAS è opzionale e quasi sempre necessaria. Un ExplanationOfBenefit deve indicare quale copertura è stata utilizzata per la decisione e solo la richiesta la trasporta; senza di essa la conversione si ferma e lo segnala. L'azione di revisione — approvata, rifiutata, sospesa, con il suo numero di autorizzazione e motivo — si sposta dall'estensione PAS a PDex, e il tipo di servizio X12 mantiene il suo codice sotto l'URI a cui PDex lo associa.

16.5 Le API di accesso ai fornitori e di comunicazione tra pagatori

Con -fhir-payer-apis l'endpoint FHIR risponde a tre operazioni aggiuntive:

• POST /fhir/Patient/$member-match — abbinamento dei membri HRex. Gli identificatori di copertura si restringono a pochi candidati e il cognome e la data di nascita devono essere concordi; un nome proprio è confrontato per iniziale e il genere solo quando entrambi i lati lo indicano. Più di un candidato superstite non è un abbinamento e la risposta è 422 anziché un'ipotesi, poiché un'ipotesi rivela le pretese di uno sconosciuto. È richiesto un consenso attivo che consente la divulgazione, poiché l'API di comunicazione tra pagatori è opt-in per il membro; -fhir-member-match-without-consent lo disattiva per i test.
• GET o POST /fhir/Group/{id}/$davinci-data-export — l'esportazione bulk Da Vinci del gruppo corrente. exportType sceglie il pubblico: hl7.fhir.us.davinci-pdex#provider-download o #provider-delta per l'accesso ai fornitori, #payertopayer per la comunicazione tra pagatori.
• GET /fhir/Group/{id}/$export — l'esportazione standard dei dati del gruppo, trattata come accesso ai fornitori.

Le esportazioni applicano le esclusioni della regola in uscita. Le pretese perdono il pagamento e ogni importo di condivisione dei costi e rimborso, e mantengono i servizi, i codici, le date e i fornitori; il profilo CARIN viene rimosso da meta.profile perché la risorsa non soddisfa più tale profilo. La comunicazione tra pagatori esclude anche le autorizzazioni preventive rifiutate. I membri che detengono un consenso attivo di opt-out PDex Provider Access sono esclusi dall'esportazione del fornitore e il registro indica quanti. Il parametro patient può restringersi solo ai membri del gruppo; il nome di chiunque altro viene rifiutato.

L'accesso all'esportazione di un Gruppo è deciso dall'autenticazione dell'endpoint. Gli ambiti SMART dicono quali tipi di risorsa un token può leggere, non quale Gruppo, quindi ogni fornitore necessita di un token che possa raggiungere solo la propria lista di attribuzione. Un token API può essere limitato ai Gruppi quando viene creato — perfuse token create -label riverside-provider-access -fhir-groups riverside-attributed, o il campo Limita ai Gruppi FHIR sotto Utenti → Credenziali macchina — e sul punto di terminazione FHIR può quindi leggere quei Gruppi, eseguire $davinci-data-export o $export su di essi e recuperare ciò che l'esportazione ha prodotto, e nulla altro. Un token di un altro fornitore risponde non trovato piuttosto che vietato, quindi un token non apprende quali altre liste di attribuzione esistono; ogni altra richiesta, inclusa la corrispondenza dei membri e la ricerca ordinaria, viene rifiutata. Il limite si applica ai token API; un token da un emittente SMART non porta alcun limite di Gruppo. Quando SMART è configurato anche, i token API vengono rifiutati a meno che Impostazioni → FHIR → Accetta token API Perfuse accanto ai token SMART non sia attivato (vedere Sicurezza, *Chi può chiamare il punto di terminazione FHIR*); un token del Gruppo di un fornitore limitato necessita di esso.

16.6 Un elenco dei fornitori: Plan-Net

CMS-0057 chiede anche ai pagatori un elenco dei fornitori e il punto di terminazione FHIR serve uno a Da Vinci Plan-Net 1.1.0 senza opzione per attivarlo: caricare i Practitioners, PractitionerRoles, Organizations, OrganizationAffiliations, Locations, HealthcareServices, InsurancePlans e Endpoints, e le app dei membri possono cercarli. Ogni parametro di ricerca Plan-Net è indicizzato - il ruolo di rete e servizio, l'area di copertura di un piano, l'organizzazione partecipante di un'affiliazione, l'organizzazione partof - insieme agli include e alle catene inverse (_has) che le query della guida utilizzano, e la CapabilityStatement elenca i profili Plan-Net.

La suite Plan-Net di Inferno supera 199 test. I 10 test che non supera sono catene di collegamento in cui il kit prende il valore di ricerca dal primo organizzazione che ha visto invece che da una delle risorse cercate; ciò è stato segnalato al kit (problema 34) e il server risponde correttamente a quelle query quando viene fornito un valore che i dati contengono.

16.7 Metriche di autorizzazione preventiva

perfuse cms0057 metrics legge un file CSV di decisioni esportate dal sistema di gestione dell'utilizzo e produce la pagina pubblica richiesta da CMS, nel layout della sua *Rapporto e modello di metriche di autorizzazione preventiva*.

perfuse cms0057 metrics -year 2025 -org "Springfield Health Plan" -services services.csv \
    decisions.csv > prior-authorization-metrics-2025.html

Le colonne vengono trovate per intestazione: priority, received, decided e decision sono obbligatorie, e request_id, line_of_business, extended, appealed, appeal_decision, service_code e service_description vengono letti quando presenti. Una richiesta appartiene all'anno in cui è stata decisa; una richiesta ancora in sospeso viene elencata come esclusa, mai conteggiata. Ogni riga che non può essere letta viene segnalata con il suo numero di riga.

L'aritmetica segue il modello: per richieste standard ed accelerate separatamente, la quota approvata e rifiutata, approvata e rifiutata entro il termine di decisione, approvata dopo l'estensione del tempo di revisione e approvata dopo appello — su appelli, non su richieste — con la media e la mediana del tempo da ricezione a decisione. Una mediana inferiore a un giorno viene scritta in ore anziché arrotondata a "0 giorni", che il modello chiede esplicitamente. Le richieste parzialmente approvate vengono conteggiate come approvate, poiché il modello non ha una categoria per esse, e la pagina indica quante ce ne sono state. Le metriche vengono segnalate per linea di business, che è il livello richiesto da CMS.

La pagina è autonoma — nessuno script, nessun foglio di stile esterno o font — perché è pubblicata su un sito web pubblico da chiunque lo mantenga, e qualsiasi cosa carichi da altrove è qualcosa che può rompersi o tracciare un visitatore. -format csv e -format json forniscono gli stessi numeri per altri usi. Senza -services la pagina riporta un avviso che l'elenco di elementi e servizi che richiedono autorizzazione preventiva è mancante, perché CMS lo richiede sulla stessa pagina.

16.8 Farmaci: il prontuario, il beneficio prescrittivo in tempo reale e l'autorizzazione preventiva elettronica

CMS-0062-P (proposto il 14 aprile 2026) introdurrebbe i farmaci nell'autorizzazione preventiva: i pagatori interessati supporterebbero l'autorizzazione preventiva elettronica NCPDP SCRIPT, lo standard NCPDP Formulary & Benefit e il beneficio prescrittivo in tempo reale NCPDP a partire dal 1 ottobre 2027, deciderebbero le richieste di farmaci entro 24 ore (accelerato) e 72 ore (standard), fornirebbero una ragione specifica per ogni diniego e segnalerebbero le metriche dei farmaci a partire dal 2028. Medicare Part D richiede già l'autorizzazione preventiva elettronica SCRIPT. Un file, il formulario, risponde a tutte queste richieste:

perfuse serve -fhir -pas -crd-rules payer-rules.yaml -formulary formulary.yaml

examples/formulary/formulary.yaml è un esempio il cui farmaci sono concetti RxNorm reali con NDC elencati in RxNav. Un file nomina il pagatore, i suoi piani (ognuno con il formulario che utilizza, i suoi ID di gruppo e le sue quote di costo per beneficio farmaceutico e fascia) e i suoi formulari. Ogni farmaco è un RxNorm SCD o SBD con il suo gruppo RxNorm (lo SCDG o SBDG richiesto dall'API Drug Formulary), i suoi NDC, una fascia e i suoi limiti: prior_authorization, step_therapy, quantity_limit (una quantità in un numero di giorni scorrevole e una quantità massima giornaliera), not_covered, alternatives (codici RxNorm, più preferiti per primi), notes e questionnaire, l'URL canonico del questionario FHIR per l'autorizzazione preventiva. cost_30_day è il costo del piano per una fornitura di 30 giorni, che è una percentuale della copertura assicurativa; senza di esso, la copertura assicurativa è indicata come una percentuale, mai come un importo inventato. L'intero file viene verificato quando viene caricato, ogni problema viene elencato contemporaneamente. Un membro viene trovato dall'elenco members del file, per gruppo o attraverso il negozio FHIR: una Coverage il cui subscriberId è l'ID del membro e il cui class di tipo plan è l'ID del piano. Payers › Drugs visualizza il formulario, prezza un farmaco ed esegue un'autorizzazione preventiva dall'inizio alla fine.

16.8.1 L'API Da Vinci US Drug Formulary

Pubblicato in /formulary/fhir come Da Vinci US Drug Formulary 2.1.0: ogni piano è un PayerInsurancePlan, ogni formulario è un Formulary (entrambi InsurancePlan), ogni farmaco è un FormularyDrug (MedicationKnowledge) e ogni voce è un FormularyItem (Basic). Le ricerche della guida vengono servite (Basic?code=formulary-item&formulary=...&drug-tier=...&pharmacy-benefit-type=...&period=..., subject:MedicationKnowledge.code, InsurancePlan?formulary-coverage=..., coverage-type, MedicationKnowledge?code=...&doseform=...) con _include=Basic:subject, Basic:formulary e InsurancePlan:formulary-coverage. È pubblico, senza credenziali, come richiesto da CMS per il formulario di un pagatore: viene servito da un negozio dedicato, in memoria, che contiene solo il formulario e non può quindi accedere al record di un paziente. È di sola lettura. Un farmaco escluso non viene pubblicato, poiché l'API elenca ciò che il formulario copre; RTPB e ePA rispondono comunque come non coperto. Verificato con il validatore HL7 FHIR contro il pacchetto 2.1.0 della guida con terminologia verificata: ogni risorsa generata dal campione non contiene errori.

16.8.2 Beneficio prescrittivo in tempo reale

POST /ncpdp/rtpb accetta un RTPBRequest (NCPDP RTPB v13) con un token API del ruolo operatore e risponde con un RTPBResponse dal formulario: lo stato di copertura, lo stato del formulario, la quota stimata del membro e del piano, e le restrizioni di copertura, con fino a cinque alternative coperte prezzate allo stesso modo. I codici di restrizione e lo stato a cui ogni codice si riferisce seguono le Raccomandazioni di implementazione RTPB pubbliche di NCPDP: 75 autorizzazione preventiva richiesta, 608 terapia a gradini, 76 limiti del piano superati, 7X giorni di fornitura oltre il limite del piano (un farmaco non disponibile per posta, ad esempio), 70 non coperto, tutti *coperti con restrizioni* (CR) tranne 70 (NC). Un membro con un'autorizzazione preventiva approvata in archivio ottiene CC e AB8, come richiesto dalla guida Surescripts, in modo che il prescrittore non debba chiedere di nuovo. Una richiesta che non può essere prezzata è NotProcessed con un codice di rifiuto NCPDP: 52 per un membro non trovato, E7 e 19 per una quantità o fornitura mancante. Il beneficio farmaceutico viene letto dalla richiesta: una fornitura superiore a 34 giorni è una fornitura di tre mesi e il tipo di farmacia M è la posta.

16.8.3 Autorizzazione preventiva elettronica (NCPDP SCRIPT)

POST /ncpdp/script accetta PAInitiationRequest, PARequest, PAAppealRequest e PACancelRequest con un token API del ruolo operatore e risponde a ciascuno con la sua risposta:

L'insieme di domande è il questionario FHIR del farmaco dal negozio FHIR, lo stesso utilizzato da DTR per compilare: un valore booleano diventa una scelta sì/no, una scelta una scelta, un numero un valore numerico, una data una data e qualsiasi altra cosa un testo libero; i gruppi vengono appiattiti in ordine e enableWhen non viene mantenuto, poiché SCRIPT ramifica in base alla scelta e non alle condizioni. Un farmaco senza questionario viene chiesto tre domande a testo libero: la diagnosi, cosa è stato provato e perché questo farmaco. Una PARequest diventa una richiesta Da Vinci PAS: una Claim per il farmaco (RxNorm e NDC), la MedicationRequest che richiede, il paziente, il prescrittore, il pagatore e la copertura, e le risposte come una QuestionnaireResponse, con eventuali allegati come DocumentReference. Viene quindi deciso come ogni autorizzazione preventiva su questo server: il file delle regole, un servizio di decisione (-pas-decider-url), o la coda del revisore, dove viene contrassegnato Farmaco e mantenuto all'interno dei tempi del farmaco. Un servizio di decisione vede una richiesta di farmaco esattamente come vede una richiesta da un client PAS di un sistema di cartella clinica elettronica. Consigliamo Vaglio, il motore di decisione open source (PolyForm Shield) di BioDream, che dispone di politiche per farmaci con terapia a gradini; il motore di un pagatore si collega attraverso lo stesso -pas-decider-url e non ne è necessario uno per il file delle regole e i revisori per decidere.

Una decisione presa dopo che la richiesta è stata risposta (di un revisore, di un appello) viene inviata al prescrittore come un PAResponse o PAAppealResponse non sollecitato, instradato al canale denominato da -epa-reply-channel, che lo consegna alla rete. Senza di esso, o quando la consegna fallisce, il caso afferma che il prescrittore non è stato informato e lo schermo lo invia nuovamente.

Payers › Drugs › Prior authorization invia i messaggi che il sistema di un prescrittore invierebbe al proprio endpoint del server (inizia, risponde alle domande, visualizza la decisione), elenca ogni caso con ciò che il prescrittore è stato informato e visualizza le cifre dei farmaci che CMS-0062-P propone: richieste approvate, negate e in sospeso, appellate e approvate o negate in appello, la media e la mediana delle ore dalla richiesta alla decisione e quanti sono stati decisi in ritardo. I farmaci a beneficio medico richiesti attraverso PAS (un codice HCPCS J con un MedicationRequest o un articolo codificato in RxNorm o NDC) sono conteggiati come farmaci nelle cifre PAS anche.

Cosa si basa questo, espresso chiaramente. Gli schemi e le guide di implementazione di NCPDP sono concessi in licenza. I nomi degli elementi e l'ordine seguito qui seguono le guide companion pubbliche di Surescripts ePA e RTPB e i loro esempi, e le raccomandazioni pubbliche di NCPDP per RTPB. Due elementi che il materiale pubblico non mostra mai sono scritti nel modello SCRIPT utilizzato altrove e dovrebbero essere verificati contro una copia concessa in licenza prima della certificazione: Closed/ReasonCode e Denied/DenialReason. Nessun messaggio è stato verificato contro lo XSD di NCPDP o la certificazione di una rete. Il file di formulari e benefici di NCPDP non viene prodotto: il suo layout completo è nella guida concessa in licenza di NCPDP e un file parziale verrebbe rifiutato dalla rete che lo carica.

16.9 Cosa è stato verificato e contro cosa

Le uscite CARIN e PDex sono state convalidate con il validator ufficiale HL7 FHIR, caricato con i pacchetti pubblicati (hl7.fhir.us.carin-bb#2.2.0, hl7.fhir.us.davinci-pdex#2.2.0): professionale, ricoveri e degenze, e due decisioni PAS, senza errori. Gli input PDex sono stati gli esempi della guida PAS stessa invece delle forme scritte qui per concordare con il convertitore. Il validator ha trovato cinque difetti al primo ciclo — tra cui il fatto che CARIN richiede la versione del profilo in meta.profile e la versione del codice di sistema del tipo di richiesta sulle richieste istituzionali — e ognuno è stato corretto e coperto da un test.

La costruzione di questo ha trovato un difetto più vecchio di esso: il negozio FHIR eliminava ogni elemento che il suo modello interno non dichiarava, quindi una ExplanationOfBenefit perdeva i suoi elementi, le diagnosi, l'addebito e il pagamento durante il percorso di ingresso. Il negozio ora mantiene qualsiasi risorsa che trasporta e un test carica una richiesta CARIN attraverso il server e la legge nuovamente intera.

L'output di CRD - l'ordine aggiornato e la risposta CDS Hooks contro il modello logico di CRD - e l'output del pacchetto DTR convalidano nel validatore ufficiale HL7 contro CRD 2.2.1 e DTR 2.2.0 senza errori.

DTR qui è il lato del pagatore di 2.2.0. $questionnaire-package prende i questionari denominati, quelli denominati da CRD in un ordine, o l'ID di affermazione di copertura restituito da CRD (context, mentre lo stesso processo serve CRD), e restituisce ogni questionario come un pacchetto bundle con una QuestionnaireResponse da compilare, le Libraries che il suo CQL necessita e le loro dipendenze. I set di valori che le sue risposte utilizzano viaggiano nel pacchetto quando vengono caricati (PUT /fhir/ValueSet/{id}), e $expand elenca i loro codici. $log-questionnaire-errors scrive cosa un'app DTR segnala al log del server.

Questionari adattivi: scrivere l'intero questionario una volta, con l'estensione questionnaireAdaptive di SDC e enableWhen sulle domande che si applicano solo a volte. Il pacchetto consegna all'app un guscio vuoto, e ogni chiamata $next-question aggiunge la prossima domanda che si applica alle risposte finora, fino a quando non c'è più nulla da chiedere e la risposta è segnata come completata. L'ordine e la ramificazione sono le regole del pagatore; le domande che non si applicano non vengono mai visualizzate.

Accedere come client: i client DTR e PAS raggiungono il pagatore con i servizi SMART Backend - un JWT firmato scambiato per un token sul server di autorizzazione del pagatore. Puntare Perfuse su quel server con -smart-issuer (e -smart-jwks se il suo indirizzo non si risolve da Perfuse), e passare -smart-backend-services in modo che il documento di scoperta lo dica. La suite Inferno DTR passa in questo modo con Keycloak come server di autorizzazione.

Perfuse può essere quel server di autorizzazione stesso: serve -fhir -smart-clients clients.yaml emette token Backend Services a /auth/token ai client elencati, ogni token con le chiavi pubbliche che utilizza per firmare le sue affermazioni e gli ambiti di sistema che può essere concesso, e l'endpoint FHIR accetta tali token. Non è necessario un server di identità separato per i client machine-to-machine del pagatore.

Con -smart-users users.yaml inoltre, i membri e i clinici si accedono lì per autorizzare le app, che l'API di accesso del paziente necessita: l'app invia la persona a /auth/authorize, si accede, un clinico sceglie il paziente e entrambi visualizzano cosa l'app chiede e possono deselezionare qualsiasi parte di esso. Un membro riceve solo il proprio record, qualsiasi cosa l'app chieda. Ogni persona nel file nomina la risorsa FHIR che è, Patient/… o Practitioner/…, e un hash della password da perfuse smart hash; la password stessa non viene mai scritta.

Le persone possono accedere all'organizzazione del proprio fornitore di identità invece: -smart-oidc oidc.yaml nomina il fornitore (emittente, ID client e dove si trova il segreto), e la pagina di accesso offre "Accedi con" accanto alla password. Ogni persona è collegata dal soggetto del fornitore, oidc_subject nel file degli utenti, quindi il file decide ancora chi può autorizzare le app e quale risorsa FHIR è; un account collegato a nessuno viene rifiutato. I codici, i token di aggiornamento e le revocazioni vengono conservati nel database, quindi un riavvio non disconnette nessuno.

Utenti → App SMART nella console elenca le app registrate e le persone, e aggiunge, modifica e rimuove gli elementi. Ogni salvataggio viene verificato come i file all'avvio, scritto su di essi e utilizzato subito. Un'app confidenziale salvata senza un segreto riceve uno, mostrato una volta; una password viene impostata lì e non viene più mostrata. La rimozione di un'app o di una persona interrompe i token di accesso già emessi per essa o concesso da essa subito, non quando scadono, e i token di aggiornamento con essi.

Gli ambiti possono essere granulari, come SMART App Launch 2 e US Core li definiscono: patient/Observation.rs?category=laboratory legge solo le Observations che la ricerca troverebbe. Una concessione filtrata per un tipo applica il suo filtro a ogni ricerca e a ogni lettura di quel tipo; una concessione non filtrata per il tipo, o per *, la solleva. Un filtro che non può essere letto non concede nulla invece di tutto.

16.10 Decidere le richieste di autorizzazione preventiva: PAS

serve -fhir -pas -crd-rules rules.yaml risponde a Da Vinci PAS 2.2.1 a POST /fhir/Claim/$submit e POST /fhir/Claim/$inquire. Le decisioni provengono dallo stesso file di regole delle risposte di CRD, quindi l'ordine in cui un clinico viene informato che è necessaria l'autorizzazione è deciso dalla regola che lo ha detto:

  - 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

Ogni elemento ottiene un'azione di revisione X12: A1 certificato, A3 non certificato, A4 sospeso, A6 modificato, C annullato (tipo di certificazione 3). Una riga che non nomina un servizio non viene decisa ma risponde con un errore (X12 901 AG, correggere e rinviare). La risposta ripete ciò che una risposta 278 ripete — numeri di tracciamento degli elementi, le date dei servizi richiesti, le date dell'incontro, gli identificatori di trasmissione con mittente e destinatario scambiati — e fornisce a ogni riga il numero di riferimento amministrativo del pagatore. Un servizio che non viene nominato da alcuna regola viene sospeso e non approvato: una decisione che nessuno ha scritto è una decisione per una persona.

Richieste sospese attendono un revisore, che risponde con POST /fhir/Claim/$decide:

{"resourceType": "Parameters", "parameter": [
  {"name": "claimResponse", "valueString": "<the ClaimResponse id>"},
  {"name": "decision", "valueCode": "approve"},
  {"name": "reason", "valueString": "Reviewed with the plan of care."},
  {"name": "reviewer", "valueString": "<the reviewer's NPI>"}]}

decision può anche essere modify: certificato, ma non come richiesto, con quantity (valueDecimal, le unità certificate) e/o alternative (valueCoding, il servizio approvato al posto). La risposta dice quindi A6 Modificato, con il dettaglio certificato o l'alternativa come elemento aggiunto, e un numero di autorizzazione. item (valueInteger, ripetibile) limita la decisione a determinate righe. La decisione diventa una nuova versione della risposta, contrassegnata come esaminata da una persona, e con -fhir-subscriptions viene consegnata sul topic PAS (PASSubscriptionTopic, filtrato per org-identifier, l'identificatore dell'organizzazione richiedente) come il bundle di risposta PAS completo, nella stessa transazione che la registra. $inquire restituisce la risposta corrente a ogni richiesta che il fornitore ha fatto su quel membro; un'altra richiesta di un fornitore non trova nulla. $decide richiede un ambito di scrittura; $inquire è una lettura.

Le richieste e ogni versione delle loro risposte vengono mantenute in pas_requests e pas_responses nel database del server.

16.10.1 La coda del revisore

Nella console web, Payers → CMS-0057 → Reviewer queue elenca le richieste sospese in scadenza più vicina per prime: una richiesta accelerata (Claim.priority stat) scade 72 ore dopo il suo arrivo, una standard 7 giorni. La scelta di una di esse mostra il membro, il fornitore, ogni servizio con le unità richieste e il suo stato, ciò che la risposta ha richiesto e ogni documento ricevuto per esso, con documenti in testo semplice visualizzati in linea. Un editor registra la decisione lì: approvare, rifiutare o modificare (unità certificate o un altro servizio approvato al posto), con un motivo e il numero NPI del revisore. Una modifica deve certificare meno unità di quelle richieste; altrettante o più sono un'approvazione e vengono rifiutate come modifica. Un servizio approvato al posto inizia nel sistema di codici di quello richiesto. È la stessa decisione che $decide prende, quindi la sottoscrizione del fornitore la consegna. La lettura di una richiesta e la decisione su di essa vengono scritte entrambe nel registro di controllo.

Monitor → Team dashboards → Prior authorization mostra, per gli ultimi 30 giorni, quanti richiesti standard e accelerati sono stati decisi entro i tempi previsti dal CMS-0057, decisi in ritardo, ancora in attesa di tempo e scaduti adesso, con il tempo mediano per decidere, e come sono state risposte le richieste di servizi: approvate, modificate, negate o ancora pendenti. Queste due piastrelle vengono lette dalle richieste stesse, quindi non sono nell'esportazione Grafana del dashboard, che lo specifica nella sua descrizione.

16.10.2 Ricezione dei documenti richiesti da una richiesta pendente

Una risposta pendente richiede documenti con un Task e una CommunicationRequest per ogni documento. Un questionario è richiesto come descritto da PAS: una CommunicationRequest con il singolo codice LOINC 102089-0, sotto il numero di traccia della riga per cui è richiesto (itemTraceNumber, che la ClaimResponse echeggia; una riga inviata senza uno ne riceve uno). Quel numero di traccia è il contesto DTR: $questionnaire-package con solo context impostato su di esso restituisce il questionario. Il fornitore invia ciò che è stato richiesto con Da Vinci CDex $submit-attachment (POST /fhir/$submit-attachment): il TrackingId è il numero di traccia della richiesta (il primo identificatore della ClaimResponse, che è anche il Task), o un identificatore della CommunicationRequest, AttachTo è preauthorization, e MemberId deve essere il membro della richiesta. Ogni allegato DocumentReference o QuestionnaireResponse è mantenuto con la richiesta e mostrato al suo revisore; un documento in arrivo decide nulla.

16.10.3 Decisione in un sistema di gestione dell'utilizzo X12

La maggior parte dei pagatori decide le autorizzazioni preventive in un sistema UM che parla X12 278. Con -pas-278-url, Perfuse è il front-end FHIR di quel sistema: ogni $submit viene inviato come una richiesta 278 (005010X217), ogni elemento un evento del paziente. Ognuno trasporta ciò che PAS chiama per esso: il tipo di revisione (extension-serviceItemRequestType, UM01: servizi sanitari, ammissione o assistenza specialistica), il tipo di certificazione (extension-certificationType, UM02), il tipo di servizio, il luogo di servizio (UM04), il livello di servizio (extension-levelOfServiceCode, UM06: elettivo, urgente o di emergenza; una priorità stat sostituisce l'urgente), la data, le date di ammissione e dimissione di una revisione di ammissione, le diagnosi, il fornitore del team di assistenza che eseguirà il servizio e la procedura e la quantità, come servizio professionale (SV1) o, in una richiesta di rimborso istituzionale, una linea di servizio dell'ospedale (SV2). Il codice di azione e il numero di autorizzazione della risposta 278 diventano l'azione di revisione dell'elemento: certificato, in parte o modificato, rifiutato, sospeso, annullato o non considerato (sospeso per un revisore, con i motivi di rifiuto). Le regole locali non vengono consultate.

perfuse serve -fhir -pas -pas-278-url https://um.example/x12/278 -pas-278-receiver ACMEUM \
  -pas-278-token-env UM_TOKEN

Un sistema di gestione dell'assistenza sanitaria che sospende inizialmente e decide in seguito pubblica la sua risposta 278 successiva a POST /fhir/Claim/$decide-278; ogni evento viene abbinato alla sua richiesta dal numero di tracciamento inviato da Perfuse e viene deciso come $decide lo deciderebbe. Se il sistema di gestione dell'assistenza sanitaria non può essere raggiunto o risponde con qualcosa che non è una risposta 278, ogni elemento viene sospeso per un revisore e il fornitore viene informato solo di ciò; il motivo è nel registro del server.

Richieste a cui risponde il sistema UM

Un fornitore di $inquire deve trovare un'autorizzazione però sia stata richiesta: per fax, attraverso il portale del pagatore, per telefono o in un 278 che un altro mittente ha inviato. Perfuse conserva solo le richieste che sono state inviate attraverso di esso; il sistema UM le conserva tutte. Quindi con un sistema UM che risponde in tempo reale (ogni trasporto tranne sftp), ogni $inquire viene anche inviato lì come una richiesta di autorizzazione 278 (005010X215: BHT02 28, il membro, il fornitore, il numero di autorizzazione dal insurance.preAuthRef della richiesta quando è presente e le date di evento da billablePeriod o le date di servizio degli elementi, altrimenti un anno prima o dopo oggi). Ogni autorizzazione che la risposta contiene che Perfuse non ha (abbbinata ai numeri di traccia che ha inviato e ai numeri di autorizzazione che ha già fornito) torna come un'altra raccolta di risposte di richiesta di autorizzazione: la decisione del sistema UM per ogni linea di servizio, il numero di autorizzazione e il periodo e una nota che indica dove è stata trovata. Nessuna richiesta di autorizzazione viene creata per un'autorizzazione che nessuno ha inviato in FHIR: la sua ClaimResponse.request contiene un motivo di assenza di dati, come consente il profilo PAS. Una richiesta di autorizzazione legge solo; nulla nei registri di Perfuse cambia. Se il sistema UM è disattivato o risponde con un TA1 o 999, il fornitore ottiene ciò che Perfuse conserva e lo stato del collegamento indica il motivo. La forma segue le guide di accompagnamento della richiesta 278 che UnitedHealthcare, Cigna e Blue Cross Blue Shield of Massachusetts pubblicano; non è stato provato contro un sistema UM reale.

Come i 278 raggiungono il sistema UM

La guida alla connettività del sistema UM dice come accetta i 278 e -pas-278-transport (Impostazioni, Payer, Collegamento gestione dell'utilizzo) lo segue:

Un certificato client è -pas-278-cert e -pas-278-key; -pas-278-ca si fida di un'autorità di certificazione del payer. OAuth è -pas-278-oauth-token-url, -pas-278-oauth-client-id e il segreto, recuperato con la concessione client-credentials e mantenuto fino a un minuto prima della scadenza. Le password, i token e i segreti non sono mai flag: ogni nome è un nome di variabile d'ambiente (-pas-278-password-env, -pas-278-token-env, -pas-278-oauth-secret-env, -pas-278-sftp-password-env), o digitato nello schermo delle impostazioni, dove viene mantenuto nel file delle impostazioni (leggibile solo dall'account del server) e non viene più mostrato.

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

Su SFTP ogni richiesta viene messa in attesa fino all'arrivo della risposta: la risposta 278 decide gli elementi e Perfuse mette un 999 di accettazione nella cartella in uscita. Un file che non può essere letto rimane nella cartella in entrata per una persona e viene offerto nuovamente alla prossima lettura.

Quando il sistema UM non può leggere una richiesta

Un sistema UM che non può leggere un 278 risponde con un TA1 (la busta) o un 999 (la transazione) invece di una decisione. Perfuse legge quale e cosa dice, mette in attesa ogni elemento ("la gestione dell'utilizzo non può leggere la richiesta") e lo registra. Payer, CMS-0057, coda del revisore mostra il collegamento: cosa è stato inviato negli ultimi sette giorni, ogni scambio con il suo numero di controllo e cosa ne è stato (risposto; riconosciuto, risposta in arrivo; rifiutato, con il segmento, l'elemento e il codice del 999; non raggiunto). Ogni scambio ha il proprio numero di controllo, uno più dell'ultimo, che è ciò che un TA1 o un 999 nomina quando risponde.

16.10.4 Decisione sulla base delle prove cliniche, con un servizio di decisione

Un file di regole decide in base al codice di servizio: un codice non richiede autorizzazione, non è coperto o va a un revisore. Se questo paziente soddisfa i criteri per esso è una domanda diversa, risposta dalle condizioni, dalle risposte ai questionari e dai documenti che il fornitore ha inviato con la richiesta. Con -pas-decider-url, ogni elemento che le regole lasciano a un revisore viene inviato a un servizio di decisione, come Vaglio, che legge lo stesso bundle di richiesta PAS attraverso il pacchetto pas pubblicato da Perfuse. Un Vaglio pubblico, su richieste inventate solo, viene eseguito accanto all'istanza di test di Perfuse all'indirizzo https://vaglio.perfuse.health:8443 (accedi come demo, password try-vaglio-demo; può guardare tutto e non modificare nulla): ogni decisione lì ha la sua prova, una lettera in linguaggio semplice e una ricevuta che chiunque può verificare.

perfuse serve -fhir -pas -crd-rules payer-rules.yaml -pas-decider-url https://vaglio.example/api/pas/decide \
  -pas-decider-token-env VAGLIO_TOKEN

L'URL deve essere https o http semplice per questa macchina (localhost, 127.0.0.1), poiché trasporta il record di un paziente e il token. Vaglio stesso risponde solo su https; quando utilizza un certificato dalla propria autorità, passare quell'autorità con -pas-decider-ca DATA/tls/ca.crt (o qualsiasi autorità interna del pagatore da cui proviene il certificato del servizio). Il servizio riceve la richiesta Bundle come l'ha inviata il fornitore, POST <url>?item=<sequence> (application/fhir+json), e risponde con {"decision": "approve" | "deny" | "pend", "why": "...", "requested": ["..."]}, o 404 quando non decide nulla per quell'elemento, il che lascia la risposta delle regole in piedi. why è la nota di processo della risposta e è obbligatoria per un rifiuto, che altrimenti è rinviato; requested è detto al fornitore come informazione di cui ha bisogno una richiesta rinviata. Un rinvio può anche trasportare "questionnaire": "<canonical>" e "attachments": ["<LOINC>", ...], che vengono richiesti nella risposta CDex Task e CommunicationRequests oltre a qualsiasi questionario o allegato DTR richiesto dalla regola (il questionario della regola vince, poiché un Task ne richiede uno; un codice che non ha la forma di LOINC viene scartato e registrato). Una regola che approva o rifiuta è la politica di copertura del pagatore e non viene inviata al servizio. Un errore, un timeout o una risposta che non è una delle tre decisioni rinviato l'elemento per un revisore, con il motivo nel registro del server: nulla qui trasforma un errore in un'approvazione. Non può essere combinato con -pas-278-url, dove il sistema di gestione dell'utilizzo risponde a ogni elemento.

Consiglio prima di inviare. Con -crd-advisor-url accanto a -crd-rules, CRD chiede anche a un servizio di decisione cosa sarebbe detto a una richiesta di autorizzazione preventiva per ogni ordine che ne ha bisogno, e mostra la risposta come un'altra carta: "Prima di inviare: una richiesta per questo avrebbe bisogno di: ...", o "sarebbe approvata", con ciò che è ancora necessario, il questionario che lo chiede e cosa lo approverebbe. Vaglio risponde a /api/pas/advise, con lo stesso token e autorità di sopra:

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 invia POST <url> con {"service": {"system": "...", "code": "..."}, "resources": [ ... ]}, le risorse essendo il prefetch dell'uncino (il paziente per primo, la copertura omessa), e legge {"decides": true, "answer": "approve" | "pend" | "deny", "summary": "...", "missing": [...], "questionnaire": "...", "toApprove": [[...]], "policyTitle": "..."}. È un consiglio e non modifica nulla: le informazioni sulla copertura, le altre carte e la decisione del PAS sono ciò che dicono le regole. Aspetta al massimo tre secondi e nessuna risposta, un errore o "decides": false lascia la risposta esattamente com'è senza di essa. Perfuse non ha mai bisogno di un servizio di decisione.

La richiesta trasporta X-PAS-Request-Id, l'id per cui la risposta è conosciuta. Un servizio con i propri revisori che rinviato un elemento può inviare la propria decisione in seguito come quella di qualsiasi revisore: Claim/$decide con quell'id come claimResponse, la sequenza dell'elemento e la decisione e il motivo. La sottoscrizione del fornitore lo consegna come se fosse stato fatto nella coda del revisore.

Una sottoscrizione con contenuto id-only dice al fornitore quale risposta è cambiata senza dire cosa sia: il focus della notifica è Bundle/<id>. GET /fhir/Bundle/<id> restituisce l'ultimo bundle di risposta PAS, GET /fhir/Bundle/<id>/_history/<n> la versione di una notifica inviata, e GET /fhir/ClaimResponse/<id> il ClaimResponse solo. Un token legato a un paziente viene detto che non esiste, come per qualsiasi record al di fuori del suo paziente.

Verificato con la suite ufficiale Inferno PAS Server v2.2.1 (vedi verifica). Non inviato, anche se PAS lo segna come supporto obbligatorio: ClaimResponse.adjudication con un'azione di revisione, ClaimResponse.extension:authorizedProvider e ClaimResponse.item.extension:communicatedDiagnosis, perché le estensioni di cui hanno bisogno non sono consentite lì dal proprio contesto in PAS 2.2.1 e il validator rifiuta una risposta che le trasporta; e request.extension:DataAbsentReason, perché Perfuse sa sempre la richiesta. I 278 inviati a un sistema di gestione dell'utilizzo (sopra) vengono verificati contro gli esempi di richiesta di PAS 2.2.1, gli esempi di esMD 278 pubblicati da CMS e un controllore 278 scritto da guide di accompagnamento pubbliche, e ogni trasporto contro un sistema UM sostitutivo scritto dalle Regole di connettività CAQH (vedi verifica); non ancora contro un sistema UM reale o un clearinghouse, e non certificato CORE. Non implementato: allegati inviati indietro con CDex.

Un file di regole viene controllato contro le invarianti di CRD quando viene caricato: un questionario necessita di documentazione, un servizio che non è coperto non può necessitare di autorizzazione, satisfied appartiene a un caso e non a una regola, e qualsiasi cosa condizionale deve fornire un motivo.

Non verificato: le esportazioni e l'abbinamento dei membri contro l'implementazione di un altro pagatore, le metriche contro le figure pubblicate di un pagatore, e CRD contro un client CDS Hooks di un EHR reale.

16.11 Invio di richieste di autorizzazione preventiva a un pagatore (per i fornitori)

Tutto ciò che è stato detto sopra risponde alle richieste, come un pagatore. Il lato di un fornitore è l'opposto: un'app EHR o un'app DTR costruisce un bundle di richiesta Da Vinci PAS e qualcosa deve inviarlo al pagatore, conservare la risposta e passarla. Una destinazione pas fa questo.

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

Ogni messaggio deve essere una richiesta PAS completa Bundle su un canale grezzo. Perfuse la invia invariata a {payer}/Claim/$submit: il pagatore decide sulla richiesta di rimborso insieme al paziente, alla copertura e alle risorse di supporto nel Bundle, e una richiesta di rimborso ricostruita da un riassunto perderebbe queste informazioni. Fuori da questa macchina l'indirizzo del pagatore deve essere https.

Una decisione è una richiesta consegnata, indipendentemente da cosa dice. Un'approvazione, un rifiuto e una sospensione sono tutti registrati e nessuno di essi viene ritentato, perché ritentare un rifiuto sottopone due volte la stessa richiesta. Ciò che fallisce la consegna e viene ritentato è un pagatore che non ha preso una decisione: uno stato di errore, un OperationOutcome (il cui testo è l'errore) o un ClaimResponse il cui esito è error. La decisione viene letta voce per voce dai codici di azione di revisione del PAS (X12 306: A1 approvato, A2 parzialmente, A3 rifiutato, A4 sospeso, A6 modificato); una risposta senza codice viene elencata come "nessun codice di decisione" piuttosto che considerata come un'approvazione. Un rifiuto senza motivo in nessun luogo viene rifiutato in quanto non soddisfa CMS-0057.

La risposta del pagatore è la risposta della destinazione, quindi Ispeziona la risposta può giudicarla e results_to la consegna a un altro canale. Ogni richiesta è elencata in CMS-0057, Richieste inviate ai pagatori: quando è stata inviata, il paziente, il servizio, la decisione e il riferimento del pagatore (preAuthRef), che un'indagine successiva nomina. L'elenco viene conservato in prior-auth.json accanto al database (al massimo 10.000 richieste; le decisioni più vecchie vengono eliminate per prime, una richiesta in sospeso non lo fa mai) e ogni tenant vede solo il proprio.

Verificato contro l'implementazione di riferimento HL7 Da Vinci PAS per pagatori (immagine docker hlseven/davinci-prior-auth): una richiesta inviata attraverso un canale in esecuzione viene messa in attesa da esso con il suo riferimento e la risposta appare sullo schermo (vedi verifica). Non ancora provato contro un pagatore di produzione. Non costruito: seguire una richiesta in attesa con $inquire, o ricevere la risposta successiva del pagatore tramite abbonamento; un canale può fare entrambe le cose oggi con una destinazione http o fhir.

16.12 Reti allineate con CMS

Il CMS Interoperability Framework (CMS Health Technology Ecosystem) chiede alle reti di dati sanitari di auto-attestare a 26 criteri e di essere elencate come reti allineate CMS; EHR, fornitori, pagatori e app si connettono a loro. I criteri dal 13 al 16 sono in vigore dal 4 luglio 2026: API FHIR su US Core con un CapabilityStatement completo e Bulk Data, documenti come allegati FHIR leggibili dall'uomo, notifiche di appuntamento e incontro tramite FHIR Subscription, e un localizzatore di record.

Amministra › Rete allineata CMS elenca ogni criterio con ciò che Perfuse fornisce per esso e dove si trova questo server: letto da ciò che è attivato qui:

Ciò di cui hanno bisogno i quattro in vigore da questo server:

Lo schermo è un foglio di lavoro per l'attestazione, non una certificazione: CMS esamina le reti che sospetta non soddisfino i criteri, e il testo del framework stesso è l'autorità. Non costruito oggi: query di lacune di qualità aperte (criterio 8), query di un pagatore per i dati di incontro di una richiesta di rimborso (9), segnalazione delle metriche delle query al National Provider Directory (19), controllo dei fornitori contro quel directory (6), lettura delle patenti di guida mobili o delle carte di assicurazione digitali (3, 23), e applicazione di una politica di consenso generale su ogni lettura (5). L'identificazione IAL2 è del servizio di identità; Perfuse accetta i token di quello che si sceglie.

17 Sicurezza

Perfuse gestisce dati clinici. Questo capitolo descrive cosa fa al riguardo e cosa lascia a voi.

17.1 Sicurezza del trasporto

TLS sull'interfaccia web è configurato con -tls-cert e -tls-key. Senza di essi l'interfaccia è HTTP semplice, che è accettabile su un indirizzo di loopback per un primo sguardo e da nessun'altra parte — trasporta credenziali e contenuto del messaggio, entrambi leggibili sul filo.

TLS sui trasporti del canale è per sorgente e per destinazione, sotto un blocco tls. Le impostazioni disponibili sono nelle sorgenti e destinazioni di riferimento.

insecure_skip_verify accetta qualsiasi certificato. Esiste perché i sistemi ospedalieri presentano regolarmente certificati che non verificano e rifiutare di connettersi significherebbe rifiutare di integrare. È denominato per essere vistoso e utilizzarlo significa che la connessione è crittografata ma non autenticata — si ha protezione contro l'intercettazione passiva e nessuna contro un server interposto.

17.2 Autenticazione e ruoli

Gli utenti sono memorizzati nel database. Ognuno ha uno dei cinque ruoli e ogni ruolo include tutto ciò che è incluso nei ruoli sopra di esso:

Un sesto ruolo, Piattaforma, appartiene a chi esegue un server condiviso: crea tenant e imposta i loro limiti e non possiede canali propri.

Monitor è per un help desk o per uno schermo operativo su un muro: tutto ciò che è necessario per vedere che un feed si è interrotto e nulla che nomina un paziente. Viewer può leggere il contenuto dei messaggi, che sono dati clinici; è un ruolo a basso privilegio per la *configurazione*, non per la privacy. Operator separa la correzione di una consegna fallita di notte dal cambiamento di ciò che un feed fa: la persona che rinviene non deve essere in grado di riscrivere il canale.

17.2.1 Password errate ripetute

Le password errate e i tentativi di accesso con passkey falliti vengono conteggiati per l'indirizzo da cui proviene la connessione, e dopo alcuni tentativi consecutivi quell'indirizzo deve attendere prima di poter riprovare (la risposta è 429, con Retry-After). Gli account non vengono bloccati per nome, perché ciò permetterebbe a chiunque di bloccare un amministratore di proposito.

L'indirizzo è quello della connessione stessa, mai quello che una richiesta afferma in X-Forwarded-For, che il mittente scrive. Dietro un proxy inverso sulla stessa macchina Perfuse utilizza l'ultimo elemento X-Forwarded-For invece, quello aggiunto dal proxy, in modo che ogni client venga ancora conteggiato separatamente. Un proxy su un'altra macchina raggiunge Perfuse da un solo indirizzo e tutti i suoi client condividono un solo conteggio: è necessario limitare la frequenza degli accessi anche a quel proxy.

17.2.2 Gruppi di canali

Una persona (o un token API) può essere limitata a alcuni gruppi di canali: possono quindi visualizzare e agire solo sui canali il cui group è uno dei loro. Questo è l'assetto di un gruppo ospedaliero su un server, gli analisti di ogni struttura che si occupano dei propri feed e un team centrale, senza limiti, che si occupa di tutti. Rhapsody lo chiama un locker.

Il limite si applica ovunque contemporaneamente, perché è applicato alla richiesta piuttosto che ricordato da ogni schermo: l'elenco dei canali, il dashboard e la mappa di flusso, i messaggi e la loro ricerca, i conteggi e i grafici, la coda, gli avvisi, le metriche, i certificati, i contratti e l'utilizzo dei set di codici. Un canale al di fuori dei gruppi di una persona non esiste per loro; chiedere il suo nome risponde *non trovato*, quindi il suo nome non è confermato. Un canale senza gruppo è visibile solo alle persone senza limite.

Salvare un canale lo mantiene all'interno dei gruppi di una persona: non possono creare un canale in un altro gruppo o spostarlo fuori dal proprio. Ciò che ogni struttura condivide - tabelle di codici, librerie di script, decisioni di autorizzazione preventiva - possono leggerle ma non modificarle. Le cifre a livello di server (autorizzazione preventiva, utilizzo di token, tunnel) sono mostrate solo alle persone senza limite e così sono le metriche e gli avvisi relativi all'intero server piuttosto che a un canale.

Un amministratore limitato ai gruppi è l'amministratore della struttura stessa. Gestisce le persone e i token dei propri gruppi, avvia e ferma i canali e svuota le code. Un collega che aggiunge ottiene i gruppi a meno che non ne specifichi alcuni, non può dare un gruppo che non possiede e non vede mai o modifica nessuno senza limite. Tutto il resto che un amministratore può fare cambia l'intero server - impostazioni, accesso, riavvio, regole di avviso, branding, flotta, il server SMART - e gli viene rifiutato.

I gruppi sono impostati in Utenti (e per i token in Token), come elenco separato da virgole. Ogni modifica è registrata nel registro di attività e ha effetto alla prossima richiesta della persona.

Un ruolo diverso in ogni gruppo

Una persona può avere un ruolo diverso in ogni gruppo: lab=editor, adt in Utenti modifica i canali del laboratorio e ha il ruolo scelto accanto ad esso - ad esempio visualizzatore - in quelli delle ammissioni. Vedono i canali di entrambi i gruppi su ogni schermo. Salvare, avviare o rinviare uno in un gruppo in cui il loro ruolo è troppo basso viene rifiutato con il ruolo che detengono lì; non finge che il canale sia mancante, poiché possono vederlo. Il loro ruolo in alto sullo schermo è il più forte che detengono, che apre gli schermi che quel ruolo utilizza, e ogni azione su quegli schermi è ancora limitata ai gruppi in cui lo detengono.

Solo le persone limitate ai gruppi di canali possono averne uno. Qualcuno che vede ogni canale ha un solo ruolo, perché "editore dei canali del laboratorio" per una persona senza limite sarebbe editore di tutto ciò che appartiene a nessun gruppo e delle pagine a livello di server. Un amministratore della struttura può dare un ruolo per gruppo solo nei gruppi che amministra e mai al di sopra del proprio ruolo lì.

17.3 Chi può chiamare l'endpoint FHIR

L'endpoint FHIR (serve -fhir) controlla uno di due tipi di token:

• Token API Perfuse, creati in Utenti → Credenziali macchina o con perfuse token create. Ognuno ha un ruolo e può essere

limitato ai Gruppi FHIR. Questo è l'impostazione predefinita quando non è configurato un server di autorizzazione SMART.

• Token di accesso SMART, dal server di autorizzazione di Perfuse (-smart-clients) o da uno esterno (-smart-issuer). Ognuno

trasporta ambiti, e l'endpoint tiene ogni richiesta ad essi.

Con SMART configurato, vengono accettati solo token SMART, quindi ogni chiamante è soggetto ai suoi ambiti. Un token API ha un ruolo e non ha ambiti: un token viewer può leggere il record di ogni paziente. Un pagatore che ha attivato SMART per limitare ogni app a ciò che è stato concesso non dovrebbe avere un modo per accedere che non sia limitato.

Alcuni siti necessitano di entrambi - un feed di richieste interne che tiene un token API e non ha un client SMART, accanto ad app di membri che si connettono tramite SMART. Per quelli, Impostazioni → FHIR → Accetta token API Perfuse accanto ai token SMART (-fhir-api-tokens all'avvio) consente ai token API di accedere anche. È disattivato per default, ha effetto sulla prossima richiesta in entrambe le direzioni e il cambio è scritto nel registro di audit. Un token è distinto dalla sua forma: un token SMART è un JWT firmato, e un token API non lo è mai, quindi uno non viene mai controllato come l'altro. Dove possibile, fornire a un tale sistema un client SMART Backend Services con solo gli ambiti di sistema di cui ha bisogno.

17.3.1 Un endpoint FHIR aperto a sconosciuti

Un server di test pubblico fornisce credenziali che possono scrivere, poiché il test della precedente autorizzazione o delle iscrizioni richiede scritture. Due limiti impediscono a un client di rovinare tutto per tutti, entrambi sotto Impostazioni → FHIR e entrambi disabilitati per impostazione predefinita:

• Scrive un minuto da un client (-fhir-writes-per-minute): crea, aggiorna e cancella da un indirizzo client. Oltre ad esso, una

scrittura viene risposta 429 con Retry-After: 60. Le letture e le ricerche, incluse le ricerche tramite POST, non vengono mai conteggiate.

• Risorse più tenute (-fhir-max-resources): superato questo limite, nuove risorse vengono rifiutate con 507, mentre aggiornamenti e cancellazioni continuano a funzionare.

L'endpoint di un ospedale non necessita di nulla di tutto ciò.

17.4 Agenti di intelligenza artificiale: il server MCP

Con Impostazioni › Sicurezza › Agenti AI (MCP) attivato (o serve -mcp), Perfuse serve il Model Context Protocol a /mcp, in modo che un agente AI come Claude, ChatGPT o un assistente IDE possa chiedergli cosa sta succedendo. È disattivato per default e spegnendolo si ferma ogni agente alla sua prossima chiamata.

Un agente si connette con un token API da Amministra › Utenti › Credenziali macchina come token bearer, mai con una sessione del browser di una persona (questo viene rifiutato, quindi un agente non agisce mai con l'accesso completo di una persona). Una configurazione del client sembra:

{ "mcpServers": { "perfuse": { "type": "http", "url": "https://perfuse.example/mcp",
    "headers": { "Authorization": "Bearer <token>" } } } }

Ogni strumento risponde alla stessa route o alla ricerca FHIR di uno schermo di una persona, chiamata con il token dell'agente, quindi il ruolo del token, i gruppi di canali e l'inquilino decidono cosa vede, esattamente come fanno nella console; e fhir_search ottiene l'accesso del token sul endpoint FHIR (che potrebbe rifiutare i token API; vedere la sezione FHIR sopra). Un agente viene offerto solo gli strumenti che il suo token può utilizzare. La lettura è l'impostazione predefinita: uno strumento che modifica qualcosa richiede anche l'ambito mcp:write del token ("Consenti a un agente AI di agire con esso" quando si rilascia il token), quindi un token rilasciato per un agente di reporting non può essere indotto ad agire da un prompt. Le risposte di un token di monitoraggio hanno i contenuti dei messaggi rimossi, qualunque cosa restituisca una route.

Ogni chiamata è registrata in Activity come mcp.tool con il nome del token, lo strumento, i suoi argomenti e l'esito (ok, refused, invalid, rate-limited o lo stato HTTP); mcp.connect registra quale client si è connesso. Ogni token può effettuare 60 chiamate di strumenti al minuto (Chiamate di strumenti al minuto da un token); superato questo limite, una chiamata restituisce un errore che l'agente può leggere e nulla viene eseguito. Una richiesta da una pagina del browser su un'altra origine viene rifiutata, che MCP chiede a un server di interrompere il rebinding DNS. Il trasporto è lo Streamable HTTP di MCP, risposto come JSON senza stream di eventi; sono accettate le versioni del protocollo 2025-06-18, 2025-03-26 e 2024-11-05. I messaggi e le risorse FHIR contengono dati dei pazienti: le risposte di un agente vanno al modello su cui viene eseguito, quindi assegnare un token a un agente solo dove quel modello è autorizzato a visualizzarli e assegnargli il ruolo più basso che svolge il lavoro.

17.5 Un account di dimostrazione

serve -demo-account demo:PASSWORD crea un account condiviso per un server di dimostrazione pubblica, e la pagina di accesso mostra il suo nome utente e la password con un pulsante che si accede con essi. L'account è un visualizzatore, quindi può visualizzare tutto e modificare nulla. A differenza di qualsiasi altro visualizzatore, può anche aprire gli schermi degli amministratori (utenti, token macchina, impostazioni, protezione dei dati, i peer della flotta), in modalità sola lettura: una dimostrazione è giudicata dai suoi schermi. Li legge come un visualizzatore legge i canali, con ogni credenziale mostrata come impostata o meno, mai il suo valore, e ogni modifica rifiutata. Può anche premere i controlli che non modificano nulla e non raggiungono nulla all'esterno del server: un controllo di script e convalida e analisi dell'editor di canale. Non può modificare la sua password o aggiungere una chiave di accesso, perché il primo visitatore a farlo bloccerebbe tutti gli altri dopo di lui. Ogni avvio lo ripristina come visualizzatore con la password pubblicata. La password deve essere di almeno 12 caratteri, come qualsiasi altra. Utilizzarlo solo su un server che contiene dati di test: chiunque legge la pagina di accesso può leggere ogni messaggio sul server.

17.6 Registro di controllo

I cambiamenti di configurazione, gli accessi e l'accesso al contenuto dei messaggi vengono registrati con chi, cosa e quando.

Il registro di controllo si trova nello stesso database dei messaggi. Ciò è comodo ed è una limitazione: qualcuno che può modificare il database può modificare il registro di controllo. Se le tue esigenze includono un registro di controllo a prova di manomissione, il registro deve essere inviato da qualche parte in modalità solo aggiunta, e l'output del registro di Perfuse è il modo per farlo.

17.7 Segreti nella configurazione

Le password, i codici di accesso e le chiavi appaiono nella configurazione del canale, il che significa che sono presenti nei file YAML.

Due conseguenze. I file necessitano di autorizzazioni del file system che riflettono il loro contenuto e, se sono sotto controllo versione — il che è comunque consigliato — il repository contiene credenziali e deve essere trattato di conseguenza.

Quando un valore è un segreto, l'interfaccia lo visualizza come segreto e l'API non lo restituisce una volta salvato. Ciò lo protegge dall'essere letto sulla spalla di qualcuno o divulgato in uno screenshot. Tuttavia, non protegge il file.

17.8 Ciò che è nel database

Il message store conserva i messaggi come ricevuti, il che per un flusso clinico significa dati identificativi dei pazienti. Dovrebbe essere su un archiviazione crittografata, salvato come dati clinici con la conservazione che ne consegue e controllato dall'accesso al livello del file system nonché attraverso i ruoli propri di Perfuse.

cleanup.periodDays limita quanto a lungo viene conservato. Vedere il message store per la tensione tra questo e avere abbastanza storia per l'avviso ritmico.

17.9 Protezione dei dati (GDPR e UK GDPR)

Lo schermo Protezione dei dati (Amministra, solo amministratori) risponde alle richieste di una persona ai sensi del GDPR e del GDPR del Regno Unito. Non decide nulla per conto del titolare del trattamento: se una richiesta deve essere accolta e se si applica un'esenzione, è una decisione del titolare del trattamento, registrata con la richiesta.

Trovare cosa è memorizzato. Una persona è identificata da identificatori: system|value (un numero NHS, un MRN con l'autorità di assegnazione) o un numero da solo. Con un indice dei pazienti, questi si estendono a ogni numero di ogni record collegato alla stessa persona, quindi una richiesta che cita un numero di ospedale trova i record archiviati con gli altri. Visualizzare cosa è memorizzato cerca quindi in ogni archivio che memorizza dati dei pazienti:

Cosa non può raggiungere dice: tracce inviate a un collector (-trace-endpoint), il log di audit (conservato: è il record di chi ha fatto cosa, inclusa questa richiesta), e le copie di backup.

Richieste. Una richiesta è registrata con il suo tipo (accesso, Articolo 15; portabilità, Articolo 20; cancellazione, Articolo 17; limitazione, Articolo 18), chi la fa in base ai record del controller, gli identificatori e una nota (come è stata confermata l'identità, un'estensione e il suo motivo). Deve essere eseguita entro un mese dalla ricezione (Articolo 12(3)); una richiesta in ritardo è mostrata in rosso.

• Accesso e portabilità: Scarica la copia fornisce un file zip: ogni messaggio come ricevuto con il suo record, ogni risorsa FHIR con ogni versione memorizzata, le richieste di autorizzazione precedenti e le loro risposte, e i record dell'indice dei pazienti, tutto in formato JSON, con un file README che spiega cosa rappresenta ogni parte. Segna come risposto chiude la richiesta.
• Cancellazione: un secondo amministratore approva la richiesta (chi l'ha registrata non può farlo). Cancella ora elimina tutto ciò che è stato trovato: messaggi interi (record, corpo, consegne, identificatori, allegati che non vengono utilizzati da altri messaggi), consegne in coda (non vengono inviate), le risorse FHIR con la loro storia, le richieste di autorizzazione precedenti con le loro risposte, allegati e numeri di tracciamento, e la persona nell'indice dei pazienti con ogni record collegato e la sua storia (un evento registra che una cancellazione è avvenuta e da parte di chi).
• Restrizione: registrata come una richiesta di blocco legale, in modo che nulla venga cancellato o scada mentre dura.
• Rifiuta chiude una richiesta con il suo motivo, che deve essere comunicato alla persona.

Una richiesta chiusa conserva solo gli ultimi caratteri dei numeri della persona: rimane come record di una risposta senza essere un'altra copia di essi. Ogni passaggio è nel log di audit con i numeri mascherati.

Blocco legale. Un blocco nomina una persona tramite identificatori, con il suo motivo e una data di fine opzionale. Finché è in vigore, una cancellazione viene rifiutata direttamente, e la finestra di conservazione dell'archivio dei messaggi risparmia i messaggi della persona (record e corpi) fino a quando il blocco non viene revocato.

Copie di backup e registro di cancellazione. Una copia di backup creata prima di una cancellazione conserva ancora ciò che è stato cancellato fino a quando non scade. Ogni cancellazione viene scritta in un registro: quando, da chi, approvata da chi, quanto è stato rimosso da ogni archivio, e gli identificatori della persona come hash SHA-256 salati invece che in chiaro. Dopo aver ripristinato una copia di backup, Applica nuovamente le cancellazioni hash gli identificatori che gli archivi ripristinati contengono con ogni voce del sale ed elimina ogni persona che il registro nomina. I numeri brevi possono essere trovati dai loro hash provando ogni valore, quindi il registro è esso stesso un dato personale e viene conservato con la protezione del database.

Ritenzione. Lo schermo elenca per quanto tempo ogni tipo di record viene conservato qui e cosa lo modifica: record e corpi dei messaggi in base alle loro finestre di ritenzione, la coda fino a quando non viene consegnata o rimossa, l'archivio FHIR, richieste di autorizzazione precedenti e l'indice dei pazienti fino a quando non vengono cancellati (i record clinici non vengono eliminati secondo una programmazione), il registro di controllo conservato.

Record di elaborazione (Articolo 30). Record di elaborazione scarica, in formato Markdown o CSV, cosa questo server sa di esso: il controller, l'ufficiale per la protezione dei dati e dove i dati vengono conservati (Impostazioni → Dati → Protezione dati), la conservazione di ogni tipo di record, e un'attività di elaborazione per canale con cosa riceve, da dove, a quali destinazioni, e gli host a cui invia. Gli scopi, le basi giuridiche e le categorie di soggetto dei dati vengono lasciati al controller per compilarli, e dirlo. Una cella CSV che inizia con =, +, - o @ viene scritta con un apostrofo iniziale, in modo che una cartella di lavoro non lo esegua.

Dove vengono conservati i dati. Dove vengono conservati i dati (Impostazioni → Dati → Protezione dei dati) afferma, in parole che un regolatore può verificare, dove il server, il suo database e i suoi backup vengono eseguiti; lo schermo di protezione dei dati e il record lo mostrano. Un progetto di accordo di elaborazione dei dati per le organizzazioni BioDream che ospita si trova in docs/legal/dpa-template.md; è un progetto per un avvocato, non un consiglio legale.

L'API è /api/privacy (riassunto), /api/privacy/find, /api/privacy/requests (e /{id}/approve, /{id}/export, /{id}/erase, /{id}/close), /api/privacy/holds, /api/privacy/reapply e /api/privacy/register.

17.10 Tenant

Un tenant è un limite di isolamento: canali, messaggi, utenti e impostazioni appartengono a uno e nulla li attraversa.

Esiste per un fornitore di servizi che esegue feed per più studi. Non utilizzarlo per separare i dipartimenti all'interno di un'organizzazione che devono vedere il traffico degli altri: l'isolamento è reale e non esiste una visualizzazione tra inquilini. Per questo, utilizzare i gruppi di canali (sopra), che dividono le persone di un'organizzazione consentendo a un team centrale di vedere tutto.

17.10.1 Limiti

Un operatore di piattaforma imposta i limiti di ogni tenant in Tenants, in modo che un cliente non possa occupare tutto lo spazio di un server condiviso. Lasciare un limite vuoto per non impostarne nessuno.

• Canali: quanti canali il tenant può avere. La creazione di uno in più viene rifiutata, con il conteggio e il limite.
• Messaggi al minuto: quanti messaggi i suoi canali possono ricevere insieme in un minuto.
• Archiviazione: quanti contenuti di messaggi archiviati può conservare, in megabyte.

Nessuno di loro perde un messaggio. Oltre la velocità o il limite di archiviazione, un messaggio ricevuto viene rifiutato nel modo in cui un ricevitore occupato rifiuta uno, prima che qualcosa venga archiviato o consegnato: MLLP non riceve un acknowledgement (non un rifiuto, che alcuni mittenti considerano come "non rinviare"), HTTP riceve 429 con Retry-After, SOAP riceve 503, DICOM riceve uno stato ripetibile e una coda, un bucket o un file rimane dove si trovava. Il mittente rinvia, come fa ogni motore di integrazione e ogni sistema di cartella clinica. Nulla di ciò che è già stato archiviato viene cancellato per fare spazio. Un limite aumentato ha effetto entro un minuto e ogni modifica dei limiti viene registrata nel registro di attività.

17.11 Dati di test

I messaggi generati descritti in testing esistono in parte come controllo della privacy. Riprodurre un problema altrove, inviare un esempio a un fornitore o popolare un ambiente di test sono tutte cose che altrimenti vengono fatte con messaggi reali.

L'output del generatore non contiene dati del paziente per costruzione piuttosto che per oscuramento. Preferirlo ai messaggi reali sfrondati a mano, che è un processo che può essere fatto in modo incompleto e di solito lo è.

17.12 Accesso singolo

Tre meccanismi e account locali accanto a tutti loro.

OpenID Connect (-oidc), un directory su LDAP (-ldap) e SAML 2.0 (-saml). Ognuno di essi è configurato da Amministra → Accesso e scritto nel file che il flag nomina, quindi lo schermo e il file sono due visualizzazioni di una sola cosa piuttosto che due posti da mantenere allineati.

Gli account locali sono sempre disponibili e non possono essere disattivati. Ciò è deliberato: un motore di integrazione locale il cui unico modo di accesso è un fornitore di identità diventa irraggiungibile proprio quando il fornitore di identità è irraggiungibile, e un'interfaccia clinica non è un buon posto per imparare che. Lo schermo di accesso ti dice quanti amministratori locali esistono prima di incoraggiarti a dipendere da qualcos'altro.

17.12.1 Cosa decide un mapping di gruppo

Tutti e tre mappano gruppi dal directory ai ruoli di Perfuse e qualcuno in gruppi che corrispondono a più di uno ottiene il più privilegiato. Ciò è l'unica direzione sicura per risolverlo — l'alternativa è una persona che perde l'accesso a cui ha diritto perché è anche in un gruppo inferiore.

Uno dei sei ruoli può essere concesso: monitor, visualizzatore, operatore, editore, amministratore e piattaforma.

Un gruppo può anche essere limitato a alcuni gruppi di canali, nella seconda casella della sua riga (channel_groups nel file). Una volta che un gruppo ne nomina uno, ogni accesso imposta i gruppi di canali della persona dai gruppi che hanno concesso il loro ruolo: qualcuno in un gruppo che modifica i canali del laboratorio e in un altro che visualizza ogni canale è un editore dei canali del laboratorio e nulla altro. Il ruolo più forte non viene mai unito alla portata più ampia, perché nessun gruppo concede questo. Un gruppo con una casella vuota concede ogni canale. Finché nessun gruppo ne nomina uno, l'accesso lascia i gruppi di canali come li ha impostati un amministratore in Utenti.

Quando ogni gruppo a cui una persona appartiene nomina gruppi di canali, ogni gruppo di canali ottiene il ruolo più forte tra i gruppi che lo nominano: con Lab-Interfaces (editore, laboratorio) e Clinical-IT (visualizzatore, laboratorio e adt), la persona modifica i canali del laboratorio e visualizza quelli delle ammissioni, come se fosse stato impostato manualmente. Quando uno dei loro gruppi concede ogni canale, non c'è una lista per tenere un ruolo per gruppo, e si applica la regola sopra.

roles:
  editor: [Lab-Interfaces]
  operator: [Night-Desk]
  viewer: [Clinical-IT]
  channel_groups:
    Lab-Interfaces: [lab, pathology]
    Night-Desk: [adt]

Questo è il file OpenID Connect e SAML. Il file della directory mappa ogni gruppo a un ruolo (roles: {Lab-Interfaces: editor}), e channel_groups si trova accanto a roles lì.

Una mappatura che non concede nulla a nessuno viene rifiutata invece di essere salvata. Una configurazione che autentica le persone e le respinge tutte sembra identica a un prodotto rotto dall'esterno: il round trip si completa e tutti vengono negati senza nulla che spieghi il motivo.

La creazione di un account al primo accesso è disabilitata per default. Con essa disabilitata, qualcuno deve esistere in Perfuse prima di poter accedere, quindi la directory decide chi sono e Perfuse decide chi è autorizzato ad accedere.

17.12.2 SAML, in particolare

Le parti importanti da conoscere prima di configurarlo:

• Solo il certificato configurato è attendibile. Un certificato contenuto all'interno di una risposta non viene mai utilizzato. Un attaccante che può inviare un documento può anche inserire il proprio certificato in esso, e un verificatore che lo legge è uno che chiunque può autenticare come chiunque.
• Una risposta deve rispondere a un accesso avviato da questo server. Perfuse ricorda la richiesta che ha inviato e rifiuta una risposta che nomina qualcos'altro, o nomina una richiesta che ha già risposto. Senza questo controllo, una risposta valida è un token di portatore per chi lo detiene: qualcuno si accede come se stesso, mantiene la risposta e la invia nel tuo browser, e poi sei all'interno del suo account con il registro di audit che registra il suo nome.
• Gli accessi avviati dal provider di identità sono quindi disabilitati per default. Attiva *Accetta accessi avviati dal provider di identità* solo se hai bisogno di un riquadro del portale, e sapendo che è ciò che rende possibile quanto sopra.
• L'attributo di gruppo non ha un valore predefinito e è obbligatorio. Entra invia groups, Okta invia ciò che l'applicazione è stata configurata per inviare, ADFS invia un URI di attestazione. Una supposizione produrrebbe un accesso che funziona e non concede nulla a nessuno. Se un accesso viene rifiutato per non avere un ruolo, il registro del server nomina gli attributi che sono effettivamente arrivati — che è di solito la risposta completa.
• L'URL di risposta deve corrispondere esattamente a ciò che è registrato presso il provider. Una risposta dice dove è destinata e una risposta indirizzata altrove viene rifiutata, perché accettarla significherebbe accettare una risposta destinata a un servizio diverso.

17.12.3 Cosa invia ogni provider

L'attributo di gruppo è dove gli accessi vanno storti, e i tre provider comuni lo nominano in modo diverso.

Un URI di attestazione può essere immesso dal suo segmento finale: digitare groups trova http://schemas.microsoft.com/ws/2008/06/identity/claims/groups. Un nome che termina semplicemente con la parola non corrisponde — excluded_groups non è groups.

L'appartenenza al gruppo che arriva come un solo valore separato da virgole viene trattata come un singolo nome di gruppo e non corrisponde a nulla. Questa è la lettura corretta dello standard, e dividere le virgole significherebbe che un gruppo che legittimamente contiene uno è diventato silenziosamente due. Se questo è ciò che il tuo provider invia, modificalo lì.

Test sulla schermata di accesso controlla tutto ciò che può essere controllato senza una persona: le impostazioni, il certificato e se una richiesta di accesso può essere costruita. Dice chiaramente che non può provare che qualcuno possa accedere, perché ciò richiede un'asserzione reale su una persona reale e l'unico modo per ottenerla è che provino.

17.13 Account provisionati dal provider di identità: SCIM

Con -scim (Impostazioni → Accesso → Account automatici), un provider di identità come Okta, Microsoft Entra ID o Google Workspace crea, aggiorna e rimuove account Perfuse da solo in /scim/v2/Users, quindi una persona che lascia l'organizzazione perde l'accesso quando il suo account del directory viene disabilitato, non quando qualcuno se ne ricorda. Il provider si autentica con un token API che detiene il ruolo di amministratore, creato sotto Utenti → Credenziali macchina, inviato come token di portatore.

• La disabilitazione di un account termina immediatamente le sue sessioni, e il server verifica che nessuna sia sopravvissuta prima di rispondere. Un fornitore non viene mai informato che un account è stato disabilitato quando non lo è stato, perché un fornitore non ritenta ciò che gli è stato detto di aver avuto successo.
• Un eliminazione disabilita prima, quindi elimina, quindi un errore a metà strada lascia un account con cui nessuno può accedere. La storia di audit di un account rimosso viene conservata.
• Il ruolo deriva dai gruppi o ruoli della persona, abbinati per nome: un gruppo il cui nome contiene *admin*, *editor*, *operator*,

*viewer* (o *solo lettura*) o *monitor* assegna quel ruolo, quindi APP-Perfuse-Editor e Perfuse Operators funzionano come sono denominati. Tutto il resto ottiene -scim-default-role, viewer a meno che non sia impostato diversamente. La piattaforma non può essere concessa in questo modo.

• Nessuna password. Un account creato da SCIM accede tramite il provider di identità; una seconda password che nessuno a monte conosce sopravviverebbe a una disabilitazione.
• /scim/v2/ServiceProviderConfig indica cosa è supportato: creazione, lettura, sostituzione, patch e eliminazione di Utenti, e filtri fino a 200

risultati. Le operazioni bulk, l'ordinamento e le ETag non sono supportate.

17.14 Cosa Perfuse non fa

Non crittografa il database a riposo. Utilizzare la crittografia del file system o del volume.

Non gestisce i propri certificati o il loro rinnovo. Indicarlo ai file e gestire quei file con ciò che già si utilizza.

SAML è stato verificato contro due provider indipendenti, ciascuno con un accesso al browser reale, un'asserzione reale e una sessione reale: Keycloak 26 e Microsoft Entra. Due questioni più del doppio di una, perché i due sono in disaccordo in un modo che si è rivelato fondamentale — Keycloak scrive la sua asserzione con prefissi di namespace e Entra scrive gli stessi elementi senza di essi, e il difetto che questa area ha avuto è stato nella gestione dei prefissi.

Iniziare leggendo i metadati del provider. Impostazioni, quindi Accesso, quindi la scheda SAML: fornire l'URL dei metadati o incollare il documento, e l'indirizzo di accesso e il certificato di firma sono compilati automaticamente. Ogni provider SAML pubblica uno di questi — Okta, Entra, AWS IAM Identity Center, Keycloak, ADFS — ed è la differenza tra la configurazione di un provider e la trascrizione di uno. Farlo manualmente significa trovare il certificato all'interno del XML, rimuovere le interruzioni di riga dalla base64 e avvolgerlo in intestazioni PEM, dove uno spazio isolato produce un errore di firma che non dice nulla sulla formattazione.

Ciò che torna è descritto piuttosto che scaricato: il soggetto di ogni certificato, la scadenza e l'impronta SHA-256, in modo che sia possibile verificarlo con ciò che mostra la console del provider. Un certificato scaduto è indicato come scaduto piuttosto che lasciato come data da confrontare ad occhio. Nulla è salvato leggendo — applicarlo al modulo è un clic separato, perché un documento che qualcuno ha incollato non è ancora una decisione su cosa fidarsi.

Un URL dei metadati è recuperato solo su https e l'indirizzo è verificato contro la stessa politica che governa le destinazioni dei canali, quindi questo non può essere utilizzato per far leggere al server le credenziali delle istanze cloud. Le reindirizzamenti non sono seguiti, perché un indirizzo consentito che reindirizza a uno bloccato passerebbe direttamente oltre quel controllo.

Se si sta configurando Entra, cinque cose non corrisponderanno a ciò che mostrano gli esempi. Non invia alcuna richiesta di posta elettronica. Il suo NameID è un identificatore opaco piuttosto che un indirizzo. Non invia alcuna richiesta di gruppo a meno che l'applicazione non sia configurata esplicitamente per emetterne una, quindi un mapping di ruolo scritto contro i gruppi rifiuta ogni accesso. Quando i gruppi vengono emessi, sono GUID di oggetto piuttosto che nomi, a meno che il tenant non sincronizzi da Active Directory locale. E i nomi delle sue richieste vivono sotto schemas.microsoft.com/identity dove la maggior parte della documentazione mostra schemas.xmlsoap.org. Perfuse gestisce tutti e cinque; sono elencati perché i primi quattro altrimenti sembrerebbero difetti in Perfuse quando sono Entra che è Entra.

Quella distinzione non è teorica qui. La prima asserzione Keycloak genuina è fallita del tutto, perché la forma canonica della firma coperta stava venendo calcolata con prefissi di namespace rilasciati. Nessun provider di identità reale avrebbe potuto firmare qualcuno, e i cinque test di canonizzazione del pacchetto sono passati in tutto — ciascuno di essi firmato e verificato con lo stesso codice, quindi hanno dimostrato solo che era d'accordo con se stesso. Se si è i primi a puntare un provider diverso su questo, aspettarsi di trovare qualcosa, e il registro del server nomina la fase che è fallita.

18 Operazioni

18.1 Distribuzione

Un binario e due percorsi: una directory di file di canale e un file di database. Non c'è un server di applicazioni, nessun livello web separato e nessun broker di messaggi richiesto.

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

Eseguirlo sotto qualsiasi cosa supervisioni i servizi sull'host — systemd, launchd, un runtime del contenitore. Si aspetta di essere riavviato se esce.

18.2 Dove i dati possono andare (residenza dei dati)

serve -residency (Impostazioni → Dati → Dove i dati possono andare) nomina le regioni cloud in cui i dati di questo server possono essere inviati o letti: aree (eea, uk, ch) e codici di regione (eu-central-1, uksouth, europe-west2), separati da virgole. eea sono le regioni AWS, Azure e Google Cloud nell'Area Economica Europea (Frankfurt, Irlanda, Parigi, Stoccolma, Milano, Spagna; Paesi Bassi, Germania, Francia, Svezia, Norvegia, Italia, Polonia, Spagna; Belgio, Paesi Bassi, Germania, Italia, Francia, Finlandia, Spagna, Polonia), uk quelle nel Regno Unito, ch quelle in Svizzera.

Con esso impostato, un canale viene rifiutato quando viene salvato e quando viene caricato, se un connettore nomina una regione al di fuori dell'elenco: una sorgente o destinazione S3, SQS o SNS con region (o il suo endpoint, quando è un hostname AWS), o qualsiasi destinazione il cui indirizzo è un hostname AWS che trasporta una regione (sqs.us-east-1.amazonaws.com, un URL dell'API Gateway). Il server rifiuta di avviarsi con un collector di tracce o un webhook di allarme in un'altra regione. Un connettore puntato a un host che non nomina una regione (un sistema di un ospedale, MinIO nella rete del sito) non viene giudicato: il record dell'elaborazione sullo schermo di protezione dei dati elenca ogni host a cui ogni canale invia, per il controllore di verificarlo. Il cruscotto e lo schermo di protezione dei dati dicono dove i dati possono andare.

Hosting nell'UE e nel Regno Unito. deploy/hosted contiene OpenTofu (o Terraform) per un server ospitato per organizzazione a Francoforte, Irlanda o Londra: il server, il suo database PostgreSQL e i backup, un bucket di backup, log e record di sessioni di supporto, tutto criptato con una chiave nella Regione, nulla replicato in un'altra Regione, supporto tramite Session Manager solo, e Perfuse eseguito con -residency. Il suo README dice cosa costruisce, cosa non copre, cosa è stato verificato (validato e pianificato contro un account reale; non ancora applicato) e cosa costa al prezzo di lista in ogni Regione.

18.3 Configurazione come file

I canali sono file, il che significa che possono essere in controllo di versione, esaminati prima della distribuzione e confrontati dopo un incidente.

I file vengono riletto senza riavvio. Un file che non si analizza viene segnalato e la versione precedentemente caricata continua a funzionare, quindi un errore di sintassi non può interrompere un feed funzionante.

18.4 Backup

Due cose da eseguire il backup, e hanno caratteristiche diverse.

La directory del canale è piccola, cambia raramente e è ciò di cui hai bisogno per ricostruire il servizio. Eseguire il backup come configurazione; il controllo di versione è di solito sufficiente.

Il database contiene messaggi, utenti e storia di audit. È grande, cambia costantemente e contiene dati clinici — quindi ha bisogno di essere eseguito il backup come dati clinici, con la conservazione e la crittografia che ne conseguono. La perdita di esso non interrompe il servizio, ma perde la capacità di indagare su tutto ciò che è già accaduto e la storia di cui dipende l'apprendimento del ritmo.

18.5 Comportamento di riavvio

Al riavvio, i canali vengono caricati e le sorgenti iniziano ad ascoltare. Le consegne in coda riprendono.

La cosa da capire è cosa succede al lavoro in volo. Con l'acknowledgement predefinito on_delivery, un messaggio che non era stato ancora confermato non viene confermato, quindi il mittente lo rinviará — che è l'esito corretto. Con on_receipt, un messaggio che era stato confermato ma non ancora consegnato è nella coda e riprende; se la coda è disabilitata, viene perso. Vedi flusso di messaggi.

18.6 Aggiornamento

Sostituire il binario e riavviare. Lo schema del database viene migrato in avanti automaticamente all'avvio.

Le migrazioni sono solo in avanti. Non c'è downgrade, quindi un rollback a un binario precedente dopo che lo schema è stato spostato richiede il database precedente. Prendere una copia prima di eseguire l'aggiornamento — questa è l'unica precauzione operativa per cui vale la pena essere disciplinati.

18.7 Monitoraggio

L'allertamento all'interno di Perfuse è coperto in allertamento e sarà ciò che ti dirà che un feed si è fermato.

Dall'esterno, monitorare il processo, il disco su cui si trova il database e se l'interfaccia web risponde. Il database cresce e un disco pieno interrompe la registrazione dei messaggi, che è una modalità di guasto senza altri avvisi.

18.7.1 SNMP

Per strumenti di monitoraggio che parlano SNMP (Nagios, Zabbix, PRTG, SolarWinds, LibreNMS), Perfuse esegue un agente SNMPv2c in sola lettura e invia una trappola quando un allarme si attiva o si risolve. Impostalo sotto Impostazioni → Monitoraggio → SNMP, o con flag:

perfuse serve -snmp-listen :161 -snmp-community 'long-random-community' -snmp-allow 10.0.5.0/24 \
  -snmp-traps nms.example.org,10.0.5.9:1162

• L'agente risponde a GET, GETNEXT e GETBULK, e solo dalle reti in -snmp-allow: la community di v2c è una password inviata in chiaro, quindi non è mai aperta a tutti. Una community con meno di 6 caratteri, o public/private, ferma il server all'avvio.
• Fornisce il gruppo di sistema (sysDescr, sysUpTime, sysName dal label della flotta, sysContact, sysLocation), totali sotto

BASE.1 (canali, in esecuzione, interrotti, ricevuti, consegnati, non riusciti, in coda) e una tabella dei canali sotto BASE.2.1 (nome, in esecuzione o interrotto, ricevuti, consegnati, non riusciti, in coda, età del messaggio più vecchio in coda). I numeri sono quelli visualizzati dal cruscotto e /metrics.

• Le trappole vanno a ogni gestore in -snmp-traps: BASE.0.1 un allarme attivato, BASE.0.2 si è risolto, trasportando il tipo di allarme,

gravità, canale, destinazione e riassunto. Mai il contenuto del messaggio. Un allarme riconosciuto non invia trappole.

• BASE è 1.3.6.1.4.1.8072.9999.9999.16 (spazio sperimentale di Net-SNMP) a meno che -snmp-base-oid non lo metta sotto il proprio

numero di impresa. Scarica il MIB nella pagina Impostazioni (o GET /api/snmp/mib) fornisce un MIB per la base in uso; lo stesso pannello indica se l'agente sta rispondendo e quanti allarmi sono stati inviati.

18.7.2 Un inventario di ogni interfaccia

-inventory interfaces.md (Impostazioni → Monitoraggio → Inventario) scrive un documento Markdown che elenca ogni canale - il suo formato, se è in esecuzione, cosa riceve da e cosa invia a - seguito dalla descrizione di ogni canale, e lo riscrive ogni -inventory-every (un giorno per default). È destinato a essere commitato accanto ai file del canale, o consegnato a un revisore, e letto senza che l'applicazione sia in esecuzione.

18.8 Capacità

Il soffitto di throughput di Perfuse non è stato misurato su hardware reale in traffico reale, e questo manuale non stampa un numero che non possa supportare.

Ciò che può essere detto: l'architettura è un goroutine per connessione con code per destinazione, quindi il throughput scala con le destinazioni piuttosto che essere serializzato attraverso un solo lavoratore; la registrazione dei messaggi è una scrittura SQLite per messaggio, che rende il disco la limitazione più probabile; e l'archiviazione dei messaggi cresce linearmente con il traffico, quindi la conservazione è l'impostazione che governa l'utilizzo del disco a lungo termine.

Se si sta dimensionando questo per un grande feed, misurarlo con il proprio traffico utilizzando il corpus di test generato descritto in testing. Questa è la risposta onesta, ed è anche una risposta migliore di un numero proveniente da hardware di qualcun altro.

18.9 Dove questa installazione si è bloccata

L'attività porta un pannello, visibile agli amministratori, che mostra cosa Perfuse ha rifiutato di fare — raggruppato per messaggio, più frequente per primo — e quanto l'installazione ha progredito verso un canale funzionante.

Esiste perché ogni altra affermazione sulla facilità d'uso di questo software proviene dalle persone che lo hanno scritto. Un rifiuto non è così: qualcuno voleva qualcosa, il server ha detto no e nessuna delle due parti stava indovinando. È l'unica prova nel prodotto che non proviene da BioDream LLC.

Il funnello nomina il passaggio che non è ancora avvenuto piuttosto che lasciare i timestamp da confrontare. Lo stato degno di essere osservato è i messaggi arrivano e nessuno è stato consegnato a una destinazione — un canale può gestire il traffico per settimane e non consegnare nulla, e da ogni altro schermo sembra che funzioni.

Nessuno di ciò che qualcuno ha digitato è registrato. La tabella contiene il percorso della richiesta con gli identificatori sostituiti da {id}, lo stato e la frase del server. Un messaggio di convalida nomina un campo e una regola, che è la parte utile; il valore che ha violato la regola è molto spesso un dato del paziente e una tabella di questi sarebbe una responsabilità peggiore della frizione che misura.

Due esclusioni deliberate. Un 5xx è un errore in questo software e viene già registrato come tale — mescolare i due seppellirebbe i casi in cui qualcuno non poteva capire cosa digitare sotto i casi in cui nulla di ciò che hanno digitato avrebbe aiutato. E una sessione scaduta produce una serie di 401 che non dicono nulla sulla facilità d'uso e sommergerebbero ogni scoperta che lo fa.

La lettura del report tronca anche la tabella alle sue ultime cinquemila righe. I rifiuti sono risposte 4xx quindi cresce lentamente, e la lettura è un momento naturale per sistemare: nessun timer e nulla che funzioni quando nessuno sta guardando.

GET /api/friction restituisce la stessa cosa per chi preferisce leggerla come JSON.

18.10 Registri

Perfuse registra l'output standard, che è dove un supervisore o un runtime del contenitore lo raccoglierà.

I dettagli a livello di messaggio vanno al message store invece del registro, intenzionalmente. Una riga di registro per messaggio in un feed attivo è rumore che nasconde le righe che contano, e il negozio è ricercabile in modi che un file di registro non è.

Il registro porta ciò che il negozio non può: avvio e arresto, risultati del caricamento della configurazione, modifiche dello stato del canale e errori che non sono attribuibili a un messaggio specifico.

18.11 Esecuzione di due istanze

Due o più server possono essere eseguiti come un cluster: quando il server che esegue un feed si ferma, un altro lo assume entro pochi secondi, e il prossimo tentativo del mittente lo raggiunge. Condividono un database PostgreSQL invece di ogni server che mantiene un file SQLite, e si accordano tra loro, attraverso di esso, su quale di loro esegue cosa.

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

Avvia ogni server allo stesso modo con il proprio nome e indirizzo. L'account del database deve creare tabelle e, una volta, la estensione citext (o un amministratore esegue CREATE EXTENSION citext prima). Ogni server mantiene i propri file in -data: il proprio log, il proprio ID di nodo e le proprie copie della configurazione.

Due modi di condividere il lavoro.

• active-passive: il leader esegue ogni canale e ogni lavoro che deve essere eseguito una volta (notifiche di abbonamento FHIR). Gli

altri aspettano. Il più semplice da capire, e ciò che un sito con un server occupato e uno di riserva vuole.

• active-active: i canali sono distribuiti sui server attivi, più o meno uniformemente. Un server che si ferma passa i propri canali

agli altri; uno che si unisce prende la propria quota man mano che i canali sono liberati, uno alla volta. I canali che instradano l'uno all'altro (una destinazione del canale) vengono eseguiti su un server e si spostano insieme, perché l'instradamento avviene all'interno di un server. Un amministratore può spostare un canale manualmente da Monitor → Fleet; rimane dove è stato messo finché quel server vive.

Chi esegue cosa, e nessun momento con due. Ogni pezzo di lavoro è un lease nel database, rinnovato ogni quinto di -cluster-lease (15 s per impostazione predefinita). Un server che non può rinnovarlo (si è bloccato, la sua rete è fallita, il database non è raggiungibile) ferma quel lavoro da solo una volta che il proprio orologio dice che il lease è quasi finito, con un terzo del lease di riserva. Un altro server prende il lease solo dopo che il proprio orologio ha osservato il contatore del lease rimanere fermo per un intero lease. Nessun orologio viene confrontato con un altro, quindi gli orologi dei server e del database non devono essere coerenti; devono solo funzionare più o meno alla stessa velocità, il che ogni orologio fa. Tra la fine del vecchio detentore e l'inizio del nuovo c'è un breve intervallo con nessuno in ascolto, che un mittente vede come una connessione rifiutata e ritenta; non c'è mai un momento con due in ascolto su un feed o due lavoratori che svuotano una coda.

Un server che si spegne in modo pulito, o un amministratore che sceglie Ritira sul leader, passa il testimone subito invece di aspettare il lease.

Cosa ogni server condivide. I messaggi, la coda di consegna, gli account e le sessioni, il log di audit, l'archivio FHIR, le tabelle di terminologia e l'indice dei pazienti sono nel database, quindi qualunque server esegua un canale trova la coda che l'ultimo ha lasciato. I file del canale, il file di impostazioni, le regole di allarme, i file di accesso singolo, il logo, i certificati Direct e le viste salvate vengono mantenuti uguali su ogni server attraverso il database: ogni server mantiene la propria copia sul proprio disco, una modifica su qualsiasi server (nella console, a mano, tramite git pull) raggiunge gli altri entro due secondi, e un canale modificato su un altro server si riavvia con il nuovo file. Lo stesso file modificato su due server contemporaneamente mantiene la versione che ha raggiunto il database per prima, e l'altro accanto come NAME.conflict-SERVER. Le impostazioni che si applicano solo al riavvio (il database dei messaggi, le porte che la console ascolta) vengono applicate da ogni server al prossimo riavvio, e il log lo dice. Cosa nomina qualcosa su una macchina rimane sulla riga di comando del server e fuori dal file condiviso: il certificato e la chiave (-tls-cert, -tls-key), l'indirizzo di ascolto SNMP e il nome del server nelle tracce. Le impostazioni li visualizzano come impostati su ogni server.

Avvio e arresto. L'avvio o l'arresto di un canale su qualsiasi server si applica al cluster: il server che lo esegue lo avvia o lo arresta entro un secondo, e la risposta indica quale server lo fa.

Il bilanciatore di carico davanti. L'indirizzo di un feed deve raggiungere il server che lo esegue. Puntare il mittente a un indirizzo virtuale (un bilanciatore di carico, un IP galleggiante, un nome DNS con un TTL breve) e fare in modo che il bilanciatore di carico controlli /readyz?channel=NAME, che risponde 200 solo sul server che esegue quel canale, e 503 sugli altri. Per la console, /readyz è 200 su ogni server attivo; /readyz?role=leader solo sul leader.

Su un AWS Network Load Balancer, utilizzare un gruppo di destinazione per feed con un controllo di salute HTTPS su /readyz?channel=NAME, un intervallo di 5 secondi e una soglia di 2, e attivare il bilanciamento di carico tra zone. Con esso disattivato, il nodo del bilanciatore di carico in una zona in cui nessun server esegue il feed vede solo destinazioni non sane, invia comunque a tutte loro, e un mittente che ha risolto quel nodo attende fino a quando il feed non torna nella sua zona (95 secondi in un test). Impostare il ritardo di deregistrazione su 0, poiché un server che smette di eseguire un feed non ha nulla da drenare.

Ciò che è stato testato. Due server su PostgreSQL 16, un mittente che invia 300 messaggi, rinviando fino a quando non riceve una risposta, e il server che esegue il feed ucciso con SIGKILL due volte (la prima, poi la seconda dopo che la prima è tornata). Ogni messaggio riconosciuto ha raggiunto il ricevente, in entrambe le forme provate: consegnato prima dell'ack, e in coda nell'archivio condiviso mentre il ricevente rifiutava (185 messaggi riconosciuti in coda al momento dell'uccisione; il superstite li ha consegnati tutti). Il failover ha richiesto da 3 a 4 secondi su un lease di 3 secondi. Una copia è possibile e si è verificata una volta su 600: un messaggio che il server morente ha consegnato e non ha potuto riconoscere, che il mittente ha rinviato. I test del coordinatore coprono un crash, un server tagliato fuori dal database mentre è in esecuzione, step-down, diffusione, spostamenti e configurazione condivisa con conflitti. Vengono eseguiti in CI contro PostgreSQL con il rilevatore di gare, con l'intera suite.

Lo stesso è stato fatto su AWS: due server Linux (ARM) e un server Windows Server 2022 in tre zone di disponibilità, Amazon RDS PostgreSQL 16 su TLS con il certificato verificato (sslmode=verify-full), un bilanciatore di carico di rete interno in fronte, e mittenti che rinviavano fino a quando non ricevevano una risposta:

Con il lease predefinito di 15 secondi, un server tagliato fuori dal database ha fermato il suo feed 10 secondi dopo l'ultima rinnovazione, e il prossimo server lo ha avviato 6-8 secondi dopo: mai entrambi contemporaneamente. Gli orologi distorti non hanno cambiato nulla, poiché nessun orologio viene confrontato con un altro.

Non ancora. Un cluster serve un'organizzazione: -cluster con -multi-tenant viene rifiutato. Gli ascoltatori si spostano con il loro canale, quindi il bilanciatore di carico è di competenza del sito.

Un server da solo continua a funzionare come sempre, su SQLite, senza cluster.

18.12 Più di un server

Un sito con due istanze ha una domanda a cui nessuna console singola può rispondere: è tutto in esecuzione? Mirth addebita per la risposta. Questa è la visualizzazione della flotta.

Un'istanza è designata come il luogo in cui si guarda. Interroga le altre e visualizza ogni canale su ogni server in una tabella, con un riepilogo su tutti loro.

18.12.1 Aggiungere un peer

Impostazioni → Flotta, o PUT /api/fleet/peers. Un peer necessita di un nome, un URL e un token rilasciato dal peer stesso.

Il nome è obbligatorio e non è l'URL, perché un URL non è qualcosa che chiunque riconosca alle tre del mattino.

Il token deve essere creato sul peer, sotto Utenti, e dovrebbe avere un ambito di visualizzazione. L'aggiunta di un peer senza uno di questi token viene rifiutata, con queste istruzioni, piuttosto che essere accettata e poi fallire silenziosamente ad ogni poll. La lettura dello stato di salute di un'altra istanza è il privilegio minimo che esiste, ed è l'unico di cui ha bisogno la visualizzazione della flotta.

18.12.2 Controllo di un peer, che è spento

allow_control consente di avviare e fermare i canali di quel peer da qui. È disattivato per default e ogni utilizzo viene registrato per nome.

I due privilegi sono deliberatamente separati. Leggere la salute di un altro server è una questione minore; fermare i suoi canali durante una trasfusione non lo è, e il secondo non dovrebbe mai arrivare silenziosamente allegato al primo.

18.12.3 Cosa dice il report

Ogni server segnala il numero totale di canali, quanti sono in esecuzione, fermi o in errore, la profondità della coda e l'età del messaggio più vecchio in attesa, quanti allarmi sono attivi, e se sta drenando per lo spegnimento.

Il riepilogo conta i server in tre modi: raggiungibile, irraggiungibile e indeterminato. Il terzo copre i peer di cui nessuno conosce la salute — non ancora interpellati, rifiutanti il token, o in esecuzione di una versione che questo non può leggere. Viene tenuto separato dall'irraggiungibile perché "non sappiamo" non è "è giù", e fondere i due insieme è come iniziare a mentire su una pagina della flotta.

Per lo stesso motivo, il rollup riporta knownFrom: quante istanze i dati del canale e della coda sono stati effettivamente letti. Dodici canali in esecuzione su una flotta significano qualcosa di diverso quando due dei cinque server non hanno risposto e il totale da solo non può dirlo.

Un peer irraggiungibile dice perché in termini che un operatore può utilizzare. Una connessione rifiutata viene segnalata come l'host che è attivo senza nulla in ascolto su quella porta, che è un problema diverso da un host che non risponde affatto.

18.12.4 Differenza di orologio

Il rollup riporta la maggiore differenza tra gli orologi dei server in esso. Vale la pena di un numero proprio: la correlazione di un incidente tra due istanze le cui ore non concordano di quattro minuti produce una sequenza di eventi che non è avvenuta.

18.12.5 Cosa un peer apprende da te

Conteggio e tassi. Il report che un'istanza fornisce a un'altra non contiene identificatori di messaggio, dettagli a livello di canale e nessun dato paziente di alcun tipo.

È ciò che impedisce a una visualizzazione della flotta di essere una centralizzazione dei dati clinici: l'istanza aggregante apprende quanti canali sono in esecuzione e nulla riguardo a ciò che è stato trasmesso attraverso di essi. Se si desiderano i messaggi, si apre la console del server stesso, dove il registro di audit registra che lo si è fatto.

18.12.6 Un peer puntato a se stesso

Rifiutato. Un'istanza che interpella il proprio indirizzo attraverso il proprio stack HTTP appare due volte nella propria visualizzazione della flotta e conta due volte ogni canale che possiede.

18.12.7 TLS nelle reti interne

insecure_skip_verify accetta il certificato di un peer senza verificarlo. Esiste perché l'infrastruttura ospedaliera funziona con autorità di certificazione private e rifiutare di funzionare affatto spingerebbe le persone verso HTTP semplice, che è peggiore. È denominato in modo che non possa essere scambiato per una buona idea.

19 La riga di comando

Tutto ciò che Perfuse fa a un sistema in esecuzione è raggiungibile dall'interfaccia web, e ciò è deliberato: una funzionalità che necessita di un terminale è trattata come un difetto piuttosto che come una scelta di progettazione. I comandi qui sono per il lavoro che avviene *intorno* a un sistema in esecuzione — prima che esista, mentre si decide se fidarsi di esso e quando è necessario consegnare qualcosa a qualcun altro.

Molti di essi non toccano affatto un server. perfuse explain, perfuse profile, perfuse deident e perfuse translate leggono file e scrivono file, quindi sono utili su un laptop contro un patrimonio che ancora funziona interamente con qualcos'altro.

Eseguire qualsiasi comando con -h per le sue opzioni. Questo capitolo dice a cosa serve ogni comando.

19.1 Esecuzione dei canali

19.1.1 perfuse serve

Esegue l'interfaccia web e l'API e, per default, esegue anche i canali. Questo è il comando utilizzato da un'installazione.

Ogni opzione che accetta è elencata in Opzioni del server, generata dal programma. Rifiuta di servire HTTP non crittografato a tutto tranne che al loopback a meno che non si passi -insecure. Ciò non è una configurazione di cortesia: il traffico clinico e un cookie di sessione su una connessione LAN non crittografata è un evento segnalabile e la bandiera esiste in modo che dire sì sia una decisione presa da qualcuno piuttosto che un'impostazione predefinita ereditata. Vedi sicurezza.

19.1.2 perfuse run

Esegue i canali da YAML senza interfaccia web e senza database. Utile in un contenitore che dovrebbe fare esattamente una cosa e utile quando si desidera vedere il comportamento di un canale senza che nulla altro sia in esecuzione.

19.1.3 perfuse check

Convalida le definizioni dei canali e stampa cosa fanno, senza eseguirle. La seconda metà è il punto: un canale che si carica non è necessariamente il canale che si intendeva e la lettura di un riassunto in inglese chiaro di cosa farà un file coglie un errore che la convalida non può vedere.

Esci con un codice diverso da zero in caso di errore, quindi appartiene a qualsiasi controllo della configurazione prima che raggiunga un server. -quiet non stampa nulla in caso di successo, per questo utilizzo.

-allow-metadata-egress consente ai destinatari di puntare agli indirizzi dei metadati delle istanze cloud. Tali indirizzi contengono le credenziali della macchina stessa, quindi un canale che può essere convinto a inviare lì è una perdita di credenziali; il controllo rifiuta tali indirizzi a meno che non si specifichi diversamente.

19.1.4 perfuse test

Esegue i test scritti contro le definizioni dei canali. Un test invia un messaggio attraverso il filtro reale del canale, le trasformazioni reali e gli script reali, nell'ordine reale, con solo la rete sostituita — quindi ciò che passa qui è ciò che il canale fa.

I test si trovano in *_test.yaml o *.test.yaml accanto ai canali. Vedi testing.

19.2 Migrazione da un altro motore

Questi tre sono quelli da eseguire per primi, prima di decidere qualsiasi cosa. Vedi migration.

19.2.1 perfuse explain

Legge le esportazioni di Mirth, Open Integration Engine e BridgeLink — un canale, un gruppo di canali o un backup di un intero server — e descrive cosa fa ogni canale e cosa bloccerebbe una migrazione. Non modifica nulla e non richiede un'installazione di Perfuse, il che lo rende il passo più economico possibile: puntarlo a un'esportazione del proprio patrimonio e leggere cosa viene restituito.

-strict esci con un codice diverso da zero se qualcosa è bloccato, quindi può essere utilizzato per controllare una pipeline. -json emette gli stessi risultati per una macchina.

19.2.2 perfuse translate

Converte le esportazioni di Mirth, Open Integration Engine e BridgeLink in file di canali Perfuse: un canale, un gruppo di canali, un'esportazione di una libreria di modelli di codice o un backup di un intero server.

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

Le librerie di modelli di codice vengono scritte nella cartella lib/ accanto ai canali e ogni canale di Mirth include la libreria abilitata per esso. Vedi migration.

Nessuna parte di un canale viene silenziosamente eliminata. Ogni parte di un canale viene tradotta, portata come uno script che esegue invariato o segnalata come necessitante di un intervento umano. L'ultima categoria è quella onesta — un traduttore che produce un file pulito per ogni input starebbe nascondendo le decisioni che più si necessitano di prendere.

19.2.3 perfuse compare

Esegue lo stesso traffico attraverso due motori e segnala dove sono in disaccordo, raggruppati per campo.

Questo è il comando che risponde alla domanda "perché dovrei fidarmi di questo con i dati dei pazienti", e risponde con le prove che hai raccolto piuttosto che con un'affermazione fatta qui. È il passo finale consigliato prima di effettuare il cut-over e il primo passo consigliato in qualsiasi discussione su se Perfuse è pronto.

19.3 Comprendere un feed

19.3.1 profilo di Perfuse

Legge i messaggi e segnala cosa contiene effettivamente: quali campi sono sempre popolati, quali mai, i set di valori reali dei campi codificati, i contatori di ripetizione e quali segmenti Z appaiono.

I valori vengono segnalati solo per i campi il cui valore forma un piccolo set di codici, in modo che un profilo del traffico reale non diventi un file pieno di dati dei pazienti.

Salvare un profilo e confrontarlo in seguito è il modo per scoprire che un mittente ha cambiato qualcosa:

perfuse profile -save last-month.json corpus/ perfuse profile -against last-month.json new/

19.3.2 contratto di Perfuse

Trasforma l'output di quel pensiero in qualcosa di applicabile. Un contratto dice come deve essere un feed, in modo che il giorno in cui cambia, tu venga avvisato, piuttosto che scoprirlo settimane dopo da un ricevitore che è caduto — i messaggi sono ancora validi HL7 quando un campo scompare, quindi nulla altro si accorge.

perfuse contract promote -o adt.contract.yaml corpus/ perfuse contract check adt.contract.yaml today/

promote genera un punto di partenza, non una risposta. Leggilo e cancella la maggior parte di esso: ogni riga registra se è stata misurata o decisa, che è ciò che ti dice quali righe tenere.

19.4 Produzione di messaggi

19.4.1 perfuse generate

Produce messaggi sintetici HL7 v2. Tutto è inventato — nomi ovviamente fittizi, identificatori sequenziali, indirizzi inventati — quindi l'output è sicuro da inviare, inviare e allegare a un ticket.

Può inviare direttamente a un canale invece di scrivere un file, che è il modo più veloce per dimostrare che un listener funziona:

perfuse generate -n 100 -send 127.0.0.1:6661

19.4.2 perfuse deident

Legge messaggi reali e scrive un corpus che mantiene la loro struttura, i loro codici e i loro intervalli, e nessuno di ciò che identifica un paziente. Questa è la differenza tra essere in grado di inviare a qualcuno una riproduzione e non.

Non è lo stesso strumento di perfuse generate e la distinzione è importante. I messaggi generati sono inventati e quindi sicuri ma irrealistici; un corpus de-identificato è *derivato dal traffico reale*, quindi riproduce le stranezze che effettivamente rompono le interfacce.

Due proprietà degne di nota prima di utilizzarlo:

• Lo stesso sale produce sempre lo stesso corpus, quindi un corpus condiviso può essere rigenerato invece di essere archiviato.
• Mantieni il sale segreto. I pseudonimi sono derivati da valori reali, quindi chiunque detenga il sale può confermare un'ipotesi su chi si riferisce a un record.

19.5 Spostamento dei messaggi manualmente

19.5.1 perfuse listen

Accetta HL7 v2 su MLLP e lo conferma. Un ricevitore che esiste per tutto il tempo necessario, per dimostrare che un mittente può raggiungere questa macchina.

19.5.2 perfuse invia

Invia messaggi HL7 v2 su MLLP da file.

19.6 FHIR

19.6.1 perfuse fhir

Converte HL7 v2 in FHIR, convalida FHIR o lo serve, a seconda del sottocomando.

Il sottocomando di convalida è utile di per sé: ti dirà se una risorsa che qualcuno ti ha inviato soddisfa US Core, che è il profilo contro cui è scritta la regolamentazione americana. Essere in grado di rispondere a ciò senza adottare un motore è l'obiettivo.

19.6.2 perfuse x12

Converte X12 (o altri EDI delimitati) in XML Mirth Connect e Open Integration Engine scrive per esso e viceversa: perfuse x12 xml FILE e perfuse x12 from-xml FILE, input standard quando non è specificato un file. L'output è esattamente ciò che OIE 4.6 scrive, byte per byte, in modo che possa essere confrontato con ciò che un server Mirth ha prodotto o alimentato a un sistema costruito contro di esso. Un canale fa la stessa cosa con x12.arrives_as: xml e x12_as: xml di una destinazione; vedere X12.

19.6.3 perfuse sof

Esegue un SQL su FHIR ViewDefinition su file FHIR (il NDJSON di un'esportazione bulk, Bundles o array JSON; - per stdin) e scrive la tabella: -view FILE (obbligatorio), -format csv|ndjson|json|parquet (csv per default), -header=false e -o FILE (obbligatorio per Parquet). Vedi SQL on FHIR views.

19.6.4 perfuse misura

Valuta una misura di qualità con criteri FHIRPath su file FHIR (il NDJSON di un'esportazione bulk, Bundles o array JSON; - per stdin) e scrive il MeasureReport. Flag:

• -measure FILE, o -measure example:ID per un esempio fornito: obbligatorio. -examples elenca gli esempi.
• -period-start e -period-end: obbligatori.
• -type summary|subject|subject-list.
• -subject Patient/ID.
• -reporter NAME.
• -o FILE.

Vedi misure di qualità digitali.

19.6.5 Flag FHIR su perfuse serve

Il negozio mantiene documenti nonché risorse: un documento, raccolta o messaggio Bundle PUT su /fhir/Bundle/{id} viene mantenuto integro, letto nuovamente con ogni voce nella versione servita e trovato per type, identifier, timestamp e composition. Una transazione PUT lì viene mantenuta come record e non applicata; un POST su /fhir ne applica uno.

Le risposte sono in JSON a meno che il client non chieda XML (Accept: application/fhir+xml, o _format=xml). Perfuse legge solo JSON: un corpo inviato come XML ottiene 415. Un documento Bundle POSTato a /fhir viene mantenuto quando questo server tiene, per identificatore, il paziente e l'incontro che la sua Composizione nomina, e rifiutato con 422 altrimenti. Una lettura Binaria con Accept impostato sul suo tipo di contenuto risponde con il contenuto stesso.

19.7 Impostazione e funzionamento

19.7.1 perfuse init

Crea la struttura delle directory, un canale di esempio e una definizione di servizio per il sistema operativo su cui viene eseguito. Nulla di esistente viene sostituito a meno che non si passi -force.

perfuse init -dir /opt/perfuse -service systemd

19.7.2 perfuse servizio

Registra Perfuse come servizio Windows, lo rimuove o segnala se è installato e in esecuzione. Solo Windows; su Linux l'equivalente è il file unitario perfuse init che può scrivere per te. Vedi operazioni.

19.7.3 perfuse token

Rilascia credenziali per macchine anziché persone. Un token non scade e non è influenzato da chiunque si disconnetta, il che è ciò di cui un server che interpella il suo vicino ha bisogno e ciò che una sessione del browser non è intenzionalmente.

perfuse token crea -db perfuse.db -etichetta flotta-da-sito-a -ruolo visualizzatore perfuse token elenca -db perfuse.db perfuse token revoca -db perfuse.db -etichetta flotta-da-sito-a

Viene memorizzato solo l'hash, quindi un token viene visualizzato una volta quando viene creato e non può essere recuperato in seguito. Un database rubato non produce quindi alcun token utilizzabile. Assegna a un token il ruolo più basso che faccia il lavoro: una visualizzazione a livello di flotta richiede viewer e nulla che legga solo deve avere nulla di più.

-fhir-groups riverside-attributed,riverside-north limita un token a quei gruppi FHIR, per un'esportazione del fornitore CMS-0057 Provider Access: sull'endpoint FHIR può leggere quei gruppi ed esportarli, e nulla altro. Vedi CMS-0057 per i pagatori.

19.7.4 Perfuse Athena

Stampa la tabella esterna di Amazon Athena CREATE EXTERNAL TABLE per un archivio S3 scritto con format: ndjson, utilizzando la proiezione di partizione sulla parte dt=YYYY-MM-DD della chiave, in modo che non debba essere eseguito alcun crawler man mano che vengono aggiunti giorni.

Perfuse Athena -bucket hospital-archive -destination archive

Viene stampato anziché eseguito, poiché la creazione di una tabella richiede autorizzazioni Athena e Glue che questo programma non dovrebbe possedere.

19.7.5 Perfuse SBOM

Elenca tutto ciò che è collegato al binario, letto dal build stesso anziché da go.mod — quindi descrive il binario di fronte a te e non ciò che qualcuno ha richiesto in precedenza.

-json emette CycloneDX e -spdx emette SPDX tag-value, che è generalmente ciò che una revisione di approvvigionamento o di sicurezza sta effettivamente richiedendo. Il codice del browser incorporato nel binario è incluso, poiché un revisore che confronta un binario con gli avvisi di sicurezza deve sapere che contiene un'applicazione React.

19.7.6 Perfuse versione

Stampa la versione e il commit da cui è stato costruito. Vale la pena inserirlo in un ticket: "l'attuale" non è una versione, e due macchine che sono state installate a una settimana di distanza spesso non eseguono lo stesso build.

20 Opzioni del server

Ogni opzione perfuse serve accetta, generata dal programma stesso, quindi questa lista non può nominare un'opzione che non esiste o ometterne una. La maggior parte di esse sono anche un'impostazione nell'interfaccia web, denominata nell'ultima colonna: un valore salvato lì vince sul flag al prossimo avvio, e il flag rimane il modo per impostarlo da una definizione di servizio. L'indirizzo di ascolto, il database e la directory del canale rimangono flag solo, poiché dicono al server dove trovare ciò che starebbe modificando.

I segreti non sono mai flag. Un'opzione che richiede una password o un token nomina una variabile d'ambiente che la contiene.

20.1 Tutte le opzioni

21 Riferimento canale

Ogni chiave che può apparire nel file di canale di livello superiore. Queste vengono estratte dalla sorgente, quindi questo capitolo non può descrivere un'opzione che non esiste o omettere una che esiste.

21.1 Canale

Un canale è un flusso di messaggi configurato: da qualche parte arrivano i messaggi, un filtro opzionale e uno o più posti in cui vanno.

Definito come Channel in internal/config.

21.1.1 nome

Il nome identifica il canale nei log e nelle metriche.

Obbligatorio e univoco.

21.1.2 gruppo

Il gruppo è a cosa appartiene questo canale, per organizzare un elenco che è cresciuto troppo lungo per essere letto.

Cosmetico a cinque canali e strutturale a duecento: i canali di un sito si dividono per il sistema a cui si connettono, o per il team che li possiede, e un elenco piatto di duecento nomi è inutilizzabile per quanto buona sia l'interfaccia.

Una stringa semplice piuttosto che un oggetto gruppo con il proprio file, perché un gruppo non ha comportamento. Il momento in cui ha un file acquisisce impostazioni, e le impostazioni su un gruppo significano che il comportamento di un canale dipende da qualcosa che non è scritto nel canale - che è la proprietà che rende la configurazione di Mirth difficile da comprendere. I gruppi qui sono un'etichetta e nulla più.

21.1.3 allegati

Gli allegati spostano i payload grandi fuori dal messaggio e li ripristinano prima della consegna.

Opzionale per canale: un feed di messaggi ADT semplici non ha nulla da estrarre e non dovrebbe pagare per la macchina.

21.1.4 delimitato

Delimitato configura un canale delimitato.

Significativo solo quando il tipo di dati è delimitato.

21.1.5 tabelle

I nomi dei file delle tabelle di mappatura condivise che una trasformazione può fare riferimento per nome.

Condivise perché la tassonomia del dominio è in gran parte una rielaborazione di una mappatura che qualcun altro ha già derivato: i codici di sesso e le classi di pazienti di un sito vengono tradotti allo stesso modo in ogni canale che li tocca, e una tabella all'interno di un canale è una tabella che solo quel canale può utilizzare.

21.1.6 abilitato

Abilitato predefinito su true.

Un canale disabilitato viene caricato e convalidato ma non avviato, quindi un file che è temporaneamente spento è ancora controllato da CI.

21.1.7 tipo di dati

Il tipo di dati è il formato dei messaggi che questo canale riceve.

Di default è hl7, quindi ogni canale scritto prima dell'esistenza di questo continua a funzionare.

21.1.8 x12

X12 contiene le impostazioni che hanno senso solo su un canale X12.

Impostarlo su qualsiasi altro tipo viene rifiutato invece di essere ignorato.

21.1.9 script

Script configura un canale NCPDP SCRIPT.

I suoi passaggi si trovano qui invece che nelle trasformazioni di livello superiore per lo stesso motivo per cui ogni altro formato non v2 fa: i tipi di passaggi differiscono per formato, quindi una chiave avrebbe significati diversi a seconda del tipo di dati.

21.1.10 dicom

Imaging configura i passaggi di trasformazione denominati di un canale DICOM.

Imaging denominato invece di DICOM perché Sorgente e Destinazione hanno già un campo DICOM e tre campi con lo stesso nome a livelli diversi è il modo in cui qualcuno imposta il campo sbagliato. La chiave yaml è dicom, che è ciò che una persona che scrive il file si aspetta, e il nome Go è quello che evita un errore nel sito di chiamata.

21.1.11 filtro

Filtro è un'espressione che deve essere vera affinché un messaggio venga inoltrato.

Un messaggio che non corrisponde viene comunque confermato: il mittente non ha fatto nulla di sbagliato, semplicemente non siamo interessati.

21.1.12 trasformazioni

Le trasformazioni sono modifiche dichiarative applicate ai messaggi accettati, in ordine, prima di eseguire qualsiasi script.

Questo è il livello destinato a svolgere il lavoro ordinario: ogni passaggio viene convalidato quando il file viene caricato, appare in una diff e può essere esaminato da qualcuno che non legge JavaScript.

21.1.13 script

Script contiene JavaScript per i casi in cui i passaggi dichiarativi non possono esprimere, ed è ciò in cui gli script propri di un canale Mirth vengono inseriti invariati.

Un canale con uno script è contrassegnato come tale nell'interfaccia, perché il suo comportamento non può essere stabilito leggendo la configurazione.

21.1.14 ombra

Ombra esegue una versione candidata di questo canale accanto ad esso e segnala dove differiscono.

Niente di ciò che fa può raggiungere un ricevitore.

22 Riferimento sorgente

Ogni modo in cui un canale può ricevere messaggi e ogni chiave che ogni uno accetta. Un canale ha esattamente una sorgente.

22.1 Sorgente AMQP

AMQPSource riceve da una coda o sottoscrizione.

Un messaggio è accettato solo dopo che il canale lo ha gestito. Uno che non poteva essere gestito viene rilasciato come consegna non riuscita, quindi il broker lo ridelivera e - su Service Bus, oltre il numero massimo di consegne della coda - lo sposta nella coda dei messaggi morti.

Definito come AMQPSource in internal/config.

22.1.1 prefetch

Prefetch è il numero di messaggi che il broker può inviare in anticipo.

Il valore predefinito è 10. Vengono comunque gestiti uno alla volta, in ordine.

22.1.2 reconnect

Reconnect è l'attesa dopo una connessione persa.

Defaults to 5s.

22.2 Sorgente AS2

AS2Source riceve AS2 (RFC 4130): EDI inviato tramite HTTP, firmato e crittografato con S/MIME, risposto con una ricevuta (un MDN) che contiene un digest di ciò che è arrivato.

Il payload è ciò che il canale gestisce; X12 e EDIFACT sono quelli più comuni.

Definito come AS2Source in internal/config.

22.2.1 path

Path è il percorso URL a cui i partner inviano.

Default /as2.

22.2.2 tls

TLS serve HTTPS.

La maggior parte dei partner richiede TLS nel loro accordo, oltre al S/MIME.

22.2.3 id

ID è il nostro identificatore AS2, che i partner inviano in AS2-To.

Un messaggio inviato a qualsiasi altro identificatore viene rifiutato.

22.2.4 partners

I partner sono coloro che possono inviare messaggi qui.

Un messaggio da chiunque altro viene rifiutato.

22.2.5 duplicate_window

DuplicateWindow è il periodo di tempo durante il quale l'ID del messaggio di un partner viene ricordato, in modo che un messaggio inviato nuovamente (il partner non ha ricevuto la nostra ricevuta e ha ritentato) venga risposto con una ricevuta e non venga inoltrato due volte (RFC 4130 sezione 7.5).

Default 30 days.

22.3 Azure Blob Source

AzureBlobSource raccoglie i blob da un prefisso del contenitore.

Definito come AzureBlobSource in internal/config.

22.3.1 move_to

MoveTo è dove si sposta un blob gestito.

Predefinito su processed/.

22.3.2 error_prefix

ErrorPrefix è dove si sposta un blob che non può essere gestito, in modo che non blocchi il resto.

Predefinito su error/.

22.3.3 poll_interval

PollInterval tra le liste.

Defaults to 30s.

22.3.4 max_object_size

MaxObjectSize rifiuta un blob più grande, che rimane dove si trova.

Predefinito su 16 MiB.

22.4 Broker Source

BrokerSource legge i messaggi da un message broker.

JMS Reader di Mirth, raggiunto tramite STOMP perché JMS è un'API Java e non un protocollo. Vedi internal/stomp per sapere perché STOMP e non OpenWire.

Definito come BrokerSource in internal/config.

22.4.1 addr

Addr è l'host e la porta del broker.

Obbligatorio. 61613 è la porta STOMP usuale.

22.4.2 destinazione

La destinazione è la coda o l'argomento da cui leggere.

Required.

I broker scrivono questi in modo diverso - /queue/name su ActiveMQ, un nome semplice su RabbitMQ - quindi viene passato invariato anziché essere assemblato qui. Indovinare significherebbe lavorare contro un broker e leggere silenziosamente nulla su un altro.

22.4.3 accesso

Accesso e codice di accesso autenticano.

La maggior parte dei broker rifiuta una connessione anonima.

22.4.4 codice di accesso

Accesso e codice di accesso autenticano.

La maggior parte dei broker rifiuta una connessione anonima.

22.4.5 host

L'host è l'host virtuale.

Di default è l'host dell'indirizzo.

22.4.6 selettore

Il selettore filtra i messaggi nel broker.

Un selettore JMS, passato invariato anziché interpretato. La filtratura nel broker anziché qui significa che i messaggi che questo canale non vuole non attraversano mai la rete - il che, in una coda condivisa, è la differenza tra la lettura di cento messaggi al giorno e centomila.

22.4.7 id_abbonamento

L'ID di abbonamento nomina l'abbonamento.

Di default è il nome del canale.

Nominali anziché generati, perché un abbonamento durevole è identificato da esso: uno generato creerebbe un nuovo abbonamento ad ogni riavvio e lascerebbe gli abbonamenti vecchi accumulare messaggi che nessuno legge.

22.4.8 batticuore

Il batticuore mantiene la connessione attiva.

Di default è trenta secondi.

Attivato di default qui, a differenza del default del client, perché una sorgente mantiene una connessione aperta per settimane. Senza batticuori, una connessione attraverso un firewall che ha silenziosamente rilasciato il percorso sembra perfettamente sana da questo capo e i messaggi semplicemente smettono di arrivare, senza nulla registrato.

22.4.9 reconnect

La riconnessione è il tempo di attesa prima di riconnettersi dopo un errore.

Di default è cinque secondi.

22.4.10 timeout

Limiti di timeout durante la connessione.

Di default è trenta secondi.

22.5 Sorgente di query DICOM

DICOMQuerySource interroga un archivio con C-FIND ed emette un messaggio per ogni nuovo studio.

Mirth non ha un connettore equivalente. Il suo supporto DICOM è un listener e un inviante - può ricevere immagini inviate e inoltrarle, e questo è tutto. Chiedere a un archivio cosa contiene è stato richiesto nei loro forum dal 2015.

Ciò che lo rende utile non è la query, ma l'automazione: un prefetch che si esegue alle tre del mattino, una riconciliazione che nota che all'archivio manca uno studio che il RIS dice esiste, un elenco di lavoro costruito da ciò che è stato effettivamente scansionato piuttosto che da ciò che è stato ordinato. Sono lavori che i siti attualmente eseguono con uno script pianificato all'esterno del motore, il che significa che sono invisibili ad esso - nessun ritento, nessun allarme, nessuna storia dei messaggi.

Definito come DICOMQuerySource in internal/config.

22.5.1 indirizzo

L'indirizzo è l'host e la porta dell'archivio.

Required.

Denominato per corrispondere alla destinazione DICOM piuttosto che abbreviato. I due erano "indirizzo" e "addr" per un pomeriggio, il che è il tipo di inconsistenza che qualcuno che scrive a mano un file di canale si sbaglia una volta e poi non si fida più del formato.

22.5.2 called_ae

CalledAE è il titolo AE dell'archivio.

Obbligatorio nella pratica: la maggior parte degli archivi rifiuta un'associazione indirizzata ad altro, e quel rifiuto si legge come un'interruzione piuttosto che come un errore di configurazione.

22.5.3 calling_ae

CallingAE è il titolo AE presentato da Perfuse.

Gli archivi lo utilizzano comunemente per il controllo di accesso.

22.5.4 livello

Il livello è il livello di query: PATIENT, STUDY, SERIES o IMAGE.

Predefinito su STUDY.

STUDY è il predefinito perché è ciò che quasi ogni query utile vuole e perché le alternative sorprendono le persone: il livello IMAGE contro un grande CT restituisce una risposta per ogni fetta, che è di centinaia per studio.

22.5.5 corrispondenza

Le corrispondenze sono le chiavi di query.

Un valore filtra; un valore vuoto chiede di restituire il campo.

Le chiavi sono nominate piuttosto che numerate - "PatientID" anziché "0010,0020" - perché un file di canale è letto dalle persone, e un numero di tag in un file di configurazione è una ricerca che ogni lettore deve eseguire.

22.5.6 ritorna

I campi di ritorno sono campi da restituire senza applicare filtri su di essi.

Separati da Match con un valore vuoto, anche se vengono codificati in modo identico, perché l'intento differisce e un lettore può vedere quali chiavi stanno restringendo la ricerca e quali stanno venendo raccolte.

22.5.7 intervallo

L'intervallo è la frequenza con cui eseguire il polling.

Required.

22.5.8 finestra

La finestra è quanto indietro ogni polling guarda, come un intervallo di data di studio.

Zero disabilita completamente il filtro di data.

Una finestra è ciò che mantiene questo limite. Senza di essa, ogni polling chiede all'archivio tutto ciò che ha mai contenuto e poi scarta ciò che ha visto prima - il che funziona su un archivio di test e è antisociale contro un archivio reale che contiene milioni di studi.

22.5.9 sovrapposizione

La sovrapposizione richiede nuovamente questo periodo già pollato.

Il valore predefinito è di un'ora.

Necessario piuttosto che cauto. Uno studio può essere registrato con la data di ieri, il nostro orologio e quello dell'archivio non devono essere d'accordo, e un limite di polling che si allinea esattamente con un arrivo lo perde. La sovrapposizione richiede nuovamente e il controllo già visto ferma il duplicato - quindi il costo della sovrapposizione è una query leggermente più grande e il costo della mancanza di sovrapposizione è uno studio silenziosamente perso.

22.5.10 limite

Il limite limita le corrispondenze accettate da un singolo polling.

Defaults to 500.

Un limite piuttosto che nessun limite perché una chiave di corrispondenza errata trasforma questo in "dammi tutto", e il primo sintomo di ciò contro un archivio reale è l'amministratore dell'archivio che chiede chi sta martellando.

22.5.11 timeout

Il timeout delimita un singolo polling.

Il valore predefinito è di due minuti.

22.5.12 emetti_al_primo_polling

EmitOnFirstPoll invia messaggi per tutto ciò che il primo polling trova.

Il valore predefinito è false.

False è importante. Puntare questo su un archivio che già contiene un milione di studi e farlo emettere un messaggio per ognuno non è un primo esecuzione utile, ed è il tipo di errore che viene notato a valle piuttosto che qui. Il primo polling registra ciò che esiste e non emette nulla; il secondo polling in poi segnala ciò che è nuovo.

22.6 Sorgente DICOM

DICOMSource riceve oggetti di imaging come un fornitore di servizio di classe C-STORE.

Ciò a cui un ospedale punta una modalità o un PACS. Mirth chiama questo il listener DICOM e fa solo C-STORE, quindi questo è parità piuttosto che un subset.

Definito come DICOMSource in internal/config.

22.6.1 listen

Listen è l'indirizzo su cui servire.

Obbligatorio. 104 è la porta DICOM registrata; 11112 è l'alternativa comune dove non è possibile eseguire il binding di una porta privilegiata.

22.6.2 ae_title

AETitle è il nome con cui questo endpoint si identifica.

Fortemente raccomandato piuttosto che obbligatorio e avvertito quando assente. L'accesso a un endpoint DICOM è spesso controllato solo dal titolo AE, quindi un endpoint che accetta qualsiasi titolo accetta tutto ciò che può raggiungerlo.

22.6.3 allowed_calling_ae

AllowedCallingAE elenca i titoli AE consentiti per la connessione.

Vuoto accetta qualsiasi chiamante.

Questo è il controllo di accesso che il DICOM ha effettivamente. Un PACS è solitamente configurato per accettare un titolo di chiamata denominato e rifiutare tutto il resto, e questo endpoint non aveva un equivalente: il titolo chiamato è stato controllato - che è il nome che il chiamante compone, quindi chiunque può inviarlo correttamente - mentre chi stava chiamando è stato registrato nel log e ignorato altrimenti.

Vuoto accetta ancora qualsiasi cosa, perché una modalità che nessuno ha elencato è lo stato normale di una prima installazione e rifiutare per impostazione predefinita romperebbe ogni distribuzione nel giorno uno. Avverte invece, e l'avvertimento nomina i titoli che si sono connessi in modo che qualcuno possa riempire questo elenco con ciò che è effettivamente arrivato.

22.6.4 sop_classes

SOPClasses limita i tipi di oggetto da accettare.

Vuoto accetta qualsiasi oggetto.

Vuoto è un valore predefinito ragionevole qui perché questo motore inoltra oggetti invece di interpretarli, quindi rifiutare una classe sconosciuta rifiuterebbe immagini valide senza alcun beneficio.

22.6.5 transfer_syntaxes

TransferSyntaxes limita le codifiche da accettare, nell'ordine di preferenza.

Vuoto accetta i tre non compressi.

22.6.6 max_object_bytes

MaxObjectBytes delimita un oggetto ricevuto.

Zero applica un valore predefinito.

22.6.7 idle_timeout

IdleTimeout chiude un'associazione che è diventata silenziosa.

Zero significa mai, che è solitamente corretto - una modalità mantiene un'associazione aperta tra gli studi.

22.6.8 tls

TLS crittografa le associazioni in entrata e può richiedere un certificato client.

Vale la pena affermarlo chiaramente: Mirth necessita della sua estensione SSL Manager a pagamento per questo, e le fork della community non possono spedirla affatto. DICOM trasporta i nomi dei pazienti nei suoi metadati, quindi questo è uno dei luoghi in cui essere una riscrittura piuttosto che una fork è un vero vantaggio piuttosto che uno stilistico.

22.7 Sorgente Mweb DICO

DICOMwebSource accetta richieste STOW-RS.

Definito come DICOMwebSource in internal/config.

22.7.1 listen

Listen è l'indirizzo su cui servire.

Required.

22.7.2 path

Percorso è la radice del servizio.

Gli oggetti sono accettati in Path/studies e Path/studies/{uid}. Di default è /dicom-web, che è ciò che utilizzano Orthanc e dcm4chee, quindi un mittente configurato per uno di essi ha bisogno solo di cambiare l'host.

22.7.3 token

Token, quando impostato, è richiesto come token bearer.

Username e Password richiedono autenticazione HTTP di base.

22.7.4 username

Token, quando impostato, è richiesto come token bearer.

Username e Password richiedono autenticazione HTTP di base.

22.7.5 password

Token, quando impostato, è richiesto come token bearer.

Username e Password richiedono autenticazione HTTP di base.

22.8 Sorgente del database

DatabaseSource legge le righe da un database e le trasforma in messaggi.

Questo è il modo in cui inizia la maggior parte delle interfacce ospedaliere. Un sistema di reparto non ha la capacità HL7, quindi qualcuno scrive righe in una tabella di staging e il motore di interfaccia la interpella. È poco glamour e si trova ovunque.

È anche il modo più comune in cui un canale Mirth si blocca, e il motivo è quasi sempre della stessa forma: una riga che non può essere elaborata viene letta, fallisce e viene letta di nuovo, all'infinito, perché nulla l'ha segnalata. Il canale sembra vivo. La coda sembra vuota. Nulla si muove e ogni messaggio dietro la riga cattiva aspetta una riga che non avrà mai successo.

La maggior parte della progettazione qui è su questo.

Definito come DatabaseSource in internal/config.

22.8.1 driver

Driver nomina il database.

See SupportedDrivers.

22.8.2 dsn

DSN è la stringa di connessione.

Preferisci un riferimento a una variabile d'ambiente rispetto a un valore letterale, poiché questo contiene normalmente una password e i canali sono destinati a vivere in git.

22.8.3 query

La query seleziona le righe in attesa di essere inviate.

Required.

Deve essere un SELECT. Un'interrogazione che esegue silenziosamente scritture sarebbe in esecuzione su una pianificazione senza alcun record di cosa è stato modificato.

22.8.4 after_query

AfterQuery contrassegna una riga come elaborata ed esegue con la chiave della riga associata ad esso.

Strongly recommended.

Senza di esso, ogni interrogazione ri-legge ogni riga che la query ancora corrisponde, quindi la query stessa deve escludere le righe elaborate in qualche altro modo. Se nessuna delle due condizioni è vera, il canale rinviare le stesse righe all'infinito, il che è una tempesta di duplicati piuttosto che un blocco e potrebbe essere considerato peggiore.

22.8.5 key_column

KeyColumn identifica una riga per AfterQuery, quarantena e de-duplicazione.

Obbligatorio quando AfterQuery è impostato.

22.8.6 template

Il modello costruisce un messaggio da una riga.

È richiesto o questo o Colonna.

I riferimenti alle colonne utilizzano ${nome_colonna}. Le colonne mancanti sono un errore durante il caricamento piuttosto che una stringa vuota in un messaggio clinico.