KR20150105900A - 대상체의 의료 정보를 생성하는 방법 및 장치. - Google Patents

대상체의 의료 정보를 생성하는 방법 및 장치. Download PDF

Info

Publication number
KR20150105900A
KR20150105900A KR1020140109954A KR20140109954A KR20150105900A KR 20150105900 A KR20150105900 A KR 20150105900A KR 1020140109954 A KR1020140109954 A KR 1020140109954A KR 20140109954 A KR20140109954 A KR 20140109954A KR 20150105900 A KR20150105900 A KR 20150105900A
Authority
KR
South Korea
Prior art keywords
filter
cloud
content
document
group
Prior art date
Application number
KR1020140109954A
Other languages
English (en)
Other versions
KR102382313B1 (ko
Inventor
최승욱
Original Assignee
(주)아이알엠
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by (주)아이알엠 filed Critical (주)아이알엠
Priority to PCT/KR2015/001851 priority Critical patent/WO2015137646A1/ko
Priority to US15/111,830 priority patent/US20160350485A1/en
Publication of KR20150105900A publication Critical patent/KR20150105900A/ko
Priority to US17/308,513 priority patent/US11901075B2/en
Application granted granted Critical
Publication of KR102382313B1 publication Critical patent/KR102382313B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
    • G16H50/20—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for computer-aided diagnosis, e.g. based on medical expert systems
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
    • G16H50/30—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for calculating health indices; for individual health risk assessment

Abstract

대상체의 의료 정보를 생성하는 방법은 클라우드와 연결된 외부 장치들 중 적어도 어느 하나로부터 적어도 하나 이상의 제 1 컨텐츠를 수신하는 단계; 복수의 필터 클래스들 각각에 포함된 필터들 중에서 상기 제 1 컨텐츠에 기반하여 작업을 수행하는 제 1 필터를 선택하는 단계; 및 상기 제 1 필터에 의하여 기 설정된 작업을 수행하는 단계;를 포함한다.

Description

대상체의 의료 정보를 생성하는 방법 및 장치. {Method and apparatus for generating medical information of object}
대상체의 의료 정보를 생성하는 방법 및 장치에 관한다. 보다 구체적으로, 기 설정된 작업을 수행하는 적어도 하나 이상의 필터로 설계한 워크플로우를 이용하여 대상체의 의료 정보를 생성하는 방법 및 장치에 관한다.
클라우드 컴퓨팅(Cloud Computing)은 인터넷 또는 네트워크를 기반으로 하는 컴퓨팅 환경을 말한다. 인터넷 상에 존재하는 데이터 서버에 프로그램 인프라를 구축하고, 사용자가 이용하고자 할 때 컴퓨터, 휴대폰 등을 통해 데이터 서버에 저장된 프로그램들을 이용할 수 있도록 한다. 다시 말하면, 구름(Cloud)과 같이 무형의 형태로 존재하는 하드웨어 및/또는 소프트웨어 등의 컴퓨팅 자원을 사용자가 컴퓨터, 휴대폰과 같은 단말기(Terminal 또는 Client)를 통해 이용할 수 있다.
한편, 의학 기술 및 통신 기술이 발달함에 따라, 근래에는 의료 산업과 통신 산업을 융합하려는 시도가 활발히 진행되고 있다. 특히, 대상체(예를 들어, 환자)의 진단 결과를 가공함으로써 원하는 유형의 의료 정보를 생성하고, 이를 격지자 간에 공유할 수 있는 기술에 대한 연구가 진행되고 있다.
대상체의 의료 정보를 생성하는 방법 및 장치를 개시한다. 또한, 상기 방법을 컴퓨터에서 실행시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록매체를 제공하는 데 있다. 해결하려는 기술적 과제는 상기된 바와 같은 기술적 과제들로 한정되지 않으며, 또 다른 기술적 과제들이 존재할 수 있다.
일 측면에 따른 대상체의 의료 정보를 생성하는 방법은 클라우드와 연결된 외부 장치들 중 적어도 어느 하나로부터 적어도 하나 이상의 제 1 컨텐츠를 수신하는 단계; 복수의 필터 클래스들 각각에 포함된 필터들 중에서 상기 제 1 컨텐츠에 기반하여 작업을 수행하는 제 1 필터를 선택하는 단계; 및 상기 제 1 필터에 의하여 기 설정된 작업을 수행하는 단계;를 포함한다.
상술한 방법에 있어서, 상기 기 설정된 작업은 상기 제 1 컨텐츠가 제 2 컨텐츠로 변환되는 제 1 작업, 상기 클라우드와 연결된 장치들 중 적어도 어느 하나에 상기 제 1 컨텐츠가 제공되는 제 2 작업, 상기 제 1 컨텐츠와 제 3 컨텐츠를 조합함으로써 제 4 컨텐츠를 생성하는 제 3 작업 및 상기 제 1 컨텐츠를 저장하는 제 4 작업 중 어느 하나를 포함한다.
상술한 방법에 있어서, 상기 제 1 컨텐츠 내지 제 4 컨텐츠는 텍스트, 이미지, 동영상, 파형 및 일반 문서 중 어느 하나를 포함한다.
상술한 방법에 있어서, 상기 복수의 필터 클래스들 각각에 포함된 필터들 중에서 상기 기 설정된 작업의 수행 결과에 기반하여 작업을 수행하는 제 2 필터를 선택하는 단계; 및 상기 제 2 필터에 의하여 상기 제 2 필터에 기 설정된 작업을 수행하는 단계;를 더 포함한다.
상술한 방법에 있어서, 상기 필터 클래스는 동일한 유형의 작업을 수행하는 필터들이 포함된 그룹을 의미한다.
상술한 방법에 있어서, 상기 제 1 필터 및 상기 제 2 필터는 상기 제 1 필터 및 상기 제 2 필터 각각의 동작에 요구되는 정보 및/또는 상기 제 1 필터 및 상기 제 2 필터 각각이 상기 동작을 수행하는 시점에 대응하는 시간 조건이 설정된 필터를 포함한다.
상술한 방법에 있어서, 상기 제 1 필터 및 상기 제 2 필터 각각은 상기 클라우드의 내부에서 동작하는 내부 필터 또는 상기 외부 장치들 중 적어도 어느 하나에서 동작하는 외부 필터를 포함한다.
상술한 방법에 있어서, 상기 외부 필터는 상기 클라우드로부터 상기 외부 필터에서 수행될 작업 리스트를 수신하고, 상기 작업 리스트에 포함된 적어도 하나 이상의 작업의 수행 결과를 상기 클라우드로 전송하는 필터를 포함한다.
상술한 방법에 있어서, 상기 작업 리스트는 상기 클라우드가 상기 외부 필터에서 수행될 작업을 생성하고, 상기 생성된 작업을 상기 클라우드가 데이터베이스에서 검색함으로써 구성될 수 있다.
다른 측면에 따른 컴퓨터로 읽을 수 있는 기록매체는 상술한 방법을 컴퓨터에서 실행시키기 위한 프로그램을 기록한 기록매체를 포함한다.
또 다른 측면에 따른 대상체의 의료 정보를 생성하는 클라우드 시스템에 포함된 장치는 상기 클라우드와 연결된 외부 장치들 중 적어도 어느 하나로부터 적어도 하나 이상의 제 1 컨텐츠를 수신하는 인터페이스부; 및 복수의 필터 클래스들 각각에 포함된 필터들 중에서 상기 제 1 컨텐츠에 기반하여 기 설정된 작업을 수행하는 제 1 필터를 선택하는 필터 선택부;를 포함한다.
상술한 장치에 있어서, 상기 기 설정된 작업은 상기 제 1 컨텐츠가 제 2 컨텐츠로 변환되는 제 1 작업, 상기 클라우드와 연결된 장치들 중 적어도 어느 하나에 상기 제 1 컨텐츠가 제공되는 제 2 작업, 상기 제 1 컨텐츠와 제 3 컨텐츠를 조합함으로써 제 4 컨텐츠를 생성하는 제 3 작업 및 상기 제 1 컨텐츠를 저장하는 제 4 작업 중 어느 하나를 포함한다.
상술한 장치에 있어서, 상기 제 1 컨텐츠 내지 제 4 컨텐츠는 텍스트, 이미지, 동영상, 파형 및 일반 문서 중 어느 하나를 포함한다.
상술한 장치에 있어서, 상기 필터 선택부는 상기 복수의 필터 클래스들 각각에 포함된 필터들 중에서 상기 기 설정된 작업의 수행 결과에 기반하여 작업을 수행하는 제 2 필터를 선택하고, 상기 제 2 필터는 상기 제 2 필터에 기 설정된 작업을 수행한다.
상술한 장치에 있어서, 상기 필터 클래스는 동일한 유형의 작업을 수행하는 필터들이 포함된 그룹을 의미한다.
상술한 장치에 있어서, 상기 제 1 필터 및 상기 제 2 필터는 상기 제 1 필터 및 상기 제 2 필터 각각의 동작에 요구되는 정보 및/또는 상기 제 1 필터 및 상기 제 2 필터 각각이 상기 동작을 수행하는 시점에 대응하는 시간 조건이 설정된 필터를 포함한다.
상술한 장치에 있어서, 상기 제 1 필터 및 상기 제 2 필터 각각은 상기 클라우드의 내부에서 동작하는 내부 필터 또는 상기 외부 장치들 중 적어도 어느 하나에서 동작하는 외부 필터를 포함한다.
상술한 장치에 있어서, 상기 외부 필터는 상기 클라우드로부터 상기 외부 필터에서 수행될 작업 리스트를 수신하고, 상기 작업 리스트에 포함된 적어도 하나 이상의 작업의 수행 결과를 상기 클라우드로 전송하는 필터를 포함한다.
상술한 장치에 있어서, 상기 작업 리스트는 상기 클라우드가 상기 외부 필터에서 수행될 작업을 생성하고, 상기 생성된 작업을 상기 클라우드가 데이터베이스에서 검색함으로써 구성될 수 있다.
상술한 바에 따르면, 기 설정된 동작을 수행하는 적어도 하나 이상의 필터를 이용하여 워크플로우를 설계함으로써 사용자의 개입 없이 대상체의 의료 정보를 생성할 수 있다. 또한, 개방형 플랫폼에 기반하여 대상체의 의료 정보를 생성하고 제공할 수 있는바, 시간 및 공간의 제약 없이 대상체의 의료 정보를 제공할 수 있다.
도 1은 본 발명의 일 실시예에 따른 의료 정보 제공 시스템의 일 예를 도시한 개념도이다.
도 2는 본 발명의 일 실시예에 따른 의료 정보 제공 시스템의 일 예를 설명하기 위한 구성도이다.
도 3은 본 발명의 일 실시예에 따른 의료 정보 제공 시스템이 동작하는 일 예를 설명하기 위한 흐름도이다.
도 4는 본 발명의 일 실시예에 따른 워크플로우의 일 예를 도시한 도면이다.
도 5는 본 발명의 일 실시예에 따른 외부 필터의 일 예를 설명하기 위한 도면이다.
도 6은 본 발명의 일 실시예에 따른 의료 정보 제공 시스템에서 사용되는 통신 프로토콜의 일 예를 설명하기 위한 도면이다.
도 7은 본 발명의 일 실시예에 따른 대상체의 의료 정보를 생성하는 장치의 일 예를 나타내는 구성도이다.
도 8은 본 발명의 일 실시예에 따른 대상체의 의료 정보를 생성하는 방법의 일 예를 나타내는 흐름도이다.
이하에서는 도면을 참조하여 본 발명의 실시예들을 상세히 설명한다. 본 발명의 하기 실시예는 본 발명을 구체화하기 위한 것일 뿐 본 발명의 권리 범위를 제한하거나 한정하지 않는다. 또한, 본 발명의 상세한 설명 및 실시예로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자가 용이하게 유추할 수 있는 것은 본 발명의 권리범위에 속하는 것으로 해석된다.
도 1은 본 발명의 일 실시예에 따른 의료 정보 제공 시스템(100)의 일 예를 도시한 개념도이다.
도 1을 참조하면 의료 정보 제공 시스템(100)은 클라우드(110) 및 사용자(130)를 포함한다. 도 1에서는 설명의 편의를 위하여 사용자(130)를 도시하였으나, 여기에서 사용자(130)는 사용자(130)가 이용하는 장치로서 클라우드(110)에 접속이 가능한 외부 장치를 포함하는 개념이다. 또한, 클라우드(110)는 하나 이상의 외부 장치가 유무선 통신을 통하여 접속할 수 있는 소정의 서버로 구현될 수 있다.
본 발명의 일 실시예에 따른 의료 정보 제공 시스템(100)은 클라우드(110)에 기반하여 대상체의 의료 정보를 형성하고, 이를 사용자(130)에게 제공하는 시스템을 의미한다. 여기에서, 대상체는 진단이 요구되는 환자(patient)가 해당될 수 있으나, 이에 제한되지 않는다.
구체적으로, 의료 정보 제공 시스템(100)은 개방형 플랫폼에 기반하여 대상체의 의료 정보를 형성하고 이를 사용자(130)에게 제공할 수 있다. 예를 들어, 의료 정보 제공 시스템(100)은 IHE, DICOM, HL7과 같은 의료정보 표준 및 W3C, ISO와 같은 국제표준에 근거하여 의료정보를 검색, 저장, 전송, 조회, 교환하는 등의 다양한 서비스(120)를 제공하는 플랫폼을 포함한다.
예를 들어, 의료 정보 제공 시스템(100)이 제공하는 서비스(120)에는 의료 정보의 제공 또는 가공 서비스, 원격 진료(tele-medicine) 서비스, 의료 결정 지원 시스템(clinical decision supporting system) 서비스, 의료 정보의 저장 또는 공유 서비스, 서버 사이드 컴퓨팅(server-side computing) 서비스, 소셜 네트워킹(social networking) 서비스 등을 포함할 수 있다. 그러나, 상술한 서비스들에 한정되지 않고, 의료 정보를 이용하여 사용자가 수행할 수 있는 행위에 대한 서비스라면 본 발명의 일 실시예에 따른 의료 정보 제공 시스템(100)이 제공하는 서비스(120)에 제한 없이 해당될 수 있다.
이하, 도 2를 참조하여 의료 정보 제공 시스템(200)의 일 예를 설명한다.
도 2는 본 발명의 일 실시예에 따른 의료 정보 제공 시스템(200)의 일 예를 설명하기 위한 구성도이다.
도 2에는 의료 정보 제공 시스템(200)에서 제공하는 서비스(210), 외부 필터(220) 및 클라우드의 아키텍쳐(230)가 도시되어 있다. 아키텍쳐(230)에는 하부구조(infrastructure)(2310), 내부 필터(2320), 데이터 저장소(2330), 제어부(2340), 플랫폼 레벨 API(platform-level API)(2350), 서비스 특정 API(servie-specific API)(2360) 및 사용자 인터페이스(2370)가 포함된다. 여기에서, 제어부(2340)에는 데이터셋 핸들러(handler)(2341), 워크플로우 매니저(manager)(2342), 환자 매니저(2343), 사용자 매니저(2344), 그룹 매니저(2345), 조건 매니저(2346)가 포함된다. 또한, 도 2에는 도시되지 않았으나, 제어부(2340)에는 필터 매니저가 더 포함된다.
서비스(210)의 종류는 도 1을 참조하여 상술한 바와 같다. 따라서, 이하에서는 자세한 설명을 생략한다.
외부 필터(220)는 클라우드의 외부에서 동작하는 필터를 의미한다. 구체적으로, 외부 필터(220)는 클라우드의 데이터베이스 외부에서 작업을 수행한다. 예를 들어, 외부 필터(220)는 클라우드와 연결된 외부 장치들 중 적어도 하나 이상의 장치들에 포함될 수 있다. 이때, 외부 필터(220)에 대한 정보는 아키텍쳐(230)의 필터 매니저에서 생성, 설정, 변경, 삭제되어 외부 장치로 전송될 수도 있고, 또는 외부 장치에서 생성, 설정, 변경, 삭제될 수도 있다. 본 발명의 일 실시예에 따른 외부 필터(220)에 대한 구체적인 설명은 도 5 내지 도 6을 참조하여 후술한다.
도 2에 도시된 아키텍쳐(230)는 도 1의 클라우드(110)에 구현될 수 있는 일 예에 해당된다. 따라서, 도 2에 도시된 구성요소들 외에 다른 범용적인 구성요소들이 더 포함될 수 있음을 본 실시예와 관련된 기술분야에서 통상의 지식을 가진 자라면 이해할 수 있다.
또한, 도 2에 도시된 아키텍쳐(230)에 포함된 하부구조(2310), 데이터 저장소(2330), 제어부(2340), 플랫폼 레벨 API(2350), 서비스 특정 API(2360) 및 사용자 인터페이스(2370)는 하나 또는 복수 개의 프로세서에 해당할 수 있다. 프로세서는 다수의 논리 게이트들의 어레이로 구현될 수도 있고, 범용적인 마이크로 프로세서와 이 마이크로 프로세서에서 실행될 수 있는 프로그램이 저장된 메모리의 조합으로 구현될 수도 있다. 또한, 다른 형태의 하드웨어로 구현될 수도 있음을 본 실시예가 속하는 기술분야에서 통상의 지식을 가진 자라면 이해할 수 있다.
데이터 저장소(2330)는 클라우드가 처리할 수 있는 모든 종류의 컨텐츠를 저장 및 관리한다. 여기에서, 컨텐츠는 텍스트, 이미지, 동영상을 포함하는 모든 종류의 문서(document)를 의미한다. 다시 말해, 컨텐츠는 영상(image), 파형(waveforms), 측정값(measured values) 등 일반적인 연산 장치에서 처리될 수 있는 모든 종류의 문서를 포함한다. 따라서, 본 발명의 일 실시예에서의 컨텐츠와 문서는 동일한 개념으로 기술한다.
본 발명의 일 실시예에 따른 의료 정보 제공 시스템(200)에서, 하나의 문서는 0개 이상의 문서집합(document set; 이하 DocSet)에 포함될 수 있다. 다시 말해, 문서는 문서집합에 포함되지 않을 수도 있고, 하나 이상의 문서집합에 포함될 수도 있다. 또한, 특정 문서는 반드시 1개의 그룹에 속해야 한다. 여기에서, 그룹은 병원, 부서/과 등의 실체적 조직상의 그룹을 의미할 수도 있고, 가상적인 형태의 사용자 집합을 의미할 수도 있다. 그룹에 대한 구체적인 내용은 후술한다. 클라우드에서는 각각의 문서를 식별하기 위한 ID가 부여된다. 본 발명의 일 실시예에 따른 문서와 관련된 ID의 종류와 이에 대한 정의는 아래의 표 1과 같다.
ID 종류 정의
Document UID 문서의 고유 ID로서, 문서를 생성한 특정 그룹 내에서 고유하다.
Document UUID Document UID와는 별개의 고유 ID로서, 전체 문서들 내에서 고유하다. 예를 들어, 제 1 문서의 Document UID는 하나이나, 제 1 문서가 전송(또는 처리)되는 경우마다 Document UUID는 달라질 수 있다.
Filter UID 문서를 생성한 필터를 나타내는 ID이다.
Patient Id 문서와 관련된 환자를 나타내는 ID이다.
본 발명의 일 실시예에 따른 모든 문서들 각각은 고유한 ID (Unique ID; 이하 UID)를 갖는데, 이 UID는 특정 그룹 내에서만 고유함을 보장한다. 또한, 모든 문서들 각각은 UID와는 별도로 고유의 UUID를 갖는데 이는 전체 문서 내에서 고유함을 보장한다. 본 발명의 일 실시예에 따른 클라우드에서의 문서는 IHE XDS 개념에서의 Document Entry와 대응된다.
데이터셋 핸들러(2341)는 문서집합을 관리한다. 구체적으로, 데이터셋 핸들러(2341)는 문서집합의 생성, 설정, 변경, 삭제를 수행한다. 여기에서, 문서집합(DocSet)은 실제 문서(Document)들의 가상적인 집합을 의미한다. 클라우드 내에서의 모든 처리는 문서집합 단위로 이루어진다. 또한, 특정 문서집합은 반드시 1개의 그룹에 속해야 한다. 클라우드에서는 각각의 문서집합을 식별하기 위한 ID가 부여된다. 본 발명의 일 실시예에 따른 문서집합과 관련된 ID의 종류와 이에 대한 정의는 아래의 표 2와 같다.
ID 종류 정의
DocSet UID 문서집합의 고유 ID로서, 문서집합을 생성한 특정 그룹 내에서 고유하다.
DocSet UUID DocSet UID와는 별개의 고유 ID로서, 전체 문서집합 내에서 고유하다. 예를 들어, 제 1 문서집합의 DocSet UID는 하나이나, 제 1 문서집합이 전송(또는 처리)되는 경우마다 DocSet UUID는 달라질 수 있다.
DocSet Class UID 문서집합의 종류를 나타내는 것으로 필터(Filter)의 입출력 형식을 지정하는데 사용된다.
DocSet Group UID 문서집합들 사이에서 연관 관계를 표현하는데 사용된다.
Filter UID 문서집합을 생성한 필터를 나타낸다.
Patient Id 문서집합과 관련된 환자를 나타낸다.
본 발명의 일 실시예에 따른 클라우드에서의 문서집합은 IHE XDS 개념에서의 Submission Set과 대응된다.
또한, 문서집합은 반드시 1개의 문서집합 클래스(DocSet Class)를 갖는다. 여기에서, 문서집합 클래스는 문서집합의 클래스를 의미한다. 문서집합 클래스는 필터(filter)의 입출력 형식을 지정하는데 사용되며, 클라우드 내에서 고유한 DocSet Class UID로 표현된다.
워크플로우 매니저(2342)는 클라우드 내에서 동작하는 워크플로우를 관리한다. 구체적으로, 워크플로우 매니저(2342)는 워크플로우의 생성, 설정, 변경, 삭제를 수행한다. 본 발명의 일 실시예에 따른 워크플로우의 구체적인 일 예는 도 4를 참조하여 후술한다.
환자 매니저(2343)는 환자에 대한 정보를 관리한다. 구체적으로, 환자 매니저(2343)는 환자 정보의 생성, 설정, 변경, 삭제를 수행한다. 환자는 의료 정보 또는 건강 정보의 소유자를 의미하며, 의료 정보를 이용하는 다른 주체인 사용자(user)와는 대별된다. 현실에서, 환자는 기관(예를 들어, 병원 또는 정부)별로 서로 다른 환자번호를 부여받는다. 따라서, 클라우드 내에서 환자는 여러 개의 그룹에서 서로 다른 환자번호로 표현될 수 있으며, 서로 연관 지어 같은 환자를 나타낼 수 있다.
사용자 매니저(2344)는 사용자에 대한 정보를 관리한다. 구체적으로, 사용자 매니저(2344)는 사용자 정보의 생성, 설정, 변경, 삭제를 수행한다. 여기에서, 관리는 환자 정보의 생성, 변경, 삭제를 모두 포함한다. 사용자는 클라우드 서비스를 이용하는 사용자를 의미하는 것으로 환자와는 대별된다. 예를 들어, 사용자는 주로 의사, 간호사 등의 의료진인 경우가 많으나 정부 관계자 등이 될 수도 있다.
하나의 사용자는 0개 이상의 그룹에 속할 수 있다. 다시 말해, 사용자는 그룹에 속하지 않을 수도 있고, 하나 이상의 그룹에 속할 수도 있다. 만약, 사용자가 하나 이상의 그룹에 속할 경우, 사용자는 그룹 관리자 권한을 부여받을 수도 있다. 상술한 문서집합을 검색, 조회하는 권한은 개별 사용자에게 부여될 수 있다. 본 발명의 일 실시예에 따른 사용자는 의료 정보 제공 시스템(200) 자체의 방식을 통해 인증될 수도 있고, 기타 인증 서비스를 제공하는 사업자를 통해 인증될 수도 있다.
그룹 매니저(2345)는 그룹에 대한 정보를 관리한다. 구체적으로, 그룹 매니저(2345)는 그룹 정보의 생성, 설정, 변경, 삭제를 수행한다. 그룹은 사용자들의 집합을 의미한다. 구성하기에 따라, 그룹은 병원, 부서/과 등의 실체적 조직상의 그룹을 의미할 수도 있고, 가상적인 형태의 사용자 집합을 의미할 수도 있다.
그룹은 독립 그룹으로 구성되거나 또는 1개의 상위 그룹 아래 구성될 수 있다. 또한, 그룹은 다수의 사용자를 포괄할 수 있다. 그룹은 소속된 특정 사용자에게 그룹을 관리하는 관리자 권한을 부여할 수 있다. 이때, 그룹의 관리권은 해당 그룹의 하위 그룹들에도 상속된다. 다시 말해, 특정 그룹의 관리자는 해당 그룹의 하위 그룹도 관리할 수 있다.
문서집합을 검색, 조회하는 권한을 사용자가 속한 그룹을 통해 간접적으로 부여할 수 있다. 다만, 문서집합을 검색, 조회하는 권한은 지정된 그룹에만 유효할 뿐이고, 해당 그룹의 하위 그룹들에 전파되지는 않는다.
조건 매니저(2346)는 의료 정보 제공 시스템(200) 상에 설정된 조건들을 관리한다. 구체적으로, 조건 매니저(2346)는 조건의 생성, 설정, 변경, 삭제를 수행한다. 여기에서, 조건은 문서집합 조건(DocSet rule) 및/또는 필터 조건(filter rule)이 해당될 수 있다. 한편, 필터 조건은 조건 매니저(2346)에 의하여 생성, 설정, 변경, 삭제될 수도 있고, 필터 매니저에 의하여 생성, 설정, 변경, 삭제될 수도 있다.
구체적으로, 문서집합 조건은 특정 문서집합의 검색, 조회권을 어떤 사용자에게 자동으로 부여할 때 사용되는 조건을 의미한다. 또한, 필터 조건은 필터의 작업이 자동으로 수행되도록 하는 조건을 의미한다. 본 발명의 일 실시예에 따른 필터에는 내부 필터(2320) 또는 외부 필터(220)가 포함될 수 있다.
내부 필터(2320)는 클라우드 내부에서 동작하는 필터를 의미한다. 구체적으로, 내부 필터(2320)는 클라우드의 데이터베이스 내부에서 작업을 수행한다. 이때, 내부 필터(2320)에 대한 정보는 아키텍쳐(230)의 필터 매니저에서 생성, 설정, 변경, 삭제된다.
필터와 관련된 필터 클래스(filter class), 필터 조건(filter rule), 필터 큐(filter queue) 및 필터 로그(filter log) 각각에 대한 구체적인 설명은 아래와 같다.
먼저, 필터 클래스(Filter Class)는 필터의 클래스를 의미하며, 문서집합 클래스에 의해 입출력 형식을 표현한다. 하나의 필터 클래스는 다수의 필터에 대응될 수 있다. 즉, 같은 입출력 형식 및 기능을 갖는 다양한 필터가 존재할 수 있다.
필터의 입력 및 출력은 0개 이상의 문서집합 클래스로 표현될 수 있다. 구체적으로, 필터는 1개의 문서집합을 입력받아 1개의 문서집합을 출력할 수 있으나, 복수의 문서집합을 입력받아 복수의 출력 문서집합을 생성할 수도 있다. 또한, 입력 없이 출력만 가능한 필터 또는 출력 없이 입력만 가능한 필터도 가능하다.
내부 필터(2320)는 클라우드의 데이터베이스 내에서 작업을 수행하는 필터를 의미하며, 하부 구조(2310)의 데이터베이스의 저장 함수(stored function)으로 구현될 수 있다. 한편, 외부 필터(220)는 클라우드 데이터베이스 외부에서 작업을 수행하는 필터를 의미하며, 클라우드가 제공하는 API(2350, 2360)를 이용하여 구현될 수 있다.
필터(Filter)는 필터의 인스턴스(instance)를 나타내는 것으로 필터 클래스로 표현된 필터의 실제 인스턴스를 나타낸다. 동일한 필터 클래스 UID를 갖는 모든 필터들은 실질적으로 동일한 기능을 수행한다.
다만, 각각의 필터에 따라 기본 그룹(default group), 기본 환자(default patient) 등을 서로 다르게 지정될 수 있다. 예를 들어, 필터 매니저는 기본 그룹 지정을 통해 해당 필터가 생성하는 문서집합 및 문서의 그룹을 자동 설정할 수 있다. 또한, 필터 매니저는 기본 환자 지정을 통해 해당 필터가 생성하는 문서집합 및 문서의 환자를 자동 설정할 수 있다.
필터 조건은 필터의 동작에 요구되는 적어도 하나 이상의 조건을 의미하며, 필터 조건이 만족될 경우 필터는 자동으로 작업을 수행한다. 만약, 하나의 필터가 동작하기 위하여 다수의 문서집합이 필요한 경우, 각각의 문서집합 별로 조건이 설정될 수 있다.
예를 들어, 필터가 작업을 수행하는 시간을 다음과 같이 지정할 수 있다.
일 예로, 절대적으로 지정된 특정 일시(예를 들어, 2014년 4월 5일 오후 3시)
다른 예로, 필터 조건의 충족 시점을 기준으로 일정 시간 이후(예를 들어, 필터 조건이 충족되고 5시간 이후)
또 다른 예로, 조건 충족 시점의 다음 날 0시를 기준으로 일정 시간 이후(예를 들어, 2014년 4월 5일 오후 3시에 조건이 충족되었다면, 2014년 4월 6일 오전 0시를 기준으로 5시간 이후)
필터 조건이 충족되면, 필터 매니저(또는, 조건 매니저(2346))는 작업을 수행할 필터와 필요한 문서집합들을 필터 큐에 등록하고, 필터가 작업을 수행할 시간을 지정한다. 만약, 필터 수행 시간을 특정되지 않으면, 필터는 즉시 작업을 수행한다.
필터 큐는 필터의 동작을 위한 대기 큐를 의미한다. 내부 필터(2320)의 경우, 지정된 시간 간격(예를 들어, 60초)으로 필터 큐의 내용을 처리한다. 한편, 외부 필터(220)의 경우 FilterProc 모듈 설정에 따라 필터 큐의 내용을 처리한다.
필터 로그는 내부 필터(2320)의 처리(동작)에 관한 로그를 의미한다.
본 발명의 일 실시예에 따른 내부 필터(2320) 및 외부 필터(220)에 대한 구체적인 설명은 도 5 내지 도 6을 참조하여 후술한다.
사용자 인터페이스(2370)는 클라우드의 관리, 정보의 검색 및 조회를 위한 사용자 인터페이스를 의미한다. 예를 들어, 사용자 인터페이스(2370)는 웹(web) 기반의 인터페이스가 될 수 있다.
플랫폼 레벨 API(2350)는 클라우드와 외부 장치들 사이의 직접적인 인터페이스를 위하여 구현된 API 모음을 의미한다. 또한, 서비스 레벨 API(2360)는 의료 정보 제공 시스템(200)이 제공하는 서비스(210) 중 특정 서비스(예를 들어, service A)를 목적으로 플랫폼 레벨 API(2350)에 기반하여 구현된 API 모음을 의미한다.
하부 구조(2310)는 상술한 모든 클라우드 서비스가 동작하기 위한 하부 구조를 의미한다. 예를 들어, 하부 구조(2310)에는 Amazon Web Services 클라우드 서비스가 해당될 수 있으나, 이에 한정되지 않는다.
상술한 아키텍쳐(230)로 구현된 클라우드는 개방형 플랫폼에 기반하여 대상체(예를 들어, 환자)의 의료 정보를 생성하고 제공할 수 있는바, 시간 및 공간의 제약 없이 사용자에게 대상체의 의료 정보를 제공할 수 있다.
도 3은 본 발명의 일 실시예에 따른 의료 정보 제공 시스템이 동작하는 일 예를 설명하기 위한 흐름도이다.
도 3을 참조하면, 의료 정보 제공 시스템이 동작하는 일 예는 도 1 및 도 2 에 도시된 의료 정보 제공 시스템(100, 200) 또는 클라우드(110)에서 시계열적으로 처리되는 단계들로 구성된다. 따라서, 이하에서 생략된 내용이라 하더라도 도 1 및 도 2에 도시된 의료 정보 제공 시스템 또는 클라우드(110)에 관하여 이상에서 기술된 내용은 도 3의 의료 정보 제공 시스템이 동작하는 일 예에도 적용됨을 알 수 있다.
이하에서는 설명의 편의를 위하여, 도 3에 도시된 각 단계들의 수행 주체는 '클라우드(110)'인 것으로 기재한다. 다만, 도 3에 도시된 각 단계들의 수행 주체는 도 2에 도시된 아키텍쳐(230)에 포함된 구성들 중 어느 하나가 될 수 있음은 당해 기술 분야에서 통상의 지식을 가진 자라면 쉽게 이해할 수 있다.
310 단계에서, 클라우드(110)는 그룹 정보의 생성 및 설정을 수행한다.
먼저, 클라우드(110)는 사용자로부터 입력된 외부 신호에 기초하여, 서비스를 개설하려는 기관을 대표하는 그룹(이하, 마스터 그룹이라 부르기로 한다)을 생성한다. 마스터 그룹 아래에는 실제 병원들과 같은 기관들이 생성될 수 있다. 예를 들어, 클라우드(110)는 아래의 표 3과 같이 그룹을 생성할 수 있다.
그룹 계층
Group: Radionet 최상위 그룹: 마스터 그룹
Group: SNUH 1차 자식 그룹: 의료기관
Group: Radiology 2차 자식 그룹: 의료기관 내 부서
Group: CMC 1차 자식 그룹: 의료기관
Group: Cardiology 2차 자식 그룹: 의료기관 내 부서
Group: GuroClinic 1차 자식 그룹: 의료기관
상기 표 3을 참조하면, 클라우드(110)는 라디오넷 마스터 그룹(Radionet)을 생성하고, 서울대병원(SNUH), 카톨릭병원(CMC), 구로의원(Guro Clinic) 등의 실제 의료기관들을 라디오넷 마스터 그룹 아래에 자식 그룹으로 생성할 수 있다. 또한, 클라우드(110)는 실제 의료기관들을 그룹으로 구성한 후, 의료기관 내에 부서들을 또 다른 자식 그룹(Radiology, Cardiology)으로 등록할 수 있다.
그룹 정보의 저장을 위한 데이터베이스 테이블 구조의 일 예는 아래의 표 4와 같다.
Table "VGroup

Column Type Modifiers
--------------------------------------------------------------------------
vgroup_key integer not null PK
vgroup_id character varying(64) not null UK
vgroup_id_type character varying(16) not null UK
vgroup_name character varying(256)
vgroup_type character varying(64)
parent_vgroup_key integer FK
created_dttm timestamp without time zone not null
deleted_dttm timestamp without time zone
상기 표 4의 테이블 구조에 포함된 속성들의 구체적인 설명은 아래의 표 5와 같다.
속성 설명
Group Id 그룹의 ID를 의미하며, 환자번호를 구성하는 3개 요소 중의 하나인 assigning_authority_id를 Group Id 로 설정한다. ISO OID를 사용해서 표기할 수도 있으나, 이에 제한되지 않는다.
예를 들어, 82999와 같은 형태로 의료기관 코드가 부여되었다면, 이것은 한국(82)에 있는 999번 병원을 의미하는 것이다.
Group Id Type 그룹의 ID의 형태를 의미하며, 환자번호를 구성하는 3개 요소 중의 하나인 assigning_authority_id_type을 Group Id Type으로 설정한다. 그룹 ID가 ISO OID 형식으로 등록되어 있을 경우에는 ISO를 지정해야 하지만, 그렇지 않은 경우에는 자체적으로 정해서 사용할 수 있다.
예를 들어, Group Id Type는 “BIS-CLOUD”와 같이 설정될 수 있다.
Group Name 사람이 알아볼 수 있는 그룹의 이름을 의미한다. 예를 들어, 의료기관의 공식이름으로 설정될 수 있다.
Group Type 그룹의 형태를 나타내기 위한 항목을 의미한다.
예를 들어, 병원의 경우 “HOSPITAL”, 의원의 경우 “CLINIC"으로 설정될 수 있다.
Parent Group 부모 그룹을 의미한다.
320 단계에서, 클라우드(110)는 사용자 정보의 생성 및 설정을 수행한다.
클라우드(110)는 사용자로부터 입력된 외부 신호에 기초하여, 마스터 그룹을 관리할 사용자(이하, 마스터 관리자)를 생성한다. 그리고, 클라우드(110)는 마스터 관리자에게 마스터 그룹에 대한 관리권을 부여한다. 본 발명의 일 실시예에 따른 의료 정보 제공 시스템에서는 일 사용자가 어떤 그룹에 대해 관리권을 갖고 있다면 (즉, 그룹 관리자라면), 해당 그룹의 하위 그룹도 관리할 수 있다. 따라서, 마스터 관리자가 마스터 그룹에 대해 관리권을 갖고 있다는 것은 결국 마스터 관리자가 마스터 그룹 아래에 여러 그룹을 생성할 수 있다. 그룹 관리자만이 해당 그룹 및 해당 그룹의 자식 그룹들에 사용자 또는 환자를 추가할 수 있다.
예를 들어, 그룹에 따른 그룹 관리자가 설정된 일 예는 아래의 표 6과 같다.
그룹 계층 그룹 관리자
Group: Radionet bioadmin
Group: SNUH bioadmin, snuhadmin
Group: Radiology bioadmin, snuhadmin, snuhradioadmin
Group: CMC bioadmin, cmcadmin
Group: Cardiology bioadmin, cmcadmin
Group: GuroClinic bioadmin, gurocadmin
상기 표 6을 참조하면, 마스터 관리자 bioadmin은 Radionet 그룹 및 자식 그룹들을 모두 관리할 수 있다. 한편, 그룹 관리자 snuhadmin은 SNUH 그룹 및 이것의 자식 그룹인 Radiology 그룹을 관리할 수 있다. 만약, Radiology 그룹에 대해 별도의 관리자가 필요하다면, 상기 표 6과 같이 snuhradioadmin이라는 그룹 관리자가 추가로 지정될 수 있다.
본 발명의 일 실시예에 따른 의료 정보 제공 시스템에서 사용자는 여러 개의 그룹에 소속될 수 있다. 이때, 사용자가 특정 그룹에 소속되어 관리권을 부여받으면 해당 그룹에 대한 관리자가 되고, 그렇지 않으면 일반 사용자가 된다. 그룹 관리자가 생성된 이후에는 클라우드(110)는 필요한 만큼의 일반 사용자를 생성하고 이들을 그룹에 소속시킨다.
다만, 권한이 상속되는 관리권과는 달리 조회권은 상속되지 않는다. 즉, 어떤 그룹에 대한 문서를 조회하려면 반드시 해당 그룹에 소속된 사용자이어야만 한다. 예를 들어, 상기 표 6을 참조하면, 그룹 관리자 snuhadmin은 SNUH 그룹과 Radiology 그룹을 관리할 수는 있지만, Radiology 그룹의 문서를 조회할 수는 없다. 사용자 snuhadmin이 Radiology 그룹의 문서를 조회하려면, snuhadmin 역시 Radiology 그룹에 소속되어야 한다.
사용자는 여러 개의 인증 방법을 가질 수 있다. 예를 들어, 사용자는 의료 정보 제공 시스템의 자체 인증을 통해 로그인할 수도 있고, 기타 인증 계정(예를 들어, 구글 계정)을 통해 로그인할 수도 있다.
사용자 정보 저장을 위한 데이터베이스 테이블 구조의 일 예는 아래의 표 7과 같다.
Table "Users

Column Type Modifiers
--------------------------------------------------------------------------
user_key integer not null PK
user_name character varying(256) not null
created_dttm timestamp without time zone not null
deleted_dttm timestamp without time zone
그룹과 사용자 간의 관계 설정을 위한 데이터베이스 테이블 구조의 일 예는 아래의 표 8과 같다.
Table "VGroupUser

Column Type Modifiers
--------------------------------------------------------------------------
vgroup_user_key integer not null PK
vgroup_key integer not null FK
user_key integer not null FK
admin_role Boolean default false
330 단계에서, 클라우드(110)는 환자 정보의 생성 및 설정을 수행한다.
클라우드(110)는 사용자로부터 입력된 외부 신호에 기초하여, 환자 정보를 생성하고 설정할 수 있다. 본 발명의 일 실시예에 따른 의료 정보 제공 시스템에서 환자는 환자번호, 이름, 성별, 생년월일 등의 속성을 가질 수 있다. 이 중에서, 환자번호는 (patient_id_value, assigning_authority_id, assigning_authority_id_type)과 같이 3개의 부분으로 구성된다. 이때, assigning_authority_id, assigning_authority_id_type는 그룹의 Group Id, Group Id Type에 대응하는 것이고, patient_id_value가 해당 그룹에서의 환자번호를 나타낸다. 따라서, 본 발명의 일 실시예에 따른 의료 정보 제공 시스템에서 환자는 반드시 1개의 그룹에만 속하게 된다.
환자 정보 저장을 위한 데이터베이스 테이블 구조의 일 예는 아래의 표 9와 같다.
Table "Patient

Column Type Modifiers
--------------------------------------------------------------------------
patient_key integer not null PK
vgroup_key integer not null FK
patient_id_value character varying(64) not null
patient_name character varying(256) not null
patient_sex character varying(1)
patient_birth_dttm timestamp without time zone
related_patient_key integer FK
created_dttm timestamp without time zone not null
deleted_dttm timestamp without time zone
상기 표 9의 테이블 구조에 포함된 속성들의 구체적인 설명은 아래의 표 10과 같다.
속성 설명
Patient Id Value 환자번호를 구성하는 3개 부분 중 첫 번째인 patient_id_value를 의미한다.
Patient Name 환자이름을 의미한다. 예를 들어, HL7 방식(Last name^First name^Middle name^Suffix^Prefix)으로 입력될 수 있다.
Patient Sex 환자성별을 의미한다. 예를 들어, 'M=남성, F=여성, O=기타, U=모름'과 같이 입력될 수 있다.
Patient Birthdate 환자의 생년월일을 의미한다.
Related Patient 다른 환자정보와 연결을 의미한다.
동일한 환자라 하더라도 여러 개의 의료기관을 이용할 수 있다. 이 경우, 동일한 환자에 대해서 의료기관별로 서로 다른 환자번호가 부여될 수 있다. 따라서, 본 발명의 일 실시예에 따른 의료 정보 제공 시스템은 의료기관별로 환자를 생성한다. 다만, 의료 정보 제공 시스템에서의 환자 속성에는, 상기 표 10에 기재한 바와 같이 Related Patient라는 속성이 있는바, 다른 환자정보와 연결할 수 있다. 다시 말해, 클라우드(110)는 Related Patient 속성을 이용하여 각각의 의료기관에 분산된 동일한 환자에 대한 정보들을 찾아 연결할 수 있다.
340 단계에서, 클라우드(110)는 클라우드(110)의 관리자로부터 입력된 외부 신호에 기초하여 워크플로우를 설계한다.
워크플로우는 의료 정보 제공 시스템의 적어도 하나 이상의 필터가 작업을 수행하는 흐름을 나타낸다. 본 발명의 일 실시예에 따른 의료 정보 시스템은 워크플로우에 따라 대상체(예를 들어, 환자)의 의료 정보를 생성하고, 이를 사용자에게 제공한다. 이하, 도 4를 참조하여 워크플로우의 일 예를 설명한다.
도 4는 본 발명의 일 실시예에 따른 워크플로우(400)의 일 예를 도시한 도면이다.
도 4에는 클라우드(110)가 설계한 워크플로우(400)의 일 예가 도시되어 있다. 도 4는 설명의 편의를 위하여 도시된 것일 뿐, 클라우드(110)가 설계하는 워크플로우(400)는 도 4에 도시된 것에 한정되지 않는다. 다시 말해, 적어도 하나 이상의 필터집합 또는 단일 필터집합에 속한 적어도 하나 이상의 필터를 이용하여 대상체(예를 들어, 환자)의 의료 정보를 생성하고, 이를 사용자에게 제공할 수 있는 워크플로우라면 제한 없이 본 발명의 범위에 속할 수 있다.
도 4의 워크플로우(400)에서 원형상으로 도시된 부분은 문서집합 클래스(DSC)를 의미한다. 하나의 문서집합 내에는 적어도 하나 이상의 문서가 포함될 수 있다. 따라서, 도 4의 원형상들 각각에는 특정 문서집합 클래스가 기재되어 있으나, 문서집합에 속한 다른 문서도 해당될 수 있음은 당해 기술분야에서 통상의 기술을 가진 자라면 쉽게 이해할 수 있다. 문서집합 클래스, 문서집합 및 문서에 대한 구체적인 설명은 도 2를 참조하여 전술한 바와 같으므로, 이하에서는 생략한다.
또한, 도 4의 워크플로우(400)에서 사각형상으로 도시된 부분은 필터 클래스(FC) 및 필터 클래스에 포함된 필터(FU)를 의미한다. 하나의 필터 클래스에는 적어도 하나 이상의 필터가 포함될 수 있다. 따라서, 도 4의 사각형상들 각각에는 특정 필터 클래스 및 필터가 기재되어 있으나, 필터 클래스에 포함된 다른 필터도 해당될 수 있음은 당해 기술분야에서 통상의 기술을 가진 자라면 쉽게 이해할 수 있다. 필터 클래스 및 필터에 대한 구체적인 설명은 도 2를 참조하여 전술한 바와 같으므로, 이하에서는 생략한다.
또한, 도 4에 기재된 문서집합 클래스, 필터 클래스 및 필터의 구체적인 명칭은 편의상 부가한 것이므로, 이에 한정되지 않는다.
필터 클래스 3.1의 한 인스턴스인 필터 4.1(410)은 EKG(411), Holter(412), Event Recorder(413), DICOM(414)의 4가지 종류의 문서집합 중 하나 이상을 생성한다. 여기에서, 필터 4.1(410)은 문서집합을 생성하는 외부필터가 될 수도 있고, 외부 장치로부터 수신된 신호를 이용하여 문서집합을 생성하는 내부필터가 될 수도 있다. 문서집합 클래스 5.1로 표현된 EKG 문서집합(411)은 데이터 저장소(2330)에 저장될 수 있다.
필터 클래스 3.2.1의 한 인스턴스인 필터 4.2.1(420)은 Holter 문서집합(문서집합 클래스 5.2)(412)을 입력받아 CDSS 결과보고서 문서집합(문서집합 클래스 5.2.1)(421)을 출력한다.
필터 클래스 3.2.2의 한 인스턴스인 필터 4.2.2(450)는 원본 Holter 문서집합(412)과 CDSS 결과보고서 문서집합(421)을 통합하여 새로운 문서집합(문서집합 클래스 5.2.2)(451)을 생성한다. 생성된 문서집합(451)은 데이터 저장소(2330)에 저장될 수 있다.
필터 클래스 3.2의 한 인스턴스인 필터 4.2(430)는 문서집합 클래스 5.3으로 표현된 Event Recorder 문서집합(413)을 통합한다.
필터 클래스 3.4.1의 한 인스턴스인 필터 4.4.1(440)은 문서집합 클래스 5.4로 표현된 DICOM 문서집합(414)을 외부 장치에 제공한다. 그리고, 외부 장치는 DICOM 문서 집합(414)을 화면에 디스플레이한다. 디스플레이된 문서집합(441)은 클라우드(110)에 의하여 확인될 수 있다.
다시 도 3을 참조하면, 350 단계에서, 클라우드(110)는 문서집합 클래스를 설정한다. 다시 말해, 클라우드(110)는 340 단계에서 설계한 워크플로우(400)가 동작하기 위하여 필요한 문서집합 클래스를 설정한다.
클라우드(110)는 각 문서집합 및 필터에 UID를 부여하고, 이를 의료 정보 제공 시스템에 설정한다. 예를 들어, 도 4에 도시된 필터 클래스 3.1(410), 문서집합 클래스 5.1(411)은 각각 1.2.410.200054.3.1, 1.2.410.200054.5.1와 같은 UID로 표현될 수 있다. 문서집합 클래스의 설정은 상기 UID와 문서집합 클래스의 이름이 지정되는 것으로 완료된다.
문서집합 클래스 정보의 저장을 위한 데이터베이스 테이블 구조의 일 예는 아래의 표 11과 같다.
Table "DocSetClass

Column Type Modifiers
--------------------------------------------------------------------------
docset_class_uid character varying(64) not null PK
docset_class_type character varying(10) not null
docset_class_name character varying(256) not null
상기 표 11의 테이블 구조에 포함된 속성들의 구체적인 설명은 아래의 표 12와 같다.
속성 설명
DocSet Class UID 문서집합 클래스의 UID를 의미하며, 각 문서집합 클래스에는 고유한 UID가 부여된다.
DocSet Class Type 문서집합 클래스의 형태를 의미하는 것으로 참고용으로만 사용된다.
DocSet Class Name 문서집합 클래스의 이름을 나타낸다.
360 단계에서, 클라우드(110)는 필터 클래스를 설정한다. 다시 말해, 클라우드(110)는 340 단계에서 설계한 워크플로우(400)가 동작하기 위하여 필요한 필터 클래스를 설정한다.
클라우드(110)가 필터 클래스를 설정하기 위해서는 필터 클래스 UID 및 필터 클래스 이름 뿐만 아니라 다음과 같이 몇 가지 추가 속성이 더 필요하다.
필터 클래스 정보의 저장을 위한 데이터베이스 테이블 구조의 일 예는 아래의 표 13 및 표 14와 같다.
Table "FilterClass

Column Type Modifiers
--------------------------------------------------------------------------
filter_class_uid character varying(64) not null PK
filter_class_name character varying(256) not null
filter_type character varying(10) not null
filter_proc_name character varying(256)
filter_proc_args character varying(256)
Table "FilterInOut

Column Type Modifiers
--------------------------------------------------------------------------
filter_class_uid character varying(64) not null PK, FK
docset_type character varying(1) not null PK
docset_class_uid character varying(64) not null PK, FK
상기 표 13 및 표 14의 테이블 구조에 포함된 속성들의 구체적인 설명은 아래의 표 15와 같다.
속성 설명
Filter Class UID 필터 클래스의 UID로서 각 필터 클래스에 고유한 UID가 부여된다.
Filter Class Name 필터 클래스의 이름을 나타낸다.
Filter Class Type 필터 클래스의 형태를 의미하는 것으로 내부필터(I)인지, 외부필터(E)인지 나타낸다.
Filter Proc Name 내부 필터에서만 설정되는 것으로 데이터베이스 프로시저의 이름이다.
Filter Proc Args 내부 필터에서만 설정하는 것으로 데이터베이스 프로시저의 인자들이다.
DocSet Type 지정된 문서집합이 필터의 입력(I)인지 출력(O)인지 나타낸다.
DocSet Class UID 필터의 입력 또는 출력 문서집합을 지정한다.
또한, 클라우드(110)는 각각의 필터 클래스가 처리할 수 있는 입력 문서집합 및 출력 문서집합을 설정한다.
예를 들어, 클라우드(110)는 아래의 표 16과 같이 필터 클래스를 설정할 수 있다.
filter_class_uid filter_class_name type filter_proc_name
docset_type docset_class_uid
--------------------------------------------------------------------------
1.2.410.200054.3.1 data uploader E
O 1.2.410.200054.5.1
O 1.2.410.200054.5.2
O 1.2.410.200054.5.3
O 1.2.410.200054.5.4
1.2.410.200054.3.2 Holter data creator E
I 1.2.410.200054.5.3
1.2.410.200054.3.2.1 CDSS caller E
I 1.2.410.200054.5.2
O 1.2.410.200054.5.2.1
1.2.410.200054.3.2.2 data merger I FilterQueue_bypass
I 1.2.410.200054.5.2
I 1.2.410.200054.5.2.1
O 1.2.410.200054.5.2.2
1.2.410.200054.3.4.1 DICOM viewer E
I 1.2.410.200054.5.4
O 1.2.410.200054.5.4.1
370 단계에서, 클라우드(110)는 필터를 설정한다. 다시 말해, 클라우드(110)는 340 단계에서 설계한 워크플로우(400)가 동작하기 위하여 필요한 필터를 설정한다.
필터 정보의 저장을 위한 데이터베이스 테이블 구조의 일 예는 아래의 표 17과 같다.
Table "Filter

Column Type Modifiers
--------------------------------------------------------------------------
filter_key integer not null PK
filter_uid character varying(64) not null UK
filter_class_uid character varying(64) not null FK
filter_name character varying(256) not null
filter_proc_args character varying(32)
default_vgroup_key integer FK
default_patient_key integer FK
user_key integer FK
created_dttm timestamp without time zone not null
deleted_dttm timestamp without time zone
상기 표 17의 테이블 구조에 포함된 속성들의 구체적인 설명은 아래의 표 18과 같다.
속성 설명
Filter UID 필터의 UID를 나타내는 것으로 각각의 필터마다 고유한 값이다.
Filter Class UID 필터의 종류를 나타내는 것으로 필터 클래스 UID를 설정한다
Filter Name 필터 이름을 의미한다.
Filter Proc Args 내부 필터에서 사용하는 데이터베이스 프로시저의 인자를 재정의한다.
Default Group 필터가 처리하는 문서집합에 그룹정보가 없을 때 자동으로 설정되는 그룹을 의미한다.
Default Patient 필터가 처리하는 문서집합에 환자정보가 없을 때 자동으로 설정되는 환자를 의미한다.
예를 들어, 클라우드(110)는 아래의 표 19와 같이 필터를 설정할 수 있다.
filter_uid filter_class_uid filter_name
--------------------------------------------------------------------------------
1.2.410.200054.4.1.2.152.82.177.100.84.74.1598 1.2.410.200054.3.1 Bioroid02(ejoonie)

1.2.410.200054.4.1.2.152.82.177.100.84.74.1582 1.2.410.200054.3.1 Bioroid

1.2.410.200054.4.1.2.20.137.253.246.167.124.1347 1.2.410.200054.3.1 Bioroid

1.2.410.200054.4.1.2.152.82.177.100.84.74.2289 1.2.410.200054.3.1 Bioroid

1.2.410.200054.4.1.2.20.137.253.246.167.124 1.2.410.200054.3.1 Bioroid

1.2.410.200054.4.1 1.2.410.200054.3.1 BioPump

1.2.410.200054.4.1.2.152.82.177.100.84.74 1.2.410.200054.3.1 Bioroid (ejoonie)

1.2.410.200054.4.1.2.12.223.164.47.47.236 1.2.410.200054.3.1 Bioroid

1.2.410.200054.4.1.2.8.212.43.25.38.81 1.2.410.200054.3.1 Bioroid

1.2.410.200054.4.2 1.2.410.200054.3.2 EventMerge

1.2.410.200054.4.2.1 1.2.410.200054.3.2.1 HolterExport

1.2.410.200054.4.2.2 1.2.410.200054.3.2.2 SimpleMerge

1.2.410.200054.4.4.1 1.2.410.200054.3.4.1 ezDICOM
380 단계에서, 클라우드(110)는 필터 조건을 설정한다.
만약, 클라우드(110)가 필터 조건을 설정하지 않으면 문서집합들은 단순히 저장하는 것만이 가능할 뿐이고, 도 4에 도시된 워크플로우(400)는 구현될 수 없다. 필터 조건은 i) 작업을 수행해야 할 필터에 대한 설정 부분과, ii) 필터가 작업을 수행하기 위한 입력조건을 설정하는 부분으로 구성된다.
먼저, 필터의 입력조건이 만족되었을 때, 필터가 수행할 작업의 정보를 저장하기 위한 데이터베이스 테이블 구조의 일 예는 아래의 표 20과 같다.
Table "FilterRule

