[일오갓생] 4일차가 토요일이라고요?

🤓 DAY 4

새벽까지 집에서 간소하게 지인과 술자리를 가졌지만 스스로가 해이해지지 않도록

눈은 일찍 뜨고 매일 하는 이불 정리와 환기로 하루를 열어 뿌듯했다.

백준도 풀고 책도 읽고 하루를 정리하면서 오늘 일오갓생은

최근에 헬스케어개발공부를 하며 들었던 생각들을 적어보며 다짐하는 15분을 만들어보고자 한다.

---

📚 오늘의 갓생

요즘 개발 공부하면서 데이터베이스를 배우다보니 연구간호사로 일하던 시절이 자꾸 떠오른다.

그 시절의 나는 허다하면 eCRF(전자증례기록)에 데이터를 입력해야 했다.

eCRF 란: 임상시험에서 대상자의 데이터를 컴퓨터 시스템을 이용해 전자적으로 수집, 관리, 보고 하는 기록 양식 또는 시스템을 의미합니다. 이는 임상시험의 효율성을 높이고 데이터의 정확성과 품질을 확보하며, 신속하고 체계적인 데이터 관리 및 분석을 가능하게 하는.. (출처: 구글)

 

혈액검사 수치, 이상반응 기록, 방문 정보, 약물 복용 여부, SAE 같은 사건 사고 관련 내용까지

하루에도 적게는 수십, 많게는 수백 개의 칸을 노가다 하듯이 채웠다.

그 때의 나는 그게 그냥 단순 '입력 작업' 이라고만 여기고 힘들어하면서 했었다.

 

솔직히 말하면 그 땐 오타도 대수롭지 않게 여겼다.

어차피 수정할 수 있으니까 나중에 시간날 때 고치면 되지 나는 지금 입력해야 되는 칸이 이렇게나 많은데..? 라는 생각에

가볍게 여겼었고. 모니터나 데이터, DM 측에서 오타 하나/날짜 하나/단어 하나 때문에 메일이 많이 왔다.

"이 값 확인 부탁 드립니다.", "수정 요청 드립니다.", "수치 다시 확인 부탁 드립니다." 라는 내용의 메일 혹은 

eCRF에 입력했던 값 밑에 바로 Query로 달려있기도 하고, 대부분 영어로 달려있기 때문에 내용이 너무 길 경우에는

지피티한테 이거 무슨 말이라는거니..? 하면서 해석을 요청하기도 했고 

eCRF 창에서 DM 팀이랑 싸우듯이 query와 답변을 주고 받기도 했다..^^

 

데이터베이스를 배우고 나서야 이해가 됐다.

내가 eCRF 에 입력한 그 모든 값들이 결국 데이터베이스 테이블에 그대로 저장됐을 거고,

그게 통계가 되고 분석이 되고.. 신약 허가 자료가 되면서 논문이 된다는 걸 알게 되니 생각이 많이 달라졌다.

특히 내가 주로 썼던 Medidata Rave, Oracle Clinical, InForm 같은 프론트엔드 뒤의 백엔드에는

Oracle, Oracle DB, PostgreSQL 같은 관계형 데이터베이스가 붙어있었다.

 

임상연구 대상자들은 Subject_ID 로 관리가 되었었는데 

그 지역의 병원마다 정해져있는 숫자가 있고 등록되는 대상자 만큼 숫자가 올라갔다.

예를 들면

경기도의 어떤 병원이 031 이라는 숫자를 가지고 있다면 첫 번째 대상자는 0310001 같은 숫자로 등록되는 것이다.

 

아마 이걸 지금 내 시점에서 보자면..

# 아래는 모두 예시를 들어보았습니다.
Subject Table 에는
+ subject_id (PK) : 0310001
+ demographics 
+ Age ...

Visit Table 에는
+ visit_id (PK) : Visit1Day1, Visit1Day2...
+ subject_id (FK) : 0310001
+ visit_date: 27-DEC-2025 ...

AE Tabel 에는
+ AE_id (PK) : 각 AE 마다 정해져있는 번호가 있었다.
+ subject_id (FK) : 0310001
+ AE_term : Anemia 
+ CTCAE_grade : ...

 

