EDI-решения для BizTalk

Обработка медицинских страховок с помощью BizTalk Server 2010

Марк Бекнер

В BizTalk Server 2010 полностью переработана архитектура платформы для управления обменом EDI-документами (Electronic Data Interchange) между компаниями-партнерами. Если вам доводилось работать с ранними версиями этой платформы, то, вероятно, вы сталкивались с некоторыми проблемами, настраивая обмен документами между различными сторонами. В последнем выпуске вы получаете полный контроль над организацией и конфигурацией параметров документов, относящихся к обмену между сторонами.

Кроме того, в BizTalk Server 2010 значительно усовершенствованы средства разработки карт (maps).

Чтобы продемонстрировать эти новые средства, я рассмотрю все этапы, необходимые для создания EDI-решения. Каждое такое решение, разрабатываемое в BizTalk Server 2010, соответствует базовому шаблону:

• добавление и модификация базовых схем EDI;
• создание сопоставлений (карт) между EDI-документом и внутренней/внешней системой обмена сообщениями;
• реализация управляющих элементов для рабочего процесса, связанного с обработкой EDI-документов;
• настройка параметров компаний-партнеров, в том числе сторон, бизнес-профилей, соглашений и подтверждений;
• конфигурирование портов для поддержки приема или доставки документов по FTP, AS2 или другому протоколу.

В целях демонстрации мы рассмотрим обмен документами между госпиталем и подразделением обработки страховок (claims-processing unit). Эти документы будут соответствовать требованиям закона об ответственности и переносе данных о страховании здоровья граждан (Health Insurance Portability and Accountability Act, HIPAA) и формату файлов 837 Professional и Institutional.

Работа со схемами

В большинстве EDI-решений вы будете работать с двумя базовыми типами схем: схемами EDI (представляют плоские файлы, которыми вы обмениваетесь с компаниями-партнерами) и внутренними (представляют типы документов для обработки данных внутри EDI-документов).

В моем примере решение обеспечивает обмен документами 837 с внешними сторонами, но для внутренней обработки использует другой формат документов. Внутренняя схема представляет плоский файл ECSIF: стандартный формат для обработчиков страховок (claims processors). Схемы 837, которые поставляются с BizTalk, можно добавлять в проекты Visual Studio, но внутренние схемы (например, ECSIF) нужно создавать вручную.

BizTalk Server 2010 поставляется с тысячами существующих схем, которые определяют большинство используемых в настоящее время EDI-документов. Чтобы получить доступ к этим схемам, запустите файл MicrosoftEdiXSDTemplates.exe в каталоге $\Program Files\Microsoft BizTalk Server 2010\XSD_Schema\EDI. Для целей этого примера я воспользуюсь схемами 837 Professional и Institutional, совместимыми с HIPAA, которые находятся в подкаталоге HIPAA\00501. Добавляя XSD-файл в проект Visual Studio, вы обеспечиваете возможность ссылок на него и использование другими компонентами BizTalk, в том числе, что самое важное, картами (maps).

Схема 837 Professional 5010 в Visual Studio 2010 показана на рис. 1.Обратите внимание на количество узлов в этой схеме: 837 — один из самых сложных EDI-документов, и работа с ним может оказаться крайне трудной. В схеме содержатся сотни почти одинаковых узлов, представляющих информацию о подписчике и пациенте.

Рис. 1. Схема 837 Professional 5010

На рис. 2 показана внутренняя схема, представляющая формат ECSIF. Эта схема сгенерирована с помощью мастера Flat File Schema. Этому мастеру можно указать допустимый экземпляр плоского файла, и он создаст XSD. В этой схеме можно повышать уровень (promote) ряда полей в узле FileHeader. Поля с повышенным уровнем (promoted fields) обеспечивают поддержку расширенных параметров фильтрации и сопоставления.

Рис. 2. Целевой формат схемы ECSIF

Как только схема определена и добавлена в проект Visual Studio, можно приступать к формированию карт. В данном случае я рассмотрю несколько сценариев, полезных при сопоставлении документа 837.

Разработка карт