Column Type Modifiers
--------------------------------------------------------------------------
filter_rule_key integer not null PK
filter_key integer not null FK
filter_rule_name character varying(256)
scheduled_dttm timestamp without time zone
scheduled_delay integer
created_dttm timestamp without time zone not null
deleted_dttm timestamp without time zone
상기 표 20의 테이블 구조에 포함된 속성들의 구체적인 설명은 아래의 표 21과 같다.
속성 설명
Filter Rule Name 필터 룰의 이름을 나타낸다.
Filter 수행되어야 할 필터를 선택한다.
Scheduled Time 필터가 수행될 절대시간을 지정하는 것으로, 지정된 시간에 필터가작업을 수행한다. 절대시간 지정은 아래의 상대시간 지정보다 우선한다.
Scheduled Delay 필터가 수행될 상대시간을 지정하는 것으로,
a) 모드에서는 현재시점으로부터 지정된 시간 이후에, 또는
b) 모드에서는 내일 0시 이후 지정된 시간에 필터가 수행된다.
예를 들어, 현재시점이 2014년 2월 5일 18:00이고 Scheduled Delay 속성이 3:00 이라면,
a) 모드에서는 2014년 2월 5일 21:00에 필터가 수행된다.
b) 모드에서는 2014년 2월 6일 3:00에 필터가 수행된다.
다음으로, 필터의 입력조건의 설정을 위한 데이터베이스 테이블 구조의 일 예는 아래의 표 22와 같다.
Table "FilterRuleInput

