8. 목표 시스템 [복구] · CCM분석및 환경/지식추가 분석 엔진 확장/튜닝...

개발 관리

개정 이력(전체)개정일 개정 분야 개정 내용 개정자 담당자

3개 사이트 지원 서비스 인터페이스를 위한 병원 환경 조사

3개 사이트 지원 서비스 인터페이스 시나리오 정의

저장소 초기 요구사항 정의

검증기 초기 요구사항 정의

저장소 유스케이스 모델 및 요구사항 명세서 정리

3개 사이트 지원 서비스 인터페이스 방안 정의

약물 상호 작용에 대한 요구 사항 2개 추가

3개 사이트 지원 스키마 매핑 애플리케이션 요구사항 1개 추가

저장소 WBS 추가

검증기 WSB 재작성

3개 사이트 지원 약물 상호 작용추가 요구사항 수용 방안 설계

3개 사이트 지원 진단 검사 용어 매핑 사례

3개 사이트 지원 A대 병원 지원 방안

저장소 Oss 목록 및 아키텍처 추가

검증기 1차 요구사항 (개념, 범위) 정의

DIA 인터페이스 XML 사용을 위한 NET 용 API 추가개발

저장소 접근법에 대한 재고찰-기술 아키텍처에 이슈 수정- WBS 수정

개정 이력(전체)개정일 개정 분야 개정 내용 개정자 담당자 비고

저장소 Samson 미팅 후, 아키텍처에 반영(Change control 추가)

저장소 프로테제 collaboration 버전 분석

3개 사이트 지원 -변환기 약물 상호작용에 대한 요구사항 1개 추가-논의 사항 추가

3개 사이트 지원 스트레스 테스트를 위한 아키텍처

3개 사이트 지원 스트레스 테스트 처리 방법 결론(회의 결과)

3개 사이트 지원 –변환기 기 처방 정보 처리는 필요 없음(결론)

3개 사이트 지원 –엔진 DUR 중복성 처리(추후 일정을 고려하여 처리)

3개 사이트 지원-변환기 DDI 서비스 방법 정의 및 중복성 처리 개발

3개 사이트 지원-인터페이스 모듈

B대 특화 요구사항 지원을 위하여인터페이스 모듈 수정

3개 사이트 지원

개정 이력

개정일 개정 내용 개정자 확인자

서비스 인터페이스를 위한 병원 환경 조사

서비스 인터페이스 시나리오 정의

서비스 인터페이스 방안 정의

약물 상호 작용에 대한 요구 사항 2개 추가

스키마 매핑 애플리케이션 요구사항 1개 추가

약물 상호 작용추가 요구사항 수용 방안 설계

진단 검사 용어 매핑 사례

A 병원 지원 방안

약물 상호 작용에 대한 요구 사항 1개 추가-조교수님 논의 사항 추가

B대 스트레스 테스트 아키텍처 수립

스트레스 테스트 처리 방법 결론(회의 결과)

기 처방 정보 처리는 필요 없음(결론)

DUR 중복성 처리(추후 일정을 고려하여 처리)

CCM

CDSS화면

EMR 화면

진단검사 DDI

…폐렴예방

약물 DBEMR DB

EMR DB

SIACDSS화면

EMR 화면

CDSS화면

EMR 화면

SIA

DIA

SIA

DIA

SIA LIS APPLIS APP

DDI APPDDI APP

폐렴 예방APP

폐렴 예방APP

KEIKEI

SIA: 서비스 인터페이스

DIA: 데이터 인터페이스

KEI: 지식 엔진 인터페이스

U-BRAIN

2009-05-08

실행 흐름도(개요)

EMR 화면 OOO APPOOO APP EMR DB

CDSS요청

CDSS요청

추가 입력

지식 실행

지식 검색

[필요시] 데이터 요청

결과반환

결과반환

피드백입력

피드백 저장

U-BRAIN 저장소

2009-05-08

실행 흐름도

EMR 화면 SIA DIAOOO APPOOO APP KEI EMR DB

CDSS요청

CDSS요청

CDSS화면CDSS 실행

생성추가 입력

CDSS 실행CDSS 실행

지식 실행

지식 실행지식 검색

[필요시] 데이터 요청데이타검색결과반환

결과반환결과반환

결과반환피드백입력

피드백 저장피드백 저장

U-BRAIN 저장소

2009-05-08

사이트 지원 프로세스

지식 저작

지식 변환

Application 개발

지식 실행Application

운영

검증

지식/환경분석

가변적 요소

- 저작 환경- 변환기 활용여부- 지식 엔진 활용 범위

변환기 확장

DIA 확장

추가 변환대상 식별

CCM 분석 및환경 /지식추가

분석

엔진확장/튜닝

C병원을제외하면

각 병원에서맡아야 함

C병원을제외하면

각 병원에서맡아야 함

서비스 인터페이스를 위한 환경 조사서C 병원

서비스 인터페이스를 위한 환경 조사서B 대 병원

서비스 인터페이스를 위한 환경 조사서A 병원

2009-04-29

서비스 제공을 위한 시나리오 1안

화면CDSS

DB

APP

HTML 기반CDSS

결과 조회

Http & xml

DIA Service

CDSS Service

CDSS연계 모듈

CDSS 서비스 버튼

Http & xml

2009-05-21

서비스 제공을 위한 시나리오 2안

화면CDSS

DB

APP

HTML 기반CDSS

결과 조회

Http & xml

CCM DIA Service

CDSS Service

CDSS연계 모듈

Http & xml

CCM화면생성기

CDSS 서비스 화면

2009-05-21

서비스 제공을 위한 시나리오 적용 방안

• A병원, B 병원– 1안

• C 병원– 2안

2009-05-21

통합 엔진

u-BRAIN Architecture

Java Virtual MachineDBMS / FILE

RuleEngine

KnowledgeRepository

HTTP XML-RPC RMI

변환기

EHR지식프레임워크

Client API

MedicalFunction Lib

CDSS 애플리케이션

Data Interface AdaptorProcessEngine Rule Engine

Adaptor

RepositoryManager

2009-05-08

Self Configurable u-BRAIN


RuleEngine

KnowledgeRepository

HTTP XML-RPC RMI

변환기


Client API

MedicalFunction Lib



Adaptor

RepositoryManager

Context에따라서

지식 저작방법/환경을변경해야 함 지식 종류에

따라서 프로세스엔진을 활용하지않을 수도 있음