Интерфейс сопоставления в BizTalk Server 2010 основательно переработан и теперь обладает целым рядом новых возможностей. К ним относятся масштабирование (zooming), автоматическое сопоставление узлов (automatic node matching) и средства поиска. Одно из наиболее заметных усовершенствований заключается в том, что вы можете щелкнуть какую-либо строку или функтоид и после этого все остальные сопоставления уйдут на задний план.

Как известно любому разработчику EDI-карт, некоторые из них становятся чрезвычайно сложными, с несколькими вкладками и десятками (если не сотнями) функтоидов. Найти в схеме-источнике какие данные соответствуют данным в схеме-мишени и какие функтоиды используются для соответствующий сопоставлений, может быть очень трудно — равно как и визуализировать все это. А теперь, когда вы щелкаете любую из строк или любой из применяемых функтоидов, автоматически выделяются все релевантные сопоставления.

Пример сложной карты с выделенным набором логики сопоставления показан на рис. 3. Это подводит нас к такой точке в разработке карт BizTalk, которую многие часто упускают из виду: есть случаи, когда нужно обязательно использовать интерфейс сопоставления, и есть случаи, когда делать этого не следует. Не все, что делается в BizTalk, является наилучшим для стандартного сопоставления — иногда эффективнее альтернативные подходы. К таковым относятся написание подставляемых скриптов (inline scripting) и использование внешних компонентов, в том числе компонентов XSLT и Microsoft .NET Framework.

Рис. 3. Возможности выделения релевантных элементов в картах BizTalk Server 2010

Разработка карт BizTalk включает в основном использование стандартных функтоидов, а также подставляемого кода XSLT и C#. В некоторых ситуациях даже считается в порядке вещей вызов внешней таблицы стилей XSLT (что приводит к полному обходу маппера BizTalk). Карты EDI могут усложниться, и для них может потребоваться изобретательность и планирование для получения необходимого решения.

Чтобы проиллюстрировать применение подставляемого C#-кода, рассмотрим функцию сопоставления исходящего файла 837 Professional или Institutional, а именно: сопоставление иерархических (hierarchical, HL) сегментов. HL-сегменты требуют наличия инкрементальных значений для каждой записи в файле и обозначают отношения «предок-потомок». Комбинации стандартных функтоидов, которая позволила бы корректно задавать эти значения, на самом деле нет. Зато с этой целью можно просто воспользоваться подстановкой кода на C#. В этом случае потребуются два функтоида, поддерживающие скрипты: один из них будет содержать глобальную переменную и сопоставлять HL01, а второй — HL02 (зависимый от значений HL01).

Функтоидный скрипт HL01 выглядит так:

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

А это код для скрипта HL02:

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

На рис. 4 показаны функтоиды, помещенные в карту.

Рис. 4. Сопоставление HL-сегмента в исходящем документе 837

Другая ситуация, часто возникающая при сопоставлении EDI-документов, — потребность в подстановке XSLT. Это один из важнейших элементов при создании карт BizTalk, и вы должны уметь им пользоваться. XSLT обеспечивает поддержку многих вариаций циклов и создания узлов, которые просто недоступны при использовании комбинаций стандартных функтоидов.

Один из примеров с подстановкой XSLT — карта на рис. 5. Этот код демонстрирует, как применять функциональность шаблона Inline XSLT Call Template для передачи параметра из документа-источника (Name) и создания узла в целевом документе 837.

Рис. 5. Передача параметров скрипту Inline XSLT Call Template

Разрабатывая карту BizTalk, всегда думайте об удобстве ее сопровождения в долгосрочной перспективе. Сможете ли вы легко обновлять ее? Будет ли с ней работать впоследствии кто-то другой? При работе с картами BizTalk не забывайте и о принятых стилях кодирования, а при создании карт, содержащих большие объемы логики или сложной функциональности, нужно уделять внимание их архитектуре и планированию.

Управляющие элементы

Использовать управляющие элементы (orchestrations)* в EDI-решениях не обязательно. Обычно документы нужно просто преобразовать из одного формата в другой и доставить адресату.

Однако в некоторых случаях перед доставкой документа может потребоваться несколько стадий обработки. Чтобы проиллюстрировать это, я подготовлю управляющий элемент для преобразования и архивации сообщений в таблицу SQL Server. Этот управляющий элемент будет сконфигурирован с помощью фильтра, который будет разрешать обработку лишь документов определенного типа.

