HL7 FHIR JP Core ImplementationGuide
1.1.2-url - ci-build
Japan
HL7 FHIR JP Core ImplementationGuide - Local Development build (v1.1.2-url) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
項目 | 内容 |
定義URL | http://jpfhir.jp/fhir/core/StructureDefinition/JP_Encounter |
Version | 1.1.2-url |
Name | JP_Encounter |
Title | JP Core Encounter Profile |
Status | Active ( 2023-06-26 ) |
Copyright | Copyright FHIR Japanese implementation research working group in Japan Association of Medical Informatics (JAMI) 一般社団法人日本医療情報学会NeXEHRS課題研究会FHIR日本実装検討WG |
このプロファイルはEncounterリソースに対して、来院/入院情報のデータを送受信するための基礎となる制約と拡張を定めたものである。
このV1.1.2-url 版は、CodeSystemのシステムURIをOID形式からhttp:で始まるURL形式に変更したバージョンです。
例)OID形式:urn:oid:1.2.392.10495.x.y.z
→ http:で始まるURL形式: http://jpfhir/fhire/core/CodeSystem/…..
電子カルテ情報共有サービスの実装ガイドではこのJP-Core v1.1.2-url版を参照しています。
通常版はこちらを参照ください。
本プロファイルは、患者の医療機関受診に関する情報の登録や検索、取得のために 、FHIR Encounter リソースを使用するにあたっての、最低限の制約を記述したものである。Encounter リソースに対して本プロファイルに準拠する場合に必須となる要素や、サポートすべき拡張、用語、検索パラメータを定義する。
本プロファイルは、以下のようなユースケースを想定している。
患者に関連したEncounterの情報はその利用される状況によって特徴づけられる。例えば、外来、救急、在宅医療、入院、およびオンライン受診の情報も含まれる。Encounterは入院前手続き、外来受診、入院、入院中の滞在、および退院などの一連のライフサイクルを含む。Encounterに含まれる、PractitionerやLocationといった情報は状況に応じて変更されていくことがある。
このようにEncounterの適用範囲は広範になるため、すべてのエレメントがすべての状況で利用されるとは限らない。このため、入院/退院に関連した情報は、Encounter内のhospitalizationエレメントに保持される。classエレメントはこれらの状況を区別するために使用され、これによりさらなる検証とビジネスルールの適用が導かれる。
また、どのビジネスイベントが新しいEncounterの開始につながるのか、あるいはEncounterにどのようなレベルの集計が使用されるのかについては、組織ごと(および管轄や国ごと)に大きな違いがある。例えば、入院中の外来診療/開業医への一回の来院は、それぞれ新しいEncounterのインスタンスにつながるかもしれないが、個別の運用や関係するシステムによっては、これが入院全体で一つのインスタンスに集約されることもあり得る。会計システムなどの財務的な理由またはその他の理由でEncounterのグループを導入する場合には、さらに多くの集約が行われる可能性がある。Encountersは、partOfエレメントを用いて他のEncountersの下に集約またはグループ化することができる。例についてはこちらのリンクを参照すること。
Encounterインスタンスは、入院前情報を表現するために実際の外来や入院が行われる前に存在することがある。これには、予定された開始日または予定された場所を表現するためにEncounterを使用することも含まれる。この場合、status要素は「planned」に設定される。
Hospitalizationコンポーネントは、入院イベントに関連する拡張情報を格納するためのものである。これは常に、Encounter自体と同じ期間であることが期待される。期間が異なる場合は、別のEncounterのインスタンスを使用して、このEncounterのインスタンスの一部としてpartOfエレメントを使用してこの情報を取り込むべきである。
ProcedureとEncounterはお互いへの参照を持つが、これらは異なるProcedureとするべきである。1つは、Encounterの間に行われたProcedure(Procedure.encounterに格納)、もう1つは、Encounterが別のProcedureの結果である場合(Encounter.indicationに格納)、例えば、以前のProcedureによる合併症を解決するためのフォローアップのEncounterなどである。
Encounterのライフサイクルでは、多くのステータス(status)を遷移する。一般的に、これらは組織のワークフローの順に、 planned(計画), in-progress(進行中), finished/cancelled(終了/キャンセル)となる。
このステータス情報はしばしば他のことに使用され、その際にはステータス履歴の分析が必要となることもある。これは、Encounterのすべてのhistoryを検索し、それぞれの期間をチェックし、何らかの形で後処理を行うことで可能となる。しかし、このような負担を軽減するために(またはシステムがリソース履歴をサポートしていない場合のために)、statusHistoryコンポーネントが用意されている。
そのEncounterが「来院した/入院した」ということを判断できる、statusの値は存在しない。Encounterの使用法およびジネスプラクティス/ポリシ/ワークフロー/タイプがこの定義に影響を与える可能性がある。(例:急性期医療施設、高齢者医療センター、外来診療所、救急部、地域に根ざした診療所など)
arrived, triaged または in-progress のstatusは入院の開始と考えられ、入力されたhospitalizationサブコンポーネントの存在を意味する。
on leave のstatusは、例えば、患者が週末に帰宅することを許可された場合や、その他の形式の外部イベントの場合など、入院の一部である場合もあれば、そうでない場合もある。 Encounterには「入院した」という固定した定義はないので、例えば外来(日帰り手術-大腸内視鏡検査)などの例では、患者は入院しているとも考えられる。少なくとも、ステータスが「in-progress」の場合は、患者は入院していると考えられる。
Encounterリソースは予約情報を格納するために使用されるべきではなく、Appointmentリソースが予約情報のために使用されることが意図されている。多くのシステムでは、外来患者のEncounter(これはEncounterの範囲である)とAppointmentが同時に使用されていることに注意してほしい。FHIRでは、AppointmentはEncounterの日付を確定するために使用され、一方Encounterは実際の来院/入院等に関する情報、すなわち患者が現れることに適用される。
このように、「planned」のstatusのEncounterは、それを予定したAppointmentと同一ではないが、それは実際に発生する前のEncounterであり、Encounterが完了するまでに更新されることが期待される。患者の場所への到着は、必ずしもEncounterの開始を意味するものではない(例えば、患者が実際に施術者に診てもらうよりも1時間早く到着しても、Encounterの開始にはならない。)。
Appointmentは通常、Appointmentの計画段階、検索、空いている時間の場所の特定、そしてAppointmentの作成に使われる。このプロセスが完了し、Appointmentが開始されると、Appointmentは達成されたものとしてマークされ、新しく作成されたEncounterにリンクされる。
この新しいEncounterは、施設のある場所に入院したときに「arrived」状態で始まり、その後、病棟を移動した際には別のpartOfで関連付けられたEncounterが始まるかもしれない。
Communicationリソースは、直接の接触がない場合に、医療従事者と患者の間で同時に行われる対話に使用される。例としては、電話によるメッセージや、通信文書の送信などがある。通信資源には継続時間は記録されないが、送信時間と受信時間が含まれる可能性がある。
外来における入院前受診、来院、入院診療における入院、滞在、退院といった、全ての患者受診を表す。
Encounterリソースは、class要素を用いて医療提供環境を特徴づけることができる。具体的な例としては以下の環境が想定されている。
Encounter リソースは発生単位が医療機関や組織ごとに異なる可能性がある。例えば、入院中に開業医が1回訪問するたびに新しいEncounterインスタンスが発生する可能性や、地域の慣行や関連システムによっては、入院全体で1つのインスタンスに集約される場合もある。
Encounterリソースは、partOf要素を使用して、他のEncounterインスタンスの下に集約できる。
またEncounterリソースは、受診前の情報を伝達するために生成することもできる。この場合、status要素は「planned」に設定される。患者の受信内容が入院に関連する場合は、hospitalization要素に入院イベントに関連する拡張情報を格納できる。
なおこの入院イベントの関連付けは、Encounterリソースのperiod要素で指定されている期間と同じ期間内であることが望ましい。もし期間が異なる場合は、別のEncounterインスタンスを使用し、このEncounterインスタンスの一部として情報を関連付ける必要がある。
Usage:
Description of Profiles, Differentials, Snapshots and how the different presentations work.
Other representations of profile: CSV, Excel, Schematron
Encounter リソースは、次の要素を持たなければならない。
JP Encounter リソースで使用される拡張は次の通りである。
コンフォーマンス | パラメータ | 型 | 例 |
---|---|---|---|
SHALL | identifier | token | GET [base]/Encounter?identifier=http://hl7.org/fhir/sid/jpsys|123456 |
SHOULD | patient | reference | GET [base]/Encounter?patient=Patient/123456 |
SHOULD | date, patient | date, reference | GET [base]/Encounter?date=eq2021-04-15&patient=Patient/123456 |
SHOULD | class, patient | token, reference | GET [base]/Encounter?class=http://terminology.hl7.org/CodeSystem/v3-ActCode|EMER&patient=Patient/123456 |
SHOULD | patient, type | reference, token | GET [base]/Encounter?patient=Patient/123456&type=http://terminology.hl7.org/CodeSystem/encounter-type|ADMS |
SHOULD | patient, status | reference, token | GET [base]/Encounter?patient=Patient/123456&status=arrived |
identifier 検索パラメータを使用して、診察番号等の識別子によるEncounterの検索をサポートしなければならない(SHALL)
GET [base]/Encounter?identifier={system|}[code]
例:
GET [base]/Encounter?identifier=http://hl7.org/fhir/sid/jpsys|123456
指定された識別子に一致するEncounterリソースを含むBundleを検索する。
次の検索パラメータをサポートすることが望ましい。
patient 検索パラメータを使用して、識別子によるEncounterの検索をサポートすることが望ましい(SHOULD)
GET [base]/Encounter?patient={reference}
例:
GET [base]/Encounter?patient=Patient/123456
指定されたpatientに一致するEncounterリソースを含むBundleを検索する。
date, patient 検索パラメータを使用して、識別子によるEncounterの検索をサポートすることが望ましい(SHOULD)
GET [base]/Encounter?date={date}&patient={reference}
例:
GET [base]/Encounter?date=eq2021-04-15&patient=Patient/123456
指定されたdate,patientに一致するEncounterリソースを含むBundleを検索する。
class, patient 検索パラメータを使用して、識別子によるEncounterの検索をサポートすることが望ましい(SHOULD)
GET [base]/Encounter?class={token}&patient={reference}
例:
GET [base]/Encounter?class=http://terminology.hl7.org/CodeSystem/v3-ActCode|EMER&patient=Patient/123456
指定されたclass,patientに一致するEncounterリソースを含むBundleを検索する。
patient, type 検索パラメータを使用して、識別子によるEncounterの検索をサポートすることが望ましい(SHOULD)
GET [base]/Encounter?patient={reference}&type={token}
例:
GET [base]/Encounter?patient=Patient/123456&type=http://terminology.hl7.org/CodeSystem/encounter-type|ADMS
指定されたpatient, typeに一致するEncounterリソースを含むBundleを検索する。
patient, status 検索パラメータを使用して、識別子によるEncounterの検索をサポートすることが望ましい(SHOULD)
GET [base]/Encounter?patient={reference}&status={token}
例:
GET [base]/Encounter?patientPatient/123456&status=arrive
指定されたpatient, statusに一致するEncounterリソースを含むBundleを検索する。
JP Encounter リソースに対して使用される操作は次の通りである。
この操作は、この操作が呼び出された特定のEncounterリソースに関連する全ての情報を返す。 応答は "searchset" タイプのBundleリソースである。
この操作の公式なURLは以下である。
https://hl7.org/fhir/R4/operation-encounter-everything.html
URL: [base]/Encounter/[id]/$everything
本操作は、べき等な操作である。
名前 | 多重度 | 型 | 説明 |
---|---|---|---|
_since | 0..1 | instant | 指定された日時以降に更新されたリソースのみが応答に含まれる。 |
_type | 0..* | code | 応答に含むFHIRリソース型を、カンマ区切りで指定する。指定されない場合は、サーバは全てのリソース型を対象とする。 |
_count | 0..1 | integer | Bundleの1ページに含まれるリソース件数を指定。 |
名前 | 多重度 | 型 | 説明 |
---|---|---|---|
return | 1..1 | Bundle | バンドルのタイプは"searchset"である。この操作の結果は、リソースとして直接返される。 |
リクエスト:単一のEncounterに関連する全てのリソースを取得する。
GET [base]/Encounter/example/$everything
[some headers]
レスポンス:指定されたEncounterに関連する全てのリソースを返す。
HTTP/1.1 200 OK
[other headers]
{
"resourceType": "Bundle",
"id": "p001",
"meta": {
"lastUpdated": "2020-01-06T15:11:11.447+00:00"
},
"type": "searchset",
"entry": [
{
"fullUrl": "http://example.org/fhir/Encounter/p001",
"resource": {
"resourceType": "Encounter",
・・・
},
}
]
}
Encounterリソースは、予定情報や予約の保存には使用されない。予約の保存にはAppointmentリソースを利用すること。FHIRでは、Appointmentは診察の日付を決定するのに利用されるのに対して、Encounterは実際に患者が来院して診察が実施されたことを表現する。 そのため、「計画済み」 status の Encounter は実際に発生する前の Encounter であり、診療行為が完了するまで更新されることが期待される。