2009-05-08

u-BRAIN 확장


RuleEngine

KnowledgeRepository

HTTP XML-RPC RMI

변환기


Client API

MedicalFunction Lib



Adaptor

RepositoryManager

효율적 지식처리를 위한

지식처리함수를추가 개발해야 함

2009-05-08

추가요구사항1: 약물상호작용

• 배경: SAGE 인코딩 과정 효율화(생산성 향상)– 성분 금기에 대한 방향성 문제 해결

• 내용– 현재 evidence statement 는 from, to로 방향성을

갖도록 되어 있음– 약물상호작용의 경우는 방향성이 없음

• 즉, A와 B 약물간 금기 관계가 있을 경우는 자동으로 B와A 약물간 금기 관계가 성립함

• Evidence-statement 를 이용할 경우, A->B와 B-> A 금기관계를 두번 모델링해야 함

– 한번의 모델링으로 2개의 금기 관계를 처리할 수있어야 함

2009-05-25


• 변경 여부– 수용

• 변경 방안– 변경 대상: Medical Library– 방법 : 함수 수정

• "A와 B 약물간 금기 관계가 있을 경우는 B와 A 약물간 금기관계가 성립"되도록 함

2009-06-05


• 배경: 대량의 약물금기 정보를 자동 입력처리 할 필요 있음– 800-1000개의 금기 관계를 인코딩 할 예정– SAGE에 직접 인코딩 하는 것은 너무 비효율적임

• 진행 상황– A 대학교 팀이 금기 관계를 표현할 엑셀 틀을 설계하고 있음

• 추가 요구사항• 엑셀 틀에 맞춰서 정의한 금기 관계를 sAGE 인코딩에 반영된 것 처럼 해석할 수 있어야 함

• 변경 프로세스 1 (제안)– SAGE 인코딩– 변환기로 지식 변환– 금기약물자동입력기(가칭)가 금기관계 정의 엑셀 파일을 읽어서 변환기가 변환한

지식에 금기 관계 지식 추가• 변경 프로세스 2 (제안)

– SAGE 인코딩– 금기약물자동입력기(가칭)가 금기관계 정의 엑셀 파일을 읽어서 SAGE지식에 추가 하는

방법– 변환기로 지식 변환

2009-05-25


• 변경 여부– 수용– 추가 개발

• 변경 방안– 추가 개발 대상: 변환기 또는 추가 입력기– 제안 방법에 대한 평가 의견– 1번 방법 :

• 장점 - 구현이 상대적으로 쉽다.– 구현 내용: Excel의 내용 읽기, 내부에서 처리하기 위한 Evidence Statement 객체 생성

• 단점 - SAGE 사용자는 Excel에서만 금기관계를 보고 Editing 할 수 있으며, SAGE에서는Excel의 내용을 볼 수 없다.

– 2번 방법:• 장점 - SAGE 사용자는 금기관계가 기술된 Excel의 내용을 SAGE에서 보거나 Editing이

가능하다.• 단점 - 구현이 상대적으로 복잡하다.

– 구현 내용: Excel 내용 읽기, Fortege의 Knowledge Instance를 생성하기 위한 방법 학습하여, Excel내용변환

• 이슈– SAGE에서 금기관계의 Excel의 내용을 불러와서 SAGE에서 이를 Editing하는 경우에는 Excel의 내용과

Inconsistency문제 발생

2009-06-05

처리 결과-추가요청 사항2

• 1차 완료일– 2009.07.06

• 1차 검증 완료일

2009-07-202009-07-06

DDI Support ArchitectureConverting time

Run time

Validator DDIRuleConverter

DDI Support System

ConvertedDDI Rules

DDIComp Rule Engine

Request to Convert

DDI Rule(CSV Format)

Client Comp

(?)

Request forDDI

DDIApp.

Interface XML(per Patient)

Convert

Load Rules

2009-07-06

Rule Converting Strategy(for 병용)

변환: ATC Code1, 투여경로1 – ATC Code2, 투여경로2

입력: 신규처방( ATCCode, 투여 경로), 기존 처방(ATCCode, 투여경로)변환된 룰의 구조: IF( execute(input.ATCCode, input.투여경로) ) THEN true Else false;출력: 병용 금기 여부, + 알파

사용자 정의 함수내의 자료 구조: è 자료구조(1안): Key(ATCCode1, 투여경로1) – Value(ATCCode2, 투여경로2)

Key(ATCCode2, 투여경로2) – Value(ATCCode1, 투여경로1)

è 자료구조(1안 , 예): Key(M01AB16, O) – Value(M01AB15, O), Key(M01AB16, O) – Value(M01AB15, I)Key(M01AB15, O) – Value(M01AB16, O), Key(M01AB15, I) – Value(M01AB16, O)Key(M01AB16, O) – Value(S01BC05, O), Key(M01AB16, O) – Value(S01BC05, I)Key(S01BC05, O) – Value(M01AB16, O), Key(S01BC05, I) – Value(M01AB16, O)

è 자료구조(2안): Key((ATCCode1, 투여경로1), (ATCCode2, 투여경로2)) à Sorting해서 저장è 자료구조(2안 , 예):

Key( (M01AB16, O), (M01AB15, O)), Key( (M01AB16, O), (M01AB15, I))Key( (M01AB16, O), (S01BC05, O)), Key( (M01AB16, O), (S01BC05, I))

è 성능상 이유로 2안 수용: è 예상 비교 횟수: 입력(신규(n), 기처방(m))에 대해서 (nC2 + m*n) * 1 è HashTable로 구현 예정이므로 검색속도는 1

금기 등급 대표성분1 ATC코드1 투여경로1 대표성분2 ATC코드2 투여경로2

병용금기 Aceclofenac M01AB16 O Ketorolac M01AB15/ S01BC05 O/I

DDI Rule (CSV Format)

2009-07-06

Rule Converting Strategy(for 과처방)

변환: ATC Code1, 투여경로1 – ATC Code2, 투여경로2

입력: (신규처방 약의 ingredient, 투여방법, CrCl, Crtdose(1일용량))*

변환된 룰의 구조:• RuleID 0:

– If((input.Crcl >=0) and (input.Crcl <10)) THEN fire(“RuleID0-1”) ELSE fire(“RuleID1”)• RuleID 0-1:

– if( input.Crtdose > 10) THEN true Else false;• RuleID 1:

