#PUT: запись протокола

Этот endpoint реализует ваша МИС. Smartica вызывает его асинхронно после подготовки полной стенограммы и значений полей.

Используется метод PUT. POST и PATCH текущим адаптером не вызываются.

#Запрос Smartica

PUT /api/smartica/encounters/12345 HTTP/1.1
Host: mis.example.ru
Authorization: Basic <base64(login:password)>
Content-Type: application/json; charset=utf-8
Accept: application/json

{
  "encounter_id": "12345",
  "fields": [
    {
      "id": "complaints",
      "value": "Жалобы на головную боль..."
    },
    {
      "id": "diagnosis_primary",
      "value": "Гипертоническая болезнь I ст."
    }
  ],
  "transcript": "Полная стенограмма разговора врача и пациента..."
}

audio не входит в текущий payload.

#Семантика обновления

Обрабатывайте запрос как upsert существующего приёма по encounter_id:

1. Найдите карточку приёма по ID из URL.
2. Убедитесь, что encounter_id в JSON совпадает с URL.
3. Для каждого элемента fields обновите поле с таким id.
4. Поля, отсутствующие в массиве, не очищайте.
5. Сохраните transcript как актуальную полную версию, заменив предыдущую.
6. Зафиксируйте результат в одной транзакции, если это поддерживает МИС.

Smartica не отправляет поля без содержательных данных. Значения "", "не указано" и "отсутствует" отбрасываются, поэтому fields: [] является валидным запросом: стенограмму всё равно нужно сохранить.

value может содержать переводы строк и Markdown-списки. Сохраняйте Unicode и многострочный текст без потери. Если МИС отображает HTML, экранируйте или санитизируйте значение на своей стороне.

#Идемпотентность

Отдельного Idempotency-Key в текущем контракте нет. Ключ операции — encounter_id.

Одинаковый PUT может прийти повторно:

• после ручного повтора врачом;
• после повторной записи в том же приёме;
• после повторной генерации результата;
• после изменения механизма доставки в будущих версиях.

Требуемое поведение:

• одинаковый payload не создаёт новую карточку, протокол или вложение;
• изменённые переданные поля обновляются;
• стенограмма заменяется полной версией из последнего успешного запроса;
• ответ остаётся успешным, если данные уже сохранены.

Не рассчитывайте на exactly-once доставку.

#Успешный ответ

Верните 200 OK и JSON-объект:

{
  "encounter_id": "12345",
  "status": "saved"
}

Smartica проверяет успешный HTTP-код и наличие валидного JSON. Значения полей ответа сейчас не используются, но рекомендуемый формат облегчает диагностику.

Не возвращайте:

• 204 No Content;
• пустое тело;
• HTML-страницу;
• текст, который не декодируется как JSON.

#Ошибки

Для ошибки верните подходящий non-2xx и безопасный JSON:

{
  "message": "Приём закрыт для изменения"
}

При non-2xx, timeout или невалидном JSON отправка помечается ошибкой. Врач может повторить её из Smartica. Автоматический сетевой retry для каждого 5xx не гарантирован.

Не возвращайте в message stack trace, SQL, credentials или внутренние сведения о пациенте.

#Проверка через curl

curl --fail-with-body --silent --show-error \
  --request PUT \
  --user 'LOGIN:PASSWORD' \
  --header 'Content-Type: application/json; charset=utf-8' \
  --header 'Accept: application/json' \
  --data '{
    "encounter_id": "12345",
    "fields": [
      {
        "id": "complaints",
        "value": "Тестовые жалобы"
      },
      {
        "id": "diagnosis_primary",
        "value": "Тестовый диагноз"
      }
    ],
    "transcript": "Тестовая стенограмма..."
  }' \
  'https://mis.example.ru/api/smartica/encounters/12345'

Выполните команду дважды и проверьте, что в МИС остался один обновлённый приём.

#Аудиофайл

Аудиозапись не передаётся в текущем GET/PUT-контракте. Если она нужна вашей МИС, согласуйте отдельное расширение при онбординге; не добавляйте поле audio в базовый payload самостоятельно.

#Связанные статьи

• GET: контекст приёма
• Запуск из МИС
• Авторизация, ошибки и повторная доставка