이 저장소에는 Cerner의 Ignite API라고도 알려진 Cerner의 HL7 ® FHIR ® 표준 구현에 대한 공개 API 문서가 포함되어 있습니다.
배포된 문서는 https://fhir.cerner.com/에서 볼 수 있습니다.
문서가 불분명한 영역에 대한 버그 보고서나 메모는 저장소 문제로 환영합니다.
번들러를 사용하여 종속성을 설치합니다.
$ bundle install
nanoc로 사이트를 컴파일합니다.
$ bundle exec nanoc
nanoc를 사용하여 로컬 웹 서버를 시작합니다.
$ bundle exec nanoc view
사이트를 보려면 http://localhost:3000/으로 이동하세요. 사이트를 변경할 때 마지막 두 단계를 반복하여 새 콘텐츠를 다시 컴파일하고 확인하세요.
레이아웃을 할당하기 위해 일부 마크다운 파일 상단에 속성을 추가했습니다. 이는 일반적으로 실제 API 문서가 아닌 페이지에만 필요합니다(우리의 컴파일 규칙은 API 레이아웃으로 대체되기 전에 해당 레이아웃 속성을 사용합니다).
레이아웃 자체는 레이아웃 디렉터리에 정의됩니다. 위에서 언급한 것처럼 일부 레이아웃(예: API 또는 FAQ 레이아웃)은 페이지 템플릿으로 사용됩니다. 다른 레이아웃(예: 리소스 범주 레이아웃 또는 머리글/바닥글 레이아웃)은 다른 페이지에 콘텐츠를 포함하는 데 사용됩니다.
폴더 일치를 사용하여 API의 모든 마크다운 파일에 버전 및 솔루션 특성을 추가하는 전처리 규칙이 있습니다. 이 작업을 수행하기 위해 해야 할 유일한 일은 리소스 문서를 /[solution]/[version]/ 폴더 경로에 넣는 것입니다.
버전 및 솔루션 속성은 현재 API 문서의 CSS 클래스, 페이지 링크 및 탐색 도구 모음/사이드바를 조정하는 데 사용됩니다.
만들기 및 업데이트 작업에는 일반적으로 마크다운을 통해 수동으로 문서화하는 것이 지루할 수 있는 JSON 본문이 필요합니다. 이 프로세스를 단순화하고 일관성을 향상시키기 위해 yaml 콘텐츠 파일에서 테이블을 생성하는 definition_table 도우미를 추가했습니다.
definition_table 도우미에는 콘텐츠, 작업, 버전이라는 3개의 매개변수가 필요합니다.
content 로드할 콘텐츠 파일을 나타냅니다.version 콘텐츠 파일의 버전을 나타냅니다.action 생성된 테이블에 반영하기 위해 콘텐츠 파일에 정의된 작업별 변형을 나타냅니다. 일반적으로 작업은 :create 또는 :update입니다. 사용 가능한 작업은 콘텐츠 파일 자체에 정의되어 있습니다. 필드 테이블 생성은 테이블이 필요한 문서 파일에서 ERB 호출을 통해 definition_table 메소드를 호출하여 수행됩니다.
예를 들어 DocumentReference Create의 DSTU2 버전은 다음을 사용하여 생성할 수 있습니다.
<%= definition_table(:document_reference, :create, :dstu2) %>
AllergyIntolerance 업데이트의 다른 버전은 다음을 사용하여 생성될 수 있습니다(적절한 정의가 사용 가능하다고 가정).
<%= 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/<version>/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/<id> value.
- create: The id field must not be set when performing an update operation.
작업 이름은 만들기 및 업데이트로 제한되지 않지만 필드 테이블을 생성할 때 한 번에 하나의 작업만 사용할 수 있습니다.
연결은 몇 가지 형태로 지원됩니다.
필드 이름은 필드의 url 값으로 재정의되지 않는 한 base_field_name_url 기반으로 자동으로 연결됩니다.
유형 테이블 셀은 lib/resources/<version>/types.yaml 에 정의된 URL 키-값 쌍을 기반으로 링크를 생성합니다. type 필드에 있는 모든 단어는 지정된 URL로 대체됩니다.
description 및 note 필드는 `` 및 [] 태그를 사용하여 연결하는 것도 지원합니다. `` 태그로 묶인 단어는 가능하면 types.yaml 파일에 따라 연결되고, 그렇지 않은 경우에는 <code> 태그 형식으로 지정됩니다. [] 안의 단어는 동일한 테이블의 다른 필드에 대한 참조로 간주됩니다.
일반적으로 가능하더라도 type 필드에 `` 태그를 사용하지 않는 것이 가장 좋습니다. 중복 교체 및 의도하지 않은 결과를 초래할 수 있는 충돌이 있을 수 있습니다.
