간단히 말해: ImagingStudy는 이 환자가 언제 CT를 촬영했고, 어떤 시리즈와 인스턴스 UID를 사용했으며, 이미지는 어디에 있는지를 알려주는 FHIR 리소스입니다. DICOMweb은 픽셀을 보관하는 아카이브의 REST 인터페이스인 어디에 있는지를 나타냅니다. FHIR은 설명과 보고서를 전달하고, DICOM은 이미지를 전달합니다. ImagingStudy는 connectionType이 dicom-wado-rs인 Endpoint 리소스를 참조하며, 뷰어는 이 두 가지를 결합합니다.
ImagingStudy에 포함되는 내용
FHIR ImagingStudy 리소스에는 하나의 영상 검사에 대한 메타데이터가 포함됩니다. DICOM Study Instance UID가 식별자로, 상태, 대상 환자, 진료, 시작 시간 및 주문 서비스 요청, DICOM DCM 어휘의 모달리티 코드, 시리즈 및 인스턴스 수, 이미지가 있는 엔드포인트, 그리고 각 시리즈와 해당 인스턴스 및 UID가 포함됩니다. 픽셀 데이터는 포함되지 않습니다.
identifier: DICOM Study Instance UID,urn:oid:1.2.840…형식으로urn:dicom:uid시스템 사용;status: registered, available, cancelled, entered-in-error, unknown;subject: 환자;encounter,started,referrer,basedOn(주문한 ServiceRequest);modality: DICOM 자체 어휘(CT, MR, US, CR, DX 등)의 코드, 시스템http://dicom.nema.org/resources/ontology/DCM;numberOfSeries,numberOfInstances;endpoint: 이미지를 가져올 위치;series[]: 각 시리즈는 Series Instance UID, 모달리티, 신체 부위,instance[](SOP Instance UID 및 SOP Class UID 포함)를 가집니다.
포함되지 않는 내용: 픽셀 데이터, 창 설정, 전체 DICOM 헤더 또는 보고서 텍스트. 보고서는 imagingStudy가 다시 연결되는 DiagnosticReport입니다.
유효한 FHIR R4 예시
유효한 FHIR R4 ImagingStudy 예시에는 시스템 urn:dicom:uid를 가진 식별자로서의 Study Instance UID, 상태 'available', DICOM DCM 코드 시스템의 CT 모달리티, 환자, 시작 시간, 시리즈 및 인스턴스 수, connectionType이 dicom-wado-rs인 엔드포인트에 대한 참조, 그리고 UID, 신체 부위 및 SOP 클래스 UID를 가진 시리즈 항목이 포함됩니다.
{
"resourceType": "ImagingStudy",
"id": "ct-chest-2026-03",
"identifier": [{"system": "urn:dicom:uid", "value": "urn:oid:1.2.840.113619.2.55.3.2831164356.781.1710415000.1"}],
"status": "available",
"modality": [{"system": "http://dicom.nema.org/resources/ontology/DCM", "code": "CT"}],
"subject": {"reference": "Patient/example"},
"started": "2026-03-14T09:12:00+01:00",
"numberOfSeries": 2,
"numberOfInstances": 412,
"endpoint": [{"reference": "Endpoint/pacs-dicomweb"}],
"series": [{
"uid": "1.2.840.113619.2.55.3.2831164356.781.1710415000.2",
"number": 1,
"modality": {"system": "http://dicom.nema.org/resources/ontology/DCM", "code": "CT"},
"bodySite": {"system": "http://snomed.info/sct", "code": "51185008", "display": "Thoracic structure"},
"numberOfInstances": 410,
"instance": [{
"uid": "1.2.840.113619.2.55.3.2831164356.781.1710415000.3",
"sopClass": {"system": "urn:ietf:rfc:3986", "code": "urn:oid:1.2.840.10008.5.1.4.1.1.2"},
"number": 1
}]
}]
}
SOP Class UID 1.2.840.10008.5.1.4.1.1.2는 CT Image Storage입니다. Endpoint는 다음과 같습니다.
{
"resourceType": "Endpoint",
"id": "pacs-dicomweb",
"status": "active",
"connectionType": {"system": "http://terminology.hl7.org/CodeSystem/endpoint-connection-type", "code": "dicom-wado-rs"},
"payloadType": [{"text": "DICOM WADO-RS"}],
"address": "https://pacs.example-hospital.org/dicomweb"
}
뷰어는 이 두 가지를 사용하여 검색 URL을 만듭니다: {Endpoint.address}/studies/{StudyInstanceUID}, 그런 다음 메타데이터와 프레임을 위해 WADO-RS를 호출합니다.
ImagingStudy 리소스를 생성하는 주체
ImagingStudy 리소스는 일반적으로 PACS 또는 VNA 앞에 있는 FHIR 파사드 또는 통합 엔진에서 검사가 완료될 때 생성되며, 종종 HL7 v2 ORU 또는 DICOM MPPS 메시지에 의해 트리거됩니다. 일부 아카이브는 QIDO-RS 쿼리에서 실시간으로 생성하기도 합니다. 스캐너 자체는 ImagingStudy 리소스를 생성하지 않습니다.
일반적으로 스캐너가 아닙니다. PACS 또는 VNA 앞에 있는 FHIR 프록시 또는 통합 엔진이 스터디가 완료되면(종종 HL7 v2 ORU 또는 DICOM MPPS 메시지에 의해 트리거됨) ImagingStudy를 생성하고 numberOfInstances를 동기화 상태로 유지합니다. 일부 아카이브는 QIDO-RS 쿼리에서 ImagingStudy를 즉석에서 생성합니다. 프로젝트에서 수동으로 작성하는 경우 UID는 아카이브와 문자 하나하나 정확히 일치해야 합니다. 그렇지 않으면 뷰어에 빈 스터디가 표시됩니다.
뷰어를 망가뜨리는 실수
FHIR ImagingStudy를 읽는 뷰어를 망가뜨리는 실수는 다음과 같습니다. identifier 대신 id에 Study UID를 넣는 것, DICOM이 아닌 모달리티 코드를 사용하는 것, 잘못된 connectionType으로 엔드포인트가 DICOMweb 서버를 가리키도록 하는 것, 이미지가 변경된 후 시리즈 및 인스턴스 수를 최신 상태로 유지하지 않는 것, 그리고 DICOM 아카이브 대신 FHIR Binary에서 픽셀 데이터를 기대하는 것입니다.
- Study UID를
identifier대신id에 넣는 경우; FHIR id는 서버에서 할당되며 OID가 아닐 수 있습니다. - SNOMED 또는 로컬 목록의 모달리티를 DICOM DCM 코드 시스템 대신 사용하는 경우.
- DICOMweb 서버를 가리키는
connectionType이hl7-fhir-rest인 Endpoint 또는 그 반대의 경우. - 시리즈와 인스턴스를 한 번만 계산하고 이미지가 추가되거나 삭제될 때 업데이트하지 않는 경우.
- FHIR Binary에서 픽셀 데이터를 기대하는 경우. FHIR 사양 자체에서 이미지는 Binary가 아닌 DICOM에 속한다고 명시하고 있습니다.
Anpheros 기록에서
Anpheros Platform은 ImagingStudy 또는 DICOM 데이터를 호스팅하지 않습니다. 영상의학과 소견은 DiagnosticReport 또는 DocumentReference(코드 및 텍스트가 포함된 보고서)로 도착합니다. 병원에서 뷰어 링크를 제공하는 경우 DocumentReference에 첨부 URL로 포함될 수 있습니다. 이미지는 병원의 접근 규칙에 따라 병원 아카이브에 그대로 유지됩니다.
관련 페이지
- DICOMweb 설명
- DICOM 태그 설명
- DocumentReference vs DiagnosticReport vs Binary
- PACS vs RIS vs VNA
- CT 스캔 보고서 설명
- 개발자를 위한 DICOM vs FHIR
출처
- HL7 FHIR R4: ImagingStudy
- HL7 FHIR R4: Endpoint
- HL7 FHIR R4: endpoint-connection-type 코드 시스템
- DICOM PS3.16: DCM 제어 용어 (CID 29 Acquisition Modality)
- DICOM PS3.18: 웹 서비스
자주 묻는 질문
FHIR 서버에서 이미지를 직접 저장할 수 있나요?
기술적으로 Binary는 어떤 바이트든 담을 수 있지만, FHIR 사양은 영상에 대해 이를 권장하지 않으며 어떤 뷰어도 그런 방식으로 작동하지 않습니다. 이미지는 DICOM 아카이브에 그대로 유지되며, FHIR은 해당 위치를 가리킵니다.
ImagingStudy에 대해 FHIR R5에서 무엇이 변경되었나요?
R5는 동일한 구조를 유지하고 명명 규칙을 정리하며(예: procedure가 procedureReference 및 procedureCode를 대체함), 신체 부위 처리를 조정합니다. R4는 대부분의 아카이브와 국가 프로필에서 사용하는 버전으로 남아 있습니다.
보고서는 이미지와 어떻게 연결되나요?
DiagnosticReport.imagingStudy는 ImagingStudy를 참조하며, DiagnosticReport.media는 Media 리소스로 주요 이미지를 담을 수 있습니다. ImagingStudy는 전체 스터디를 위해 Endpoint를 참조합니다.
DICOMweb이 이미 있는데 ImagingStudy가 필요한가요?
다른 FHIR 소비자가 스터디의 존재를 알아야 하는 경우(예: 환자 앱, 케어 플랜 또는 연구 내보내기)에만 필요합니다. 영상의학과 뷰어만으로는 QIDO-RS 및 WADO-RS를 사용할 수 있습니다.
Anpheros Daily에서 사용해 보세요
검사 및 진단 보고서를 Anpheros Daily의 한 곳에 보관하고 다음 진료 시 보여줄 준비를 하세요.
앱에서 작동 방식 →
Anpheros는 환자가 직접 관리하고 어떤 병원과도 공유할 수 있는 의료 기록을 EU 기반의 HL7 FHIR R4 플랫폼에서 구축합니다. 이 가이드들은 건강 정보를 이해하고 정리하는 데 도움을 드리며, 의사의 진료를 대체하지 않습니다.
Anpheros 소개 →