Как разработчики системы, мы сталкиваемся с дилеммой при переходе с одной версии FHIR на другую. Мы начали с FHIR 0.0.81, а затем 10 сентября 2014 года перешли на версию 2833 SVN, чтобы исправить ошибку. Как было предложено, мы загрузили код Java из магистрали SVN и следовали инструкциям на странице FHIR Build Process.
FHIR 0.0.82 Несовместимость
Теперь, когда доступен FHIR 0.0.82, мы хотим перейти на выпущенную версию. Однако после загрузки 0.0.82 мы заметили, что некоторые ресурсы, такие как Appointment, которые были в магистрали rev2833, отсутствуют в версии 0.0.82. Это приводит к нашим первым вопросам:
Что содержит транк, если он не содержит последнего кода, предназначенного для следующего выпуска?
Должен ли кто-нибудь использовать то, что находится в багажнике?
Есть ли ветка релиза, из которой была создана 0.0.82?
Несовместимость магистральных линий
Поскольку наш код зависит от ресурсов, представленных в магистрали, но не включенных в 0.0.82, мы должны продолжать проверять FHIR непосредственно из SVN. 21 октября 2014 г. мы загрузили Java-код SVN версии 3218. Когда мы интегрировали этот код в нашу систему, мы обнаружили множество проблем совместимости. Вот некоторые из них:
Различные значения Enum изменены с нижнего регистра на верхний, включая Patient.AdministrativeGender и HumanName.NameUser. Хотя соответствие соглашению об именах Java - хорошая идея, изменение основных типов данных нарушает компиляцию.
Имена методов изменились, что также привело к ошибкам компиляции. Мы также обнаружили, что произошли одновременные изменения имен. Например, в классе HumanName старый setTextSimple (String) теперь имеет значение setText (String), а старый setText (StringType ) теперь setTextElement (StringType). И имя, и тип параметра setText () изменились, что сделало миграцию подверженной ошибкам, потому что при каждом использовании нужно решать, изменять ли метод или его параметр.
Тип ресурса ResourceReference изменил имя класса. В одном только пакете модели FHIR было затронуто 859 вхождений ResourceReference в 61 файл. Сюда не входят изменения, которые произошли в других пакетах FHIR, или изменения, которые будут отражаться в коде нашего приложения и наших схемах базы данных.
Мы заметили несколько новых ресурсов в магистральном коде rev3218, включая NewBundle. Ранее мы предлагали, чтобы пакеты были ресурсами, поэтому приятно видеть это изменение. Однако, поскольку магистраль не имеет обратной совместимости с выпусками 0.0.8x, я не уверен, придется ли нам поддерживать как старый, так и новый способ синтаксического анализа и составления пакетов JSON и XML.
Чтобы прояснить ситуацию, важно понимать, что некоторые из вышеупомянутых изменений FHIR не только влияют на компиляцию, но и могут легко внести небольшие ошибки во время выполнения. Кроме того, изменения FHIR могут потребовать изменения схемы базы данных и миграции данных в некоторых приложениях. Например, наше приложение сохраняет потоки ресурсов JSON в базе данных. Для чего-то столь же простого, как изменение значения перечисления с «male» на «MALE», требуются утилиты миграции, которые обновляют существующее содержимое базы данных.
Идти вперед
Мы вкладываем большие средства в FHIR; мы хотим, чтобы он был успешным и широко применялся в качестве стандарта. Для этого необходимо решить проблемы обратной совместимости и миграции версий. В этом тщетном случае любой свет, который может быть пролит на следующий вопрос, продвинет всех нас вперед:
Какова цель строки кода 0.0.8x? Кто его целевые пользователи?
Какова цель кода в транке? Кто его целевые пользователи?
Ожидается ли, что пользователи 0.0.8x когда-нибудь перейдут на кодовую базу транка?
- If so, what migration strategy will used to address the many incompatibilties between the codebases?
Какова политика устаревания кода в каждой базе кода?
Какой уровень обратной совместимости можно ожидать от редакции к редакции в коде в транке?
Есть ли дорожная карта FHIR, которую разработчики систем могут использовать для планирования собственных циклов разработки?
Спасибо, Rich C
