BizTalk EDI Solutions

  • 아티클

BizTalk Server 2010을 사용한 의료업계 클레임 처리

Mark Beckner

BizTalk Server 2010에는 거래 업체 간에 EDI(전자 데이터 교환) 문서 교환을 관리하기 위한 완전히 새로 설계된 아키텍처가 도입되었습니다. 이전 버전의 플랫폼을 사용해 보았다면 다양한 파티 간에 문서 교환을 설정하면서 다양한 문제를 경험해 보았을 것입니다. 최신 릴리스에서는 파티 간에 교환 가능한 모든 항목과 관련된 문서 설정의 구조와 구성을 완벽하게 제어할 수 있습니다.

BizTalk Server 2010은 또한 맵을 개발하는 훨씬 개선된 환경을 제공합니다.

EDI 솔루션을 구축하는 단계를 안내하면서 이러한 새로운 기능을 소개하겠습니다. BizTalk Server 2010에서 개발되는 모든 EDI 솔루션은 다음 기본 패턴을 따릅니다.

  • 기본 EDI 스키마 추가 및 수정.
  • EDI 문서 및 내부/외부 메시징 간의 맵 만들기.
  • EDI 문서 처리와 연결된 워크플로를 처리하는 오케스트레이션 구현.
  • 파티, 비즈니스 프로필, 규약 및 승인을 비롯하여 거래 업체 설정 구성.
  • FTP, AS2 또는 다른 프로토콜을 통해 문서 수신 및 전달을 활성화하는 포트 구성.

여기에서는 병원과 클레임 처리 기관 간의 문서 교환의 예를 살펴볼 것입니다. 파티 간에 교환되는 문서는 HIPAA(Health Insurance Portability and Accountability Act)-준수 837 Professional 및 Institutional 파일입니다.

스키마 작업

대부분의 EDI 솔루션에서는 거래 업체와 교환하는 플랫 파일을 나타내는 EDI 스키마와 EDI 문서 내의 데이터를 처리하기 위한 문서 유형을 나타내는 내부 스키마의 두 가지 기본적인 스키마 유형을 사용하게 됩니다.

이 솔루션 예에서는 외부 파티와 837 문서를 교환하지만 내부 처리를 위해 다른 문서 형식을 사용합니다. 내부 스키마는 클레임 처리 기관을 위한 일반적인 형식인 ECSIF 플랫 파일을 나타냅니다. 837 스키마는 BizTalk에서 제공되며 Visual Studio 프로젝트로 가져올 수 있지만 내부 스키마(예: ECSIF)는 직접 작성해야 합니다.

BizTalk Server 2010은 현재 사용되는 대부분의 EDI 문서를 정의하는 수천 가지의 기존 스키마를 제공합니다. 스키마에 액세스하려면 $\Program Files\Microsoft BizTalk Server 2010\XSD_Schema\EDI 디렉터리에 있는 MicrosoftEdiXSDTemplates.exe 실행 파일을 실행하면 됩니다. 이 예에서는 HIPAA\00501 폴더에 있는 837 Professional 및 Institutional HIPAA 준수 스키마를 사용할 것입니다. XSD 파일을 Visual Studio 프로젝트로 추가하면 다른 BizTalk 구성 요소, 특히 맵에서 이를 참조하고 사용할 수 있게 됩니다.

<strong>그림 1</strong>은 Visual Studio 2010에서 837 Professional 5010 스키마를 연 것입니다. 이 스키마의 노드 수에서 알 수 있듯이 837은 작업하기 극히 까다로운 가장 복잡한 EDI 문서 중 하나입니다. 이 문서에는 가입자와 환자 정보를 나타내는 거의 동일한 수백 개의 노드가 포함되어 있습니다.

image: The 837 Professional 5010 Schema

그림 1 837 Professional 5010 스키마

그림 2에는 ECSIF 형식을 나타내는 내부 스키마가 나옵니다. 이 스키마는 플랫 파일 스키마 마법사를 사용하여 생성한 것이며 마법사에서 유효한 플랫 파일 인스턴스를 참조하여 XSD를 만들 수 있습니다. FileHeader 노드의 여러 필드가 이 스키마에서 승격되었습니다. 승격된 필드는 개선된 필터링과 매핑 옵션을 가능하게 합니다.

