Программное обеспечение для ведения базы данных о пациентах, ПО для врачей Опции

[Sancho]

Никому не попадались программы для ведения базы данных о пациентах (другими словами, программное обеспечение для клиник), где бы можно было вносить диагнозы, назначаемое лечение, дату повторного визита и пр.?
Или дайте ссылки на эти ресурсы (желательно бесплатные) или тематические форумы.
Заранее спасибо.

P.S.: может быть это вопрос и не для этой ветки форума, но более подходящей я не нашел

[Игорь]

В связи с вступлением в силу с 1 января 2010 года законодательства о персональных данных всю представленную в теме информацию о госпитальных информационных системах следует дезавуировать. В настоящее время ни одна (!) госпитальная система, эксплуатирующаяся на территории России, не соответствует требованиям и не сертифицирована в установленном законом порядке в ФСТЭК (т.е. отсутствует в списке сертифицированных продуктов на сайте ФСТЭК). Следовательно, начиная с указанного выше срока, эксплуатация всех госпитальных информационных систем во всех клиниках России незаконна, подпадает под действие Кодекса об административных правонарушениях со всеми вытекающими правовыми последствиями для руководства клиник и должна быть прекращена.

Если уважаемых коллег заинтересовала данная информация, могу предоставить все необходимые ссылки на информационные ресурсы (за исключением 4-х документов ФСТЭК с грифом ДСП).

Приглашаю также обсудить меры по решению проблемы.

Сообщение отредактировал Игорь - 16.05.2009 - 14:46

[Igoroshka]

В связи с вступлением в силу с 1 января 2010 года законодательства о персональных данных всю представленную в теме информацию о госпитальных информационных системах следует дезавуировать. В настоящее время ни одна (!) госпитальная система, эксплуатирующаяся на территории России, не соответствует требованиям и не сертифицирована в установленном законом порядке в ФСТЭК (т.е. отсутствует в списке сертифицированных продуктов на сайте ФСТЭК). Следовательно, начиная с указанного выше срока, эксплуатация всех госпитальных информационных систем во всех клиниках России незаконна, подпадает под действие Кодекса об административных правонарушениях со всеми вытекающими правовыми последствиями для руководства клиник и должна быть прекращена.

Если уважаемых коллег заинтересовала данная информация, могу предоставить все необходимые ссылки на информационные ресурсы (за исключением 4-х документов ФСТЭК с грифом ДСП).

Приглашаю также обсудить меры по решению проблемы.

Было бы интересно познакомиться с такими документами. У нас (Белоруссия) пока до этого дело не дошло (к сожалению). Но, думаю, вскоре также будут подвижки в этом направлении.

По существу.
Вся информация госпитальной системы хранится в БД. Рискну предположить, что для более-менее крупной системы это будет из коммерческих: MS SQL сервер, Oracle, 4D, из бесплатных: mysql, PostgreSQL.
Как мне видится, в случае MS SQL сервер, Oracle проблема хранения, регламентации доступа прозрачно решается на уровне сервера и/или сервера приложений (возможно, с приобритением дополнительных модулей). В случае с Oracle регламентация может вестить "в особо извращенном виде ". Однако, скорее всего, прийдется изменять представления (если приложение написано нормально) или править запросы, что гораздо хуже.
При использовании mysql, PostgreSQL Нужно будет шифровать поля с персональной информацией и реализовывать механизм организации доступа. Это приличные переделки в ПО.

Остается открытым вопрос передачи персональных данных по сети. В случае с Oracle есть прозрачное решение. Как в SQL server -- не знаю.

[Игорь]

Было бы интересно познакомиться с такими документами. У нас (Белоруссия) пока до этого дело не дошло (к сожалению). Но, думаю, вскоре также будут подвижки в этом направлении.

К сожалению? Святая наивность! http://www.iksmedia.ru/blogs/post/449145.html Это еще минимально радикальное мнение.