Column Type Modifiers
--------------------------------------------------------------------------
filter_rule_input_key integer not null PK
filter_rule_key integer not null FK, UK
docset_class_uid character varying(64) not null FK, UK
filter_key integer FK, UK
vgroup_key integer FK, UK
patient_key integer FK, UK
상기 표 22의 테이블 구조에 포함된 속성들의 구체적인 설명은 아래의 표 23과 같다.
속성 설명
Filter Rule 필터 조건을 선택한다.
DocSet Class UID 어떤 문서집합이 준비되어야 필터가 수행될 것인지를 설정한다.
Filter 위의 문서집합이 어떤 필터가 생성한 것이어야 하는지 설정한다.
Group 위의 문서집합이 어떤 그룹에 속한 것이어야 하는지 설정한다.
Patient 위의 문서집합이 어떤 환자의 것이어야 하는지 설정한다.
도 4에 도시된 워크플로우(400)를 참조하면, Holter 문서(412)와 DICOM 문서(414)에 대해서만 워크플로우 설정이 필요하다. 이는, 클라우드(110)가 아래의 표 24와 같이 설정함으로써 구현될 수 있다.
filter_rule_name filter_uid scheduled_dttm delay
docset_class_uid filter vgroup patient
--------------------------------------------------------------------------
HolterExport rule 1.2.410.200054.4.2.1
1.2.410.200054.5.2
Merger rule 1.2.410.200054.4.2.2
1.2.410.200054.5.2
1.2.410.200054.5.2.1
ezDICOM rule 1.2.410.200054.4.4.1
1.2.410.200054.5.4
새로운 문서집합이 생성될 경우, 자동으로 FilterRule_apply() 함수가 호출된다. 이때, 클라우드(110)는 필터 조건을 검색하여 새로 생성된 문서집합에 적용할 필터가 있는지를 검색하고, 그 결과를 필터 큐에 기록한다. 만약, 필터 조건의 입력조건이 하나의 문서집합으로만 구성되어 있을 경우에는, 조건을 만족하는 해당 문서집합이 생성되는 즉시 필터 조건이 적용된다. 그러나, 필터 조건의 입력조건이 여러 개의 문서집합으로 구성되어 있는 경우에는(즉, 여러 개의 문서집합을 한꺼번에 처리해야 하는 필터라면), 필터 수행에 필요한 모든 문서집합이 준비 완료되었을 때에 필터 조건이 적용된다.
상기 표 24의 내용을 설명하면 아래와 같다.
1) 필터 룰 “HolterExport rule”은 문서집합 클래스 1.2.410.200054.5.2에 대한 문서집합이 준비되면 필터 1.2.410.200054.4.2.1이 즉시 수행된다.
2) 필터 룰 “Merger rule”은 문서집합 클래스 1.2.410.200054.5.2 및 1.2.410.200054.5.2.1에 대한 문서집합이 모두 준비될 때 필터 1.2.410.200054.5.2.2가 수행된다.
3) 필터 룰 “ezDICOM rule”은 문서집합 클래스 1.2.410.200054.5.4에 대한 문서집합이 준비될 때 필터 1.2.410.200054.4.4.1이 수행된다.
390 단계에서, 필터 큐가 생성된다. 필터 큐는 설정하는 것이 아니라 필터 조건을 적용한 결과로서 생성되는 것으로, 작업을 수행해야 할 필터에 대한 정보들과 필터의 작업 수행 결과를 저장한다.
필터 큐는 i) 작업을 수행할 필터에 대한 정보를 저장하는 부분과, ii) 필터의 입력으로 들어갈 문서집합에 대한 정보를 저장하는 부분으로 구성된다.
먼저, 작업을 수행할 필터에 대한 정보를 저장하기 위한 데이터베이스 테이블 구조의 일 예는 아래의 표 25와 같다.
Table "FilterQueue