Управляющий элемент можно настроить на подписку почти на любое поле в пределах ISA- или ST-сегментов EDI-документа. Чтобы сконфигурировать управляющий элемент на подписку на определенное поле в документе, можно задать фильтр, как показано на рис. 6.

Рис. 6. Установка фильтра в управляющий элемент

После указания фильтра управляющий элемент сможет выполнять необходимую обработку EDI-документа. В данном случае управляющий элемент будет преобразовывать данные из формата 837 в ECSIF, а затем записывать полученную информацию в архивную таблицу в SQL Server. Преобразование документов осуществляется по шаблону преобразования (transform shape) и включением файла карты, но при записи информации в SQL Server доступен ряд вариантов.

Размышляя о SQL Server, многие разработчики для BizTalk предполагают, что для записи в SQL понадобится один из доступных адаптеров. На самом деле в большинстве случаев адаптеры для SQL чрезмерно сложны для элементарных обращений к базе данных. В целом, самый простой и наиболее удобный в поддержке способ взаимодействия с SQL Server — применение собственного .NET-класса в виде сборки. Создавая классы, которые будут вызываться из управляющего элемента, всегда помечайте их как сериализуемые, чтобы BizTalk мог обращаться к ним из любого типа транзакционного состояния:

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

Разработка управляющих элементов для EDI-решений ничем не отличается от других видов разработки для BizTalk. Главное, что следует помнить при создании управляющих элементов, — не усложнять их без нужды. Важно должным образом организовывать проекты BizTalk. Если вы уделяли тщательное внимание планированию и разработке, то в конечном счете создадите решение, которое будет легко обновлять и развертывать в производственной среде.

Конфигурации компаний-партнеров

В BizTalk Server 2010 введен новый интерфейс для управления обменом EDI-документами между компаниями-партнерами. Он охватывает три основных уровня организации: сторону (party), бизнес-профиль и соглашение.

Сторона представляет организацию верхнего уровня партнера. Конфигурации на этом уровне относятся к общим элементам во всех документах, которыми вы обмениваетесь с компанией-партнером. Например, сертификаты, которые могут потребоваться для защищенных коммуникаций, конфигурируются на этом уровне.

В моем примере две стороны: обработчик страховок и госпиталь. Каждая из них настраивается как уникальная сторона BizTalk. Для этого достаточно указать название, как показано на рис. 7.

Рис. 7. Конфигурация стороны

Со стороной сопоставляется один или более бизнес-профилей. Бизнес-профиль представляет отдел внутри организации, использующий уникальную бизнес-идентификацию при отправке или приеме EDI-документов. Бизнес-идентификация — это значение, которое содержится в сегменте ISA06 или ISA08 EDI-документа (в зависимости от того, посылается или принимается документ) и уникально отличает партнера от всех остальных сущностей. Многие организации имеют единственный бизнес-профиль, но некоторым требуется множество профилей.

В моем примере обработчик страховок имеет два бизнес-профиля: один представляет обработку страховок Professional, а второй — обработку заявок Institutional. У госпиталя тоже два бизнес-профиля: национальный и международный. Стороны со своими бизнес-профилями показаны на рис. 8.

Рис. 8. Бизнес-профили, сопоставленные со сторонами

Поскольку бизнес-профиль представляет уникальную бизнес-идентификацию стороны, конфигурации на этом уровне содержат информацию, общую для всех документов, которыми обмениваются с этой идентификацией. При этом конфигурируются параметры входящих и исходящих документов, которая являются общими для всех типов пересылаемых документов: используемые протоколы (X12, EDIFACT, AS2), параметры проверки, транзакционные наборы (на этом уровне допускаются EDI-документы), подтверждения (acknowledgments) и некоторые параметры конвертов. Во многих случаях на этом уровне можно применять информацию по умолчанию, так как дальнейшая детализация определяется конфигурацией конкретных соглашений для бизнес-профиля.

С бизнес-профилем может быть сопоставлено одно или более соглашений. Соглашение представляет способ, которым стороны обмениваются одним или более типами документов. Именно здесь определяется специфика конверта, подтверждений и разрешенных транзакционных наборов. Одно соглашение может разрешать обмен определенными документами с подтверждениями 997, а другое — обмен документами других типов без подтверждений.

