Найкращі практики та міркування щодо дизайну управління доглядом
Зведення
Microsoft Cloud for Healthcare включає такі рішення, як додаток Care Management, який побудований на можливостях у межах Microsoft Dynamics 365, Microsoft 365, Microsoft Azure, та Microsoft Power Platform.
Профіль пацієнта як частина рішення вимагає ретельного планування та стратегічної реалізації. У цьому посібнику ми розглянемо найкращі практики та ключові міркування щодо розробки надійного профілю пацієнта. Дотримуючись цих вказівок, виконавці можуть розкрити весь потенціал Microsoft Cloud for Healthcare і зменшити ризик помилок і помилок під час процесу проектування та розробки, оскільки вони надають чіткий набір вказівок, яких слід дотримуватися.
Розробка профілів пацієнтів, планів догляду та медичних бригад
Уніфікований сценарій профілю пацієнта надає Microsoft Cloud for Healthcare лікарням 360-градусну перспективу свого пацієнта, щоб забезпечити більш активну взаємодію з планами догляду та медичними бригадами. Рішення містить Адміністрацію, Людей (пацієнтів і практикуючих лікарів), Організації та місця, Плани догляду, Заходи Плану догляду, Цілі та шаблони Плану догляду. У цьому розділі наведено міркування щодо налаштування для кожної з цих вкладок.
Налаштування людей (пацієнтів і практикуючих лікарів)
Профіль пацієнта є основою процесу визначення та перегляду всіх планів і процедур, які будуть застосовуватися. Їх можна переглянути різними способами за допомогою програми «Керування доглядом» або Єдиного подання пацієнтів. Нижче описано деякі області, де можна переглядати або редагувати інформацію про пацієнта.
- Додаток для управління доглядом, люди: пацієнти та практикуючі лікарі.
- Спілкуйтеся зі своїми пацієнтами за допомогою чату та голосових дзвінків Microsoft Teams за допомогою Центру обслуговування пацієнтів.
- Картки статистики пацієнтів інформують вас про відповідний контекст про пацієнтів Картки статистики пацієнта.
- Уніфіковане подання пацієнтів відображає дані пацієнтів у програмах на основі моделей Dynamics 365, зокрема демографічну та клінічну дані.
Налаштування планів догляду, цілей плану догляду та шаблонів
- У категорії «Менеджер з догляду» ви можете створювати та керувати планами догляду за пацієнтами, планами догляду та цілями плану догляду. Плани, цілі та шаблони управління доглядом
- Щоб переглянути можливості покращеного плану догляду, перейдіть до розділу Покращений план догляду
Розширена програма для керування доглядом
Якщо функціональні вимоги не можуть бути задоволені за допомогою конфігураційного та low-code підходу, кожен рівень компонентів, що складають рівень архітектури рішення, може бути розширений за допомогою наведених нижче міркувань та рекомендацій щодо дизайну.
Розширення моделі даних
- Модель кероване рішення: Microsoft Cloud for Healthcare data буде встановлена як кероване рішення. Для майбутньої сумісності, а також для уникнення та вирішення проблем із сегментацією, пропонується;
- Створення нових елементів даних, коли потрібно змінити наявні керовані елементи даних.
- Додавайте лише нові або змінені компоненти рішення. Не слід вибирати параметр «Додати всі ресурси» під час додавання наявної сутності до власного рішення.
- Нові елементи даних: можна додавати нові поля до наявних таблиць і створювати нові таблиці для розширення моделі даних. Не слід змінювати наявні типи даних полів, але все одно можна додати нові параметри до наявних наборів параметрів, таких як категорії та типи, або збільшити довжину текстових полів. Ви можете отримати доступ до деталей моделі даних тут.
- Поліморфні зв’язки: Галузева модель даних включає поліморфні зв’язки, такі як ті, що містяться в таблиці «Групи», яка включає кілька підстановок. Наразі не існує жодних обмежень, які б обмежували вас у розширенні цих поліморфних зв’язків. Однак важливо зазначити, що такі розширення можуть вплинути на можливість оновлення та не рекомендуються.
- Ключ інтеграції: Використовуйте поле ключа інтеграції в таблицях для відстеження та зіставлення з основними системами.
- Довідкові таблиці: Довідкові дані – це дані, які використовуються для класифікації або категоризації інших даних. Як правило, вони статичні або повільно змінюються з часом.
Розширення інтерфейсу користувача
Заклади охорони здоров’я можуть захотіти впровадити існуючу головну систему, елементи даних у режимі реального часу та сповіщення, щоб розширити існуючий профіль пацієнта, щоб доповнити потребу в наданні цілісного уявлення про пацієнта. Ці розширення інтерфейсу користувача можуть бути розроблені з можливостями PowerApps конфігурації та налаштування.
Нові форми та подання Dynamics 365
У разі будь-яких змін у наявних формах і поданнях не змінюйте їх безпосередньо. Розгляньте можливість створення клону існуючого та внесіть бажані зміни до проблем сегментації рішень для зниження ризиків.
Елементи керування PCF
PowerApps Компонентний фреймворк дозволяє розробникам створювати компоненти коду, які можна вбудовувати як у моделі, так і в полотнові програми. Він використовує клієнтський TypeScript для доступу до даних і CSS для форматування. Специфічним застосуванням цього фреймворку є представлення фінансових даних клієнтам в інтерфейсі профілю пацієнта. Такий підхід вигідний для користувачів, підключених через пристрої та корпоративні мережі, оскільки дозволяє інтегруватися з корпоративними API без доступу до публічної хмари. Крім того, це усуває необхідність дублювання даних до Microsoft Cloud for Healthcare моделі даних.
Однак відмова від копіювання даних у модель даних обмежить використання певних вбудованих елементів керування та моделей прогноз аналітики клієнтів. Щоб усунути це обмеження, можна розглянути гібридний підхід, коли доступ у реальному часі досягається за допомогою елементів керування PCF, тоді як процедури синхронізації даних все ще реплікують дані в модель даних для інших сценаріїв.
Розширення безпеки
Microsoft Cloud for Healthcare використовує вбудовані можливості безпеки, описані Dataverse тут. Рекомендується використовувати підхід, орієнтований на конфігурацію, як показано нижче, щоб розробити модель безпеки з цими вбудованими компонентами безпеки для застосування цих правил надання прав.
Дотримуйтесь найкращих практик безпеки, наведених у посібнику із впровадження Dynamics 365, а також наведених нижче додаткових практик.
- Dataverse Безпека розроблена з правом власності, не призначайте записи та не діліться ними з окремими користувачами. Натомість розгляньте можливість призначення записів і надання спільного доступу до них командам.
- Якщо існує система записів, яка містить ці правила доступу, розгляньте можливість виконання процесу пакетної синхронізації, щоб перетворити модель власності на модель безпеки Dataverse.
- Щоб підвищити ефективність вашої моделі безпеки, розгляньте можливість використання власних команд замість команд доступу та виключіть або принаймні оптимізуйте обмін записами між різними командами.
Маскування даних і потреби в безпеці на рівні полів
Заклади охорони здоров’я часто використовують додаткові заходи безпеки для захисту конфіденційних даних, таких як номери соціального страхування (SSN), дані пацієнтів, а іноді й особисту інформацію, як-от номери мобільних телефонів та адреси електронної пошти. Ці заходи безпеки часто передбачають обмеження доступу до конкретних осіб і навіть маскування конфіденційної інформації під час відображення.
Щоб реалізувати ці вимоги безпеки, можна створити нові профілі безпеки на рівні полів, які визначають дозволи на читання, оновлення та створення дозволів для певних полів. Потім ці профілі можна призначити користувачам або командам, надаючи їм контрольований доступ до конфіденційних даних.
Крім того, якщо існують додаткові вимоги, що вимагають маскування даних, ви можете досягти цього, створивши новий стовпець PowerFX (попередній перегляд) або обчислюваний стовпець. Цей новий стовпець створить замасковану версію вихідних даних, забезпечуючи додатковий рівень захисту даних.
Потреби в автоматизації безпеки
Автоматизація безпеки є життєво важливим аспектом сучасних організацій, особливо коли ми маємо справу з безліччю користувачів і складними сценаріями. У міру того, як база користувачів розширюється, а організаційна динаміка розвивається, забезпечення надійних заходів безпеки стає все більш складним завданням. Від додавання нових користувачів до обробки змін у ролях, командах і бізнес-підрозділах, до створення нових середовищ і визначення системних адміністраторів — кожен сценарій вимагає прискіпливої уваги до захисту конфіденційних даних і критично важливих систем. У цьому контексті впровадження автоматизованих протоколів безпеки виявляється незамінним, оптимізуючи процеси, зменшуючи ризики та зміцнюючи захист організації від потенційних загроз. Впроваджуючи автоматизацію безпеки, компанії можуть ефективно адаптуватися до динамічних користувацьких ландшафтів і підтримувати гнучке та безпечне середовище, яке захищає як цінні активи, так і конфіденційність користувачів.
Нижче наведено деякі сценарії та підходи до впровадження безпеки для авторизації та автоматизації завдань.
| Сценарій | Підхід до впровадження безпеки |
|---|---|
| Коли в моделі безпеки вводяться нові персони | Кожна персона повинна бути представлена роль безпеки в динаміці з відповідними функціональними правами. Налаштуйте групову команду Dataverse для кожної персони та призначте роль безпеки для персони. Налаштуйте групові команди в Active Directory для персон і використовуйте готову інтеграцію, щоб керувати членством користувачів у групових командах Dataverse. Виключіть або мінімізуйте призначення ролей безпеки окремим особам. Змініть параметр успадкування привілеїв учасника ролей безпеки на команду «Тільки привілеї», щоб записи, які користувачі створюють з командою як власником, а не з окремими особами. |
| Коли створюються нові середовища | Для кожного Dataverse середовища має бути створена нова група безпеки, яка контролюватиме та обмежуватиме доступ користувачів до певних середовищ. В іншому випадку, той, хто має Dataverse ліцензію, буде створений як користувач у середовищі. |
| До програми додаються нові користувачі, або деяких користувачів потрібно буде видалити з програми | Замість того, щоб додавати/видаляти користувачів до кожного середовища, ви можете застосувати вкладений груповий підхід і додати групові команди (тобто relationship-manager-group) як дочірні до групи безпеки середовища (ucp-production). При такому підході, коли користувачі додаються в групову команду на певну роль, вони автоматично додаються в середовище як користувач і отримують роль. Так само, коли користувачів буде вилучено з групової команди, їх також буде вилучено з середовища, якщо вони не є частиною інших групових команд. |
| Коли наявні користувачі змінюють назву, роль або місцезнаходження, це може змінити їхню персону. | Динамічний ідентифікатор типу Microsoft Entra членства використовує бізнес-правила для динамічного керування членством у групі. Ви можете використовувати цей динамічний тип членства, щоб налаштувати бізнес-правила, щоб визначити, які користувачі будуть додані або видалені з групи, створеної для певної персони. Оскільки Dataverse зараз підтримується динамічний тип членства, ці нові або видалені учасники будуть автоматично синхронізовані для групування команд Dataverse , і користувач отримає останню роль безпеки, призначену для доступу. |
| При офбордингу користувачів | Як і вище, використовуйте динамічний тип членства, щоб додавати активних користувачів до груп. Будь-який неактивний користувач буде автоматично видалений. Ви можете використовувати робочі процеси життєвого циклу для офбордингу, які можна оновлювати та запускати з порталу Azure абоMicrosoft Graph API. |
| Коли змінюються організаційні структури | Не кожна зміна структури організації може вплинути на безпеку програми. Подумайте, як змінюватиметься право власності на дані залежно від ієрархії власності бізнес-одиниці, і відобразіть ці зміни в середовищі з оновленою конфігурацією бізнес-одиниці. |
| Коли користувачі змінювали свої команди або бізнес-підрозділи, з якими вони працюють | Пропонується використовувати динамічний тип членства та групові команди під час призначення ролей безпеки командам, а також не призначати безпосередньо ролі безпеки користувачам. З цією моделлю безпеки команди, що змінюють користувачів, не потребуватимуть автоматизації, щоб відобразити зміни, оскільки авторизація ґрунтуватиметься на членстві в групових командах. Якщо в профілі користувача потрібно змінити структурну одиницю, можна створити автоматизацію потужності, яка запускатиме зміну бізнес-одиниці в основних системах, і скористатися дією SetBusinessSystemUser , щоб перемістити користувача до іншої бізнес-одиниці. |
| Коли користувачі змінюють посаду або керівника | Ієрархічна модель безпеки є розширенням існуючих моделей безпеки, які використовують бізнес-одиниці, ролі безпеки, спільне використання та команди. Якщо це настроєно в моделі безпеки, переконайтеся, що відомості про посаду та керівника в записі користувача оновлено |
Розширення Analytics
Ви можете розширити аналітику, створивши настроювані приладні дошки, діаграми та Power BI вбудовані приладні дошки Dynamics 365, подібні до інформаційної панелі популяції пацієнтів.
Докладніші вказівки щодо розширення можливостей аналітики можна знайти в статті Operational Analytics Data State.
Розширення для спільної роботи
Елементи керування співпрацею (попередній перегляд) допомагають створювати власні можливості для співпраці, які можна переглядати безпосередньо в Teams. Існує кілька способів приєднатися до візиту залежно від уподобань опікуна. На інформаційній панелі та записах зустрічей є кнопки, за допомогою яких доглядальниця може приєднатися до зустрічі, а для отримання більш детальної інформації перегляньте досвід приєднання до віртуальної зустрічі.
Ці елементи керування дають змогу застосовувати Microsoft 365 Microsoft Teams затвердження, файли, наради, нотатки та завдання, щоб забезпечити контекстну взаємодію навколо бізнес-процесів.