– If((input.Crcl >= 10) and (input.Crcl <50)) THEN fire(“RuleID1-1”) ELSE fire(“RuleID2”)• RuleID 1-1:


– If((input.Crcl >= 50) and (input.Crcl <90)) THEN fire(“RuleID2-1”) ELSE fire(“RuleID3”)• RuleID 2-1:


– If(true) THEN fire(“RuleID3-1”) ELSE• RuleID 3-1:

– if( input.Crtdose > 10) THEN true Else false;

Rule의 IDATCCode + 투여경로+ 룰Hierarchy: (예) J05AB_O_0, J05AB_O_0_1. J05AB_O_1, J05AB_O_1_1

출력: 과처방 금기 여부, + 알파

속도: 입력(신규처방(n)) 이고, 약당 평균 DDI룰 개수(m) 인 경우 n*m*2

ATC code 성분명 투여경로(O/I/E) LowCrCl(<) UppCrCl(<=) MaxDoseJ05AB Adefovir O NULL NULL 10

J05AB Adefovir O 5 10 10



DDI Rule (CSV Format)

2009-07-06

추가 요구사항 3: 약물 상호작용

• 추가 요구사항 명: DUR 자동 연동 기능• 요청자: A 대학교

• 배경– A 대학교는 DUR룰을 사용하고 있음– 하루에 한번씩 KIMS 온라인에 의해 update 실시함– DUR 룰과 세부과제가 정의한 룰과 상호 비교 후 연동이 필요함

• 정의– 변환 룰: EHR 사업단에서 정의한 룰 중 B대에서 사용 가능하다고 판단하여 엑셀에 정의한

룰을 자동 변환 모듈에 의해 u-brain이 실행할 수 있는 형태로 변환한 룰

• 요청 내용– DUR 룰을 저장하고 있는 DB와 변환 룰의 자동 연동– 변환기가 직접 DUR DB에 접근하여 DB에 저장된 내용을 u-BRAIN이 이해하는 형태로 변환

2009-07-06

추가 요구사항 3: 약물 상호작용• 현재 아키텍처

– 사업단이 정의하여 B대에 제공한 약물 상호 작용 룰 중– B대가 정의한 기준에 따라 필요한 룰을 선별하여 엑셀로 정의– 엑셀 파일을 u-BRAIN이 실행할 수 있는 형태로 자동 변환할 수있는 DDI룰 자동 변환기를 추가

개발

Converting time


DDI Support System

ConvertedDDI Rules

DDIComp

Rule Engine

Request to Convert


DDI룰변환환경

Request forDDI

DDIApp.


Convert

Load Rules

2009-07-06

추가 요구사항 3: 약물 상호작용• A 대학교 요청을 그대로 반영할 경우의 아키텍처

– DB에 정의된 DUR 룰을 읽어서 u-brain 실행 형태로 변환하는 변환 환경을 추가개발해야 함

Converting time

Validator2 DDIRuleConverter2

DDI Support System

ConvertedDDI Rules

DDIComp

Rule Engine


DDI룰변환환경1

Request forDDI

DDIApp.


Convert

Load Rules

DDI룰변환환경2

DUR DB

2009-07-06

변환환경1: 정의된 DDI룰을 u-brain이 실행 가능한 형태로 변환하도록 요청하는 환경Validator: 정의된 DDI를이 변환 가능한지 여부를 검증하는 모듈DDI Rule Converter: 정의된 DDI 룰을 u-brain이 실행 가능한 형태로 변환하는 모듈

Validator 1 DDIRuleConverter 1

추가 요구사항3: 약물 상호작용

• 요구사항 처리 이슈– 이슈1:

• DUR과 사업단이 정의한 룰간의 연동이 필요한가?• 이번 연구 범위에 속하는가?

– 이슈2:• 만약 연동해야 하는 것이 업무 범위에 속한다면• 연동의 역할이 사업단에 있는가 B대학교에 있는가?

• 2009년 7월 6일 조교수님과 논의 결과– 이번 업무 범위에는 속하지 않음– 장기적으로는 필요한 내용이기는 함– 연구 진행 상황을 보면서 여력이 생기면 처리하고(처리할 주체 및 방법은

추후 결정)– 여력이 없다면 내년 연구로 넘기도록 함

2009-07-06

추가 요구사항 3: 약물 상호작용• 바람직한 아키텍처

– 사업단이 제공하고 B대와 협의를 통해 만든 공통 지식 정의 틀(엑셀 파일 구조)는 범용적인것이므로, 이를 바탕으로 u-brain 지식으로 변환하는 모듈은 하나로 존재하는 것이 바람직함

– DUR DB로 부터 룰 변환이 필요하다면 DUR DB로 부터 이번에 정의한 엑셀로 변환하는 모듈을추가 개발하는 것이 아키텍처의 일관성을 유지하는 방법임

Converting time


DDI Support System

ConvertedDDI Rules

DDIComp

Rule Engine


룰변환기

Request forDDI

DDIApp.


Convert

Load Rules

DUR정보

해석기

DUR DB

DDI Rule(CSV Format)생성

2009-07-06

추가 요구사항 4: 약물상호작용• 추가 요구사항명

– DUR 룰과 사업단이 정의한 룰 간의 중복성을 자동으로 판단

• 요청자: A 대학교 박OO

• 요청 내용– A 병원 룰과 EHR 사업단 룰을 비교하여 중복되는 것은 자동으로 EHR 사업단 룰을 flag를 걸어서 사용 하지

못하도록 되거나 룰을 삭제를 해야 함

• 이슈– 올해 연구 범위에 속하는가?

• 2009년 7월 6일 조교수님과 논의한 사항– 이번 연구범위에 속하지는 않음– 장기적으로는 꼭 필요한 연구 범위에 속함– 추가 개발해야 한다면 가장 우선순위가 높은 사항임– 초기에는 수작업으로 B대가 작업을 해서 반영하도록 하고– 연구 여력을 판단한 후 가능하면 올해 연구 범위내에 포함시키도록 노력한다.– 초기 수작업으로 진행한 B대 결과가 개발에 필요한 요구사항 수립 및 개발 설계에 필요한 입력 자료가 될 것임

• 2009년 7월 17일 A대 팀과 회의 결과– 6세부는 단계적으로 변환에 대한 지원을 제공할 것임(DDI 우선-> DUR까지 확대).

2009-07-202009-07-06

처리 결과-추가요청 사항3,4

• 2009. 8. 6– 요청 사항 3,4를 처리하기 위한 방안 합의– 참석자

