짧은 답변: Subscription은 FHIR 서버에게 이러한 조건에 맞는 리소스가 변경될 때 이 엔드포인트로 알림을 보내라고 알려주는 역할을 합니다. FHIR R4에서는 조건이 검색 문자열(criteria: "Observation?patient=123&code=85354-9")이며, 서버는 일치하는 리소스를 REST hook, websocket, 이메일 또는 FHIR 메시지로 보냅니다. R4B 및 R5에서는 SubscriptionTopic을 중심으로 모델이 재구축되었습니다. 서버는 알림 가능한 이벤트들을 게시하고, 클라이언트는 필터를 사용하여 토픽을 구독하며, 알림은 항상 SubscriptionStatus 리소스로 시작하는 subscription-notification 타입의 Bundle로 도착합니다. Subscriptions R5 Backport 구현 가이드를 통해 R4 서버에서도 새로운 모델을 제공할 수 있습니다.
R4: 기준 기반 구독
FHIR R4에서는 구독이 기준 기반입니다. 클라이언트는 Observation?code=…&patient=…와 같은 검색 문자열을 기준으로 하고 채널이 rest-hook, websocket, email, sms 또는 message인 Subscription 리소스를 생성합니다. 서버는 생성 및 업데이트마다 기준을 평가하고 일치하는 각 리소스 또는 빈 알림을 엔드포인트로 POST합니다.
{
"resourceType": "Subscription",
"status": "requested",
"reason": "Blood pressure alerts for the hypertension clinic",
"criteria": "Observation?code=http://loinc.org|85354-9&patient=Patient/123",
"channel": {
"type": "rest-hook",
"endpoint": "https://clinic.example.org/hooks/bp",
"payload": "application/fhir+json",
"header": ["Authorization: Bearer <token>"]
}
}
서버는 생성 및 업데이트 시마다 기준을 평가합니다. 리소스가 일치하면 해당 리소스를 엔드포인트로 POST합니다 (또는 payload이 생략된 경우 빈 본문을 POST하여 클라이언트가 직접 리소스를 가져오도록 합니다). 이 방식은 작동했지만 세 가지 문제가 있었습니다. 서버는 지원하는 기준을 알릴 수 없었고, 클라이언트는 알림 누락과 조용한 기간을 구분할 수 없었으며, "리소스가 검색과 일치했다"는 것은 "이벤트가 발생했다"는 것과 같지 않았습니다 (예: Encounter의 종료는 검색으로 표현할 수 없습니다).
R4B 및 R5: 토픽 기반 구독
FHIR R4B 및 R5에서는 구독이 토픽 기반입니다. 서버는 이벤트(리소스, 생성, 업데이트, 삭제 또는 FHIRPath 조건과 같은 트리거, 허용된 필터)를 설명하는 SubscriptionTopic 리소스를 게시합니다. 구독자는 filterBy 값, 채널 유형, 엔드포인트, 하트비트 기간 및 빈, id만 또는 전체 리소스의 콘텐츠 설정을 지정하는 토픽을 가리키는 Subscription을 생성합니다.
SubscriptionTopic은 서버가 게시하는 리소스로, 이벤트의 종류(리소스, 트리거(생성, 업데이트, 삭제 또는 FHIRPath 조건 예: %previous.status != 'finished' and %current.status = 'finished'), 구독자가 사용할 수 있는 필터)를 설명합니다. 구독자는 이후 해당 토픽을 가리키는 Subscription을 생성합니다.
{
"resourceType": "Subscription",
"status": "requested",
"topic": "http://example.org/fhir/SubscriptionTopic/encounter-end",
"filterBy": [{"resourceType": "Encounter", "filterParameter": "patient", "value": "Patient/123"}],
"channelType": {"system": "http://terminology.hl7.org/CodeSystem/subscription-channel-type", "code": "rest-hook"},
"endpoint": "https://clinic.example.org/hooks/encounters",
"heartbeatPeriod": 60,
"timeout": 30,
"contentType": "application/fhir+json",
"content": "id-only"
}
content는 전송되는 정보의 양을 선택합니다: empty(이벤트만), id-only(참조, 자체 권한으로 나머지 가져오기), 또는 full-resource. heartbeatPeriod는 서버가 하트비트를 보내 침묵을 감지할 수 있도록 합니다.
알림의 모습
FHIR 구독 알림은 subscription-notification 유형의 Bundle이며, 첫 번째 항목은 구독, 토픽, 알림 유형(handshake, heartbeat, event-notification, query-status 또는 query-event) 및 누락된 이벤트를 감지하기 위한 eventsSinceSubscriptionStart 카운터를 제공하는 SubscriptionStatus 리소스입니다. 추가 항목은 콘텐츠 설정에 따라 변경된 리소스 또는 해당 참조를 전달합니다.
모든 알림은 subscription-notification 타입의 Bundle입니다. 첫 번째 항목은 구독 참조, 토픽, 알림 유형(handshake, heartbeat, event-notification, query-status, query-event) 및 eventsSinceSubscriptionStart 카운터를 포함하는 SubscriptionStatus입니다. 카운터의 간격은 알림 누락을 의미하며, 클라이언트는 $events를 호출하여 이를 복구할 수 있습니다. 추가 항목은 content에 따라 리소스 또는 해당 참조를 포함합니다.
채널: rest-hook(서버가 HTTPS 엔드포인트로 POST), websocket(클라이언트가 연결하여 소켓에서 알림 수신, 브라우저 앱에 유용), email(알림만, 데이터는 없음), message(FHIR 메시징 Bundle). R4의 sms 채널은 삭제되었습니다.
프로덕션 환경에서의 실행
프로덕션 환경에서 FHIR 구독을 실행하려면 이벤트 번호 및 리소스 버전을 기준으로 하는 멱등성 처리, 발신자를 확인하고 페이로드를 권한으로 절대 취급하지 않는 엔드포인트 보안, 많은 이벤트를 포함하는 일괄 번들에 대한 허용 오차, 초기 핸드셰이크 알림에 대한 2xx 응답, 그리고 많은 서버가 여전히 구독을 환자 앱이 아닌 백엔드 서비스로 제한한다는 점을 인지해야 합니다.
- 멱등성. 재시도 후 알림이 중복될 수 있습니다. 이벤트 번호와 리소스 버전을 키로 사용하십시오.
- 보안. 엔드포인트는 발신자를 확인해야 하며(공유 비밀 헤더, 상호 TLS 또는 서명), 페이로드를 권한 부여로 절대 신뢰해서는 안 됩니다.
content가id-only인 경우 자체 토큰으로 서버에서 민감한 데이터를 다시 가져와야 합니다. - 백프레셔. 서버는 이벤트를 일괄 처리하고
maxCount를 존중합니다. 클라이언트는 많은 이벤트를 포함하는 번들을 수락해야 합니다. - 핸드셰이크. 활성화 시 서버는
handshake알림을 보내고 2xx 응답을 기대합니다. 그렇지 않으면 구독은error상태로 이동합니다. - 범위. SMART on FHIR은 구독 범위를 점진적으로 추가했습니다. 많은 서버는 여전히 환자 앱보다는 백엔드 서비스(클라이언트 자격 증명)로 구독을 제한합니다.
FHIR 구독이 아닌 웹훅
FHIR 구독이 아닌 웹훅은 일반적인 플랫폼 메커니즘입니다. HTTPS URL을 등록하면 SubscriptionTopic 없이 리소스 작성 또는 동의 변경과 같은 서명된 JSON 이벤트를 수신합니다. Anpheros는 이러한 웹훅을 제공합니다. 단일 플랫폼에는 더 간단하지만 일반 FHIR 클라이언트에서 검색할 수 없으므로 모든 FHIR 서버와 작동해야 하는 통합은 구독을 사용합니다.
Anpheros를 포함한 많은 플랫폼은 일반 웹훅을 제공합니다. HTTPS URL을 등록하면 리소스 작성, 동의 변경, 문서 최종화와 같은 서명된 JSON 이벤트를 수신합니다. 이들은 더 적은 절차와 SubscriptionTopic 없이 동일한 요구 사항을 해결하며, FHIR 리소스가 아니므로 일반 FHIR 클라이언트가 이를 검색할 수 없습니다. 통합이 모든 FHIR 서버와 작동해야 한다면 Subscriptions를 사용하십시오. 특정 플랫폼을 대상으로 한다면 해당 플랫폼의 웹훅이 일반적으로 더 간단합니다. Anpheros는 개발자 사이트(아래 링크)에서 웹훅을 문서화합니다.
관련 페이지
출처
- HL7 FHIR R5: Subscription
- HL7 FHIR R5: SubscriptionTopic
- HL7 FHIR R5: SubscriptionStatus 및 알림
- HL7 FHIR R4: Subscription
- Subscriptions R5 Backport 구현 가이드
자주 묻는 질문
R4 서버에서 R5 스타일 구독을 사용할 수 있나요?
예, 서버가 Subscriptions R5 Backport 구현 가이드를 구현하는 경우 가능합니다. 이 가이드는 R4 Subscription 리소스의 확장으로 토픽, 필터 및 채널 설정을 인코딩하고 알림에 R4 번들을 사용합니다.
Subscription과 _lastUpdated를 사용한 폴링의 차이점은 무엇인가요?
폴링은 서버에 반복적으로 요청하며 아무것도 놓치지 않지만 느리고 비효율적입니다. Subscription은 이벤트가 발생하는 즉시 푸시합니다. 견고한 클라이언트는 두 가지를 결합합니다. 속도를 위해 구독하고, 다운타임 후 복구를 위해 폴링하거나 $events를 호출합니다.
알림에 데이터가 포함되나요?
content가 full-resource인 경우에만 포함됩니다. 더 안전한 기본값은 id-only입니다. 알림은 어떤 리소스가 변경되었는지 알려주고, 자체 권한으로 해당 리소스를 가져옵니다.
FHIR Subscription과 웹훅은 같은 것인가요?
rest-hook 구독은 FHIR 정의된 형태의 웹훅입니다. 즉, 검색 가능한 토픽, 표준 알림 번들 및 상태 추적 기능을 갖추고 있습니다. 플랫폼에서 제공하는 일반 웹훅은 해당 플랫폼에 대해서만 동일한 작업을 수행합니다.
샌드박스에서 무료로 사용해 보세요
5분 만에 첫 FHIR 호출. 환자의 동의가 내장된 HL7 FHIR R4 API: 샌드박스에서 먼저 사용해보고, 자체 앱 또는 병원 시스템을 연결하세요.
무료 · 합성 환자 30명 · 카드 불필요

