Dieses Repository enthält die öffentlich zugängliche API-Dokumentation für Cerners Implementierung des HL7® FHIR® - Standards, auch bekannt als Cerners Ignite APIs.
Die bereitgestellte Dokumentation kann unter https://fhir.cerner.com/ eingesehen werden.
Fehlerberichte oder Hinweise zu Bereichen, in denen die Dokumentation unklar ist, sind als Repository-Probleme willkommen.
Abhängigkeiten mit Bundler installieren.
$ bundle install
Kompilieren Sie die Site mit nanoc.
$ bundle exec nanoc
Starten Sie einen lokalen Webserver mit nanoc.
$ bundle exec nanoc view
Navigieren Sie zu http://localhost:3000/, um die Site anzuzeigen. Wenn Sie Änderungen an der Site vornehmen, wiederholen Sie die letzten beiden Schritte, um den neuen Inhalt neu zu kompilieren und anzuzeigen.
Wir haben oben in einigen Markdown-Dateien Attribute hinzugefügt, um ein Layout zuzuweisen. Diese werden normalerweise nur für Seiten benötigt, die keine eigentliche API-Dokumentation sind (unsere Kompilierungsregel verwendet dieses Layoutattribut, bevor sie auf das API-Layout zurückgreift).
Die Layouts selbst werden im Layoutverzeichnis definiert. Einige Layouts (wie die API- oder FAQ-Layouts) werden wie oben erwähnt als Seitenvorlagen verwendet. Andere Layouts (z. B. Ressourcenkategorie-Layouts oder Kopf-/Fußzeilen-Layouts) werden verwendet, um Inhalte in andere Seiten einzubinden.
Es gibt Vorverarbeitungsregeln, die den Ordnerabgleich verwenden, um allen Markdown-Dateien für die API Versions- und Lösungsattribute hinzuzufügen. Das Einzige, was Sie tun müssen, damit dies funktioniert, ist, die Ressourcendokumentation im Ordnerpfad /[Lösung]/[Version]/ abzulegen.
Die Versions- und Lösungsattribute werden derzeit zum Flexen von CSS-Klassen, Seitenlinks und Navigationssymbolleisten/Seitenleisten für die API-Dokumentation verwendet.
Für Erstellungs- und Aktualisierungsvorgänge sind in der Regel JSON-Körper erforderlich, deren manuelle Dokumentation durch Markdown mühsam sein kann. Um diesen Prozess zu vereinfachen und die Konsistenz zu verbessern, haben wir den Helfer definition_table hinzugefügt, um eine Tabelle aus einer Yaml-Inhaltsdatei zu generieren.
Der definition_table Helfer erfordert drei Parameter: Inhalt, Aktion und Version.
content gibt an, welche Inhaltsdatei geladen werden soll.version gibt die Version der Inhaltsdatei an.action gibt an, welche aktionsspezifischen Variationen, die in der Inhaltsdatei definiert sind, in der generierten Tabelle wiedergegeben werden sollen. Typischerweise ist die Aktion :create oder :update. Die verfügbaren Aktionen werden in den Inhaltsdateien selbst definiert. Das Generieren einer Feldtabelle erfolgt durch Aufrufen der Methode definition_table über einen ERB-Aufruf in der Dokumentationsdatei, die die Tabelle benötigt.
Beispielsweise kann die DSTU2-Version von DocumentReference Create generiert werden mit:
<%= definition_table(:document_reference, :create, :dstu2) %>
Während andere Versionen von AllergyIntolerance Update generiert werden können (vorausgesetzt, dass entsprechende Definitionen verfügbar sind), verwenden Sie Folgendes:
<%= definition_table(:allergy_intolerance, :update, :r4) %>
Tatsächlich verweist der version auf einen Unterordner in lib/resources , in dem die Inhaltsdateien für diese Version gespeichert sind. Somit verweist definition_table(:document_reference, :create, :dstu2) auf lib/resources/dstu2/document_reference.yaml . Zum Hinzufügen neuer Versionen oder neuer Inhaltsdateien müssen lediglich ein entsprechend benannter Ordner und eine Inhaltsdatei erstellt werden.
definition_table liest diese Felder aus der Inhalts-YAML-Definition der Ressource:
Der Helfer terminolgy_table ist verfügbar, um eine Terminologiebindungstabelle aus derselben Yaml-Inhaltsdatei wie definition_table zu generieren.
Der Helfer terminolgy_table benötigt zwei Parameter: Inhalt und Version.
content gibt an, welche Inhaltsdatei geladen werden soll.version gibt die Version der Inhaltsdatei an. Das Generieren einer Terminologietabelle erfolgt durch Aufrufen der Methode terminology_table über einen ERB-Aufruf in der Dokumentationsdatei, die die Tabelle benötigt.
Beispielsweise kann die DSTU2-Version von AllergyIntolerance generiert werden mit:
<%= terminology_table(:allergy_intolerance, :dstu2) %>
Die Verarbeitung der version erfolgt wie bei definition_table .
terminology_table liest diese Felder aus der Inhalts-YAML-Definition der Ressource:
Der Inhalt wird in YAML-Dateien definiert und die meisten Felder sind optional. Wenn sie nicht angegeben werden, ist die resultierende Tabellenzelle einfach leer.
definition_table generiert verschachtelte Links für jedes Feld, dem diese URL vorangestellt ist.field_name_base_url generiert.lib/resources//types.yaml gefunden wird, wird es mit der angegebenen Ressource verknüpft.-Tags eingeschlossen, um die Formatierung beizubehalten.
fields .field_name_base_url generierte URL, sofern definiert.Es gelten die standardmäßigen YAML-Formatierungsregeln.
Zusätzlich zu den oben genannten Feldern kann jedes Feld ein action haben, das angibt, für welche Aktion oder Aktionen das Feld gilt. Wenn es definiert ist, wird das Feld nur beim Generieren einer Tabelle mit der angegebenen Aktion einbezogen. Es werden auch mehrere Aktionen unterstützt und können als Liste definiert werden:
Make the field apply to a single action
- name: subject
...
action: create
Make the field apply to multiple actions
- name: subject
...
action:
- create
- update
Ebenso können Feldwerte auch pro Aktion geflext werden:
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.
Der Name der Aktion ist nicht auf „Erstellen“ und „Aktualisieren“ beschränkt, es kann jedoch jeweils nur eine Aktion beim Generieren einer Feldtabelle verwendet werden.
Die Verknüpfung wird in einigen Formen unterstützt.
Die Feldnamen werden automatisch basierend auf der base_field_name_url verknüpft, sofern sie nicht durch den url Wert eines Felds überschrieben werden.
Die Type-Tabellenzelle generiert Links basierend auf URL-Schlüssel-Wert-Paaren, die in lib/resources/ definiert sind. Jedes in einem type gefundene Wort wird durch die angegebene URL ersetzt.
Die description und note unterstützen auch die Verlinkung über die Verwendung von „“- und [] -Tags. In ``-Tags eingeschlossene Wörter werden, wenn möglich, gemäß der Datei types.yaml verknüpft oder, wenn nicht, nur als -Tags formatiert. Bei in [] eingeschlossenen Wörtern wird davon ausgegangen, dass es sich um Verweise auf andere Felder in derselben Tabelle handelt.
Im Allgemeinen ist es am besten, im type keine „Tags“ zu verwenden, obwohl dies möglich ist. Es kann zu Konflikten kommen, die zu doppelten Ersetzungen und unbeabsichtigten Ergebnissen führen können.
