InterSystems HealthShare™를 이용한 지역 및 국가 EHR 구축

Connected Healthcare로 가는 지름길

목차

I. 의료 정보의 국가 및 지역간공유

1. InterSystems HealthShare 개요
2. 진화하는 의료정보 시스템
3. IDNs와 병원 체인

II. HealthShare의 구조

1. HealthShare 구조 개요
• 설계 원칙
• HealthShare의 구성요소
• HealthShare 환경설정
• HealthShare 사용하기
2. HealthShare EPR
3. HealthShare Hub
4. Edge Cache Repository
5. HealthShare Gateway

III. 고급 기능

1. 용어 서비스
2. 기능성 강화
   • Ensemble 업무 프로세스
   • 복합 어플리케이션
3. 연결성
• Ensemble 어댑터
• Ensemble 데이터 변환
4. 표준
5. 프라이버시 및 보안
6. 동의 관리
7. 보안

IV. HealthShare 시스템 운영하기

1. 성능 및 확장성
2. 신뢰성 및 고 가용성
3. 모니터링 및 관리

V. 결론

I. 의료 정보의 지역적, 국가적 공유

InterSystems HealthShare 개요

전세계적으로 의료 전달 시스템은 지역적, 국가적 전자 건강 기록(EHR)의 공유에 점차 집중되고 있다. 의료 정보의 공유는 중요한 건강정보의 접근성을 증대시키고 중복 진단 및 처방을 없앰으로써 비용을 절감할 수 있으며, 무엇보다 의료관리의 질을 향상시킨다. 긴급상황에서 이러한 정보의 가용성은 말 그대로 생명을 구할 수도 있다.

많은 경우 이러한 솔루션은 단기간의 임시 프로젝트로 다루어지고 있다. 이는 의료 시스템의 복잡성으로 인해 맞춤형 프로그래밍 기반의 정교한 의료 어플리케이션을 개발한다는 것이 비실용적일 뿐만 아니라 비경제적이기도 하기 때문이다. 기존의 서로 다른 시스템들에 저장된 정보의 효과적인 수집과 공유를 위해서는 검증된 구성요소를 채택하는 제품 기반의 접근이 필요하다. 또한, 서로 다른 지역 및 국가의 상이한 요구로 인해 추가되는 기능을 쉽고 빠르게 제공할 수 있는 제품의 사용이 필수적이다.

그러한 제품은 아래와 같은 요건을 만족해야 한다:

1. EHR에 대한 임상적 접근은 단지 그 목적을 위해서만 작성된 “뷰어” 또는 “포털”이 아닌, 까다로운 의료 환경에서 검증된 어플리케이션에 기반하여야 한다.
   
   
2. 환자 기록의 데이터베이스 구조는 여러 병원, 진료소 및 커뮤니티 ? 또한 되도록이면 여러 국가 - 에서 임상적으로 검증 받은 정보 모델을 갖춘 검증된 제품을 기반으로 하여 다양한 조직의 복잡한 요구를 지원하고, 또한 요구조건이 필연적으로 늘어날 수 있으므로 추가적인 요구조건 또한 지원할 수 있어야 한다.
   
   
3. 여러 출처에서 비롯된 의료 및 인구통계학적 정보를 빠르게 통합하려면 강력한 통합 플랫폼이 필요하며, 특히 HL7의 버전 2 및 3에 중점을 두어야 한다. 기존의 시스템이 공통 포맷을 지원한다고 가정하는 것은 실용적이지 못하므로, 다른 포맷들을 위한 지원을 신속하게 개발하는 것이 최대 관건이다.
   
   
4. 핵심 데이터베이스 및 통합 기술은 빠른 개발, 신속한 맞춤화, 그리고 강력한 확장성을 지원해야 한다.
   
   
5. 강력한 표준 기반의 접근이 필요하다.

InterSystems HealthShare™는 이러한 요건을 만족하는 혁신적인 소프트웨어 제품이다. HealthShare는 완전한 EHR을 포함하고 있으며 지역 및 국가 단위의 여러 진료기관간의 의료 정보의 수집 및 공유를 제공한다. 전자 처방 또는 추가적인 업무 규칙 및 업무 프로세스를 통한 주문 서신, 복합 어플리케이션, 그리고 인터시스템즈의 협력사들이 제공하는 추가 어플리케이션등과 같은 추가 기능을 제공하도록 손쉽게 확장이 가능하다.

HealthShare는 4가지의 논리적인 구성 요소를 포함하고 있다:

• HealthShare EPR은 의사 및 기타 임상학자들이 환자 데이터에 접근하기 위해 사용하는 고도의 브라우저 기반 전자 환자 기록(EPR)이다.
• HealthShare Edge Cache Repository는 의료 데이터베이스이다. 일반적으로, 각 진료기관은 자신이 공유하고자 하는 모든 의료 데이터를 저장하고 있는 엣지 캐시를 보유하고 있다.
• HealthShare Gateway는 다수의 진료기관을 연결하는데 최적화된 의료 통합 플랫폼이다. 각 진료기관은 해당 진료기관의 기존 시스템을 엣지 캐시에 연결해주는 게이트웨이를 보유하고 있다. 게이트웨이는 또한 EPR 사용자를 다른 엣지 캐시 및 허브에 연결시켜준다.
• HealthShare Hub는 환자 및 진료기관들의 중심 인덱스이다. 허브는 환자를 식별하는데 사용되며 어느 엣지 캐시에서 그 환자의 데이터를 관리하고 있는지 명시한다. 허브는 의료 데이터를 저장하지 않는다.

HealthShare는 InterSystems Caché®, InterSystems Ensemble®, and TrakCare™를 포함한 전세계 수천 개의 병원에서 사용하고 있는 인터시스템즈의 기술에 기반하고 있다.

Caché 는 전세계적으로 가장 널리 사용되고 있는 의료 어플리케이션들의 데이터베이스이며, 모든 미국 보훈처 및 국방부 병원, 그리고 Kaiser Permanente 네트워크의 핵심 데이터베이스 기술이다. Caché 는 미국 상위 10개 병원 모두에서 사용되고 있다. (U.S. News and World Report선정).

Ensemble은 의료 관련 프로젝트에서 널리 사용되는 신속한 통합 플랫폼이다. Ensemble은 2006년 KLAS에 의해 최고평점을 받은 의료관리 인터페이스 엔진으로 지목 받았고, 가트너의 2Q07 보고서에서 복합 어플리케이션 프로젝트를 위한 어플리케이션 인프라 분야 매직 쿼드런트에서 “리더 부문” 에 선정되었다.

