KR20090083331A

KR20090083331A - 애플리케이션 프로그램 인터페이스(ａｐｉ), 개인 건강 관련 데이터와 상호작용하는 방법 및 건강 관련 데이터를 액세스하는 시스템

Info

Publication number: KR20090083331A
Application number: KR1020097006055A
Authority: KR
Inventors: 숀 패트릭 놀란; 제프리 딕 존스; 존슨 티. 아파시블; 비자이 바라단
Original assignee: 마이크로소프트 코포레이션
Priority date: 2006-11-01
Filing date: 2007-11-01
Publication date: 2009-08-03
Also published as: WO2008057973A3; JP2010508610A; US20080104615A1; EP2087462A2; IL197425A0; US8533746B2; EP2087462A4; WO2008057973A2; CA2661928A1

Abstract

애플리케이션 프로그램 인터페이스(API)는 건강 통합 네트워크 내의 데이터를 요청하고, 저장하며, 그 밖에 액세스하기 위해 제공된다. API는 XML과 같은 확장가능 언어 포맷으로 요청을 수신하는 능력뿐만 아니라, 인증/인가를 제공함으로써 중앙에 저장된 데이터로의 안전하고 끊어짐 없는 액세스를 용이하게 하고, 결과적으로 얻은 데이터를 XML 포맷으로 반환한다. 데이터는 또한 데이터와 관련된 변환, 스타일 및/또는 스키마 정보를 가질 수 있는데, 이러한 변환, 스타일 및/또는 스키마 정보는 결과적으로 얻은 XML로 반환될 수 있고, 및/또는 API에 의해 미리 데이터에 적용될 수 있다. API는 HTTP를 통한 XML 및 소프트웨어 개발 키트(SDK)를 포함하는 다수의 환경 아키텍처에서 이용될 수 있다.

API, 건강 통합 네트워크, 건강 관련 데이터, XML 포맷, 변환, 스타일, 스키마, 소프트웨어 개발 키트

Description

애플리케이션 프로그램 인터페이스(ＡＰＩ), 개인 건강 관련 데이터와 상호작용하는 방법 및 건강 관련 데이터를 액세스하는 시스템{HEALTH INTEGRATION PLATFORM API}

본 발명은 건강 통합 플랫폼 API에 관한 것이다.

고비용 저성능 데이터 처리 시스템에서 저비용 고성능 통신, 문제 해결 및 엔터테인먼트 시스템으로의 컴퓨터 및 네트워킹 기술의 발전은 서신왕래, 청구서 지불, 쇼핑, 정보 예산 및 수집 등등과 같은 일상적인 일을 수행하는 부담을 줄이기 위해 비용이 효과적이고 시간이 절약되는 수단을 제공했다. 예를 들어, 유선 또는 무선 기술을 통해 인터넷에 접속된 컴퓨팅 시스템은 세계 각 국에 위치한 웹 사이트 및 서버의 리포지토리(repository)로부터의 풍부한 정보로 거의 즉시 액세스하기 위한 채널을 사용자에게 제공할 수 있다. 이러한 시스템은 또한 사용자가 정보를 수집할 수 있게 할 뿐만 아니라, 정보를 이종의 소스에 제공할 수 있게 한다. 이와 같이, 온라인 데이터 저장 및 관리는 점점 더 인기를 끌고 있다.

예를 들어, 공동 사회 네트워킹 웹사이트가 세계적으로 급증했다. 이들 사이트는 연령, 성별, 출신 학교, 졸업반, 근무처 등과 같은 개인 데이터를 포함하여 원격 저장된 프로필을 사용자가 작성할 수 있게 한다. 이 사이트는 차후에, 다른 사용자를 찾고자 시도할 때 - 즉, 비슷한 취미를 가진 사람을 찾거나 오랫동안 잊고지낸 고등학교 시절 친구를 찾고자 할 때, 다른 사용자가 상기 기준을 검색할 수 있게 한다. 더욱 실질적인 다른 예로서, 은행 웹사이트는 납부될 요금 청구서에 관한 정보를 원격 저장하는 능력을 사용자에게 제공한다. 이 기능을 이용함으로써, 사용자들은 납부 예정 시기에 자동으로 지급될 요금 납부가 그들의 은행 계좌에서 이루어지도록 자동으로 스케줄을 잡을 수 있다. 이것은 이렇게 계좌 결산 및 청구요금 납부의 동시 전자 관리를 가능하게 하여, 사용자가 수표 기입장에 수표를 수동으로 써넣지 않아도 되게 한다.

이 나라 및 전세계에서 매우 관심 있는 또 다른 분야는 개인의 건강 및 체력 분야(health and fitness)이다. 다수의 매우 다른 관심사가 이 분야에서 논의될 수 있는데, 이를 테면 개인 체력의 목표 설정과 달성, 및 우리의 의료 제도에 존재하는 비효율성에 관한 본질적으로 매우 다른 주제가 그러하다. 예를 들어, 오늘날, 질병에 대한 약물 치료를 받고자 하는 개인은 먼저 주치 의사를 만나야 한다. 의사를 만나기 전에, 환자는 여러 번, 건강 보험 카드를 보여달라는 요구를 받을 것이다. 방문 동안에, 의사는 통상적으로 환장에 대한 처방전을 쓸 것이다. 그 다음, 환자는 조제를 위해 처방전을 약국에 가지고 가는데, 이때 환자는 건강 보험 카드를 다시 제출할 필요가 있을 수 있다. 약국은 처방전을 조제하고, 보험에 통지하며, 임의의 보상 범위 액을 공제하고, 나머지 금액의 지불시에 환자에게 처방전을 건네준다. 이러한 수동적인 단계들은 시간이 소모되고, 성가시며, 비효율적이다.

다음은 여기에서 설명된 몇몇 실시양상의 기본적인 이해를 제공하기 위해 단순화된 요약을 나타낸 것이다. 이 요약은 광범위한 개요도 아니고, 핵심적인/중요한 요소를 식별한다거나 여기에서 설명된 여러 실시양상의 범위를 나타내고자 하는 것도 아니다. 그 유일한 목적은 나중에 제시되는 더욱 상세한 설명의 서론으로서 단순화된 형태로 몇 가지 개념을 나타내기 위한 것이다.

건강 통합 네트워크와 통신하는 애플리케이션 프로그램 인터페이스(API)가 제공되는데, 여기에서 애플리케이션은 개인의 건강 및 체력 관련 데이터를 검색하고, 저장하며, 그 밖에 액세스하거나 수정하기 위해 API를 이용할 수 있다. API는 새로운 코드가 구현될 필요없이 요청 또는 응답 XML에 대한 변경이 발생할 수 있는 개방 시스템을 용이하게 하기 위해 확장성 생성 언어(XML)와 같은 확장가능 언어 포맷으로 애플리케이션과 통신할 수 있다. 그러나, 부가적으로, API는 동작가능한 개방 시스템을 유지하는데 필요한 공통 포매팅 레벨을 유지하기 위해 XML 스키마를 따르도록 요구할 수 있다. API를 통해 요청되고 저장되며 반환될 수 있는 데이터는 또한 자체-설명적인 것일 수 있고, 데이터의 지능적인 렌더링을 용이하게 하기 위해 관련된 스키마와, 또한 변환 및 스타일 정보를 가질 수 있다. API는 또한 상이한 레벨에 관한 데이터를 액세스하기 위한 애플리케이션 및 사용자의 인증/인가 계층을 제공할 수 있다.

시스템에 저장된 데이터는 예를 들어, 혈압 수치, 보험 정보, 처방전, 가족력, 개인 병력, 진단, 알레르기, 엑스레이, 혈액 검사 등과 같은 건강에 관한 데이터일 수 있다. 게다가, 데이터는 예를 들어, 운동 루틴, 운동 목표, 다이어트, 운동 루틴에 기초한 가상 탐험, 경쟁 등과 같은 체력 관련 데이터일 수 있다. API는 저장, 검색 및 기타 액세스를 위해 이 모든 데이터로의 액세스를 용이하게 한다. 애플리케이션은 데이터에 값을 추가하기 위해 이 데이터를 액세스할 수 있는데, 예를 들어, 애플리케이션은 보험 회사가 사용자의 보험 정보를 입력할 수 있게 하고, 의원은 사용자에 의한 의사 방문시에 이 정보를 액세스하여, 사용자가 보험 카드를 보여줄 필요성을 경감시킬 수 있다. 이 예를 더욱 들면, 의사는 사용자의 계정 아래에 처방전에 대한 정보를 입력할 수 있고, 약국은 보험 정보뿐만 아니라, 사용자에 대한 처방전을 조제하기 위해 이 정보를 검색할 수 있어서, 사용자가 보험증을 보여줄 필요성, 및 처방전을 집어들 때 미끄러져 놓치는 일을 경감시킬 수 있다. 그러므로, API는 값을 추가하고 건강 및 체력 분야에서의 현재의 프로세스를 능률화하기 위해 개인 건강 및 체력 관련 데이터로의 가치있는 액세스를 다수의 애플리케이션에 제공할 수 있다.

상기 및 관련 목적을 달성하기 위해, 소정의 예시적인 실시양상은 다음의 상세한 설명 및 첨부 도면과 관련하여 여기에서 설명된다. 이들 실시양상은 실시될 수 있는 다양한 방식을 나타내는데, 이 모두는 본 발명에 속하게 된다. 그 밖의 다른 장점 및 새로운 특징은 도면과 함께 고려할 때 다음의 상세한 설명으로부터 명백해질 것이다.

도 1은 요청 컴포넌트와 백-엔드 데이터 컴포넌트 사이의 데이터 통신을 위 한 API의 이용을 용이하게 하는 예시적인 시스템의 블록도.

도 2는 예시적인 API의 블록도.

도 3은 애플리케이션과 건강 통합 네트워크 사이의 데이터 통신을 위한 API의 이용을 용이하게 하는 예시적인 시스템의 블록도.

도 4는 개인 건강 정보의 통신을 용이하게 하는 예시적인 시스템의 블록도.

도 5는 API로부터의 개인 건강 정보의 요청을 용이하게 하는 예시적인 시스템의 블록도.

도 6은 소프트웨어 개발 키트(SDK)를 사용하여 API로부터 개인 건강 정보을 요청하는 것을 용이하게 하는 예시적인 시스템의 블록도.

도 7은 예시적인 API의 블록도.

도 8은 API를 사용하여 건강 통합 네트워크로부터 데이터를 요청하는 예시적인 흐름도.

도 9는 애플리케이션으로부터의 개인 건강 정보의 요청을 처리하는 예시적인 흐름도.

도 10은 적합한 운영 환경을 도시한 개략적인 블록도.

도 11은 샘플 컴퓨팅 환경의 개략적인 블록도.

애플리케이션 프로그램 인터페이스(API)는 건강 통합 네트워크의 액세스를 용이하게 하기 위해 제공된다. API는 건강 통합 네트워크 내의 데이터를 검색하거나 저장하거나 수정하거나 그렇지 않으면 액세스하라는 애플리케이션으로부터의 요 청을 수신하고 처리할 수 있으며, 인증/인가 기능을 제공할 수 있다. API는 XML(Extensible Markup Language) 스키마에 따라 XML과 같은 확장가능 데이터 형태로 요청을 수신할 수 있고; 게다가, API는 XML 스키마에 따라 요청에 관련된 정보의 데이터 집합을 나타내는 XML로 그러한 요청에 응답할 수 있다. API는 API를 사용하기 쉽고 완료하기 쉬우며 경량화하기 쉽게 개인의 건강 및 체력 관련 데이터의 중앙 저장소를 효과적으로 생성하기 위해 이렇게 다수의 장치 및 애플리케이션과 함께 동작한다. 애플리케이션은 이러한 확장가능 시스템이 전혀 없는 경우에 상호-애플리케이션 운용성을 용이하게 하기 위해 다른 애플리케이션과 공유될 수 있는 그 자신의 유형을 지정할 뿐만 아니라 시스템 데이터 유형을 사용할 수 있다. 애플리케이션과 API 사이에서 통신하기 위해 사용된 확장가능 데이터 형태는 데이터가 저장되는 방법, 데이터가 변환되고, 양식화되며 및/또는 체계화될 수 있는 방법을 설명하는 데이터와 함께 사실상 임의 종류의 정보가 저장될 수 있게 함으로써 이것을 달성한다. 데이터는 또한 비구조적 또는 비체계적 방식으로 저장될 수 있고 얻어질 수 있다는 것을 알 수 있을 것이다.

본 명세서의 다양한 실시양상은 이제 첨부 도면과 관련하여 설명되는데, 도면 전반에 걸쳐 동일한 숫자는 동일하거나 대응하는 요소를 나타낸다. 그러나, 도면 및 이에 관한 상세한 설명은 청구된 주제를 개시된 특정 형태로 제한하고자 하는 것이 아니라는 것을 이해할 것이다. 오히려, 의도하는 바는 청구된 주제의 정신 및 범위에 속하는 모든 변경, 등가물 및 대안을 포함하고자 하는 것이다.

