Soluzioni EDI di BizTalk

Elaborazione di richieste di rimborso per spese mediche con BizTalk Server 2010

Mark Beckner

In BizTalk Server 2010 viene introdotta una piattaforma completamente rinnovata per gestire lo scambio di documenti EDI (Electronic Data Interchange) tra partner commerciali. Chi ha già utilizzato edizioni precedenti della piattaforma si sarà sicuramente trovato in difficoltà nel tentativo di configurare lo scambio di documenti tra varie entità. Con la nuova edizione gli utenti possono disporre del controllo completo sull'organizzazione e sulla configurazione delle impostazioni per l'interscambio di documenti.

BizTalk Server 2010 garantisce inoltre un'esperienza avanzata per quanto riguarda lo sviluppo di mappe.

Per presentare queste nuove funzionalità, in questo articolo verranno fornite indicazioni dettagliate per la compilazione di una soluzione EDI Ogni soluzione EDI sviluppata in BizTalk Server 2010 segue uno schema di base:

• Aggiunta e modifica di schemi EDI di base.
• Creazione di mappe tra un documento EDI e la messaggistica interna/esterna.
• Implementazione di orchestrazioni per gestire un flusso di lavoro associato all'elaborazione di documenti EDI.
• Configurazione di impostazioni di partner commerciali, tra cui entità, profili di business, contratti e riconoscimenti.
• Configurazione di porte per consentire la ricezione o il recapito di documenti tramite FTP, AS2 o altri protocolli.

Ai fini di questa spiegazione verrà esaminato lo scambio di documenti tra un ospedale e un'unità di elaborazione di richieste di rimborso. Tra le entità verranno scambiati file 837 Professional e Institutional conformi all'Health Insurance Portability and Accountability Act (HIPAA).

Utilizzo di schemi

Nella maggior parte delle soluzioni EDI verranno utilizzati due tipi di schemi di base: gli schemi EDI che rappresentano i file flat scambiati con i partner commerciali e gli schemi interni che rappresentano i tipi di documenti necessari per elaborare i dati nel documento EDI.

In questo esempio la soluzione scambierà i documenti 837 con le entità esterne, ma utilizzerà un formato di documento diverso per l'elaborazione interna. Lo schema interno rappresenta un file flat ECSIF, un formato comune per gli elaboratori di richieste di rimborso. Gli schemi 837 inclusi in BizTalk possono essere aggiunti a un progetto Visual Studio, mentre gli schemi interni (ad esempio, un file ECSIF) devono essere compilati manualmente.

BizTalk Server 2010 include migliaia di schemi esistenti che costituiscono la maggior parte dei documenti EDI attualmente in uso. Per accedere agli schemi, eseguire il file MicrosoftEdiXSDTemplates.exe nella directory $\Programmi\Microsoft BizTalk Server 2010\XSD_Schema\EDI. In questo esempio verranno utilizzati gli schemi 837 Professional e Institutional conformi all'HIPAA, disponibili nella cartella HIPAA\00501. L'aggiunta del file XSD a un progetto Visual Studio ne consente il riferimento e l'utilizzo da parte di altri componenti BizTalk e in particolar modo dalle mappe.

Nella Figura 1 è illustrato lo schema 837 Professional 5010 in Visual Studio 2010. Osservare il numero di nodi nello schema: l'837 è uno dei documenti EDI più complessi da utilizzare e contiene centinaia di nodi praticamente identici che rappresentano le informazioni dei sottoscrittori e dei pazienti.

Figura 1 Schema 837 Professional 5010

Nella Figura 2 è illustrato lo schema interno che rappresenta il formato ECSIF. Questo schema è stato generato mediante la Procedura guidata Schema file flat. La procedura può essere puntata a un'istanza valida di file flat per creare un file XSD. Nello schema è stato innalzato di livello un numero di campi nel nodo FileHeader. I campi innalzati di livello consentono di utilizzare filtri avanzati e opzioni di mapping.

Figura 2 Formato di schema ECSIF di destinazione

Una volta definiti e aggiunti gli schemi al progetto Visual Studio, sarà possibile iniziare a compilare le mappe. In questo caso verranno illustrati diversi scenari utili per il mapping di un documento 837.

Sviluppo di mappe

L'interfaccia di mapping in BizTalk Server 2010 è stata ampiamente revisionata e contiene un'ampia gamma di nuove funzionalità, tra cui lo zoom, la corrispondenza automatica dei nodi e le funzionalità di ricerca. Uno di principali miglioramenti consiste nella possibilità di selezionare una riga o un functoid per spostare sullo sfondo tutti gli altri mapping.