Column Type Modifiers
--------------------------------------------------------------------------
filter_queue_key integer not null PK
filter_queue_uuid uuid not null UK
filter_key integer not null FK
filter_result_text text
filter_result_code integer
scheduled_dttm timestamp without time zone
performed_dttm timestamp without time zone
created_dttm timestamp without time zone not null
상기 표 25의 테이블 구조에 포함된 속성들의 구체적인 설명은 아래의 표 26과 같다.
속성 설명
Filter Queue UUID 필터 큐에 대한 UUID로서, 필터 작업을 XDS 방식으로 처리할 때 사용된다.
Filter 수행될 필터를 지정한다.
Filter Result Text 필터의 수행 결과를 나타낸다.
Filter Result Code 필터의 수행 결과코드를 나타낸다.
Scheduled Time 필터가 수행될 시간을 나타낸다.
Performed Time 필터가 수행된 시간을 나타낸다.
다음으로, 필터의 입력으로 들어갈 문서집합에 대한 정보를 저장하기 위한 데이터베이스 테이블 구조의 일 예는 아래의 표 27과 같다.
Table "FilterQueueInput

Column Type Modifiers
--------------------------------------------------------------------------
filter_queue_input_key integer not null PK
filter_queue_input_uuid uuid not null UK
filter_queue_key integer not null UK2
docset_key integer not null UK2
created_dttm timestamp without time zone not null
상기 표 27의 테이블 구조에 포함된 속성들의 구체적인 설명은 아래의 표 28과 같다.
속성 설명
Filter Queue Input UUID 필터 큐 입력에 대한 UUID로서, 필터 작업을 XDS 방식으로 처리할 때 사용된다.
Filter Queue 필터 큐를 지정한다.
DocSet 문서집합을 지정한다.
상술한 바와 같이 필터 큐에 작업을 수행할 필터의 정보들이 저장되면, 필터의 형태에 따라 다음과 같이 필터가 작업을 수행한다.
1) 내부필터는 데이터베이스의 작업 관리자(job manager)에 의해 작업을 수행한다. 데이터베이스 작업 관리자는 주기적으로 FilterQueue_execute() 함수를 호출하는데, 이 함수는 필터 큐의 내용 중에서 내부필터를 찾은 후 필터가 작업을 수행하여야 할 시간에 데이터베이스 작업 관리자가 해당 필터가 작업을 수행하도록 한다.
2) 외부필터는 FilterProc에 의해 작업을 수행한다. 여기에서, FilterProc 프로그램은 외부필터를 구현하기 위한 인터페이스 모듈을 의미한다. 이하, 도 6을 참조하여 외부 필터에 대하여 구체적으로 설명한다.
도 5는 본 발명의 일 실시예에 따른 외부 필터(541)의 일 예를 설명하기 위한 도면이다.
도 5를 참조하면, 클라우드(510) 및 클라우드(510)와 연결된 외부장치들(520, 530, 540)이 도시되어 있다. 이때, 클라우드(510)와 외부장치들(520, 530, 540)은 유선 또는 무선 통신에 의하여 서로 연결될 수 있다. 예를 들어, 클라우드(510)와 외부장치들(520, 530, 540)은 IHE XDS 또는 MHD 표준 프로토콜을 통하여 연결될 수 있으나, 이에 한정되지 않는다. 클라우드(510)와 외부장치들(520, 530, 540)이 연결되는 통신 프로토콜의 일 예는 도 6을 참조하여 후술한다.
외부장치는 다른 외부장치 또는 클라우드(510)와 통신이 가능한 장치라면 제한없이 해당될 수 있다. 예를 들어, 외부장치들(520, 530, 540) 각각은 환자에 대한 진단 정보를 획득하는 의료 장비, PC 또는 모바일 단말기 등이 해당 될 수 있으나, 이에 제한되지 않는다.
외부필터(541)는 외부장치들(520, 530, 540) 중 적어도 어느 하나에 포함될 수 있다. 이때, 외부필터(541)와 클라우드(510)는 FilterProc 프로그램을 통하여 작업을 송수신할 수 있다. FilterProc 프로그램은 지정된 Filter UID를 이용하여 자신이 처리해야 할 필터 작업들을 검색한 후 입력 문서집합들을 다운로드하고, 필터 처리를 수행한 후, 생성된 결과 문서들을 새로운 문서집합 형태로 구성하여 다시 업로드하는 역할을 한다. FilterProc 프로그램의 설정에 대해서는 도 6을 참조하여 후술한다.
도 6은 본 발명의 일 실시예에 따른 의료 정보 제공 시스템에서 사용되는 통신 프로토콜의 일 예를 설명하기 위한 도면이다.
도 6을 참조하면, 의료 정보 제공 시스템(600)에 포함된 클라우드(610) 및 외부장치들 각각에 설치된 프로그램(620, 630)의 일 예가 도시되어 있다. 여기에서, 프로그램(620, 630)은 유무선 통신을 통하여 클라우드(610)와 연결될 수 있는 프로그램이라면, 제한 없이 해당될 수 있다.
예를 들어, 생체 신호 정보(621)를 클라우드(610)로 전송하는 프로그램인 BioPump(620)와 클라우드(610)는 IHE(Integrating the Healthcare Enterprise) XDS (Cross-Enterprise Document Sharing) 또는 MHD (Mobile-access to Health Document) 프로토콜을 사용하여 통신할 수 있다. 구체적으로, BioPump(620)와 클라우드(610)의 통신에는 XDS Provide and Register Document Set 프로토콜 또는 MHD Put Document Dossier 프로토콜이 사용될 수 있다.
또한, Event Recorder에서 생체 신호 정보를 수신(622)하여 이를 클라우드(610)로 재전송해주는 Bioroid(630)에서는 모바일 환경에 특화된 IHE MHD 프로토콜이 사용될 수 있다. 여기에서, MHD 프로토콜은 XDS 프로토콜을 모바일 환경에 맞도록 간략화한 것을 의미한다.
클라우드(610)와 외부 필터(650, 660) 사이에서 사용되는 프로토콜 역시 IHE XDS 프로토콜이 될 수 있다. 구체적으로, 클라우드(610)와 외부 필터(650, 660)는 XDS Registry Stored Query, XDS Retrieve Document Set, XDS Provide and Register Document Set 프로토콜을 사용하여 통신할 수 있다.
본 발명의 일 실시예에 따른 의료 정보 제공 시스템(600)은 범용 통신 표준 프로토콜을 사용할 수 있다. 따라서, 의료 정보 제공 시스템(600)에서 사용되는 표준 프로토콜을 구현한 것이라면, 어떤 API이든 클라우드(610)와 연동이 가능하다.
외부장치에 설치된 프로그램(620, 630)이 XDS 또는 MHD 프로토콜을 이용하여 클라우드(610)와 통신할 때 사용되는 주요 키(Key) 값들의 일 예는 아래의 표 29 및 표 30과 같다.
XDS/MHD Document Entry
Key 설명
entryUUID 문서의 UUID로서, 전체적으로 완전히 고유하여야 한다. 최초 전송할 때에는 UUID 대신에 symbolic name을 사용할 수도 있다.
classCode 문서의 클래스 코드이다.
creationTime 문서의 생성 일시이다.
formatCode 문서의 포맷 코드이다.
mimeType 문서의 MIME 타입을 나타낸다.
patientId 환자번호를 나타낸다.
serviceStartTime 서비스가 시작된 시간을 나타낸다.
sourcePatientInfo 환자이름, 성별, 생년월일, 주소를 나타낸다.
title 문서의 제목이다.
typeCode 문서의 타입 코드이다.
uniqueId 문서의 UID로서, 그룹 내에서 고유하여야 한다.
XDS/MHD Submission Set
Key 설명
entryUUID 문서집합의 UUID로서, 전체적으로 완전히 고유하여야 한다. 최초 전송할 때에는 UUID 대신에 symbolic name을 사용할 수도 있다.
contentTypeCode 문서집합의 내용을 나타내는 코드로서, 내부적으로는 Document Set Class UID에 대응된다.
patientId 환자번호를 나타낸다.
sourceId 문서집합을 생성한 소스를 나타내는 것으로, 내부적으로는 Filter UID에 대응된다.
submissionTime 문서집합을 전송한 일시를 나타낸다.
title 문서집합의 제목이다.
uniqueId 문서집합의 UID로서, 그룹 내에서 고유하여야 한다.
IHE XDS/MHD 표준에서는 Document Entry, Submission Set, Folder, Association 객체를 이용하여 문서, 문서집합, 폴더 등을 구현하고 관계를 표현한다. 상기 객체들을 클라우드(610)에 저장하기 위한 데이터베이스 테이블 구조의 일 예는 아래의 표 31 내지 표 36과 같다.
Table "Document

