Form Designer

• 임상 관찰과 설문 등을 기록하기 위해 사용자가 정의하고 구성할 수 있는 데이터 입력 템플릿입니다. 구성 가능한 동작과 필드 또는 폼 수준 검증을 갖는 여러 데이터 요소의 모음입니다. 각 데이터 요소는 concept에 연결되며, 데이터 요소를 set인 concept로 그룹화할 수도 있습니다. 예: 혈압(수축기와 이완기).

• 고정 초기 평가 폼: 한 번만 입력할 수 있습니다(예: 당뇨병). 반복 초기 평가 폼: 초기 평가 폼을 수정하고 다시 입력할 수 있습니다(예: 여러 결핵 사례). 추적/경과 폼.

현재 Bahmni에서는 Clinical → Patient Consultation → History & Observations 탭에 폼이 표시됩니다.

화면 예시

폼에는 단순 관찰뿐 아니라 진단, 주호소, 증상, 처방(검사실 또는 영상) 같은 임상 항목도 포함되어야 합니다.

• 폼은 관례에 따라 OpenMRS의 Concept Set으로 정의되고 애플리케이션 구성으로 구동됩니다. 이를 흔히 conceptSetUI, 기술 버전을 Forms 1.0이라고 합니다. ‘새 관찰 폼 만들기’ 문서에서 현재 절차를 볼 수 있습니다. 구축 담당자는 기록할 관찰의 concept를 OpenMRS에 만들고 concept set으로 묶은 뒤, 폼으로 표시되도록 완전 지정 이름이 ‘All Observation Templates’인 concept set of sets에 추가합니다. 이후 JSON 구성으로 UI에서 각 concept set의 동작을 정의하며, 맞춤 JavaScript 함수로 특정 필드를 검증할 수도 있습니다.

Form Builder는 구축 담당자가 각 환경의 폼을 설계하는 도구입니다. concept set을 반드시 만들고 concept set of sets에 추가해야 했던 기존 절차를 바꾸며, concept 동작을 제어하는 JSON 구성도 Form Builder에서 처리할 수 있습니다.

목업 예시:

1. Bahmni 폼 구성에 필요한 구축 담당자의 기술 지식 의존도를 낮춥니다. 각 구축에서 폼 설정 시작 시간을 줄입니다. 모든 폼 또는 폼 절을 concept set으로 만들어야 하는 의존성을 없애고 concept set 없이 UI 요소를 별도로 설계할 수 있게 합니다. 기존에는 concept를 concept set으로 묶고, 이를 concept set of sets에 추가한 뒤, 폼에서 concept 동작을 제어하는 JSON 구성을 만드는 어려움이 있었습니다.

제안 워크플로

폼 유형 선택, 요소 선택, 필드·폼 수준 검증 정의, 초안 미리 보기, 게시의 워크플로를 정의합니다.

1. 구축 담당자가 폼과 UI 요소를 정의하는 사용자 인터페이스를 제공합니다. UI 요소는 concept 데이터 유형에 연결할 수 있습니다. 예를 들어 coded concept에는 드롭다운이나 다중 선택을 사용할 수 있습니다. UI 요소의 검증도 정의할 수 있으므로 JSON 구성 파일 편집과 맞춤 JavaScript 검증 함수가 필요 없어집니다.

구축 환경 간에 폼 정의를 공유하여 각 현장의 폼 정의 시간을 줄일 수 있어야 합니다. 마스터 폼을 만들고 여러 구축 현장에서 내보내고 가져옵니다. 기존 폼을 가져와 수정할 수도 있어야 하며, 이 경우 수정본이 새 폼 정의가 되고 이전 버전은 폐기되어야 합니다.

1. Form Designer에서 레이블이 있는 필드를 끌어 놓을 수 있어야 합니다. 필드는 표시 레이블과 값을 가질 수 있습니다. 각 필드는 데이터 유형에 따른 기본 시각화를 지원해야 합니다. 예를 들어 coded concept의 기본 시각화는 드롭다운일 수 있습니다. 필드 요소에는 폼 자체, concept group(concept set), 시각적 section/container 중 하나인 부모 컨테이너가 필요합니다. 필드를 시각적 또는 관련 데이터 절로 그룹화하거나 중첩 그룹과 절을 만들 수 있습니다. 각 필드의 UI 컨트롤은 텍스트, 단일 선택 드롭다운, 다중 선택 목록, 체크박스, 라디오 버튼 또는 이미지 업로드가 될 수 있습니다. 설계 후 폼을 미리 볼 수 있어야 하며 미리 보기 모드에서는 저장할 수 없습니다.