Gli sviluppatori di mappe EDI sanno bene che alcune mappe possono diventare decisamente complesse, con varie schede e decine (se non centinaia) di functoid. Può risultare difficile individuare per quali dati nelle mappe degli schemi di origine viene eseguito il mapping ad altri dati nello schema di destinazione o quali functoid vengo utilizzati per eseguire questa operazione. Selezionando una riga o un functoid qualsiasi utilizzato, verranno evidenziati tutti i mapping correlati.

Nella figura Figure 3 viene illustrato un esempio di una mappa complessa con un set specifico di logica di mapping evidenziata. A questo punto emerge un dibattito relativo a una situazione spesso trascurata in fase di sviluppo di mappe BizTalk: l'interfaccia delle mappe può essere utilizzata solo in alcuni casi. Il mapping standard non è sempre valido per tutti i mapping effettuati in BizTalk. A volte è opportuno ricorrere a un approccio alternativo, ad esempio l'esecuzione di script inline e i componenti esterni (XSLT e Microsoft .NET Framework, per citarne alcuni).

Figura 3 Funzionalità di evidenziazione nelle mappe di BizTalk Server 2010

Lo sviluppo di mappe BizTalk è in genere costituito da una combinazione di functoid standard e XSLT e C# inline. In alcune situazioni può risultare opportuno ricorrere a un foglio di stile XSLT esterno (che ignora il mapper di BizTalk). Le mappe EDI possono diventare complesse e richiedere un certo livello di pianificazione per creare la soluzione necessaria.

Per illustrare l'utilizzo del codice C# inline, osserviamo una funzione comune di mapping di un file 837 Professional o Institutional in uscita: il mapping di segmenti gerarchici (HL). Questi segmenti richiedono valori incrementali per ogni record nel file e denotano relazioni padre/figlio. Nessuna combinazione di functoid tradizionale consente una configurazione appropriata di questi valori. A tale scopo è quindi opportuno ricorrere a un semplice approccio C# inline, che richiede due functoid per l'esecuzione di script: uno per l'archiviazione di una variabile globale che esegue il mapping di HL01, l'altro che esegue il mapping di HL02 (in base al valore di HL01).

Lo script di functoid HL01 è simile al seguente:

int intHL01;
  public int getHL01() {
  intHL01++;
  return intHL01;
  }

Di seguito viene riportato lo script HL02:

public int getHL02() {
  return intHL01 -1;
  }

Nella Figura 4 vengono illustrati i functoid nella mappa.

Figura 4 Mapping di un segmento HL in un file 837 in uscita

Un'altra situazione piuttosto frequente in fase di mapping di documenti EDI è rappresentata dalla necessità di utilizzare XSLT inline. Si tratta di una delle competenze più importanti da incorporare nel mapping di BizTalk, in quanto consente l'utilizzo di molte opzioni relative ai cicli e alla creazione di nodi non disponibili mediante le combinazioni standard di functoid.

Nella Figura 5 è illustrato un esempio di utilizzo di XSLT inline in una mappa. Questo codice consente di utilizzare la funzionalità Modello chiamata inline XSLT a cui passare un parametro dal documento di origine (Name) e creare un nodo nel documento 837 di destinazione.

Figura 5 Passaggio di parametri a uno script Modello chiamata inline XSLT

In fase di sviluppo di una mappa BizTalk è sempre opportuno tenere in considerazione la manutenibilità a lungo termine. Si tratta di un elemento semplice da aggiornare o che altri potranno utilizzare in futuro? È necessario utilizzare un approccio di codifica appropriato in caso di utilizzo di mappe BizTalk, oltre a considerare un certo livello di architettura e pianificazione in caso di sviluppo di mappe che includono logica o funzionalità complesse.

Orchestrazioni

Non è obbligatorio utilizzare orchestrazioni nelle soluzioni EDI. Spesso è sufficiente recapitare i documenti, dopo averne eseguito il mapping da un formato a un altro, senza introdurre flussi di lavoro.

A volte è tuttavia necessario eseguire diversi passaggi di elaborazione prima di poter recapitare un documento. Per illustrare questa condizione verrà configurata un'orchestrazione per il mapping e l'archiviazione di messaggi in una tabella in SQL Server. L'orchestrazione verrà configurata con un filtro per garantire la sola elaborazione di documenti di un certo tipo.

È possibile configurare l'orchestrazione per la sottoscrizione a qualsiasi campo nei segmenti ISA o ST di un documento EDI (oltre a molte altre proprietà). Per configurare la sottoscrizione a un campo specifico di un documento, è possibile configurare un filtro nella forma Ricezione iniziale dell'orchestrazione, come illustrato nella Figura 6.