Column Type Modifiers
--------------------------------------------------------------------------
document_key integer not null PK
vgroup_key integer not null FK, UK
document_uid character varying(64) not null UK
repository_uid character varying(64) not null UK location_type character varying(4)
location_root character varying(256)
location_path character varying(256)
document_size integer
document_hash character varying(256)
filter_key integer not null FK
patient_key integer FK
created_dttm timestamp without time zone not null
deleted_dttm timestamp without time zone
Table "XDSDocument

Column Type Modifiers
--------------------------------------------------------------------------
xds_document_key integer not null PK
document_key integer not null FK
metadata_xml xml
mime_type character varying(128) not null
document_uuid uuid not null UK
document_uid character varying(64) not null
repository_uid character varying(64) not null
document_status character varying(1) not null default 'A'
patient_id personid_t
source_patient_id personid_t
document_title character varying(128)
document_comments character varying(4000)
author_id personid_t
author_name character varying(64)
class_code codeinfo_t
format_code codeinfo_t
h_f_type_code codeinfo_t
language_code character varying(256)
practice_code codeinfo_t
type_code codeinfo_t
service_start_dttm timestamp without time zone
service_stop_dttm timestamp without time zone
created_dttm timestamp without time zone not null
deleted_dttm timestamp without time zone
patient_name character varying(256)
patient_sex character varying(1)
patient_birth_dttm timestamp without time zone
patient_address character varying(256)
Table "DocSet