image: The Target ECSIF Schema Format

그림 2 대상 ECSIF 스키마 형식

스키마를 정의하고 Visual Studio 프로젝트로 추가한 다음에는 맵 구축을 시작할 수 있습니다. 여기에서는 837 문서를 매핑하는 데 유용한 몇 가지 시나리오를 살펴보겠습니다.

맵 개발

BizTalk Server 2010의 매핑 인터페이스는 광범위하게 수정되었으며 다양한 새 기능이 도입되었습니다. 이러한 기능에는 확대/축소, 자동 노드 일치 및 검색 기능이 있습니다. 주목할 만한 기능 중 하나는 줄이나 펑토이드를 클릭하면 다른 모든 매핑을 배경으로 페이드할 수 있는 기능입니다.

EDI 맵 개발자라면 잘 알고 있겠지만 간혹 여러 탭과 펑토이드 수십 개(심지어 수백 개)를 포함하는 극히 복잡한 맵이 있습니다. 이 경우 원본 스키마의 어떤 데이터가 대상 스키마의 어떤 데이터에 매핑되는지, 그리고 이 매핑에 어떤 펑토이드가 사용되는지 시각화하기가 어렵습니다. 이 경우 사용되는 줄이나 펑토이드를 클릭하면 관련된 모든 매핑이 강조 표시됩니다.

그림 3에는 복잡한 맵에서 특정 매핑 논리 집합을 강조 표시한 예가 나옵니다. 여기에서 간과되기 쉬운 BizTalk 맵 개발의 한 가지 측면이 있는데, 맵 인터페이스를 사용해야 할 때와 그렇지 않아야 할 때가 있다는 것입니다. BizTalk에서 수행되는 모든 매핑에 표준 매핑이 적합한 것은 아니며 때로는 대안을 사용하는 것이 좋습니다. 대안에는 인라인 스크립팅과 XSLT 및 Microsoft .NET Framework 구성 요소를 포함한 외부 구성 요소가 포함됩니다.

그림 3 BizTalk Server 2010 맵의 강조 표기 기능

BizTalk 맵 개발은 일반적으로 표준 펑토이드 및 인라인 XSLT와 C#의 조합으로 이루어집니다. BizTalk 매퍼를 완전히 우회해서 외부 XSLT 스타일시트로 분리해야 하는 경우도 있습니다. EDI 맵은 복잡해질 수 있으며 필요한 솔루션을 구축하려면 머리를 쓰고 계획을 세워야 합니다.

아웃바운드 837 Professional 또는 Institutional 파일을 매핑하는 일반적인 함수(계층(HL) 세그먼트를 매핑)를 통해서 인라인 C#의 사용에 대해 알아보겠습니다. HL 세그먼트는 파일의 각 레코드에 증가하는 값을 필요로 하며 부모/자식 관계를 나타냅니다. 기존의 펑토이드 조합으로는 이러한 값을 제대로 설정할 수 없습니다. 그러나 간단한 인라인 C# 접근 방법으로 올바른 값을 얻을 수 있습니다. 이 방법을 사용하려면 스크립팅 펑토이드 두 개가 필요하며 하나는 전역 변수를 저장하고 HL01을 매핑하는 것이고, 다른 하나는 HL02(HL01의 값에 의존)를 매핑하는 것입니다.

HL01 펑토이드는 다음과 같습니다.

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

다음은 HL02 스크립트의 코드입니다.

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

그림 4에는 맵에 배치된 펑토이드가 나옵니다.

image: Mapping HL Segment on Outbound 837

그림 4 아웃바운드 837에 HL 세그먼트 매핑

EDI 문서의 매핑에서 자주 발생하는 다른 상황으로 인라인 XSLT를 사용해야 하는 경우가 있습니다. 이것은 BizTalk 매핑에 통합해야 하는 가장 중요한 기술 중 하나이며 반드시 익숙해져야 할 기술이기도 합니다. 표준 펑토이드의 조합으로는 불가능한 루프 및 노드 생성과 관련된 많은 옵션이 인라인 XSLT를 통해 가능합니다.