TrakCare는 환자 중심의 전자기록 위에 구축된 완전한 웹 기반의 병원 정보 시스템이다. TrakCare는 소규모 진료소에서부터 수백만의 환자를 가진 전국적 시스템에 이르기까지 전세계적으로 사용되고 있다. TrakCare는 인터시스템즈의 자회사인 TrakHealth의 제품이다.

본 문서에서 EPR이란 하나의 진료기관에서 사용되고 있는 환자 의료기록의 컴퓨터 버전을 의미한다. 때로는 HealthShare EPR과 같이 환자기록을 액세스하고 상호작용하는 소프트웨어를 지칭하기도 한다. EHR은 다수의 진료기관들이 공유하는 정보를 통합하는 환자의 의료기록에 대한 복합열람을 말한다.

진화하는 의료정보 시스템

지난 30년 동안 의료 어플리케이션의 진화는 실험실, 방사선과 등 점점 더 복잡해지는 부서별 어플리케이션의 발달을 통해 이루어졌다. 최근에는 이들 시스템이 상호작용하여 의사에게 환자에 대한 보다 통합된 정보를 제공하도록 하기 위해-때로는 각 병원마다-많은 노력을 기울여 왔다.

그러나 최신의 병원 정보 시스템 구축에 대한 접근방식은 달라졌다. 환자의 의료기록이 시스템의 핵심에 자리한, 보다 환자 중심의 시스템인 것이다. 부서별 어플리케이션은 이후에 그 핵심을 중심으로 구축되며 의료기록에 직접 액세스하고 정보를 저장한다. 임상학자들은 일정하지 않은 인터페이스를 가진 여러 부서별 어플리케이션 보다는 포괄적인 EPR을 통해 데이터를 액세스하게 된다. EPR에 중점을 둠으로써 환자를 보다 전체적인 관점으로 볼 수 있게 해주고 새로운 기능 추가를 가능하게 해주며 임상학자와의 보다 고도의 상호작용을 제공한다. 이러한 접근 방식은 확실히 EPR의 질, 정교함, 그리고 사용의 용이성에 대한 높은 수준의 요구를 필요로 하게 된다.

이와 마찬가지로, 서로 다른 커뮤니티는 의료정보 공유에 대해 다양한 접근방식을 채택하였으며, 각각 특정 기능성을 강조하고 그에 맞는 네트워크를 설계 및 구축하기 위한 노력을 해왔다. 예를 들어, 한 커뮤니티는 실험실 또는 약국에서의 정보 공유를 시작으로 하고자 할 수도 있다.

이러한 점에서 이전의 부서별 어플리케이션을 구축하는 접근방식과 동일하다고 할 수 있다. 문제는 그러한 토대는 범위가 확장되면서 어떻게 작동할 것인가, 또는 토대 자체가 될 수 있는가 하는 것이다.

우리는 지역 또는 국가적 시스템에 대한 최선의 접근 방식은 풍부하고 완전한 EHR을 지원할 수 있는 토대 기술을 가지고서 보다 환자중심적인 접근방식을 채택하는 것이라고 믿는다. 완전한 EHR만큼 야심 차지는 않지만 적어도 토대를 채택하여 미래의 요구에 쉽게 대응할 수 있도록 구축하는 프로젝트로부터 시작하는 것이 합리적일 것이다. 이와 더불어 처음부터 임상학자들이 EPR 인터페이스를 사용하게 함으로써 새로운 기능을 도입했을 때 보다 쉽고 자연스럽게 적응할 수 있다. 이러한 구조를 중심으로 전자처방 또는 주문과 같은 다른 기능을 추가할 수 있다.

IDNs 와 병원 체인

Integrated Delivery Networks (IDNs)와 병원체인들은 점차 의료기록의 수집 및 공유라는 유사한 요구에 직면하고 있으며 그러한 요구는 아래와 같은 요인들로부터 기인한다:

• 이들 그룹은 인수를 통해 성장했고 이제 서로 잘 통합되지 않은 여러 개의 시스템을 갖게 됐다. 메시징 시스템을 통해 많은 노력을 해왔으나 의료진들은 완전한 의료기록을 액세스할 수 있는 간단한 방법이 없을 때가 많으며 이는 통합된 의료 서비스 제공이라는 목표와 어긋난다.
• 이러한 조직들을 정교한 EPR에 액세스할 수 있도록 하고 의료기록을 공유함으로써 커뮤니티 내 의사들과의 연결을 증대할 수 있다.
• 암이나 HIV환자와 같이 장기간 동안 지속적인 치료를 받아야 하는 환자를 관리하고 치료하는 데 기관 간에 정보 공유를 하는 것은 큰 도움을 줄 수 있다.

이들 조직의 요구는 지역 및 국가적 시스템과 근본적으로 동일하지만 때로 몇 가지 추가 요구조건이 있을 수 있다. 예를 들어 어느 한 IDN은 일차 의료원에 결과를 “제공하기” 원하거나, 적어도 환자에 대한 새로운 정보가 있음을 의사들에게 알리기를 원할 수 있다. 바로 이러한 요구의 진화적인 성질은 선택한 기술이 검증된 의료 제품에 기반하는 강력한 의료적인 토대를 가져야 하고, 복합 어플리케이션으로 새로운 기능을 빠르게 개발할 수 있어야 하는 이유를 강조한다고 하겠다.

II. HealthShare의 구조

HealthShare 구조 개요

설계 원칙
HealthShare 구조는 다음과 같은 전제를 기반하고 있다:

• 다른 기능이 같이 제공될 수는 있으나 시스템의 핵심은 건강기록이다.
• 모든 의료 용어를 표준화하는 것이 매우 바람직하나 많은 경우?특히 초기에는?실현되지 않을 것이다. 시스템은 다른 용어로 된 다수의 소스로부터 데이터를 수집하고 디스플레이 할 수 있어야 한다.
• 동의 정책(환자 비밀유지를 위한)은 국가마다 다르다.
• 때로 어느 진료 기관의 기존 EPR이 요구에 따라 전자적으로 의료기록을 제공할 수도 있다. 그러나 그러한 경우보다는 업무가 처리되면서 (예를 들어 실험을 수행하면서) 부서별 시스템에서 생성한 메시지에서 정보를 축적해서 새로운 데이터베이스에 저장해야 하는 경우가 더 많다.
• 시스템 내 통신 및 메시지 프로토콜은 차후 다른 지역 또는 국가 시스템과의 연결을 가능하게 하고 새로 부상하는 전자 의료기록 시스템과의 상호운용성을 가능하게 하기 위해 반드시 표준기반이어야 한다.
• 메시지 포맷을 표준화하기 위한 시도에도 불구하고, 기존의 시스템들을 통합하기 위해서는 다양한 기존의 포맷을 지원해야 하며, 이들은 특정 부서 시스템에 고유한 양식인 경우도 많을 것이다.