• 박OO 교수, 조OO 교수, 김OO 교수

2009-08-06

요구사항 3,4 에 대한 최종 결정안

2009-08-06

OCS

SMART

EHR 룰 시스템

화면

메시지박스

DUR 룰

통합 룰 = EHR 룰 + DUR 룰

전제: 2개의 룰, 2개의 룰 시스템이 존재한다.

사용 흐름1. OCS는 SMART을 호출한 후, EHR 룰 시스템을호출한다. (2개 모두 호출함)

2. EHR 룰 시스템으로 부터 적시에 응답이 돌아오면DUR로 부터 받은 응답 메시지는 사용하지 않고EHR 룰 시스템으로 부터 받은 메시지만 보여줌

2. EHR 룰 시스템으로 부터 응답이 늦게 오면, SMART 실행 결과를 화면에 보여준다

발생할 수 있는 이슈1. EHR 룰과 DUR를 초기 통합해야 함(통합 룰)2. DUR 룰이 갱신될 때 마다 통합 룰도 갱신해야 한다.

최종 결정안) 2개 룰, 2개 룰 시스템

최종 결정안 수용을 위한 방법• 전제

– DUR 룰 갱신 주기에 따른 통합 룰 갱신– 중복이 제거된 통합 룰 운영– 성능 보장

• 추가 개발이 필요한 기능(1) 서비스 호출 모듈 변경 사항

- SMART과 EHR룰 시스템을 모두 호출하게 개발- SMART과 EHR룰 시스템으로부터 모두 결과가 돌아온 경우, EHR룰

시스템으로부터 받은 메시지만 사용자에게 제공한다. (EHR룰시스템으로부터 받은 메시지가 우선적으로 제공됨을 의미)

- EHR룰 시스템으로부터 응답이 늦어질 경우는 SMART 결과를제공하고 EHR룰 시스템으로부터 응답을 기다리지 않는다.

(2) 통합 룰 관리 시스템- DUR 룰 시스템의 룰과 EHR룰 시스템의 룰 중복 제거

- SMART의 룰을 EHR룰 시스템을 룰 형식으로 변경- 룰 set 관리

2009-08-06

제안하는 아키텍처

2009-08-06

Converting time

Validator DDI RuleConverter

DDI Support System

ConvertedDDI Rules

DDIComp

Rule Engine


룰 변환기

Request forDDI

DDIApp.

Interface XML (per Patient)

Convert

Load Rules

DUR정보 해석기

DUR DB DDI Rule (CSV Format) 생성

SMART

개발 R&R

2009-08-06

A대 개발A대 개발 세부과제 개발

Converting time

Validator DDI RuleConverter

DDI Support System

ConvertedDDI Rules

DDIComp

Rule Engine


(2)룰 변환기

Request forDDI

(3) DDIApp.

Interface XML (per Patient)

Convert

Load Rules

(1) DUR정보 해석기

DUR DB DDI Rule (CSV Format) 생성

SMART

추가 요구사항 4: 약물상호작용

• 2009. 09. 05 회의– 중복성 제거는 A대가 담당한다.

추가 요구사항 5: 약물 상호작용

• 추가 요구사항명– 기 처방 내용을 포함하여 약물 상호작용 룰 적용

• 요청자: A대학교 박OO

• 요청 내용– 약물 상호작용 판단 범위를 현 약물 처방에만 국한하지 않고– 해당 환자의 기 처방 내용까지 적용해야 함

• 이슈– 이슈1: 올해 연구 범위에 속하는가?– 이슈2: 범위에 속한다면, 초기 u-BRAIN 호출시 기 처방 내용을 질의하여 인터페이스 XML에 담아 보내줄

것인가, 룰 실행 중에 DIA를 통해 기 처방 내용을 EMR로 부터 얻어올것인가?

• 2009년 7월 6일 조교수님과 논의한 사항– 정확한 내용 파악 후 다시 논의

• 2009년 7월 17일 A대 팀과 회의 결과– 사용하지 않는 것으로 확인함. 초기 한번에 전달.

• 이슈 종료

2009-07-202009-07-06

A대학교 스트레스 테스트 지원

• 제한 사항– DIA Java 인터페이스만을 지원

• .Net 기반의 클라이언트에서 DIA로 입력XML을구성불가

• 방법1: DIA를 사용한 입력 XML 구성부분과 서비스I/F을 담당하는 CDSS Server의 추가

• 방법2: DIA 사용 대신 이미 만들어진 입력XML을 로딩하여 사용

– DIA2를 적용한 Engine이 존재하지 않음• DIA1(made by 최현숙) 버전 사용 or DIA 사용안함

2009-07-07


• 제안 1

uBrain

지식:Lab Alerting

지식:Lab Alerting

DB:분당 Data

DB:분당 Data

Test Client Stress Test App.

이름 설명

1 uBrain 지식엔진

2 지식 지식엔진 위에서 동작하는 지식

3 DB 지식을 해석하기 위해 필요한 로컬 DB

4 CDSS ServiceApp.

지식엔진(uBrain)과의 인터페이스를 담당하고 DIA로 입력 XML을 가져와 서비스를 요청, WEB Service지원

5 Test Client CDSS Service App.에 서비스를 요청하는Test Client 모듈

6 .Net I/F 지식엔진과 통신을 지원하는 I/F모듈

7 Stress Test App.

스트레스 테스트를 위한 Application

HTTPHTTP

API Call 등

API Call 등

CDSSService

App.DIA

.Net I/F.Net I/F

2009-07-07


• 제안 1 처리 방법– 지식: 분당에서 작업한 Lab Alerting (有)

– 지식엔진• 인터페이스: Web App. 형태의 인터페이스 (이재훈 작업 중)• DIA: DIA1(최현숙 작업) 이 적용된 케이스 (有)

– DB: MicroSite 때 사용한 20건 정도 (有)

– CDSS Service App.: CDSS Service Server로 작업을 해야 함 (New)

– Test Client: (New)

– .Net I/F: 기본 구조는 존재 LabAlerting용으로 customizing 필요 (수정필요)

2009-07-07


• 제안 2

uBrain

지식:Lab Alerting

지식:Lab Alerting

Test Client Stress Test App.

이름 설명



3 Test Client 미리 만들어진 입력(XML)을 지식엔진에서비스를 받을 수 있도록 지원하는 모듈


5 입력XML 미리 만들어진 사용자 입력 XML