Column Type Modifiers
--------------------------------------------------------------------------
docset_key integer not null PK
vgroup_key integer not null FK, UK
docset_uid character varying(64) not null UK
docset_class_uid character varying(64) not null FK
docset_group_uid character varying(64) not null
filter_key integer not null FK
patient_key integer FK
created_dttm timestamp without time zone not null
deleted_dttm timestamp without time zone
Table "XDSDocSet

Column Type Modifiers
--------------------------------------------------------------------------
xds_docset_key integer not null PK
docset_key integer not null FK
metadata_xml xml
docset_uuid uuid not null UK
docset_uid character varying(64) not null
source_id character varying(64) not null
patient_id personid_t
content_type_code codeinfo_t
docset_status character varying(1) not null default 'A'
docset_title character varying(128)
docset_comments character varying(4000)
submit_dttm timestamp without time zone
created_dttm timestamp without time zone not null
deleted_dttm timestamp without time zone
Table "XDSFolder

Column Type Modifiers
--------------------------------------------------------------------------
xds_folder_key integer not null PK
metadata_xml xml
folder_uuid uuid not null UK
folder_uid character varying(64) not null
patient_id personid_t
code_list codeinfo_t[]
folder_status character varying(1)
folder_title character varying(128)
folder_comments character varying(4000)
update_dttm timestamp without time zone
created_dttm timestamp without time zone not null
deleted_dttm timestamp without time zone
Table "XDSAssociation

Column Type Modifiers
--------------------------------------------------------------------------
xds_association_key integer not null PK
metadata_xml xml
association_uuid uuid not null UK
association_kind character varying(4) not null
association_type character varying(16) not null
source_uuid uuid not null
target_uuid uuid not null
created_dttm timestamp without time zone not null
상기 표 31 내지 표 36의 테이블들과 IHE XDS/MHD 객체들과의 대응 관계는 아래의 표 37 내지 표 40과 같다.
IHE XDS/MHD 클라우드 데이터베이스
DocumentEntry.entryUUID XDSDocument.document_uuid
DocumentEntry.uniqueId XDSDocument.document_uid
Document.document_uid
DocumentEntry.hash Document.hash
DocumentEntry.size Document.size
DocumentEntry.repositoryUniqueId XDSDocument.repository_uid
DocumentEntry.patientId XDSDocument.patient_id
Document.patient_key
Document.vgroup_key
DocumentEntry.mimeType XDSDocument.mime_type
DocumentEntry.status XDSDocument.document_status
DocumentEntry.title XDSDocument.document_title
DocumentEntry.comments XDSDocument.document_comments
DocumentEntry.author XDSDocument.author_id
XDSDocument.author_name
DocumentEntry.sourcePatientId XDSDocument.source_patient_id
DocumentEntry.sourcePatientInfo XDSDocument.patient_name
XDSDocument.patient_sex
XDSDocument.patient_birth_dttm
XDSDocument.patient_address
DocumentEntry.classCode XDSDocument.class_code
DocumentEntry.formatCode XDSDocument.format_code
DocumentEntry.healthcareFacilityTypeCode XDSDocument.h_f_type_code
DocumentEntry.languageCode XDSDocument.language_code
DocumentEntry.practiceSettingCode XDSDocument.practice_code
DocumentEntry.typeCode XDSDocument.type_code
DocumentEntry.creationTime XDSDocument.created_dttm
DocumentEntry.serviceStartTime XDSDocument.service_start_dttm
DocumentEntry.serviceStopTime XDSDocument.service_stop_dttm
Document Document.location_type
Document.location_root
Document.location_path
IHE XDS/MHD 클라우드 데이터베이스
SubmissionSet.entryUUID XDSDocSet.docset_uuid
SubmissionSet.uniqueId XDSDocSet.docset_uid
DocSet.docset_uid
SubmissionSet.patientId XDSDocSet.patient_id
DocSet.patient_key
DocSet.vgroup_key
SubmissionSet.sourceId XDSDocSet.source_id
DocSet.filter_key
SubmissionSet.contentTypeCode XDSDocSet.content_type_code
DocSet.docset_class_uid
SubmissionSet.status XDSDocSet.docset_staus
SubmissionSet.title XDSDocSet.docset_title
SubmissionSet.comments XDSDocSet.docset_comments
SubmissionSet.submissionTime XDSDocSet.submit_dttm
IHE XDS/MHD 클라우드 데이터베이스
Folder.entryUUID XDSFolder.folder_uuid
Folder.uniqueId XDSFolder.folder_uid
Folder.patientId XDSFolder.patient_id
Folder.status XDSFolder.folder_status
Folder.title XDSFolder.folder_title
Folder.comments XDSFolder.folder_comments
Folder.codeList XDSFolder.code_list
Folder.lastUpdateTime XDSFolder.update_dttm
IHE XDS/MHD 클라우드 데이터베이스
Association.uuid XDSAssociation.association_uuid
Association.sourceObject XDSAssociation.source_uuid
Association.targetObject XDSAssociation.target_uuid
Association.associationType XDSAssociation.association_type
HAS: hasMember
APND: append
RPLC: replace
XFRM: transform
XFRM_RPLC: transformWithReplace
SIGNS: signs
XDSAssociation.association_kind
SD: SubmissionSet - Original Document
SE: SubmissionSet - Existing Document
SF: SubmissionSet - Folder
FD: Folder - Document
DD: Document - Document
JS: FilterJob - SubmissionSet
JD: FilterJob - Document
한편, 외부필터(650, 660)는 총 5 단계들을 거쳐 작업을 수행한다. 외부필터(650, 660)가 작업을 수행하면서 거치는 5단계는 아래와 같다.
제 1 단계로, 외부필터(650, 660)에서 수행될 작업을 생성한다. 구체적으로, 필터 조건에 의하여 필터 작업이 필요한 경우, 클라우드(610)는 필터 큐(즉, 표 25 및 표 27에 기재된 테이블)에 각각 FilterQueue UUID, FilterQueueInput UUID를 생성한다.
제 2 단계로, 외부필터(650, 660)에서 수행될 작업을 검색한다. 예를 들어, 외부필터(650, 660)에서 수행될 작업의 검색은 XDS Registry Stored Query 방식을 확장하여 구현할 수 있다. 구체적으로, FindFilterJobs라고 하는 Stored Query는, 아래의 표 41과 같이, 필터 작업을 Association의 리스트 형태로 반환할 수 있다.
클라우드 데이터베이스 IHE XDS/MHD
FilterQueueInput.filter_queue_input_uuid Association.uuid
FilterQueue.filter_queue_uuid Association.sourceObject
XDSDocSet.docset_uuid Association.targetObject
제 3 단계로, 외부필터(650, 660)에서 수행될 작업 리스트를 준비한다. 예를 들어, 검색된 필터 작업들에 대한 Association 리스트는 FilterProc 내에서 아래의 표 42와 같이 FilterJob 리스트를 구성한다.
IHE XDS/MHD FilterProc.FilterJob
Association.uuid FilterJob.docsetList.subjobUUID
= FilterQueueInput . filter _ queue _ input _ uuid
Association.sourceObject FilterJob.jobUUID
= FilterQueue . filter _ queue _ uuid
Association.targetObject FilterJob.docsetList.docsetUUID
= XDSDocSet . docset _ uuid
여기에서, FilterProc 프로그램은 외부필터(650, 660)를 구현하기 위한 인터페이스 모듈을 의미한다. 다시 말해, FilterProc은 의료 정보 제공 시스템 상에서 동작하는 외부필터(650, 660)의 구현을 위해 필요한 것으로 특정 필터/문서집합에 대한 처리 방법을 지정한다. FilterProc은 지정된 서버, 포트 정보를 이용하여 클라우드에 접속한 후 설정 파일에 저장된 내용에 따라 지정된 동작을 수행한다.
만약, 설정 파일 이외에 추가로 지정된 쿼리 파일이 없으면, 설정 파일의 filterUID에서 지정된 필터의 역할을 하도록 특정된다. 만약, 추가로 지정된 쿼리 파일이 있을 경우, 쿼리 파일에서 지정한 내용으로 필터 처리를 수행한다.
FilterProc 설정 파일에서 사용할 수 있는 키 값들 및 이에 대한 설명은 아래의 표 43과 같다.
Key 설명
logLevel 로그 레벨을 나타내는 것으로 다음 값들 중의 하나를 지정한다.
OFF
ERROR
WARN
INFO (default)
DEBUG
serverHost 클라우드의 XDS/MHD 서버의 주소이다.
serverPort 클라우드의 XDS/MHD 서버의 포트번호이다.
workingDir 작업 디렉토리를 지정한다.
filenameFormat 다운로드할 문서들의 파일 이름을 지정하는 것으로 다음과 같은 키워드를 사용할 수 있다.
%uid: 문서의 UID로 치환된다.
%dttm: 문서의 생성일시로 치환된다.
%seq: 자동으로 부여되는 일련번호로 치환된다.
retrieveSetCount 문서를 다운로드할 때의 묶음 크기를 나타낸다. 클수록 HTTP 오버헤드는 줄어들지만 너무 크면 버퍼 용량 초과로 다운로드 자체가 실패할 수 있다. 기본값은 1이다.
preprocessor 문서집합을 모두 다운로드한 후 전처리가 필요할 때 지정하는 것으로 다음과 같은 키워드를 사용할 수 있다.
%inDocSetDir: 입력 문서집합의 폴더 이름으로 치환된다.
%inDocSetPathList: 입력 문서집합 내에 포함된 모든 문서 파일들의 전체 경로명 리스트로 치환된다.
%inDocSetFileList: 입력 문서집합 내에 포함된 모든 문서들의 파일 이름 리스트로 치환된다.
%outDocSetDir: 출력 문서집합의 폴더 이름으로 치환된다.
processor 문서 또는 문서집합을 대상으로 호출되는 외부 처리기의 경로명 및 인자들을 지정하는 것으로 위의 preprocessor에서 지정된 키워드 이외에 다음과 같은 키워드를 추가로 사용할 수 있다.
%inDocFile: 개별 입력 문서의 파일 이름으로 치환된다.
%inJobDir: 필터 처리를 위해 2개 이상의 입력 문서집합이 필요한 경우 전체 작업 폴더의 이름으로 치환된다.
%inJobPathList: 작업 폴더 내에 포함된 모든 입력 문서 파일들의 전체 경로명 리스트로 치환된다.
%inJobFileList: 작업 폴더 내에 포함된 모든 입력 문서들의 파일 이름 리스트로 치환된다.
%outDocFile: 개별 출력 문서 파일의 이름으로 치환된다.
%outJobDir: 출력 작업 폴더의 이름으로 치환된다.
postprocessor 문서집합의 처리가 모두 완료된 후 후처리가 필요할 때 지정하는 것으로 사용할 수 있는 키워드는 preprocessor에서와 같다.
filterUID 필터의 UID를 지정한다.
UIDPrefix 메타데이터를 위해 생성되는 UID들을 위한 접두어를 의미한다.
groupIdType Group Id Type을 나타내는 것으로 특별한 사유가 없는 한 BIS-Cloud에서는 “BIS-CLOUD”를 사용하도록 한다.
docsetClassUID 생성된 문서집합들을 위한 클래스 UID 값을 의미한다.
docsetTitle 생성된 문서집합들에 대한 기본 제목이다.
docsetComments 생성된 문서집합들에 대한 기본 설명이다.
mimeType 생성된 문서를 업로드할 때 필요한 MIME 타입이다.
rename 작업에 사용된 문서들을 이동할지 삭제할지 지정한다. 이동하려면 true를, 삭제하려면 false를 지정한다. 기본값은 false(삭제)이다.
repeat 반복 여부를 지정한다. 기본값은 false(반복없음)이다.
repeatInterval 반복 주기를 지정한다. 예를 들어, 300(초)로 지정될 수 있다.
FilterProc은 workingDir로 지정된 폴더 아래에 표 47과 같은 구조로 작업 폴더를 생성한다. FilterProc은 작업 폴더의 내용들이 추후 삭제되도록 지정할 수 있다.
Folder / Filename 설명
{workingDir}/FJ-xxxx 입력 작업 폴더
{workingDir}/FJ-xxxx/output 출력 작업 폴더
{workingDir}/FJ-xxxx/DS-yyyy 입력 문서집합 폴더
{workingDir}/FJ-xxxx/DS-yyyy/output 출력 문서집합 폴더
{workingDir}/FJ-xxxx/DS-yyyy/zzzz 입력 문서 파일
{workingDir}/FJ-xxxx/DS-yyyy/zzzz.xml 입력 문서 메타데이터 (XDS Document Entry)
{workingDir}/FJ-xxxx/DS-yyyy/zzzz.output 출력 문서 파일
{workingDir}/FJ-xxxx/DS-yyyy/DS.xml 입력 문서집합 메타데이터 (XDS Submission Set)
제 4 단계로, 외부필터(650, 660)는 작업의 수행 결과를 클라우드(610)로 전송한다. 이때, 외부필터(650, 660)는 작업의 수행 결과인 문서집합을 클라우드(610)로 전송하기 전에, 아래의 표 45와 같은 Association 정보를 전송한다.
FilterProc.FilterResult IHE XDS/MHD
Auto - generated Association.uuid
Created XDSDocSet.docset_uuid 또는 XDSDocument.document_uuid Association.sourceObject
FilterJob.docsetList.subjobUUID
= FilterQueueInput . filter _ queue _ input _ uuid 		Association.targetObject
APND Association.associationType
“FilterJobStatus” Association.slotName
“SubmissionSet” 또는 “DocumentEntry” Association.slotValue
제 5 단계로, 외부필터(650, 660)는 작업의 수행을 완료한다. 본 발명의 일 실시예에 따른 클라우드(610)의 XDSServer는 보통의 DocumentEntry, SubmissionSet, Folder 및 Association 객체들을 데이터베이스에 저장하기 전에 Association.slotName=”FilterJobStatus”인 Association 들을 먼저 데이터베이스에 저장한다. 이때, Association.slotValue에 따라 XDSAssociation 테이블의 association_kind 컬럼 값이 결정된다. 그러면, XDSServer는 이러한 Association 객체의 속성들을 데이터베이스에 저장함과 동시에 최종적으로 FilterQueue_update() 함수를 호출하여 필터 작업 완료를 기록한다. 일 예는 아래의 표 46과 같다.
IHE XDS/MHD 클라우드 데이터베이스
Association.uuid XDSAssociation.association_uuid
Association.sourceObject
= Created XDSDocSet . docset _ uuid / XDSDocument . document _ uuid 		XDSAssociation.source_uuid
Association.targetObject
= FilterJob . docsetList . subjobUUID
= FilterQueueInput . filter _ queue _ input _ uuid 		XDSAssociation.target_uuid
Association.associationType
= “ APND ” 		XDSAssociation.association_type
Association.slotName
= “ FilterJobStatus ”
Association.slotValue
= “ SubmissionSet ”
= “ DocumentEntry ” 		XDSAssociation.association_kind
JS (FilterJob - SubmissionSet)
JD (FilterJob - Document)
HolterCDSS(650)는 클라우드(610) 내에 구현된 외부 필터의 하나로서 클라우드(610)로부터 라디오넷 홀터 파일을 다운로드한 후 CDSS(Clinical Decision Supporting System) 처리를 수행하도록 HolterExport.exe 또는 Holter.exe 프로그램을 수행한다. 그리고, HolterCDSS(650)는 프로그램의 수행 결과로 생성된 JPEG 형태의 자동진단 결과 파일들을 다시 클라우드(650)에 업로드하는 역할을 한다.
HolterCDSS(650)는 FilterProc에 기반하여 작성된 일괄처리 파일(batch file)로서, 구체적으로는 클라우드와 통신을 담당하는 FilterProc.jar 모듈 및 실제 CDSS 처리를 담당하는 HolterExport.exe 또는 Holter.exe 모듈로 구성된다.
본 발명의 일 실시예에 따른 HolterCDSS(650)의 구성 예 및 설정 예는 각각 아래의 표 47 및 표 48과 같다.
구성: HolterCDSS.bat
@ECHO OFF