이제, 도면을 참조하면, 도 1은 건강 통합 네트워크에 참여하기 위해 이용될 수 있는 시스템으로서 데이터 저장 및 검색을 용이하게는 시스템(100)을 도시한 것이다. 요청 컴포넌트(102)는 API(104)에 데이터 검색, 데이터 저장 등의 요청을 지정할 수 있고, API(104)는 요청을 해석하고, 요청에 기초하여 백 엔드 데이터 컴포넌트(106)에 문의할 수 있다. 그 다음, 백 엔드 데이터 컴포넌트(106)는 API(104)에 응답할 수 있고, API(104)는 최소한 요청 컴포넌트(102)에 결과를 반환할 수 있다. 요청 컴포넌트(102)는 이를테면 요청을 함으로써 API(104)와 통신할 수 있는 임의의 장치일 수 있다. 가능한 요청은 요청 컴포넌트(102)의 인증/인가를 위해 이루어진 것들, 데이터 저장, 데이터 검색, 데이터 변경 및 데이터로의 임의의 값-추가 서비스, 이를테면 데이터 단위의 추가, 데이터의 포맷에 관한 스타일 및 스키마의 검색 및 적용, 사용자 인터페이스 및 데이터의 레이아웃 등을 포함하는데, 이에 제한되는 것은 아니다.

API(104)는 백 엔드 데이터 컴포넌트(106)와의 통신을 용이하게 하기 위해 요청 컴포넌트(102)로부터의 요청을 해석하는데 이용될 수 있다. 요청 컴포넌트(102)에 의해 보내진 요청은 HTTP(hypertext transfer protocol)를 사용하여 XML을 통해 이루어진 호출, API(104)에 직접 이루어진 호출, 및/또는 API(104) 주위의 래퍼(wrapper)에 이루어진 호출일 수 있다. XML의 사용은 구조가 변경될 수 있고 데이터 해석에 새로운 코드를 필요로 하지 않는 확장가능 데이터 모델을 가능하게 한다. 이것은 특히 XML 스키마와 함께 사용했을 때, XML의 자기 설명 능력에 기인한다. 게다가, API(104)는 인가된 요청 컴포넌트만이 백 엔드 데이터 컴포넌트(106) 내의 소정의 데이터를 액세스할 수 있게 하기 위해 백 엔드 데이터 컴포넌 트(106) 위에 보안 계층을 제공할 수 있다. 본 주제에 따르면, 백 엔드 데이터 컴포넌트(106)는 개인 건강에 관련된 정보를 수용할 수 있는데, 방대한 정보 저장을 포함한다. 이러한 정보는 비교적 정적이고(예를 들어, 키, 체중, 병력(개인 및 가족), 질병, 알레르기, 보험 등), 이벤트-특정적이며(예를 들어, 운동 처방, 운동 바이탈(vitals) 및 통계, 현재의 약 처방, 건강 진단 등), 완전 동적이고(예를 들어, 혈압, 심박수, 식이요법 등), 기타 등등일 수 있다. API(104)는 본인의 요구나 의사의 명령 등에 기초하여 특정 개인에게 이 모든 정보로의 액세스를 허용하고 제한할 수 있다.

더욱이, API 컴포넌트(104)는 이벤트를 트리거하고, 실시간 갱신을 제공하며(예를 들어, 콜백 함수 등을 통해), 경고를 수신하는 등등을 위해 이용될 수 있다. 더욱이, 요청 컴포넌트(102)는 이벤트 또는 경고를 수신하게 될 수 있다. 그러한 이벤트 또는 경고는 임계치를 넘는 데이터(예를 들어, 높은 혈압) 입력시에, 필요한 데이터의 부재시에(예를 들어, 혈당 레벨 수치가 없을 때), 현실 세계 이벤트의 발생시에, 획기적인 사건 또는 목표의 달성시에, 데이터 만료시에, 기타 등등에 발생할 수 있다. 그러므로, 여기에 제시된 주제는 개인 건강 관련 데이터의 유리한 추적 및 그 데이터가 가치 있는 당사자들 사이의 능률적 통신을 가능하게 하기 위해 개인 건강 관련 데이터의 중앙 집중식 저장 및 액세스를 제공한다. 게다가, API(104)에서 다시 요청 컴포넌트(102)로 반환되거나 보내진 값은 (예를 들어, 소프트웨어 개발 키트를 사용할 때) 오리지널 호출로부터의 반환 호출, HTTP를 통한 XML 등등일 수 있다.

도 2와 관련하여, 설명된 주제에 따라 데이터를 검색하거나 저장하거나 변경하거나 그렇지 않으면 액세스하라는 요청을 용이하게 위해 다양한 컴포넌트를 갖는 API(200)가 도시된다. API(200)는 데이터 액세스의 요청을 수신하는 수신기 컴포넌트(202), 요청을 해석하고 원하는 데이터 및 임의의 관련 데이터 및/또는 메타데이터(상기 데이터에 대한 데이터)를 수집하는 인터프리터 컴포넌트(204)를 가질 수 있다. API(200)는 또한 요청 엔티티가 원하는 요청을 하기에 충분한 액세스를 갖는다는 것을 보장하기 위해 인가/인증 규칙을 요청 엔티티에 적용하는 인가 컴포넌트(206)를 포함할 수 있다. API(200)는 원하는 경우에 데이터에 변환, 번역, 스타일 및/또는 스키마를 적용할 수 있는 변환 컴포넌트(208)를 가질 수 있다. 변환 컴포넌트(208)는 이렇게 얻은 데이터를 적절한 및/또는 사용가능한 변환 정보로 패키징할 수 있으므로, 요청 엔티티는 원하는 변환을 실행할 수 있다. API(200)는 또한 임의의 부가된 데이터뿐만 아니라 원하는 데이터를 다시 요청 엔티티에 보내기 위해 반환 컴포넌트(210)를 활용할 수 있다. 갱신 컴포넌트(212)는 또한 애플리케이션이 API(200)에 부가되게 하고, 통신 채널을 개방해서, 정보에 대한 갱신을 자동으로 수신할 수 있게 하기 위해 제공될 수 있다. API(200)는 API(200)의 사용을 용이하게 하기 위해 지능적인 루틴을 작성하는 루틴 패키징 컴포넌트(214)를 더욱 제공할 수 있다.

API(200)를 이용하여, 장치, 애플리케이션, 애플리케이션을 실행하는 장치, 애플리케이션을 갖는 시스템에 부착된 레거시(legacy) 장치 등과 같은 요청 엔티티는 API(200)에 데이터 요청을 시작할 수 있는데, 이 요청은 수신기 컴포넌트(202) 에 의해 포착된다. 요청은 예를 들어, 처방전 정보와 같은 개인의 건강 및/또는 체력 관련 데이터를 액세스하는 것일 수 있다. 수신기 컴포넌트(202)는 요청을 수신하여, 인터프리터 컴포넌트(204)에 보낸다. 인터프리터 컴포넌트(204)는 예를 들어, 데이터 검색, 데이터 저장 또는 데이터 변경에 대한 요청의 유형을 판정하고, 요청되는 레코드 또는 유형을 판정한다. 인터프리터 컴포넌트(204)는 요청 엔티티가 제시된 요청 유형에 대해 요청 데이터를 액세스하기에 충분한 권한을 가졌는지 판정하기 위해 인가 컴포넌트(206)를 활용할 수 있다. 예를 들어, 한 당사자는 배우자의 의료 진단을 변경하거나 심지어 그 의료 진단을 볼 수 있는 충분한 액세스를 갖지 못할 수 있다. 인가 규칙은 데이터가 직접 관련된 사람, 의료 전문가 등을 포함하여 많은 당사자에 의해 설정될 수 있다. 엔티티의 액세스가 거부되면, 반환 컴포넌트(210)는 다시 그 요청 엔티티에 (예를 들어, XML 포맷으로) 결과적으로 생긴 에러 통지를 보낼 수 있다.

액세스가 허가되면, 인터프리터 컴포넌트(204)는 관련 데이터를 액세스할 수 있는데, 처방전 예에서, 이것은 처방약 이름, 유형 코드, 지침, 용량, 의사의 서명이 있는 처방전의 이미지 등을 포함할 수 있다. 그 다음, 이 정보는 변환 컴포넌트(208)에 넘겨질 수 있는데, 변환 컴포넌트(208)는 요청 엔티티가 찾는 정보, 및 요청한 임의의 변환을 판정할 수 있다. 예를 들어, 아마도 요청 엔티티는 처방전의 그림을 요청하지는 않았을 것이고; 변환 컴포넌트(208)는 인터프리터 컴포넌트(204)에 의해 보내진 명령어로부터 그림 이외의 모든 정보를 얻기 위한 스키마를 적용할 수 있으므로, 텍스트 정보만을 보내는 것보다 상당히 많은 대역폭을 필요로 할 수 있는 그림을 보낼 필요성이 경감된다. 게다가, 아마도 요청 엔티티는 처방전에 대한 유형 코드의 번역을 원할 것이고, 예를 들어 코드는 항염증 치료를 나타낼 수 있으며, 요청 엔티티는 이 정보를 사용자에게 표시하고자 할 것이다. 또한, 아마도 활성 성분 및/또는 부작용의 설명이 유형 코드에 기초하여 반환될 수 있을 것이고 - 변환 컴포넌트(208)는 또한 요청한 경우에 이 정보를 수집할 수 있다. 원하는 모든 정보가 수집된 후, 반환 컴포넌트(210)는 요청한 포맷으로, 예를 들어 확장성 생성 언어(XML) 또는 임의의 반환 유형으로 데이터를 다시 요청 엔티티에 보낼 수 있다. 반환된 데이터의 레이아웃을 설명하는 첨부 스키마가 또한 반환될 수 있다.

갱신 컴포넌트(212)는 통신 채널, 예를 들어 파이프가 애플리케이션(또는 다른 수신 컴포넌트)과 API(202) 사이에서 개방되는 다른 유형의 데이터 액세스를 제공할 수 있다. 데이터가 건강 통합 네트워크와 같은 하위 시스템을 통과할 때, 갱신 컴포넌트(212)는 접속된 애플리케이션이 데이터에 접근할 권한을 가졌다고 하면, 소정의 데이터를 접속된 애플리케이션에 자동으로 통지(또는 경고)할 수 있다. 이 갱신 컴포넌트(212)는 이벤트 또는 소정의 임계치를 넘는 데이터의 실시간 발생에 기초하여 상이한 사용자들에게 경고가 보내질 수 있는 이벤트 기반 시스템을 용이하게 한다. 예를 들어, 혈압이 다수의 일관된 높은 혈압 수치(임계치를 초과하는 수치)를 받은 경우에, 이벤트는 통지를 하고 예약을 요청하기 위해 의원 시스템에 보내질 수 있다. 정보는 또한 사용자에게 높은 혈압 수치, 및 예약 요청이 자신의 의사에게 보내졌다는 것을 통지하기 위해 다시 혈압 모니터에 보내질 수 있 다. 갱신 컴포넌트(212)를 이용함으로써 사용가능한 다수의 유사한 시나리오가 있을 수 있다. 이와 유사하게, 개방 채널은 예를 들어, 장치가 일정한 갱신을 보내는 것이라면, 자동으로 건강 통합 네트워크에 데이터를 제공할 수 있다. 예를 들어, 사용자에 의해 작동된 트레드밀(treadmill)은 세션 동안에 일정한 심박수를 잴 수 있고, 예를 들어 실시간으로, 이 정보 및 운동 루틴에 관한 기타 정보로 건강 통합 네트워크를 갱신하기 위해 채널을 개방할 수 있다. 개방 채널이 요구되지 않고; 오히려 API(200)는 자동으로, 예를 들어 (콜백 유형 함수와 같은) 애플리케이션에 경고 또는 갱신을 통지하도록 요청할 수 있다는 것을 알 수 있을 것이다.

루틴 패키징 컴포넌트(214)는 애플리케이션 개발자가 API(200)를 이용하여 제3자 애플리케이션을 작성하는 것을 돕기 위해 다수의 상이한 기능을 제공할 수 있다. 예를 들어, 루틴 패키징 컴포넌트(214)는 실제로 API(200)와 함께 시작될 필요가 있는 것을 개발자에게 제공하기 위해, 공통으로 이용된 루틴 집합을 단일 호출 내에 함께 묶거나 또는 이들을 패키지 프레젠테이션 내에 제시할 수 있다. 게다가, 루틴은 건강 통합 네트워크와 같은 하위 시스템에서 일반적으로 사용되는 XML 및 관련 스키마를 작성하기 위해 제공되어, 네트워크에 저장될 데이터 유형 및 상이한 레코드와 같은 것들을 작성할 수 있다. 더구나, 인공 지능은 루틴의 패키징, 또는 더욱 사용하기 쉬운 추가 루틴의 작성을 판정하기 위해 이용될 수 있다. 이들 작성된 루틴은 반드시 함께 저장되는 것은 아닌 관련 데이터를 얻기 위한 단일 호출과 같은 다소 향상된 작업을 실행하기 위해 개발자에게 제공된 단일 호출일 수 있고, 예를 들어 GetLastExerciseRoutine은 사용자의 최종 운동 기간 정보뿐만 아니라 이 즈음에 측정된 임의의 심박수를 검색하도록 작성될 수 있다. 언급된 바와 같이, 이들 함수가 종종 함께 호출된다는 결정과, 이 데이터를 함께 원할 수 있는 애플리케이션 개발자에게 데이터 액세스를 더욱 용이하게 하기 위해 데이터를 액세스하는 단일 루틴을 작성한다는 결정이 (예를 들어, 인공 지능을 사용하여) 이루어질 수 있다. 상기 시나리오는 단지 예일 뿐이고, 주제는 이에 제한되지 않는다는 것을 알 수 있을 것이다.