6 Stress Test App.


HTTPHTTP

API Call 등

API Call 등

입력XML입력XML

.Net I/F.Net I/F

2009-07-07


• 제안 2 추진 방법– 지식: A대에서 작업한 Lab Alerting (有)

– 지식엔진• 인터페이스: Web App. 형태의 인터페이스 (이재훈 작업 중)

– 입력XML: 테스트를 위해 사용한 20건 정도 (有)


– .Net I/F: 기본 구조는 존재 LabAlerting용으로 customizing 필요 (수정 필요)

2009-07-07


• 추천 안– 2안을 추천– u-Brain 자체에 대한 성능 검증이라면 2안으로 충분하다고 봄– 구조적으로 더 간단하고 추가 개발 범위가 적음

• Test Client 추가 개발의 R&R– CDSS팀에서 인터페이스를 가이드하고 A대에서 개발 가능할 것으로 사료됨– 엔진에 대한 요청은 Web 호출로 이루어지므로 무리가 없을 것으로 보임.– 이는 가능함의 여부 뿐이고, 논의가 필요할 것으로 생각함

• A대 병원에 확인 할 사항– Test Client

• Test Client의 요건 사항: 반복적으로 지식엔진을 호출해야 하는지 여부• Test Client와 Stress Test App간의 연계 방법 확인 필요• Test Client의 환경: .Net을 지원해야하는지 여부

2009-07-07


• 제안 3

uBrain

지식:약물 상호 작용

(일부)


(일부) Test Client Stress Test App.

이름 설명






6 Stress Test App.


HTTPHTTP

API Call 등

API Call 등

입력XML입력XML

.Net I/F.Net I/F

2009-07-07


• 처리 방법– 지식

• 약물 상호 작용 일부여야 의미가 있을 것임• 지식을 확보하기 위해서는 B대 팀이 만들고 있는 자동 변환기의 테스트가 완료된

후여야 확보될 수 있음• 그러므로, 스트레스 테스트도 그 이후가 되어야 함(박OO 교수와 논의 필요)

– 지식엔진• 인터페이스: Web App. 형태의 인터페이스 (이재훈 작업 중)

– 입력XML: 테스트를 위해 사용한 20건 정도 (A 대 만들어 주어야 함)


– .Net I/F: 기본 구조는 존재 LabAlerting용으로 customizing 필요 (수정 필요)

2009-07-07


• 처리 방법 (결론)

2009-07-20

A대병원 범위A대병원 범위

A대병원 범위A대병원 범위

uBrain


(일부)


(일부) Test Client Stress Test App.

이름 설명






6 Stress Test App.


HTTPHTTP

API Call 등

API Call 등

입력XML입력XML

.Net I/F.Net I/F


• 처리 방법 (결론)– 대상

• 약물상호작용 일부를 대상으로 uBrain의 스트레스 테스트

– 제한점• 변환기 테스트 완료 후 가능

– R&R• 6세부

– 약문상호작용 일부만 담긴 지식– uBrain– .Net I/F Lib & 명세: .Net Lib.로 입력XML을 로딩 uBrain으로 서비스 요청 API를 제공

• A대병원– 입력 XML작성– TestClient– Stress Test APP

• A대병원 측의 모듈들은 A대병원의 편의에 따라 변경 가능– Ex) TestClient와 Stress Test App.의 통합등

2009-07-20


• 처리 방법 (결론)– 단계적 수행

• Test Application 작성– 6세부: .Net I/F와 명세(사용법) 선제공 (7/14일 제공 예정)– A대병원: .Net I/F와 사용법을 기반으로 스트레스 테스트에

필요한 작업 진행(Test Client와 스트레스 Test App. 등)

• 입력XML 작성– 6세부 : 입력XML 포맷 제공 (7/14일 제공 예정)– A대병원: 제공된 포맷을 기반으로 테스트에 사용할 XML 작성

• 지식이 탑재된 uBrain 제공– 6세부: 변환기 테스트 완료 후 uBrain제공 (확인 후 일정 전달)– A대병원: 설치 후 스트레스 테스트

2009-07-20

추가요구사항 6: 세부 정보 처리

• 추가요구사항– 인터페이스 XML에 세부 정보를 담아달라– A 대 애플리케이션이 룰 처리와 상관없는 부가 정보 전달– 룰 처리 이후, 룰이 판단한 문제 약물 관련 부가 정보를 함께 반환

• 변경 영향 범위– 서비스 모듈 변경

• 변경 방법– 인터페이스 XML 이원화– A대 애플리케이션으로부터 서비스 모듈이 받는 인터페이스 XML과

서비스 모듈이 유브레인에게 전달할 인터페이스 XML을 달리 함– 서비스 모듈이 부가 정보를 담은 인터페이스 XML에서 유브레인이 필요로

하는 데이터만 추출하여 유브레인 전달용 인터페이스 XML 생성– 서비스 모듈은 부가 정보를 임시 저장소에 저장– 유브레인 처리 결과를 해석하여 키 값을 얻어내고, 임시 저장소로 부터 키

값에 해당하는 부가 정보를 검색하여 함께 출력 인터페이스 XML을 만들어A대 애플리케이션에 전달


• 입력 인터페이스 XML 처리 흐름

A대APP

서비스모듈

유 브레인

부가정보

룰 처리 정보+ 부가 정보

룰 처리 정보

부가정보


• 출력 인터페이스 XML 처리 흐름

A대APP

서비스모듈

유 브레인

부가정보

오류 ACT에 대한부가 정보를 담은XML

오류 ACT 코드 쌍

ACT 코드쌍에 대한 부가정보 획득

추가 요청사항 7: 예외 처리

• 요구사항– 다음 경우에 시스템 장애로 애플리케이션에

응답해야 한다.• 서버가 죽었을 경우• 엔진이 죽었을 경우• 제한 시간내에 엔진이 응답을 만들지 못한 경우

• 수용• 변경 대상

– 서비스 인터페이스 모듈– 유 엔진

DIA Architecture

Converter

EVMR QueryGenerator

EVMR QueryGenerator

SAGESAGE

SAGE Knowledge

MappingEditor

(Terminology Mapping,

EMR Mapping)

MappingEditor


EMR Mapping)

(Rule) Converter

(Rule) Converter

EVMR InterfaceModel GeneratorEVMR Interface

Model Generator

EMR QueryGenerator

EMR QueryGenerator

EMR InterfaceModel

Generator

EMR InterfaceModel

