Este repositorio alberga la documentación API pública para la implementación por parte de Cerner del estándar HL7 ® FHIR ® , también conocido como API Ignite de Cerner.
La documentación implementada se puede ver en https://fhir.cerner.com/.
Los informes de errores o notas de áreas donde la documentación no está clara son bienvenidos como problemas del repositorio.
Instale dependencias con el paquete.
$ bundle install
Compile el sitio con nanoc.
$ bundle exec nanoc
Inicie un servidor web local con nanoc.
$ bundle exec nanoc view
Navegue a http://localhost:3000/ para ver el sitio. Al realizar cambios en el sitio, repita los dos últimos pasos para volver a compilar y ver el nuevo contenido.
Hemos agregado atributos en la parte superior de algunos archivos de rebajas para asignar un diseño. Por lo general, solo son necesarios para páginas que no son documentación de API real (nuestra regla de compilación usa ese atributo de diseño antes de recurrir al diseño de API).
Los diseños en sí se definen en el directorio de diseños. Algunos diseños (como los diseños de API o de preguntas frecuentes) se utilizan como plantillas de página, como se mencionó anteriormente. Otros diseños (como diseños de categorías de recursos o diseños de encabezado/pie de página) se utilizan para incluir contenido en otras páginas.
Existen reglas de preprocesamiento que utilizan la coincidencia de carpetas para agregar atributos de versión y solución a todos los archivos de rebajas de la API. Lo único que debe hacer para que esto funcione es colocar la documentación de recursos en la ruta de la carpeta /[solución]/[versión]/.
Los atributos de versión y solución se utilizan actualmente para flexibilizar clases de CSS, enlaces de páginas y barras de herramientas/barras laterales de navegación para la documentación de API.
Las operaciones de creación y actualización normalmente requieren cuerpos JSON, que pueden resultar tediosos de documentar manualmente mediante rebajas. Para simplificar este proceso y mejorar la coherencia, hemos agregado el asistente definition_table para generar una tabla a partir de un archivo de contenido yaml.
El asistente definition_table requiere 3 parámetros: contenido, acción y versión.
content indica qué archivo de contenido cargar.version indica la versión del archivo de contenido.action indica qué variaciones específicas de acción definidas en el archivo de contenido se reflejan en la tabla generada. Normalmente la acción será :crear o :actualizar. Las acciones disponibles se definen en los propios archivos de contenido. La generación de una tabla de campos se realiza invocando el método definition_table a través de una llamada ERB en cualquier archivo de documentación que necesite la tabla.
Por ejemplo, la versión DSTU2 de DocumentReference Create se puede generar usando:
<%= definition_table(:document_reference, :create, :dstu2) %>
Mientras que se pueden generar otras versiones de AllergyIntolerance Update (suponiendo que haya definiciones apropiadas disponibles) usando:
<%= definition_table(:allergy_intolerance, :update, :r4) %>
En realidad, el parámetro version hace referencia a una subcarpeta en lib/resources donde se almacenan los archivos de contenido para esa versión. Por lo tanto, definition_table(:document_reference, :create, :dstu2) hace referencia a lib/resources/dstu2/document_reference.yaml . Agregar nuevas versiones o nuevos archivos de contenido es simplemente una cuestión de crear una carpeta y un archivo de contenido con el nombre apropiado.
definition_table lee estos campos de la definición de contenido yaml del recurso:
El asistente terminolgy_table está disponible para generar una tabla vinculante de terminología a partir del mismo archivo de contenido yaml que definition_table .
El asistente terminolgy_table requiere 2 parámetros: contenido y versión.
content indica qué archivo de contenido cargar.version indica la versión del archivo de contenido. La generación de una tabla de terminología se realiza invocando el método terminology_table a través de una llamada ERB en cualquier archivo de documentación que necesite la tabla.
Por ejemplo, la versión DSTU2 de AllergyIntolerance se puede generar usando:
<%= terminology_table(:allergy_intolerance, :dstu2) %>
El procesamiento del parámetro version se maneja de la misma manera que definition_table .
terminology_table lee estos campos de la definición de contenido yaml del recurso:
El contenido se define en archivos YAML y la mayoría de los campos son opcionales. Si no se proporcionan, la celda de la tabla resultante simplemente estará vacía.
definition_table generará enlaces anidados para cada campo antepuesto con esta URL.field_name_base_url .lib/resources/<version>/types.yaml , este campo se vinculará al recurso especificado.fields .field_name_base_url si está definida.Se aplican las reglas de formato YAML estándar.
Además de los campos anteriores, cada campo puede tener un campo action que indica a qué acción o acciones se aplica el campo. Cuando se define, el campo solo se incluirá al generar una tabla con la acción especificada. También se admiten varias acciones que se pueden definir como una lista:
Make the field apply to a single action
- name: subject
...
action: create
Make the field apply to multiple actions
- name: subject
...
action:
- create
- update
De manera similar, los valores de los campos también se pueden flexionar por acción:
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/<id> value.
- create: The id field must not be set when performing an update operation.
El nombre de la acción no se limita a crear y actualizar, pero solo se puede usar una acción a la vez al generar una tabla de campos.
La vinculación se admite en algunas formas.
Los nombres de los campos se vincularán automáticamente en función de base_field_name_url a menos que se anulen por el valor de url de un campo.
La celda de la tabla Tipo generará enlaces basados en pares clave-valor de URL definidos en lib/resources/<version>/types.yaml . Cualquier palabra encontrada en un campo type será reemplazada por la URL especificada.
Los campos description y note también admiten enlaces mediante el uso de etiquetas `` y [] . Las palabras encerradas en etiquetas `` se vincularán de acuerdo con el archivo types.yaml , si es posible, o simplemente se formatearán como etiquetas <code> si no. Se asumirá que las palabras encerradas entre [] son referencias a otros campos de la misma tabla.
En general, es mejor no utilizar etiquetas `` en el campo type , aunque es posible. Puede haber conflictos que pueden dar lugar a reemplazos duplicados y resultados no deseados.