HealthShare의 구성요소
HealthShare Hub는 모든 환자의 인덱스를 관리하고 각 환자에 대한 정보를 어느 HealthShare Gateway가 저장하고 있는지 관리하는 중앙 컴퓨터이다. 허브는 전자 마스터 환자 인덱스(EMPI)를 갖거나 기존의 것을 사용한다. 의료 데이터는 저장하지 않는다.

각각의 HealthShare Edge Cache Repository 는 진료 기관이 공유하고자 하는 정보를 보유하고 있는 정교한 EPR 데이터베이스이다. 대개의 경우 대규모 진료기관 별로 한 개씩 있으며 소규모 진료기관들은 엣지 캐시를 공유하는 수가 있다. 이러한 접근방식에 따라 의료 데이터는 그것을 수집하는 기관의 관리 하에 놓이게 된다.

HealthShare Gateway 는 진료기관의 기존 시스템을 자신의 엣지 캐시와 연결시키는 역할을 한다. 메시지들이 부서 시스템에서 유입되면 (실험 결과 등) 게이트웨이는 메시지를 변환시켜 환자 데이터를 해당 조직의 엣지 캐시에 삽입하게 된다. 또한 임상학자가 정보를 요청하면 게이트웨이는 임상학자를 허브에 연결시켜 환자를 식별하고 환자 데이터가 어디에 위치하는지 판단한다. 그런 다음 다른 게이트웨이 및 엣지 캐시와 통신하여 환자 데이터를 입수하고 이를 임상학자의 EPR 로 반환한다.

HealthShare EPR 은 임상학자를 위하여 사용자 인터페이스를 제공하는 풍부한 브라우저 기반의 의료 기록 어플리케이션이다. 게이트웨이가 반환한 환자 데이터는 임상학자의 EPR 에 수집되고 저장된다. 그 데이터는 임상학자가 삭제를 요청할 때까지 EPR 을 통해 사용 가능하다.

HealthShare 환경설정
HealthShare는 다양한 환경설정을 지원한다. 일반적으로 HealthShare Hub는 하나 밖에 없지만 각 진료기관은 (또는 경우에 따라 여러 진료기관들은) 자기만의 HealthShare Edge Cache Repository 및 HealthShare Gateway를 보유한다. 일반적으로 게이트웨이와 해당 엣지 캐시는 진료기관의 사업 현장 또는 소규모 진료기관의 경우 공통 시설에 위치하나 환경설정을 다르게 하는 것도 가능하다. 어떤 커뮤니티에서는 별도의 엣지 캐시보다는 중앙 데이터베이스를 선호할 수도 있고, 다른 곳에서는 이들의 혼합된 형태를 원할 수도 있다.

다음 페이지의 도면(그림1)은 단순한 환경설정에서의 HealthShare 배치 예를 보여준다. 두 개의 진료기관과 의료 실험실이 서로 간에 의료 데이터를 공유하고 있다.

그림1. HealthShare 구조: 이 예를 보면, 의료 및 실험실의 부서별 시스템에 업데이트가 이루어지면서 데이터는 해당 시스템에서 엣지 캐시 리포지터리로 유입되는 것을 알 수 있다. 참여 조직에 새로운 환자가 생기면서 허브의 EMPI 에 입력되고, 허브는 어느 게이트웨이가 각 환자에 대한 정보를 갖고 있는지 관리한다. 협진을 하는 (또한 이외의 경우에도) 의사들은 통합되고 조직적이며 치료건 별로 기록된 환자의 병력을 보기 위해 HealthShare EPR 을 사용할 수 있다.

HealthShare 사용하기
각각의 HealthShare 구성요소의 역할은 간단한 예로 가장 잘 설명이 가능하다. 협진을 하는 의사가 어느 환자의 의료 데이터를 입수하기를 원한다고 가정하자. 기본적으로 3 단계로 이루어진다: (a)환자를 식별하고 환자의 의료 정보의 위치를 판단하기, (b) 환자 정보를 각각의 사이트에서 입수하여 의사의 지역 EPR 에 입력하기 (c) 환자 데이터를 디스플레이하고 상호작용하기. 대개, 조수가 앞의 두 단계를 전날 또는 환자가 입실하면서 이미 실행했을 것이다.

환자를 식별하고 환자 데이터의 위치를 확인하기 위해 HealthShare Hub로 (진료기관의 게이트웨이를 통해) 질의가 보내지고, 허브는 어느 게이트웨이가 해당 환자에 대한 정보를 갖고 있는지를 명시하는 메시지를 반환한다. 진료 기관의 게이트웨이는 정보를 갖고 있는 각각의 게이트웨이에 메시지를 보낸다. 그 메시지는 환자에 대한 모든 정보를 요청하거나 필터를 포함하여 보다 제한된 양을 전송하도록 할 수 있다. 각각의 게이트웨이는 요청된 정보를 자신의 엣지 캐시 리포지터리로부터 회수하여 의사의 게이트웨이로 전송한다. 의사의 게이트웨이는 그 메시지를 의사의 HealthShare EPR 로(또는 그 메시지를 읽어 들일 수 있는 의사가 가진 다른 EPR 로) 전달하고, EPR 은 이 정보를 로컬 데이터베이스에 저장한다. 입수된 데이터는 로컬 EPR에 남게 되어 의사가 해당 기록을 삭제할 때까지 (또는 사전에 정한 일정 시간이 경과할 때까지) 재사용이 가능하다.

The HealthShare EPR

임상학자의 시스템의 사용은 모두 HealthShare EPR 을 통해 이루어지며, 이는 전세계 수백 개의 병원에서 널리 사용된 후 검증 받은 고도의 웹 기반 EPR 어플리케이션인 TrakCare에 기반하고 있다. 그러나 진료기관들은 자신의 의료 기록 시스템을 사용할 수도 있다. 단, 해당 시스템은 HealthShare가 사용하는 동일한 표준과 프로토콜을 사용해야 하며, 필요한 경우 비표준화된 용어도 지원할 수 있어야 한다.