Generator

EVMRIM

EVMRQuery

EMR Supporter

Terminology /SchemaMapping Data

EMRQuery

EMRIF

AppAppQuery ExecutorQuery Executor

Operating Time

Converting Time

2009-05-08

DIA Architecture (Run time)

AppApp Query ExecutorQuery Executor

uBRAINuBRAIN

EMR

EMR Query

Control DirectionLegend

Interface Model

2: AssembleInterface Model

3: Request to query to EMR 5: query to EMR

6: RequestFor Reasoning

4: Load Query1: Load Schema

2009-05-08

DIA 확장

EMR QueryGenerator

EMR QueryGenerator

Query ExecutorQuery Executor

Oracle version

CCMversion

Oracle version

CCMversion

MappingEditor


EMR Mapping)

MappingEditor


EMR Mapping)

Oracle version

CCMversion

2009-05-08

추가요구사항3: 매핑 관계 추가

• 변경 대상: 스키마 매핑 어플리케이션

• 변경 내용– 기존의 경우 ( HT의 사례)

• 병원 DB에서 하나의 DB 연결에서 그 하위의 테이블만을 매핑의대상으로 함

– 추가 사항(랩 사례)• 여러 DB를 연결하여 데이터를 가져와야 함• 각각의 DB연결을 만드는 것이 아니라, 하나의 연결DB에서

Database Link를 사용하여 다른 DB의 정보를 가져오는 것 임

• 스키마 매핑 어플리케이션에서 DB Link의 테이블도매핑이 가능하도록 해야 할 것임

2009-05-29


No VMR Context Concept Label Concept Description Table 명 field명 condition CIS 값 배율 비고Code

1 Observation EHRLAB01 /mm3 (qualifier value) serum WBC 결과값의 단위 SL0ITEMV TST_RSLTUNT 10^3/㎕ 10002 Encounter EHRLAB02 초진 현재진료과에 처음온자 APOPRSVT MEDTYPE 13 Observation EHRLAB03 Blast cells present (finding) serum 내 Blast cell 존재4 Observation EHRLAB04 Finding of glucose level (finding) serum glucose 결과값

복합의미를 지닌 용어 (아래 참고)앞 (테이블, 필드명,필드값) 조건을 모두 만족하면서 뒤(테이블, 필드명)을 가진환자의 필드값

5 Observation EHRLAB05 Finding of hematocrit (finding) serum Hct 결과값6 Observation EHRLAB06 Finding of potassium level (finding) serum potassium 결과값7 Observation EHRLAB07 Finding of Rh antigen type (finding) serum Rh antigen type 결과값8 Observation EHRLAB08 Finding of sodium level (finding) serum sodium 결과값9 Observation EHRLAB09 Finding of white blood cell number (finding) serum WBC 결과값

10 Encounter EHRLAB10 Inpatient (person) 방문형태가 입원환자임. moeexamt patsect I

11 Observation EHRLAB11 mEq/L (qualifier value)serum potassium 결과값의단위, serum sodium 결과값의단위

SL0ITEMV TST_RSLTUNT 〓 mmol/L 1

12 Observation EHRLAB12 mg/dL (qualifier value) serum glucose 결과값의 단위serum bilirubin 결과값의단위

SL0ITEMV TST_RSLTUNT 〓 mg/dL 1

13 Observation EHRLAB13 Negative (qualifier value) CBC blast 결과값, Rh 결과값newborn antibody 결과값

SLXWORKT TST_RSLT =0, -, ( )( )의 경우, 검사시행여부 Y인 경우, Negative로 판단

14 Encounter EHRLAB14 Nephrology department (environment) 신장내과 moeexamt dpcd IMN15 Encounter EHRLAB15 Outpatient (person) 방문형태가 외래환자임. moeexamt patsect O16 Encounter EHRLAB16 Patient (person) SLXWORKT PT_NO 환자교유인식코드17 Observation EHRLAB17 Percent (property) (qualifier value) serum Hct 결과값의 단위 SL0ITEMV TST_RSLTUNT 〓 %18 Observation EHRLAB18 Positive (qualifier value) CBC blast 결과값, Rh 결과값 SLXWORKT TST_RSLT >0, + 0초과시 positive

19 Observation EHRLAB19 year (qualifier value) 유효기간에 대한 단위 SLXWORKT UPDTETM ? YYYYMMDDhhmm

20 Observation EHRLAB20 Finding of Absolute neutrophil count (finding) ANC 결과값

21 Observation EHRLAB21 cells/uL (qualifier value) ANC 결과값의 단위

22 Observation EHRLAB22 platelets/L (qualifier value) serum platelets 결과값의단위

23 Observation EHRLAB23 Platelet finding (finding) serum platelets 결과값24 Observation EHRLAB24 Finding of bilirubin level (finding) serum bilirubin 결과값25 Observation EHRLAB25 newborn antibody present (finding) newborn antibody 존재

A병원 사례

2009-06-08


A병원 사례복합의미를 지닌 용어 Table 명 field명 field값 Table 명 field명 field값

3 Observation EHRLAB03 Blast cells present (finding) serum 내 Blast cell 존재 SL0ITEMV TST_cd L20129 SLXWORKT TST_RSLT4 Observation EHRLAB04 Finding of glucose level (finding) serum glucose 결과값 SL0ITEMV TST_cd L3005, L8137 SLXWORKT TST_RSLT5 Observation EHRLAB05 Finding of hematocrit (finding) serum Hct 결과값 SL0ITEMV TST_cd L2004, L8003 SLXWORKT TST_RSLT6 Observation EHRLAB06 Finding of potassium level (finding) serum potassium 결과값 SL0ITEMV TST_cd L3044, L8131 SLXWORKT TST_RSLT7 Observation EHRLAB07 Finding of Rh antigen type (finding) serum Rh antigen type 결과값 SL0ITEMV TST_cd L7021 SLXWORKT TST_RSLT8 Observation EHRLAB08 Finding of sodium level (finding) serum sodium 결과값 SL0ITEMV TST_cd L3043, L8130 SLXWORKT TST_RSLT9 Observation EHRLAB09 Finding of white blood cell number (finding) serum WBC 결과값 SL0ITEMV TST_cd L2001, L8004 SLXWORKT TST_RSLT

20 Observation EHRLAB20 Finding of Absolute neutrophil count (finding) ANC 결과값

22 Observation EHRLAB21 Platelet finding (finding) ANC 결과값의 단위