도 3은 애플리케이션(302)으로부터의 데이터 저장, 검색 등의 요청을 해석하기 위한 API(104)의 이용을 용이하게 하는 시스템(300)을 도시한 것이다. API(104)는 애플리케이션(302)으로부터의 요청에 기초하여 건강 통합 네트워크(304)에 문의하고, 건강 통합 네트워크(304)로부터의 응답에 기초하여 애플리케이션(302)에 데이터를 반환한다. 애플리케이션(302)은 컴퓨터 또는 기타 장치상에서 실행되는 소프트웨어 애플리케이션, 장치 자체, 예를 들어 레거시 장치 컨텍스트 내의 애플리케이션 또는 컴퓨터에 결합된 장치 등일 수 있다. 예시적인 장치는 출력이 있는 것들과 같은 임의의 의료 또는 개인 건강 장치(예를 들어, 혈압 모니터, 체중계, 혈/당 레벨 모니터, IV, 맥박 조정기, 청진기, 엑스레이 등), 개인 체력 추적 장치(결합형 심박수 모니터 시계, 보수계(pedometers), 자전거 장비(이를테면, 속도계, 고도계, 주행 거리계 등), 스톱워치 등), 및 개인용 및 의료용 사용자 인터페이스를 포함하는 기타 애플리케이션을 포함한다. 그러므로, 의사는 처방전, 진단 또는 기타 차트로부터 수동으로 환자 특정 정보를 저장할 수 있고, 개인은 식이요법, 운동 처방, 의료 보험 등에 대한 정보를 저장할 수 있다. 데이터는 임의의 유형일 수 있고, 관련된 유형 정의, 데이터의 레이아웃을 설명하는 스키마, 및 데이터가 제시될 수 있는 방법을 설명하는 스타일 파라미터를 가질 수 있다. 애플리케이션(302)은 API(104)에 직접 요청을 하기 위해 이렇게 접속될 수 있지만, 또한 갱신 기능을 이용하여 개방 채널(또는 파이프) 접속으로 접속될 수 있다.

한 예로서, 환자는 보험 및 약국 정보를 입력하기 위해 애플리케이션(302)을 이용할 수 있다. 애플리케이션(302)은 이것을 API(104)에 제출할 수 있고, API(104)는 건강 통합 네트워크 내의 저장을 요청할 수 있다. 그 다음, 환자가 의원에 가면, 접수원은 API(104)를 사용하여 정보를 요청하는 동일한 또는 분리된 애플리케이션(302)을 통해 보험 정보를 검색할 수 있다. API(104)는 건강 통합 네트워크(304)로부터 환자의 보험 정보를 검색해서 API(104)에 전송하고, API(104)는 이것을 애플리케이션(302)에 전송한다. 이것은 접수원이 환자의 보험 카드를 요구할 필요성을 경감시킨다. 그 후, 예약 동안에, 의사는 환자의 의료 처방전을 입력하기 위해 동일하거나 상이한 애플리케이션(302)을 사용할 수 있고; 처방전은 API(104)를 통해 건강 통합 네트워크(304)에 저장된다. 이때, 동일하거나 상이한 애플리케이션(302)을 또한 실행하고 있는 환자의 약국에 경고가 보내져서 처방전의 조제를 요청할 수 있다. 대안적으로, 환자는 약국에 가서 처방전 조제를 요청할 수 있고, 약국은 정보가 건강 통합 네트워크(304)에 저장되어 있으므로 환자로부터 처방전을 얻을 필요가 없다. 약국은 애플리케이션(302)을 사용하여 API(104)를 액세스해서 건강 통합 네트워크(304)로부터 그 환자에 대한 처방전 및 보험 데이터를 검색할 수 있다.

다른 예로서, 애플리케이션(302)은 API(104)에 개인의 혈압을 저장하라고 요청할 수 있는 혈압 모니터와 같은 장치일 수 있는데, 아마도 혈압은 최근 5번의 판독 수치에서 높다고 생각되었을 것이고, 혈압기는 API(104)로부터 경고를 받아서 이 사실을 개인에게 통지할 수 있다. 더욱이, 의원에 있는 애플리케이션(302)은 개인에 대한 이 정보를 API(104)로부터의 경고를 통해 수신하여, 연속적으로 높은 혈압 수치를 의사에게 통지할 수 있고, 의사 또는 아마도 개인 트레이너는 또한, 예를 들어 몇 가지 추가 심혈관 세션을 포함하도록 환자의 운동 계획을 조정할 수 있고 식단에서 소금을 줄이도록 할 수 있다. API(104)는 상기 예에 제한되지 않고, 실제로, 데이터 감사 방법을 또한 포함하여 데이터 및 건강 통합 네트워크(304)에 관한 여러 가지 방법을 실행할 수 있다. 게다가, 애플리케이션(302)은 API(104)로부터 보내진 메시지가 공개 및/또는 개인 키에 의해 암호화되도록 지정할 수 있고, 애플리케이션(302)은 데이터를 암호 해독하기 위한 개인 키를 갖는다. 이러한 방식으로, 개인 정보 및 신빙성을 보장하기 위해 시스템 내에서 통신된 데이터에 더 많은 보안이 제공된다. 더구나, 애플리케이션(302)은 응답이 주어진 기간 내에 수신되지 않을 때 메시지가 만료될 수 있게 하기 위해 메시지에 유지 시간 값을 설정할 수 있다. 이와 관련하여, 애플리케이션(302)은 메시지가 돌아오기를 기다릴 필요가 없고; 오히려 메시지는, 예를 들어 애플리케이션(302)이 다른 곳에서 더 빨리 정보를 찾을 수 있는 경우에 만료될 수 있다.

도 4와 관련하여, 건강 통합 네트워크 내의 정보의 액세스를 용이하게 하는 예시적인 시스템(400)이 도시된다. 애플리케이션(302)은 건강 관련 데이터를 표시 하거나 지정하는 것 중의 적어도 한 가지를 할 수 있다. 애플리케이션(302)은 소프트웨어 애플리케이션, 소프트웨어 애플리케이션을 실행하는 전자 장치, 전자 장치 단독, 소프트웨어 애플리케이션을 실행하는 장치와 접속할 수 있는 레거시 장치 등을 포함하여 다수의 상이한 유형의 애플리케이션일 수 있다는 것을 알 수 있을 것이다. 애플리케이션은 건강 통합 네트워크(304) 내의 데이터를 요청하고 그 네트워크 내에 데이터를 저장하기 위해 API(104)를 이용할 수 있다. API(104)는 유사한 또는 상이한 유형의 다수의 애플리케이션(302)과 동기로 또는 비동기로 통신할 수 있다는 것을 알 수 있을 것이다. API(104)는 또한 요청을 해석하고 처리할 때 활용하기 위해 소프트웨어 계층(402)을 가질 수 있다. 소프트웨어 계층(402)은 도시된 바와 같이 분리될 수 있고, 또는 API(104) 또는 건강 통합 네트워크(304) 내에 통합되거나, 또는 이 둘 다에 통합될 수 있다. 애플리케이션(302)으로부터의 요청을 해석하고 처리할 때, 소프트웨어 계층(402)은 임의의 필요한 데이터를 위해 또는 요청을 이행하는데 필요한 데이터를 저장하기 위해 건강 통합 네트워크(304)를 액세스할 수 있다. 소프트웨어 계층(402)은 또한 건강 통합 네트워크(304)로부터의 데이터를 어셈블하는 것, 데이터와 관련하여 비즈니스 모델 또는 프로세스를 적용하는 것, 데이터를 캐싱하는 것, 및/또는 데이터에 관한/데이터에 변환 또는 추가 정보를 가하는 것과 같이, 데이터에 값 추가를 제공할 수 있다. 중앙 집중 건강 통합 네트워크(304)에 접속하는 다수의 API(104) 및 소프트웨어 계층(402)이 있을 수 있고, 중앙 집중 건강 통합 네트워크(304)는 단일 시스템이거나 다수의 시스템, 플랫폼 등에 걸쳐 분산될 수 있다.

건강 통합 네트워크(304)는 레코드 데이터베이스(404), 디렉토리 데이터베이스(406) 및 사전 데이터베이스(408)를 포함하는 다수의 데이터 저장소를 포함할 수 있다. 게다가, 건강 통합 네트워크(304)는 데이터 관리 및 전송을 용이하게 하기 위해 다수의 다른 시스템을 포함할 수 있다. 더욱이, 데이터베이스들은 각 데이터베이스의 다수의 버전이 그외 다른 API 및 애플리케이션에, 및/또는 데이터베이스의 다른 버전을 위한 백업 소스에 사용 가능하도록 중복적일 수 있다. 게다가, 데이터베이스는 높은 액세스 시스템을 위한 효율적인 액세스를 가능하게 하기 위해 다양한 물리적 데이터 저장소 사이에서 논리적으로 분할될 수 있다. 더구나, 데이터베이스는 XML과 같은 계층 기반형 및/또는 관계 기반형일 수 있다. 레코드 데이터베이스(404)는 고도로 분산될 수 있고, 다수의 사용자를 위한 개인 건강 관련 데이터 레코드를 포함할 수 있다. 레코드들은 상이한 포맷으로 이루어질 수 있고, 일반 데이터, 데이터 및 관련 유형 정보, (예를 들어, XSL 스키마와 같은 관련 스키마를 통한) 자기 설명 데이터, (예를 들어, 스타일시트를 통해) 관련된 템플릿을 갖는 데이터, (변환 명령어를 갖는 데이터, (그림, 엑스레이 등과 같은) 이진 데이터와 같은) 유닛을 갖는 데이터 등과 같은 임의 종류의 데이터(단일 인스턴스, 구조적 또는 비구조적 데이터)를 포함할 수 있다. 더구나, 레코드 데이터베이스(404)는 추적 및 복원 목적을 위해 레코드에 행해진 변경의 감사 내역을 유지할 수 있다. 게다가, 상기 정보의 임의의 데이터 유형 또는 관련 인스턴스는 아래에서 설명되는 사전 데이터베이스(408)와 같은 이종의 데이터베이스 내에 저장될 수 있다. 레코드 데이터베이스(404)는 성능, 논리적인 사용자 그룹화(예를 들어, 동 일 회사, 가족 등의 사용자들)를 포함하는 다수의 요인에 기초하여 분할, 분산 및/또는 세분화될 수 있다.

디렉토리 데이터베이스(406)는 사용자 이름, 인증서, 사용자를 위한 레코드의 존재 등을 포함할 수 있는 사용자 계정 데이터와 같은 정보를 저장할 수 있다. 디렉토리 데이터베이스(406)는 또한 레코드가 속해 있는 사용자, (분산 레코드 데이터베이스(404) 구성에서) 레코드가 유지되는 곳, 레코드를 위한 인증 규칙 등을 포함하여 레코드 자체에 대한 정보를 수용할 수 있다. 예를 들어, 사용자는 배우자가 자신의 체력 관련 데이터로의 액세스를 갖지만 의료 건강 관련 데이터로의 액세스는 갖지 않는다는 것을 지정할 수 있다. 이러한 방식으로, 사용자는 적절한 당사자(이를테면, 배우자, 의사, 보험 회사, 개인 트레이너 등) 또는 애플리케이션/장치(혈압기, 맥박 조정기, 피트니스 시계 등)가 관련 데이터로의 액세스를 가질 수 있게 하면서 자신의 데이터를 보호할 수 있다. 게다가, 디렉토리 데이터베이스(406)는 건강 통합 네트워크(304)와 상호작용하기 위해 애플리케이션(302)의 구성에 관한 데이터를 포함할 수 있고; 애플리케이션(302)은 건강 통합 네트워크(304)에 등록하도록 요구될 수 있으므로, 디렉토리 데이터베이스(406) 내의 애플리케이션 데이터는 등록 정보를 포함한다.

사전 데이터베이스(408)는 API(104) 및 소프트웨어 계층(402)과 같은 엔티티를 요청하고 건강 통합 네트워크(304)에 의해 사용된 어휘 정의에 관한 정보를 유지할 수 있다. 이러한 정의는 데이터 유형 정의, 및 상이한 데이터 유형을 표시하거나 이들을 변환하는 방법에 관한 정보를 포함할 수 있다. 게다가, 사전 데이터 베이스(408)는 레이아웃 및 템플릿 등의 표시를 위한 정보를 유지할 수 있다. 더욱이, 사전 데이터베이스(408)는 표준의 사용 등을 통해 코드를 정의하는 상이한 조회 테이블을 유지할 수 있다. 예를 들어, 사전 데이터베이스(408)는 국가 건강 통계 센터에 의해 배포된 국제 질병 분류 제9 개정판(ICD-9)을 지원할 수 있다. 이들 코드는 상이한 질병 및 진단을 식별하고; 따라서 의사는 이들 코드 중의 하나를 건강 통합 네트워크(304) 내의 사용자 차트에 기록할 수 있고, 사전 데이터베이스(408)는 소프트웨어 계층(404)(또는 API(104))이 이 코드를 사용자에게 더 잘 이해되는 어떤 것으로, 이를테면 의학적인 명칭, 및/또는 진단에 관한 상이한, 그외 다른, 또는 추가적인 정보로 번역할 수 있게 할 수 있다. 사전 데이터베이스(408)는 또한 복수형 및 단축된 형태의 코드(이를테면 ICD-9 코드)와 같은 기타 메타데이터를 검색하기 위해 사용될 수 있다. 사전 데이터베이스(408)는 또한 상이한 측정 단위들 사이의 변환, 이를테면 피트에서 미터로, 화씨에서 섭씨로, 파운드에서 킬로그램으로 등등의 변환을 할 수 있게 하는 정보를 유지할 수 있다.