커뮤니티 전체에 환자 조회를 실시하기 위해 HealthShare EPR은 진료기관의 게이트웨이를 통해 허브와 해당 환자에 대한 정보를 갖고 있는 다른 게이트웨이에 연결한다. 그 후 여러 사이트 및 여러 진료 사례에서 입수한 데이터를 수집하여 풍부하고 포괄적이며 환자중심적인 관점을 제공한다.

EPR은 광범위한 정보 종류에 대한 직관적인 디스플레이를 제공하며, 이는 환자에 대한 인구학적 통계, 알레르기, 투약, 진단, 실험실 결과(결과 범위, 누적 및 그래프 포맷으로), 방사선 기록(텍스트 및 이미지), 가족력, 임상소견, 진료경과 기록지등에 대한 정보를 포함한다. 데이터는 임상 구분에 따라 일련의 탭에 정리된다 (그림 2 참조) 탭 위의 일정은 각 치료건 및 관련 기간을 디스플레이하며 이는 빠르게 특정 치료건을 선택하여 검토하는데 사용할 수 있다. 그림 3에서, 의사는 환자의 현재 투약 상황을 보기로 하였다.

그림 2. HealthShare EPR 이 환자가 갔던 여러 기관에서의 기록을 디스플레이하고 있다.

 

그림 3. HealthShare EPR 이 환자의 투약 상황을 디스플레이하고 있다.

HealthShare는 환경설정도가 높기 때문에 실제 사용하는 단계/화면은 지역의 요구 및 언어에 맞추어 다양하게 변경할 수 있다. 의사는 또한 EPR에서 상세한 정보를 CDA(Clinical Document Architecture) 문서 형태로 다른 어플리케이션에서 사용하기 위해 내보낼 수 있다.

HealthShare EPR은 자체문서화(self-documenting) 데이터 기술을 사용하여 여러 소스로부터의 비표준화된 용어를 수신 및 디스플레이 할 수 있다.

웹 기반 기술로서, HealthShare EPR 은 배치 및 지원이 매우 용이하다. 웹 브라우저만을 필요로 하며, 클라이언트 구성요소를 설치할 필요가 없다.

The HealthShare Hub

HealthShare Hub는 Ensemble을 기반으로 하며, 3가지 기능을 제공한다.

• 신원관리 기능은 각기 다른 진료기관이 가진 다른 기록이 같은 환자의 것인지 다른 환자의 것인지 구별한다
• 임상 환자 인덱스는 한 환자에 대해 어느 진료기관이 정보를 갖고 있는지 판단한다
• 권한 있는 사용자 목록, 게이트웨이 주소, 보안 및 비밀 정보와 같은 행정 정보를 관리한다

데이터는 여러 개의 조직에서 수집되므로 지역 또는 국가 규모의 시스템이 제대로 작동하기 위해서는 환자를 식별하고 각기 다른 진료기관들이 보유한 데이터 중 어떤 것이 같은 환자의 것인지 구별할 수 있어야 한다. 주민등록번호가 있다면 문제는 간단해지겠지만, 항상 그런 것은 아닐 것이다.

주민등록번호가 없는 경우, 신원 관리 기능은 이미 IDNs및 병원 체인에서 널리 사용되고 있는 EMPI로 제공할 수 있다.

이미 EMPI를 가진 조직의 경우, HealthShare Hub는 해당 EMPI를 사용하게 된다. EMPI가 없는 경우, HealthShare는 대표적인 신원관리 제품에 맞는 지원체계를 내장하고 있으며 이는 다른 제품을 지원하도록 변경 가능하다.

EMPI에는 최소한의 정보만이 저장된다. 임상 정보는 저장되지 않으며 환자의 인구통계 정보 요약 및 해당 환자를 식별하기 위해 각 진료기관이 사용하는 식별장치만 저장된다. 환자 인덱스에 들어있는 정보는 진료기관이 프로그램을 조인할 때 일괄 저장된다. 그 후 환자 인덱스는 치료 현장에서 변화가 있을 때마다 지속적으로 업데이트된다. 예를 들어 새로운 환자가 추가되거나 기존 환자의 데이터가 업데이트되거나, 두 개의 환자기록이 같은 환자의 것으로 판명되어 두 기록을 한 개로 합병시켜야 하는 경우 등이다.

EMPI는 다양한 인구통계 데이터를 통한 검색을 수행할 수 있는 정교한 매칭 기술을 제공한다. 그러나 EMPI를 사용할 때 신규 환자의 경우 수동 검토가 필요하다.

The HealthShare Edge Cache Repository

특정 진료기관에 있는 어느 환자의 임상 데이터를 가져오라는 요청이 있을 경우 해당 데이터의 소스는 3가지가 될 수 있다.

• 모든 임상 데이터는 중앙 데이터베이스에 저장 및 회수 될 수 있다(예를 들어 HealthShare Hub에 위치)
• 진료기관의 전자의료기록 시스템에 요청을 하거나 심지어 진료기관의 소스 시스템에 요청을 할 수 있다
• 엣지 캐시-진료기관이 공유하고자 하는 모든 데이터를 저장하고 있는 데이터베이스-에 요청할 수 있다

HealthShare는 3가지 전략 모두를 지원하나 일반적으로 엣지 캐시 접근방식이 가장 실용적이다. 중앙 데이터베이스는 너무 규모가 크기 때문에 진료기관들은 정보에 대한 제어력을 잃어버릴 수 있다. 진료기관의 소스 시스템에 요청을 넣는 것은 몇 가지 문제점을 가진다. (a) 대부분의 소스 시스템은 요청에 대응할 수 있는 SOA(Service Oriented Architecture)로 되어 있지 않다. 그보다는 실험 결과와 같은 업무처리 데이터가 발생하면 이를 다른 시스템으로 전달할 수 있을 뿐이다. (b) 다수의 소스 시스템에 쿼리를 해야 하므로 응답시간이 문제가 될 수 있다. 또한, (c) 특정 소스 시스템이 가용하지 않는 경우도 있을 수 있다. 진료기관의 전자의료기록시스템에 요청을 넣는 것이 더 실용적이긴 하나, 위와 같은 문제가 발생할 수 있으며, 보안상의 문제 때문에 많은 진료기관들은 이것이 좋은 접근방식이 아니라고 판단할 것이다. 일차 진료 및 소규모 협진에 대해서 시스템은 하루 24시간 가용하지 않을 수가 있다.