맵에서 인라인 XSLT를 사용하는 한 가지 예가 그림 5에 나옵니다. 이 코드는 인라인 XSLT 호출 템플릿 기능을 사용해서 원본 문서로부터 매개 변수(Name)를 전달하고 대상 837 문서에서 노드를 만드는 방법을 보여 줍니다.

image: Passing Parameters to an Inline XSLT Call Template Script

그림 5 인라인 XSLT 호출 템플릿 스크립트로 매개 변수 전달

BizTalk 맵을 개발할 때는 항상 맵의 장기적인 유지 관리를 고려해서 쉽게 업데이트할 수 있고 나중에 다른 사람이 사용할 수 있도록 해야 합니다. BizTalk 맵을 개발할 때도 바람직한 코딩 방법을 잊지 않아야 하며, 많은 양의 논리나 복잡한 기능이 포함된 맵을 개발할 때는 적절한 수준의 설계와 계획을 거쳐야 합니다.

오케스트레이션

EDI 솔루션에서 오케스트레이션을 반드시 사용할 필요는 없습니다. 워크플로를 포함할 필요 없이 문서를 한 형식에서 다른 형식으로 매핑하고 전달하면 되는 경우가 많습니다.

반면에 문서를 전달하기 전에 몇 가지 처리 단계를 거쳐야 하는 경우도 많습니다. 이를 설명하기 위해서 메시지를 SQL Server의 테이블로 매핑하고 아카이브하는 오케스트레이션을 설정해 보겠습니다. 이 오케스트레이션에는 특정한 유형의 문서만 처리되도록 하는 필터가 구성됩니다.

EDI 문서의 여러 속성 중에서도 ISA 또는 ST 세그먼트 내의 필드를 구독하도록 오케스트레이션을 설정할 수 있습니다. 문서의 특정 필드를 구독하도록 오케스트레이션을 구성하기 위해 그림 6에 나오는 것처럼 오케스트레이션의 초기 수신 셰이프에 필터를 설정할 수 있습니다.

image: Setting a Filter on an Orchestration

그림 6 오케스트레이션에 필터 설정

필터를 지정되면 오케스트레이션은 필요한 EDI 문서 처리를 수행할 수 있습니다. 여기에서 오케스트레이션은 데이터를 837 형식에서 ECSIF 형식으로 매핑하고 이 정보를 SQL Server의 아카이브 테이블에 기록합니다. 문서 매핑은 변형 셰이프와 맵 파일 포함을 통해 수행되지만, 정보를 SQL Server에 기록하는 데는 몇 가지 옵션을 선택할 수 있습니다.

BizTalk 개발자들은 SQL Server에 대해 생각할 때 데이터를 SQL로 기록하려면 어댑터 중 하나를 사용해야 한다고 가정하는 경우가 많습니다. 그러나 대부분의 경우 SQL 어댑터는 기본적인 데이터베이스 호출 용도로는 지나치게 복잡합니다. 일반적으로 SQL Server와 상호 작용하는 가장 쉽고 지원이 용이한 방법은 사용자 지정 .NET 어셈블리 클래스를 사용하는 것입니다. 오케스트레이션에서 호출될 클래스를 개발할 때는 클래스를 순차 가능으로 설정하여 BizTalk가 모든 트랜잭션 상태 유형에서 이를 호출할 수 있도록 하십시오.

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

EDI 솔루션을 위해 오케스트레이션을 개발하는 것 역시 다른 유형의 BizTalk 구현과 다르지 않습니다. 오케스트레이션을 개발할 때 기억할 가장 중요한 요점은 단순하게 유지하라는 것입니다. BizTalk 개발과 올바른 BizTalk 프로젝트의 구성은 정교한 작업입니다. 올바르게 계획하고 개발한다면 업데이트하기 쉽고, 프로덕션 환경으로 배포하기 쉬운 솔루션을 구축할 수 있을 것입니다.

거래 업체 구성

BizTalk Server 2010에는 거래 업체 간의 EDI 문서 교환을 관리하기 위한 새로운 인터페이스가 도입되었습니다. 이 인터페이스는 파티, 비즈니스 프로필 및 규약이라는 세 가지 기본적인 구성 계층으로 이루어져 있습니다.