Figura 6 Impostazione di un filtro in un'orchestrazione

Una volta specificato il filtro, l'orchestrazione potrà procedere con l'elaborazione necessaria del documento EDI. In questo caso l'orchestrazione eseguirà il mapping dei dati dal formato 837 al formato ECSIF e quindi scriverà le informazioni in una tabella di archivio in SQL Server. Il mapping dei documenti viene eseguito mediante una forma Trasforma e l'inclusione di un file di mappa, ma per la scrittura di informazioni in SQL Server sono disponibili varie opzioni.

Quando si tratta di SQL Server, molti sviluppatori di BizTalk ritengono che sia necessario utilizzare un adapter SQL disponibile per la scrittura in SQL. In realtà, nella maggior parte dei casi, gli adapter SQL sono estremamente complessi per le chiamate di base al database. In genere l'approccio più semplice e sostenibile per l'interazione con SQL Server è rappresentato dall'utilizzo di una classe di assembly .NET personalizzata. In caso di sviluppo di classi che verranno chiamate dall'orchestrazione, è opportuno contrassegnare la classe come serializzabile per fare in modo che possa essere chiamata da BizTalk da qualsiasi tipo di stato di transazione:

namespace Demo.BizTalk.Helper {
    [Serializable]
    public class DataAccess
    { }
  }

Lo sviluppo di orchestrazioni per soluzioni EDI non è diverso da quello per altri tipi di implementazioni BizTalk. È essenziale ricordare che, in caso di sviluppo di orchestrazioni, la parola d'ordine è: semplicità. Lo sviluppo BizTalk e l'organizzazione efficace di progetti BizTalk sono una vera e propria arte. Una pianificazione e uno sviluppo appropriati determineranno una soluzione semplice da aggiornare e distribuire in un ambiente di produzione.

Configurazione di partner commerciali

In BizTalk Server 2010 viene introdotta una nuova interfaccia per gestire lo scambio di documenti EDI tra partner commerciali. L'interfaccia è costituita da tre livelli di organizzazione di base: l'entità, il profilo di business e il contratto.

L'entità rappresenta l'organizzazione di livello superiore del partner commerciale. Le configurazioni vengono effettuate tra gli elementi in comune con tutti i documenti scambiati con questo partner commerciale. Ad esempio, in questo livello possono essere configurati i certificati necessari per le comunicazioni protette.

Nel mio esempio sono presenti due entità: l'elaboratore di richieste di rimborso e l'ospedale, entrambe configurate come singole entità BizTalk. È necessario configurare solo il nome, come illustrato nella Figura 7.

Figura 7 Configurazione dell'entità di livello superiore

A un'entità saranno associati uno o più profili di business. Il profilo di business rappresenta un reparto di un'organizzazione con una specifica identità di business in fase di invio o ricezione di documenti EDI. Un'identità di business rappresenta il valore visualizzato nel segmento ISA06 o ISA08 di un documento EDI (a seconda che il documento venga inviato o ricevuto) e identifica in modo univoco il partner commerciale rispetto a tutte le altre entità. Molte organizzazioni presentano un solo profilo di business, altre necessiteranno di più profili.

Nel mio esempio l'elaboratore di richieste di rimborso presenta due profili di business: uno rappresenta l'elaborazione di richieste di rimborso professionali, l'altro rappresenta l'elaborazione di richieste di rimborso istituzionali. Anche l'ospedale presenta due profili di business: la succursale nazionale e quella internazionale. Nella Figura 8 sono illustrate le entità con i rispettivi profili di business.

Figura 8 Profili di business associati alle entità

Poiché il profilo di business rappresenta un'identità di business univoca in un'entità, le configurazioni in questo livello riguardano le informazioni comuni tra tutti i documenti scambiati con l'identità. Verranno configurate tutte le impostazioni in ingresso e uscita comuni tra tutti i tipi di documenti scambiati: protocolli utilizzati (X12, EDIFACT, AS2), impostazioni di convalida, set di transazioni (documenti EDI consentiti in questo livello), riconoscimenti e impostazioni della busta configurati in un profilo di business. In molti casi è possibile utilizzare le informazioni predefinite in questo livello, in quanto la configurazione dei contratti specifici di un profilo di business definirà queste e altre informazioni.

Un profilo di business può disporre di uno o più contratti. Un contratto rappresenta il mezzo con cui due entità prevedono di scambiare reciprocamente uno o più tipi di documenti. In questo elemento vengono definiti i set di transazione, i riconoscimenti e le specifiche sulla busta. Un contratto può consentire lo scambio di determinati documenti con riconoscimenti 997 configurati, un altro può consentire ad altri tipi di documenti di ignorare i riconoscimenti.

