Ce référentiel héberge la documentation API publique pour la mise en œuvre par Cerner de la norme HL7 ® FHIR ® , également connue sous le nom d'API Ignite de Cerner.
La documentation déployée peut être consultée sur https://fhir.cerner.com/.
Les rapports de bogues ou les notes sur les domaines dans lesquels la documentation n'est pas claire sont les bienvenus en tant que problèmes de référentiel.
Installez les dépendances avec le bundler.
$ bundle install
Compilez le site avec nanoc.
$ bundle exec nanoc
Démarrez un serveur Web local avec nanoc.
$ bundle exec nanoc view
Accédez à http://localhost:3000/ pour afficher le site. Lorsque vous apportez des modifications au site, répétez les deux dernières étapes pour recompiler et afficher le nouveau contenu.
Nous avons ajouté des attributs en haut de certains fichiers markdown pour attribuer une mise en page. Ceux-ci ne sont généralement nécessaires que pour les pages qui ne constituent pas une véritable documentation de l'API (notre règle de compilation utilise cet attribut de mise en page avant de revenir à la mise en page de l'API).
Les mises en page elles-mêmes sont définies dans le répertoire des mises en page. Certaines mises en page (comme les mises en page API ou FAQ) sont utilisées comme modèles de page comme mentionné ci-dessus. D'autres mises en page (telles que les mises en page de catégories de ressources ou les mises en page d'en-tête/pied de page) sont utilisées pour inclure du contenu dans d'autres pages.
Il existe des règles de prétraitement qui utilisent la correspondance de dossiers pour ajouter des attributs de version et de solution à tous les fichiers de démarque pour l'API. La seule chose que vous devez faire pour que cela fonctionne est de placer la documentation des ressources dans le chemin du dossier /[solution]/[version]/.
Les attributs de version et de solution sont actuellement utilisés pour adapter les classes CSS, les liens de page et les barres d'outils/barres latérales de navigation pour la documentation de l'API.
Les opérations de création et de mise à jour nécessitent généralement des corps JSON qui peuvent être fastidieux à documenter manuellement via markdown. Pour simplifier ce processus et améliorer la cohérence, nous avons ajouté l'assistant definition_table pour générer une table à partir d'un fichier de contenu yaml.
L'assistant definition_table nécessite 3 paramètres : contenu, action et version.
content indique quel fichier de contenu charger.version indique la version du fichier de contenu.action indique les variations spécifiques à l'action définies dans le fichier de contenu à refléter dans le tableau généré. Généralement, l'action sera :create ou :update. Les actions disponibles sont définies dans les fichiers de contenu eux-mêmes. La génération d'une table de champs s'effectue en appelant la méthode definition_table via un appel ERB dans le fichier de documentation nécessitant la table.
Par exemple, la version DSTU2 de DocumentReference Create peut être générée en utilisant :
<%= definition_table(:document_reference, :create, :dstu2) %>
Alors que d'autres versions de AllergyIntolerance Update peuvent être générées (en supposant que les définitions appropriées soient disponibles) en utilisant :
<%= definition_table(:allergy_intolerance, :update, :r4) %>
En réalité, le paramètre version fait référence à un sous-dossier dans lib/resources où sont stockés les fichiers de contenu de cette version. Ainsi definition_table(:document_reference, :create, :dstu2) fait référence à lib/resources/dstu2/document_reference.yaml . L'ajout de nouvelles versions ou de nouveaux fichiers de contenu consiste simplement à créer un dossier et un fichier de contenu correctement nommés.
definition_table lit ces champs à partir de la définition yaml du contenu de la ressource :
L'assistant terminolgy_table est disponible pour générer une table de liaison terminologique à partir du même fichier de contenu yaml que definition_table .
L'assistant terminolgy_table nécessite 2 paramètres : contenu et version.
content indique quel fichier de contenu charger.version indique la version du fichier de contenu. La génération d'une table terminologique s'effectue en appelant la méthode terminology_table via un appel ERB dans le fichier de documentation nécessitant la table.
Par exemple, la version DSTU2 d'AllergyIntolerance peut être générée en utilisant :
<%= terminology_table(:allergy_intolerance, :dstu2) %>
Le traitement des paramètres version est géré de la même manière que definition_table .
terminology_table lit ces champs à partir de la définition yaml du contenu de la ressource :
Le contenu est défini dans les fichiers YAML et la plupart des champs sont facultatifs. S'ils ne sont pas fournis, la cellule du tableau résultant sera simplement vide.
definition_table générera des liens imbriqués pour chaque champ précédé de cette URL.field_name_base_url .lib/resources//types.yaml , ce champ sera lié à la ressource spécifiée.pour préserver le formatage.
fields .field_name_base_url si elle est définie.Les règles de formatage YAML standard s'appliquent.
En plus des champs ci-dessus, chaque champ peut avoir un champ action qui indique à quelle(s) action(s) le champ s'applique. Une fois défini, le champ ne sera inclus que lors de la génération d'une table avec l'action spécifiée. Plusieurs actions sont également prises en charge et peuvent être définies sous forme de liste :
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 même, les valeurs des champs peuvent également être modifiées par action :
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.
Le nom de l'action ne se limite pas à créer et mettre à jour, mais une seule action peut être utilisée à la fois lors de la génération d'une table de champs.
La liaison est prise en charge sous quelques formes.
Les noms de champs seront automatiquement liés en fonction de la base_field_name_url à moins qu'ils ne soient remplacés par la valeur de url d'un champ.
La cellule du tableau Type générera des liens basés sur les paires clé-valeur d'URL définies dans lib/resources/ . Tout mot trouvé dans un champ type sera remplacé par l'URL spécifiée.
Les champs description et note prennent également en charge les liens via l'utilisation des balises `` et [] . Les mots entourés de balises `` seront liés selon le fichier types.yaml , si possible, ou simplement formatés en balises sinon. Les mots entourés de [] seront considérés comme des références à d'autres champs de la même table.
En général, il est préférable de ne pas utiliser de balises `` dans le champ type , bien que cela soit possible. Il peut y avoir des conflits pouvant entraîner des remplacements en double et des résultats inattendus.
