Dofamine — двусторонняя синхронизация с МИС клиники

Dofamine — двусторонняя синхронизация с МИС клиники

Кто чей source of truth и какие события летят между МИС клиники и нашей платформой. МИС — юридическая правда (паспорт, визиты, заключения). Мы — непрерывная правда (wearables, AI, decision trail, roadmap). Сценарий: новый пациент → визит → AI flow → возврат в МИС.

Key · @kuzminykh_igor_b3550a9b

0 звёзд

1 просмотр

только что · последнее обновление

Key

dofamine-mis-sync.js

Loading canvas…

Обзор

Двусторонняя синхронизация между МИС клиники и платформой Дофамин. Диаграмма отвечает на вопрос «у клиники же уже есть данные о пациенте, зачем дублировать?». Не дублируем — разделяем source of truth и обмениваемся событиями.

Кто чей источник правды

Тип данных	Источник правды	Где у нас
ФИО, паспорт, полис, контакты	МИС (нормативка, биллинг)	read-only реплика
Визиты и заключения врача (КЭП)	МИС (юр. документ)	реплика + ссылка
Препараты, выписанные на визите	МИС	реплика + расписание приёма
Лаб-результаты внутренней лабы	МИС	через коннектор
Лаб-результаты внешних партнёров	Helix/Invitro/Гемотест	напрямую, мимо МИС
Wearable снапшоты (HRV/RHR/сон/шаги)	Apple Health / Health Connect	у нас, мимо МИС
Геномика (VCF)	Atlas/Genotek	изолированно, мимо МИС
AI-предложения и reasoning	Мы	`ai_proposals`
Decision trail (AI→врач→пациент)	Мы	`doctor_decisions` + audit
Roadmap, daily focus, журнал	Мы	`pg-main`
Granular consent	Мы	`consent_grants`

Тип данных

Источник правды

Где у нас

ФИО, паспорт, полис, контакты

МИС (нормативка, биллинг)

read-only реплика

Визиты и заключения врача (КЭП)

МИС (юр. документ)

реплика + ссылка

Препараты, выписанные на визите

МИС

реплика + расписание приёма

Лаб-результаты внутренней лабы

МИС

через коннектор

Лаб-результаты внешних партнёров

Helix/Invitro/Гемотест

напрямую, мимо МИС

Wearable снапшоты (HRV/RHR/сон/шаги)

Apple Health / Health Connect

у нас, мимо МИС

Геномика (VCF)

Atlas/Genotek

изолированно, мимо МИС

AI-предложения и reasoning

Мы

ai_proposals

Decision trail (AI→врач→пациент)

Мы

doctor_decisions + audit

Roadmap, daily focus, журнал

Мы

pg-main

Granular consent

Мы

consent_grants

Компоненты

Узел	Роль
`mis-registry`	Регистратура МИС — оператор заводит нового пациента.
`mis-encounters`	Encounters МИС: визиты, расписание.
`mis-clinical-notes`	Заключения врачей в МИС, подписанные КЭП.
`mis-prescriptions`	Назначения препаратов на визитах.
`mis-internal-lab`	Внутренняя лаба клиники.
`mis-connector`	Двусторонний адаптер МИС (зависит от вендора).
`fhir-transform`	Нормализация в FHIR R4 — один формат внутри нас.
`pg-main`	Основной Postgres платформы.
`ai-agents`	Мультиагентная обвязка над LLM.
`doctor-cabinet`	Веб-кабинет Анны П.
`audit-log`	Append-only журнал решений.
`patient-app`	Flutter-приложение пациента.
`healthkit` / `helix-labs` / `genomics-partner`	Внешние источники, минующие МИС (контекст).

Узел

Роль

mis-registry

Регистратура МИС — оператор заводит нового пациента.

mis-encounters

Encounters МИС: визиты, расписание.

mis-clinical-notes

Заключения врачей в МИС, подписанные КЭП.

mis-prescriptions

Назначения препаратов на визитах.

mis-internal-lab

Внутренняя лаба клиники.

mis-connector

Двусторонний адаптер МИС (зависит от вендора).

fhir-transform

Нормализация в FHIR R4 — один формат внутри нас.

pg-main

Основной Postgres платформы.

ai-agents

Мультиагентная обвязка над LLM.

doctor-cabinet

Веб-кабинет Анны П.

audit-log

Append-only журнал решений.

patient-app

Flutter-приложение пациента.

healthkit / helix-labs / genomics-partner

Внешние источники, минующие МИС (контекст).

Сценарий анимации (17 шагов)

Полный путь данных «новый пациент → первый визит → AI-flow → возврат заметки в МИС»:

Фаза 1, МИС→нас ([1]–[4]): оператор клиники завёл пациента в МИС → patient.created → коннектор → FHIR Patient → у нас создаётся patients с mis_patient_id как foreign-key.

Фаза 2, МИС→нас ([5]–[8]): первый визит у Анны П. — encounter.created, заключение note.signed (КЭП в МИС) — попадает к нам как read-only копия со ссылкой на оригинал.

Фаза 3, внутри нас ([9]–[10]): AI-агенты подтягивают контекст (включая wearables от WHOOP через HealthKit) и кладут предложение в doctor_queue.

Фаза 4, нас→МИС ([11]–[15]): Анна П. одобряет в нашем кабинете → doctor_decision сохранён → попадает в audit → возвращается в МИС как DocumentReference (AI-обзор Анны П., видный в карте пациента другим врачам клиники).

Фаза 5, мимо МИС ([16]–[17]): wearables и внешние лабы приходят к нам напрямую — это автономные потоки данных, не требующие участия МИС.

Trade-offs

mis_patient_id как foreign-key. Любая наша запись пациента — это «прокси» к МИС-карте. Если МИС упадёт — у нас остаются wearables/AI данные, но нельзя завести нового пациента. Это правильно: новый пациент = регистрация в клинике, не «скачал app».

Заключения врача — read-only. Мы не редактируем мед.документы — только присоединяем AI-обзор как DocumentReference. КЭП пишется только в МИС. Это снимает требование к нам встраивать КЭП-инфраструктуру (отдельный TBD-вопрос для встречи с Юлей).

Wearables/лабы/геномика — мимо МИС. Эти данные у нас не дублируют МИС, а расширяют картину пациента. МИС всё равно может их получить через DocumentReference (если клинике это нужно для документации).

Открытые вопросы (к Юле)

Какая МИС? 1С

/ qMS / ArchiMed+ / другое — узел mis-connector сейчас абстрактен. См. CONTEXT.md → «Вопросы к Юле».

Юр. модель заключения. Если врач пишет заключение в нашем кабинете, нам нужен свой КЭП-сервис. Если только в МИС — нет.

Платёжная модель. На диаграмме не показана (отдельный модуль apps/admin/billing — пока заглушка).