파티는 거래 업체의 최상위 조직을 나타냅니다. 이 아티팩트의 구성은 이 거래 업체와 교환하는 모든 문서에서 공통적인 사항들과 관련됩니다. 예를 들어 보안 통신에 필요한 인증서를 이 수준에서 구성할 수 있습니다.

이 예에서는 클레임 처리 기관과 병원이라는 두 개의 파티가 있으며, 각각 고유한 BizTalk 파티로 설정됩니다. 여기에서는 그림 7에 나오는 것처럼 이름만 구성하면 됩니다.

image: Top-Level Party Configuration

그림 7 최상위 파티 구성

파티에는 하나 이상의 비즈니스 프로필이 연결됩니다. 비즈니스 프로필은 EDI 문서를 전송 및 수신할 때 고유한 자체 비즈니스 ID를 가지는 조직 내 부서를 나타냅니다. 비즈니스 ID는 EDI 문서의 ISA06 또는 ISA08 세그먼트(문서를 전송 또는 수신하는지에 따라)에 나오는 값으로서 거래 업체를 다른 모든 엔터티로부터 구분하는 데 사용됩니다. 단일 비즈니스 프로필을 가지는 조직이 많지만 프로필이 여러 개 요구되는 조직도 있습니다.

이 예에서 클레임 처리 기관은 비즈니스 프로필을 두 개 가지는데 하나는 전문가 Professional 처리를 나타내고, 다른 하나는 Institutional 클레임 처리를 나타냅니다. 병원 역시 두 개의 비즈니스 프로필을 가지며 각각 국내 지점과 국제 지점을 나타냅니다. 그림 8에는 해당 비즈니스 프로필을 포함한 파티가 나옵니다.

image: Business Profiles Associated with Parties

그림 8 파티와 연결된 비즈니스 프로필

비즈니스 프로필은 파티 내 고유한 비즈니스 ID를 나타내므로 이 수준의 구성으로 이 ID를 사용하여 교환하는 모든 문서의 공통적인 정보를 처리할 수 있습니다. 교환되는 모든 문서 유형에서 공통적인 모든 인바운드 및 아웃바운드 설정이 구성되며, 사용되는 프로토콜(X12, EDIFACT, AS2), 유효성 검사 설정, 트랜잭션 집합(이 수준에서는 EDI 문서가 허용됨), 승인 및 일부 봉투 설정이 모두 비즈니스 프로필에서 구성됩니다. 비즈니스 프로필의 특정한 규약의 구성에서 이 정보와 다른 항목을 정의하므로 이 수준에서 기본 정보가 사용되는 경우가 많습니다.

비즈니스 프로필은 하나 이상의 규약을 가집니다. 규약은 두 파티가 서로 하나 이상의 문서 유형을 교환하는 방식을 나타냅니다. 그리고 봉투, 승인 및 허용되는 트랜잭션 집합의 상세 내역이 정의되는 위치이기도 합니다. 한 규약은 997 승인이 구성된 특정한 문서의 교환을 허용하고, 다른 규약은 다른 문서 유형을 승인 없이 교환하도록 허용할 수 있습니다.

이 예에서는 클레임 처리 기관과 병원이 문서를 교환합니다. 병원은 클레임(X12 837 Institutional 버전 5010)을 클레임 처리 기관에 전송하고, 클레임 처리 기관은 승인(X12 997)을 병원에 전송합니다. 그림 9에는 봉투 식별자 구성이 나오며 그림 10에는 병원에서 클레임 처리 기관으로의 문서 흐름을 위한 규약의 트랜잭션 집합 설정 구성이 나옵니다. 상 위쪽의 탭에 문서 흐름이 표시되는 것을 볼 수 있습니다.

image: Configuring ISA Envelope Settings on an Agreement

그림 9 규약에서 ISA 봉투 설정 구성

image: Configuring Transaction Sets on an Agreement

그림 10 규약에서 트랜잭션 집합 구성

그림 11에는 클레임 처리 기관이 병원으로 전송하는 승인의 구성이 나옵니다.

image: Configuring acknowledgments on an Agreement