한 실시예에서, 2개 이상의 애플리케이션일 수 있는 애플리케이션(302)은 예를 들어, 데이터를 요청하거나 저장하거나 변경하기 위해 API(104)에 호출을 할 수 있다. API(104)는 애플리케이션(302)에 의해 이루어진 호출을 처리하기 위해 소프트웨어 계층(402)을 활용한다. 그 다음, 소프트웨어 계층(402)은 원하는 데이터를 찾기 위해 자신의 내부 캐시 또는 건강 통합 네트워크(304)를 조회할 수 있고; 추가로 또는 대안적으로, 소프트웨어 계층(402)은 원하는 데이터를 찾기 위해 하나 또는 다수의 데이터베이스(404, 406 및 408)를 직접 조회할 수 있다. 소프트웨어 계층(402)은 건강 통합 네트워크(304)로부터 모든 데이터가 얻어질 때까지 데이터를 찾기 위해 직렬로 또는 비동기로 조회할 수 있다. 그 다음, 소프트웨어 계층(402)은 다른 데이터를 사용하여 자신이 얻은 데이터의 부분들을 조작처리 해서 애플리케이션(302)에 의해 요구된 결과를 체계적으로 나타내어 그 결과를 API(104)를 통해 애플리케이션(302)에 반환할 수 있다. 예를 들어, 애플리케이션(302)은 API(104)를 호출함으로써 사용자의 혈압 수치를 요청할 수 있고, 그 다음 API(104)는 요구된 수치를 체계적으로 나타내기 위해 소프트웨어 계층(402)과 통신할 수 있다. 소프트웨어 계층(402)은 혈압 수치의 위치를 얻기 위한 디렉토리 데이터베이스(406), 혈압 유형에 대한 스키마, 스타일 및 일반 유형 정보를 얻기 위한 사전 데이터베이스(408) 및 실제 수치를 얻기 위한 레코드 데이터베이스(404)를 건강 통합 네트워크(304)를 통하거나 직접 조회할 수 있다. 스키마를 사용하여, 소프트웨어 계층(402)은 수축기 혈압 및 확장기 혈압(및 아마도 맥박수)을 나타내는 2개의 정수로서 레코드를 해석할 수 있고, 이들 숫자를 API(104)를 통해 애플리케이션(302)에 반환하거나, 또는 숫자에 스타일, 단위 또는 다른 템플릿을 적용하고, 결과가 문자열이든, XML이든, HTML이든, 그림 등등이든지 그 결과를 반환한다. 게다가, 소프트웨어 계층(402)은 원시 데이터를 변환, 스타일 및/또는 스키마 정보와 함께 API(104)를 통해 애플리케이션(302)에 반환하여, 애플리케이션이 이들을 마음대로 적용할 수 있게 할 수 있다. 또한, 소프트웨어 계층(402)은 결과를 장래의 액세스를 위해 캐시 메모리에 저장할 수 있다. 설명된 주제는 상기 예/실시예에 제한되는 것이 아니라, 오히려 이것은 건강 통합 네트워크(304)와 접속하는 API(104)의 다수의 가능한 실시예 중의 하나라는 것을 알 수 있을 것이다.

이제, 도 5를 참조하면, 여기에 개시된 주제의 실시예에 따른 시스템(500)이도시된다. 시스템(500)은 건강 통합 네트워크(304)로부터 데이터를 검색하거나, 저장하거나, 변경하거나 그렇지 않으면 액세스하는 것 중의 최소한 하나에 대한 요청을 하는 애플리케이션(302)을 포함한다. 요청은 XML 포맷으로 요청을 지정하는 HTTP 프로토콜을 사용하여 인터넷(502)을 통해 API(104)에 보내질 수 있다. API는 애플리케이션(302)에 의해 보내진 요청으로부터 요청 파라미터를 구하기 위해 XML 인터프리터(504)를 포함한다. 데이터의 요청은 설명된 바와 같이 XML 형태로 API(104)에 제출될 수 있고, XML 인터프리터(504)는 유효 요청으로 생각되도록 XML이 XML 스키마에 부착될 것을 요구할 수 있다. 요청은, 예를 들어 애플리케이션의 인가/인증 또는 보안 토큰 유형 목적을 위한 서명, (메서드 이름을 포함할 수 있는) 파라미터의 목록, 사람 ID(요청하는 당사자가 정보를 찾는 사용자와 다른 경우, 예를 들어 환자 기록을 액세스하는 의사), 레코드 ID(예를 들어, 레코드가 조작처리되고 있는 경우), 사용자의 인증 토큰, 언어 사양, 국가 사양, 메시지 생성 시간 및 만료 시간, 및/또는 메서드에 의해 요구된 임의의 파라미터와 같은 정보를 지정할 수 있다. 설명된 주제의 실시예에 따라 API에 보내진 샘플 XML 요청은 다음과 같을 수 있다.

이 예에서, sig 태그는 요청하는 애플리케이션 인증서의 개인 키와 관련하여 데이터의 암호화에 관한 정보를 포함하고, params 섹션은 요청의 상세를 나타낸다. 특히, method 태그는 메서드 이름, 및 위에서 열거한 다양한 엔트리를 지정한다. 구체적으로, info 섹션은 호출되는 메서드에 의해 요구된 파라미터를 포함한다. 이 경우에, GetThings는 섹션이 2개 이상 있는 경우에 어느 섹션이 반환될 것인지 지정하는 섹션 파라미터뿐만 아니라 검색되고 있는 정보의 유형(체중, 혈압, 약물 등)을 식별하는 유형 id를 요구한다. 적절한 데이터가 요구된다는 것을 보장하기 위해 그외 다른 info 요소가 보충될 수 있고; 따라서 XML API 호출은 건강 통합 네트워크 내에 존재할 수 있는 추가 정보 및 유형을 수용하기 위해 확장 가능하다는 것을 알 수 있을 것이다. 개시된 주제는 HTTP 요청을 통한 XML에 제한되는 것이 아니라, 오히려 이것은 애플리케이션이 API를 통해 건강 통합 네트워크와 통신하는 여러 방법 중의 하나일 뿐이라는 것을 알 수 있을 것이다.

레코드 데이터 요청에 대한 응답은 또한 XML 형태로 될 수 있고, 인터넷(502)을 통해 HTTP를 사용하여 다시 API(104)에서 애플리케이션(302)으로 전송될 수 있다. 이들 응답은 상태 코드(숫자 및 설명), 임의의 결과적으로 생긴 데이터(이 예에서 "싱(thing)"으로 불리고 아래에서 더욱 설명됨)를 단위, 스타일, 스키마 등과 함께 포함할 수 있다. 예를 들어, 여기에서 설명된 주제에 따른 API 호출로부터의 응답은 다음과 같을 수 있다.

여기에서 설명된 주제는 상기 요청 및 응답 예에 제한되는 것이 아니라, 오히려 이들은 HTTP 요청/응답 규칙을 통한 XML의 예일 뿐이라는 것을 알 수 있을 것이다. 알 수 있는 바와 같이, SDK 개체 모델 및 XML뿐만 아니라, 아래에 나타낸 다수의 지원 언어(이를테면 .NET, Java 등)와 호환가능한 노출된 소프트웨어 개발 키트(SDK)와 같이 애플리케이션(302)이 API(104)와 통신하는 여러 가지 방식이 있다.

이제, 도 6을 참조하면, 여기에서 설명된 주제의 실시예에 따라 건강 통합 네트워크로부터 데이터를 액세스하는 시스템(600)이 제시된다. 건강 통합 네트워크(304)를 액세스할 수 있는 애플리케이션인 애플리케이션(302)에는 소프트웨어 개발 키트(SDK)(602)가 구비된다. SDK(602)는 애플리케이션이 건강 통합 네트워크(304) 내에 저장된 데이터를 요청하거나, 저장하거나, 변경하거나, 그렇지 않으 면 액세스하기 위한 호출을 할 수 있게 한다. API(104)는 건강 통합 네트워크(304)와의 통신을 용이하게 하기 위해 제공된다.

애플리케이션(302)은 API(104)에 호출을 하기 위해 SDK(602)를 활용할 수 있다. SDK(602)는 API(104)에 의해 포함되는 기능 중의 최소한 일부를 제공하기 위해 구현된다. 예를 들어, 애플리케이션은 건강 통합 네트워크(304) 내의 데이터를 검색하고, 저장하며, 변경하기 위해 단지 SDK(602)와 통신하면 된다. 애플리케이션(302)은 SDK(602)를 초기화할 수 있고, 이때 SDK(602)를 이용할 수 있다. 통상적으로, 일단 초기화되면, 애플리케이션(302)은 아래의 유사 부호(pseudo-code)로 표현된 바와 같이 도트 표기법 형태를 통해 SDK(602) 상에 함수 호출을 할 수 있다.

상기 유사 부호는 본 주제의 실시예를 SDK와 함께 사용하는 한 예일 뿐이고, 주제는 이에 제한되지 않는다는 것을 알 수 있을 것이다. 애플리케이션(302)이 record.GetThingsByType...과 같이 SDK(602)에 호출을 할 때, SDK(602)는 (건강 통합 네트워크 컴포넌트가 원격 저장되는 경우에) 인터넷(502)을 통해 데이터를 검색하거나, 저장하거나, 변경하기 위해 API(104)에 후속 호출을 하도록 구현된다. SDK(602)는 이 상호작용이 애플리케이션(302)에 끊어짐 없이 나타나게 한다. API(104)에 적절한 요청을 하면, API(104) 및/또는 가능한 소프트웨어 계층은 건강 통합 네트워크(304)로부터 관련 데이터를 요청한다. 요청은 상기 설명된 바와 같 이 하나 이상의 본질적으로 다르게 저장되거나 로컬 저장된 데이터베이스에 대한 하나 이상의 요청을 포함할 수 있다. 일단 관련 정보가 수집되면, API(104) 및/또는 가능한 소프트웨어 계층은 데이터가 인터넷(502)을 통해 다시 SDK(602)에 제출하기 전에 데이터에 변환, 스타일 및/또는 스키마를 적용할 수 있다.

도 5 및 도 6에서, 건강 통합 네트워크(304) 및/또는 API(104)의 액세스는 인터넷 통신에 제한되지 않고, 오히려 컴포넌트들이 동일한 근거리망(LAN)에 위치하는 경우에, LAN 통신이 이용될 수 있을 뿐만 아니라 WAN, WLAN 등도 이용될 수 있다는 것을 알 수 있을 것이다. 2개의 시스템 사이에서 데이터를 통신하는 임의의 모드가 사용될 수 있다. 더구나, 인터넷이나 그외 다른 것을 이용한 임의 종류의 데이터 통신/사양이 또한 사용될 수 있다. 게다가, API(104)는 (상기 샘플 XML로 나타낸 바와 같이) 최소한 하나의 상태 코드와 함께 애플리케이션(302)에서 이루어진 호출로부터 반환할 것이고; 이 코드는 다음의 상태 코드 목록과 같은 어떤 것일 수 있다.

코드	설명	이유
0	OK	성공
1	FAILED	일반적인 실패, 불분명한 원인
2	BAD HTTP	HTTP 프로토콜 문제
3	INVALID_XML	요청 XML이 구문 분석되지 않거나 부적합함
4	BAD_SIG	요청에 관한 서명 검증 실패
5	BAD_METHOD	요청된 메서드가 존재하지 않음
6	INVALID_APP	지정된 애플리케이션이 존재하지 않거나, 비활성이거나, 호출하는 IP 어드레스가 무효임
7	TOKEN_EXPIRED	인증 토큰이 만료되었음
8	INVALID_TOKEN	인증 토큰이 변형되거나 그렇지 않으면 파괴됨
9	INVALID_PERSON	사람이 존재하지 않거나 활동하지 않음
10	INVALID_RECORD	지정된 ID를 갖는 레코드가 존재하지 않음
11	ACCESS_DENIED	사람 또는 애플리케이션이 동작을 실행하기에 충분한 권리를 갖지 않음