В моем примере документами обмениваются обработчик страховок и госпиталь. Госпиталь посылает заявку (X12 837 Institutional версии 5010) обработчику, а тот отправляет госпиталю подтверждение (X12 997). Конфигурация идентификатора конверта показана на рис. 9, а конфигурация транзакционного набора в соглашении по документам, передаваемым от госпиталю обработчику страховок, — на рис. 10. Обратите внимание на вкладки вверху окна, указывающие на направление передачи документа.

Рис. 9. Настройка параметров ISA-конверта в соглашении

Рис. 10. Настройка транзакционных наборов в соглашении

На рис. 11 приведена конфигурация подтверждений, передаваемых обработчиком страховок госпиталю.

Рис. 11. Настройка подтверждений в соглашении

Если вы обмениваетесь документами более чем с одним партнером, то скорее всего обнаружите, что большинство ваших конфигураций практически идентичны; единственное, что будет меняться, — идентификаторы в ISA-сегменте конверта.

Чтобы упростить разработку, используйте функциональность шаблонов, доступную на экране настройки соглашения. Вас должны заинтересовать две кнопки: Save As Template и Load From Template. Если вы полностью сконфигурировали партнера и если EDI-документы передаются между вами с правильными настройками конверта и подтверждениями, просто сохраните настройки соглашения как шаблон и используйте их в качестве отправной точки для будущих соглашений.

Конфигурации портов и доставка документов

Прием или передача документов от внешних партнеров в BizTalk осуществляется с помощью конфигурации портов. Порт определяет тип механизма доставки (FTP, файл и т. д.) и сопоставляется с конвейером BizTalk, который преобразует XML-документ в BizTalk в плоский файл формата EDI-документа, ожидаемого компаниями-партнерами. В конвейере содержится логика для интерпретации (или создания) EDI-конверта в документе и для определения того, какой стороне адресован документ.

Чтобы понять, как эти порты обрабатывают EDI-документы, рассмотрим отправку подтверждения. Как вы уже видели, подтверждения конфигурируются в соглашениях стороны BizTalk. При получении документа BizTalk может автоматически генерировать подтверждение 997. При этом BizTalk создает XML-сообщение формата 997 и помещает его в ящик сообщений (message box) BizTalk, но на самом деле никуда не направляет это сообщение. Нужно настроить порт отправки (send port) и сконфигурировать преобразование XML в плоский файл, добавить конверт и доставить его по соответствующему адресу.

Настройка порта отправки для доставки подтверждения требует трех основных этапов.

1. Определение порта отправки и протокола доставки.
2. Включение конвейера EdiSend (или собственного конвейера с компонентами конвейера EDI).
3. Конфигурации фильтров для прослушивания соответствующих подтверждений.

Конфигурирование порта отправки для доставки документов по определенному адресу достаточно прямолинейно. На рис. 12 показан порт отправки, сконфигурированный с помощью конвейера EdiSend. Этот порт отправки будет записывать файлы в файловый каталог с полным EDI-конвертом и необходимым форматированием.

Рис. 12. Настройка конвейера и информации доставки для порта

Задать фильтр для порта отправки тоже нетрудно.Вы просто указываете, что он должен отбирать подтверждения, генерируемые системой для данного партнера (в противоположность входящим сообщениям 997 от партнера). На рис. 13 показан полностью сконфигурированный набор фильтров.

Рис. 13. Фильтрация на порту отправки

Задача решена

Новая функциональность EDI в BizTalk Server 2010 сконцентрирована в основном в управлении компаниями-партнерами. Иерархические связи и организации, поддержка которых отсутствовала в предыдущих выпусках платформы, теперь можно относительно легко моделировать. Кроме того, расширен интерфейс сопоставления, а создание карт значительно упрощено. Благодаря разнообразным усовершенствованиям и расширенной функциональности BizTalk Server 2010 позволяет моделировать и успешно реализовать любое EDI-решение.

Марк Бекнер (Mark Beckner) — учредитель Inotek Consulting Group LLC. Специализируется в области ряда технологий Microsoft, в том числе BizTalk, SharePoint, Dynamics CRM и общих задач .NET-разработки. С ним можно связаться по адресу mbeckner@inotekgroup.com.