Я уже цитировал п. 1 ст. 22 Закона 152. Процитирую п. 2 этой же статьи: "Оператор вправе осуществлять без уведомления уполномоченного органа по защите прав субъектов персональных данных обработку персональных данных: ... 2) полученных оператором в связи с заключением договора, стороной которого является субъект персональных данных, если персональные данные не распространяются, а также не предоставляются третьим лицам без согласия субъекта персональных данных и используются оператором исключительно для исполнения указанного договора и заключения договоров с субъектом персональных данных; ...". Т.е., достаточно заключить с пациентом договор (а многие клиники так и делают) на оказание медицинских услуг - и можно использовать для информационной защиты стандартные (возможно, несертифицированные), но эффективные средства, не получать лицензию на защиту информации и т.д. Кстати, в договоре учесть согласие на передачу данных в установленном законом порядке. Наверное, это является основанием того, чтобы все существующие медицинские информационные системы (МИС) могли быть выведены "из-под удара" Закона. Это мое личное мнение.

Однако некоторые авторы так не считают, а напротив, утверждают, что МИСам должна быть установлена максимально возможная конфиденциальность и максимальная группа по защите персональной информации (= максимально возможные затраты, ведущие к полной нереализуемости МИСов в существующих условиях, что, впрочем, самими авторами и признается). См., например, http://www.consultant.ru/online/base/?req=...MED;n=31473;p=1, а также http://www.consultant.ru/online/base/?req=...ase=MED;n=29496.

Сообщение отредактировал Игорь - 3.06.2009 - 18:00

[плав]

К сожалению? Святая наивность! http://www.iksmedia.ru/blogs/post/449145.html Это еще минимально радикальное мнение.

Я уже цитировал п. 1 ст. 22 Закона 152. Процитирую п. 2 этой же статьи: "Оператор вправе осуществлять без уведомления уполномоченного органа по защите прав субъектов персональных данных обработку персональных данных: ... 2) полученных оператором в связи с заключением договора, стороной которого является субъект персональных данных, если персональные данные не распространяются, а также не предоставляются третьим лицам без согласия субъекта персональных данных и используются оператором исключительно для исполнения указанного договора и заключения договоров с субъектом персональных данных; ...". Т.е., достаточно заключить с пациентом договор (а многие клиники так и делают) на оказание медицинских услуг - и можно использовать для информационной защиты стандартные (возможно, несертифицированные), но эффективные средства, не получать лицензию на защиту информации и т.д. Кстати, в договоре учесть согласие на передачу данных в установленном законом порядке. Наверное, это является основанием того, чтобы все существующие медицинские информационные системы (МИС) могли быть выведены "из-под удара" Закона. Это мое личное мнение.

Боюсь, что так легко не получится. Данная фраза об отсутствии уведомления не снимает всех требований к информационной защите, т.е. лицензионные органы могут просто проверить, насколько МИС исполняет требования 152 закона и связанных с ним подзаконных актов, даже если уведомления и не было. Во-вторых, договор будет только относительно платных услуг, а их в медицине меньшинство и большая часть ОМС и ДМС не будет прикрываться даже этой лазейкой.
Кроме того, конструкция статьи предполагает информацию, относящуюся к договору (в связи с заключением), т.е. законодатель имел в виду то, что содержится в договоре, а не дополнительную информацию, получаемую в ходе работ выполняемых и предоставляемых услуг по договору.

[Игорь]

А вот еще проблема, на которую указали коллеги. Это - современное медицинское оборудование: томографы, цифровые рентгеновские аппараты, УЗИ и т.д. Все эти аппараты содержат встроенные компютеры и встроенные базы данных по пациентам. Уверен, что ни один из этих аппаратов должным образом не сертифицирован. И вряд ли возможно такую сертификацию провести (не повезете же вы томограф весом 5 тонн в соседний город на сертификацию).

Сообщение отредактировал Игорь - 4.06.2009 - 07:25

[плав]