12	NYI	아직 구현되지 않음
13	INVALID_THING	지정된 ID를 갖는 싱(thing)이 존재하지 않음
14	CANT_CONVERT_UNITS	싱의 값에 대해 지정된 단위가 이 유형의 존재하는 싱들의 단위 유형으로 변환될 수 없음
15	INVALID_FILTER	GetThings에 지정된 필터가 누락되거나 무효임
16	INVALID_FORMAT	GetThings에 지정된 포맷이 누락되거나 무효임
17	APPACCEPT_MISSING	애플리케이션은 사용자가 애플리케이션 동의를 받도록 요구함
18	INVALID_APPAUTH	애플리케이션이 이 사람에 의해 사용되도록 인가되지 않음
19	INVALID_THING_TYPE	지정된 싱 유형이 존재하지 않음
20	THING_TYPE_IMMUTABLE	싱은 변경 불가능하기 때문에 갱신될 수 없음
21	THING_TYPE_UNCREATABLE	이러한 유형의 싱들은 시스템에 의해서만 작성될 수 있음
22	DUPLICATE_CREDENTIAL_FOUND	지정된 로그온 이름이 이미 존재함
23	INVALID_RECORD_NAME	무효 레코드 이름이 지정되었음
24	DRUG_NOT_FOUND	지정된 약을 찾을 수 없음
25	INVALID_PERSON_STATE	무효 사람 상태가 지정되었음. 유효 사람 상태는 활동(Active), 중지(Suspended) 및 삭제(Deleted)를 포함함
26	INVALID_CODESET	지정된 코드 세트를 찾을 수 없음
27	INVALID_GROUP	지정된 그룹이 존재하지 않거나, 무효이거나, 비활성임
28	INVALID_VALIDATION_TOKEN	지정된 이메일 검증 토큰이 무효임
29	INVALID_ACCOUNT_NAME	사람 계정 이름이 빈 상태(null 또는 empty)로 될 수 없음
30	INVALID_CONTACT_EMAIL	이메일 이름이 빈 상태로 될 수 없음
31	INVALID_LOGIN_NAME	로그인 이름이 빈 상태로 될 수 없음
32	INVALID_PASSWORD	암호가 빈 상태로 될 수 없음
33	INVALID_OPENQUERY	지정된 ID를 갖는 오픈 쿼리를 찾을 수 없음
34	INVALID_TRANSFORM	변환이 로드될 수 없음
35	INVALID_RELATIONSHIP_TYPE	관계 유형이 무효임
36	INVALID_CREDENTIAL_TYPE	자격증명 유형이 뮤효임
37	INVALID_REQUEST_PARAMETERS	요구된 파라미터가 누락되었거나, 금지된 파라미터가 발견되었음
38	APP_AUTH_NOT_REQUIRED	애플리케이션이 애플리케이션 인가를 요구하지 않음
39	VOCABULARY_NOT_FOUND	요청된 어휘 항목(들)을 찾을 수 없음
40	DUPLICATE_AUTHORIZED_ RECORD-FOUND	이것은 애플리케이션의 명령으로 실행된 레코드 인가를 위해 인가 병합이 구현될 때 제거될 단기 상태 코드임. (사용권한, 관계 유형, 프라이머리 여부 등이 서로 다를 수 있지만) 사람이 이미 레코드 인가를 얻었음을 나타냄

도 7과 관련하여, API(700)는 상이한 데이터를 액세스하는 상이한 방법을 제공하는 다양한 루틴 그룹을 포함하는 것으로 도시된다. 레코드 데이터 루틴(702)은 애플리케이션(302)(도 4)이 건강 통합 네트워크(304)(도 4)에 저장된 레코드 데 이터를 요청하거나, 저장하거나, 변경하거나, 그렇지 않으면 액세스할 수 있게 하는 다수의 루틴을 포함한다. 이러한 데이터는 3개의 데이터베이스(404, 406 및 408)(도 4)로부터의 데이터를 포함할 수 있고, 데이터 자체뿐만 아니라 데이터를 설명하는 데이터, 관련된 이진 데이터(이를테면 그림, 엑스레이 등) 등을 포함할 수 있다. 레코드와 관련되고 유형에 의해 정의된 데이터는 여기에서, 예 및 루틴 이름에서, "싱(thing)"이라 칭해질 것이다. 레코드 데이터 루틴(702)은 건강 통합 네트워크에 저장된 건강 레코드로부터 데이터를 조회하기 위해 이렇게 루틴을 포함할 수 있다. 싱들은 구조적 데이터(XML), 이진 데이터(이미지) 등의 형태로 될 수 있고; 이들은 건강 통합 시스템 내의 단일 인스턴스 데이터를 나타낼 수 있고, 통상적으로 유형 및 메타데이터(값에 대한 유형, 측정 단위, 코멘트, 데이터의 발생 시점 등을 가질 수 있음)와 관련된다. 예를 들어, GetThings 루틴은 상기 예에서 나타낸 바와 같이 이 정보를 검색하기 위해 제공될 수 있다. 예를 들어 HTTP를 통해 XML을 사용하여 호출될 수 있는 이 루틴은 호출될 루틴을 지정하고, 데이터 쿼리용 필터를 지정하기 위한 "info" 섹션을 더 포함하는 XML 입력을 필요로 할 수 있고; 필터는 다음 중의 어느 것을 포함할 수 있다.

필터	정의
id	싱 ID의 임의의 번호가 지정될 수 있음. 이 조항은 다른 모든 조항과 OR되고, 필터 요소 밖에서 지정됨.
type-id	단일 싱에 대한 식별자.
eff-date-min	지정된 날짜보다 새로운 유효 날짜를 갖는 싱. 날짜는 UTC 시간으로 되어 있음.

eff-date-max	지정된 날짜보다 오래된 유효 날짜를 갖는 싱. 날짜는 UTC 시간으로 되어 있음.
created-app-id	싱을 작성한 애플리케이션의 ID. 이것은 Guid임.
created-person-id	싱을 작성한 사람의 ID. 이것은 Guid임.
updated-app-id	싱을 마지막으로 갱신한 애플리케이션의 ID. 이것은 Guid임.
updated-person-id	싱을 마지막으로 갱신한 사람의 ID. 이것은 Guid임.
created-date-min	지정된 날짜보다 새로운 작성 날짜를 갖는 싱. 날짜는 UTC 시간으로 되어 있음.
created-date-max	지정된 날짜보다 오래된 작성 날짜를 갖는 싱. 날짜는 UTC 시간으로 되어 있음.
updated-date-min	지정된 날짜보다 새로운 마지막 갱신 날짜를 갖는 싱. 날짜는 UTC 시간으로 되어 있음.
updated-date-max	지정된 날짜보다 오래된 마지막 갱신 날짜를 갖는 싱. 날짜는 UTC 시간으로 되어 있음.
xpath	싱 유형이 구조적 데이터(XML)로 표시되면, XPATH 쿼리는 데이터에 대해 실행되도록 지정될 수 있음. 쿼리는 존재에 대해서만 확인할 수 있음. 쿼리가 그 싱에 대해 참 결과를 생성하면 그것이 반환됨. 이 조항은 이진 사항 유형에 대해 일치하지 않음.
set-id	사용자 정의 집합 내의 모든 사항을 얻음.

게다가, "info" 섹션은 적용될 임의의 변환, 스타일 또는 스키마뿐만 아니라 지정된 필터에 일치하는 싱에 대해 어떤 데이터가 반환될 것인지 더욱 판정하기 위해 하나 이상의 포맷 섹션을 지정할 수 있다. 요청이 API에 보내지고, 소프트웨어 계층이 요청을 처리하고 데이터를 수집할 때, 응답은 다시 요청 엔티티에 보내진다. 응답은 일치하는 싱 결과, 상태 코드 등이 그룹화된, 위에서 나타낸 바와 같은 XML 응답일 수 있다. 응답은 응답의 레이아웃을 정의할 수 있는 XML 스키마에 따르게 되고, 그 XML 스키마와 함께 보내질 수 있으며, 특히 GetThings 루틴 응답은 싱을 위해 정의된 스키마에 따를 수 있는데, 다수의 섹션을 가질 수 있다. API는 요청에서 지정된 섹션을 수집하고; 섹션은 레코드 및 멤버 시스템 집합(싱이 속할 수 있는 하이 레벨 그룹)의 유효 날짜를 정의할 수 있는 핵심 섹션, 장래의 쿼리를 위해 레코드의 작성 및 갱신 정보를 정의할 수 있는 감사 섹션, 싱의 데이터를 나타내는 XML을 포함하는 XML 섹션(유형이 스키마를 정의하면, 데이터는 그 스 키마에 따라야 함), (이미지/엑스레이와 같은) 이진 데이터를 위한 BLOB 섹션, 감사를 위한 설명을 또한 포함할 수 있는 하나 이상의 주석을 정의할 수 있는 주석 섹션, 데이터가 속하는 하나 이상의 사용자 정의 집합을 정의하는 집합 섹션, 및 싱에 대한 상이한 승인 권한의 개요를 나타낸 권한 섹션을 포함한다. 이와 유사하게, 레코드 데이터 루틴(702)은 새로운 싱을 작성하고 및/또는 기존의 싱을 갱신하는 PutThings 루틴을 제공할 수 있다. 요청은 위에서 나타낸 바와 같은 XML 형태로 될 수 있고, 기록하기 위한 싱은 상기 싱 스키마에 따르도록 요구될 수 있다. 이 루틴은 결과 코드, 및 작성된/갱신된 싱의 ID를 반환할 수 있다. 게다가, RemoveThings 루틴은 요청이 GetThings 요청과 유사한 요소를 포함할 수 있는 경우에 싱을 삭제하기 위해 제공될 수 있고; 하지만 지정된 싱은 삭제되고, 반환되지 않는다. 더구나, GetAuthorizedRecords 루틴은 요청 엔티티가 권한을 갖는 공지된 레코드 ID를 조회하기 위해 제공될 수 있다(예를 들어, 요청 엔티티는 데이터가 속해 있는 사용자가 아님). 이 루틴은 스키마에 따라 및/또는 스키마와 함께 레코드를 반환할 수 있다.

API(700)는 또한 건강 통합 네트워크 내의 사용자 및 그룹을 관리하기 위한 계정 루틴 집합(704)을 제공할 수 있다. 예를 들어, QueryPersons 루틴이 제공될 수 있는데, 이 루틴은 요청하는 애플리케이션이, 지정된 필터 기준에 일치하는 사용자들에 대한 감소된 계정 정보 집합을 수집할 수 있게 한다. 이것을 위해, 요청은 요청 스키마에 따르도록 요구될 수 있다. 사용 가능한 필터는 찾는 사람의 이름, ID, 이메일 주소 등을 포함할 수 있고, 이들 요소가 임의의 지정된 인물을 포 함하는지 확인하여 긍정의 결과를 반환할 수 있으며; 결과는 스키마(XML 또는 기타)에 따르도록 요구될 수 있다. 더욱이, GetPersonInfo 루틴은 이름, 이메일 주소, 이메일 주소의 유효성 검사 상태, 애플리케이션 설정, 인가된 레코드 등을 포함하는 요청하는 사용자에 대한 계정 정보를 요청하기 위해 제공될 수 있다. 게다가, 유사한 그룹 루틴은 사용자가 논리 그룹에 속할 수 있게 하기 위해 제공될 수 있다. 그룹은 시스템의 사용자와 유사하게 관리될 수 있다. 그러므로, GetGroups 루틴과 같은 루틴은 예를 들어, 멤버 ID를 포함하는 그룹에 대한 정보를 검색하기 위해 제공될 수 있다. 요청 및 응답은 데이터를 해석하기 위해 XML 스키마에 따르도록 요구될 수 있다.

게다가, API(700)는 API(700) 및 건강 통합 네트워크를 사용하여 애플리케이션의 등록 및 위치를 허용하는 애플리케이션 루틴(706)을 제공할 수 있다. 예를 들어, GetApplication 루틴은 건강 통합 네트워크에 등록된 하나 이상의 애플리케이션에 관한 정보를 수집하기 위해 제공될 수 있고; 지정된 파라미터는 공지된 경우에 애플리케이션의 이름 및/또는 ID를 포함할 수 있다. 루틴은 위치를 찾아낸 하나 이상의 애플리케이션(이름 및 ID)뿐만 아니라, 애플리케이션이 인가 및/또는 승인을 요구하는 지의 여부 등을 반환할 수 있다. 더구나, AddApplication 루틴은 또한 애플리케이션을 건강 통합 네트워크에 등록하기 위해 제공될 수 있다. 요청은 애플리케이션의 ID(인증서를 사용하여 작성됨), 애플리케이션의 이름, 모든 요청을 검증하기 위해 사용된 공개 암호화 키, 레코드 레벨 인가, 루틴 레벨 인가, (XML 형태 또는 기타 형태로 된) 애플리케이션 설정, 애플리케이션을 사용하기 위 해 인가가 요구되는 지의 여부 및 애플리케이션을 사용하기 위해 승인이 요구되는 지의 여부에 대응하는 파라미터를 갖는 XML로 보내질 수 있다. 승인은 최종 사용자 사용권 계약(end-user license agreement: EULA)을 수락하는 것과 같은 단계를 포함할 수 있다. 루틴은 예를 들어, 애플리케이션의 ID 및 상태 코드를 반환할 수 있다.

더욱이, API(700)는 예를 들어, 주어진 싱 및/또는 레코드를 위한 보안을 관리하는 보안 루틴(708)을 포함할 수 있다. 이들 루틴은 주어진 레코드에 대한 인가된 사용자와 관련된 권한을 얻기 위한 GetPermissions 루틴을 포함할 수 있는데, 이 권한은 권한 정보가 요청되고 있는 사용자 ID 및 레코드 ID를 필요로 할 수 있다. 그 다음, 루틴은 사용자 또는 그룹에 관한 레코드 ID와 관련된 규칙 집합, 레코드에 대해 존재할 수 있는 권한, 권한이 적용되는 레코드 내의 싱, 및 권한이 적용될 수 없는 임의의 예외된 싱을 반환할 수 있다. 이와 유사하게, GetAuthorizations 루틴은 소정의 싱으로의 액세스를 갖는 사용자 또는 그룹의 ID를 얻기 위해 제공될 수 있다. 이것을 위해, 싱 ID는 입력으로서 권한 사양과 함께 제공되고, 루틴은 요청된 싱에 대한 액세스 레벨을 갖는 사용자 및/또는 그룹의 목록을 반환한다. 게다가, AddPermissions 및 RemovePermissions 루틴은 새로운 권한을 설정하고, 주어진 레코드에 대한 권한을 삭제하기 위해 제공될 수 있다. 또한, 보안 루틴(708)은 가변적인 권한을 갖는 그룹의 일부이기도 한 사용자에 대한 레코드의 권한 정보를 수집하기 위한 GetEffectivePermissions 루틴을 포함할 수 있다. 이 루틴은 사용자가 그룹 회원 자격에 기인하든 사용자 레벨의 부여된 권한에 기인하든 사용자에게 최상의 권한 정보를 제공하고자 시도할 수 있다. 더 많은 루틴이 또한 제공될 수 있으며, 예를 들어 (네트워크에 참여하는 시스템의 관리 및/또는 그외 다른 유형에 의해) 건강 통합 네트워크 내에서만 이용될 수 있는 루틴이 있을 수 있다. 더구나, 사용자에게 가입 기능을 제공하는 루틴은 예를 들어, 그외 다른 애플리케이션 및 회사를 위해 건강 통합 네트워크에 의해 제공된 서비스에 가입하기 위해 제공될 수 있다. 이들은 또한 시스템 사용을 위한 인센티브, 예를 들어 상이한 애플리케이션 제공자로부터의 프로모션, 서비스 사용을 위한 쿠폰 등을 제공하는 루틴을 포함할 수 있다.