엣지 캐시의 또 다른 중요한 장점은 활용률, 공공보건, 연구 및 다른 유용한 정보를 끌어내기 위해 BI(business intelligence) 또는 SQL 리포팅 툴을 이용하여 쿼리를 할 수 있다는 것이다. 지역 내 또는 국가 내 용어는 표준화되지 않을 수도 있으나 하나의 엣지 캐시에서는 표준화가 이루어져 있게 되고, 이로써 쿼리가 더 유용하게 된다.

HealthShare Edge Cache Repository는 TrakCare 기술 - HealthShare EPR에서 사용하는 동일한 기술 - 및 Cache 오브젝트 데이터베이스를 사용하는 고도의 의료 데이터베이스이다. 임상 데이터를 포함한 업무처리가 발생하면 소스 시스템이 진료기관의 게이트웨이로 메시지를 보내고, 게이트웨이는 메시지를 변형하여 진료기관의 엣지 캐시로 전달하며 이곳에 저장된다.

일반적으로 각 게이트웨이는 고유한 엣지 캐시를 가지며 큰 진료기관은 각자 자신만의 게이트웨이와 관련 엣지 캐시를 보유하고 있다. 작은 진료기관 (예를 들어 일차 진료의사 및 소규모 협진)의 경우 대개 게이트웨이와 엣지 캐시를 사용하기 위해 같은 컴퓨터를 공유한다. 엣지 캐시는 같은 게이트웨이를 공유하는 진료기관 (또는 진료기관들)의 임상 정보만을 저장한다. 그러나 다른 환경설정도 가능하며, 극단적인 예로 엣지 캐시가 모두 중앙 데이터베이스에 들어있을 수도 있다.

원본시스템의 데이터(의사 사무실의 검진관리 시스템이나 병원의 EPR 같은)는 사용이 불가능해 질 때도 있으므로, 엣지 캐시는 어떠한 혼란상황에서도 가용성을 유지하는 것이 중요하다. 엣지 캐시는 일년 내내 하루 24시간 작동하도록 설계되었다.

The HealthShare Gateway

HealthShare Gateway는 Ensemble을 기반으로 한다. Ensemble은 의료 분야에서 인터페이스 엔진 및 복합 어플리케이션의 구축 및 운영에 널리 사용되는 빠른 통합 플랫폼이다.

HealthShare Gateway는 아래 명시한 항목들 간의 모든 통신을 책임진다.

• 의료 현장 및 관련 엣지 캐시
• 의료 현장 및 허브
• 의료 현장 사이의 게이트웨이 대 게이트웨이 간 통신

각 게이트웨이는 또한 아래 명시한 항목을 제공한다.

• 환자의 동의성명을 기록하고 이를 집행할 수 있는 동의 관리 프레임웍.
• 해당사항이 있는 경우 데이터 표준화 및 용어 서비스
• 메시지 프로토콜 변환

의료기관의 시스템이 공유할 수 있는 정보를 생성한 경우 게이트웨이에 메시지를 보낸다(예를 들어 실험실에서 실험을 완료하면 결과를 게이트웨이로 보낸다). 게이트웨이는 메시지를 검토하여 정보의 유형을 판단하고 저장하기에 적합한지 여부를 결정한다. 적합한 경우 표준 HealthShare 프로토콜을 사용하도록 메시지를 변형시키고 이를 엣지 캐시로 보내 저장하도록 한다.

의사가 환자에 대한 정보를 요청하면 - 일반적으로 HealthShare EPR 을 통해 - EPR은 의사의 게이트웨이로 메시지를 보내며, 게이트웨이는 HealthShare Hub와 통신을 한다. 허브가 어떤 다른 게이트웨이들과 접촉해야 할지 확인하고 나면 의사의 게이트웨이는 해당 게이트웨이들을 접촉하고 그곳으로부터 환자 데이터를 요청한다. 요청을 받은 게이트웨이들은 각자의 엣지 캐시에 쿼리를 수행하여 수신된 결과 데이터를 XML문서로 본래의 게이트웨이로 반환하며, 본래의 게이트웨이는 그렇게 여러 게이트웨이에서 수신한 XML문서를 다시 요청을 했던 EPR에게 제공한다.

HealthShare는 게이트웨이가 직접 다른 게이트웨이를 접촉하거나 모든 게이트웨이 메시지가 허브를 통하도록 할 수 있는 유연성을 갖고 있다. 어떤 경우 이들의 혼합된 형태가 적합할 수도 있다.

III. 고급 기능

용어 서비스

서로 다른 진료기관은 각기 다른 용어를 사용할 수 있으며 이는 정보 공유를 더욱 어렵게 만든다. 이상적인 경우라면 진료기관이 공통 용어를 채용하거나 적어도 정보 교환을 위한 공통표준에 합의하고 이를 지원해야 할 것이다. 그러나 많은 경우 이는 비실용적이거나 적어도 적잖은 시간을 요한다.

HealthShare는 공통 용어를 필요로 하지 않는다. HealthShare EPR과 엣지 캐시는 자체문서화 데이터 기술을 채용하여 여러 소스로부터의 비표준화된 용어를 저장하고 디스플레이 할 수 있다.

표준화된 용어를 공유하기를 원하는 진료기관들을 위해 HealthShare는 어플리케이션의 구애를 받지 않는(application-independent) 용어 서비스를 사용할 수 있는 옵션을 제공하고 있다. 이 서비스는 SNOMED, ICD 9/10, CPT및 LOINC를 포함하는 표준 의학용어집 간의 번역 역할을 해주며, 게이트웨이에서 수행될 수 있다. 번역 서비스는 각 진료기관에서 직접 설정 할 수 있다.

기능성의 제고

조직은 사람과 마찬가지로 생존하기 위해서는 성장을 해야 하며 연결된 의료 시스템은 의료 커뮤니티와 환자의 요구가 진화함에 따라 이와 함께 진화할 수 있어야 한다. 초기의 시스템간 연결 및 정보공유는 시작에 불과하다. 중요한 것은, 시스템이 미래의 성장 및 빠른 적응을 가능하게 해 주는 토대를 마련하고 있는가 하는 것이다.

