Este repositório abriga a documentação da API pública para a implementação do padrão HL7 ® FHIR ® da Cerner, também conhecida como APIs Ignite da Cerner.
A documentação implantada pode ser visualizada em https://fhir.cerner.com/.
Relatórios de bugs ou notas de áreas onde a documentação não está clara são bem-vindos como problemas de repositório.
Instale dependências com bundler.
$ bundle install
Compile o site com nanoc.
$ bundle exec nanoc
Inicie um servidor web local com nanoc.
$ bundle exec nanoc view
Navegue até http://localhost:3000/ para visualizar o site. Ao fazer alterações no site, repita as duas últimas etapas para recompilar e visualizar o novo conteúdo.
Adicionamos atributos no topo de alguns arquivos markdown para atribuir um layout. Geralmente, eles são necessários apenas para páginas que não são documentação real da API (nossa regra de compilação usa esse atributo de layout antes de voltar ao layout da API).
Os próprios layouts são definidos no diretório de layouts. Alguns layouts (como os layouts de API ou FAQ) são usados como modelos de página conforme mencionado acima. Outros layouts (como layouts de categorias de recursos ou layouts de cabeçalho/rodapé) são usados para incluir conteúdo em outras páginas.
Existem regras de pré-processamento que usam a correspondência de pastas para adicionar atributos de versão e solução a todos os arquivos markdown da API. A única coisa que você precisa fazer para que isso funcione é colocar a documentação do recurso no caminho da pasta /[solução]/[versão]/.
Os atributos de versão e solução são usados atualmente para flexibilizar classes CSS, links de páginas e barras de ferramentas/barras laterais de navegação para a documentação da API.
As operações de criação e atualização normalmente exigem corpos JSON que podem ser entediantes de documentar manualmente por meio de descontos. Para simplificar esse processo e melhorar a consistência, adicionamos o auxiliar definition_table para gerar uma tabela a partir de um arquivo de conteúdo yaml.
O auxiliar definition_table requer 3 parâmetros: conteúdo, ação e versão.
content indica qual arquivo de conteúdo carregar.version indica a versão do arquivo de conteúdo.action indica quais variações específicas da ação definidas no arquivo de conteúdo serão refletidas na tabela gerada. Normalmente a ação será :create ou :update. As ações disponíveis são definidas nos próprios arquivos de conteúdo. A geração de uma tabela de campos é feita invocando o método definition_table por meio de uma chamada ERB em qualquer arquivo de documentação que precise da tabela.
Por exemplo, a versão DSTU2 do DocumentReference Create pode ser gerada usando:
<%= definition_table(:document_reference, :create, :dstu2) %>
Considerando que outras versões da Atualização AllergyIntolerance podem ser geradas (assumindo que as definições apropriadas estejam disponíveis) usando:
<%= definition_table(:allergy_intolerance, :update, :r4) %>
Na verdade, o parâmetro version faz referência a uma subpasta em lib/resources onde os arquivos de conteúdo dessa versão são armazenados. Assim, definition_table(:document_reference, :create, :dstu2) está referenciando lib/resources/dstu2/document_reference.yaml . Adicionar novas versões ou novos arquivos de conteúdo é simplesmente uma questão de criar uma pasta e um arquivo de conteúdo com nome apropriado.
definition_table lê estes campos da definição yaml de conteúdo do recurso:
O auxiliar terminolgy_table está disponível para gerar uma tabela de ligação terminológica a partir do mesmo arquivo de conteúdo yaml que definition_table .
O auxiliar terminolgy_table requer 2 parâmetros: conteúdo e versão.
content indica qual arquivo de conteúdo carregar.version indica a versão do arquivo de conteúdo. A geração de uma tabela de terminologia é feita invocando o método terminology_table por meio de uma chamada ERB em qualquer arquivo de documentação que precise da tabela.
Por exemplo, a versão DSTU2 do AllergyIntolerance pode ser gerada usando:
<%= terminology_table(:allergy_intolerance, :dstu2) %>
O processamento do parâmetro version é tratado da mesma forma que definition_table .
terminology_table lê estes campos da definição yaml de conteúdo do recurso:
O conteúdo é definido em arquivos YAML e a maioria dos campos são opcionais. Se não forem fornecidos, a célula da tabela resultante ficará vazia.
definition_table irá gerar links aninhados para cada campo prefixado com este URL.field_name_base_url .lib/resources//types.yaml , este campo será vinculado ao recurso especificado.para preservar a formatação.
fields .field_name_base_url , se definido.Aplicam-se regras de formatação YAML padrão.
Além dos campos acima, cada campo pode ter um campo action que indica a qual ação ou ações o campo se aplica. Quando definido, o campo só será incluído ao gerar uma tabela com a ação especificada. Múltiplas ações também são suportadas e podem ser definidas como uma 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
Da mesma forma, os valores dos campos também podem ser flexibilizados por ação:
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.
O nome da ação não se limita a criar e atualizar, mas apenas uma ação pode ser usada por vez ao gerar uma tabela de campos.
A vinculação é suportada em alguns formatos.
Os nomes dos campos serão vinculados automaticamente com base no base_field_name_url a menos que sejam substituídos pelo valor url de um campo.
A célula da tabela Type gerará links com base em pares de valores-chave de URLs definidos em lib/resources/ . Qualquer palavra encontrada em um campo type será substituída pela URL especificada.
Os campos description e note também suportam links através do uso de tags `` e [] . Palavras entre tags `` serão vinculadas de acordo com o arquivo types.yaml , se possível, ou apenas formatadas como tags se não. As palavras entre [] serão consideradas referências a outros campos na mesma tabela.
Em geral, é melhor não usar tags `` no campo type , embora seja possível. Pode haver conflitos que podem resultar em substituições duplicadas e resultados não intencionais.