24 Observation EHRLAB22 Finding of bilirubin level (finding) serum platelets 결과값의단위

25 Observation EHRLAB23 newborn antibody present (finding) serum platelets 결과값

2009-06-08

지원방안1: 진단 검사

• A 병원에 배포할 모듈– 지식 저작 환경 (EHR-CDSS Framework)- 변환기 포함 모듈– U-BRAIN (통합 지식 엔진)– 스키마 매핑 애플리케이션

• A병원에서 Lab 실행을 위한 저작 및 배포 프로세스– 지식 저작– 지식 변환– 스키마 매핑– 지식 실행

• 특이사항– 용어 매핑 애플리케이션은 배포하지 않아도 됨.– 용어 매핑 애플리케이션을 통해 만들어저야 하는 용어 매핑 결과 XML을 수작업으로

만들어서 지식 실행시 참조하는 것으로 진행– 이유

• 소량의 용어 매핑 수준• A 병원에 매핑 대상 용어가 없음

2009-06-10

지식 저장소

개정 이력


초기 작성-전체 목표 시스템으로 부터 분리

유스케이스 모델 및 요구사항 명세서 정리

WBS 추가

Oss 목록 및 아키텍처 추가

저장소 접근 법 수정- WBS 수정

Samson 미팅 후 Initial architecture 수정 (Change control 추가)

개발 프로세스

저장소 개발 프로세스

지식 정의단위 식별

지식 재사용방법 식별

메타 모델정의

저장소 구현

지식 특성 분석

확장 가능성확인

저장소 모듈설계

활용 가능한OSS 식별

저장소아키텍처 수립

활용 가능방법 확인

지식 관련성정의

지식 관리기능 정의

도메인 팀이 맡아주시면효율적일 것임

2009-05-08

WBS

Seq 단게 Task 산출물 기간

1 분석 저장소 기능 정의 -유스케이스 모델- BMT 결과서

1.1 - 사용자 분석을 통한 저장소 기능 정의

1.2 - OSS 분석을 통한 저장소 기능 정의

1.2.1 . 후보 OSS 선정

1.2.2 . 설치 및 기능 분석

1.2.3 . 평가 결과 작성

1.3 Protégé 분석 - Protégé 환경 분석서

1.3.1 - Protégé Client-server 버전 분석

1.3.2 - Collaborative protégé 분석

1.3.3 - SAGE 플러그인 사용가능성 분석

1.4 초기 아키텍처 정의 - Initial architecture 정의서

1.4.1 - Protégé 연동 방안 분석

1.4.2 - 구성 모듈 개념도

2009-05-312009-06-23

Initial Architecture

Service Interface

Refined Architecture

nowledge

Informaticians

Knowledge Engineer

Knowledge Repository

KnowledgeRepository

CDS Service Layer

CaseDatabase

CDSS QualityDatabase

Doctor Nurse Staff

EHR Database

Common Service Layer

Terminology services

TerminologyServer

Event Listener

Guideline Viewer

Authoring Env

KnowledgeFramework

CDSS framework

Guideline Simulator

GuidelineDeployment tool

Guideline Converter

CDSS ApplicationCDSS Application

Inference

Server

Library for Medical

Knowledge Engine

Interface ServerInterface Server

Data Interface Adaptor

Query Generator

Mapping Engine

Data Interface Editor

Interface RepositoryInterface Repository

eVMR eVMR Profile for EMR

ResourceLocator

CKMS-Initial Architecture

Service Log

Terminology

Knowledge portal

Clinical Content Model

Guideline Ontology

Service Definition

Encoding work product

Converted Knowledge

Knowledge Authoring Framework

Knowledge Converter

Knowledge Verifier

Version Control

Configuration Mgt

Discovery Service- Search & Navigation

Collaboration Service- Forum & Board

Access Control

Meta Data Mgt

Analytic Service

Content Layer

InterfaceLayer

ManagementLayer

RepositoryService Layer

File Server DBMSIntranet Service

- Mail, BBS

InfrastructureLayer 2009-05-08

2009-06-25

ChangeMgt

기술 아키텍처

• 저장기의 기술 요구사항– SAGE + CVS + access control + 기타.. – SAGE에서 저작하고, 저장하면 저장소에

등록되어야 함– Java를 이용한 SAGE에서 동작하는 Plugin

2009-05-31

기술 아키텍처

• 이슈– Protégé plugin 을 찾아야 한다.

• 저장소 클라이언트를 개발하는 것은 매우 어렵다• Protégé version 4.0 이상에서는 저장소 플러그인 활용이

가능하지만• 3.0 버전에서는 존재 하지 않음 è ???????

– 다양한 protégé 버전이 존재 함• 예

– 3.4.1 버전에는 client-server 버전이 존재함– Collaborative protégé도 따로 있음

• 다양한 버전에 대한 분석이 필요함– 공동작업을 위해 제공하는 기능 리스트

» 형상관리, 변경관리, 접근 제어 등– SAGE 플러그인과 연동 가능한가

2009-05-312009-06-23

요구사항 정의서

사용 시나리오

• 시나리오 11. 도메인 전문가가 저작기를 이용해서, 가이드라인(지식)을

저작한다.2. 도메인 전문가는 저작된 지식을 포탈에 등록한다.3. 가이드라인을 적용하려는 병원 IT전문가는 포탈에서 적합한

가이드라인을 검색하여 다운로드 받는다.4. 병원 IT전문가는 다운로드받은 지식을 변환기를 이용해 변환한다.

• 시나리오 21. 도메인 전문가는 저작기를 이용해서 가이드라인을 저작한다.2. 도메인 전문가는 저작에서 저장소로 가이드라인을 등록한다.3. 도메인 전문가는 변환기를 이용해서 변환한다4. 변환한 지식을 저장소에 등록한다.5. 병원 전문가들은 포털에서 저장소에 등록된 지식을 검색한다.

2009-05-15

유스케이스 모델

• Actor– 도메인 전문가– 지식 저작 전문가– 일반 의료 전문가.

• 유스케이스(기능 요구사항)– 지식 저작 과정의 산출물을 저장– EHR지식 프레임워크 저작 결과물 저장– 변환 지식 저장– 산출물, 저작 결과물, 변환 지식간 연결성 정의 (형상관리)– 변경 관리– 권한 관리– 검색/조회 기능– 다운로드– 로그 관리

2009-05-15

기술 요구사항