HealthShare의 연결성은 Ensemble이 제공하는 것이며, 이는 업무 프로세스 및 작업흐름 관리를 포함한다. 이는 또한 “복합 어플리케이션”이라고 하는 차세대 어플리케이션을 가능케 한다. 또한 HealthShare는 Cache를 채용하여 추가 기능성을 더하는 것이 용이하다.

Ensemble 업무 프로세스
각각의 커뮤니티는 대개 상이한 요구 사항을 갖는다. 예를 들어, 어느 커뮤니티는 다양한 사건에 따라 공공보건 경보를 작동시키기를 원할 수 있다. 더구나 사건의 성질이나 취할 조치는 환자마다 다를 수가 있다. ? 어쩌면 여성 환자의 경우 어떤 조치를 취하기 전 부인과 시스템에 쿼리를 넣어야 할 수도 있다.

이러한 요건을 수용할 수 있는 강력한 기술이 Ensemble의 업무 프로세스를 활용하는 것이다. Ensemble은 조직 고유의 여러 업무 규칙과 프로세스를 설정할 수 있도록 하며 그러한 규칙과 프로세스를 자동으로 적용시킨다.

업무 규칙과 프로세스는 높은 수준에서 정의되고 캡슐화 되므로 변경이 용이하다. 따라서 어플리케이션별 또는 사이트별 차이점과 진화하는 요구는 HealthShare나 어댑터(아래에 설명)를 변경하지 않고도 빠르게 수용될 수 있는 것이다.

복합 어플리케이션
복합 어플리케이션은 상호 연결된 시스템을 기반으로 하는 차세대 어플리케이션이다. 그러한 어플리케이션은 자신의 데이터베이스는 아주 작거나 없는 대신 연결된 다른 시스템의 데이터에 의존한다. 복합 어플리케이션은 다른 어플리케이션의 데이터뿐만 아니라 기능성?즉 어플리케이션 논리? 도 액세스하며 대개 SOA를 사용하기도 한다. Ensemble은 풍부한 복합 어플리케이션을 빠르게 구축할 수 있는 첨단 개발 환경을 포함하고 있다.

HealthShare EPR이 복합 어플리케이션의 일례이다. 즉, EPR에 알려지지 않은 포맷으로 된 여러 의료기관 사이트에 저장된 임상 정보에 EPR이 의존하고 있기 때문이다. 또 다른 예로는 주문 어플리케이션이 각 진료기관 어플리케이션이 주문을 실제로 어떻게 처리하는지 알지 못한 상태에서도 내릴 수 있는 커뮤니티 임상주문 또는 전자 처방의 도입이다. 이는 단순하게 공통의 오브젝트 기반의 인터페이스를 사용하는 것으로서, 이 인터페이스는 다양한 어플리케이션의 기능에 액세스하게 된다.

요양기관의 여러 어플리케이션들이 서로 연결될 때 복합 어플리케이션이 어떻게 진화하는 기능성에 대응할 수 있는 강력한 메커니즘이 될 수 있는지 쉽게 알 수 있을 것이다.

연결성

전국적인 시스템이 성공하기 위해서는 최소한의 비용과 노력을 통해 다수의 기존 의료 어플리케이션에 안정적으로 연결될 수 있어야 한다. HealthShare는 특히 이러한 목적을 위해 강력한 성능을 발휘하는 Ensemble을 사용함으로써 이를 달성하며, 여기에는 어댑터, 데이터 변환, 그리고 특정 요구에도 대응할 수 있는 진보한 프로그래밍 기능이 포함된다.

Ensemble 어댑터
Ensemble 어댑터는 재활용이 가능한 소프트웨어 구성요소로서 어플리케이션과의 연결을 제공하고 오브젝트 인터페이스를 통해 어플리케이션 고유의 논리를 전체 시스템으로부터 분리시킬 수 있다. Ensemble은 다수의 시스템의 요구에 대응할 수 있는 사전구축 된(pre-built) 어댑터의 방대한 라이브러리를 포함한다. 소스 또는 타깃 어플리케이션이 표준 어댑터의 활용을 허용하지 않는 경우에도 기존의 어댑터를 확장(“subclassing”)함으로써 원하는 맞춤 어댑터를 빠르게 만들 수 있다.

대부분의 경우, 기존의 의료 어플리케이션을 연결하기 위해 HL7 v2의 일부분이 “사용”될 것 이다. HL7 v2 및 v3 스키마에 대한 빌트인 지원 및 강력한 가상 문서 구조를 통해 HealthShare는 현존하는 가장 풍부하고 가장 빠른 HL7 기반의 연결성을 제공한다.

그러나 모든 어플리케이션이 HL7을 통해 통신하는 것은 아니다. 실제로 몇몇 어플리케이션은 어떠한 표준 통신 방식도 갖고 있지 않다. 통합 기술이 몇 개의 어댑터를 갖고 있는지 또는 몇 개의 어플리케이션에 연결할 수 있는지를 강조하다 보면, 사용자에게 꼭 필요한 한 가지 어플리케이션에는 연결되지 못할 위험이 존재할 수도 있다. 이러한 이유로 Ensemble의 프로그래밍 기능이 중요한 것이다. Ensemble은 완전히 고유한 어댑터의 개발을 손쉽게 지원하기 때문이다.

Ensemble 데이터 변환
Ensemble 변환 엔진은 필요한 어떠한 메시지 세트 번역, 메시지 표준화 또는 변경 임무도 수행할 수 있다. 이는 메시지 안에서 필드를 제거 또는 재정렬하듯 간단한 것일 수도 있고 아니면 어플리케이션 고유의 메시지를 표준 양식에 맞도록 바꿔주는 복잡한 처리과정을 수반할 수도 있다. Ensemble은 참여 어플리케이션의 HL7 v2 및 v3의 응답을 표준 CDA 포맷으로 변경해주는 확장 가능한 변환 클래스를 포함한다. 신규 또는 기존의 변환은 그래픽적으로 또는 XML기반 변환 “언어”를 통해 지정할 수 있다. 아주 특이한 경우에도 언제나 Ensemble의 프로그래밍 기능을 사용할 수 있다.

표준

상호 운용성의 열쇠는 표준이다. 데이터 교환의 모든 단계에서 표준을 채택함으로써 시스템은 신규 또는 기존의 의료 시스템뿐만 아니라 지역 또는 전국에 위치한 의료 정보 솔루션들과 접속할 수 있다.

