электронных систем здравоохранения
|
Процедура внесения изменений в спецификации
Статус документа История изменений документа Жизненный цикл спецификаций Смена этапов жизненного цикла спецификаций Управление изменениями Отчеты о проблемах Запросы о внесении изменений Создания новых спецификаций Правила процедуры
Введение Данный документ описывает План управления изменениями Проекта по спецификации openEHR.
Статус документа Настоящий документ является предварительной версией Плана по управлению изменениями версии 1.0
История внесения изменений
Благодарности Настоящий документ был создан при непосредственном участии · Корэя Аталага, Оклэндский Университет, Новая Зеландия.
Жизненный цикл спецификаций Все элементы спецификаций, существующие как в документарной, так и в электронной форме, следуют традиционному жизненному циклу от «создания» (или «принятия» в случае, если элемент спецификаций является объектом безвозмездной передачи openEHR Foundation) до этапа «стабильной эксплуатации спецификации» («зрелости») и последующего устаревания. Различают следующие стадии жизненного цикла: Этап разработки, Этап тестирования, Этап эксплуатации (зрелости), Этап устаревания и Этап замены. Спецификации, разработанные в openEHR Foundation, следуют следующему жизненному циклу:
· Этап разработки: на данном этапе осуществляется быстрое проектирование спецификации проектной группой; отсутствует схема управления ее изменениями. По завершению этапа разработки должна быть представлена эталонная реализация спецификации. · Этап тестирования: на данном этапе применяются формальные процедуры управления спецификацией. Конфликты и проблемы регистрируются онлайн трекером; вносимые изменения также регистрируются на отдельном, специально созданном для данных нужд трекере, обеспечивая фиксацию каждого изменения. Изменения версионности спецификаций осуществляется согласно правилам, указанным на сайте semver.org · Этап эксплуатации (зрелости): на данном этапе спецификация распространяется в формате высокого качества. Изменения, вносимые в спецификацию, проходят оценку их возможного влияния на существующие реализации спецификаций. Основная цель управления изменениями – обеспечить простоту процесса и в то же время его корректность, если спецификации получат широкое международное распространение. Спецификации, разрабатываемые на основании существующего программного обеспечения или широко распространенных практик, могут начать жизненный цикл на этапе «Тестирования» или «Стабильной эксплуатации», если соответствуют установленным критериям.
В следующей таблице приведены детальные пояснения к каждому этапу жизненного цикла:
*Правила версионности указаны на сайте semver.org; обратите внимание, что версии типа 0.x.y не подчиняются строгим правилам.
Отчеты об ошибках / сообщения о проблемах могут подаваться всеми желающими и нацелены на фиксирование существующих проблем, конфликтов, также новых требований к спецификациям. Запрос о внесении изменений может быть составлен только Группой по спецификациям и документирует все изменения, вносимые в спецификации. Без участия Группы по спецификациям, никакие изменения не допустимы.
Для сравнения, существуют также и другие спецификации управления жизненным циклом: · IHTSDO's Development, Approval, Maintenance and Review of IHTSDO Technical Reports, Guidelines and Standards («Процесс разработки, утверждения, сопровождения и пересмотра Технических отчетов, нормативов и стандартов» Международная организация по разработке стандартов в области медицинской терминологии.); · Жизненный цикл openEHR Foundation (Current openEHR lifecycle); · Существующий План управления изменениями openEHR Foundation;
Смена этапов жизненного цикла спецификаций Продвижение спецификаций до следующего этапа жизненного цикла осуществляется по окончанию периода времени, предусмотренного для текущего этапа, в котором находится спецификация. Редакционный совет проводит проверку соответствия спецификации вышеуказанным критериям (перехода к новому этапу жизненного цикла) за 3 месяца до предполагаемой даты продвижения. Если Редакционный совет обнаруживает полное соответствие требованиям, составляется Запрос о внесении изменений, устанавливающий дату продвижения спецификации до следующего этапа жизненного цикла, и инициирующий внесение модификаций во все ее артефакты, документацию, изменение формата распространения и текущей распространяемой версии. В случае, если по итогам проверки обнаруживается, что спецификация не соответсвует предъявляемым требованиям, ответственная Группа сопровождения компонентов спецификаций берет на себя обязательство гарантировать выполнение работ по подготовке соответствующей спецификации к ее продвижению на новый этап жизненного цикла. В ходе выполнения такой работы, Группа сопровождения компонентов спецификаций возможно придется взаимодействовать с командами разработчиков из Проекта по разработке программного обеспечения (openEHR Foundation) или сторонними разработчиками для того чтобы гарантировать наличие качественной реализации спецификации. Если в установленную дату перехода спецификации на новый этап жизненного цикла вышеуказанные условия все еще не соблюдены, ответственная Группа сопровождения компонентов спецификаций должна предоставить отчет, с указанием плана действий, необходимых для подготовки спецификации к продвижению в трехмесячный срок, если данные действия возможно выполнить в течение данного времени. Редакционный совет может одобрить план и предоставить Группе сопровождения компонентов спецификаций трехмесячную отсрочку в подготовке спецификации. В противном случае, работы по подготовке спецификации останавливаются и она получает статус "устаревшей" (выведенной из эксплуатации). По истечению трехмесячного срока подготовки спецификации к продвижению, Редакционный совет проводит повторную проверку на соответствие установленным критериям. По итогам проверки спецификация получает продвижение до следующего этапа или получает статус "устаревшей" (выведенной из эксплуатации).
Управление изменениями В целостном представлении, библиотеке спецификаций обычно соответствует набор сообщений о проблемах и запросов о внесениии изменений для их решения. Обработка сообщений о проблемах, а также создание, принятие и конечное утверждение или отклонение запросов о внесении изменений осуществляется Редакционным советом проекта, состоящим из представителей всех Групп сопровождения компонентов спецификаций.
Сообщения о проблемах / Отчеты об ошибках Сообщения о проблемах / Отчеты об ошибках регистрируются на открытом ресурсе трекинга спецификаций SPEC tracker. Ресурс регулярно проходит проверку на наличие новых сообщений/отчетов, в случае необходимости составляется Запрос о внесении изменений. Сообщения и отчеты трекера могут быть отклонены ("rejected") без последующего их разрешения. В этом случае они получают статус "закрыт" ("closed"). Если сообщения и отчеты трекера приняты на разрешение ("accepted"), может быть создано более одного запроса о внесении изменений. Возможно также группирование отчета с другими отчетами / сообщениями трекера в категории. Отчеты об ошибках для которых создаются запросы о внесении изменений объединяются по общей тематике таких запросов. После группирования по категориям запросов, ошибки/проблемы получают разрешение в соответствии с прецедентными разрешениями ошибок в данной категории. Запросы на внесение изменений не создаются для спецификаций, находящихся на этапе разработки. Вместо этого, необходимые модификации вносятся в запрос о внесении изменений, инициирующий создание спецификации.
Запросы о внесении изменений Запросы о внесении изменений обычно создаются в ответ на сообщения о проблемах / отчеты об ошибках. Редакционный совет также имеет право создавать запросы в случае единогласного решения его членов или на основании решения голосования, если в пользу конкретного запроса проголосовало не менее 2/3 участников совета.
Запросы о внесении изменений должны быть а) отсортированы в соответствии с их важностью и б) иметь привязку к конкретным релизам спецификаций. Таким образом, обязательным условием обработки запроса о внесении изменений является планирование одного или нескольких релизов, с указанием его идентификационных показателей и планируемых сроков выпуска.
Создание запросов Запросы о внесении изменений формируются при помощи трекера SPEC CR tracker. Для составления запроса необходимо указать:
Другая ключевая информация, например, id запроса, дата внесения и т.д. указывается системой автоматически.
Принятие запросов для разрешения Каждый Запрос о внесении изменений должен быть принят на разрешение или отклонен Редакционным советом. Вынесение решения в отношении конкретного запроса заключается в установлении: · существенной необходимости предлагаемого изменения; · совместимости запроса с текущей библиотекой спецификаций.
Если запрос принят на разрешение, требуется указать следующую информацию: · Планируемую дату разрешения запроса; · Примерное количество рабочих дней, необходимых для внесения изменений; · Лицо, ответственное за конкретное изменение спецификации. Лицо, ответственное за конкретное изменение и входящее в состав релевантной Группы поддержки компонентов спецификаций берет на себя ответственность по доведению соответствующего изменения до его завершения (т.е. до этапа «устаревания»). Под этим подразумевается контроль за выполнением процесса внесения изменения. · Масштаб вносимого изменения, отражающий влияние изменения на работу пользователей. Изменения разделяются на существенные и несущественные.
Лицо, ответственное за внесение изменения в спецификацию, должно получить от Группы поддержки компонентов спецификаций следующую информацию: · Значимость/масштаб изменения; · Детальное описание предложенного изменения; · По необходимости – пересмотренную классификацию.
После этого, Редакционный совет осуществляет пересмотр Запроса на внесение изменений. В случае, если по результатам пересмотра вносимые изменения признаются допустимыми, начинается процедура модифицирования классификации. · Если Запрос о внесении изменений предполагает существенное модифицирование классификации, допустимо назначение нескольких лиц, ответственных за внесение изменений. При этом, ответственность за контроль над выполнением процесса модификации возлагается на одно из ответственных лиц, назначенных для разрешения конкретного запроса.
Выполнение работы по внесению изменений в классификации Суть несущественных изменений обычно заключается во внесении незначительных поправок в один или несколько элементов спецификации, а также, при необходимости, использовании альтернативных форматов ее распространения. Изменения должны быть привязаны к конкретным разделам или версиям спецификаций или артефактов. Существенные изменения должны быть внесены в соответствующий раздел репозитория спецификаций. Кроме того, должна быть создана страница в wiki-разделе с описанием выполняемой деятельности по внесению изменений в спецификации, текущего статуса спецификации, указанием ответственного лица, привязкой к соответствующему запросу о внесении изменений, а так же разделу версии работы.
Утверждение изменений Утверждение изменений, инициированных Запросом о внесении изменений, происходит согласно следующей процедуре: · При внесении несущественных изменений, осуществляется проверка релевантных документов или артефактов релевантного электронного инструмента. · Для утверждения конкретного изменения в спецификации требуется единогласное решение всех членов Группы поддержки компонентов спецификации. · В случае утверждения, изменение получает привязку к библиотеке спецификаций. · В случае, если вносимые изменения не получают утверждения, лицо, назначенное за разрешение конкретного запроса о внесении изменений, имеет право повторно представить предлагаемое изменение в течение недели после его отклонения. · Если предлагаемое изменение не получает одобрения после трех рассмотрений, оно автоматически отклоняется и получает статус «закрытого» (“closed”).
Для существенных изменений действует следующая процедура: · В течение установленного срока проводится открытое обсуждение вносимых изменений. К примеру, обсуждение может длиться в течение 30 дней; во внимание принимаются комментарии всего сообщества openEHR, включая участников проектов организации openEHR Foundation. · По завершению периода обсуждения, лицо, назначенное за разрешение конкретного запроса о внесении изменений, обязуется в двухнедельный срок представить итоги работ по внесению изменений в спецификацию с учетом комментариев сообщества openEHR и участников проектов организации openEHR Foundation. · Для утверждения вносимых изменений (с учетом комментариев сообщества openEHR и участников проектов организации openEHR Foundation), они должны быть одобрены не менее чем 2/3 членского состава Редакционного совета. · Сомнения членов Редакционного совета (к примеру, касательно полноты вносимых изменений), если это возможно, должны находит разрешение в дополнительных Запросах на внесение изменений. · В случае утверждения, изменение получает привязку к библиотеке спецификаций. · Если вносимое изменение не получает одобрение Редакционного совета, оно отправляется на доработку. · Если предлагаемое изменение не получает одобрения после трех рассмотрений, оно автоматически отклоняется и получает статус «закрытого» (“closed”).
Разработка новых спецификаций
Процедура создания новых спецификаций Любой член сообщества openEHR может предложить разработку новой спецификации. Согласно формальной процедуре, необходимо размещение Отчета об ошибке (Сообщения о проблеме) на открытом трекере SPEC tracker. Если аргументация в пользу необходимости создания новой спецификации будет представлена в рамках Отчета об ошибке (Сообщения о проблеме), по решению Редакционного совета может быть создан Запрос о внесении изменений. В этом случае, сроки разработки новой спецификации, а также ее уникальный идентификатор и области применения будут установлены Запросом о внесении изменений. Новые спецификации должны быть полностью совместимы со структурой и планом развития уже существующей библиотеки спецификаций. Каждой новой спецификации должен быть присвоен уникальный идентификатор и определено место в существующей структуре библиотеки спецификаций (разработка новая спецификаций может потребовать создание новой категории в структуре библиотеки спецификаций). Для каждой новой спецификации определяется такая область применения, которая бы дополняла и была согласована с областями применения существующей библиотеки спецификаций. Уникальный идентификатор, место в структуре библиотеки спецификаций, а также области применения новой спецификации устанавливаются и публикуются Редакционным советов до создания Запроса о внесении изменений, направленного на создание новой спецификации. Новая спецификация теоретически может заменить одну или несколько существующих спецификаций, что повлечет за собой изменение в структуре и плане развития библиотеки спецификаций. Данные изменения будут также зафиксированы при помощи Запроса о внесении изменений.
Аспекты интернационализации и адаптации должны быть задокументированы.
В случае, если Редакционный совет пример решение о создании новой спецификации, им будут рассмотрены следующие вопросы:
Создание спецификаций возможно двумя способами: · Первый способ заключается в предоставлении Проекту по спецификации openEHR разработанного и корректного документа или исчисляемого артефакта. В данном случае Редакционный совет оценит завершенность спецификации в соответствии с критериями этапов жизненного цикла, указанными выше, и будет осуществлять ее распространение соответствующим образом. Спецификация, удовлетворяющая критериям этапов «Тестирования» или «Зрелости», может начать жизненный цикл на данных этапах, если Редакционный совет · Другой способ заключается в определении потребности в новой спецификации, что повлечет за собой разработку спецификации в рамках Редакционного совета.
Типовая структура спецификации Все спецификации openEHR включают в себя следующие стандартные разделы: · Титульный лист с указанием идентификатора, версии и дата релиза спецификации; · Перечень внесенных изменений; · Раздел об авторском праве; · Раздел, посвященный используемым логотипам и раздел благодарностей; · Оглавление; · Вступление, с указанием цели, сопутствующих документов openEHR, номенклатуры, статуса и электронных инструментов, изменений, внесенных в предшествующую версию спецификации; · <<Основные разделы спецификации>> · Раздел использованных источников; · Заключительная страница
Кроме того, в случает необходимости, могут быть добавлены следующие разделы: · Интернационализация и адаптация; · Руководство по применению.
Внесение изменений в спецификации на этапе «тестирования» и «эксплуатации» Несущественные изменения в спецификационные документы обычно вносятся Группой сопровождения компонентов спецификаций при согласии ее членов. Утверждение изменений осуществляется по итогам внутреннего обсуждения, согласно процедуре, описанной выше. Существенные изменения могут быть внесены как одним лицом, так и группой лиц. Утверждение вносимых изменений осуществляется посредством всеобщего обсуждения с установлением крайних сроков. Обмен мнениями и комментирование вносимых изменений происходит в рамках созданного Запроса о внесении изменений. Процедура принятия изменений описана выше.
Часто задаваемые вопросы Кто может сообщить об ошибке или предложить внесение изменений в спецификацию? Любой желающий. Сообщить об ошибке можно при помощи открытого трекера SPEC PR tracker. Редакционный совет Проекта по спецификации openEHR осуществляет регулярную проверку наличия новых сообщений об ошибках и принимает решение о создании Запросов на внесение изменений в библиотеку спецификаций на основании таких отчетов.
Кто принимает решение об утверждении или отклонении изменений? Предложения об изменениях вносимые при помощи открытого трекера SPEC PR tracker будут рассмотрены Редакционным советом проекта. По результатам рассмотрения, Редакционный совет может создать Запрос о внесении конкретных изменений в спецификации. Внесение изменений осуществляется непосредственно членами Проекта по спецификации openEHR. В некоторых случаях возможно отклонение изменений в ходе процесса модификации спецификаций. В таком случае, изменение спецификаций не будет произведено.
Кто устанавливает приоритет вносимых изменений? Редакционный совет Проекта по спецификации openEHR совместно с Операциональной группой openEHR.
Кто устанавливает соответствие между релизами и вносимыми в спецификации изменениями?
Редакционный совет Проекта по спецификации openEHR совместно с Операциональной группой openEHR. |