이렇게 볼 수 있을 것 같다.

내가 입력한 값들이 테이블의 한 행이 됐을 거고, 대상자 한 명이 여러 테이블에 join 될 수 있었을 거고,

글로벌 연구였고 수 백, 수 천명의 대상자가 있을 테니 엄청 거대한 테이블이었을 것 같다.

 

그 시절에도 Oracle 이름을 많이 들었었는데 이제와서 알아보니

안정성과 확장성이 좋아서 대규모 임상시험 데이터 관리에 많이 사용된다고 한다.

 

아마 내가 오타 하나 냈을 때 그걸 찾아내고 수정하고, 데이터 무결성을 맞추기 위해 관리하고

다시 검증하던 데이터 관리팀이나 개발자들은 그런 오타에 스트레스를 많이 받았을 것 같다.

그 사람들 입장에서는 나 뿐이 아닌 여러 연구간호사들의 '사소한 입력 실수'가 데이터 전체 신뢰도에 영향을 주는 일이었을 테니까.

 

데이터 수정해달라 해서 했더니 바로 승인도 안 해주고 여러번 검토 후에 수정완료 표시를 해준다거나

DB-Lock 기간이 있었는데 그 기간 동안 데이터를 검증하고 그 기간 이후로는 그 시절의 데이터를 동결해놓기 때문에

빡세게 오타 수정 및 요청 사항들을 검토해야 했는데.. 다 이유가 있는 힘든 시기였던 것이다.

아마 나보다 그들이 더 힘들었을 것 같다..

 

예전에는 그냥 화면에 적는 일이었지만 공부를 하다보니

내가 했던 모든 게 데이터 생성이었고 데이터 관리의 출발점이었던 것 같다.

이미 그 데이터 한가운데서 일해본 사람으로서 데이터베이스가 얼마나 중요한지를 더 실감하게 된다.

 

 

마지막으로 일한 기간동안의 챗지피티와의 대화를 보고 몇 개 가져와봤다.

 

해당 스크린샷 안에는 쿼리가 총 2가지인데,

해당 일자의 입원 전 2일간 Vital Signs(체온) 과 Lab Data(CRP 라는 염증 수치) 가 eCRF에 입력되지 않았다는 걸 지적하고 있다. 내가 SAE 내용을 서술하면서 입원 2일전부터 fever(열)이 있었다고 작성했으나

eCRF 상에서 fever와 관련된 데이터(혈액검사 상 염증수치가 올라갔다던가 등의) 가 입력되어 있지 않기 때문에 입력을 하던지,

아니면 해당 날짜에 측정이 안되었다고 명확히 응답하라는 요청이다.

 

DM 입장에서는 데이터로만 상황을 판단해야 하기 때문에 아무런 정보가 작성되어 있지 않은데 fever가 있다고

어떻게 판단해? 싶었을 수 있다. 열이 났다는 것은 대상자의 진술과 자가체온기록지를 통해서 알 수 있었기 때문에

해당 부분을 입력해주고 염증 수치는 입원 시에 했던 검사로 확인했다는 것을 알려야 했고,

답변을

"Fever was noted two days prior to admission, based on the patient's self-recorded temperature log. CRP elevation was confirmed on 30-Jun upon admission."

이런 내용으로 달고 해당 쿼리는 closed 되었다.

 

가끔 같은 사건으로만 여러 개의 쿼리를 만나면 읽으면서 해석하기도 귀찮고 힘들어서

챗지피티한테 바로 물어본 것도 많았다.

ㅋㅋㅋㅋㅋㅋㅋ 뭐래?...

 

뭐래 무새...

---

✍🏻 기록

- DACON

- 백준 문제 풀이 (10951번)

- 일오갓생 

- 주말이라도 일찍 일어나서 정리한 내 자신 갓생! ✨

- 독서 (작은 땅의 야수들) Thanks to 지수

---

🍀 내 얘기

 

몇 몇 분들이 연구간호사 시절 얘기를 궁금해하시기도 해서 적어보았읍니다.

조금은 해소가 되었나요?

 

나름 헬스케어AI개발자 같이 데이터베이스의 얘기를 살려서 적어보았습니다!

보람찬 2025년의 마지막 토요일입니다. 🍀