한국어 번역 완료

Bahmni REST API 및 FHIR API

FHIR API 엔드포인트: Bahmni가 제공하는 FHIR 엔드포인트는 기반 OpenMRS 문서를 참조하십시오. Bahmni Lite v1.0과 최신 Bahmni에는 이러한 엔드포인트를 노출하는 OpenMRS FHIR 모듈이 포함되어 있습니다. 문서: https://fhir.openmrs.org (Patient 리소스 예: https://fhir.openmrs.org/Patient-example-openmrs-Patient.json.html) https://wiki.openmrs.org/display/projects/FHIR+Support+in+1.3.0 해당 환경에서 URL을 시험할 수 있으며 터미널 명령도 사용할 수 있습니다. bash관련 문서: Bahmni Lite 환경

# where last paremeter is UUID of the patient in Bahmni/OpenMRS
curl -u"superman:Admin123" -H "Content-Type: application/json" https://dev.lite.mybahmni.in/openmrs/ws/fhir2/R4/Patient/1457e050-06aa-4b9e-99fc-342d79e09b05

Java 클라이언트 코드에서 Bahmni/OpenMRS FHIR 엔드포인트를 호출하려면 HAPI FHIR 라이브러리를 사용할 수 있습니다. 예제: https://github.com/sivareddyp/fhir-client-demo/blob/main/src/main/java/org/bahmni/fhirclientdemo/service/FhirResourceService.java

Bahmni API 설계에 관한 오래된 메모(보관 자료) 데이터가 시스템에 구성된 방식이 아니라 사용자 관점에서 API를 설계한다면 어떤 모습일지에 대한 아이디어입니다. 세부 사항을 모두 검토한 것은 아니며 다음은 개요입니다. 리소스 일부는 다른 리소스 안에 포함될 수 있는 하위 리소스입니다. 예를 들어 treatments는 직접 접근하거나 encounter 안에 포함할 수 있습니다. Patient Profiles Visits encounter 자체를 포함하지 않지만 내부에 encounter 참조가 있으면 좋습니다. OpenMRS 리소스로 충분한지 검토해야 합니다. Clinical Encounters encounter에 방문 날짜를 비정규화하여 포함하고 방문을 가리키는 href를 둘 수 있습니다. Diagnoses Lab Investigations 검사 주문, 검체 접수, 검사 결과를 포함합니다. 너무 크다면 하위 리소스로 나눕니다. OpenELIS 교체 작업의 결과가 아직 확실하지 않습니다. Procedures Observations 시술, 검사 결과 또는 자체 리소스가 있는 항목을 제외한 OpenMRS 관찰값의 일부입니다. 서버 엔드포인트에서 필터링해야 합니다. 소비자가 쉽게 쓰도록 클래스별 처리도 달라야 합니다. 현재 Bahmni가 지원하는 관찰 클래스는 Qualified with Duration, Qualified with Normality, Multiple Coded입니다. Treatments 의약품 주문과 치료 관련 관찰값이며 active라는 특수 작업도 지원합니다. Clinical Images 성능상 속성이 아닌 하위 리소스로 둡니다. Enrolled Programs 만성 환자에게 프로그램을 사용하며 내부 encounter의 href를 포함합니다. 메타 리소스(참조 데이터) Programs Visit Types Patient Attributes Lab Tests Lab Test Panels Lab Departments Diagnosis Types Reference Terms Observation Type Groups 서로 다른 집계 관찰 클래스를 별도로 노출하여 소비자가 쉽게 사용하도록 합니다. 개념 자체를 API로 직접 노출해야 하는 사용 사례는 아직 찾지 못했습니다. Procedure Types Locations Address Elements 환자 데이터 구분 방법 리소스 범위: Visit, Date, Encounter, All For 키워드: ID를 찾기 위한 불필요한 호출을 줄입니다. 현재 목록은 LastVisit, LastVisitFoundIn, CurrentEncounter, CurrentVisit, All(기본값), Initial(In Visit), Most Recent(In Visit)입니다. 내부 또는 기술 리소스 SqlSearch Scheduled Tasks 설계 - Bahmni에 항상 포함되는 개념은 UUID 대신 이름으로 참조해야 합니다. 예: consultation note, radiology notes. - encounter types와 order types는 외부에 노출할 필요가 없으며 Bahmni 내부 요소로 둡니다. - 메타 리소스 참조에는 하이퍼링크를 사용하되 하위 리소스에는 사용하지 않습니다. 너무 많은 데이터를 불러오는 성능 문제는 하위 리소스를 직접 불러오고 범위 키워드를 사용하여 해결할 수 있습니다. - 성능상 불가능한 경우가 아니라면 사용자 트랜잭션은 서버 저장 호출 한 번으로 끝나야 합니다. - 저장 요청 데이터를 채우기 위해 ID 등을 가져오는 클라이언트 읽기 호출이 필요하지 않는 것이 이상적입니다. 예시 /patient-profiles/<patient-id> /diagnoses?patient-id=<patient-id> /observations?observation-type=vitals /treatments?patient-id=<patient-id>&for=last-visit /encounters?for=current /encounters?for=current-visit /visits 링크 http://pages.apigee.com/rs/apigee/images/api-design-ebook-2012-03.pdf 회의 메모 개념 답변과 다른 개념 집합에서 오는 답변의 처리 방법: 개념 답변은 observation type group 리소스와 함께 반환할 수 있습니다. 다른 concept-set의 답변은 전체 목록을 API로 노출하지 않고 검색하면 될 것입니다. 여러 리소스의 범위 매개변수를 정의해야 합니다. LastEncFound 키워드가 필요한가? BMI 맥락에서는 most recent 또는 recent라고 부르자는 제안이 있으며 MostRecent[Observation] 형태를 고려합니다. 검사 결과 검증을 어떻게 처리할 것인가? 병상 관리는 어떻게 할 것인가? Location은? 보고서가 필요한 모든 데이터를 얻기에 이 API가 충분한가? 위 예시에는 patient-id가 필요한 모든 곳에 들어 있지 않습니다. observation type groups를 form이라고 불러야 하는가?

원문 정보

Bahmni Wiki · CC BY-SA 4.0

원문 보기 ↗