설명된 바와 같이, 앞에서 설명된 예시적인 실시예는 XML 컨텍스트로 언급되지만, 이러한 루틴을 제공하는 다른 방식이 사용될 수 있는데, 예를 들어 SDK는 예를 들어, .NET을 사용하여 노출될 수 있고, HTTP를 통한 XML보다 오히려 도트 표기/파라미터 지정 포맷으로 호출을 해석할 수 있다. 파라미터는 XML 또는 다른 유형의 파라미터일 수 있지만, 송수신된 실질적인 데이터는 앞의 예에서와 같이 HTTP를 통한 XML이 사용되는 경우와 동일하다.

API(700)는 고객 서비스 담당자와 같이 건강 통합 네트워크를 유지 관리할 권한이 부여된 자들에 의해서만 액세스 가능한 관리 루틴 집합(710)을 더 포함할 수 있다. 이들 루틴은 건강 통합 네트워크 내의 임의의 싱 및/또는 레코드에 대해서만 변경할 수 있는 수퍼-사용자 레벨 권한을 부여할 수 있다. 이들 루틴은 위의 것들과 유사하게 구현되거나, 또는 잠재적 해킹 등으로부터 보호하기 위해 분리된 아키텍처 내에 구현될 수 있다.

API(700)는 또한 지능 루틴 집합(712)을 노출할 수 있다. 지능 루틴(712)은 작성되어, API를 사용하여 제3자 애플리케이션을 개발하는 것을 돕도록 특정 애플리케이션 또는 패키지에 맞춰질 수 있다. 예시적인 루틴은 애플리케이션이 이용할 예정인 데이터의 XML 스키마를 개발자가 작성할 수 있도록 도울 수 있다. 이것은 개발자가 새로운 가능한 데이터 값, 유형 및 컨테이너를 빨리 추가할 수 있게 할 수 있다. 이것은 또한 일괄 처리 방식으로 실행될 수 있고, 루틴은 이 정보를 애플리케이션과 관련시킬 수 있다. 이들 루틴은 또한 풍부한 데이터로의 단순한 액세스를 용이하게 하기 위해 API(700)로의 추가 기능으로서 제3자에 의해 작성될 수 있다. 예를 들어, 회사는 루틴 호출 이름 내의 상표명을 사용하여 사유 데이터를 액세스하는 공개 루틴을 노출시켜서, 추가로 금전적 인텐시브를 창출하여, 가치있는 데이터를 노출하는 개발을 촉진할 수 있다. API(700) 및 몇몇 루틴은 멀리 떨어져서 위치할 수 있지만, 그외 다른 것들은 액세스하는 애플리케이션의 근처나 그 위에 또는 그 안에 위치할 수 있다는 것을 알 수 있을 것이다. 실제로, 몇몇 루틴은 더욱 확장된 기능 및 더욱 사용하기 쉽고 더욱 효율적인 루틴을 고려하여 장치로 다운로드 가능하게 될 수 있다. 이들은 패키지로 되거나 개별적으로 다운로드 가능하게 되거나 심지어 자동 갱신으로 될 수 있고, 또한 소프트웨어 개발 키트의 일부일 수 있다.

지능 루틴(712)의 다른 예는 경고 시스템 기능일 수 있는데, 시스템 내의 소정의 이벤트 다음에 및/또는 어떤 임계치가 초과된 경우에, API는 정보에 관계된 적절한 당사자에게 통지할 수 있다. 예를 들어, 혈당 레벨 모니터가 여러 번의 낮 은 판독 수치 또는 한 번의 치명적인 낮은 판독 수치를 수신한 경우에, 판독 수치는 API(700)에 보내지면, 지능 루틴(712)을 트리거하여, 건강 통합 네트워크에 열거된 EMS 및/또는 비상 연락처에 통지할 수 있다. 우리는 오로지 이 기능에만 기초하여 만들어진 장치를 상상할 수 있는데; 아마도 모든 사람이 언제나 착용할 수 있는 자동 맥박 검출기는 낮은 맥박이나 맥박이 뛰지 않음(또는 빠른 맥박)을 검출하고 담당 기관 및/또는 비상 연락처에 통지할 것이다. 게다가, 장치는 GPS(global positioning system)를 기반으로 하거나 GPS와 관련될 수 있고, API(700)는 장치의 GPS 좌표를 얻어서 이 좌표를 경고 시스템/당사자에게 제출하는 능력을 가질 수 있다. 그러므로, 다른 지능 루틴(712)은 GPS 좌표를 주소로 해독할 수 있고, 또한 통지 시스템 또는 사용자의 현재 위치로부터의 방향을 제공할 수 있다. API(700)는 데이터 기능 이외에 이러한 서비스를 제공할 수 있지만, 이에 제한되는 것은 아니라는 것을 알 수 있을 것이다.

더구나, 통신 루틴(714)은 예를 들어, 건강 통합 네트워크 내에서 사용자, 장치, 애플리케이션 및 기타 엔티티에 자동으로 정보를 통신하는 것을 용이하게 하기 위해 제공될 수 있다. 이러한 통신은 네트워크의 내부 및/또는 외부에서 발생할 수 있다. 내부 통신은 이벤트, 경고, 갱신 등을 포함할 수 있고; 예를 들어 방사선 기사는 사용자의 1차 진료 의사의 애플리케이션으로 엑스레이를 보낼 수 있다. 그외 다른 예는 병력 알림과 같은 건강 경보, 처방전 또는 관련 정보의 변경, 예약 리마인더 등을 포함할 수 있다. 외부 통신은 예를 들어, 전자 메일(이메일), 팩스, 인스턴트 메시지 등을 포함할 수 있고; 앞의 예에서, 엑스레이는 1차 진료 의사에게 (예를 들어, 첨부를 통해) 이메일로 전달될 수 있다. 게다가, 동기화 루틴(716)은 설명된 주제에 따른 분산 건강 통합 네트워크들 사이의 통신을 용이하게 하기 위해 제공될 수 있다. 구체적으로, 2개 이상의 건강 통합 네트워크가 존재할 수 있고, 사용자는 이종의 건강 통합 네트워크에 저장된 정보를 원할 수 있으며; 따라서 동기화 루틴(716)은 이 목적을 달성하기 위해 시스템들 사이의 통신을 용이하게 할 수 있다. 다수의 원격 위치한 건강 통합 네트워크를 갖는 것은 세계의 여러 곳에서 효율적인 액세스를 제공하고, 동기화 루틴(716)은 보안 및/또는 개인 정보의 계층을 제공할 수 있다는 것을 알 수 있을 것이다. 게다가, 동기화 루틴(716)은 더 큰 데이터 접근성을 용이하게 하기 위해 다수의 건강 통합 네트워크 내에서 중복성을 제공할 수 있다.

상기 설명된 시스템, 아키텍처 등은 몇 개의 컴포넌트들 사이의 상호작용에 관해 설명되었다. 이러한 시스템 및 컴포넌트는 여기에서 지정된 이들 컴포넌트 또는 서브 컴포넌트, 지정된 컴포넌트 또는 서브 컴포넌트의 일부, 및/또는 추가 컴포넌트를 포함할 수 있다는 것을 알기 바란다. 서브 컴포넌트는 또한 부모 컴포넌트 내에 포함되기보다는 다른 컴포넌트에 통신으로 결합된 컴포넌트로서 구현될 수 있다. 또한, 하나 이상의 컴포넌트 및/또는 서브 컴포넌트는 집합 기능을 제공하기 위해 단일 컴포넌트 내로 결합될 수 있다. 시스템들, 컴포넌트들 및/또는 서브 컴포넌트들 사이의 통신은 푸시 및/또는 풀 모델에 따라 달성될 수 있다. 컴포넌트들은 또한 간단하게 하기 위해 여기에서 구체적으로 설명되지 않았지만 본 분야에 숙련된 기술자들에게 공지되어 있는 하나 이상의 다른 컴포넌트들과 상호작용 할 수 있다.

더욱이, 알게 되는 바와 같이, 개시된 시스템 및 방법의 여러 부분은 인공 지능, 기계 학습, 또는 지식 또는 규칙 기반의 컴포넌트, 서브 컴포넌트, 프로세스, 수단, 방법, 또는 메커니즘(예를 들어, SVM(support vector machines), 신경망, 전문가 시스템, 베이지안 믿음 네트워크, 퍼지 로직, 데이터 융합 엔진, 분류자...)을 포함하거나 이러한 것들로 이루어질 수 있다. 이러한 컴포넌트는 그 중에서 특히, 예를 들어 상황에 맞는 정보에 기초하여 동작을 추론함으로써, 시스템 및 방법의 부분들을 효율적이고 지능적일 뿐만 아니라 더욱 적응적으로 하기 위해, 이에 따라 실행된 소정의 메커니즘 또는 프로세스를 자동화할 수 있다. 예로서, 이러한 메커니즘은 유형화된 뷰의 발생 등과 관련하여 이용될 수 있는데, 이에 제한되는 것은 아니다.

앞에서 설명된 예시적인 시스템을 고려하여, 개시된 주제에 따라 구현될 수 있는 방법은 도 8-9의 순서도와 관련하여 더욱 잘 이해될 것이다. 설명을 간단하게 하기 위해, 방법은 일련의 블록으로 도시되고 설명되지만, 청구된 주제는 몇몇 블록이 여기에 도시되고 설명된 것과 다른 순서로 발생하고 및/또는 다른 블록과 동시에 발생하므로 블록의 순서에 의해 제한되지 않는다는 것을 이해하고 알 수 있을 것이다. 더구나, 도시된 모든 블록이 아래에 설명된 방법을 구현하기 위해 요구되는 것은 아니다.

도 8은 애플리케이션이 API를 통해 건강 통합 네트워크로부터 데이터를 요청하는 방법을 도시한 것이다. 요청은 요청된 데이터 또는 기타 데이터에 대한 임의 의 데이터를 포함하여 건강 통합 네트워크에 존재하는 임의의 데이터에 대한 것일 수 있다. 요청은 임의의 요청/응답 유형 아키텍처뿐만 아니라, HTTP를 통한 XML, SDK, 및/또는 이 둘 다, 또는 이들 아키텍처의 혼합을 포함하는 다수의 아키텍처로 지정될 수 있다. 요청은 요청/응답 유형 및/또는 예약 기반형으로 이루어질 수 있는데, 예약 기반형에서, 데이터 채널은 요청시에 개방 상태로 유지되고, 갱신은 자동으로 채널에 보내져서 요청 애플리케이션에 의해 픽업된다. 후자의 형태는 경고/경보, 자동 갱신, 및 앞에서 설명된 것과 같은 것에 유용할 수 있다. 예를 들어, 극도로 낮은 인슐린 레벨 수치는 인슐린 모니터가 이 정보를 건강 통합 네트워크에 보내게 할 수 있고(이것은 요청/응답임); 그 다음, 건강 통합 네트워크는 개방 채널을 통해 의원의 애플리케이션 및/또는 비상 연락처의 애플리케이션(이를테면, 페이지 및/또는 텍스트 메시지를 보낼 수 있는 애플리케이션)에 사용자의 인슐린 레벨이 낮다는 경고를 보낼 수 있어서, 이 정보를 요청할 필요성을 경감시킨다(이것은 예약 기반 시스템의 예임). 그러나, 이 특정 방법(800)은 요청/응답을 표시하지만, 예약 기반 방법이 또한 설명된 주제에 따라 이용될 수 있다는 것을 알 수 있을 것이다.

참조 번호(802)에서, 애플리케이션은 여기에서 설명된 건강 통합 네트워크의 API로부터 데이터 요청을 시작한다. 애플리케이션은 앞에서 설명된 바와 같이, 먼저 API를 통해 건강 통합 네트워크에 등록하도록 요구될 수 있는데, 이것은 다른 형태의 요청일 수 있다는 것을 알 수 있을 것이다. 더욱이, 요청은 건강 통합 네트워크 내의 데이터를 조회하는 것뿐만 아니라 데이터를 저장하는 것일 수 있다. 또한, 요청하는 애플리케이션은 API와 통신할 능력이 있는 다수의 장치, 애플리케이션 등일 수 있다. 예를 들어, 애플리케이션은 외부의 개인 체력 장치에 의해 수집된 데이터를 저장하고 검색하기 위해 건강 통합 네트워크 API와 접속하도록 적응된 외부의 개인 체력 장치(이를테면, 심박수 모니터 시계)로 통상적으로 동작할 수 있는 제3자 애플리케이션일 수 있다. 게다가, 개인 체력 장치에는 API 자체를 통해 건강 통합 네트워크에 통신하는 기술이 갖추어질 수 있다. 더구나, 요청이 데이터에 대한 것인 경우, 애플리케이션은 쿼리 유형 기능을 위한 필터 및 또한 검색하기 위한 데이터의 섹션을 지정할 수 있다. 예를 들어, 엑스레이 정보를 요청하는 경우, 애플리케이션은 단지 관리 정보를 원할 수 있고(실제로 단지 관리 정보를 수신하는 권리가 부여될 수 있으며); 따라서 요청은 이것을 지정하여, 건강 통합 네트워크로부터의 응답시에 (다른 관련 데이터에 비해 아마 큰 용량인) 엑스레이 이미지를 전송할 필요성을 경감시킬 수 있다.

