You are here: Foswiki>Gnumed Web>CertificationProsAndConsRu (19 Feb 2013, IvanLykov)EditAttach

Сертификационные требования в Системе управления качеством

Каким должно быть их применение для производителей и пользователей свободного программного обеспечения с конкретным указанием на медицинскую помощь?

Мы считаем, что медпомощь детям важна, но применяются разные стандарты для платных посещений детей и тех, кто оказывает помощь или надзор бесплатно на дому, несмотря на то, что это может быть один и тот же ребенок. Нормативными усилиями, следовательно, является не урезанная и сухая система применяемых правил только и исключительно для достижения унифицированного результата, а во многих случаях цели достижения "вообще правильно".

В контексте программного обеспечения по ведению пациента (PMS), включая программу для электронной медицинской записи (EMR) я хотел бы предложить нижеуказанные соображения.

Я надеюсь, что любое регулирующее учреждение, стремящееся способствовать качеству, сделает это без чрезмерно дорогостоящего процесса, который устанавливается для погашения разнообразных типов и инноваций, кажется с небольшими и, в частности, проектами свободного программного обеспечения. Проекты не могут себе позволить дорогие обручи, лучше переживаемые крупными учреждениями, для возможности последних и стратегических выгод.

Понятия и принципы:

  • производитель и потребитель (в отличие от сообщества по обмену)
    • традиционные ожидания производителей:
      • получения платежа (то есть договорные отношения)
      • неюридическое требование (только конкурентоспособность) для гарантии от проблем или их исправление
      • тайна или, по крайней мере, неразглашение, как продукт был сделан, или работает
      • сохранение всего управления продуктом (ограничение потребительского потенциала для решения проблемы)
    • традиционные ожидания потребителей:
      • гарантия
      • качество обслуживания
      • продукт работает, как описано/обещано/требуется

В случае "продуктов" мы, обычно, регулируем качественную основу, если не полностью, то только до первоначальной точки продажи потребителю. Только неординарность ожидает еще встретить оригинальный стандарт в точке, где продукт вторично перераспределяется. Некоторые товары, как подержанные автомобили, несмотря на, что они могут страдать снижением качества, остаются адекватно проверяемыми любым потребителем, приобретающим его.

В случае систем Электронной медицинской записи (EMR) стандартом системы по менеджменту качества (QMS) является посредник для фактического осмотра, тестирования и любого ремонта или других изменений программного обеспечения, которое – в программном обеспечении с открытым исходным кодом (свободном) или модели "FLOSS" - является свободой, полностью доступной для потребителя. Это во многом, если не полностью, недоступно для пользователей несвободного, "собственнического" программного обеспечения с закрытым исходным кодом, по крайней мере традиционно.

Для удобства и, несмотря на то, что не все из упомянутого соответствует последующему описанию, позвольте в худшем случае ссылаться на него, как на программное обеспечение с непрозрачной блокировкой (OLIS - от opaque lock-in software, перев.). Позвольте также высказать мнение, что несмотря на такой ярлык, хорошо управляемое OLIS может достичь высокого уровня QMS и могло бы, несомненно, помочь обеспечить качество медицинской помощи, хотя расходы могут быть значительными.

Выделение всех элементов договорных отношений, сфокусированных только на качестве, и в сценарии, где производители конкретной версии программного обеспечения FLOSS или даже OLIS не сделали бы явную систему менеджмента качеством (и не получили сертификации), ставит вопрос, будет ли развертывание и использование программного обеспечения конечными пользователями другим, если бы конечные пользователи написали свое собственное программное обеспечение.

Регулятор должен, поэтому, задаться вопросом, будут ли вне закона все модификации конечного пользователя в общих инструментах, которые затем послужат их собственным потребностям, поскольку типичные EMR'ы – несмотря на то, что "упакованы" – уже сочетают инструменты компонентов "с полки", то есть базу данных, язык программирования, сервер подключения и графический интерфейс пользователя. Утверждение, касающееся конечного пользователя, собравшего свою собственную EMR из текстового процессора (который внутри него может иметь или ссылаться на базу данных, и сортировать и манипулировать функциями в дополнение к внутренним языкам программирования), является ложным аргументом.

Регулятор должен затем рассмотреть – если это использование не будет вне закона – на какой основе запретить ему совместное использование копий таких программных систем среди таких пользователей с общими потребностями. Следующим расширением является концепция нескольких отдельных лиц или групп в рамках сообщества, каждое развертывающее копию для собственного использования. Если такая группа сложит записи каждого в одну гигантскую базу данных, используемую всеми – не то, что мы должны – не будет ли предоставление этой точки оригинала. Эта форма EMR, несмотря на что она была бы гигантской, предположительно будет освобождена. Это, по сути, то, что делают некоторые госучреждения, и рассуждения, в каких государственных органах можно написать или многократно развернуть программное обеспечение, освобождены от медвежьего пересмотра требований QMS для медицинских устройств правительства.

Регулятор не может оценить назначение программного обеспечения, оторванного от оборудования, как медицинское устройство, он вносит под регулятивный контроль, либо виртуальные устройства, либо в случае централизованного использования и осуществления систем удалённого доступа, программу, как службу, которая регуляторы рискуют, определяя, как тогда рассматриваемую вне области. Какими будут нормативные положения, когда практикующие врачи подпишутся на услугу, размещенную за пределами Канады, где им уже не препятствует законодательство о конфиденциальности? Что же тогда от общественности, которая могли бы выбрать размещение своей личной медицинской информации в системе, подобной Google Health. Конечно, это программное обеспечение для ведения пациента (медицинское), поэтому должен ли Google Health быть многонациональным регулятором, чтобы требовать сертификацию и лицензирование?