HealthShare Gateway는 Ensemble에 기반하고 있다. Ensemble은 아래 명시한 바와 같이 여러 종류의 의료 데이터 및 상호 운용성 기준을 지원한다. Ensemble은 HL7 v2 및 v3을 지원하며 인터시스템즈는 HL7 표준단체의 회원이다. Ensemble은 또한 빌트인 XML 파서, DTD 및 XML 스키마를 위한 양방향성 지원, 문서 쿼리 및 XPATH와 XSLT를 통한 변환, 그리고 SOAP를 사용한 메시지 전송을 포함하는 강력한 XML지원기능을 갖는다. 이들 모두가 HealthShare로 하여금 CDA 및 기타 XML 문서기반 표준을 위한 고성능 지원을 제공할 수 있도록 해주는 요인들이다. 인터시스템즈는 의료 분야에서 컴퓨터 시스템들이 정보를 공유하는 방식을 개선하기 위한 IHE(Integrating the Healthcare Enterprise)의 노력에 적극 참여하고 있다.

다른 기술과 연결할 때 우리는 가능한 한 메시징/데이터 표준을 사용하고자 노력한다. 게이트웨이 대 허브 및 게이트웨이 대 게이트웨이 통신은 일반적으로 웹 서비스를 통해 전송되는 표준 포맷을 사용한다. 게이트웨이 대 허브 통신은 의료 연결 공통 프레임워크(Connecting for Health Common Framework)의 RLS(Record Locator Service/기록 안내 서비스) 시방서를 사용한다. 게이트웨이 대 게이트웨이 통신에서는 임상 데이터를 요청하는데 HL7 v3 메시지가 사용되고 해당 데이터를 재전송하는데 CDA 문서가 사용된다.

Healthcare standards
HL7 v2	Health Level 7 version 2 (www.hl7.org)
HL7 v3	Health Level 7 version 3 (www.hl7.org)
CDA	Clinical Document Architecture (www.ansi.org)
CCD	Clinical Care Record (CCR) encapsulated in CDA (www.astm.org)
DICOM	Digital Imaging and Communications in Medicine (medical.nema.org)
NCPDP	National Council for Prescription Drug Programs (www.ncpdp.org)
RLS	Record Locator Service (www.connectingforhealth.org)
HealthShare가 지원하는 의료 데이터 교환 표준

그러나 HealthShare가 다른 HealthShare 구성요소와 내부적으로 통신할 때는 보다 고성능의 독점 프로토콜로 자동 전환하여 더욱 빠른 응답시간과 더욱 커진 범위로의 확장을 가능하게 한다.

프라이버시 및 보안

동의 관리
HealthShare는 빌트인 동의 관리 기능을 제공한다. 동의는 일반적으로 두 가지 방식으로 집행한다.

• 환자 매칭: 허브가 매치 요청을 받으면 EMPI 등록에 동의한 환자에 대한 기록만 회신한다.
• 임상 데이터: 게이트웨이가 특정 환자의 데이터를 요청 받은 경우 게이트웨이는 기록 중 환자가 공유하기를 동의한 부분만을 회신한다.

T시스템은 모든 환자로부터 명시적인 동의를 받도록 설정될 수도 있고 또는 환자가 명시적으로 달리 의사표시를 하지 않는 한 동의하는 것으로 설정할 수도 있다.

보안
HealthShare는 프라이버시 및 보안 표준을 엄격히 준수하기 위해 암호화, 강력 인증, 역할기반의 권한(role-based privileges), 보안 정책, 훼손방지 감사 로그 등을 포함하는 진보한 기술들을 사용한다.

HealthShare의 빌트인 Cache 데이터베이스 암호화 기술은 인덱스를 포함한 데이터베이스 내용 전체를 암호화한다. 허브와 게이트웨이에 위치한 "실질적인” 임상 및 인구통계 정보와 함께 다른 “시스템” 데이터, 즉 감사 기록 및 로그와 같은 모든 민감한 데이터를 보호한다.

데이터베이스의 암호화는 연방정부 정보처리표준(FIPS) 197에서 지정한 고급암호표준(AES) 알고리즘을 사용하여 실행된다. AES는 강력하고 빠른 대칭형 암호화 알고리즘이며, 256비트 암호화 키와 함께 사용된다. 키는 HealthShare 외부에 저장되며 (예를 들어 메모리 스틱, CD 또는 파일) 시스템 가동 시 로드된다. 암호 키를 액세스하기 위해서는 비밀번호가 필요하다. 운영시간 동안 키는 안전한 메모리 위치에 저장된다.

여러 HealthShare 허브와 게이트웨이 구성요소 사이의 안전한 통신을 보장하기 위해 HealthShare는 SSL(2.0, 3.0) 및 TLS를 위한 지원기능도 포함한다. 게이트웨이 사이 그리고 게이트웨이와 허브 사이의 연결 요청은 요청하는 게이트웨이가 유효한 인증을 제시하고 인증에 들어있는 신원이 서버에 알려져 있어야만 승인이 떨어진다. 인증이 유효 하려면 인정된 인증기관이 발급한 것이어야 하고 유효기간이 만료되지 않아야 한다.

HealthShare는 강력한 인증 정책을 집행하기 위해 내재된 인증 기술을 지원한다. HealthShare EPR 사용자는 사용자이름과 비밀번호를 입력하게 되어있다. 이 정보는 (암호화된 형태로) HTTPS 연결을 사용해 HealthShare Gateway로 전송되고 게이트웨이는 Kerberos 키 배포센터(KDC)에 연결해 사용자 신원을 확인한다. KDC는 비밀번호의 길이와 패턴, 비밀번호 변경 주기와 감사기록 같은 엄격한 비밀번호 정책을 이행하도록 설정될 수 있다.

HealthShare는 매우 유연하고 강력한 역할기반의 보안 메커니즘을 포함한다. 역할은 다양한 등급의 사용자 액세스에 맞도록 정의되어 있어 필요에 따라 사용자들에게 할당할 수 있다. 또한 감사기록 정보접근과 같이 다른 종류의 시스템 액세스를 위한 역할을 추가적으로 설정할 수 있다.

HealthShare 허브와 게이트웨이는 안전한 훼손방지 감사 로그를 사용하여 모든 요청에 대한 유연한 로그 기능을 제공한다. 이 데이터는 시스템 사용을 모니터하고 악용 혐의를 조사하거나 정기적인 감사를 실행하는데 활용할 수 있다.

IV. HealthShare 시스템 운영하기

성능 및 확장성