SET BIS_DIR=C:\OPHIES
SET LIB_DIR=%BIS_DIR%\lib
SET CONFIG_FILE=%BIS_DIR%\bin\HolterCDSS . conf

java -jar %LIB_DIR%\FilterProc.jar -conf %CONFIG_FILE% %1
설정 예제: HolterCDSS.conf
{
"FilterProc" : {
"logLevel" : "INFO",

"serverHost" : "54.238.177.162",
"serverPort" : "8080",

"workingDir" : "C:/OPHIES/work",
"filenameFormat" : "%uid",
"retrieveSetCount" : "3",

"preprocessor" : "",
" processor " : "\"C:\\ Program Files \\ RADIONET \\ Holter \\ Holter . exe \" -hrw2jpg % inDocFile % outJobDir ",
"postprocessor" : "",

" filterUID " : "1.2.410.200054.4.2.1",
"UIDPrefix" : "1.2.410.200054",
"groupIdType" : "BIS-CLOUD",
"docsetClassUID" : "1.2.410.200054.5.2.1",
"docsetTitle" : "HolterExport Results",
"docsetComments" : "%cmdline",
"mimeType" : "image/jpeg",

"rename" : "false",

"repeat" : "true",
"repeatInterval" : "60",
}
}
EventMerge(660)는 클라우드(610)를 위해 구현된 외부 필터의 하나로서, 클라우드(610) 내에 저장된 Event Recorder 신호 파일들을 다운로드한 후 이를 통합, 변환하여 Holter.exe 프로그램에 입력으로 전달한다.
EventMerge(660)는 FilterProc에 기반하여 작성된 일괄처리 파일(batch file)이며, 구체적으로는 Event Recorder 신호 파일들을 통합하기 위한 전처리기(preprocessor)인 EventBuild.jar와 실제 홀터 정보를 처리하는 Holter.exe로 구성되어 있다.
EventMerge(660) 수행을 위해서는 반드시 아래 예제에서와 같은 쿼리 파일을 생성하여 인자로 전달해 주어야 한다. 이때, queryType은 GetSubmissionSetAndContents로 지정하여야 하고, docsetUID에는 통합할 Event Recorder 파일들을 담고 있는 문서집합의 UID를 지정해 주어야 한다. 이러한 쿼리 파일들은 웹 브라우저(640)의 문서집합 리스트 상에서 다운로드하여 얻을 수 있다.
본 발명의 일 실시예에 따른 EventMerge(660)의 구성 예 및 설정 예는 각각 아래의 표 49 및 표 50과 같다.
구성: EventMerge.bat
@ECHO OFF

SET BIS_DIR=D:\OPHIES
SET LIB_DIR=%BIS_DIR%\lib
SET CONFIG_FILE=%BIS_DIR%\bin\EventMerge . conf

java -jar %LIB_DIR%\FilterProc.jar -conf %CONFIG_FILE% %1
설정 예제: EventMerge.conf
{
"FilterProc" : {
"logLevel" : "INFO",

"serverHost" : "54.238.177.162",
"serverPort" : "8080",

"workingDir" : "D:/Temp",
"filenameFormat" : "%dttm.raw",
"retrieveSetCount" : "3",

" preprocessor " : " java - jar D:/ OPHIES / lib / EventBuild . jar %inDocSetDir",
" processor " : "\"C:\\ Program Files \\ RADIONET \\ Holter \\ Holter . exe \" -evt % inDocSetDir ",

"rename" : "false",
}
}
도 7은 본 발명의 일 실시예에 따른 대상체의 의료 정보를 생성하는 장치(700)의 일 예를 나타내는 구성도이다.
도 7을 참조하면 대상체의 의료 정보를 생성하는 장치(700)는 인터페이스부(710), 필터 선택부(720) 및 복수의 내부 필터들(731, 732, 733)을 포함한다. 또한, 필터들 중 적어도 하나 이상은 장치(700)에 포함되지 않은 외부 필터(734)로 존재할 수 있다. 도 7에 도시된 장치(700)에는 본 실시예와 관련된 구성요소들만이 도시되어 있다. 따라서, 도 7에 도시된 구성요소들 외에 다른 범용적인 구성요소들이 더 포함될 수 있음을 본 실시예와 관련된 기술분야에서 통상의 지식을 가진 자라면 이해할 수 있다.
또한, 도 7에 도시된 장치(700)에 포함된 인터페이부(710), 필터 선택부(720)는 하나 또는 복수 개의 프로세서에 해당할 수 있다. 프로세서는 다수의 논리 게이트들의 어레이로 구현될 수도 있고, 범용적인 마이크로 프로세서와 이 마이크로 프로세서에서 실행될 수 있는 프로그램이 저장된 메모리의 조합으로 구현될 수도 있다. 또한, 다른 형태의 하드웨어로 구현될 수도 있음을 본 실시예가 속하는 기술분야에서 통상의 지식을 가진 자라면 이해할 수 있다.
또한, 도 7에 도시된 장치(700)는 도 1, 도 2, 도 5 및 도 6에 도시된 의료 정보 제공 시스템 또는 클라우드에 포함될 수 있다. 따라서, 이하에서 생략된 내용이라 하더라도 도 1, 도 2, 도 5 및 도 6에 도시된 의료 정보 제공 시스템 또는 클라우드에 관하여 이상에서 기술된 내용은 도 7의 장치(700)에도 적용됨을 알 수 있다.
인터페이스부(710)는 클라우드와 연결된 외부 장치들 중 적어도 어느 하나로부터 적어도 하나 이상의 컨텐츠를 수신한다. 여기에서, 컨텐츠는 텍스트, 이미지, 동영상을 포함하는 모든 종류의 문서(document)를 의미한다. 다시 말해, 컨텐츠는 영상(image), 파형(waveforms), 측정값(measured values) 등 일반적인 연산 장치에서 처리될 수 있는 모든 종류의 문서를 포함한다. 도 1 내지 도 6을 참조하여 상술한 내용에서는 컨텐츠를 문서와 동일한 개념으로 표현하였다.
필터 선택부(720)는 복수의 필터 클래스들 각각에 포함된 필터들 중에서 인터페이스부(710)가 수신한 컨텐츠에 기반하여 기 설정된 작업을 수행하는 필터를 선택한다. 여기에서, 필터 클래스는 필터의 클래스를 의미하며, 문서집합 클래스에 의해 입출력 형식을 표현한다. 하나의 필터 클래스는 다수의 필터에 대응될 수 있다. 즉, 동일한 입출력 형식 및 기능을 갖는 다양한 필터가 존재할 수 있다.
또한, 필터의 종류에는 내부 필터 또는 외부 필터가 있다. 내부 필터는 클라우드의 데이터베이스 내에서 작업을 수행하는 필터를 의미하며, 하부 구조의 데이터베이스의 저장 함수(stored function)으로 구현될 수 있다. 한편, 외부 필터는 클라우드 데이터베이스 외부에서 작업을 수행하는 필터를 의미하며, 클라우드가 제공하는 API를 이용하여 구현될 수 있다.
필터 선택부(720)에 의하여 선택된 필터가 수행하는 기 설정된 작업은 입력 컨텐츠가 출력 컨텐츠로 변환되는 작업, 클라우드와 연결된 장치들 중 적어도 어느 하나에 컨텐츠가 제공되는 작업, 서로 다른 두 컨텐츠들을 조합함으로써 새로운 컨텐츠를 생성하는 작업 및 컨텐츠를 저장하는 작업 중 어느 하나를 의미한다. 여기에서, 컨텐츠가 제공되는 장치는 제공된 컨텐츠를 디스플레이하는 장치 등 컨텐츠를 다양한 방법으로 소비하는 장치를 의미한다.
또한, 필터 선택부(720)는 복수의 필터 클래스들 각각에 포함된 필터들 중에서 기 설정된 작업의 수행 결과에 기반하여 작업을 수행하는 필터를 선택할 수 있다. 다시 말해, 도 4를 참조하여 전술한 워크플로우와 같이, 필터 선택부(720)는 일 필터에 의하여 작업이 수행된 결과를 이용하여 다른 작업을 수행하는 다른 필터를 선택할 수 있다.
한편, 내부 필터들(731, 732, 733) 및 외부 필터(734)들 각각은 필터의 동작에 요구되는 정보 및/또는 필터가 동작을 수행하는 시점에 대응하는 시간 조건이 설정된다. 여기에서, 시간 조건은 필터에 정보가 입력되는 때에 필터가 동작을 수행하는 조건, 정보가 입력된 후 소정의 시간이 경과된 후에 필터가 동작을 수행하는 조건 및 정보가 입력된 익일 0 시를 기준으로 일정 시간이 경과된 경우에 필터가 동작을 수행하는 조건 중 어느 하나가 해당될 수 있다.
도 8은 본 발명의 일 실시예에 따른 대상체의 의료 정보를 생성하는 방법의 일 예를 나타내는 흐름도이다.
도 8을 참조하면, 필터에 대한 정보를 생성하는 방법은 도 1, 도 2, 도 5, 도 6 및 도 7에 도시된 의료 정보 제공 시스템, 클라우드 또는 대상체의 의료 정보를 생성하는 장치(700)에서 시계열적으로 처리되는 단계들로 구성된다. 따라서, 이하에서 생략된 내용이라 하더라도 도 1, 도 2, 도 5, 도 6 및 도 7을 참조하여 이상에서 기술된 내용은 도 8의 대상체의 의료 정보를 생성하는 방법에도 적용됨을 알 수 있다.
810 단계에서, 클라우드는 클라우드와 연결된 외부 장치들 중 적어도 어느 하나로부터 적어도 하나 이상의 컨텐츠를 수신한다.
820 단계에서, 클라우드는 복수의 필터 클래스들 각각에 포함된 필터들 중 수신된 컨텐츠에 기반하여 작업을 수행하는 필터를 선택한다.
830 단계에서, 선택된 필터는 기 설정된 작업을 수행한다.
한편, 상술한 방법은 컴퓨터에서 실행될 수 있는 프로그램으로 작성 가능하고, 컴퓨터로 읽을 수 있는 기록매체를 이용하여 상기 프로그램을 동작시키는 범용 디지털 컴퓨터에서 구현될 수 있다. 또한, 상술한 방법에서 사용된 데이터의 구조는 컴퓨터로 읽을 수 있는 기록매체에 여러 수단을 통하여 기록될 수 있다. 상기 컴퓨터로 읽을 수 있는 기록매체는 마그네틱 저장매체(예를 들면, 롬, 램, USB, 플로피 디스크, 하드 디스크 등), 광학적 판독 매체(예를 들면, 시디롬, 디브이디 등)와 같은 저장매체를 포함한다.
본 실시예와 관련된 기술 분야에서 통상의 지식을 가진 자는 상기된 기재의 본질적인 특성에서 벗어나지 않는 범위에서 변형된 형태로 구현될 수 있음을 이해할 수 있을 것이다. 그러므로 개시된 방법들은 한정적인 관점이 아니라 설명적인 관점에서 고려되어야 한다. 본 발명의 범위는 전술한 설명이 아니라 특허청구범위에 나타나 있으며, 그와 동등한 범위 내에 있는 모든 차이점은 본 발명에 포함된 것으로 해석되어야 할 것이다.
100: 의료 정보 제공 시스템
110: 클라우드
120: 서비스
130: 사용자

