このリポジトリには、Cerner の Ignite API とも呼ばれる Cerner の HL7 ® FHIR ®標準の実装に関する公開 API ドキュメントが格納されています。
導入されたドキュメントは https://fhir.cerner.com/ で参照できます。
バグレポートやドキュメントが不明確な領域のメモは、リポジトリの問題として歓迎されます。
バンドラーを使用して依存関係をインストールします。
$ bundle install
nanoc を使用してサイトをコンパイルします。
$ bundle exec nanoc
nanoc を使用してローカル Web サーバーを起動します。
$ bundle exec nanoc view
http://localhost:3000/ に移動してサイトを表示します。サイトに変更を加える場合は、最後の 2 つの手順を繰り返して再コンパイルし、新しいコンテンツを表示します。
レイアウトを割り当てるために、いくつかのマークダウン ファイルの先頭に属性を追加しました。これらは通常、実際の API ドキュメントではないページにのみ必要です (コンパイル ルールは、API レイアウトにフォールバックする前にそのレイアウト属性を使用します)。
レイアウト自体は、レイアウト ディレクトリで定義されます。一部のレイアウト (API レイアウトや FAQ レイアウトなど) は、前述のようにページ テンプレートとして使用されます。他のレイアウト (リソース カテゴリ レイアウトやヘッダー/フッター レイアウトなど) は、他のページにコンテンツを含めるために使用されます。
フォルダーの一致を使用して、API のすべてのマークダウン ファイルにバージョン属性とソリューション属性を追加する前処理ルールがあります。これを機能させるために必要なのは、リソース ドキュメントを /[ソリューション]/[バージョン]/ フォルダー パスに置くことだけです。
現在、バージョン属性とソリューション属性は、API ドキュメントの Flex CSS クラス、ページ リンク、ナビゲーション ツールバー/サイドバーに使用されています。
通常、作成および更新操作には JSON ボディが必要ですが、マークダウンを使用して手動で文書化するのは面倒な場合があります。このプロセスを簡素化し、一貫性を向上させるために、yaml コンテンツ ファイルからテーブルを生成するためのdefinition_tableヘルパーを追加しました。
definition_tableヘルパーには、content、action、version の 3 つのパラメータが必要です。
contentどのコンテンツ ファイルをロードするかを示します。versionコンテンツ ファイルのバージョンを示します。actionコンテンツ ファイルで定義されているアクション固有のバリエーションを、生成されたテーブルに反映するかを示します。通常、アクションは :create または :update です。使用可能なアクションはコンテンツ ファイル自体で定義されます。フィールド テーブルの生成は、テーブルが必要なドキュメント ファイルで ERB 呼び出しを通じてdefinition_tableメソッドを呼び出すことによって行われます。
たとえば、DocumentReference Create の DSTU2 バージョンは次を使用して生成できます。
<%= definition_table(:document_reference, :create, :dstu2) %>
一方、AllergyIntolerance Update の他のバージョンは、以下を使用して生成できます (適切な定義が利用可能であると仮定します)。
<%= 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ヘルパーはdefinition_tableと同じ yaml コンテンツ ファイルから用語バインディング テーブルを生成するために使用できます。
terminolgy_tableヘルパーには、コンテンツとバージョンという 2 つのパラメーターが必要です。
contentどのコンテンツ ファイルをロードするかを示します。versionコンテンツ ファイルのバージョンを示します。用語テーブルの生成は、テーブルが必要なドキュメント ファイルで ERB 呼び出しを介してterminology_tableメソッドを呼び出すことによって行われます。
たとえば、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が定義されている場合は、生成された 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.
アクションの名前は作成と更新に限定されませんが、フィールド テーブルの生成時に一度に使用できるアクションは 1 つだけです。
リンクはいくつかの形式でサポートされています。
フィールド名は、フィールドのurl値によってオーバーライドされない限り、 base_field_name_urlに基づいて自動的にリンクされます。
Type テーブルのセルは、 lib/resources/で定義された URL のキーと値のペアに基づいてリンクを生成します。 typeフィールドで見つかった単語は、指定された URL に置き換えられます。
descriptionフィールドとnoteフィールドでは、`` タグと[]タグを使用したリンクもサポートされています。 ` タグで囲まれた単語は、可能であれば、 types.yamlファイルに従ってリンクされ、そうでない場合は、単にタグとしてフォーマットされます。 []で囲まれた単語は、同じテーブル内の他のフィールドへの参照であるとみなされます。
一般に、 typeフィールドでは `` タグを使用することは可能ですが、使用しないことをお勧めします。競合が発生し、重複した置換や意図しない結果が生じる可能性があります。