Существует опасность того, что регулятор здесь будет рассматриваться, как неосуществляемое требование к качеству, устанавливающее подотчетность, которой оно подлежит. В случае потребителей традиционного OLIS их подотчетность по использованию программы сдвигается напротив в место контроля, потому что, как потребители, они могут лишь попытаться влиять, но не могут управлять исходным кодом работы, без помощи выявить какой-либо из ее недостатков путем внутренней инспекции. Это формирует основу регулятора требовать от производителя OLIS сертификации для QMS как посредника безопасной и эффективной функции программного обеспечения.

Где, однако, программное обеспечение по ведению пациента становится доступным для тех, кто может заняться и помочь себе в этом, на компьютере ли сервера, доступном на международном уровне, или через точку обмена в рамках сообщества пользователей в любом из указанных сценариев, подотчетность должна быть у пользователей, за исключением тех случаев, когда они будут совместно назначать посредника QMS, который принят и взял на себя эту ответственность. В случае программного обеспечения FLOSS это может быть поддерживаемая сообществом некоммерческая корпорация, но в настоящее время, главным образом, простое обращение к принципу для таких инвестиций.

В отсутствие такой договоренности между большинством пользователей и теми, чьи EMR не добилась сертификации ISO 13485 (буть EMR типа OLIS или FLOSS), каждая группа пользователей – например, каждое медицинское учреждение – должна отвечать за регистрацию собственного QMS.

Для этого имеется прецедент в существующем требовании для врачей, работающих в частном секторе, на их политику и соблюдение конфиденциальности. Любой пациент может запросить показать их. Такой же она должна быть для любого используемого медицинского устройства. Можно утверждать, что оно может быть изменчиво для общественности, как пациенты, чтобы более прозрачно предоставлять доказательства процессов QMS, которые часто во многих учреждениях могут быть определены неадекватно.

Преимуществом такого подхода будет продвижение медицинского учреждения на более высокий уровень соглашений и сотрудничества, и принятие практики качества, неважно, окажутся ли они через такую работу на уровне сотрудничества в сообществе, или же она будет достигнута через посредника от некоммерческой организации (где они будут создавать таковую для сертификации), или OLIS, или FLOSS.

Даже, когда мы хотим удовлетворительного QMS на месте, в случае ли, когда потребители его подразумевают в EMR с сертификатом ISO 13485, или в случае QMS с демонстрируемым формальным отсутствием сертификации у пользователей, может быть менее важным для качества доставки. Здесь кажется важным момент – когда любо пользователь-медик будет иметь возможность использовать любое несертифицированное программное обеспечение, действительность не должна препятствовать использованию программного обеспечения, а требовать от пользователей разрабатывать и делать доступную документацию для их собственных QMS. Этот подход будет оказывать давление, где она должна располагаться. Даже можно расширить этот аргумент, вменяя в обязанность врачей регистрировать QMS, относящуюся к их не -электронной системе медицинских записей. Их потребность в лучшем качестве ведения медицинской информации и оказания медицинских услуг создаст стремление принять функциональность EMR, где и как нужно добавить качество и стоимость. Это будет продвигать принятие функциональности EMR по правильным причинам!

Практикующие медики, которые скорее примут согласованную систему качества, которую может предоставить сертифицированный OLIS или поддерживаемый сообществом FLOSS, согласны отдать часть своей работы. Многие врачи говорят мне: "Я скорее бы просто заплатил кому-то дополнительно за предоставление того, что уже отработано, чем делать это сам". Многие сочтут, что проще перейти непосредственно к "поставщику" сертифицированного OLIS. Но мы должны также найти способы, чтобы медицинское сообщество соблюдало или поддерживало расходы на программы OLIS и FLOSS, которые еще не получили сертификацию. Это сделало бы их лучшим программным обеспечением, что должно быть указателем всего этого.

Регистраторы, утвердившие регулятора, могут решить определить, что процесс, в котором медицинские офисы, использующие компьютеры под любое, что больше, чем биллинг и планирование – и, возможно, (как выше), даже без этого – должен предоставить документацию QMS по ведению записей, включая любые компоненты по медпомощи в электронной форме, которые не сертифицированы по стандарту ISO 13485. Воздействие на практику не должно быть чрезмерно вредящим. В каком-либо одном учреждении в течение одного года должно быть ограничено около половины дня времени для практикующих врачей, а стоимость может быть $200 за полный рабочий день врача, эквивалентом суммы в $1000 за практику. Это может быть развернуто под системой случайного аудита с интенсивностью в рамках совместного потенциала регистраторов и коллег терапевтов и хирургов – постоянные регулирующие органы, назначенные врачами – с которыми должен располагаться такой процесс развития.

За исключением такой системы, я не могу представить, чтобы регулятор придумал подход, который учитывал бы тот факт, что врачи, использующие собственные системы и те, которые этого не делают, могут также использовать многие другие инструменты электронного ведения пациента, независимы от того, что EMR может быть или нет сертифицирован в ISO 13485.
Topic revision: 19 Feb 2013, IvanLykov
 
Download.png
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback
Powered by Olark