Claims (19)

  1. 대상체의 의료 정보를 생성하는 방법에 있어서,
    클라우드와 연결된 외부 장치들 중 적어도 어느 하나로부터 적어도 하나 이상의 제 1 컨텐츠를 수신하는 단계;
    복수의 필터 클래스들 각각에 포함된 필터들 중에서 상기 제 1 컨텐츠에 기반하여 작업을 수행하는 제 1 필터를 선택하는 단계; 및
    상기 제 1 필터에 의하여 기 설정된 작업을 수행하는 단계;를 포함하는 방법.
  2. 제 1 항에 있어서,
    상기 기 설정된 작업은 상기 제 1 컨텐츠가 제 2 컨텐츠로 변환되는 제 1 작업, 상기 클라우드와 연결된 장치들 중 적어도 어느 하나에 상기 제 1 컨텐츠가 제공되는 제 2 작업, 상기 제 1 컨텐츠와 제 3 컨텐츠를 조합함으로써 제 4 컨텐츠를 생성하는 제 3 작업 및 상기 제 1 컨텐츠를 저장하는 제 4 작업 중 어느 하나를 포함하는 방법.
  3. 제 2 항에 있어서,
    상기 제 1 컨텐츠 내지 제 4 컨텐츠는 텍스트, 이미지, 동영상, 파형 및 일반 문서 중 어느 하나인 방법.
  4. 제 1 항에 있어서,
    상기 복수의 필터 클래스들 각각에 포함된 필터들 중에서 상기 기 설정된 작업의 수행 결과에 기반하여 작업을 수행하는 제 2 필터를 선택하는 단계; 및
    상기 제 2 필터에 의하여 상기 제 2 필터에 기 설정된 작업을 수행하는 단계;를 더 포함하는 방법.
  5. 제 1 항에 있어서,
    상기 필터 클래스는 동일한 유형의 작업을 수행하는 필터들이 포함된 그룹을 의미하는 방법.
  6. 제 4 항에 있어서,
    상기 제 1 필터 및 상기 제 2 필터는 상기 제 1 필터 및 상기 제 2 필터 각각의 동작에 요구되는 정보 및/또는 상기 제 1 필터 및 상기 제 2 필터 각각이 상기 동작을 수행하는 시점에 대응하는 시간 조건이 설정된 필터인 방법.
  7. 제 4 항에 있어서,
    상기 제 1 필터 및 상기 제 2 필터 각각은 상기 클라우드의 내부에서 동작하는 내부 필터 또는 상기 외부 장치들 중 적어도 어느 하나에서 동작하는 외부 필터인 방법.
  8. 제 7 항에 있어서,
    상기 외부 필터는 상기 클라우드로부터 상기 외부 필터에서 수행될 작업 리스트를 수신하고, 상기 작업 리스트에 포함된 적어도 하나 이상의 작업의 수행 결과를 상기 클라우드로 전송하는 필터인 방법.
  9. 제 8 항에 있어서,
    상기 작업 리스트는 상기 클라우드가 상기 외부 필터에서 수행될 작업을 생성하고, 상기 생성된 작업을 상기 클라우드가 데이터베이스에서 검색함으로써 구성되는 방법.
  10. 제 1 항 내지 제 9 항 중 어느 한 항의 방법을 컴퓨터에서 실행시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록매체.
  11. 대상체의 의료 정보를 생성하는 클라우드 시스템에 포함된 장치에 있어서,
    상기 클라우드와 연결된 외부 장치들 중 적어도 어느 하나로부터 적어도 하나 이상의 제 1 컨텐츠를 수신하는 인터페이스부; 및
    복수의 필터 클래스들 각각에 포함된 필터들 중에서 상기 제 1 컨텐츠에 기반하여 기 설정된 작업을 수행하는 제 1 필터를 선택하는 필터 선택부;를 포함하는 장치.
  12. 제 11 항에 있어서,
    상기 기 설정된 작업은 상기 제 1 컨텐츠가 제 2 컨텐츠로 변환되는 제 1 작업, 상기 클라우드와 연결된 장치들 중 적어도 어느 하나에 상기 제 1 컨텐츠가 디스플레이되는 제 2 작업, 상기 제 1 컨텐츠와 제 3 컨텐츠를 조합함으로써 제 4 컨텐츠를 생성하는 제 3 작업 및 상기 제 1 컨텐츠를 저장하는 제 4 작업 중 어느 하나를 포함하는 장치.
  13. 제 12 항에 있어서,
    상기 제 1 컨텐츠 내지 제 4 컨텐츠는 텍스트, 이미지, 동영상, 파형 및 일반 문서 중 어느 하나인 방법.
  14. 제 11 항에 있어서,
    상기 필터 선택부는 상기 복수의 필터 클래스들 각각에 포함된 필터들 중에서 상기 기 설정된 작업의 수행 결과에 기반하여 작업을 수행하는 제 2 필터를 선택하고,
    상기 제 2 필터는 상기 제 2 필터에 기 설정된 작업을 수행하는 장치.
  15. 제 11 항에 있어서,
    상기 필터 클래스는 동일한 유형의 작업을 수행하는 필터들이 포함된 그룹을 의미하는 장치.
  16. 제 14 항에 있어서,
    상기 제 1 필터 및 상기 제 2 필터는 상기 제 1 필터 및 상기 제 2 필터 각각의 동작에 요구되는 정보 및/또는 상기 제 1 필터 및 상기 제 2 필터 각각이 상기 동작을 수행하는 시점에 대응하는 시간 조건이 설정된 필터인 장치.
  17. 제 14 항에 있어서,
    상기 제 1 필터 및 상기 제 2 필터 각각은 상기 클라우드의 내부에서 동작하는 내부 필터 또는 상기 외부 장치들 중 적어도 어느 하나에서 동작하는 외부 필터인 장치.
  18. 제 17 항에 있어서,
    상기 외부 필터는 상기 클라우드로부터 상기 외부 필터에서 수행될 작업 리스트를 수신하고, 상기 작업 리스트에 포함된 적어도 하나 이상의 작업의 수행 결과를 상기 클라우드로 전송하는 필터인 장치.
  19. 제 18 항에 있어서,
    상기 작업 리스트는 상기 클라우드가 상기 외부 필터에서 수행될 작업을 생성하고, 상기 생성된 작업을 상기 클라우드가 데이터베이스에서 검색함으로써 구성되는 장치.
KR1020140109954A 2014-03-10 2014-08-22 대상체의 의료 정보를 생성하는 방법 및 장치. KR102382313B1 (ko)

Priority Applications (3)

Application Number Priority Date Filing Date Title
PCT/KR2015/001851 WO2015137646A1 (ko) 2014-03-10 2015-02-26 대상체의 의료 정보를 생성하는 방법 및 장치
US15/111,830 US20160350485A1 (en) 2014-03-10 2015-02-26 Method and apparatus for generating medical information of object
US17/308,513 US11901075B2 (en) 2014-03-10 2021-05-05 Method and apparatus for generating medical information of object

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR1020140027953 2014-03-10
KR20140027953 2014-03-10

Publications (2)

Publication Number Publication Date
KR20150105900A true KR20150105900A (ko) 2015-09-18
KR102382313B1 KR102382313B1 (ko) 2022-04-04

Family

ID=54244976

Family Applications (3)

Application Number Title Priority Date Filing Date
KR1020140109953A KR101633911B1 (ko) 2014-03-10 2014-08-22 대상체의 의료 정보를 생성하는 방법 및 장치.
KR1020140109954A KR102382313B1 (ko) 2014-03-10 2014-08-22 대상체의 의료 정보를 생성하는 방법 및 장치.
KR1020160030267A KR101945993B1 (ko) 2014-03-10 2016-03-14 대상체의 의료 정보를 생성하는 방법 및 장치.

Family Applications Before (1)

Application Number Title Priority Date Filing Date
KR1020140109953A KR101633911B1 (ko) 2014-03-10 2014-08-22 대상체의 의료 정보를 생성하는 방법 및 장치.

Family Applications After (1)

Application Number Title Priority Date Filing Date
KR1020160030267A KR101945993B1 (ko) 2014-03-10 2016-03-14 대상체의 의료 정보를 생성하는 방법 및 장치.

Country Status (2)

Country Link
US (2) US20160350485A1 (ko)
KR (3) KR101633911B1 (ko)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107358691A (zh) * 2017-06-27 2017-11-17 苏州美天网络科技有限公司 一种基于app的病患住院管理系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001290890A (ja) * 2000-04-04 2001-10-19 Terumo Corp 医療情報検索システム及びその制御方法、記憶媒体
JP2012226632A (ja) * 2011-04-21 2012-11-15 Seikatsu Kyodo Kumiai Coop Sapporo 患者情報提供サーバ、及び患者情報提供処理プログラム
KR20130062446A (ko) * 2011-11-23 2013-06-13 건국대학교 산학협력단 의료용 단말기를 통한 의료정보 처리 시스템 및 그 방법

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002083058A (ja) 2000-09-06 2002-03-22 Yokogawa Electric Corp 広域医療情報システム
JP2004113730A (ja) 2002-09-25 2004-04-15 Terarikon Inc コンピュータ読影支援システム
JP2010267042A (ja) 2009-05-14 2010-11-25 Konica Minolta Medical & Graphic Inc 医療データ管理システム
US8712120B1 (en) * 2009-09-28 2014-04-29 Dr Systems, Inc. Rules-based approach to transferring and/or viewing medical images
KR20110055921A (ko) * 2009-11-20 2011-05-26 어울림엘시스 주식회사 온라인상의 개인정보 보호 시스템 및 이 시스템을 이용한 개인정보 보호 방법
US9251295B2 (en) * 2011-08-31 2016-02-02 International Business Machines Corporation Data filtering using filter icons
US9639615B1 (en) * 2012-06-28 2017-05-02 Open Text Corporation Systems and methods for health information messages archiving
JP6075833B2 (ja) 2012-08-09 2017-02-08 キヤノン株式会社 医用情報処理装置、医用情報処理方法及びプログラム
US9218569B2 (en) * 2013-03-14 2015-12-22 Siemens Aktiengesellschaft Rules-based management system and method for processing medical information
US10033702B2 (en) * 2015-08-05 2018-07-24 Intralinks, Inc. Systems and methods of secure data exchange

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001290890A (ja) * 2000-04-04 2001-10-19 Terumo Corp 医療情報検索システム及びその制御方法、記憶媒体
JP2012226632A (ja) * 2011-04-21 2012-11-15 Seikatsu Kyodo Kumiai Coop Sapporo 患者情報提供サーバ、及び患者情報提供処理プログラム
KR20130062446A (ko) * 2011-11-23 2013-06-13 건국대학교 산학협력단 의료용 단말기를 통한 의료정보 처리 시스템 및 그 방법

Also Published As

Publication number Publication date
US20160350485A1 (en) 2016-12-01
KR101945993B1 (ko) 2019-02-08
KR20150105899A (ko) 2015-09-18
KR102382313B1 (ko) 2022-04-04
KR20160034877A (ko) 2016-03-30
US20210257098A1 (en) 2021-08-19
US11901075B2 (en) 2024-02-13
KR101633911B1 (ko) 2016-06-27

Similar Documents

Publication Publication Date Title
US11410753B2 (en) System and methods of capturing medical imaging data using a mobile device
US9961158B2 (en) System and methods of managing content in one or more networked repositories during a network downtime condition
US8407244B2 (en) Management of virtual packages of medical data in interconnected content-addressable storage systems
EP3631644B1 (en) Universal data scaffold based data management platform
US9646394B2 (en) Case data visualization application
US20110153351A1 (en) Collaborative medical imaging web application
US11515016B2 (en) Rule-based low-latency delivery of healthcare data
US20140317552A1 (en) Metadata Templates for Electronic Healthcare Documents
US9826054B2 (en) System and methods of pre-fetching content in one or more repositories
JP2011203964A (ja) 文書管理システム及び方法
US11901075B2 (en) Method and apparatus for generating medical information of object
US20180189446A1 (en) System and Methods of Capturing Medical Imaging Data Using a Mobile Device
US20230237116A1 (en) Web-based medical image viewer with web database
Wollatz et al. Curation of image data for medical research
US20210158938A1 (en) Enhanced Enterprise Image Reading with Search and Direct Streaming
EP3011488B1 (en) System and methods of managing content in one or more repositories
US20230128299A1 (en) Cloud server, computer readable medium, and cloud system
US11243974B2 (en) System and methods for dynamically converting non-DICOM content to DICOM content
WO2024065061A1 (en) Healthcare record virtualization
Yuan et al. An architecture for cross-hospital access to electrocardiogram data

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
AMND Amendment
E601 Decision to refuse application
AMND Amendment
X701 Decision to grant (after re-examination)
GRNT Written decision to grant