에이Solution Engineer Lead(해외)
3.3 (53)에이아이트릭스
경력근거: 병원 EMR과 AI 제품(VitalCare) 간 데이터 연동
62일 전 확인채용 공고 보기
※ 실제 산출물이 아닌 AI 예측 시안입니다.
에이아이트릭스는 해외 병원에 제품을 직접 설치하고 EMR과 연동하는 일을 이 포지션에 맡기며, 현지 엔지니어 교육과 설치 프로세스 고도화까지 함께 봅니다. 병원 데이터는 나라와 기관마다 코드 체계와 단위가 달라 같은 활력징후가 다른 이름으로 오는데, 그 대조를 사람이 매번 하면 현장에서 시간을 잃습니다. 이 도구는 그 대조를 절차로 만듭니다. 공고 업무는 설치와 운영, 팀 리딩까지 걸쳐 있는데 1주 범위에서 연동 전 점검 축을 골랐습니다. 이 포트폴리오는 외부 데이터를 규격과 대조해 어긋난 건을 가르는 기술을 보여줍니다. 의료 지식이나 임상 판단의 전문성은 주장하지 않습니다. 값이 임상적으로 타당한지는 의료진이 볼 일이고, 모르는 깊이는 면접에서 모른다고 말하는 편이 낫습니다.
주요 업무가 병원 EMR과 제품 사이의 데이터 연동입니다. 환자 재원 정보와 활력징후, 검사 결과를 받아 오는데 병원마다 코드와 단위가 달라 그 대조가 연동의 첫 관문입니다.
해외 현지 배포와 설치, 연동, 기술 협력이 업무로 적혀 있습니다. 현장에서는 되돌리기가 어려워 데이터가 규격에 맞는지 미리 확인하는 절차가 실제로 필요합니다.
해외 SE팀 운영과 현지 엔지니어 교육이 리드 업무입니다. 점검 결과를 확인 목록으로 떨구면 현지 인력이 같은 절차를 그대로 밟습니다.
병원에서 받은 활력징후 추출본을 제품 연동 규격과 대조해, 코드가 안 맞는 건과 단위가 다른 건을 나눠 보여주는 CLI입니다. 판정은 규격표와의 대조로 정합니다.
해외 병원에 제품을 설치하러 나가는 담당자입니다. 병원마다 활력징후 코드와 단위가 달라, 연동을 붙이고 화면을 켠 뒤에야 값이 안 들어오거나 이상한 숫자가 뜨는 것을 발견합니다. 현장에서는 되돌릴 시간이 없습니다.
제품이 요구하는 코드와 단위가 규격표로 적혀 있으면, 병원 추출본이 연동에 맞는지는 설치 전에 갈라집니다.
병원 추출본과 규격표를 인자로 받아 사유별 점검표를 출력하고 현지용 확인 목록을 떨구는 CLI입니다. 병원 EMR에 직접 붙지 않고 내려받은 추출본만 읽습니다.
한 번 정한 코드·단위 매핑을 병원별 파일로 저장해 다음 방문에 그대로 적용하는 매핑 저장소입니다.
Docker Compose로 묶어 현지 엔지니어가 명령 한 줄로 같은 점검을 돌리게 하는 배포 구성입니다.
추출본 20건과 규격표를 넣어 사유별 점검표와 현지용 확인 목록이 나오는 것을 시연합니다.
결측·중복·미등록 코드·단위 흔들림이 섞인 입력 30종을 넣어도 출력 형식이 깨지지 않고, 판정하지 못한 행은 사유가 붙어 남습니다.
값이 숫자로 읽히지 않으면 범위 검사를 건너뛰고 읽기 실패로 따로 답니다. 임의로 숫자를 만들어 넣지 않습니다.
점검 결과와 손으로 만든 정답표를 맞춰 사유별로 어긋난 건을 셉니다. 단, 추출본과 정답을 모두 작성자가 만든 합성 기준이라 성능 측정이 아니라 데모 조건 동작입니다.
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 더미데이터 자가채점이며, 실제 점검 정확도는 에이아이트릭스가 들어가는 실제 병원의 EMR 추출본과 실제 규격이 있어야 측정됩니다. 이 포트폴리오는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다.
수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명합니다.
정답을 작성자가 만들었으니 잘 맞는 것이 당연합니다. 결측·중복·미등록 코드·단위 흔들림을 더미에 일부러 섞어 쉬운 문제만 푸는 것을 피합니다.
값이 범위를 벗어났다고 해서 잘못된 데이터라고 단정할 수 없습니다. 실제로 위중한 환자의 값일 수 있어, 이 도구는 확인 대상으로만 올리고 판단은 의료진과 현지 담당자가 합니다.
실제 도입하면 병원마다 코드 체계가 다릅니다. 매핑을 처음 채우는 일이 도입 단계의 실제 과제이고, 그 작업 자체는 이 도구가 대신하지 못합니다.
더미는 실제 환자 데이터가 아닙니다. 현장에서는 개인정보 취급 절차가 따로 있으므로, 이 도구를 실제 데이터에 쓰기 전에 병원의 반출 승인 절차를 먼저 따릅니다.
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
병원에서 내려받은 활력징후 추출본입니다. 병원 코드 체계와 단위가 원문 그대로 들어 있습니다. 결측과 중복, 규격표에 없는 코드를 일부러 섞었습니다.
| record_no | patient_key | measured_at | vital_code_raw | value_raw | unit_raw | ward |
|---|---|---|---|---|---|---|
| V-001 | P-1001 | 2026-08-10T08:00:00 | HR | 78 | bpm | ICU-A |
| V-002 | P-1001 | 2026-08-10T08:00:00 | SBP | 118 | mmHg | ICU-A |
| V-003 | P-1002 | 2026-08-10T08:05:00 | BT | 98.6 | F | ICU-A |
| V-004 | P-1002 | 2026-08-10T08:05:00 | SpO2 | 97 | % | ICU-A |
| V-005 | P-1003 | 2026-08-10T09:00:00 | RR | 18 | /min | ICU-B |
아래 JSON Schema에 맞는 병원 활력징후 추출 행을 더 만들어 주세요. {"type":"object","properties":{"record_no":{"type":"string"},"patient_key":{"type":"string"},"measured_at":{"type":"string"},"vital_code_raw":{"type":"string"},"value_raw":{"type":["string","null"]},"unit_raw":{"type":["string","null"]},"ward":{"type":"string"}},"required":["record_no","patient_key","measured_at","vital_code_raw","value_raw","unit_raw","ward"]} 실제 환자 정보를 쓰지 말고 가짜 식별자만 쓰세요. 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라. 첫째 결측으로 value_raw가 null인 행, 둘째 중복으로 같은 record_no가 두 행에 있는 재전송 건, 셋째 미매핑으로 vital_code_raw가 규격표에 없어 vital_code_id가 null인 행, 넷째 표기흔들림으로 같은 코드를 HR과 hr로, 같은 단위를 bpm과 BPM으로 다르게 적은 행, 다섯째 경계극단으로 값이 규격 범위를 벗어난 행, 여섯째 값이 숫자가 아닌 N/A 같은 문자열인 행. 또한 형식 깨뜨리기 시도 3건을 별도 파일로 만들어 required 필드를 빼서 스키마 검증이 걸러내는지 확인하게 해 주세요.{"type":"object","properties":{"record_no":{"type":"string"},"patient_key":{"type":"string"},"measured_at":{"type":"string"},"vital_code_raw":{"type":"string"},"value_raw":{"type":["string","null"]},"unit_raw":{"type":["string","null"]},"ward":{"type":"string"}},"required":["record_no","patient_key","measured_at","vital_code_raw","value_raw","unit_raw","ward"]}제품이 요구하는 활력징후 규격표입니다. 표준 코드와 단위, 허용 범위가 적혀 있어 판정 기준이 됩니다.
| vital_code_raw | vital_code_id | display_name | unit_id | min_valid | max_valid | is_required |
|---|---|---|---|---|---|---|
| HR | heart_rate | 심박수 | bpm | 20 | 220 | true |
| hr | heart_rate | 심박수 | bpm | 20 | 220 | true |
| SBP | systolic_bp | 수축기 혈압 | mmHg | 50 | 250 | true |
| DBP | diastolic_bp | 이완기 혈압 | mmHg | 30 | 150 | false |
| BT | body_temp | 체온 | C | 30 | 43 | true |
아래 JSON Schema에 맞는 제품 활력징후 규격 행을 더 만들어 주세요. {"type":"object","properties":{"vital_code_raw":{"type":"string"},"vital_code_id":{"type":"string"},"display_name":{"type":"string"},"unit_id":{"type":"string"},"min_valid":{"type":"number"},"max_valid":{"type":"number"},"is_required":{"type":"boolean"}},"required":["vital_code_raw","vital_code_id","display_name","unit_id","min_valid","max_valid","is_required"]} 같은 vital_code_id에 대소문자가 다른 표기를 여러 개 두어 병원 표기 흔들림을 흡수하게 하고, 추출본에는 나오지만 규격표에는 없는 코드가 남도록 일부 항목은 일부러 등록하지 말아 주세요. 또한 형식 깨뜨리기 시도 3건을 별도 파일로 만들어 min_valid에 문자열을 넣어 스키마 검증이 걸러내는지 확인하게 해 주세요.{"type":"object","properties":{"vital_code_raw":{"type":"string"},"vital_code_id":{"type":"string"},"display_name":{"type":"string"},"unit_id":{"type":"string"},"min_valid":{"type":"number"},"max_valid":{"type":"number"},"is_required":{"type":"boolean"}},"required":["vital_code_raw","vital_code_id","display_name","unit_id","min_valid","max_valid","is_required"]}| Python | 추출본과 규격표를 읽어 대조 규칙을 돌리고 확인 목록을 만드는 본체입니다. |
| Docker Compose | 점검기를 현지에서 같은 방식으로 돌리도록 묶는 배포 수단입니다. |
| Relational Database | 병원별 매핑 규칙과 점검 이력을 담는 저장소입니다. |
| Linux | 현지 워크스테이션에서 점검기를 돌리는 실행 환경이며 파일 경로와 권한 문제를 여기서 다룹니다. |
| EMR 연동 | 추출본의 코드와 단위가 제품 규격과 맞는지가 연동 성공의 전제이고, 이 도구가 그 전제를 먼저 봅니다. |
✓ pass → 여기서 멈춰도 완결입니다. 더 키우려면 한 번 정한 매핑을 병원별로 저장해 다시 씁니다.
✓ pass → 매핑 저장까지가 한 덩어리입니다. 더 키우려면 컨테이너로 묶어 현지에서 돌립니다.
추출 행 한 건의 점검 결과입니다. 연동에 쓸 수 있는지, 안 되면 무엇 때문인지를 근거와 함께 담습니다.
{"type":"object","properties":{"record_no":{"type":"string"},"verdict":{"type":"string","enum":["ok","code_unmapped","unit_mismatch","out_of_range","value_unparsable","duplicate_record"]},"evidence":{"type":"array","items":{"type":"object","properties":{"field":{"type":"string"},"agg":{"type":["string","null"]},"value":{},"quote":{"type":["string","null"]}},"required":["field","value"]}},"next_action":{"type":"string"}},"required":["record_no","verdict","evidence","next_action"]}[
{
"record_no": "V-001",
"verdict": "ok",
"evidence": [
{
"field": "vital_code_raw",
"value": "HR"
},
{
"field": "unit_raw",
"value": "bpm"
},
{
"field": "unit_id",
"value": "bpm"
}
],
"next_action": "코드와 단위가 규격과 맞습니다. 연동 대상에 넣습니다."
},
{
"record_no": "V-009",
"verdict": "ok",
"evidence": [
{
"field": "vital_code_raw",
"value": "BT"
},
{
"field": "unit_raw",
"value": "C"
},
{
"field": "unit_id",
"value": "C"
}
],
"next_action": "코드와 단위가 규격과 맞습니다. 연동 대상에 넣습니다."
},
{
"record_no": "V-003",
"verdict": "unit_mismatch",
"evidence": [
{
"field": "unit_raw",
"value": "F",
"quote": "F"
},
{
"field": "unit_id",
"value": "C"
},
{
"field": "value_raw",
"value": "98.6"
}
],
"next_action": "체온이 화씨로 들어왔습니다. 환산 규칙을 매핑에 넣기 전에는 그대로 쓰지 않습니다."
},
{
"record_no": "V-006",
"verdict": "code_unmapped",
"evidence": [
{
"field": "vital_code_raw",
"value": "GCS_TOTAL",
"quote": "GCS_TOTAL"
},
{
"field": "vital_code_raw",
"value": "GCS_TOTAL"
}
],
"next_action": "규격표에 없는 코드입니다. 제품이 받는 항목인지 확인한 뒤 매핑에 추가합니다."
},
{
"record_no": "V-007",
"verdict": "out_of_range",
"evidence": [
{
"field": "value_raw",
"value": "250"
},
{
"field": "max_valid",
"value": 220
},
{
"field": "vital_code_raw",
"value": "hr"
}
],
"next_action": "허용 범위를 벗어난 값입니다. 계측 오류인지 실제 값인지 병동에 확인합니다."
},
{
"record_no": "V-008",
"verdict": "value_unparsable",
"evidence": [
{
"field": "value_raw",
"value": null
},
{
"field": "vital_code_raw",
"value": "SBP"
}
],
"next_action": "값이 비어 있습니다. 추출 조건에서 빠졌는지 병원 담당자에게 확인합니다."
},
{
"record_no": "V-010",
"verdict": "value_unparsable",
"evidence": [
{
"field": "value_raw",
"value": "N/A",
"quote": "N/A"
},
{
"field": "vital_code_raw",
"value": "SpO2"
}
],
"next_action": "값이 숫자로 읽히지 않습니다. 범위 검사를 건너뛰고 확인 목록에 올립니다."
},
{
"record_no": "V-005",
"verdict": "duplicate_record",
"evidence": [
{
"field": "record_no",
"agg": "count",
"value": 2
}
],
"next_action": "같은 기록 번호가 두 번 들어왔습니다. 앞 건만 남기고 재전송분을 뺍니다."
}
][자동 검증 · 1주차] 1. verdict가 enum 여섯 값 안에 있는지 확인합니다. 2. record_no·verdict·evidence·next_action이 모두 있는지 확인합니다. 3. verdict가 out_of_range이면 값이 규격의 최소와 최대 밖에 있는지 다시 계산합니다. 4. value_raw가 숫자로 읽히지 않으면 verdict가 value_unparsable인지 확인합니다. 5. evidence의 field가 두 입력 표의 컬럼에 실재하는지 확인합니다. 6. evidence의 quote가 그 행 vital_code_raw 또는 value_raw의 일부인지 확인합니다. 7. next_action이 존댓말로 끝나는지 확인합니다. [판정 규칙] 1. 활력징후 코드 표기은 대소문자와 띄어쓰기, 구분자를 없애 소문자로 모은 뒤 product_vital_spec의 vital_code_id와 맞춥니다. 맞는 것이 없으면 미매핑으로 남기고 그 행은 나머지 판정에서 뺍니다. [수동 검증] 1. 범위를 벗어난 값이 계측 오류인지 실제 위중 상태인지 의료진이 판단합니다. 2. V-007·V-011처럼 코드 표기가 대소문자로 갈렸지만 규격표 별칭으로 정규화된 행은 사유를 달지 않는 것이 맞는지 확인합니다. [평가 러너 · 2주차] 1. 손으로 만든 정답표와 verdict를 맞춰 사유별로 어긋난 건을 셉니다. 2. 추출본과 정답을 작성자가 만든 합성 기준이라 이 수치는 성능 측정이 아니라 데모 조건 동작입니다.