Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
tema15.doc
Скачиваний:
52
Добавлен:
15.02.2016
Размер:
469.5 Кб
Скачать

Питання безпеки

Інформаційні системи у ОЗ працюють із надзвичайно особистими даними, що накладає жорсткі вимоги до безпеки таких систем. Тільки авторизовані постачальники медичної допомоги повинні мати доступ до даних пацієнтів. З іншого боку, система безпеки неповинна заважати щоденній роботі медпрацівників.

Наступний перелік резюмує декілька питань безпеки, які потрібно вирішити при впровадженні госпітальної інформаційної системи та ЕМК:

  • підтвердження автентичності користувачів та права доступу;

  • управління сесіями та єдиний вхід в систему;

  • дані перевірки та історія версій;

  • адміністрування користувачів;

  • шифрування бази даних та резервних копій;

  • шифрування мереженого трафіку;

  • фізична безпека;

Архітектура безпеки даних

Архітектура безпеки даних повинна бути спланована таким чином, щоб вона підходила і регіональним системам, і основним локальним інформаційним системам. Елементи безпечної комунікації наведено на рисунку нижче:

Підтвердження автентичності означає, що користувач буде перевірятися не лише на початку сесії, але також під час неї. Підтвердження автентичності користувача повинно бути достатньо надійним, але незанадто обтяжливим. Користування без підтвердження автентичності має бути можливим тільки там, де немає необхідності у високому рівні захисту. В майбутньому має бути можливість єдиного входу в систему.

Технічні рішення для підтвердження автентичності:

• логін та пароль користувача;

• пароль на одну сесію;

• віддалене підтвердження автентичності;

• ІВК та смарт-карта;

• національне рішення та послуги смарт-карт ІВК;

• національне підтвердження автентичності ролей користувачів та послуги;

Після підтвердження автентичності користувача, роль цього користувача повинна перевірятися з використанням ролевих служб. Цей сервіс визначає розділ організації та підрозділи, а також значення цієї сесії. Також необхідна перевірка посади (напр. лікар, медсестра) та прав користувача, що відносяться до такої посади, якщо рецепти або довідки будуть видаватися пацієнту. Інтерфейс такого сервісу має бути стандартизований. Система реєструє, підписує та зберігає дозволи пацієнтів через використання бази даних дозволів.

Зміст даних дозволу:

• чиїх файлів стосується дозвіл (напр.ім’я та ІН)

• хто надав дозвіл (напр.ім’я та ІН)

• хто може використовувати інформацію (ідентифікація того, хто зробив запит)

• які файли включені в дозвіл (ідентифікація файлів)

• відділення, яке надавало лікування (код ІО)

• час лікування

• продовження допомоги (ідентифікація ланцюгу лікування)

• на який часовий інтервал надано дозвіл

• електронний підпис особи, що надала дозвіл

У відкритих та швидких мережах і запити, і дані ЕМК можуть зберігатись у основних інформаційних системах, у базах даних запитів, у копіях баз даних або у архівах.

Документація даних перевірки та історія версій

Дуже важливими аспектами безпеки даних є відповідна система документації даних перевірки та історії версій. Вона надає інформацію про оновлення даних у медичних інформаційних системах: що було змінено, коли та ким. Факультативно можна також додати причину змін. Роль користувача, під час внесення змін повинна записуватися також, оскільки один і той самий користувач може мати різні ролі у системі.

Сервери даних перевірки:

• пацієнт-центричні дані перевірки

• дані перевірки по функціях

• дані перевірки по користувачах

Важливо, щоб інформація перевірки даних записувалася до бази даних, яку неможливо модифікувати.

Сучасні системи баз даних шифрують дані під час запису до бази даних або витягування даних з бази. Таке шифрування та дешифрування відбувається «находу» та абсолютно прозоре для користувача або розробника медичних інформаційних систем. Окремий файл, що містить ключ шифру бази даних, це все що потрібно, тож, звичайно, логічна та фізична безпека файлу ключа шифру дуже важлива.

Резервні копії даних можна розглядати як частину безпеки даних, оскільки вони забезпечують цілісність в разі відновлення після збою. Якщо бази даних шифруються, резервні копії також повинні шифруватися, інакше безпека даних буде під загрозою. За відповідного втілення, неавторизований доступ до медичних даних неможливий навіть через використання офф-лайн носіїв резервних копій. Також, стосовно резервного копіювання, нижче наведено перелік питань, які часто отримують менше уваги, ніж слід:

• резервне копіювання повинно бути достатньо регулярним;

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

• ротація носіїв резервного копіювання;

• створення повних та додаткових резервних образів, зображень, (snap-shot)

• зберігання носіїв резервного копіювання поза територією лікарні, на випадок фізичного лиха;

• локальне зберігання у вогнестійких сейфах;

• відновлення резервних копій повинне перевірятися регулярно;

• інші питання безпеки, пов’язані із резервним копіюванням, включно із фізичною безпекою (авторизації).

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]