А вот еще проблема, на которую указали коллеги. Это - современное медицинское оборудование: томографы, цифровые рентгеновские аппараты, УЗИ и т.д. Все эти аппараты содержат встроенные компютеры и встроенные базы данных по пациентам. Уверен, что ни один из этих аппаратов должным образом не сертифицирован. И вряд ли возможно такую сертификацию провести (не повезете же вы томограф весом 5 тонн в соседний город на сертификацию).

Ну, вот это не проблема - Вы же сами предлагали решение - вместо фамилии случайный код, расшифровка которого хранится только в истории болезни

[Igoroshka]

Ну, вот это не проблема - Вы же сами предлагали решение - вместо фамилии случайный код, расшифровка которого хранится только в истории болезни

В любой БД ФИО хранится только как информационное поле (правда, может использоваться для связывания с другими БД) и используется для поиска. Вся информация, относящаяся к пациенту, связывается по паре первичный-внешний ключ. Таким образом, если первичный ключ продублировать на ИБ, возможна однозначная идентификация пациента. Особенно, если первичный ключ будет формироваться по определенным правилам и с ИБ вводиться посредством считывания штрих-кода.

[плав]

В любой БД ФИО хранится только как информационное поле (правда, может использоваться для связывания с другими БД) и используется для поиска. Вся информация, относящаяся к пациенту, связывается по паре первичный-внешний ключ. Таким образом, если первичный ключ продублировать на ИБ, возможна однозначная идентификация пациента. Особенно, если первичный ключ будет формироваться по определенным правилам и с ИБ вводиться посредством считывания штрих-кода.

А внимательно прочитать, что это случайный ключ? Не задумывались, что слово случайный и "формируются по правилам" вещи несовместные?

[Igoroshka]

А внимательно прочитать, что это случайный ключ? Не задумывались, что слово случайный и "формируются по правилам" вещи несовместные?

1. В БД, которые являются основой любой информационной системы, использование случайного числа в качестве первичного ключа вряд ли можно считать оправданным подходом. Во всех современных БД есть эффективные внутренние функции для генерации последовательностей, применяемых в качестве первичного ключа. Использование собственных генераторов ключей в большинстве случаев является нецелесообразным, поскольку может оказать неоправданную назгрузку на систему.
2. Честно говоря, не вижу причин, почему последовательно формируемый ключ не может использоваться в качестве идентификатора пациента, с одной стороны скрывающий его ФИО, с другой -- обеспечивающий однозначное соответствие.
3. Под "формируемым по правилам" ключом лично я имел ввиду диапазоны чисел, отводимые, например, отдельным диспансерам, входящим в одну службу.

[плав]

1. В БД, которые являются основой любой информационной системы, использование случайного числа в качестве первичного ключа вряд ли можно считать оправданным подходом. Во всех современных БД есть эффективные внутренние функции для генерации последовательностей, применяемых в качестве первичного ключа. Использование собственных генераторов ключей в большинстве случаев является нецелесообразным, поскольку может оказать неоправданную назгрузку на систему.
2. Честно говоря, не вижу причин, почему последовательно формируемый ключ не может использоваться в качестве идентификатора пациента, с одной стороны скрывающий его ФИО, с другой -- обеспечивающий однозначное соответствие.
3. Под "формируемым по правилам" ключом лично я имел ввиду диапазоны чисел, отводимые, например, отдельным диспансерам, входящим в одну службу.

Вообще-то разговор идет не о правилах формирования БД, а о том, как можно работать в условиях существующей нормативной базы. Поскольку в законе идет речь о деперсонализированных данных, любые методы, которые могут быть использованы для сопоставления открытой и закрытой информации достаточно легко не могут являться приемлимыми. Альтернативой "неоправданной назгрузки на систему" является сертификация эхокардиографа во ФСТЭК.
И просьба, не надо предполагать, что люди, пишущие в форум не имеют представления о базах данных, и повторять поэтому очевидные вещи. Если кто чего не понимает, спросит - иначе это - флуд.