• 저장기의 기술 요구사항– SAGE + CVS + access control + 기타.. – SAGE에서 저작하고, 저장하면 저장소에

등록되어야 함– Java를 이용한 SAGE에서 동작하는 Plugin

2009-05-15

적용 범위(1차)

• 형상관리의 대상– 고혈압 지식 v1 형상

• SAGE 가이드라인 V3 + • 변환 지식 V3 + • 서비스 정의서 V5 + • 테스트 케이스 V2

2009-05-15

분석 OSS

후보 OSS 목록

OSS 명 URL 특성

Archiva http://archiva.apache.org/ Configuration management Tool로 활용 가능함

ApacheJackrabbit

http://jackrabbit.apache.org/getting-started-with-apache-jackrabbit.html

Content Repository for Java Technology API (JCR)제공으로 인하여 다양한응용이 가능할 듯함

2009-06-10

Jackrabbit Architecture

2009-06-10

검증기

개정 이력


초기 작성-전체 목표 시스템으로 부터 분리

WSB 재작성

1차 요구사항 (개념, 범위) 정의

WBS

2009-06-01

Task Level Task 기간1 지식 검증 방법론 수립 (문서)

1.1 의료 지식 검증 방법 조사/분석 6월1.1.1 의료 지식 검증 방법론 Overview1.1.2 Guideline interchange format별 테스트 사례 조사

1.2 룰 기반 비즈니스 규칙 검증 방법 조사/분석 6월1.2.1 룰 처리 엔진의 테스트 커버리지에 대한 문헌 조사1.2.2 단위 룰 검증을 위한 테스트케이스 생성 방법론 (Decision/Condition) 조사

1.3 프로세스 검증 방법 조사/분석 6월1.3.1 프로세스의 테스트 커버리지에 대한 문헌 조사1.3.2 상태/ 경로 기반의 테스트 케이스 생성 방법론 (State, Path) 조사

1.4 EHR-CDSS 지식 검증 기법 수립 7월1.4.1 테스트 방법론 조사1.4.2 EHR-CDSS의 특성 정의 (커버리지, 테스트 케이스 수, 오류율 등)1.4.3 예제 가이드라인(HtMgt)를 바탕으로 테스트 방법론 검증1.4.4 EHR-CDSS 지식 검증을 위한 테스트 방법론 선정1.4.5 적정 케이스 수 결정

1.5 검증 프로세스 수립 7월1.5.1 검증을 위한 요구사항 수립1.5.2 시나리오 수립 (역할, 프로세스)1.5.3 자동화/반자동화 영역 설정

검증기 활용 프로세스(안)

지식 저작

(EHR저작Framework)지식 변환 지식 실행

인터페이스모델

도메인모델

프로세스지식

룰지식

테스트 케이스 생성

테스트 케이스 생성 테스트 케이스 실행

레포트예상결과테스트

데이터

테스트

케이스

2009-05-08

검증기 개발 프로세스

지식 검증대상 식별

지식 검증기법 정의

저장소 구현

지식 특성 분석

적용 가능 테스팅기법 식별

테스팅 기법 정리

테스팅 알고리즘설계

지식 검증절차 정의

도메인 팀이 맡아주시면효율적일 것임

2009-05-08

지식 검증의 필요성

• 저작자의 원 지식과 지식으로부터 도출된 결과물과의 사이에는 반드시차이가 발생 → 100% 완전한 지식의 구현이란 있을 수 없음

• 테스트는 오류를 발견하는 활동일 뿐, 산출물의 완전함을 보증하는 것이아님

• 따라서 이미 완성된 결과물의 품질을 높이는 활동보다는, 저작과정에서올바른 지식을 모델링하는 체계의 확립이 근본적으로 중요함

지식 검증의필요성

• 아폴로 11호의 시스템 신뢰성 (99.9999999% -> Nine-Nine)

• 일반적인 상용 S/W의 목표 품질 (5~6sigma : 99.99x%)

• CDSS의 임상 지식 표현의 목표 정확도 (99.98%)

• CDSS의 테스트와 검증 수준은 아직 초기 단계에 머무르고 있음

• 따라서 일반적인 테스트 도구를 그대로 적용하기는 어려우며 현 수준과목표에 맞는 검증 방법론이 필요

CDSS에서의지식 검증 수준

2009-06-17

기존의 검증 관련 연구

경험적 테스트케이스

Offline Testing이 대부분

전문가가 만든 테스트 케이스의 결과를 동일한 입력이 주어졌을때의 시스템 수행 결과와 비교

(Sailors 1996, Wang 2004, Paul 2004, Martins 2006 …)

사후 검증 수동적

지식 모델로부터 테스트케이스 생성

지식 저작 과정에서부터검증

자동화된 테스트 케이스생성과 비교 분석

지식 모델을 논리적으로커버하지 못함

제한된 테스트 케이스

지식이 완전히 구현되어실행된 후에 검증 가능

테스트 케이스를 일일이생성하고 비교 분석해야함

기존 방식의특성

개선방향

문제점

2009-06-17

uBrain 가이드라인의 검증 프로세스

• 실행 가능한 지식은 원작자의 원형으로부터 최종적으로 검증된 상태에이르기까지 여러 절차를 거침

• 지식이 검증될 수록 유효성과 정확도는 높아지며, 지식의 범위는 줄어들어명료한 프로세스와 룰의 형태로 남게 됨

• uBrain은 Sage Guideline을 Executable, Verified, Validated하도록 만드는 역할수행

2009-06-17

모델로부터의 테스트케이스 생성

• 경계값을 이용한 개별 룰의 테스트 케이스 생성

Ex) If (SerumK > 6.5) then Action

INPUT (SerumK) OUTPUT

6.51 Action

6.5 Action

6.49 NULL

•Condition/Deicsion Coverage를 이용한 테스트케이스 생성

Ex) If ( DM == true AND CHF==true) then Action

DM CHF OUTPUT

True True Action

True False NULL

False True NULL

• Path Coverage를 이용한 프로세스의테스트 케이스 생성

Ex) A – (B1 or B2) – (C1 or C2) - D

A B1 C1 D

A B2 C2 D

A B1 C2 D

A B2 C1 D

2009-06-17

8. 목표 시스템 [복구] · CCM분석및 환경/지식추가 분석 엔진 확장/튜닝...

Documents

Transcript of 8. 목표 시스템 [복구] · CCM분석및 환경/지식추가 분석 엔진 확장/튜닝...