В этом репозитории размещена общедоступная документация по API для реализации Cerner стандарта HL7 ® FHIR ® , также известного как API Cerner Ignite.
Развернутую документацию можно просмотреть по адресу https://fhir.cerner.com/.
Сообщения об ошибках или заметки об областях, где документация неясна, приветствуются как проблемы с хранилищем.
Установите зависимости с помощью упаковщика.
$ bundle install
Скомпилируйте сайт с помощью nanoc.
$ bundle exec nanoc
Запустите локальный веб-сервер с помощью nanoc.
$ bundle exec nanoc view
Перейдите по адресу http://localhost:3000/, чтобы просмотреть сайт. При внесении изменений на сайт повторите два последних шага, чтобы перекомпилировать и просмотреть новый контент.
Мы добавили атрибуты в верхней части некоторых файлов уценки для назначения макета. Обычно они необходимы только для страниц, которые не являются фактической документацией API (наше правило компиляции использует этот атрибут макета, прежде чем вернуться к макету API).
Сами макеты определяются в каталоге макетов. Некоторые макеты (например, макеты API или FAQ) используются в качестве шаблонов страниц, как упоминалось выше. Другие макеты (например, макеты категорий ресурсов или макеты верхнего и нижнего колонтитула) используются для включения контента на другие страницы.
Существуют правила предварительной обработки, которые используют сопоставление папок для добавления атрибутов версии и решения во все файлы уценки для API. Единственное, что вам нужно сделать, чтобы это работало, — это поместить документацию по ресурсам в путь к папке /[solution]/[version]/.
Атрибуты версии и решения в настоящее время используются для гибкой настройки классов CSS, ссылок на страницы и навигационных панелей/боковых панелей для документации API.
Для операций создания и обновления обычно требуются тела JSON, которые может быть утомительно документировать вручную с помощью уценки. Чтобы упростить этот процесс и улучшить согласованность, мы добавили помощник definition_table для создания таблицы из файла содержимого yaml.
Помощнику definition_table требуются 3 параметра: содержимое, действие и версия.
content указывает, какой файл содержимого необходимо загрузить.version указывает версию файла содержимого.action указывает, какие конкретные варианты действия, определенные в файле содержимого, должны быть отражены в сгенерированной таблице. Обычно это действие :create или :update. Доступные действия определяются в самих файлах содержимого. Генерация таблицы полей выполняется путем вызова метода definition_table через вызов ERB в любом файле документации, которому нужна таблица.
Например, версию DocumentReference Create DSTU2 можно создать с помощью:
<%= definition_table(:document_reference, :create, :dstu2) %>
Принимая во внимание, что другие версии обновления AllergyIntolerance могут быть созданы (при условии, что доступны соответствующие определения), используя:
<%= definition_table(:allergy_intolerance, :update, :r4) %>
На самом деле параметр version ссылается на подпапку в lib/resources , где хранятся файлы содержимого для этой версии. Таким образом, definition_table(:document_reference, :create, :dstu2) ссылается на lib/resources/dstu2/document_reference.yaml . Добавление новых версий или новых файлов содержимого — это просто вопрос создания папки и файла содержимого с соответствующим именем.
definition_table считывает эти поля из определения yaml содержимого ресурса:
Помощник terminolgy_table доступен для создания таблицы привязки терминологии из того же файла содержимого yaml, что и definition_table .
Помощнику terminolgy_table требуются 2 параметра: контент и версия.
content указывает, какой файл содержимого необходимо загрузить.version указывает версию файла содержимого. Создание таблицы терминологии осуществляется путем вызова метода terminology_table через вызов ERB в зависимости от того, какой файл документации нуждается в этой таблице.
Например, версию AllergyIntolerance DSTU2 можно создать с помощью:
<%= terminology_table(:allergy_intolerance, :dstu2) %>
Обработка параметра version выполняется так же, как и definition_table .
terminology_table считывает эти поля из определения yaml содержимого ресурса:
Содержимое определяется в файлах YAML, и большинство полей являются необязательными. Если они не указаны, результирующая ячейка таблицы будет просто пустой.
definition_table будет генерировать вложенные ссылки для каждого поля, к которому добавлен этот URL-адрес.field_name_base_url .lib/resources//types.yaml , оно будет связано с указанным ресурсом.для сохранения форматирования.
fields .field_name_base_url , если он определен.Применяются стандартные правила форматирования YAML.
В дополнение к полям, указанным выше, каждое поле может иметь поле action , которое указывает, к какому действию или действиям применяется это поле. Если оно определено, поле будет включено только при создании таблицы с указанным действием. Также поддерживаются несколько действий, которые можно определить в виде списка:
Make the field apply to a single action
- name: subject
...
action: create
Make the field apply to multiple actions
- name: subject
...
action:
- create
- update
Аналогично, значения полей также могут быть изменены для каждого действия:
Alter the required and note values for update and create
- name: id
required:
- update: 'Yes'
- create: 'No'
type: id
description: The logical id of the resource to update.
example: |
{
"id": "123412"
}
note:
- update: The id value must match the AllergyIntolerance/ value.
- create: The id field must not be set when performing an update operation.
Имя действия не ограничивается созданием и обновлением, при создании таблицы полей одновременно можно использовать только одно действие.
Связывание поддерживается в нескольких формах.
Имена полей будут автоматически связаны на основе base_field_name_url , если они не переопределены значением url поля.
Ячейка таблицы Type будет генерировать ссылки на основе пар «ключ-значение» URL-адресов, определенных в lib/resources/ . Любое слово, найденное в поле type , будет заменено указанным URL-адресом.
Поля description и note также поддерживают связывание с помощью тегов `` и [] . Слова, заключенные в теги ``, будут связаны в соответствии с файлом types.yaml , если это возможно, или просто отформатированы как теги , если нет. Слова, заключенные в [] будут считаться ссылками на другие поля в той же таблице.
В общем, лучше не использовать теги `` в поле type , хотя это возможно. Могут возникнуть конфликты, которые могут привести к дублированию замен и непредвиденным результатам.