진료 지점에서 시스템이 즉각적인 응답을 제공할 수 없다면 의사들은 시스템을 사용하지 않을 것이다. HealthShare는 지역 또는 전국적으로 수천 명의 사용자들을 동시에 서비스할 경우에도 임상 정보에 대한 빠른 액세스를 제공한다.

확장성 또한 중요하다. 많은 의료 정보 공유 프로그램은 가령 수천 명 정도의 환자들로 된 파일럿 프로젝트로 시작하여 시간이 지남에 따라 10배 또는 20배 혹은 그 이상으로 확대된다. HealthShare는 서버 내 프로세서 추가 및 다중계층 설정 내에서의 서버 추가 두 가지 모두를 통해 효율적인 비용으로 점진적인 성장을 지원한다. 모든 사용자가 한 컴퓨터를 사용하고 있는 것처럼 공유 데이터베이스에 액세스하기 위해 다수의 컴퓨터를 연결시킬 수 있는 Cache 고유의 ECP(Enterprise Cache Protocol)를 사용함으로써, 의료 어플리케이션을 위한 확장성은 수만 명의 동시 사용자, 그리고 수백만 명의 환자에 의해 검증을 받았다.

신뢰성 및 고 가용성

HealthShare는 일년 내내 하루 24시간 가동이 가능하도록 설계되었다. 이러한 고 가용성을 보장하기 위해 HealthShare는 Cache와 Ensemble의 자동 지속성 아키텍처를 사용하며 이는 아래와 같은 고 가용성 기능을 제공한다.

• 어플리케이션 가동 중 및 데이터베이스 변경 중에도 전체 및 점증적인 백업
• 트랜잭션 무결성을 위한 트랜잭션 로그 및 롤 포워드 복구
• 데이터베이스 무결성을 위한 Write Image Journaling
• 빠른 장애복구를 위한 섀도우 서버
• 클러스터화된 데이터베이스
• 데이터 서버를 백업하기 위한 자동 장애복구 기능을 갖춘 ECP

또한, HealthShare는 모든 처리 단계에서 메시지 “상태”를 빌트인 Cache 데이터베이스에 자동 저장한다. 따라서 시스템 장애 또는 다른 실패가 발생하는 경우에도 신속하고 안정적인 복구가 가능하다.

모니터링 및 관리

때로는 수백 개의 게이트웨이와 수천 개의 임상 시스템상에 매일 지속적인 변화가 발생하는 다수의 “동적 부분” 때문에 시스템 운영진이 직면한 가장 힘든 과제는 문제를 신속히 발견하고, 진단 및 치료하는 것일 것이다.

HealthShare는 Ensemble을 사용함으로써 이 과제에 대하여 두 가지의 강력한 이점을 제공하는데, 원격 시스템 관리를 위해 설계된 자동 로그, 강력한 모니터링 및 관리 콘솔이 그것이다. Ensemble은 요청을 처리하기 위해 취해진 모든 조치에 대해 자동으로 기록하며, 이 기록은 문제를 정확하게 진단하는데 필요한 수준의 상세한 정보이다. 가령, 한 게이트웨이가 특정 환자의 임상 데이터를 가져오라는 요청을 받을 수 있다. 이 요청을 수행하기 위해 게이트웨이는 5개 또는 10개의 병원 시스템에 요청을 보낸다. 그 모든 요청은 완벽하게 추적이 가능하도록 로그된다.

메시지 추적(그림 4 참조)은 Ensemble 관리 포털이 제공하는 기능 중의 하나에 지나지 않는다. 관리 포털이 브라우저 기반이므로 필요한 보안권한을 가진 관리자는 어느 위치에서든 모든 네트워크의 문제를 조사할 수 있는 것이다.

그림 4. HealthShare는 메시지 및 메시지 내용을 쉽게 모니터 할 수 있도록 Ensemble 비주얼 추적 기능을 활용한다.

V. 결론

임상정보를 공유하는데 있어서 HealthShare 접근방식을 선택한다는 것은, 검증 받은 임상정보 기술을 시스템 기반으로 두고 다양한 요구에 대응하기 위해 기능성을 빠르게 확장할 수 있는 능력을 채택한다는 것을 의미한다. HealthShare는 EPR, TrakCare의 엣지 캐시 데이터베이스 구조, 그리고 Cache의 진보한 오브젝트 데이터베이스와 Ensemble 통합 플랫폼을 사용함으로써 이 목표를 달성한다. 이 접근방식은 또한 인터시스템즈가 제공하는 많은 의료 어플리케이션에 연결하거나 이들을 통합하기 용이하게 만들어준다.

HealthShare는 강력한 보안과 고도의 표준 기반에 근거하며 의료정보를 공유하는 시스템의 핵심은 환자 기록이라는 전제로부터 출발한다. 이러한 환자중심적 관점으로 인해 초기에는 최소한의 정보만을 공유하는 시스템은 차후 용도와 기능성에 대한 요구가 증대하면서 함께 확장할 수 있는 탄탄한 기반을 갖게 되는 것이다.

시스템간의 연결은 시작에 불과하다. 커뮤니티는 HealthShare를 통해 전 커뮤니티에 임상 주문 또는 전자처방과 같은 확장된 기능성을 제공하는 복합 어플리케이션을 도입 - 또는 구축 - 함으로써 진화할 수 있으며, 변화하는 요구에 대응 가능한 변경이 용이한 업무 규칙과 프로세스를 활용할 수 있게 된다.

지난 30여 년간 전세계 수천 개의 의료 시스템의 주요 의료 어플리케이션을 지원하는 소프트웨어 공급을 해온 경험을 토대로 고성능, 방대한 확장성을 가진 소프트웨어를 제공한 인터시스템즈의 실적은 의료 전 분야에서 인정 받고 있다. 의료정보 공유 프로그램의 파일럿 단계에서는 제한된 수의 환자만을 포함하겠으나 수백만 명의 환자와 수천 명의 사용자를 지원하기 위한 제품의 범위 확장성은 전면적인 도입 시에 절대적으로 필요한 요건이다.

더 상세한 정보를 원하시면

아래의 InterSystems HealthShare 웹사이트를 방문해 주십시오. InterSystems.kr/HealthShare.

Magic Quadrant for Application Infrastructure for Composite-Application Projects, 2Q07 Publication Date: 7 June 2007 ID Number: G00147640 Top 20 Year End in KLAS Report. KLAS confidential Information. © 2006 KLAS Enterprises, LLC. All rights reserved. www.healthcomputing.com