그림 11 규약에서 승인 구성

둘 이상의 거래 업체와 문서를 교환하는 경우 구성은 거의 동일하고 봉투의 ISA 세그먼트에 있는 식별자만 다른 경우가 많습니다.

개발의 편의를 위해서 규약 구성 화면에 있는 템플릿 기능을 사용하도록 하십시오. 여기에는 템플릿으로 저장 및 템플릿에서 로드라는 두 가지 흥미로운 단추가 있습니다. 거래 업체를 완전하게 구성하고 올바른 봉투 설정과 승인으로 EDI 문서를 종단 간으로 전송할 수 있도록 한 이후에는 간단하게 규약 설정을 템플릿으로 저장하여 향후 규약에서 시작점으로 사용할 수 있습니다.

포트 구성 및 문서 전달

BizTalk에서 외부 거래 업체로의 실제 문서 전달은 포트 구성을 통해 이루어집니다. 포트는 전달 메커니즘(FTP, 파일 등)을 정의하며 BizTalk 내의 XML 문서를 거래 업체가 예상하는 플랫 파일 EDI 문서로 변환하는 BizTalk 파이프라인을 포함합니다. 파이프라인에는 문서 상의 EDI 봉투를 해석(또는 생성)하고 문서가 확인되는 파티를 결정하는 논리가 포함됩니다.

포트가 EDI 문서를 처리하는 방법을 이해할 수 있도록 승인의 전송을 살펴보겠습니다. 앞서 보았듯이 승인은 BizTalk 파티의 규약에 구성됩니다. 문서가 도착하면 BizTalk는 자동으로 997 승인을 생성합니다. 그러면 BizTalk가 997 XML을 생성하여 BizTalk 메시지 상자에 전달하지만 실제 메시지를 다른 곳으로 라우팅하지는 않습니다. 송신 포트는 XML을 플랫 파일로 변환하도록 설정 및 구성해야 하고 이를 적절한 대상으로 배달하기 위한 봉투를 추가해야 합니다.

승인을 전달하도록 송신 포트를 설정하려면 세 가지 기본 단계를 수행해야 합니다.

  1. 송신 포트 및 배달 프로토콜 정의
  2. EdiSend 파이프라인(또는 EDI 파이프라인 구성 요소가 있는 사용자 지정 파이프라인)의 포함
  3. 해당하는 승인을 수신하도록 필터 구성

송신 포트를 구성하여 문서를 특정 위치로 전달하는 과정은 간단합니다. 그림 12에는 EdiSend 파이프라인을 사용하도록 구성한 송신 포트가 나옵니다. 송신 포트는 전체 EDI 봉투 및 형식 지정을 적용하고 파일 디렉터리에 파일을 작성합니다.

image: Setting Pipeline and Delivery Information on a Port

그림 12 포트의 파이프라인 및 배달 정보 설정

송신 포트에서 필터를 설정하기도 쉽습니다. 이 거래 업체의 시스템에서 생성한 승인(파트너에서 오는 997이 아닌)만 가져오도록 설정하면 됩니다. 그림 13에는 완전히 구성된 필터 집합이 나옵니다.

image: Filtering on a Send Port

그림 13 송신 포트에서 필터링

문제 해결

BizTalk Server 2010의 새 EDI 기능은 주로 거래 업체 관리에 집중되어 있습니다. 플랫폼의 이전 버전에서는 불가능했던 계층 관계 및 구성을 이제는 비교적 수월하게 모델링할 수 있습니다. 이와 함께 맵 인터페이스가 향상되었으며 매핑과 관련된 개발자 환경이 크게 개선되었습니다. 이제는 다양한 기능이 향상되고 추가되었으므로 이제는 BizTalk Server 2010에서 어떠한 EDI 솔루션이라도 모델링하고 개발할 수 있게 되었습니다.

Mark Beckner는 Inotek Consulting Group LLC의 창립자입니다. 그는 BizTalk, SharePoint, Dynamics CRM 및 일반 .NET 개발을 비롯한 다양한 Microsoft 기술에 대한 경험을 가지고 있습니다. 문의 사항이 있으면 mbeckner@inotekgroup.com으로 연락하시기 바랍니다.