1. 각 필드는 concept인 소스에 연결되거나 파생·자동 계산 필드여야 합니다. 예를 들어 BMI는 환자의 키와 체중으로 자동 계산됩니다. 필드는 읽기 전용으로 표시할 수 있어야 합니다. 예를 들어 처방 이행 폼의 생년월일이나 성별 같은 환자 데이터는 읽기 전용이어야 합니다. 필드는 필수이거나 다른 필드에 종속되도록 설정할 수 있어야 합니다. 다른 필드의 존재 여부에 따라 필드나 절을 활성화·비활성화하거나 표시·숨김 처리할 수 있어야 합니다. 현재 날짜·시간처럼 기본값을 가질 수 있습니다. 체중처럼 마지막 입력값을 읽기 전용으로 보여야 할 수도 있습니다. 텍스트의 긴 형식과 짧은 형식처럼 선택 가능한 시각화를 지원해야 합니다. Coded 필드는 버튼 선택, 드롭다운, 다중 선택, 자동 완성을 지원해야 합니다. 모든 필드의 레이블과 값은 국제화와 날짜·통화 형식 현지화를 지원해야 합니다. 기본 레이블은 concept 이름에서 가져오되 사용자가 덮어쓸 수 있어야 합니다.

1. 각 필드가 허용하는 데이터는 연결된 concept 소스를 기준으로 해야 합니다. 필드별 검증을 연결할 수 있으며 연결된 concept에서 검증을 파생할 수 있습니다. 런타임 JavaScript 함수와 연결된 맞춤 검증도 사용할 수 있습니다. 이메일 주소, 전화번호, 환자 ID 같은 특수 필드에는 특정 형식인지 확인하는 UI 검증이 필요합니다.

1. 현지 사이트에서 skip logic을 재정의하는 기능도 지원해야 합니다.

폼을 만들거나 수정할 때 시스템은 폼과 연결된 다음 정보를 저장해야 합니다.

1. 폼 생성 시 폼 유형을 정의할 수 있어야 합니다. 질환의 초기 평가 폼과 경과 폼을 구분해야 하며, 초기 평가 폼은 일반적으로 최신 항목이 보이도록 추가됩니다. 고정 초기 평가 폼은 한 번만 입력할 수 있고(예: 당뇨병), 반복 초기 평가 폼은 수정하고 다시 입력할 수 있으며(예: 여러 결핵 사례), 추적/경과 폼도 지원합니다.

1. 폼을 다른 Bahmni 시스템과 공유할 수 있도록 이식 가능하게 해야 합니다. 같은 encounter 데이터·세션 컨텍스트에서 폼 데이터를 수정할 수 있어야 합니다(obs.form_namespace_and_path → form ID, 산부인과와 심장 폼 양쪽의 체중). 기존 고객의 마이그레이션 전략으로 하위 호환, 기존·신규 방식 병행 또는 폼 정의 마이그레이션을 검토해야 합니다(TBD).

1. 기존 concept의 데이터 유형을 바꾸거나 폐기하면 어떻게 처리할 것인가? 기존 concept를 폐기할 때는 concept와 이전 폼 버전을 폐기하고 폼을 갱신합니다. 데이터 유형을 바꿀 때는 concept를 갱신하고 기본 검증을 적용한 뒤 폼을 갱신하고 이전 버전을 폐기합니다.

1. 폼을 입력하고 encounter 세션이 만료되면 읽기 전용이 됩니다. 진료 중에도 폼은 읽기 전용이지만 폼 표시 컨트롤의 편집 옵션으로 값을 수정할 수 있습니다.

1. 주석, 비정상 여부, 기간, 기간 단위 같은 추가 속성을 지원해야 합니다.

1. 새 값 추가(새 값 수락)를 더 직관적으로 만드는 방법을 마련합니다. 현재 방식은 필수로 유지하면서 같은 작업을 수행하는 새 방식도 제공하는 것이 좋습니다.

1. Encounter 유형을 폼에 연결할 수 있어야 합니다.