UDENTIVA впаивает искомую зрелость процессов для медицинского ПО в саму архитектуру. Эта страница представляет с доказательствами наш жизненный цикл разработки, уровни зрелости SPICE / ISO-IEC 15504, наши механизмы непрерывного логирования ошибок и контроля, наши критерии версий и безопасности и нашу историю разработки.
Основание: Положение о системах управления медицинской информацией (MevzuatNo 39682) ст.6 и ст.20 — требование сертификации качества ПО (CMMI/SPICE).
Определение процессов, их реализация и прослеживаемые рабочие продукты структурированы; механизмы количественного измерения, предотвращения дефектов и непрерывного улучшения работают в промышленной эксплуатации. Официальное заявление об уровне зрелости подлежит независимой оценке (appraisal).
SPICE оценивает процессы по уровню зрелости от 0 до 5. UDENTIVA выстроена так, чтобы соответствовать ожиданиям Уровней 1-3 на уровне определения процессов, их выполнения и отслеживаемых рабочих продуктов; для Уровней 4-5 функционируют механизмы количественного измерения и непрерывного улучшения. Официальное заявление об уровне подлежит независимой оценке.
Механизмы количественного контроля и непрерывного улучшения, относящиеся к Уровням 4-5, функционируют ниже с доказательствами (живое измерение, журнал ошибок/CAPA, записи о развёртываниях).
Каждая область процесса соответствует конкретной реализации в UDENTIVA и проверяемому доказательству. Процесс — это не документ, а работающий код.
| Область процесса | Приложение UDENTIVA | Доказательство |
|---|---|---|
| ENG.1 Извлечение требований | Карта фаз + определение требований по вертикальным срезам; проектный договор UDENTIVA.md фиксирует требования. | UDENTIVA.md (ЗОЛОТЫЕ ПРАВИЛА), техническая спецификация 02_tech_spec/, карта фаз/модулей |
| ENG.4 Проектирование ПО | Модульный монолит; пакеты контекстов не делят таблицы друг друга; взаимодействие через interface; внешний сервис = adapter. | правило границ internal/{identity,patient,billing,export,...}; ADR-001..008 |
| ENG.5 Разработка ПО | Явный SQL (sqlc, без ORM); context — первый параметр в каждой функции; обёртка ошибок %w; деньги = numeric. | переопределение типа в sqlc.yaml (numeric→string), db/queries/*.sql, gofmt/golangci-lint |
| ENG.6 Интеграция ПО | Loopback-цепочка PHP(BFF) ↔ Go ↔ PostgreSQL ↔ Redis; единственная публичная поверхность. | web/core/ApiClient, /healthz — состояние компонентов (db+redis) |
| ENG.7 Тестирование ПО | Тест изоляции между арендаторами (наиболее критичный), idempotency, конфликты записи на приём, точность денежных расчётов, 2FA/OTP, тест-вектор TOTP RFC6238, QR (проверка OpenCV+ISO). | internal/integration/*_test.go, platform/totp/totp_test.go, go test ./... |
| SUP.1 Обеспечение качества | Каждый PR обязан соответствовать ЗОЛОТЫМ ПРАВИЛАМ; lint чист; если тест изоляции красный в CI — слияние запрещено. | golangci-lint, Definition of Done kontrol listesi |
| SUP.8 Управление конфигурацией | Контроль версий Git (ветка core); последовательное версионирование схемы goose; артефакты сборки резервируются. | git, goose_db_version tablosu, .tools/deploy yedekleri |
| SUP.9 Решение проблем | Аудит-журнал только на добавление (append-only) + outbox эл. почты/SMS (запись каждой отправки) + дисциплина резервирования/отката развёртывания. | audit_log, email_outbox/sms_outbox, bin/server.exe.bak-* rollback |
| SUP.10 Управление запросами на изменение | Каждое изменение схемы — новая пронумерованная migration; обратимая (goose Down); одобрение классификатора развёртывания. | db/migrations/0001..0027, +goose Up/Down |
| MAN.3 Управление проектом | Поставка вертикальными срезами (каждый срез работает от начала до конца); заметки о передаче сессий. | super-devam.md, faz tablosu (DoD per dilim) |
| MAN.6 Измерение | Проверка работоспособности, измерение ёмкости, метрики отправки эл. почты/SMS, объём аудита, телеметрия событий в реальном времени. | /healthz, панель мониторинга процессов и качества (события/ошибки/развёртывание/KPI) |
Обязанности разделены по слоям; авторитет предметной области находится в одной точке и изолирован через loopback. Браузер видит только тонкий BFF и никогда не может напрямую обратиться к слою предметной области и данных.
| Слой | Ответственность и безопасность | Локация |
|---|---|---|
| Sunum (BFF) | PHP 8.4 — тонкий BFF: сессия, рендеринг, CSRF, маршрутизация. Бизнес-логики/БД НЕТ. Единственная публичная поверхность (IIS:443). | web/ |
| Uygulama / Domain | Go модульный монолит — ЕДИНСТВЕННЫЙ авторитет домена. RBAC, бизнес-правила, транзакции. Слушает только 127.0.0.1. | api/internal/ |
| Veri | PostgreSQL — в каждой таблице tenant_id + RLS FORCE; явный SQL (sqlc), параметризованный. Деньги numeric. | api/db/ |
| Кэш / Очередь | Redis — сессия, idempotency, распределённая блокировка, очередь asynq (SMS/e-fatura). | platform/redisx |
| Nesne Depolama | S3-совместимое — большие файлы (рентген) presigned/stream; blob никогда не в БД. | platform/storage |
| Внешний сервис (adapter) | e-Fatura, SMS (NetGSM), эл. почта (SMTP), (в будущем e-Nabız/MEDULA/DICOM) — абстрагированы за interface. | internal/notify |
Измерение — не декларация, а работающая система. Все операции считаются в реальном времени (успех/неудача), производственные ошибки фиксируются в постоянном журнале, а рамка KPI ниже привязана к периодическим действиям. Источники данных — реальные таблицы: event_counter (живой счётчик операций), error_log (постоянный журнал ошибок), deploy_log (журнал деплоев).
| Область измерения | KPI | Цель | Источник данных | Период | Действие |
|---|---|---|---|---|---|
| Безопасность изоляции арендаторов (tenant) | cross-tenant test fail | 0 | CI / izolasyon testi | her PR | Блокировка слияния |
| Производственная ошибка | явная ошибка (5xx/panic) | 0 | error_log (постоянный) | непрерывно/в реальном времени | RCA + CAPA zorunlu |
| Доля успешных операций | success / toplam event | ≥ 99 % | event_counter (в реальном времени) | непрерывно/в реальном времени | Корневая причина при снижении |
| Время устранения | MTTR (ср. время устранения) | ↓ убывающий тренд | error_log (resolved) | ежемесячно | Trend incelemesi |
| Надёжность развёртывания | доля откатов (rollback) | < %5 | deploy_log | 30 дней | Rollback review |
| Безопасность идентификации | 2FA/OTP kritik olay | 0 | audit + event_counter | ежемесячно | Усиление защиты |
| Надёжность обмена сообщениями | SMS/e-posta failure | ↓ низкая | *_outbox | день | Проверка провайдера |
| Готовность к восстановлению | успешность тестов восстановления | %100 | DR test (hedef) | ежеквартально | Обновить Runbook |
Каждая производственная ошибка проходит стандартный цикл анализа первопричины (RCA) и корректирующего/предупреждающего действия (CAPA); повторение той же ошибки предотвращается регрессионным контролем и отслеживанием трендов.
Производственные ошибки (5xx/panic) перехватываются автоматически → постоянный error_log (при повторе той же сигнатуры count++, тренд дефектов).
Определяется уровень (error/panic), влияние и число повторов; распространённость измеряется счётчиками неуспешных событий.
Анализ корневых причин выполняется и фиксируется на панели мониторинга процессов.
Определяются и фиксируются корректирующее и предупреждающее действия (код, тест, правило migration, контроль безопасности).
Добавляется тест/правило, предотвращающее повтор той же ошибки; отслеживается непрерывной телеметрией.
Тренды KPI (MTTR, доля ошибок, rollback) периодически оцениваются; для повторяющихся ошибок открывается действие на уровне процесса.
Суть SPICE Уровня 5: непрерывное логирование ошибок, удержание их под контролем, предотвращение дефектов и непрерывное улучшение. UDENTIVA эксплуатирует эти механизмы в продакшене.
Неизменяемый (append-only) audit_log фиксирует каждую критическую операцию; email_outbox/sms_outbox — каждую отправку (status, attempts, error). Ни одно событие не теряется незаметно.
Единообразная оболочка ошибок {error:{code,message}}; внутренние ошибки/stack никогда не раскрываются. Перед каждым развёртыванием — резервная копия binary + web; при простое откат за секунды через bin/server.exe.bak-*.
Архитектура fail-closed: без контекста RLS — 0 строк; idempotency предотвращает двойную операцию; numeric делает ошибку с float-деньгами невозможной; whitelist (набор данных экспорта) предотвращает SQL-инъекцию. Ошибки предотвращаются на этапе проектирования.
Критические компоненты проверяются двумя независимыми методами: тест-вектор TOTP RFC6238, для QR — декодирование OpenCV cv2 + эталонное кодовое слово ISO/IEC 18004, тест изоляции между арендаторами.
В каждой сессии аудит безопасности → выводы → усиление защиты (напр. добавлены RBAC фазы 2/фазы 3, 2FA, Export API). Корпоративная память сохраняется в процессных заметках (super-devam.md).
Новое регуляторное требование (VEM Görüntüsü) напрямую преобразуется в функцию продукта и доказательства; изменения законодательства непрерывно отслеживаются и вносятся в карту соответствия.
Одна кодовая база, сужение флагом — без форков.
Отслеживаемая версия на уровне схемы, источника, деплоя и API.
Весь процесс разработки под контролем версий; каждый деплой обратим (rewind/rollback).
Безопасность — не функция, а сама архитектура. Правила, нарушение которых означает отклонение PR и которые не подлежат обсуждению:
Система построена вертикальными срезами, каждый из которых работает от начала до конца. Ниже приведены фазы и хронология недавних работ по безопасности/регулированию.
pgx+sqlc, goose, тест fail-closed RLS, WithTenantTx, middleware сессий, вход+RBAC, аудит, loopback PHP↔Go, база asynq, health.
CRUD пациентов + тест изоляции между арендаторами → Приёмы (exclusion constraint + блокировка Redis) → Одонтограмма/План лечения (FDI, append-only) → Инкассация/Взаиморасчёты/Касса (derive, idempotent) → adapter e-Fatura (fast-follow) → Склад → Рентген (S3) → SMS-напоминания (asynq backoff).
Уровень платформенного оператора (супер-админ) (X-Platform-Key, отдельная плоскость идентификации); управление арендаторами, модель подписки/выставления счетов, измерение ёмкости, редактор правовых версий, reCAPTCHA, настройки NetGSM.
i18n (20 dil, key-based, RTL); 20 tema + klinik public site (/s/{slug}) + lead-booking; demo klinik siteleri.
Общий примитив OTP; сброс пароля + magic-link + активация учётной записи (реальный SMTP); ядро SMS NetGSM; мультиарендная публичная авторизация; управление пользователями клиники.
TOTP (RFC6238) + резервные коды; ОБЯЗАТЕЛЬНЫЙ QR (без внешних зависимостей, CSP-чистый qr.js; независимо проверен через OpenCV+ISO); подтверждение телефона по SMS (согласие KVKK).
VEM Görüntüsü (Минимальная модель данных) — 12 export view + Export API (задаётся SuperUser, привязан к арендатору, fail-closed); карта соответствия «Законодательство»; пересмотр правовых договоров на 100 % под требования законодательства.
Центр поддержки с отслеживанием тикетов; документация процессов SPICE (эта страница); непрерывный аудит безопасности + усиление защиты.
За подробной информацией об архитектуре, безопасности и соответствии регулированию свяжитесь с нашей командой.
We use cookies necessary for core functionality; analytics and marketing cookies are enabled only with your consent. Политика использования cookie