Nel mio esempio l'elaboratore di richieste di rimborso e l'ospedale scambiano documenti: l'ospedale invierà la richiesta (X12 837 Institutional versione 5010) all'elaboratore, che a sua volta invierà un riconoscimento (X12 997) all'ospedale. Nella Figura 9 è illustrata la configurazione dell'ID della busta e nella Figura 10 la configurazione del set di transazioni nel contratto per i documenti inviati dall'ospedale all'elaboratore di richieste. Osservare le schede nella parte superiore della finestra che indicano il flusso del documento.

Figura 9 Configurazione delle impostazioni della busta ISA in un contratto

Figura 10 Configurazione dei set di transazioni in un contratto

Nella Figura 11 è illustrata la configurazione dei riconoscimenti inviati dall'elaboratore di richieste all'ospedale.

Figura 11 Configurazione dei riconoscimenti in un contratto

In caso di scambio di documenti con più di un partner commerciale, la maggior parte delle configurazioni risulterà praticamente invariata. L'unica modifica consisterà negli ID nel segmento ISA della busta.

Per semplificare il processo di sviluppo, accertarsi di utilizzare la funzionalità di modello disponibile nella schermata di configurazione del contratto. Due pulsanti sono di particolare interesse: Salva come modello e Carica da modello. In caso di un partner commerciale completamente configurato, se i documenti EDI vengono inviati dall'origine alla destinazione con le impostazioni della busta e i riconoscimenti corretti, sarà sufficiente salvare le impostazioni del contratto come modello da utilizzare come base per contratti futuri.

Configurazioni di porte e recapito di documenti

Il recapito effettivo di documenti a BizTalk o a partner commerciali esterni viene eseguito tramite la configurazione di porte. La porta definisce il tipo di meccanismo di recapito (FTP, file e così via) e contiene la pipeline BizTalk che trasforma il documento XML all'interno di BizTalk nel documento EDI file flat previsto dai partner commerciali. La pipeline contiene la logica per interpretare (o creare) la busta EDI in un documento e per determinare l'entità in cui si risolve il documento.

Per comprendere in che modo le porte elaborano i documenti EDI, analizziamo l'invio di un riconoscimento. Come già osservato in precedenza, i riconoscimenti vengono configurati nei contratti di un'entità BizTalk. Alla ricezione di un documento, BizTalk può generare automaticamente un riconoscimento 997. In poche parole, BizTalk crea il documento XML 997 e lo recapita nel MessageBox di BizTalk, senza effettivamente instradarlo. È necessario configurare una porta di trasmissione per convertire il documento XML in un file flat, aggiungere la busta e recapitarlo alla destinazione appropriata.

La configurazione della porta di trasmissione per il recapito di un riconoscimento richiede tre passaggi di base:

1. Definizione della porta di trasmissione e del protocollo di recapito
2. Inclusione della pipeline EdiSend (o di una pipeline personalizzata con i componenti della pipeline EDI)
3. Configurazione di filtri per l'ascolto dei riconoscimenti appropriati

La configurazione della porta di trasmissione per il recapito di documenti a una destinazione specifica è semplice. Nella Figura 12 è illustrata una porta di trasmissione configurata con la pipeline EdiSend. La porta di trasmissione scriverà i file in una directory con la formattazione e la busta EDI corrette.

Figura 12 Configurazione delle informazioni di recapito e della pipeline in una porta

Anche l'impostazione del filtro nella porta di trasmissione è un'operazione semplice: è sufficiente specificare di prelevare esclusivamente i riconoscimenti generati dal sistema per un determinato partner commerciale (in contrapposizione ai documenti 997 in ingresso dal partner). Nella Figura 13 è illustrato un set di filtri completamente configurato.

Figura 13 Filtri in una porta di trasmissione

Problema risolto

La nuova funzionalità EDI di BizTalk Server 2010 è incentrata essenzialmente sulla gestione dei partner commerciali. Le organizzazioni e le relazioni gerarchiche impossibili nelle edizioni precedenti della piattaforma possono ora essere modellate con una certa semplicità. Sono state inoltre ottimizzate l'interfaccia della mappa e l'esperienza di mapping per gli sviluppatori. Grazie a questi miglioramenti e all'ottimizzazione di alcune funzionalità, è possibile modellare e sviluppare al meglio qualsiasi soluzione EDI con BizTalk Server 2010.

Mark Beckner è il fondatore di Inotek Consulting Group LLC e lavora per diversi team Microsoft, tra cui BizTalk, SharePoint, Dynamics CRM e in generale sullo sviluppo .NET. È possibile contattarlo all'indirizzo mbeckner@inotekgroup.com.