병원 API 연동의 재시도: 중복 기록과 부분 실패 다루기

응답이 없다고 서버가 처리하지 않은 것은 아닙니다

기관 API에 기록을 전송한 뒤 응답이 끊기면 요청이 처리됐는지 알기 어렵습니다. 같은 요청을 무조건 다시 보내면 중복 기록이 생길 수 있습니다. 조회와 생성·수정 요청을 구분하고 상대 시스템이 지원하는 중복 방지·조건부 처리·버전 확인 방식을 연동 명세에서 확인해야 합니다.

재시도 가능한 오류와 수정이 필요한 오류를 나눕니다

일시적 통신 실패는 대기 후 재시도할 수 있지만 필수 값 누락이나 허용되지 않는 코드는 데이터 수정이 먼저입니다. FHIR REST API의 처리 규칙을 참고하되 기관의 실제 지원 동작으로 검수하세요. 여러 기록을 전송하는 작업에서는 전체 성공과 일부 실패를 구분하고 처리된 항목을 다시 보내지 않을 기준을 마련합니다.

타임아웃 이후 원천 상태를 확인합니다

시험 서버가 저장을 완료한 뒤 응답을 지연시키는 조건을 만들어 재전송 전에 처리 여부를 확인하는지 검사합니다. 외부 기관에서 결과를 조회할 수 없다면 결과 미확인 상태로 남기고 수동 대사 절차를 두는 선택도 가능합니다. 재처리 화면에는 원천 요청 ID, 실패 이유와 시도 횟수를 표시하고 임의로 다른 환자나 기록에 연결되지 않도록 권한을 제한합니다.

검수 후 남겨둘 자료

연동 결과표에는 요청 ID, 대상 리소스, 응답 코드, 처리 상태와 재처리 이력을 연결합니다. 기관의 사용량 제한과 점검 시간을 확인해 재시도 간격을 정하세요. 자동 재시도를 중단한 항목은 운영자가 권한 안에서 조사하도록 모으고, 원본 내용을 바꿔 다시 전송했다면 수정 이유와 새 요청의 관계를 함께 보존합니다.

프로젝트에서 확인할 항목

• 조회와 기록 변경의 재시도 정책이 다른가
• 처리 완료 여부가 불명확한 상태를 표현하는가
• 부분 실패 항목만 재처리할 수 있는가

• 헬스케어 개발 범위와 사례