요청을 한 후에, 애플리케이션은 API로부터 응답이 수신되기를 기다린다(단계(804)). 요청은 애플리케이션에 관해 동기화될 수 있는데, 이것은 애플리케이션이 요청 반환을 기다리는 동안에 실제로 다른 작업을 미룬다는 것을 의미한다. 그러나, 애플리케이션은 또한 비동기 상황에서 요청을 할 수 있으므로, 애플리케이션은 응답을 기다리면서 처리를 계속 할 수 있다. 통상적으로, 이 기능은 콜백 함수, 다수의 생성 스레드 등으로 구현될 수 있다. 게다가, 애플리케이션은 현재의 호출이 반환되기를 기다리면서 API에 다른 호출을 할 수 있다.

참조 번호(806)에서, API 응답이 애플리케이션에 의해 수신된다. 데이터는 예를 들어, 지정된 상태 코드를 갖는 XML 형태로 도달할 수 있다. XML 데이터는 또한 데이터 요청으로부터 결과적으로 생긴 데이터를 포함할 수 있다. 데이터는 변환, 스타일 및/또는 스키마 정보와 함께 일반 형태로 되어 있을 수 있고, 또는 이들이 이미 적용된 문자열로 되어 있을 수 있다. 애플리케이션은 수신 정보를 렌더링하고 및/또는 그 밖에 처리하는 방법을 알고 있으므로, 애플리케이션의 사용자는 정보를 최적하게 볼 수 있고, 참조 번호(808)에서 XML 스키마에 따라 그렇게 할 수 있다.

도 9는 API를 통해 건강 통합 네트워크로부터 데이터를 요청하는 것을 용이하게 하는 방법(900)을 도시한 것이다. 데이터는 네트워크 및/또는 데이터베이스에 걸쳐 분산될 수 있는 건강 통합 네트워크 내에 존재하는 것으로 위에서 설명된 임의의 데이터일 수 있다. 요청은 데이터 단독, 데이터 및 유형 정보, 데이터 및 변형, 스타일 및/또는 스키마 정보 등에 대한 것일 수 있다. 더욱이, 앞에서 설명된 바와 같이, 요청은 임의의 요청/응답 플랫폼뿐만 아니라, HTTP를 통한 XML, SDK 및/또는 이들의 조합을 이용함으로써 이루어질 수 있다.

참조 번호(902)에서, 요청은 데이터에 대해 애플리케이션으로부터 수신된다. 요청은 API, 소프트웨어 계층 및/또는 그 조합에 에 의해 수신될 수 있다. 설명된 바와 같이, 요청은 건강 통합 네트워크에서 사용 가능한 임의의 레코드에 대한 것일 수 있다(그리고 에러가 생길 가능성이 있긴 하지만, 사용 불가능한 레코드에 대한 것일 수 있다). API 및 소프트웨어 계층은 캐싱, 감사 등과 같은, 요청에 따른 추가 처리를 실행할 수 있다. 게다가, 수신하는 엔티티는 건강 통합 네트워크로부 터 데이터를 계속 요청하기 전에 몇몇 인증/인가 루틴을 실행할 수 있다. 대안적으로 또는 추가로, 인증 및/또는 인가는 건강 통합 네트워크에 의해 실행될 수 있다.

참조 번호(904)에서, 관련 정보가 건강 통합 네트워크로부터 검색된다. 이 정보는 요청된 데이터일 수 있고, 및/또는 요청된 데이터에 관한 인가, 체계화, 변환, 양식화 또는 기타 동작 실행을 돕기 위한 추가 데이터일 수 있다. 데이터는 하나의 또는 다수의 로컬 또는 원격 저장된 데이터베이스로부터 얻어질 수 있다. 게다가, 데이터베이스들은 데이터로의 끊어짐 없는 액세스를 제공하기 위해 서로 협력하여 동작할 수 있다. 예를 들어, 마스터 데이터베이스가 제공될 수 있는데, 마스터 데이터베이스는 찾는 정보가 존재하는 곳에 관한 표시기가 있고, 정보를 검색할 수 있다. 그러므로, 한 실시예에서, 정보는 단지 마스터 데이터베이스 또는 그 인터페이스로부터 요청될 필요가 있고, 마스터 데이터베이스는 정보를 찾는 장소를 알고 있고, 그것을 요청기에 반환할 수 있다. 대안적으로, API 및/또는 소프트웨어 계층은 이 저장 정보를 알고 있거나 획득할 수 있다.

요청된 데이터가 적절한 정보와 함께 오면, 참조 번호(906)에서 변환, 스타일 및/또는 스키마가 데이터에 적용된다. 예를 들어, 변환은 킬로그램에서 파운드로의 변환과 같은 미터법에서 US 단위로의 변환 등을 포함할 수 있다. 변환은 또한, 예를 들어 문자열 또는 2개의 정수를 수축기 혈압과 확장기 혈압의 혈압 데이터 구조로 변환하는 것을 포함할 수 있다. 이와 유사하게, 스타일은, 예를 들어 73(인치를 나타내는 정수)으로 저장된 키를 6'1" 형태로 되게 하는 것과 같이 참조 기호 또는 문자를 추가하는 것을 포함할 수 있다. 게다가, 스키마에는 더욱 복잡한 데이터 구조에 대해 데이터 레이아웃을 설명하기 위한 데이터가 보충된다. API 및/또는 소프트웨어 계층은 소정의 관련 데이터를 추출하기 위해 이 스키마를 사용할 수 있고, 또는 데이터의 표현을 만들기 위해 이 스키마를 적용할 수 있다. 예를 들어, 앞의 방법에서와 같이, 애플리케이션이 단지 데이터의 일부, 이를테면 이미지 자체가 아니고 엑스레이에 대한 관리 정보를 원하는 경우에, 스키마는 단지 요청된 관리 데이터를 다시 보내기 위해 적용될 수 있다.

그 다음, 참조 번호(908)에서, 데이터는 요청 애플리케이션으로 반환된다. 반환된 데이터는 데이터 단독, 상기 설명된 변환, 스타일 및/또는 스키마가 적용된 데이터, 또는 이 둘 다일 수 있다. 그러므로, 애플리케이션은 변환, 스타일 및/또는 스키마의 전부나, 그 조합, 또는 그 각각의 일부를 이용함으로써 요청 엔티티의 요구에 부합하도록 데이터를 형성할 수 있다. 데이터에 대한 외부의 변환, 스타일 및/또는 스키마 정보는 또한 따로 요청될 수 있고, 및/또는 나중 사용을 위해 애플리케이션의 로컬 캐시 내에 저장될 수 있다.

여기에서 사용된 바와 같이, "컴포넌트", "시스템" 등의 용어는 컴퓨터 관련 엔티티, 즉 하드웨어, 하드웨어와 소프트웨어의 조합, 소프트웨어 또는 실행중인 소프트웨어를 나타내기 위한 것이다. 예를 들어, 컴포넌트는 프로세서상에서 실행되는 프로세스, 프로세서, 개체, 인스턴스, 실행파일, 실행 스레드, 프로그램 및/또는 컴퓨터일 수 있는데, 이것에 제한되는 것은 아니다. 실례로서, 컴퓨터상에서 실행되는 애플리케이션, 및 컴퓨터는 컴포넌트일 수 있다. 하나 이상의 컴포넌트 는 프로세스 및/또는 실행 스레드 내에 존재할 수 있고, 하나의 컴포넌트는 하나의 컴퓨터상에 국한될 수 있고 및/또는 2개 이상의 컴퓨터들 사이에서 분산될 수 있다.

"예시적"이라는 단어는 예제, 보기 또는 실례로서 쓰인다는 것을 나타내기 위해 여기에서 사용된다. "예시적"으로 여기에서 설명된 임의의 양상 또는 디자인은 반드시 그외 다른 양상 또는 디자인보다 양호하거나 유리한 것으로 해석될 필요는 없다. 더욱이, 예는 단지 명확하게 하고 이해를 돕기 위해 제공된 것이고, 어떤 방식으로든 본 발명 또는 그 관련 부분을 제한하고자 하는 것이 아니다. 무수한 추가적이거나 대안적인 예가 제공될 수 있지만, 간결하게 하기 위해 생략되었다는 것을 알 수 있을 것이다.

더욱이, 본 발명의 전부 또는 일부는 개시된 발명을 구현하도록 컴퓨터를 제어하기 위한 소프트웨어, 펌웨어, 하드웨어 또는 이들의 임의의 조합을 생성하기 위해 표준 프로그래밍 및/또는 엔지니어링 기술을 사용하는 방법, 장치 또는 제조품(article of manufacture)으로서 구현될 수 있다. 여기에서 사용된 "제조품"이라는 용어는 임의의 컴퓨터 판독가능 장치 또는 매체로부터 액세스 가능한 컴퓨터 프로그램을 포함하고자 하는 것이다. 예를 들어, 컴퓨터 판독가능 매체는 자기 저장 장치(예를 들어, 하드 디스크, 플로피 디스크, 자기 스트립...), 광 디스크(예를 들어, CD(compact disk), DVD(digital versatile disk)...), 스마트 카드, 및 플래시 메모리 장치(예를 들어, 카드, 스틱, 키 드라이브...)를 포함할 수 있지만, 이에 제한되는 것은 아니다. 부수적으로, 반송파는 전자 메일을 송수신할 때 또는 인터넷 또는 LAN(local area network)과 같은 네트워크를 액세스할 때 사용된 것들과 같은 컴퓨터 판독가능 전자 데이터를 전달하기 위해 이용될 수 있다는 것을 알 수 있을 것이다. 물론, 본 분야에 숙련된 기술자들은 청구된 주제의 범위 또는 정신을 벗어나지 않고서 이 구성에 많은 변경이 행해질 수 있다는 것을 인식할 것이다.

개시된 주제의 다양한 실시양상에 대한 설명을 제공하기 위해, 다음 설명뿐만 아니라 도 10 및 11은 개시된 주제의 다양한 실시양상이 구현될 수 있는 적합한 환경의 간단한 일반 설명을 제공하고자 하는 것이다. 주제가 하나 이상의 컴퓨터상에서 실행되는 컴퓨터 프로그램의 컴퓨터 실행가능 명령어와 일반적으로 관련하여 위에서 설명되었지만, 본 분야에 숙련된 기술자들은 본 발명이 또한 기타 프로그램 모듈과 조합하여 구현될 수 있다는 것을 인식할 것이다. 일반적으로, 프로그램 모듈은 특정 태스크를 수행하고 및/또는 특정 추상 데이터 유형을 구현하는 루틴, 프로그램, 컴포넌트, 데이터 구조 등을 포함한다. 게다가, 본 분야에 숙련된 기술자들은 퍼스널 컴퓨터, 핸드헬드 컴퓨팅 장치(예를 들어, 개인 휴대 정보 단말기(PDA), 전화기, 시계...), 마이크로프로세서 기반 또는 프로그램가능 소비자용 또는 산업용 전자제품 등등뿐만 아니라 단일 프로세서, 멀티프로세서 또는 멀티-코어 프로세서 컴퓨터 시스템, 미니 컴퓨팅 장치, 메인프레임 컴퓨터를 포함하는 기타 컴퓨터 시스템 구성으로 본 시스템/방법이 실시될 수 있다는 것을 이해할 것이다. 도시된 실시양상은 또한 통신 네트워크를 통해 연결되는 원격 처리 장치에 의해 태스크가 수행되는 분산 컴퓨팅 환경에서 실시될 수 있다. 그러나, 청구된 주 제의 모든 실시양상이 독립형 컴퓨터상에서 실시될 수 있는 것이 아닌 경우에 그 일부가 실시될 수 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈은 로컬 및 원격 메모리 저장 장치 둘 다에 위치할 수 있다.

도 10과 관련하여, 여기에 개시된 다양한 실시양상을 구현하는 예시적인 환경(1010)은 컴퓨터(1012)(예를 들어, 데스크톱, 랩톱, 서버, 핸드헬드, 프로그램가능 소비자용 또는 산업용 전자제품...)를 포함한다. 컴퓨터(1012)는 처리 장치(1014), 시스템 메모리(1016) 및 시스템 버스(1018)를 포함한다. 시스템 버스(1018)는 시스템 메모리(1016)를 포함하는(제한되지는 않음) 시스템 컴포넌트들을 처리 장치(1014)에 연결한다. 처리 장치(1014)는 각종 시판중인 마이크로프로세서들 중의 어느 것이라도 될 수 있다. 듀얼 마이크로프로세서, 멀티-코어 및 기타 멀티프로세서 아키텍처가 처리 장치(1014)로서 이용될 수 있다는 것을 알 수 있을 것이다.

시스템 메모리(1016)는 휘발성 및 비휘발성 메모리를 포함한다. 시동 중과 같은 때에, 컴퓨터(1012) 내의 구성요소들 사이의 정보를 전송하는 기본 루틴을 포함하는 기본 입/출력 시스템(BIOS)은 비휘발성 메모리 내에 저장되어 있다. 예시적으로, 비휘발성 메모리는 판독 전용 메모리(ROM)를 포함할 수 있지만 이에 제한되는 것은 아니다. 휘발성 메모리는 처리를 용이하게 하기 위해 외부 캐시 메모리로서 동작할 수 있는 랜덤 액세스 메모리(RAM)를 포함한다.

컴퓨터(1012)는 또한 이동식/비이동식, 휘발성/비휘발성 컴퓨터 저장 매체를 포함한다. 도 10은, 예를 들어 대용량 저장 장치(1024)를 도시하고 있다. 대용량 저장 장치(1024)는 자기 또는 광 디스크 드라이브, 플로피 디스크 드라이브, 플래시 메모리 또는 메모리 스틱과 같은 장치를 포함하는데, 이에 제한되는 것은 아니다. 또한, 대용량 저장 장치(1024)는 기타 저장 매체와 결합하여 또는 분리하여 저장 매체를 포함할 수 있다.

도 10은 적합한 운영 환경(1010)에서 설명된 기본 컴퓨터 자원들과 사용자들 및/또는 기타 컴퓨터들 사이의 중간자로서 동작하는 소프트웨어 애플리케이션(들)(1028)을 제공한다. 그러한 소프트웨어 애플리케이션(들)(1028)은 시스템과 애플리케이션 소프트웨어 중의 하나 또는 둘 다를 포함한다. 시스템 소프트웨어는 대용량 저장 장치(1024) 상에 저장될 수 있는 운영 체제를 포함하는데, 이 운영 체제는 컴퓨터 시스템(1012)의 자원을 제어하고 할당하는 동작을 한다. 애플리케이션 소프트웨어는 시스템 메모리(1016)와 대용량 저장 장치(1024) 중의 하나 또는 둘 다에 저장된 프로그램 모듈 및 데이터를 통해 시스템 소프트웨어에 의한 자원 관리를 이용한다.

컴퓨터(1012)는 또한 버스(108)에 통신으로 연결되어 컴퓨터(1012)와의 상호작용을 용이하게 하는 하나 이상의 인터페이스 컴포넌트(1026)를 포함한다. 예로서, 인터페이스 컴포넌트(1026)는 포트(예를 들어, 직렬, 병렬, PCMCIA, USB, FireWire...) 또는 인터페이스 카드(예를 들어, 사운드, 비디오, 네트워크...) 등일 수 있다. 인터페이스 컴포넌트(1026)는 (유선 또는 무선으로) 입력을 수신하고 출력을 제공할 수 있다. 예를 들어, 입력은 포인팅 장치, 이를테면 마우스, 트랙볼, 스타일러스, 터치 패드, 키보드, 마이크, 조이스틱, 게임 패드, 위성 안테나, 스캐너, 카메라, 기타 컴퓨터 등을 포함하는(이에 제한되지는 않음) 장치로부터 수신될 수 있다. 출력 장치는 그 중에서 특히, 디스플레이(예를 들어, CRT, LCD, 플라즈마...), 스피커, 프린터 및 기타 컴퓨터를 포함할 수 있다.

도 11은 본 발명이 상호작용할 수 있는 샘플-컴퓨팅 환경(1100)의 개략적인 블록도이다. 시스템(1100)은 하나 이상의 클라이언트(들)(1110)를 포함한다. 클라이언트(들)(1110)는 하드웨어 및/또는 소프트웨어(예를 들어, 스레드, 프로세스, 컴퓨팅 장치)일 수 있다. 시스템(1100)은 또한 하나 이상의 서버(들)(1130)를 포함한다. 그러므로, 시스템(1100)은 기타 모델 중에서 특히, 2 계층(tier) 클라이언트 서버 모델 또는 다중 계층 모델(예를 들어, 클라이언트, 중간 계층 서버, 데이터 서버)에 대응할 수 있다. 서버(들)(1130)는 또한 하드웨어 및/또는 소프트웨어(예를 들어, 스레드, 프로세스, 컴퓨팅 장치)일 수 있다. 서버(1130)는 예를 들어, 본 발명의 실시양상을 이용함으로써 변환을 실행하기 위한 스레드를 수용할 수 있다. 클라이언트(1110)와 서버(1130) 사이의 한 가지 가능한 통신은 2개 이상의 컴퓨터 프로세스 사이에서 전송된 데이터 패킷의 형태로 될 수 있다.

시스템(1100)은 클라이언트(들)(1110)와 서버(들)(1130) 사이의 통신을 용이하게 하기 위해 이용될 수 있는 통신 프레임워크(1150)를 포함한다. 여기에서, 클라이언트(들)(1110)는 프로그램 애플리케이션 컴포넌트에 대응할 수 있고, 서버(들)(1130)는 앞에서 설명된 바와 같이, 인터페이스 및 선택적으로 저장 시스템의 기능을 제공할 수 있다. 클라이언트(들)(1110)는 클라이언트(들)(1110)에 국한된 정보를 저장하기 위해 이용될 수 있는 하나 이상의 클라이언트 데이터 저장소 (들)(1160)에 동작가능하게 접속된다. 이와 유사하게, 서버(들)(1130)는 서버(1130)에 국한된 정보를 저장하기 위해 이용될 수 있는 하나 이상의 서버 데이터 저장소(들)(1140)에 동작가능하게 접속된다.

예로서, 프로그램 애플리케이션 컴포넌트는 클라이언트(1110)를 통해 하나 이상의 서버(1130)(및 예를 들어, 서버상에 저장되거나 서버로부터 액세스 가능한 API)로부터 개인 건강 정보를 요청할 수 있다. 서버(들)(1130)는 데이터 저장소(1140) 또는 다수의 데이터 저장소로부터 원하는 데이터를 얻을 수 있고, 예를 들어, 변환, 스타일 및/또는 스키마 정보를 적용할 수 있다. 그 후, 그외 다른 프로그램 애플리케이션 컴포넌트는 서버(들)(1130)로부터의 동일하거나 상이한 데이터로의 액세스를 요청할 수 있다.

상기 설명된 것은 청구된 주제의 실시양상의 예를 포함한다. 물론, 청구된 주제를 설명하기 위해 컴포넌트 또는 방법의 가능한 모든 조합을 설명할 수는 없지만, 본 분야에 숙련된 기술자는 개시된 주제의 더 많은 조합과 변경이 가능하다는 것을 인식할 것이다. 따라서, 개시된 주제는 첨부된 청구범위의 정신 및 범위 내에 속하는 그러한 모든 변경, 수정 및 변형을 포함하고자 하는 것이다. 더욱이, 용어 "includes", "has" 또는 "having", 또는 그 변형이 상세한 설명 또는 청구범위에서 사용되는 한도까지, 그러한 용어는 "comprising"이라는 용어가 청구범위에서 전이구(transitional word)로서 이용될 때 해석되는 바와 같이 "comprising"이라는 용어와 유사한 방식으로 포괄적인 의미로 사용하고자 하는 것이다.

Claims

애플리케이션 프로그램 인터페이스(API)(200)에 있어서,

다수의 이종 장치 또는 애플리케이션(302)으로부터 건강 관련 데이터에 대한 요청들을 수신하는 수신기 컴포넌트(202);

상기 요청들을 처리하고, 건강 통합 네트워크(304)로부터 상기 요청된 건강 관련 데이터의 서브세트를 수집하는 인터프리터(interpreter) 컴포넌트(204) - 상기 건강 통합 네트워크는 건강 관련 데이터를 각각 저장하는 다수의 이종 데이터 저장소(404, 406, 408)를 포함함-; 및

상기 장치들 또는 애플리케이션들(302)에 반환하기 위한 상기 수집된 건강 관련 데이터의 일부를 선택하기 위해 스키마를 이용하는 변환 컴포넌트(208)

를 포함하는 애플리케이션 프로그램 인터페이스.
제1항에 있어서, 상기 스키마의 최소한 일부는 상기 건강 관련 데이터에 대한 요청들 내에 지정되는 애플리케이션 프로그램 인터페이스.
제1항에 있어서, 상기 변환 컴포넌트는 상기 건강 관련 데이터의 선택된 부분의 데이터 유형에 대해 상기 건강 통합 네트워크로부터 스타일 정보를 검색하고, 상기 장치들 또는 애플리케이션들에 반환할 때 상기 건강 관련 데이터의 선택된 부분에 상기 스타일 정보를 적용하는 애플리케이션 프로그램 인터페이스.
제1항에 있어서, 데이터를 요청하는 애플리케이션이 상기 요청에서 지정된 데이터 액세스의 유형에 대해 충분한 자격증명을 갖는 지의 여부를 판정하는 인가(authorization) 컴포넌트를 더 포함하는 애플리케이션 프로그램 인터페이스.
제4항에 있어서, 상기 인가 컴포넌트는 상기 애플리케이션을 운영하는 사용자가 상기 요청에서 지정된 데이터 액세스의 유형에 대해 충분한 자격증명을 갖는 지의 여부를 판정하는 애플리케이션 프로그램 인터페이스.
제1항에 있어서, 이벤트 또는 임계치 초과 중의 최소한 하나의 발생시에 데이터를 접속된 애플리케이션에 보내는 갱신 컴포넌트를 더 포함하는 애플리케이션 프로그램 인터페이스.
제1항에 있어서, 상기 요청은 HTTP 접속을 통해 XML(Extensible Markup Language) 포맷으로 수신되는 애플리케이션 프로그램 인터페이스.
제7항에 있어서, 상기 XML 포맷으로 수신된 요청은 최소한 하나의 루틴 호출 및 상기 루틴 호출에 대한 최소한 하나의 파라미터를 지정하는 애플리케이션 프로그램 인터페이스.
제1항에 있어서, 상기 다수의 데이터 저장소 중의 최소한 하나는 고도로 분산되고, 상기 다수의 데이터 저장소 중의 최소한 하나는 상기 고도로 분산된 데이터 저장소 내에 레코드에 대한 위치 정보를 보유하는 애플리케이션 프로그램 인터페이스.
제1항에 있어서, 공통 루틴 집합을 결정하고, 애플리케이션에 의해 사용하도록 상기 공통 루틴 집합을 노출하는 루틴 패키징 컴포넌트를 더 포함하는 애플리케이션 프로그램 인터페이스.
개인 건강 관련 데이터와 상호작용하는 방법에 있어서,

제1 애플리케이션 또는 장치로부터 건강 관련 데이터 레코드의 일부에 대응하는 요청을 수신하는 단계;

상기 요청에 기초하여 건강 통합 네트워크로부터 데이터를 요청하는 단계; 및

상기 데이터의 선택된 부분들을 포함하는 결과를 준비하기 위해 상기 데이터에 스키마를 적용하는 단계

를 포함하는 개인 건강 관련 데이터와의 상호작용 방법.
제11항에 있어서, 상기 결과를 상기 제1 애플리케이션 또는 장치에 보내는 단계를 더 포함하는 개인 건강 관련 데이터와의 상호작용 방법.
제11항에 있어서, 상기 선택된 부분들은 건강 관련 데이터 레코드의 일부에 대한 요청에서 지정되는 개인 건강 관련 데이터와의 상호작용 방법.
제11항에 있어서, 상기 건강 관련 데이터 레코드의 일부에 대한 이질적인 요청을 제2 장치 또는 애플리케이션으로부터 수신하는 단계를 더 포함하고, 상기 제2 장치 또는 애플리케이션은 상기 제1 장치 또는 애플리케이션과 다른 아키텍처로 운영되는 개인 건강 관련 데이터와의 상호작용 방법.
제11항에 있어서, 상기 요청은 상기 건강 통합 네트워크 내에 상기 건강 관련 데이터의 일부를 저장하는 것인 개인 건강 관련 데이터와의 상호작용 방법.
제15항에 있어서, 최소한 부분적으로 상기 요청에 기초하여 제2 장치 또는 애플리케이션에 이벤트를 보내는 단계를 더 포함하는 개인 건강 관련 데이터와의 상호작용 방법.
제11항에 있어서, 상기 요청은 XML 문서 내에 포함되어 있는 개인 건강 관련 데이터와의 상호작용 방법.
제17항에 있어서, 상기 XML 문서는 요청된 루틴에 의해 요구된 최소한 하나 의 파라미터를 더 포함하는 개인 건강 관련 데이터와의 상호작용 방법.
제11항에 있어서, 상기 제1 장치 또는 애플리케이션은 개인 건강 장치인 개인 건강 관련 데이터와의 상호작용 방법.
건강 관련 데이터를 액세스하는 시스템에 있어서,

다수의 장치 및 애플리케이션(302)으로부터 개인 건강 관련 데이터에 대한 요청들을 수신하는 수단(202) 및 상기 요청들에 응답하는 수단(210);

상기 요청들에 관한 저장된 데이터의 서브세트를 얻는 수단(202); 및

상기 저장된 데이터의 일부 중의 요청된 선택 부분만을 반환하기 위해 상기 저장된 데이터의 서브세트에 최소한 하나의 스키마를 적용하는 수단(208)

을 포함하는 건강 관련 데이터 액세스 시스템.